text:
Services and Multistage Development of a Graphcool Service

Services and Multistage Development of a Graphcool Service
This document is WIP, feedback welcome.
Motivation
Two observations:

Working with the Graphcool Framework requires frequent changes to the setup of a deployed service. Oftentimes, this includes synchronizing changes across multiple branches of development.

Developing a project in multiple stages has become a best practice that comes with a lot of benefits. Quote from Wikipedia:

Multi-stage continuous integration is a software development technique intended to achieve highly integrated parallel development activity while reducing the scope of integration problems.

Therefore, delivering the best possible experience for multi-stage development is crucial.

Outline
This is the how the basic workflow for developing a Graphcool service looks like:

obtain the definition of a deployed service
modify it locally
apply the updated definotion to the service

The first two steps are already well understood and covered in the Graphcool Framework Preview, whereas the last step needs further research.
The purpose of this document is to define the status quo and propose new capabilities for workflows surrounding the topics of

deploying changes to a single service
synchronizing changes between multiple definitions
available migration paths for both of the above

Terminology

Note: Terminology in this document is still very much in flux.

Service
The Graphcool Framework provides an API that acts as an abstraction layer on top of a database, combining core ideas from GraphQL and Serverless for a great developer experience.
Interacting with the generated API gives access to the database, external data sources and an advanced event system that can be used to employ business logic and realtime communication.
A server instance running the Graphcool Framework is called a (Graphcool) service.
Stateful Components vs. Stateless Components
A service consists of stateless and stateful components.

Stateful Components: the shape and state of the database

Type definition: model types, non-model types, scalar + relation fields, relations, enums
Nodes and Edges: Actual data in the database

Stateless Components: components that employ business logic

Permissions: operation, a list of fields, authenticated flag, potential permission query
Functions: Code, additional documents like subscription query, environment variables
Root Tokens

Service Definition vs. Service Data
Stateful and stateless components of a service can be grouped into a definition part and a data part:

Service Definition: All information that is needed to describe & deploy a Graphcool service. This incluedes the set of all stateless components combined with type definitions. The service definition can be fully represented as a set of files, tied together in a graphcool.yml file.

A service definition does not need to be currently deployed on an actual service.
A service definition is consistent, if the type definitions are valid and all stateless components are valid and compatible with them.

Examples: a type definition with a capitalized field name is not valid. a type definition with a relational field of type [Comment] is not valid. A permission query containing SomeItemExists is not compatible with a type definition that does not contain the Item model.

Service Data: All nodes and edges in their entirety.

A service is consistent, if its service definition is consistent and the service data adheres to the type definition.

Examples: if the Item table contains duplicate values for the slug columm, but the according field was declared as slug: String! @isUnique, the service is not consistent.

Service Deployment
Applying a specific service definition to a new or existing service is called a service deployment.
Service Stages
When doing multi-stage development, several service definitions are deployed to different instances of the same service. These instances are referred to as stages of that service.
Working with multiple service definitions in parallel is what enables the main benefits of multi-stage development mentioned above: "parallel development activity while reducing the scope of integration problems".
A typical setup might look like this:

development/dev

used by individual developers
usually deployed locally
multiple definitions might exist at the same time, referred to as dev-1, dev-2 and so on
changes happen very frequently
mostly test data is used

staging

used to test & integrate service definition with external systems
usually deployed remotely
typically, only one definition exists at the same time
changes happen quite frequently, but in a more controlled manner
a mix of real and test data is used

production/prod

the definition of the service in production
only one exists
changes happen rather not frequently
runs against live data

Service definitions progress through the different stages. Starting at development, over staging and finally to production.
Desired Properties of a Service Deployment
Deploying a definition to a service should guarantee the following properties:

(P1) No data loss: No existing data is deleted without the explicit consent of the developer
(P2) Integrity: If the service is consistent before a deployment, it is consistent afterwards

Deployment scenarios
Let's run through a few scenarios that might come up during multi-stage development under the light of these properties.

Observation: The core complexity in guaranteeing P1 and P2 lies in managing changes to the type definition.

While it's important for P2 that changes to permissions, functions and root tokens are consistent and atomic, it is sufficient to check this for the definition to be created - the entire history of those components is not relevant.
This is not the case for type definitions, as shown in the following two scenarios:
S1 - Renaming a field
Consider the following types-staging.graphql file:
# types-staging

type Post implements Node {
  id: ID! @isUnique
  name: String
}

Imagine we obtain a copy from the staging configuration and update the field name: String to title: String in the new dev-1 definition:
# types-dev-1

type Post implements Node {
  id: ID! @isUnique
  title: String
}

Now, we want to deploy dev-1 to staging. The following is a potential result:

a new field title: String with value null is added to all existing nodes of type Post
the existing field name: String, including its data, is removed

Clearly, this is not intended and would result in unwanted data loss, violating P1.
S2 - Making an optional scalar field required
Consider the following types-staging.graphql file:
# types-staging

type Post implements Node {
  id: ID! @isUnique
  name: String
}

Let's change the type of name: String to name: String! in a new dev-2 definition:
# types-dev-2

type Post implements Node {
  id: ID! @isUnique
  name: String!
}

Deploying dev-2 to staging would result in a violation of property P2, as there might be nodes where the name field is currently null.
More Scenarios
Scalar fields

S3 - adding constraints

name: String => name: String! @isUnique

S4 - changing the list modifier

name: String => names: [String!]!
name: String! => names: [String!]!
names: [String!]! => name: String!
names: [String!]! => name: String

S5 - changing the type

name: String => name: Int
name: String => name: Int!

Relation fields

S6 - changing the cardinality

comment: Comment @relation("AuthorOnComment") => comments: [Comment!]! @relation("AuthorOnComment")
comment: Comment! @relation("AuthorOnComment") => comments: [Comment!]! @relation("AuthorOnComment")
comments: [Comment!]! @relation("AuthorOnComment") => comment: Comment @relation("AuthorOnComment")
comments: [Comment!]! @relation("AuthorOnComment") => comment: Comment! @relation("AuthorOnComment")

Relations

S7 - renaming

comment: Comment @relation("AuthorOnComment") => comment: Comment @relation("AuthorComment")

Model Types

S8 - renaming a model type

type Item @model { ... } => type Table @model { ... }

Non-Model Types

S9 - renaming a non-model type

type ItemPayload { ... } => type Item { ... }

Enums

S10 - removing an enum value
S11 - renaming an enum value
S12 - renaming an enum

Tracks
Because of the above observation, we can focus on investigating changes to type definitions. Comparing type definitions from two stages when deploying is similar to comparing two commits when merging in git.
But there is one key difference: for git merging, it is sufficient to only take the status of both commits into account for the comparison.
For a Graphcool service, it is actually crucial to be able to track the evolution of a single element in the type definition, across renaming, type changes and other modifications. The reason is that the type definition is highly entangled with the actual data.
A first definition
Let's try to capture the meaning of the track of a single element in the type definition of a service definition:

Definition: The track of a single element in a given type definition is a chronologically ordered list that contains the element itself, plus all instances of this element in type definitions of previous and subsequent configurations.

This definition is expandable to all elements in the type definition. As a reminder, these are available elements in a type definition:

model and non-model types
scalar fields, relation fields
relations
enums

Definition: The track of a given type definition is the set of all tracks of all elements it contains.

The intuition behind tracks
The crucial and missing part of the above definition of a track, is the classification of changes as to whether they preserve a track or not.
For example, we have an intuitive understanding as to whether or not a field in two definitions belong to the same track. We applied that in the two scenarios above.

If deleting the first field (including its data) and adding the second field has the desired outcome already, the two fields do not belong to the same track. This is not desired when solely renaming a field, so renaming a field is preserving the field track, which was seen in S1.

In S2, we saw the update from an optional to a required field. Most of the time, it is probably desirable that both fields belong to the same track, because nodes that already have a value should likely keep it, while nodes that currently store null should apply a new value based on a certain kind of "migration logic". Most likely, changing an optional field to be required is preserving the field track.

Examples

In Scenario 1 from above, a field name: String was renamed to title: String.
This is its track:
[{configuration: c1, name: String} {configuration: c2, title: String}]

In Scenario 2, a field name: String was updated to name: String!. This is its track:
[{configuration: c1, name: String}, {configuration: c2, name: String!}]

Explicit tracks
Consider S1 again. We're updating field name: String to title: String, and as pointed out before, this would lead to data loss, violating property P1.
What's an appropriate means to allow this update, while still fulfilling P1?

Observation: if the developer is making the connection between name: String and title: String explicit, the rename operation can fulfill P1 trivially.

Note: the current means to rename a field while fulfilling P1 is to use the @rename(oldName: String!) directive. In its current form, this does not allow for keeping track of the change afterwards, as the @rename directive is not preserved in the type definition.

Explicit migration logic
In S2, we're updating a field name: String to name: String!, which violates P2, because nodes with a name of value null might already exist.

Observation: additional to an explicit connection, the developer has to provide a logic for migrating old null values to non-null values to fulfill P2.

Note: currently, the @migrationValue(value: String) directive can be used to make a field required while fulfilling P2. However, this approach is fairly limited (all nodes will be migrated to a single value), and suffers the same shortcomings.

Migrations
In the previous section, we saw that keeping track of a single element across modifications are important to ensure no data loss. In ambiguous cases, the developer can provide additional information that resolve ambiguities.
Keeping track of all changes is not always sufficient to ensuring data integrity. Again, the developer can provide additional information to resolve potential data integrity issues.
These observations raise the question if both concepts can be unified.
Migration Logs
Let's call the additional information a developer provides for a given service deployment the migration log.
Hypothesis: By providing an appropriate migration log, a developer can ensure P1 and P2 for a service deployment.

Open Questions

Are there more 'desirable properties' of a service deployment?
How do other scenarios than S1 and S2 relate to P1 and P2?
What are the challenges for multi-stage deployment? The above text focuses on a single migration, but does not take parallel changes to the 'parent' branch into account (typically solved by rebasing in git).
How exactly is the migration log provided, and where is it stored, Client/Server?

I think one of the important aspects of versioning is that it doesn't apply only to the source (the definition), but also to the result (the deployed service). The concept of versioning is also applied to the service schema (in ancient terms, the WSDL).
A client sending a message to an endpoint includes a version property in that message (with XML messages, that version is part of the namespace). Whenever a new version of the schema is deployed, the old version also stays operational, especially if the new schema contains breaking changes. The server would contain the logic, deployed together with a new version of the schema, to translate (map) the old message version into the new.
Introducing a breaking change is a multi-step approach, allowing the clients time to upgrade to the newest version of the schema, before it is removed. With 'slow moving clients', this might mean supporting 3 or 4 versions at the same time (unfortunately).
S1 - Renaming a field

Add the new field to the schema
Map the old field from incoming messages (v1) to the new field (v2) before processing the message
Migrate all clients to the new message version (v2)
Disable the old schema version (v1)

S2 - Making an optional field required

Make the field required in the new service schema (v2)
Migrate all clients to the new message version (v2)
Disable the old schema version (v1)
Make the field required in the underlying storage

I won't go over all described scenario's, but even from the first two you can make the following observations:

There is a need for exposing multiple versions of the endpoint
There is a need for applying logic somewhere to translate to the latest version (this applies to both queries and mutations)
Changes to the schema, and to the underlying data source, are not always simultaneous

All three requirements are currently not supported.

Update to the above, not everyone seems to agree: http://graphql.org/learn/best-practices/#versioning. Preventing breaking changes is an interesting idea, but I seriously wonder how that would work. It hasn't worked for the past 20 years of API versioning, and I'm very interested in what we can come up with to circumvent this.

Thanks!

authors: kbrandwijk marktani sorenbs

repo: graphcool/graphcool


text:
Improve edge-based CH import performance

This PR improves the node contraction algorithm and parameters for edge-based CH and fixes #2375.
For the car/fastest profile with u_turn_costs=80 and using a recent OSM extract for Europe it reduced the CH preparation time by around 40% from 7.5h to 4.5h in my test. It slightly reduced the number of shortcuts as well (from 222mio to 209mio). The average query time for random queries in Bavaria was slightly slower (2.6ms vs 2.4ms). With this PR the preparation also takes slightly less memory, because I got rid of one integer array of size 2*edges (for Europe this saves around 2*95mio*4bytes = 760MB).
However, the most important improvement here is that edge-based CH now works better for large u-turn costs and large edge weights as they occur when we enable e.g. the GermanyCountryRule (this rule sets access=destination for tracks). For example in my test with master it took 221s to complete a car/fastest edge-based CH import for bayern-190101.osm.pbf with u_turn_costs=0, 720s for u_turn_costs=80 and 1280s with u_turn_costs=200. With the improvements in this PR this is reduced to 181s (-19%), 440s (-39%) and 516s (-60%), so the import is faster especially for large u-turn costs.
Including country rules the speed up is even better: For example for germany-190101.osm.pbf the car/fastest/u_turn_costs=40  import took 2733s without country rules in master and 10776s with country rules (almost four times slower). With this PR the import times stays around the same when enabling country rules! This means that including country rules this PR can yield a 10x speedup.
The most important changes leading to these improvements were:

Do a mini search to first find the bridge paths before running the extra witness searches. This way we can make use of an explicit weight limit for each witness search
Limit witness searches as much as possible (similar to #2390)
Use a dynamic limit for the number of polled edges based on an approximated mean degree of the graph as @karussell (:+1:) did for node-based CH. Previously I was setting such a limit based on the settled nodes of previous searches. While this works quite well normally it leads to too long witness searches when there are too many long ones (as it happens for large u-turn costs or large weight edges).
Use different limits for the number of polled edges during heuristic searches and actual node contraction
Use neighbor updates instead of just lazy updates, but limit number of neighbor updates per node (similar to what we do for node-based now: https://github.com/graphhopper/graphhopper/pull/2514)
Some heuristic parameter tuning

Related: #1565

:rocket:

source: gharchive/pull-request

authors: easbar karussell

repo: graphhopper/graphhopper

license_type: permissive

license_source: bigquery


text:
Document week / w suffix

As mentioned in graphite-project/whisper#239 the code supports "week"
as a unit of time, so document it

Codecov Report

Merging #2107 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #2107   +/-   ##
=======================================
  Coverage   78.88%   78.88%
=======================================
  Files          78       78
  Lines        7626     7626
  Branches     1515     1515
=======================================
  Hits         6016     6016
  Misses       1383     1383
  Partials      227      227

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 15f16a3...5231d27. Read the comment docs.

repo: graphite-project/graphite-web


text:
[Bug] Docker image for v0.35.0 does not build

Bug report
The docker image for v0.35.0 does not build on x86 and arm 64.
I've checked out commit 6309d5698ee4c4b4e6297fd463a7c84189b4abb6 which for some reason is not the same commit as the tag (it seems the actual commit which was tagged is not part of this repo)

However, commit 6309d5698ee4c4b4e6297fd463a7c84189b4abb6 does have the same commit message as the commit which was tagged with v0.35.0. When I try to build the docker image on commit 6309d5698ee4c4b4e6297fd463a7c84189b4abb6 with
 ❮❮❮ docker build --target graph-node \
            --build-arg "COMMIT_SHA=$(gitrev-parse --short HEAD)" \
            --build-arg "REPO_NAME=myrepo" \
            --build-arg "BRANCH_NAME=mybranch" \
            --build-arg "TAG_NAME=mytag" \
            -t myrepo/graph-node:mytag \
            -f docker/Dockerfile --target graph-node-build --progress plain .

I get an error as shown below.
Relevant log output
#17 597.2 error: could not compile `graph-node` (bin "graph-node")
#17 597.2
#17 597.2 Caused by:
#17 597.2   process didn't exit successfully: `/usr/local/rustup/toolchains/stable-aarch64-unknown-linux-gnu/bin/rustc --crate-name graph_node --edition=2021 node/src/main.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type bin --emit=dep-info,link -C opt-level=s -C lto -C metadata=41446f50e36f9cf9 -C extra-filename=-41446f50e36f9cf9 --out-dir /graph-node/target/release/deps -C strip=debuginfo -L dependency=/graph-node/target/release/deps --extern clap=/graph-node/target/release/deps/libclap-3c163f0742181ead.rlib --extern diesel=/graph-node/target/release/deps/libdiesel-c74324a9a3ba2561.rlib --extern env_logger=/graph-node/target/release/deps/libenv_logger-5d504492ceb6fff6.rlib --extern futures=/graph-node/target/release/deps/libfutures-023cd922e9400e1b.rlib --extern git_testament=/graph-node/target/release/deps/libgit_testament-e6d335343b08995d.rlib --extern graph=/graph-node/target/release/deps/libgraph-59ead945f69aa479.rlib --extern graph_chain_arweave=/graph-node/target/release/deps/libgraph_chain_arweave-bb2043ac85269bf1.rlib --extern graph_chain_cosmos=/graph-node/target/release/deps/libgraph_chain_cosmos-bcf0619234c6b68f.rlib --extern graph_chain_ethereum=/graph-node/target/release/deps/libgraph_chain_ethereum-892cd95fb13e9206.rlib --extern graph_chain_near=/graph-node/target/release/deps/libgraph_chain_near-a664125e54dd30f0.rlib --extern graph_chain_starknet=/graph-node/target/release/deps/libgraph_chain_starknet-1ade7633a6eca2d3.rlib --extern graph_chain_substreams=/graph-node/target/release/deps/libgraph_chain_substreams-f0ba8abe139d911b.rlib --extern graph_core=/graph-node/target/release/deps/libgraph_core-743f3c54d3fff7b8.rlib --extern graph_graphql=/graph-node/target/release/deps/libgraph_graphql-9103a6ca5addc308.rlib --extern graph_node=/graph-node/target/release/deps/libgraph_node-447f3a4a16cf6650.rlib --extern graph_server_http=/graph-node/target/release/deps/libgraph_server_http-3b523a2c6f764bbb.rlib --extern graph_server_index_node=/graph-node/target/release/deps/libgraph_server_index_node-e11802cbb694e2d5.rlib --extern graph_server_json_rpc=/graph-node/target/release/deps/libgraph_server_json_rpc-5928fd96166f054d.rlib --extern graph_server_metrics=/graph-node/target/release/deps/libgraph_server_metrics-8bca33e7ce9704eb.rlib --extern graph_server_websocket=/graph-node/target/release/deps/libgraph_server_websocket-6a0172672f328ade.rlib --extern graph_store_postgres=/graph-node/target/release/deps/libgraph_store_postgres-bbf87f4fe36f4651.rlib --extern json_structural_diff=/graph-node/target/release/deps/libjson_structural_diff-5cdcbc2012bcca44.rlib --extern lazy_static=/graph-node/target/release/deps/liblazy_static-93e74b27b1b19db6.rlib --extern prometheus=/graph-node/target/release/deps/libprometheus-d762906aa6e5212d.rlib --extern serde=/graph-node/target/release/deps/libserde-b046575745bc85c8.rlib --extern shellexpand=/graph-node/target/release/deps/libshellexpand-a52a5363011b8f0d.rlib --extern termcolor=/graph-node/target/release/deps/libtermcolor-5e3b6102964731b9.rlib --extern url=/graph-node/target/release/deps/liburl-9580f08525e91ad8.rlib -g -L native=/usr/lib/aarch64-linux-gnu -L native=/graph-node/target/release/build/ring-c626a2f013cb8f3e/out -L native=/graph-node/target/release/build/ring-20453f704f2406b5/out -L native=/graph-node/target/release/build/secp256k1-sys-093877d12e9b823a/out -L native=/graph-node/target/release/build/zstd-sys-9d32a5ac38a2e59f/out -L native=/graph-node/target/release/build/wasmtime-runtime-06cbcb3b73762675/out -L native=/graph-node/target/release/build/blake3-c26fc97f3b613600/out` (signal: 9, SIGKILL: kill)
#17 597.2 warning: build failed, waiting for other jobs to finish...
^CERROR: failed to solve: Canceled: context canceled

IPFS hash
No response
Subgraph name or link to explorer
No response
Some information to help us out

[X] Tick this box if this bug is caused by a regression found in the latest release.
[ ] Tick this box if this bug is specific to the hosted service.
[X] I have searched the issue tracker to make sure this issue is not a duplicate.

OS information
Linux

I get the same error when using the build.sh script

nvm, turns out it was a memory issue. I guess the newer images require more memory to build.

source: gharchive/issue

repo: graphprotocol/graph-node

license_source: github-api


text:
IntelliJIDEA dont start proyect if includ dependency graphql-java-tools

I am creating a spring boot 2.0.4.RELEASE project and when I add the dependency graphql-java-tools the IDE can not execute the project nor in debug mode.
For what is this?
it is my pom
`

4.0.0
<groupId>com.cccccc.ops</groupId>
<artifactId>apigqlwff</artifactId>
<version>1.0.0-SNAPSHOT</version>
<packaging>jar</packaging>
<name>xxxxxx</name>
<description>yyyyyyy</description>

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.0.4.RELEASE</version>
    <relativePath/> <!-- lookup parent from repository -->
</parent>

<properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
    <java.version>1.8</java.version>
</properties>

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>

    <!--Cloud-->
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-netflix-core</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-openfeign</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-config</artifactId>
        <exclusions>
            <exclusion>
                <groupId>org.bouncycastle</groupId>
                <artifactId>bcpkix-jdk15on</artifactId>
            </exclusion>
        </exclusions>
    </dependency>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-zipkin</artifactId>
    </dependency>

    <!--BD Oracle-->
    <dependency>
        <groupId>com.oracle</groupId>
        <artifactId>ojdbc6</artifactId>
        <version>11.2.0.3</version>
    </dependency>

    <!--Actuator-->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-actuator</artifactId>
    </dependency>

    <dependency>
        <groupId>com.graphql-java</groupId>
        <artifactId>graphql-java-tools</artifactId>
        <version>5.1.0</version>
    </dependency>

    <!--Starter Test-->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-test</artifactId>
        <scope>test</scope>
    </dependency>
</dependencies>
<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-dependencies</artifactId>
            <version>${spring-cloud.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>
<build>
    <finalName>xxxxx</finalName>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
        </plugin>
    </plugins>
</build>

`

Try adding the spring graphql starter as well
            <groupId>com.graphql-java</groupId>
            <artifactId>graphql-spring-boot-starter</artifactId>
            <version>4.2.0</version>
        </dependency>```

I updated my IntelliJ IDE and managed to run my project without problems, apparently it is an bug of the IDE.

authors: CH-EricLundberg Dluquem

repo: graphql-java/graphql-java-tools

license: mit


text:
Associate GraphQL ListType with any Iterable in Java

GraphQL list type representation is too limited to be mapped only to java.unit.List. Instead we should be able to represent probably any java Iterable type. As a result I'm getting the error for models with Iterables types other than List:
class User {
  addresses: Set<Address>
}

type User {
  addresses: [Address]
}

Exception in thread "main" com.coxautodev.graphql.tools.SchemaClassScannerError:
Unable to match type definition (ListType{type=TypeName{name='Address'}}) with java type (java.util.Set<Address>):
Java class is not a List: java.util.Set<Address>

Thanks!

authors: apottere jdorleans


text:
Abstract (start, end) from Spanning struct into new struct Span

This makes it easier to treat the source region (the Span) separately from the spanned item in Spanning.

The checkbox isn't visible for me. Could it be because the fork is owned by an organization in which I'm not an administrator? :thinking:
Perhaps it's better if I re-create the PR from my personal fork.

New PR up at https://github.com/graphql-rust/juniper/pull/1208 (from a my personal fork). Sorry for the noise :crying_cat_face:
The "Allow edits" github bug is discussed here: https://github.com/orgs/community/discussions/5634

@audunhalland thanks!

authors: audunhalland tyranron

repo: graphql-rust/juniper


text:
Hello World example/'vscode-graphql.contentProvider' failed

I'm probably doing something very basic wrong, as I'm just learning GraphQL.
In VS Code, I created a .gql file with the following contents:
POST https://api.github.com/graphql
Authorization: bearer ghp_my0token0here

query($owner:String!, $name:String!) {
  repository(owner: $owner, name: $name) {
    url, stargazerCount
  }
}

Then I run "Execute GraphQL Operations" via the Command Palette and receive the following error:

Running the contributed command: 'vscode-graphql.contentProvider' failed.

As said above, I'm probably doing something very basic wrong, but IMO this error message is not descriptive at all. Maybe you could give me a short hint what I am expected to do instead in order to test out my query from VS Code? :-)

If you cannot reproduce the issue, I would be willing to provide further information, but as mentioned by @hinogi, the command is no longer available and the suggested alternative works for notebooks only. It might be great to get this functionality back in any way. Please ping me if I can do anything else, and thanks for the feedback!

@linqlover we will eventually bring this functionality back via joyce's extension and/or another extension, once there are resources to support it.
For now, we need to focus on some significant changes and longstanding issues in the language server and thus the extension reference implementation. I and @orta debated it for a while but he is right, this is the most realistic path for us for now until we have more interested contributors to help.

authors: LinqLover acao

repo: graphql/graphiql

license: MIT


text:
add StorageContext and HistoryContext to @graphiql/react

This PR continues to break up the huuuuge state of the GraphiQL component by adding two new contexts to @graphiql/react:

The StorageContext exposes a StorageAPI instance. We assume that this context might be missing, i.e. a custom implementation using the components from @graphiql/react could choose to not store anything locally.
The HistoryContext manages a HistoryStore instance and exposes methods to change its items as well as state for toggling the history sidebar.

The latest changes of this PR are not available as canary, since there are no linked changesets for this PR.

@harshithpabbati this coincides with your work on the new 2.0 storage API!

@thomasheyenbrock it may not be the time to do it, but at some point we need to make StorageAPI instance allow async methods so people can use network or indexdb storage (localforage, idb, etc)

@acao thanks for making the link here! We can certainly follow up here, let's keep this PR scoped to refactoring the existing code and change functionality in a follow-up 🙂

@thomasheyenbrock indeed, which is why I said "at some point", just keeping you aware of the plans!
here is some very similar prior art from our google summer of code intern as well:
https://github.com/graphql/graphiql/pull/1558/files
linked issue #1324

The latest changes of this PR are not available as canary, since there are no linked changesets for this PR.

authors: acao thomasheyenbrock


text:
Allow to specify result tooltip as prop (was: Implement hover trace display)

Fixes #569
If you specify environment variable TRACING=true yarn dev it adds tracing information to dev server. ResultViewer component removes tracing info from response and shows it as tooltip when you hover part of response.
For this to work patch to codemirror-graphql is needed, I will submit PR there in just a moment.
Screenshot:

Thanks @jskorepa. I really love this feature, and I think it's a great example of the kind of powerful things that can be built on top of GraphiQL.
However, I am pretty reluctant to increase the dependency footprint of GraphiQL and I'd love to figure out a way to make this functionality possible as an addition outside of GraphQL. This would likely making some changes to GraphiQL to make this kind of extension possible, but not actually baking the extension into GraphiQL itself. I haven't thought deeply about what that might look like, but I'd be interested to hear any ideas that you might have for how it could be done.
cc: @asiandrummer, who I know has a strong interest in keeping GraphiQL small.

@wincent I see two options for enabling this functionality without including it in GrapiQL itself.

Allow to override ResultViewer with custom one.
Add prop renderReultsTooltip which accepts function to render tooltip. This would allow extensions to add different types of tooltips.

Another thing this PR does is that it removes tracing data from view but this can be implemented inside alternative fetcher function.
I am open to implementing any of above.

I implemented option 2 (and moved original code here)
This will allow to implement hover trace tooltip (or any tooltip in results view).
See example branch for example usage.

Sorry for the hassle @jskorepa, but I just remembered that a similar feature exists in codemirror-graphql. I'll accept & merge this PR here, but we should move this to codemirror-graphql repo to consolidate the codemirror helpers in one place.
I'm planning to do some cleanup work/release on codemirror-graphql soon, so maybe I can move it out. Let me know if you get to it earlier than I do please. Thanks for your contribution!

authors: asiandrummer jskorepa wincent


text:
run Gratipay 163

162

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/24446895-run-gratipay-163?utm_campaign=plugin&utm_content=tracker%2F85909&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F85909&utm_medium=issues&utm_source=github).

Alright, review topped up. Still nothing showing up in the user review queue. Suspect it's almost certainly broken.

[gratipay] $ heroku config -s | run_dammit /dev/stdin -c ./env/bin/python ./bin/migrate-tips.py
'introtopython' already migrated.
'duo' already migrated.
'sudo-room' already migrated.
'nuvola-player' already migrated.
'cyberpipe' already migrated.
'mojolicious' already migrated.
'pageres' already migrated.
'Gratipay' already migrated.
'citizens-cooperative' already migrated.
'catapultpgh' already migrated.
'sudomesh' already migrated.
'perl-maven' already migrated.
'exercism' already migrated.
'devdocs' already migrated.
'weblate' already migrated.
'sublimelinter' already migrated.
'pillow' already migrated.
'simplytest-me' already migrated.
'json-resume' already migrated.
'encommuns' already migrated.
'perlweekly' already migrated.
'cuberite' already migrated.
'totalism-hackbase' already migrated.
'bevry' already migrated.
'cpan-io' already migrated.
Migrated tips for 'shields'
Migrated tips for 'kivy'
'gammu' already migrated.
Migrated tips for 'knopproject'
'the-charis-project' already migrated.
'northern-plains-athletics' already migrated.
Migrated tips for 'libravatar'
'debian-lts-by-freexian' already migrated.
'doit' already migrated.
'the-mountain-spirit' already migrated.
'jshttp' already migrated.
'aegirproject' already migrated.
'image-optim' already migrated.
'survivejs' already migrated.
'nanoc' already migrated.
'sailor' already migrated.
'cider' already migrated.
'wdrl' already migrated.
Migrated tips for 'detexify'
'cpan-book' already migrated.
'ucoin' already migrated.
'act' already migrated.
'esdiscuss' already migrated.
'rhombus-tech' already migrated.
Migrated tips for 'kriasoft'
'jsbin' already migrated.
Migrated tips for 'piloting-postdevelopment'
Migrated tips for 'rtail'
Migrated tips for 'tech-store-club'
Done.

Backup taken and verified. Script started. Script ran for two minutes (0:02:37.022017).

Hit https://github.com/gratipay/gratipay.com/issues/3501.

=> update exchange_routes set fee_cap=20 where fee_cap is null and network='paypal';
UPDATE 32

POSTed MassPay back to Gratipay for 37 users.

Escrow shuffled.

Logs uploaded in https://github.com/gratipay/logs/commit/ff2889796c0f0e1d70c9cabb4c4db3c52ee0089b.

Escrow shuffled.

Decline rate is 4.5% (4/89).

Script started.


text:
GameTimerTask should not be outside ProgressBarComponent

...because GameTimerTask doesn't make sense if it's not a part of Progress bar.

Fixed in 11655e9294d56d9c9f6a7c0e81a7ef911c9d5821

repo: gravetii/wordagam


text:
chore(ci/cd): Deploy AM EE on nightly environment

fixes gravitee-io/issues#7626

Note: If this is merged we may want to have this for RiskAssessment and include the plugin.

Indeed, we will have to update the config during the RiskAssessment integration

repo: gravitee-io/gravitee-access-management


text:
Add Menu components

Issue
APIM-103
APIM-101

Gravitee.io Automatic Deployment
A prerelease version of this package has been published! 🚀
To use it in your project run the following lines:
npm install @gravitee/ui-particles-angular@3.13.0-menu-89b6911
# or
yarn add @gravitee/ui-particles-angular@3.13.0-menu-89b6911

Gravitee.io Automatic Deployment
A prerelease version of this package has been published! 🚀
To use it in your project run the following lines:
npm install @gravitee/ui-policy-studio-angular@3.13.0-menu-89b6911
# or
yarn add @gravitee/ui-policy-studio-angular@3.13.0-menu-89b6911

Gravitee.io Automatic Deployment
A prerelease version of this package has been published! 🚀
To use it in your project run the following lines:
npm install @gravitee/ui-particles-angular@3.13.0-menu-547ce26
# or
yarn add @gravitee/ui-particles-angular@3.13.0-menu-547ce26

Gravitee.io Automatic Deployment
A prerelease version of this package has been published! 🚀
To use it in your project run the following lines:
npm install @gravitee/ui-policy-studio-angular@3.13.0-menu-27e58f1
# or
yarn add @gravitee/ui-policy-studio-angular@3.13.0-menu-27e58f1

Gravitee.io Automatic Deployment
A prerelease version of this package has been published! 🚀
To use it in your project run the following lines:
npm install @gravitee/ui-particles-angular@3.13.0-menu-27e58f1
# or
yarn add @gravitee/ui-particles-angular@3.13.0-menu-27e58f1

Gravitee.io Automatic Deployment
A prerelease version of this package has been published! 🚀
To use it in your project run the following lines:
npm install @gravitee/ui-policy-studio-angular@3.13.0-menu-44592ff
# or
yarn add @gravitee/ui-policy-studio-angular@3.13.0-menu-44592ff

Gravitee.io Automatic Deployment
A prerelease version of this package has been published! 🚀
To use it in your project run the following lines:
npm install @gravitee/ui-particles-angular@3.13.0-menu-44592ff
# or
yarn add @gravitee/ui-particles-angular@3.13.0-menu-44592ff

Gravitee.io Automatic Deployment
A prerelease version of this package has been published! 🚀
To use it in your project run the following lines:
npm install @gravitee/ui-policy-studio-angular@3.13.0-menu-36f93ae
# or
yarn add @gravitee/ui-policy-studio-angular@3.13.0-menu-36f93ae

Gravitee.io Automatic Deployment
A prerelease version of this package has been published! 🚀
To use it in your project run the following lines:
npm install @gravitee/ui-particles-angular@3.13.0-menu-e686b32
# or
yarn add @gravitee/ui-particles-angular@3.13.0-menu-e686b32

Gravitee.io Automatic Deployment
A prerelease version of this package has been published! 🚀
To use it in your project run the following lines:
npm install @gravitee/ui-particles-angular@3.14.1-menu-3fb3880
# or
yarn add @gravitee/ui-particles-angular@3.14.1-menu-3fb3880

Gravitee.io Automatic Deployment
A prerelease version of this package has been published! 🚀
To use it in your project run the following lines:
npm install @gravitee/ui-policy-studio-angular@3.14.1-menu-3fb3880
# or
yarn add @gravitee/ui-policy-studio-angular@3.14.1-menu-3fb3880

Gravitee.io Automatic Deployment
A prerelease version of this package has been published! 🚀
To use it in your project run the following lines:
npm install @gravitee/ui-particles-angular@3.14.1-menu-c607785
# or
yarn add @gravitee/ui-particles-angular@3.14.1-menu-c607785

Gravitee.io Automatic Deployment
A prerelease version of this package has been published! 🚀
To use it in your project run the following lines:
npm install @gravitee/ui-policy-studio-angular@3.14.1-menu-c607785
# or
yarn add @gravitee/ui-policy-studio-angular@3.14.1-menu-c607785

Gravitee.io Automatic Deployment
A prerelease version of this package has been published! 🚀
To use it in your project run the following lines:
npm install @gravitee/ui-particles-angular@3.14.1-menu-1259967
# or
yarn add @gravitee/ui-particles-angular@3.14.1-menu-1259967

Gravitee.io Automatic Deployment
A prerelease version of this package has been published! 🚀
To use it in your project run the following lines:
npm install @gravitee/ui-policy-studio-angular@3.14.1-menu-a2d6866
# or
yarn add @gravitee/ui-policy-studio-angular@3.14.1-menu-a2d6866

Gravitee.io Automatic Deployment
A prerelease version of this package has been published! 🚀
To use it in your project run the following lines:
npm install @gravitee/ui-particles-angular@3.14.1-menu-a2d6866
# or
yarn add @gravitee/ui-particles-angular@3.14.1-menu-a2d6866

Gravitee.io Automatic Deployment
A prerelease version of this package has been published! 🚀
To use it in your project run the following lines:
npm install @gravitee/ui-policy-studio-angular@3.14.2-menu-d0475cf
# or
yarn add @gravitee/ui-policy-studio-angular@3.14.2-menu-d0475cf

Gravitee.io Automatic Deployment
A prerelease version of this package has been published! 🚀
To use it in your project run the following lines:
npm install @gravitee/ui-particles-angular@3.14.2-menu-d0475cf
# or
yarn add @gravitee/ui-particles-angular@3.14.2-menu-d0475cf

Gravitee.io Automatic Deployment
A prerelease version of this package has been published! 🚀
To use it in your project run the following lines:
npm install @gravitee/ui-particles-angular@4.0.0-menu-2375d7d
# or
yarn add @gravitee/ui-particles-angular@4.0.0-menu-2375d7d

Gravitee.io Automatic Deployment
A prerelease version of this package has been published! 🚀
To use it in your project run the following lines:
npm install @gravitee/ui-policy-studio-angular@4.0.0-menu-2375d7d
# or
yarn add @gravitee/ui-policy-studio-angular@4.0.0-menu-2375d7d

Gravitee.io Automatic Deployment
A prerelease version of this package has been published! 🚀
To use it in your project run the following lines:
npm install @gravitee/ui-particles-angular@4.0.0-menu-52deb96
# or
yarn add @gravitee/ui-particles-angular@4.0.0-menu-52deb96

Gravitee.io Automatic Deployment
A prerelease version of this package has been published! 🚀
To use it in your project run the following lines:
npm install @gravitee/ui-policy-studio-angular@4.0.0-menu-52deb96
# or
yarn add @gravitee/ui-policy-studio-angular@4.0.0-menu-52deb96

Gravitee.io Automatic Deployment
A prerelease version of this package has been published! 🚀
To use it in your project run the following lines:
npm install @gravitee/ui-particles-angular@4.0.0-menu-ec63d97
# or
yarn add @gravitee/ui-particles-angular@4.0.0-menu-ec63d97

Gravitee.io Automatic Deployment
A prerelease version of this package has been published! 🚀
To use it in your project run the following lines:
npm install @gravitee/ui-policy-studio-angular@4.0.0-menu-ec63d97
# or
yarn add @gravitee/ui-policy-studio-angular@4.0.0-menu-ec63d97

Gravitee.io Automatic Deployment
A prerelease version of this package has been published! 🚀
To use it in your project run the following lines:
npm install @gravitee/ui-policy-studio-angular@4.0.0-menu-1683e2d
# or
yarn add @gravitee/ui-policy-studio-angular@4.0.0-menu-1683e2d

Gravitee.io Automatic Deployment
A prerelease version of this package has been published! 🚀
To use it in your project run the following lines:
npm install @gravitee/ui-particles-angular@4.0.0-menu-1683e2d
# or
yarn add @gravitee/ui-particles-angular@4.0.0-menu-1683e2d

Gravitee.io Automatic Deployment
A prerelease version of this package has been published! 🚀
To use it in your project run the following lines:
npm install @gravitee/ui-particles-angular@4.0.0-menu-f041e6d
# or
yarn add @gravitee/ui-particles-angular@4.0.0-menu-f041e6d

Gravitee.io Automatic Deployment
A prerelease version of this package has been published! 🚀
To use it in your project run the following lines:
npm install @gravitee/ui-policy-studio-angular@4.0.0-menu-f041e6d
# or
yarn add @gravitee/ui-policy-studio-angular@4.0.0-menu-f041e6d

Gravitee.io Automatic Deployment
A prerelease version of this package has been published! 🚀
To use it in your project run the following lines:
npm install @gravitee/ui-particles-angular@4.0.0-menu-0dad277
# or
yarn add @gravitee/ui-particles-angular@4.0.0-menu-0dad277

Gravitee.io Automatic Deployment
A prerelease version of this package has been published! 🚀
To use it in your project run the following lines:
npm install @gravitee/ui-policy-studio-angular@4.0.0-menu-0dad277
# or
yarn add @gravitee/ui-policy-studio-angular@4.0.0-menu-0dad277

Gravitee.io Automatic Deployment
A prerelease version of this package has been published! 🚀
To use it in your project run the following lines:
npm install @gravitee/ui-particles-angular@4.0.0-menu-b0b1acd
# or
yarn add @gravitee/ui-particles-angular@4.0.0-menu-b0b1acd

Gravitee.io Automatic Deployment
A prerelease version of this package has been published! 🚀
To use it in your project run the following lines:
npm install @gravitee/ui-policy-studio-angular@4.0.0-menu-b0b1acd
# or
yarn add @gravitee/ui-policy-studio-angular@4.0.0-menu-b0b1acd

Gravitee.io Automatic Deployment
A prerelease version of this package has been published! 🚀
To use it in your project run the following lines:
npm install @gravitee/ui-policy-studio-angular@4.0.0-menu-960ed82
# or
yarn add @gravitee/ui-policy-studio-angular@4.0.0-menu-960ed82

Gravitee.io Automatic Deployment
A prerelease version of this package has been published! 🚀
To use it in your project run the following lines:
npm install @gravitee/ui-particles-angular@4.1.0-menu-a0c540e
# or
yarn add @gravitee/ui-particles-angular@4.1.0-menu-a0c540e

Gravitee.io Automatic Deployment
A prerelease version of this package has been published! 🚀
To use it in your project run the following lines:
npm install @gravitee/ui-policy-studio-angular@4.1.0-menu-a0c540e
# or
yarn add @gravitee/ui-policy-studio-angular@4.1.0-menu-a0c540e

Gravitee.io Automatic Deployment
A prerelease version of this package has been published! 🚀
To use it in your project run the following lines:
npm install @gravitee/ui-particles-angular@4.1.0-menu-3f4eb97
# or
yarn add @gravitee/ui-particles-angular@4.1.0-menu-3f4eb97

Gravitee.io Automatic Deployment
A prerelease version of this package has been published! 🚀
To use it in your project run the following lines:
npm install @gravitee/ui-policy-studio-angular@4.1.0-menu-3f4eb97
# or
yarn add @gravitee/ui-policy-studio-angular@4.1.0-menu-3f4eb97

:tada: This PR is included in version 4.2.0 :tada:
The release is available on:

npm package (@latest dist-tag)
npm package (@latest dist-tag)
npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

authors: gcusnieux graviteeio

repo: gravitee-io/gravitee-ui-particles


text:
Support: Configure Greenkeeper to create PRs against dev branch instead of master

Ughh sorry you probably have heard this question before, but how can I configure Greenkeeper to create PRs against dev branch instead of master?
thanks!

bump pls thx

Greenkeeper makes it's pull request against the default branch of your repository. You can set it (in the repository settings) to your dev branch.

Thanks, since there may be other factors that keep someone's default branch to be master, might there not be a way to configure greenkeeper to make PRs against a non-default branch? :)

One way to do this, I imagine, would be to have users place a .greenkeeper config file in each project where they did not want default settings, etc.

It's really frustrating, is there any plan for this?

authors: ORESoftware Realtin thebrodmann

repo: greenkeeperio/greenkeeper


text:
Fail to load resource

Hi Alix,
Thanks a lot for the awesome project and amazing video!
After installing the zoteroRoam, the book icon of mine is always red, so I checked the browser console. It shows these details.

The "Data Syncing" of mine is the same as yours in the demo, while the "File Syncing" is through WebDAV, I am not sure if this is the cause.
Could you please give me some suggestions? Thanks again!
Best,
Xiaojun

Hi there!
There's an issue with your data URI : you need to use your Zotero user ID (a 6-digit or 7-digit identifier) and not your username.

It works when using the user ID, Thanks a lot 😀
Cheers,
Xiaojun

repo: greenmeen/zotero-roam


text:
Failure to scale - TypeError: 'Zero' object is not iterable

Cross-posted from Stack Overflow.
Thanks for the library - it looks like exactly what we need for working with geometry in eppy.
However I've just come up against a TypeError I've not seen before and can't figure out why it's occurring. Googling for the error TypeError: 'Zero' object is not iterable returns no results. I've tested in python 2.7 and 3.5 and the error is the same in both cases.
The error comes up when I have a list of vertices which used to be part of a SymPy Polygon object, though as far as I can see the lists are identical and the assert statement in the MCVE passes.
Here's the MCVE:
from sympy.geometry.polygon import Polygon
import pyclipper as pc

start_list = [(0, 2), (2, 2), (2, 0), (0, 0)]
scaled = pc.scale_to_clipper(start_list)  # this works fine

as_poly = Polygon(*start_list)
new_list = [(pt.x, pt.y) for pt in as_poly.vertices]
assert new_list == start_list  # check that the lists are the same

fail_to_scale = pc.scale_to_clipper(new_list)  # this fails

And the traceback:
Traceback (most recent call last):
  File "C:\Users\Jamie\<blah>\mcve.py", line 10, in <module>
    fails = pc.scale_to_clipper(new_list)
  File "pyclipper/pyclipper.pyx", line 544, in pyclipper.scale_to_clipper (pyclipper/pyclipper.cpp:3535)
  File "pyclipper/pyclipper.pyx", line 542, in pyclipper.scale_to_clipper.scale_value (pyclipper/pyclipper.cpp:3454)
  File "pyclipper/pyclipper.pyx", line 542, in pyclipper.scale_to_clipper.scale_value (pyclipper/pyclipper.cpp:3454)
  File "pyclipper/pyclipper.pyx", line 542, in pyclipper.scale_to_clipper.scale_value (pyclipper/pyclipper.cpp:3416)
TypeError: 'Zero' object is not iterable

Any idea what the source of and solution to this error could be?

Ok, I've tracked the problem back to the values stored in Polygon. The issue is that the value 0 is stored by SymPy as a sympy.Zero object. These sympy.Zero values are not accepted by polyclipper.scale_to_clipper() and so are raising the TypeError when checked.
To avoid the issue I can generate new_list casting pt.x and pt.y to float:
 new_list = [(float(pt.x), float(pt.y)) for pt in as_poly.vertices]

I'm not sure whether this is something that should be fixed in sympy or in pyclipper, or if the user should be expected to know that they need to make the conversion.
One option might be to convert anything that evaluates to 0 to int(0) in pyclipper.scale_to_clipper(). That would avoid the problem for this case, and for any other strange representations of 0 that may exist in other libraries.

Hi @jamiebull1 ,
it seems that the problem lies in the "if" that checks whether an item is a list or a number - https://github.com/greginvm/pyclipper/blob/541e9084fb4b0d815d5b864bfcbee36dd2e9c875/pyclipper/pyclipper.pyx#L556. The statement isinstance(x, _numbers.Real) does not catch the sympy.Zero so it continues to treat it as a collection.
This can be fixed in pyclipper we just need to come up with a better way to distinguish a number from a collection. The definition needs to be broad enough so that we can support 3rd party collection and number types. I'm thinking of something along the way of if hasattr(N, "__len__") (http://stackoverflow.com/a/19773559/4500088).
Want to take over? If not I'll handle it.
Thanks,
Gregor

Hi @greginvm,
Thanks for getting back to me. I ran into other problems with SymPy so this issue (for now) isn't a problem for me. Happy to take a look and see if I can make the fix you've suggested though.
Keep your eyes out for a pull request.
And thanks again for the library, it's really helping out!

I merged your PR (https://github.com/greginvm/pyclipper/pull/6) :rocket: . I'll put you to the authors list, is that OK with you?

Sure, no problem. I'll keep an eye out for anything else that crops up while I'm working with this.

I released it, it should be available if you update your pip package pip install -U pyclipper

repo: greginvm/pyclipper


text:
SD_CARD_ERROR_CMD58 = 0x12 , but arduino's SD.h working

Hi-Rali 8 GB microSDHC class 10
formatted with SD card formatter 5 to  fat32 or Windows to exFat
testing CardInfo.ino or other examples
SD_SCK_MHZ(4) also 16, 8 , 2 , no luck
===== got random of this 2 errors:
SD errorCode: SD_CARD_ERROR_CMD58 = 0x12
SD errorCode: SD_CARD_ERROR_ACMD41 = 0x17
with
SD errorData = 0xf
SD errorData = 0x1
itc
=====
arduino's SD.h working with SPI_FULL_SPEED, SPI_HALF_SPEED, maybe other

I have no Idea.  I suspect the card since CMD58 simply reads the OCR register.  The card may have poor SPI support.
I can't help more since I don't have the card here.

I have no Idea.  I suspect the card since CMD58 simply reads the OCR register.  The card may have poor SPI support.
I can't help more since I don't have the card here.

Probably was voltage issue - card reader module's LDO was 3.6v. After connect to 3v3 it works good. (but I also changed cluster size to 4kb)

Probably was voltage issue - card reader module's LDO was 3.6v. After connect to 3v3 it works good. (but I also changed cluster size to 4kb)

but I also changed cluster size to 4kb

You should never format an SD with a non-standard format.  SD cards are designed with caches for FAT entries and data entries and expect structures to be the standard locations and standard sizes.  Flash and RAM buffers are designed for the standard format.  SD cards do not have 512 byte flash pages they only emulate 512 byte sectors in very large pages, much larger than your 4kb clusters.
Quote from SD Association  formatter page:
In general, formatting tools provided with operating systems can format various storage media including SD/SDHC/SDXC Cards, but it may not be optimized for SD/SDHC/SDXC Cards and it may result in lower performance.

but I also changed cluster size to 4kb

You should never format an SD with a non-standard format.  SD cards are designed with caches for FAT entries and data entries and expect structures to be the standard locations and standard sizes.  Flash and RAM buffers are designed for the standard format.  SD cards do not have 512 byte flash pages they only emulate 512 byte sectors in very large pages, much larger than your 4kb clusters.
Quote from SD Association  formatter page:
In general, formatting tools provided with operating systems can format various storage media including SD/SDHC/SDXC Cards, but it may not be optimized for SD/SDHC/SDXC Cards and it may result in lower performance.

repo: greiman/SdFs


text:
too large value (X = 163 million) in field: "Stake Weight X; Searching for coins"

the "Stake Weight X; Searching for coins" (last row: "Client Messages") text shows a probably too large stake weight:

with X being constantly >100 million (e.g. max I have seen so far was 163 million)

my DPOR weight shows normal:

so, not like this bug: #410
perhaps related, though ?

version 3.5.9.8 from master branch with today's commit: 2262b07291aa30c491d77ab6c6ee5a7a46e55a04

(cross post, because it applies)
In ~dev~ ~staging~ master branch, the stake weight is reported in two places on the overview screen.
The "DPOR Weight:" as shown in the screenshot is calculated somewhere in gui code as balance+magnitude and may not reflect real staking weight.
Second is in "Client message:" is calculated in stake miner as sum of weights of all mature UTXOs and reflects the real weight. It is not in COIN units. For version 8 blocks 1 GRC equals to 80 of weight.

For version 7 blocks, 1 GRC equals to 800 of weight in investor mode. For researchers, the weight is boosted, quite complex, by magnitude.

In private chat, we confirmed that the reported weight was right. I think this should be closed, @Erkan-Yilmaz .

authors: Erkan-Yilmaz tomasbrod

repo: gridcoin/Gridcoin-Research


text:
Prismic

Summary
https://prismic.io/ is a great modern Headless CMS and we should make a data source plugin for
Basic example
Here is an example of the Contentful data source:
https://github.com/gridsome/gridsome/tree/master/packages/source-contentful
Here is an example of how Gatsby has built it:
https://github.com/angeloashmore/gatsby-source-prismic
Learn how to contribute to Gridsome here:  https://gridsome.org/docs/contribute
The source plugin should be added to packages/source-prismic

Hello all,
I wanted to do an update on this subject. We released a plugin for Gatsby to handle the preview. Basically, at build time this plugin requests the API with the masteref (the published version of our API)
For the preview, this plugin checks when a preview cookie is in the browser to run the query client side from your React component.
You can see more details here if you're interested.
https://github.com/birkir/gatsby-source-prismic-graphql
Let me know if this was useful.
Renaud

@Duaner I'm a little confused about your comments here. It seems like they're about the Gatsby plugin specifically, right? This GitHub issue is about a feature request for adding an integration to Gridsome (similar to Gatsby but with Vue instead of React).

Still quite confused about this, this repo is for gridsome and not gatsby...

@jwkicklighter Reading back over this, I think I understand what's going on now. I take it that @Duaner works for Prismic, and he's giving advice/reference code on how to implement in Vue based on their experience in Gatsby.

That makes more sense! I may take a crack at working on a Gridsome version, but not having luck getting Prismic data via the GraphQL source plugin as of yet. So we'll see.

Hey, @jwkicklighter @scottsb seems like I brought confusion in this conversation ahah.
Yeah, my goal to show the gridsome team the approach that we took for Gatsby on the same topic.
Happy to jump on a call to help you figure this out.

@Duaner I may take you up on that to figure out what I need to know to get GraphQL working with Prismic and then get a better understanding of the architecture of the Gatsby plugin you linked. Should I send an email to the address you have on your profile?
@tomtev What's the preferred way to make a source plugin contribution? Should it be a PR against this project, or should it just be in a separate project that you can link to from the Gridsome site?

@tomtev What's the preferred way to make a source plugin contribution? Should it be a PR against this project, or should it just be in a separate project that you can link to from the Gridsome site?

Against this project, so it can become an official plugin. Please fork, make a change in a branch in your forked repo, and make a PR from there.

An update on this so far: I've done some experimenting based on gatsby-source-prismic and I'm making progress. For whatever reason, it didn't dawn on me that I was referring to the REST version of the source plugin when there's now the gatsby-source-prismic-graphql version that uses graphql and supports post previews. That was my mistake since I misread the project name in the later comment.
For a first version, I will likely continue working with the ideas in the REST version so that there's at least some Prismic plugin for Gridsome. A future version could use graphql instead and support previews, but even without these I think a basic source plugin would be useful. At the moment there's no drop-in way to get Prismic content into Gridsome, and starting small is usually a good approach.
If anyone following this issue disagrees, please let me know so I don't go down a road that won't be useful to anyone :)

@jwkicklighter Any update on this? :)

@MarcelloTheArcane I believe the Prismic team ended up working on a plugin themselves. Not sure the status on that.

authors: Duaner MarcelloTheArcane jwkicklighter robaxelsen scottsb tomtev

repo: gridsome/gridsome


text:
Out-of-source CMake build for libraries

SFML, libpng

#302 #296

SFML and libpng are not used anymore.
Won't fix.

repo: griefly/griefly


text:
Insert of an extra C if there are cystines in the classI/classII

In the CTEP 029 case, Mariam noticed that the TP53 sequence did not match the one represented in the candidates 51mer.fa.manufacurability. The C's in purple should not be there.

The problem seems to be that when there is a C within the classI or classII, the code appends an extra C. The script does not account for cystines within the classI and classII.
https://github.com/griffithlab/neoag_vaccine_scripts/blob/7de6ef1c074b83af12a146f724e9780f4f322410/scripts/color_peptides51mer.py#L208-L218

Resolved by removing some logic:
https://github.com/griffithlab/neoag_vaccine_scripts/blob/66fc980e2f02f6083038250bbe93a95fc94a8e0c/scripts/color_peptides51mer.py#L195-L224
To look like this:
https://github.com/griffithlab/neoag_vaccine_scripts/blob/1514326d1f42a610212c93c9fb9397b2c9d59635/scripts/color_peptides51mer.py#L204-L228
The logic of how the values of each amino acid is set is a little confusing. A TP53 sequence which looks like this:

Is represented view the AminoAcid class like this:
Nucleotide:  S
Open Tag:  False
Close Tag:  False
Bold:  False
Color:  False
Underline:  False
Large:  False
Nucleotide:  G
Open Tag:  False
Close Tag:  False
Bold:  False
Color:  False
Underline:  False
Large:  False
Nucleotide:  T
Open Tag:  False
Close Tag:  False
Bold:  False
Color:  False
Underline:  False
Large:  False
.
.
.
Nucleotide:  T
Open Tag:  False
Close Tag:  False
Bold:  False
Color:  False
Underline:  False
Large:  False
Nucleotide:  C
Open Tag:  True
Close Tag:  False
Bold:  False
Color:  False
Underline:  False
Large:  True
Nucleotide:  T
Open Tag:  True
Close Tag:  True
Bold:  False
Color:  False
Underline:  False
Large:  False
.
.
.
Nucleotide:  L
Open Tag:  False
Close Tag:  False
Bold:  True
Color:  True
Underline:  False
Large:  False
Nucleotide:  W
Open Tag:  True
Close Tag:  True
Bold:  True
Color:  False
Underline:  False
Large:  False
Nucleotide:  V
Open Tag:  False
Close Tag:  False
Bold:  True
Color:  False
Underline:  False
Large:  False
Nucleotide:  D
Open Tag:  False
Close Tag:  False
Bold:  True
Color:  False
Underline:  False
Large:  False
Nucleotide:  S
Open Tag:  False
Close Tag:  False
Bold:  True
Color:  False
Underline:  False
Large:  False
Nucleotide:  T
Open Tag:  False
Close Tag:  False
Bold:  True
Color:  False
Underline:  False
Large:  False
Nucleotide:  P
Open Tag:  True
Close Tag:  True
Bold:  False
Color:  False
Underline:  False
Large:  False
Nucleotide:  P
Open Tag:  False
Close Tag:  False
Bold:  False
Color:  False
Underline:  False
Large:  False
So the character after the final character that needs to format "holds" the closing tag. Also note that this code will put span tags around characters that need no formatting. This also seems like it might be confusing/incorrect.
See example of what the HTML output would look like:


text:
Cover is driving all the way up or down until end position, if a small position correction is needed

I would like to suggest some modifications I have made to your integration and in more detail to the covers part. The goal of these changes is to prevent the covers from moving all the way up or down when only a small adjustment is needed.
I have adjusted the calculations in cover.py as follows:
Original:
time = min(int(((position - self._attr_current_cover_position) / 100.0) * self._time_opens), 255)
Changed to:
time = max(1, min(int((float(position - self._attr_current_cover_position) * float(self._time_opens) / 100.0)), 255))
and
Original:
time = min(int(((self._attr_current_cover_position - position) / 100.0) * self._time_closes), 255)
Changed to:
time = max(1, min(int((float(self._attr_current_cover_position - position) * float(self._time_closes) / 100.0)), 255))
Additionally, I modified lines 183 and 186 to ensure that the covers will move to the end position when 100 or 0 is set. This helps with calibration if the device is out of sync.
Original:
elif position == 100:
    direction = "up"
    time = self._time_opens + 1
elif position == 0:
    direction = "down"
    time = self._time_closes + 1

Changed to:
elif position == 100:
    direction = "up"
    time = 0  # self._time_opens + 1
elif position == 0:
    direction = "down"
    time = 0  # self._time_closes + 1

It would be great if you could incorporate these changes into your integration.
Thank you very much for your excellent work and great commitment.

Could you please take a look at this? It's important to me. I have to edit it each time I update it. What do you think about these changes?

Hello @JSchmid6,
thanks for your contribution. Unfortunately, I don't have a proper testing environment yet. It's under development ;-). And I'm wondering if your fix would work for everyone.
Would it work in your case to just increase the time_opens and time_closes in the configuration?
if not I would rather prefer a global parameter in the configuration you can choose so that you can adjust it independently to each cover brand.

Hello grimmpp,
You are right, there is a risk that the calibration might not work for every device. I have already considered this, and since it is not critical, we can omit this part of the change. I have created a pull request without that change. A step of 0 is the real issue. It would be great if we could integrate a minimal step of 1, which should work for every device.

I agree with the pull request in general. I'm wondering though why second granularity path was taken. In my previous - less well integrated - own enocean integration I used the 100ms granularity setup. Would you be fine if we switch to that approach? It would allow to more accurately do small corrections

Of course, if 100ms are possible I would be happy. I think I missed that. For me it looked like the smallest number, to  be set is one.

@mkaufmann can you tell us what to adapt? In the meantime I will takeover this change into feature-branch and test it.

I've merged it now into feature-branch. Can you please test it?

In the 3F_7F telegram as documented here for FSB14 https://www.eltako.com/fileadmin/downloads/en/_main_catalogue/Gesamt-Katalog_ChT_gb_highRes.pdf there is a DB0_Bit1 that allows to configure 100ms granularity instead of second granularity.
The caveat is that one has to use both data bytes 2 and 3 for runtimes > 25.5 seconds in that mode.
This is the Python code that I had running in my old script for computing the msb & lsb byte fields
    duration_100ms = int(duration * 10)
    duration_msb = 0 if duration_100ms < 255 else int(duration_100ms / 255)
    duration_lsb = (duration_100ms % 255) if duration_100ms >= 255 else duration_100ms

and this was the code for getting the duration from the response
        duration = (packet.data[1]*256 + packet.data[2]) / 10.0

I hope this makes sense.

Funnily, the command is implemented but the one with seconds is used.
https://github.com/grimmpp/eltako14bus/blob/38ceae7a068c46905c5735974a83f860dd26c95c/eltakobus/eep.py#L1100
But only used for receiving the status not for sending the command.
https://github.com/grimmpp/home-assistant-eltako/blob/45418fd98c38feedb0ac9dd6df64d4654b9b5690/custom_components/eltako/cover.py#L197
Maybe you can try to replace the line with: msg = G5_3F_7F(None, time, command).encode_message(address)

The full close on short time frames is fixed, can confirm. The cover change I'll still test

I've merged it now into feature-branch. Can you please test it?

I tried to use the feature branch, but I got some problems with tilt position. Is that something new? How could I test this branch? What do I have to do? Thanks for your support

Yes, there are changes in it. You can see them here.
What problems did you discover?

authors: JSchmid6 grimmpp mkaufmann

repo: grimmpp/home-assistant-eltako


text:
Responsive design

Hello,
Is it possible to make the design responsive?
https://imgur.com/a/jV5htWM
Thanks.

I thought about this recently, but I don't have much free time.

Then the best scenario will be overriding style.

Any plan to reimplement this? i feel this could be quite essential as most of app on phone will be distorted..

authors: AlicanBalik grishkovelli herbzhao

repo: grishkovelli/vue-audio-recorder


text:
Fix remote addr option, use double dash

Ticket(s): https://app.shortcut.com/greenspace/story/50250/implement-analytics-contract-test-ci-check
Summary

The upstream docker image forked here does not handle --remote-addr options correctly. Patch it here until upstream is fixed.
Design / Approach

The goal here is to create a fixed image we can use which is controlled by our org.
It can be available via:
docker pull ghcr.io/grnspace/docker-ngrok:SHA
Questions

Changes

[x]

Screenshots

LGTM -- let me know if you need me to make the organization secret.

Thanks @matthewshirley I'll squash up the oopsies and then get this in. Thanks for the :eyes:

repo: grnspace/docker-ngrok


text:
there is a badcase

there is a badcase
strip.StripTags(<tex>0<x<2</tex>)
get          0
expect   0<x<2

must use < replace<
<tex>0<x<2</tex>

authors: hailaz zhaolunallen

repo: grokify/html-strip-tags-go


text:
Please provide channel creation arg to disable http proxying

Please answer these questions before submitting your issue.
Should this be an issue in the gRPC issue tracker?
Yes
What version of gRPC and what language are you using?
1.4 python
What operating system (Linux, Windows, …) and version?
linux
What did you do?
Set http_proxy +no_proxy env vars, run python code. Try to connect to grpc server running on localhost
What did you expect to see?
Connect to server
What did you see instead?
Connection fails because it gets proxied
Anything else we should know about your project / environment?
This used to work in 1.0 before http_proxy was implemented. We need http_proxy set in our env in order for a lot of other code to correctly proxy connections to the outside world. Even if no_proxy were supported so we could connect to localhost, we still don't want to proxy all other rpcs. Can you please implement a channel creation arg that says to ignore http_proxy?

The attached PR does not solve my problem, because no_proxy only lets you specify *.domain.com. we connect to IP/port which does not play nicely with no_proxy, so we'd still like a channel arg to explicitly disable proxy.

Ping? This was a breaking change after 1.2 and makes it harder to use grpc client in the same application with other libraries that talk to outside world such as boto (http://boto3.readthedocs.io/en/latest/index.html)

@nicolasnoble, @ctiller: what are your thoughts on this?

Bouncing this one to @markdroth - this was mainly targeted at @ctiller, but wasn't reassigned properly when he left.

Reassigning to @yashykt, who now owns the proxy mapper code.

Given that we have existing ways to disable proxying, I don't see the need for this.
(I don't see any restriction which says IP addresses cannot be added in no_proxy.)
Feel free to reopen if I'm wrong.

@yashykt yes, no_proxy can be used with an IP address, but it cannot be used with IP ranges as far as I know. (See also https://unix.stackexchange.com/questions/23452/set-a-network-range-in-the-no-proxy-environment-variable). If I am wrong about this point, please show me, I'd love a solution.
Since we have a deployment of 50K+ machines, it is not feasible to specify no_proxy env variable that will whitelist them all.
I don't see a way to reopen this issue from my end, perhaps your permissions are locked down.

Reopened per reporter's request

Another approach might have been to use separate processes, but it might be a good idea to have explicit channel arguments for http proxy.

channel arg GRPC_ARG_ENABLE_HTTP_PROXY added for this purpose in #15699. Set it to zero to disable http proxy usage.

authors: dzbarsky markdroth mehrdada nathanielmanistaatgoogle nicolasnoble yashykt

repo: grpc/grpc


text:
Failed macos bins/opt/h2_compress_nosec_test retry_streaming

c_macos_opt_native bins/opt/h2_compress_nosec_test retry_streaming GRPC_POLL_STRATEGY=poll
https://source.cloud.google.com/results/invocations/9f5db172-a441-4c1e-b4d6-8373c91f813c/targets/github%2Fgrpc%2Fc_macos_opt_native/tests
and an earlier instance:
https://source.cloud.google.com/results/invocations/6e6e5cb5-dd4c-4c0f-92d5-cb088e51fdf3/targets/github%2Fgrpc%2Fc_macos_dbg_native/tests
D0524 17:17:45.020801000 140736353821632 test_config.cc:391]           test slowdown factor: sanitizer=1, fixture=1, poller=1, total=1
D0524 17:17:45.021771000 140736353821632 ev_posix.cc:145]              Using polling engine: poll
D0524 17:17:45.021821000 140736353821632 dns_resolver.cc:339]          Using native dns resolver
I0524 17:17:45.021882000 140736353821632 retry_streaming.cc:47]        Running test: retry_streaming/chttp2/fullstack_compression
D0524 17:17:45.025936000 140736353821632 retry_streaming.cc:168]       client_peer_before_call=localhost:25226
D0524 17:17:45.025975000 140736353821632 dns_resolver.cc:280]          Start resolving.
E0524 17:17:50.026796000 140736353821632 cq_verifier.cc:235]           actual success does not match expected: tag(2) GRPC_OP_COMPLETE success=1 test/core/end2end/tests/retry_streaming.cc:206
*******************************
Caught signal SIGABRT
  no backtrace

Duplicate of #15599.

authors: AspirinSJL markdroth


text:
Windows Test Failure: unit._local_credentials_test.LocalCredentialsTest

Python unit test for local credential is failing on Windows. The observed behavior is hanging until timed out. It requires much more digging into Windows.
https://fusion.corp.google.com/runanalysis/info/prod:grpc%2Fcore%2Fmaster%2Fwindows%2Fgrpc_basictests_python/prod:grpc%2Fcore%2Fmaster%2Fwindows%2Fgrpc_basictests_python/KOKORO/f41c15a8-189d-4c8c-a17c-20dc203bc4d4/1566580323353/build %231772/Targets?e=-TargetLevelInsightsEnabled&jsmode=du

Haven't seen this issue in a long time, closing.


text:
installing gpcrio - calculate_macosx_platform_tag doesn't parse 'base_version' correctly

What version of gRPC and what language are you using?
1.51.1
What operating system (Linux, Windows,...) and version?
Mac 12.6
What runtime / compiler are you using (e.g. python version or version of gcc)
Python 3.8.15
What did you do?
pip install grpcio
What did you expect to see?
should install correctly
What did you see instead?
File "lib/python3.8/site-packages/wheel/macosx_libfile.py", line 360, in calculate_macosx_platform_tag
  assert len(base_version) == 2
  AssertionError
  ----------------------------------------
  ERROR: Failed building wheel for grpcio

This is happening because distutils.utils.get_platform is returning:
macosx-12-x86_64 instead of macosx-12.6-x86_64 and the parsing code expects to see an 12.6 for the version and not 12, so the assert fails
Anything else we should know about your project / environment?

Hi, can you provide more logs for this error?

The problem is, distutils is reporting my mac's version as macosx-12-x86_64, the code in calculate_macosx_platform_tag splits this string on the '-'' and grabs the middle segment '12', and then splits it again on '.' because it's expecting something in the format of X.X, but in this case, there is nothing to split.  There is an assert check that expects -exactly- 2 values here (a major and a minor version number), and it fails, so the install breaks.
My ugly workaround was just to hardcode it to 12.6 to get the install to pass.

Are you building grpc from source with an M1 Mac? If so this PR (https://github.com/grpc/grpc/pull/31747) will be helpful.
And also distutils is vendored by setuptools, can you try again with newer version of setuptools?

authors: XuanWang-Amos jasonhudgins


text:
Build fails with the latest gazelle (0.37.0)

What version of gRPC and what language are you using?
1.54.1 (but on the latest 1.64.0 is still present)
What operating system (Linux, Windows,...) and version?
Linux and MacOs
What runtime / compiler are you using (e.g. python version or version of gcc)
bazel 6.4.0
What did you do?
I updated to gazelle 0.37.0
What did you expect to see?
Build with no errors
What did you see instead?
Builds started to fail with
failed to build tools: # github.com/bazelbuild/bazel-gazelle/cmd/fetch_repo
src/github.com/bazelbuild/bazel-gazelle/cmd/fetch_repo/go_mod_download.go:64:17: undefined: errors.Join

This happens because errors.Join was introduced in go 1.20 (link), but grpc/grpc has hard-coded go 1.18 (link).
I tried to specify the version in my WORKSPACE file
load("@io_bazel_rules_go//go:deps.bzl", "go_register_toolchains")
go_register_toolchains(version = "1.20")

but it conflicts with the version specified in grpc
    grpc_extra_deps()
File ".../external/com_github_grpc_grpc/bazel/grpc_extra_deps.bzl", line 56, column 27, in grpc_extra_deps
    go_register_toolchains(version = "1.18")
File ".../external/io_bazel_rules_go/go/private/sdk.bzl", line 713, column 13, in go_register_toolchains
    fail("go_register_toolchains: version set after go sdk rule declared ({})".format(", ".join([r["name"] for r in sdk_rules])))
Error in fail: go_register_toolchains: version set after go sdk rule declared (go_sdk)

Could you please update the go version and/or make non hard-coded, so grpc can be used with the latest gazelle?
Anything else we should know about your project / environment?

I've updated our dependencies and backported the change to 1.64, it should be out in a 1.64.1 patch release ~soon.

authors: aira-xite drfloob


text:
Obj-C cannot resolve nodename nor servname provided or not known

When I try to run an the helloworld objective-C client and a python server, I get

[resolve_address_posix.c:119] getaddrinfo: nodename nor servname provided, or not known.

OSX El Capitan, xcode 7.0.1 Simulator version 9.0

it appears that this is happening because you're trying to force people to use SSL. Is there a reason for this? Was that the intention?

to clarify, if i modify the gRPCHosts.m file to not force SSL, it works. By default all connections even ones starting with http: are added as secure, and the addition of https:// to the beginning breaks the parsing mechanism. I've made changes for my own purposes but this isnt a long term solution, so I don't want to push. Was there an intent behind these changes? they appear to have been made months ago.

gRPCHosts.m doesn't decide whether the connection is TLS or not. That https:// there is kind of a red herring in this investigation; the hostURL object is just used to parse a provided address, which should not have a protocol specifier.
For an example of how to make a connection without TLS, see tests/InteropTestsLocalCleartext.m.

I've been basing it off of the helloworld example (which does not currently work for me, nor for a coworker). It seems like the _secure=YES tries to enforce something.

the problem with the adding the https:// I think is that it messes up the host parsing later so that it thinks that the host address is "http" instead of whatever its supposed to be

Well, I am having trouble getting the example to work, but I'm getting a different error than you're describing. And you're right, it looks like the _secure variable is in fact used to determine whether to initiate a secure connection. And the API used in the file I referenced is only available in tests.

Life is a rich tapestry. My fix was to change _secure to NO, which isn't right either (and to take http:// out of the host name). I don't know objective-c at all, otherwise I'd make a pull request and fix it myself.

it appears that this is happening because you're trying to force people to use SSL. Is there a reason for this? Was that the intention?

The intention isn't to force using SSL, rather than using cleartext requires explicit opt in that's easy to spot on a code review. That's why the switch was made from having people specify "http://" to having them call [GRPCCall useInsecureConnectionsForHost:myHost] (as in the test Michael pointed to). The reason is we don't want anybody using cleartext inadvertently.
The scheme part of the server's URL doesn't need to be specified anymore.
I'm currently going over all samples to ensure they're up-to-date (#3371). Sorry for the time it's costed you.

As far as I can tell, useInsecureConnectionsForHost is only in GRPCCall+Test.h. Is that intended to be a public header?

Yes, it's a public header, as used in the test; all private headers are under private/.

so I should be using GRPCCall+Test.h for unsecured communication from now on? Will the examples be updated to reflect this?

The +Test suffix in the name seems to imply that it's only there to be used by the tests. If we expect actual users to call it, we should probably just put it in GRPCCall.h.

I agree that it being in the Test category is misleading. Both methods there have use cases outside of tests when the user controls the server or the network. We should find a better name for the category and have GRPCCall+Test.h just import that other one.
The biggest problem for now is fixing the samples, though. I reckon the majority of users find how to do these things through them rather than exploring the library's headers.

@mdering: Yes and yes. Please give it a try and, if it works as intended, we can close this issue (there's already #3371 for the samples).

I'm not 100% sure how this would look. how would I swap this out, would it be on client creation, would that be the only change?

You have to call it once for every host address, before creating any client object to that host:
[GRPCCall useInsecureConnectionsForHost:myHost];
...
[MyProtoService serviceWithHost:myHost];

That's the only thing you should need to do to renounce to TLS. Because we're using sockets directly, you currently won't need to add an App Transport Security exception to the Info.plist file of your app. But you should anyway, because we might move to using NSURLSession under the hood if it supports gRPC in the future.

@mdering, I've updated the hellow_world sample to reflect these changes and tested it. Please give it a try and let us know if you're still having trouble.

that seems to have worked. Thanks so much.

authors: jcanizales mdering murgatroid99


text:
Requests are failing with status UNAVAILABLE

I am writing a p2p software using grpc. When testing I start all nodes in the same process. Therefore a lot of channels (sockets) are opened in the same process. Under some circumstances a lot of requests fail with status code UNAVAILABLE.
I guess this happens because some system resource is exhausted (open files/sockets?). Is there a way to get more information whether this is some grpc internal limitation or some operating system limitation that prevents the successful request?
There should be a detail text in the grpc::Status object that provides me with more information (at least in debug mode).
This is with version 1.0.1 on macOS 10.12.1.

Are you able to run with GRPC_VERBOSITY=DEBUG and GRPC_TRACE=ALL?

I did run it with GRPC_VERBOSITY=DEBUG. This is the sequence that pops up before a request fails:
I1207 10:57:18.575999000 123145534390272 subchannel.c:642] Connect failed: {"created":"@1481104638.575942000","description":"Failed to connect to remote host","file":"src/core/lib/iomgr/ev_poll_posix.c","file_line":427,"os_error":"Timeout occurred","target_address":"ipv4:127.0.0.1:50051"}
I1207 10:57:18.576049000 123145534390272 subchannel.c:645] Retry immediately
I1207 10:57:18.576091000 123145534390272 subchannel.c:642] Connect failed: {"created":"@1481104638.575950000","description":"Failed to connect to remote host","file":"src/core/lib/iomgr/ev_poll_posix.c","file_line":427,"os_error":"Timeout occurred","target_address":"ipv4:127.0.0.1:50051"}
I1207 10:57:18.576101000 123145534390272 subchannel.c:645] Retry immediately
I1207 10:57:18.576109000 123145534390272 subchannel.c:609] Failed to connect to channel, retrying
I1207 10:57:18.576203000 123145534390272 subchannel.c:609] Failed to connect to channel, retrying

All the nodes share one server with the IP 127.0.0.1:50051. So the server is there. It may be overloaded or something?
I also ran the test program with tracing enabled. This yields a massive log file (35MB). I have attached it in compressed form. In my code I print out failed client requests with the error number. So grep for (14) to get to the places where the request failed.
I use the sync API for the server and the async API for the client. Currently I use 4 client threads each with their own completion queue. Thread sanitizer does not report any issues.
The trace file (1,5MB compressed):
https://cloud.theissen.io:14101/f/8e7e7ce024/?raw=1

Looking at the logs, it seems your intuition is correct: the system resources are exhausted. Look at log messages from "connectivity_state.c:156", eg (formatted for readability):
D1207 11:19:34.926607000 123145478201344 connectivity_state.c:156]
SET: 0x10554a9d0 subchannel: CONNECTING --> TRANSIENT_FAILURE [connect_failed]
error=0x1056473b0
{
    "created": "@1481105974.926567000",
    "description": "Connect Failed",
    "file": "src/core/ext/client_config/subchannel.c",
    "file_line": 638,
    "referenced_errors": [
        {
            "created": "@1481105974.858292000",
            "description": "Failed to connect to remote host",
            "errno": 35,
            "file": "src/core/lib/iomgr/tcp_client_posix.c",
            "file_line": 186,
            "os_error": "Resource temporarily unavailable",
            "syscall": "getsockopt(SO_ERROR)",
            "target_address": "ipv4:127.0.0.1:50051"
        }
    ]
}

(btw, you can get traces of this kind by only specifying "connectivity_state" in the GRPC_TRACE env var. Using all is usually overkill, see here).
There's another issue at play here: Retries happen too eagerly. This has been recently fixed see this PR. By waiting longer we prevent the avalanche effect that only compounds the problem of not having resources available.
The problem with appending the info you see in the traces to the Status is that it may get too verbose. Imagine a connection goes over 10 retries, succeeds, fails again and then the call times out. You then get a Status indicating the deadline exceeded failure (the higher level cause of the failure after all). Which information should be included? all 10+1+1 transitions of the connectivity? That being said, I believe @ncteisen is working on something that'd actually make it possible to fully trace the cause of a failure. For now though, there's the traces.
@ncteisen is there an issue/description of the error tracing feature somewhere?

The channel tracing internal design doc is WIP, and should be done by the end of this quarter. Once it is finalized, I will publish it to Github. The implementation is going to occur next quarter.

I got exactly same error for a single client ( not multi threaded).
what could be the issue?
GRPC:INFO [socket_utils_common_posix.c::205] Disabling AF_INET6 sockets because ::1 is not available.
Mar 28 15:13:26 MaestrOS SysRepoSync.elf: 27266:GRPC:INFO [subchannel.c::642] Connect failed: {"created":"@1490732006.164787096","description":"Failed to connect to remote host","file":"src/core/lib/iomgr/ev_poll_posix.c","file_line":427,"os_error":"Timeout occurred","target_address":"ipv4:10.64.156.72:35128"}

@rajnkamr is there a (responsive) server listening at 10.64.156.72:35128?

Yes server is listening on 35128.I got another error with loopback and 35128
GRPC:INFO [socket_utils_common_posix.c::205] Disabling AF_INET6 sockets because ::1 is not available.
GRPC:ERRO [chttp2_transport.c:<u[DBG] Thread id=140737308677888 signaled.490924672.415574602","description":"FD shutdown","file":"src/core/lib/iomgr/ev_poll_posix.c","file_line":427}

Is this still relevant?

authors: athei dgquintas nathanielmanistaatgoogle ncteisen rajnkamr


text:
Backport #15362 into v1.12.x

Backport https://github.com/grpc/grpc/pull/15362 to fix Python artifact build failure

****************************************************************

libgrpc.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

****************************************************************

libgrpc++.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

[microbenchmarks] No significant performance differences

authors: grpc-testing mehrdada


text:
Ensure thread_pool is not None for grpc.Server

I am considering checking thread_pool on server construction time, rather than failing at runtime when a job is submitted to the thread_pool, in a similar vein to validating generic_handlers passed at initialization time. However, this test was passing a None thread pool for implementation simplicity of the test, which makes it fail when that validation lands.

Objective-C binary sizes
*****************STATIC******************
  New size                      Old size
 1,952,970      Total (=)      1,952,970

 No significant differences in binary sizes

***************FRAMEWORKS****************
  New size                      Old size
10,665,041      Total (<)     10,665,050

 No significant differences in binary sizes

Objective-C binary sizes
*****************STATIC******************
  New size                      Old size
 1,952,970      Total (=)      1,952,970

 No significant differences in binary sizes

***************FRAMEWORKS****************
  New size                      Old size
10,665,044      Total (>)     10,665,043

 No significant differences in binary sizes


text:
Revert "Added TCP_USER_TIMEOUT auto-detection"

Reverts grpc/grpc#23401
breaks internal android targets

Fix forward in https://github.com/grpc/grpc/pull/23425


text:
[surface] Ensure SEND_STATUS & RECV_MESSAGE do not inhabit the same batch

Add a check that SEND_STATUS_FROM_SERVER and RECV_MESSAGE are not in the same batch.
This is necessary pre-work for #31204 and implements part of https://github.com/grpc/proposal/pull/336.
Also eliminates fling instead of updating it:

My expectation is nobody has looked at this corner in many years
It's not a benchmark we want: concentrating on a microbenchmark that doesn't include a binding layer caused us to favor designs that emphasized a lightweight core at the expense of a expensive bindings. We should consider the whole.

I think Ruby & C++ are ready.. looks like some PHP changes required, and maybe some Obj-C & a smidge more Python?


text:
PHP: add use_tls and use_test_ca param to interop tests script

Fixes #3732
And some general clean up

Main jenkins build is green. Interop build has the known errors.

LGTM
Can you also update PHPLanguage in run_interop_tests.py to use the --use_tls=true and --use_test_ca=true. It's fine to do that in a followup PR if you prefer to.

I added the --use_tls=true flag to run_interop_tests.py. And I also added some code to run_interop_tests.py to bring the language.global_env() environment variables to the build_interop_image.sh job. This is to further automate #3818 a bit instead of relying on user to pass that variable from the command line. Jan, can you please take a look at the last 3 commits? Thanks.

The interop tests Jenkins build is looking good for PHP. The 2 auth interop tests failure are addressed in the next PR #3854.

Alright, by objection came after it was merged. Can we remove the changes from last two commits?

Sure. I will do it in a new PR.

authors: jtattermusch stanley-cheung


text:
How to generate reports even on force mode?

I want to generate reports without stop the tasks queue, is it possible?
For example, I am running *jshint reports and unit tests in sequence, but if jshint fail it stop, I do not want it but if I do --force jshint reports not is generated.

Ok, I have resolved it, my bad, on my Gruntfile I have many file targets to one report file, when on force mode the report run and override the first report with the second, the second have no issues. -_-
jshint: {
	options: {
		reporter: require('jshint-html-reporter'),
		reporterOutput: '<%= meta.bin.reports %>/jshint.html',
		jshintrc: '.jshintrc',
		force: true
	},
	files: {
		src: ['<%= meta.src %>/**/*.js']
	},
	gruntfile: {
		src: 'Gruntfile.js'
	}
}

The solution is set only one target or set a specific report file for every target
jshint: {
	options: {
		reporter: require('jshint-html-reporter'),
		reporterOutput: '<%= meta.bin.reports %>/jshint.html',
		jshintrc: '.jshintrc',
		force: true
	},
	files: {
		options:{
			reporterOutput: '<%= meta.bin.reports %>/files.html'
		},
		src: ['<%= meta.src %>/**/*.js']
	},
	gruntfile: {
		options:{
			reporterOutput: '<%= meta.bin.reports %>/gruntfile.html'
		},
		src: 'Gruntfile.js'
	}
}

Thank you so much, maybe it help someone

repo: gruntjs/grunt-contrib-jshint


text:
Make GetPathRelativeTo() resolve symbolic links

Related to #75.
Without this change the relative paths are not computed correctly in case when basePath is a subfolder of path, and one  of them is a symbolic link of the other.
Note that I had to create fixtures for test cases of GetPathRelativeTo(), because the filepath.EvalSymlinks() method that we're now using is actually looking for files on disk.

Thanks for the review, Zack! Merging.

repo: gruntwork-io/go-commons


text:
Update all repo names

This PR was created by git-xargs. See https://github.com/gruntwork-io/prototypes/pull/152 for context. We recently renamed all of our repos to follow the Terraform registry format of  (e.g., ). This PR does a search & replace to update all references to these repos to the new names. GitHub can handle redirects, so in theory, everything should work fine with the old names, but there were so many renames, that to reduce confusion, this will update most of our references to the proper values.

Thanks for the review! Merging now.

repo: gruntwork-io/terraform-google-network


text:
Unexpected rename function get_terraform_commands_that_need_input

Describe the bug
Unexpected rename function get_terraform_commands_that_need_input
To Reproduce
Try to run any code with functions get_terraform_commands_that_need_input
extra_arguments "disable_input" {
    commands  = get_terraform_commands_that_need_input()
    arguments = ["-input=false"]
  }

output
ERRO[0009] /Users/ilya/work/terraform-aws/terragrunt.hcl:17,17-55: Call to unknown function; There is no function named "get_terraform_commands_that_need_input". Did you mean "get_terraform_commands_that_need_inputa"?, and 1 other diagnostic(s)
ERRO[0009] Unable to determine underlying exit code, so Terragrunt will exit with error code 1
Versions

Terragrunt version: v0.53.4

Additional context
problem place in code: https://github.com/gruntwork-io/terragrunt/blob/c4dcbf1d385ce525fa9113298cb7f370885d99cd/config/config_helpers.go#L56
PR with error: https://github.com/gruntwork-io/terragrunt/pull/2791

Fixed in https://github.com/gruntwork-io/terragrunt/releases/tag/v0.53.5

repo: gruntwork-io/terragrunt


text:
Move GCP related resources to separate dir

Partially fixes #600

I'm in favor of this, but I guess we should also add build tags similar to how we handle Azure in order to future proof it. @yorinasub17 thoughts?
@StupidScience did the tests pass correctly?

@robmorgan I've moved default packer variables to separate dir and now it works fine.
Also // +build gcp tag added

I'm in favor of this 👍
Note that this only partially fixes #600, so @StupidScience, could you rephrase your PR description so that issue isn't auto-closed when this PR is merged?
@robmorgan, I'll let you take it from here, run tests, etc.

@brikis98 what should I do to prevent issue autoclosing? Just remove issue reference?

Yup! Or remove the word "fixes" as I think that's one of the keywords GitHub looks for in PR descriptions.

@brikis98 done

Thanks!

This LGTM! However, before we can kick off our build, I think the circleci config will need some surgery to make sure it runs the gcp packages.

repo: gruntwork-io/terratest


text:
🛑 kinderundjugendtanz.at is down

In 989211c, kinderundjugendtanz.at (https://kinderundjugendtanz.at) was down:

HTTP code: 0
Response time: 0 ms

Resolved: kinderundjugendtanz.at is back up in 8262f27.


text:
🛑 volkstanzwannwo.at is down

In a93417d, volkstanzwannwo.at (https://volkstanzwannwo.at) was down:

HTTP code: 0
Response time: 0 ms

Resolved: volkstanzwannwo.at is back up in a31c72b.


text:
🛑 h4.bretterhofer.at is down

In 5a35ee8, h4.bretterhofer.at (https://h4.bretterhofer.at/toggle.php) was down:

HTTP code: 0
Response time: 0 ms

Resolved: h4.bretterhofer.at is back up in 33c1f91.


text:
🛑 bretterhofer.at is down

In 519862f, bretterhofer.at (https://bretterhofer.at) was down:

HTTP code: 0
Response time: 0 ms

Resolved: bretterhofer.at is back up in ea91615.


text:
Achievements "true" on some games.

If for some reason, the extension is unable to get the user achievements information for a game, the page shows "achievements true"

Old because now the extension won't show achievements unless the user chooses to in options.
A whole new achievements system will be done.

repo: gsabater/Steam-Backlog


text:
add server2022 server2019 office2019 etc.....

add server2022 server2019 office2019 etc.....

添加的有重复的，并且有很多没有加上。我会更新一下。