WIP: V1beta api impl

This change is

Coverage decreased (-1.02%) to 56.12% when pulling a571355167fd2d366984b0d694aca295f380b931 on richardsliu:v1beta_api_impl into cf01b5125e25239042e1caef1ef44f7aaf2337e3 on kubeflow:master.

Coverage decreased (-1.02%) to 56.12% when pulling a571355167fd2d366984b0d694aca295f380b931 on richardsliu:v1beta_api_impl into cf01b5125e25239042e1caef1ef44f7aaf2337e3 on kubeflow:master.

Travis tests have failed
Hey @richardsliu,
Please read the following log in order to understand the failure reason.
     job=/some-job job_type=PS runtime_id=some-runtime tf_job_name=some-job
time="2018-11-01T03:38:33Z" level=info msg="Creating pod: some-job-ps-some-runtime-0-8hq2n" job=/some-job job_type=PS replica=0 runtime_id=some-runtime tf_job_name=some-job
time="2018-11-01T03:38:33Z" level=info msg="Job some-job missing pod for replica PS index 1, creating a new one." job=/some-job job_type=PS runtime_id=some-runtime tf_job_name=some-job
time="2018-11-01T03:38:33Z" level=info msg="Creating pod: some-job-ps-some-runtime-1-snmrr" job=/some-job job_type=PS replica=1 runtime_id=some-runtime tf_job_name=some-job
time="2018-11-01T03:38:33Z" level=info msg="Service: some-job-ps-some-runtime-0 not found, create new one." job=/some-job job_type=PS runtime_id=some-runtime tf_job_name=some-job
time="2018-11-01T03:38:33Z" level=info msg="Creating service: some-job-ps-some-runtime-0" job=/some-job job_type=PS replica=0 runtime_id=some-runtime tf_job_name=some-job
time="2018-11-01T03:38:33Z" level=info msg="Service: some-job-ps-some-runtime-1 not found, create new one." job=/some-job job_type=PS runtime_id=some-runtime tf_job_name=some-job
time="2018-11-01T03:38:33Z" level=info msg="Creating service: some-job-ps-some-runtime-1" job=/some-job job_type=PS replica=1 runtime_id=some-runtime tf_job_name=some-job
time="2018-11-01T03:38:33Z" level=info msg="Deleting Jobs namespace= selector=kubeflow.org=,job_type=PS,runtime_id=some-runtime,tf_job_name=some-job" job=/some-job job_type=PS runtime_id=some-runtime tf_job_name=some-job
time="2018-11-01T03:38:33Z" level=info msg="Deleting Pods namespace= selector=kubeflow.org=,job_type=PS,runtime_id=some-runtime,tf_job_name=some-job" job=/some-job job_type=PS runtime_id=some-runtime tf_job_name=some-job
time="2018-11-01T03:38:33Z" level=info msg="Deleting Service :some-job-ps-some-runtime-0" job=/some-job job_type=PS replica=0 runtime_id=some-runtime tf_job_name=some-job
time="2018-11-01T03:38:33Z" level=info msg="Deleting Service :some-job-ps-some-runtime-1" job=/some-job job_type=PS replica=1 runtime_id=some-runtime tf_job_name=some-job
time="2018-11-01T03:38:33Z" level=info msg="Get ConfigMaps :cm-ps-some-runtime" job=/some-job job_type=PS runtime_id=some-runtime tf_job_name=some-job
--- PASS: TestTFReplicaSet (0.00s)
=== RUN   TestTFReplicaSetStatusFromPodList
--- PASS: TestTFReplicaSetStatusFromPodList (0.00s)
=== RUN   TestIsRetryableTerminationState
--- PASS: TestIsRetryableTerminationState (0.00s)
=== RUN   TestClusterSpec
--- PASS: TestClusterSpec (0.00s)
=== RUN   TestJobSetup
--- PASS: TestJobSetup (0.00s)
=== RUN   TestPDBForGangScheduling
time="2018-11-01T03:38:33Z" level=info msg="PDB: tf-job-pdb-some-meta-name not found, create new one." job=/some-meta-name uid=
time="2018-11-01T03:38:33Z" level=info msg="Creating PDB: tf-job-pdb-some-meta-name" job=/some-meta-name uid=
--- PASS: TestPDBForGangScheduling (0.00s)
PASS
coverage: 21.9% of statements in github.com/kubeflow/tf-operator/pkg/apis/common/v1beta1, github.com/kubeflow/tf-operator/pkg/apis/tensorflow/helper, github.com/kubeflow/tf-operator/pkg/apis/tensorflow/v1alpha1, github.com/kubeflow/tf-operator/pkg/apis/tensorflow/v1alpha2, github.com/kubeflow/tf-operator/pkg/apis/tensorflow/v1beta1, github.com/kubeflow/tf-operator/pkg/apis/tensorflow/validation, github.com/kubeflow/tf-operator/pkg/client/clientset/versioned, github.com/kubeflow/tf-operator/pkg/client/clientset/versioned/fake, github.com/kubeflow/tf-operator/pkg/client/clientset/versioned/scheme, github.com/kubeflow/tf-operator/pkg/client/clientset/versioned/typed/kubeflow/v1alpha1, github.com/kubeflow/tf-operator/pkg/client/clientset/versioned/typed/kubeflow/v1alpha1/fake, github.com/kubeflow/tf-operator/pkg/client/clientset/versioned/typed/kubeflow/v1alpha2, github.com/kubeflow/tf-operator/pkg/client/clientset/versioned/typed/kubeflow/v1alpha2/fake, github.com/kubeflow/tf-operator/pkg/client/clientset/versioned/typed/kubeflow/v1beta1, github.com/kubeflow/tf-operator/pkg/client/clientset/versioned/typed/kubeflow/v1beta1/fake, github.com/kubeflow/tf-operator/pkg/client/informers/externalversions, github.com/kubeflow/tf-operator/pkg/client/informers/externalversions/internalinterfaces, github.com/kubeflow/tf-operator/pkg/client/informers/externalversions/kubeflow, github.com/kubeflow/tf-operator/pkg/client/informers/externalversions/kubeflow/v1alpha1, github.com/kubeflow/tf-operator/pkg/client/informers/externalversions/kubeflow/v1alpha2, github.com/kubeflow/tf-operator/pkg/client/informers/externalversions/kubeflow/v1beta1, github.com/kubeflow/tf-operator/pkg/client/listers/kubeflow/v1alpha1, github.com/kubeflow/tf-operator/pkg/client/listers/kubeflow/v1alpha2, github.com/kubeflow/tf-operator/pkg/client/listers/kubeflow/v1beta1, github.com/kubeflow/tf-operator/pkg/common/jobcontroller, github.com/kubeflow/tf-operator/pkg/common/util/testutil, github.com/kubeflow/tf-operator/pkg/common/util/unstructured, github.com/kubeflow/tf-operator/pkg/control, github.com/kubeflow/tf-operator/pkg/controller, github.com/kubeflow/tf-operator/pkg/controller.v1beta1/tensorflow, github.com/kubeflow/tf-operator/pkg/controller.v2/jobcontroller, github.com/kubeflow/tf-operator/pkg/controller.v2/tensorflow, github.com/kubeflow/tf-operator/pkg/logger, github.com/kubeflow/tf-operator/pkg/trainer, github.com/kubeflow/tf-operator/pkg/util, github.com/kubeflow/tf-operator/pkg/util/k8sutil, github.com/kubeflow/tf-operator/pkg/util/signals, github.com/kubeflow/tf-operator/pkg/util/testutil, github.com/kubeflow/tf-operator/pkg/util/train, github.com/kubeflow/tf-operator/pkg/util/unstructured, github.com/kubeflow/tf-operator/pkg/version
ok  	github.com/kubeflow/tf-operator/pkg/trainer	0.050s	coverage: 21.9% of statements in github.com/kubeflow/tf-operator/pkg/apis/common/v1beta1, github.com/kubeflow/tf-operator/pkg/apis/tensorflow/helper, github.com/kubeflow/tf-operator/pkg/apis/tensorflow/v1alpha1, github.com/kubeflow/tf-operator/pkg/apis/tensorflow/v1alpha2, github.com/kubeflow/tf-operator/pkg/apis/tensorflow/v1beta1, github.com/kubeflow/tf-operator/pkg/apis/tensorflow/validation, github.com/kubeflow/tf-operator/pkg/client/clientset/versioned, github.com/kubeflow/tf-operator/pkg/client/clientset/versioned/fake, github.com/kubeflow/tf-operator/pkg/client/clientset/versioned/scheme, github.com/kubeflow/tf-operator/pkg/client/clientset/versioned/typed/kubeflow/v1alpha1, github.com/kubeflow/tf-operator/pkg/client/clientset/versioned/typed/kubeflow/v1alpha1/fake, github.com/kubeflow/tf-operator/pkg/client/clientset/versioned/typed/kubeflow/v1alpha2, github.com/kubeflow/tf-operator/pkg/client/clientset/versioned/typed/kubeflow/v1alpha2/fake, github.com/kubeflow/tf-operator/pkg/client/clientset/versioned/typed/kubeflow/v1beta1, github.com/kubeflow/tf-operator/pkg/client/clientset/versioned/typed/kubeflow/v1beta1/fake, github.com/kubeflow/tf-operator/pkg/client/informers/externalversions, github.com/kubeflow/tf-operator/pkg/client/informers/externalversions/internalinterfaces, github.com/kubeflow/tf-operator/pkg/client/informers/externalversions/kubeflow, github.com/kubeflow/tf-operator/pkg/client/informers/externalversions/kubeflow/v1alpha1, github.com/kubeflow/tf-operator/pkg/client/informers/externalversions/kubeflow/v1alpha2, github.com/kubeflow/tf-operator/pkg/client/informers/externalversions/kubeflow/v1beta1, github.com/kubeflow/tf-operator/pkg/client/listers/kubeflow/v1alpha1, github.com/kubeflow/tf-operator/pkg/client/listers/kubeflow/v1alpha2, github.com/kubeflow/tf-operator/pkg/client/listers/kubeflow/v1beta1, github.com/kubeflow/tf-operator/pkg/common/jobcontroller, github.com/kubeflow/tf-operator/pkg/common/util/testutil, github.com/kubeflow/tf-operator/pkg/common/util/unstructured, github.com/kubeflow/tf-operator/pkg/control, github.com/kubeflow/tf-operator/pkg/controller, github.com/kubeflow/tf-operator/pkg/controller.v1beta1/tensorflow, github.com/kubeflow/tf-operator/pkg/controller.v2/jobcontroller, github.com/kubeflow/tf-operator/pkg/controller.v2/tensorflow, github.com/kubeflow/tf-operator/pkg/logger, github.com/kubeflow/tf-operator/pkg/trainer, github.com/kubeflow/tf-operator/pkg/util, github.com/kubeflow/tf-operator/pkg/util/k8sutil, github.com/kubeflow/tf-operator/pkg/util/signals, github.com/kubeflow/tf-operator/pkg/util/testutil, github.com/kubeflow/tf-operator/pkg/util/train, github.com/kubeflow/tf-operator/pkg/util/unstructured, github.com/kubeflow/tf-operator/pkg/version
?   	github.com/kubeflow/tf-operator/pkg/util	[no test files]
?   	github.com/kubeflow/tf-operator/pkg/util/k8sutil	[no test files]
?   	github.com/kubeflow/tf-operator/pkg/util/signals	[no test files]
?   	github.com/kubeflow/tf-operator/pkg/util/testutil	[no test files]
?   	github.com/kubeflow/tf-operator/pkg/util/train	[no test files]
?   	github.com/kubeflow/tf-operator/pkg/util/unstructured	[no test files]
?   	github.com/kubeflow/tf-operator/pkg/version	[no test files]
ignoring pkg/apis/tensorflow/v1alpha1/zz_generated.deepcopy.go
ignoring pkg/apis/tensorflow/v1alpha1/zz_generated.defaults.go
Job #2031.3
https://coveralls.io/jobs/41780494

travis_time:end:01e112b0:start=1541043445889647329,finish=1541043517351079376,duration=71461432047

TravisBuddy Request Identifier: d3a18250-dd8b-11e8-9e24-43be9eb2178e

/lgtm
/approve
Seems unfortunate that we have so much code duplication everytime we instantiate a new version of the API. Maybe it doesn't matter that much because API version changes should be rare.


API: Filter parameter (GQL filter queries spec)

This spec/issue describes the filter parameter originally mentioned in issue #5463, however it contains a more in-depth spec than usual, due to the complexity of the feature. This issue serves as a basis for documentation whilst the feature is in active development, as well as giving a basis for testing.
Table of Contents:

Summary
Key Contextual Information
Proposal
Spec
Implementation
Examples

Summary
The idea behind filter queries is including additional parameters in Browse API requests, causing the result to be filtered in some useful way. This provides an additional level of power and flexibility for users interacting with their data in themes, apps, and in the admin UI.
The initial focus is on the ability to do advanced queries against Posts, Tags, and Users. The following document outlines a detailed proposal for a 'query language' exposed via a top-level filter property available when accessing the API from various tools.

Key Contextual Information
The Ghost JSON API supports full BREAD operations, however filtering only applies to Browse requests.
Resources
There are 3 main resources in the Ghost JSON API which are 'public' resources, and have clear use cases which require advanced filtering:

Posts
Tags
Users

Relations
The following relations need special treatment when querying across resources.

Posts have many Tags
Posts have one Author (Users)
Tags have many Posts
Users have many Posts

Additionally, the relations & business logic in a blog reveal the following important relational data concepts:

Each Post has a Next Post and a Previous Post.
Each Post has a Tag Count
Each User has a Post Count
Each Tag has a Post Count

API Access Tools
There are 3 key tools which can be used to request data from the Ghost JSON API which need to be considered:

RESTful HTTP calls - E.g. GET /api/posts?limit=5
Method calls (used internally & in apps) - E.g. api.posts.browse({limit: 5})
The (in progress) 'get' handlebars helper - E.g. {{#get "posts" limit="5"}}

Proposal
Adding advanced filtering to Ghost's JSON API via a top-level filter parameter which accepts a string representation of an SQL query, highly optimised for the kinds of queries which we expect will be common to Ghost, but flexible enough to grow outside of anticipated use cases.
Top-Level Filter Parameter
A top-level filter parameter will provide advanced querying capabilities available in all 3 tools in a standard way, such that the parameter's value is always a string:

HTTP: GET /api/posts?limit=5&filter=???
Method Call: api.posts.browse({limit: 5, filter: "???"})
Get Helper: {{#get "posts" limit="5" filter="???"}}

In both the method call and get helper syntaxes, the filter parameter value will be surrounded by double-quotes. Avoiding double-quotes inside the string is therefore a requirement.
In the HTTP version, the string will need to be url safe. Url encoding & decoding will be required.
Filter Parameter Values
The key requirement of the filter parameter is to accept values which can represent the rough equivalent of the where clause of an SQL statement (language diagram). The fundamentals of this proposal are therefore the definition of a language which fits Ghost's use cases and can be converted into SQL through Ghost's Bookshelf/Knex model layer.
SQL's capabilities are extensive. To start with, the focus for Ghost is on supporting logical and & or combinations, comparisons using equals, greater than & less than (with support for not). The importance of the relation between Post & Tags also drives the need to support in.
Filter Anatomy
An individual filter is composed of 3 parts, the property that is being filtered, the operator (currently always =) and the value. Filters need to be combined in groups of or & and rules.
The property needs to support path matching: e.g. tag currently really means tag.slug.
The operators need to include equals, not equals, and numerical comparisons.
The values are strings, numbers, nulls etc that are matched/compared against.
Filter Style / Syntax
There are a number of common styles for combining properties, operators and values into expressions. This proposal borrows heavily from the style used in GitHub, Gmail & Slack amongst others: E.g.label:api or from:-hannah or stars:<10.
The syntax of this style is the use of property-operator-value triplets in the form: property:operatorvalue, where the colon is a separator, and operator is optional.
This syntax is short and compact for the common use cases in Ghost, for example: featured:true, tags:photo, author:john, image:-null, posts.count:>10
This syntax is also flexible enough to be extended to support multiple complex expressions by combining the property-operator-value triplets together with other symbols to represent and & or. Following on from using - for negation, the proposal is to use + for and as well as , for or e.g:  featured:true+tags.count:>10, tags:photo,tags:video.
This is then used inside of the filter="" parameter, E.g:

HTTP: GET /api/posts?limit=5&filter=tags:photo,featured:true
Method Call: api.posts.browse({limit: 5, filter: "tags:photo,featured:true"})
Get Helper: {{#get "posts" limit="5" filter="tags:photo,featured:true"}}

Filter Query Language Spec
Syntax
Filter Expressions
A filter expression is a string which provides the property, operator and value in the form property:operatorvalue:

property - a path representing the key to filter on
: - separator between property and an operator-value expression

operator is optional, so : on its own is roughly =

Property
Matches: [a-zA-Z_][a-zA-Z0-9_.]

can contain only alpha-numeric characters and _
cannot contain whitespace
must start with a letter
supports . separated paths, E.g. author.name or posts.count
is always lowercase, but accepts and converts uppercase

Filter expressions can be combined using the following:

+ - represents and
, - represents or
( filter expression ) - overrides operator precedence

Operator
The following operators are spec'd for the first version:

-  - not operator
> - greater than operator
>= - greater than or equals operator
< - less than operator
<= - less than or equals operator

Value
Can be one of the following

null
true
false
a **number **(integer)
a literal

Any character string which follows these rules:
Cannot start with - but may contain it
Cannot contain any of these symbols: '"+,()><=[] unless they are escaped
Cannot contain whitespace

a string surrounded by single quotes

Any character except a single or double quote surrounded by single quotes
Single or Double quote **MUST *be escaped
Can contain whitespace
A string can contain a date any format that can be understood by new Date()

Special characters:

: - filter expression separator
+ - **and **symbol
, - **or **symbol
( - left parenthesis (operator precedence)
) - right parenthesis (operator precedence)
-  - not operator
> - greater than operator
>= - greater than or equals operator
< - less than operator
<= - less than or equals operator
[ - left bracket (**in **operator)
] - right  bracket (**in **operator)
' - single quote (**string **syntax)
" - double quote - NOT PERMITTED UNESCAPED

Whitespace rules
Whitespace is not permitted inside of a property, or inside a value unless the value is surrounded with quotes. Everywhere else, whitespace is ignored and therefore becomes optional.
This allows for whitespace to be used to improve readability if necessary, as any of the following are equivalent and will be accepted.

featured:true+posts.count:>10, tags:photo,tags:video
featured:true + posts.count:>10, tags:photo, tags:video
featured: true + posts.count: >10, tags: photo, tags: video
featured: true + posts.count :> 10, tags: photo, tags: video

Implementation
Hold on to your hats, this is where shit gets real...
Creating a Parser
As far as I can determine, the set of rules above describes a language that can be represented by an unambiguous context-free grammar and therefore understood by an LALR(1) parser.
What this means is that we can represent the set of rules in a standard way, and then use JISON to generate a parser in JavaScript,  which can in turn be used in Ghost to understand filter query strings, and convert them into something more useful. Essentially, all that has to be done is write a set of rules & the hard part of this is done. Neat.
The parser should live in its own repository, with a full suite of tests, and become a dependency of Ghost. The repository for it is here: https://github.com/TryGhost/GQL
Parser Output
The next step is to determine what the 'something more useful' that the parser is supposed to output looks like. The essence of what we're doing is representing SQL, so we could output the SQL equivalent of a filter query string and then pass that to knex.whereRaw() , which will then run the query for us inside the model layer of Ghost.
In fact, this is what I did for a first test that all this works. I wrote a rudimentary version of the rules, output raw SQL, and ran it through knex. And it worked.
The downside to parsing straight to SQL is two-fold: firstly, by translating from one string format to another, there is little opportunity for semantic analysis - that is to validate or operate on the property and value parts of the query to check they exist, or are permitted (filtering by the password property of the User resource should not be permitted, for example). Secondly, it seems to me that running raw sql queries, even through knex, is likely to result in security problems.
Instead of churning out SQL, the parser needs to output an intermediary format that we can use to get all of the useful and contextual information out of the query. This format should be something we can easily pass to knex's query builder functions, like .where() and .orWhere(), (which take a property, and operator and a value) so that we can run the queries through the query builder.
The intermediary format must not lose any information from the query.
JSON Format
The proposal is to use an array. Each filter expression will be converted into an object with key value pairs representing the property, operator, and value.
Arrays are ordered, and so the order of the array will match the order in which the query should be built.
All except the first item of the array should also indicate whether the expression is to be combined with and or or. Something like this:
{statements: [
    {prop: 'tags.slug', op: '=', value: 'photo'},
    {prop: 'featured', op: '=', value: true, func: 'and'},
    {prop: 'tag.count', op: '>', value: 5, func: 'or'}
]}

To maintain precedence overrides, a single object in the array can alternatively represent a group that contains a sub-array of objects. The group object must also indicate whether it is combined using and or or.
{statements: [
    {prop: 'author.slug', op: '!=', value: 'joe'},
    {
        group: [
            {prop: 'tags.slug', op: '=', value: 'photo'},
            {prop: 'image', op: 'IS NOT', value: null, func: 'or'},
            {prop: 'featured', op: '=', value: true, func: 'or'}
        ], func: 'and'
     }
]}

This format lends itself nicely to building queries using the knex query builder functions,  as we can cycle through the array (and recursively through groups) calling where or orWhere as necessary. Having a JSON format with named key-value pairs for  property, operator, and value, makes it easy to use lodash magic to pull out parts of the query (e.g. all properties or all values) and validate them.
Post-Processing
Once we have our filter in a JSON format, and we can pull out properties (table & field names) and values, we can start to do some validation and processing of the information in order to ensure the queries are safe and sensible.
Public vs Private
Certain properties should not be filtered upon, e.g. user.email, user.password, user.status and post.status as all of these properties are affected by permissions / not intended to be available to public endpoints.
For now, as we're only intending to offer 'official' public-only beta API access via HTTP and the get helper, these properties could be santised out entirely if it's easier, or otherwise they should be santised out if the context is public (see the change coming with public permissions for more context for what I mean here).
Standard validation
All of the properties should be known attributes of the models, and all of the values should be valid values for those attributes, according to our standard validation mechanisms.
Joins
Any reference to a related table needs to be translated into a join.
Dates
Any String value used along with a date property E.g. created_at, updated_at, published_at, last_login should be converted into a Date that SQL can understand, providing it is something that can be parsed using JavaScript's new Date(). Some care needs to be taken here to check this will work across SQLite, MySQL and pg as they treat dates differently and Bookshelf/Knex is not good at handling this (yet).
Special Rules
There are a few queries which should have special rules for how they affect other parts of the query. The single example at the moment is filtering posts by tags where tag.slug is IN a set (or in fact, any use of IN).
Where using IN we need to be sure that we still return distinct items in the set (and the correct number). When using IN the default order should naturally change to be ordered by the number of matches in descending order.
E.g. when requesting posts with tags IN a group, the query output should be similar to (or have the same affect as) this:
select * from "posts"  inner join "posts_tags" on "posts_tags"."post_id" = "posts"."id"  inner join "tags" on "posts_tags"."tag_id" = "tags"."id"  where "page" = false and "status" = 'published' and "posts"."id" != 11 and "tags"."slug" in ('markdown', 'list')  group by "posts"."id"  order by count(tags.id) DESC, "posts"."status" ASC, "posts"."published_at" DESC, "posts"."updated_at" DESC, "posts"."id" DESC limit 5
Note the group by and order by count(tags.id) parts.

Examples
Here is a separate Gist outlining some example queries in HTTP, method call & get helper form: https://gist.github.com/ErisDS/f516a859355d515aa6ad, feel free to suggest more example use cases in the comments.

The GQL repository has a PR with an initial implementation: https://github.com/TryGhost/GQL/issues/2
Working on a PR to include this in Ghost, along with the {{#get}} helper so that people can start to play with it.

I put this in slack, but going to put it here too as it's a design change in the API:
For the old style requests, we include in the response some data under meta.filter which represents the object we filtered by, so posts.browse({tag: 'getting-started'}) would include meta.filter.tagscontaining an array with the getting started tag object inside it.
This was, I think, always a bit of a hack so we didn't have to do multiple requests to the API to build the page
I'm not intending to rebuild that behaviour for the new-style filter parameter - trying to figure out what extra objects need to be fetched and included is incredibly difficult, and I think, unnecessary fragility.
I think the frontend controller needs to ask for the data it wants, much like getting rid of the ability to fetch both posts & pages from the API, we need to remove all the 'hacks' from the API that we built in to make our own lives easier. E.g. part of https://github.com/TryGhost/Ghost/issues/5943 will be rewriting the frontend controller to be able to perform multiple requests.

@ErisDS I read over the requirements, examples and the GQL source. I put together a bunch of examples along with sample code for an api that I think will support everything you're looking for.
I reworked filters (aka "the JSON format"). I don't think the current implementation is flexible enough to achieve what you're looking for. I borrowed ideas from mongo on how to structure the JSON.
I also changed filters around to support aggregate queries like what you're going for with posts.count. I took some ideas from how ElasticSearch handles aggregates.
And I made one small change to how null/not-null is handled. Made it more concise.
I wrote all of this up on a fork of the README and I forked the gist with samples as well. Here's the gist and here the README.
In the gist I also show what a javascript API for GQL might look like. I think it would be amazing to have that library available to work with knexify independently from the blogging platform. We can talk more about that if you're interested.
I think going forward with the actual search implementation through bookshelf is probably best. That way you'll tie in with the event emitters, validation, and the pipelining via promises, etc.
I have some ideas on joins/projections as well that I can offer as well. But first things first. Let's see what you think of the filters. Once we're on the same page there and have a working implementation we can add to the pile.
Cheers!

I've read everything you've done, but I feel like I'm missing the beginning of your though process. GQL is currently out there in the wild, it's kinda working, it's not the prettiest, but it gets most of the job done. There are some bugs which I haven't had chance to really look into yet so maybe you're basing your thoughts on one of those, but I don't see the explanation written anywhere.
Sooo could you go back a few steps and explain in much more detail why you're proposing these changes?

Hi Hannah. Sure. A few pieces came together to prompt my ideas.
I'm working on a blog. I want to add search. Google search might work but really isn't what I'm looking for. I don't want to pay for Swiftype. So I started looking around for search options for Ghost.
I saw you're looking for a search lead and read some comments around the code which led me to believe that there was some work to be done and room still for implementation design.
I read through the models and saw how the relations fit together.
I found your sample use cases. A common problem stood out to me when I looked at them. APIs like this tend to start out with simple matching. People start to use the API and then want to do more an more complex queries. Before too long the API falls down and can't support pretty basic things like date range queries, aggregations or really anything other than exact matches.
You did a fantastic job on the spec. So it was easy to see that not only had you thought ahead to some of those more advanced query types, but you took the time to document them beautifully so that we all could understand what you're looking for :)
One thing that came up a lot in your examples was the use of .count. I translated some of the sample the GQL queries into SQL and tried to achieve the intended results, but couldn't. In order to get counts you need to use a GROUP BY. In order to achieve the results intended by posts.count:>1 you need to use GROUP BY HAVING.
At this point the statements: {prop, op, value} API fell down for me because it's not in sync with the way I have to think to get .count. The query to get .count requires a bit at the beginning and also at the end of the query. So it's more of an 'around' than an inline thought process.
Having worked a lot with mongo and elasticsearch, I had those models as references.
In ES, queries based on .count are implemented as an aggregation. And aggregations are specified separately from basic boolean or comparison match operators. It was a little weird for me at first to think of them differently. But it came to make sense quickly, feels natural after the initial learning curve and works very well.
The way .count was modeled in GQL was more like the ES count API. The difference between the count API and the count aggregation is that the count API just tells you the number of results that matched. But to use the number of matches to filter results, you need to use the aggregation.
With this in mind I went back to .count. With the idea that an aggregation mechanism is the way to go, and having worked with mongo a lot lately it seemed obvious to change posts.count to posts.$count.
This immediately brought into scope the way the mongo has implemented query operators. Having worked a lot with meteor, I know how expressive, natural and powerful this syntax is as you work with it.
At this point statements: {prop, op, value} seemed kinda clunky and verbose.
With all of this as context, I thought:

This seems straightforward.
I really want that search capability on my blog.
I'm going to need it if I'm going to be able to use Ghost for the larger help site that I need to build.
And I sure would like to use Ghost because:

I've already built the custom theme for the blog

and I want to have the same basic theme for the help site

without having to go and use another tool like Wordpress just because Ghost doesn't support search.

And Swiftype is still a lot more than I want to spend for something as fundamental as search.
And Ghost would be a lot more amazing than it already is

if it had things like analytics such as number of views, number of clicks, related posts

and they're going to need a more robust API to be able to provide things like that

And I bet the Ghost team feels pretty hamstrung by not having great search in spite of all of the great features Ghost does have.
And they're already looking for a search lead.

Heck, why don't I just build this thing!
So I swapped my architect hat in favor of my builder hat and I started to look at how I would implement an API to turn GQL into JSON filters which I could then pass directly into a call to posts.fetchAll().
It seemed natural that there should be a javascript API to do this transparently. This led me to the gql.findAll('posts').filter() API that I modeled in my fork of your gist.
I iterated on this for a couple of hours by working through a lot of the use cases in the the original README. As I did I found that the filter mechanism that I had in mind felt a lot more fluid than the original Statement Processing recommendation. And I knew it would support the more advanced aggregations that will be valuable to me and to others.
I ran into one or two things such as the recommendation for support for whitespace in GQL. It seemed to prevent me from running the query title:Hello World! against posts. But the space doesn't break any real rules in terms of the query logic. So I allowed it.
And there was the obvious conflict in how nulls were handled. image:null makes a bit more sense than title:null because image is a blob. But it prevents a query where title is actually the string 'null'. This may seem contrived. But I can avoid the conflict altogether by stating that image means WHERE image NOT NULL and image: means WHERE image IS NULL. With this syntax there's no special handling. And I felt like I was on the right track when I saw that others had stumbled on similar small inconsistencies. This syntax is also more concise.
And lastly, to wrap this up, the filter model that I came up with is less verbose than the JSON format defined here.
For example:
This:
{statements: [
    {prop: 'author.slug', op: '!=', value: 'joe'},
    {
        group: [
            {prop: 'tags.slug', op: '=', value: 'photo'},
            {prop: 'image', op: 'IS NOT', value: null, func: 'or'},
            {prop: 'featured', op: '=', value: true, func: 'or'}
        ], func: 'and'
     }
]}

becomes this
{
    'author.slug': { $ne: 'joe' },
    {
        'tags.slug': 'photo',
        'image',
        'features': true
    }
}

I see a huge amount of potential for GQL. It solves a common problem that primarily Lucene solves. But the GQL syntax is even better. It's more fluid and more concise. I really like that.
Does this help? I sure hope so. 'cus it's all I've got :)

Sorry for the slow response here! Too many exciting things happening at once :grin:
Pretty much everything you've said here makes 100% sense and seems like a great improvement to GQL. I kinda rolled with what I had as a beta implementation - the adage that you should build one to throw away. I don't think it's quite that drastic, but what I mean is, I'm definitely not precious about the implementation. (With the exception of the fact we need to use an actual parser and not regex :wink:)
I am, however, a little bit more precious about the user-facing syntax. I'm open to changing it but I feel that needs to be considered from more angles than the internal workings because it's what users come into contact with. Re: the null behaviour, I'm not 100% what the right thing is but I do agree it needs revisiting.
I'm really interested in the distinction you drew between a "count API" and a "count aggregate". This distinction makes it much easier to reason about some of the behaviour of counts in Ghost's API as a whole. However, I don't think that the user-facing filter syntax needs to change here?
I may be missing something, but at first glance it appears to me that in Ghost's API include="posts.count" is the equivalent of a count API, and filter="post.count>1" is the equivalent of an aggregate. As count in a filter is always an aggregate there seems little need for adding the $?

Hey Hannah. No worries :)
So I worked on this a bunch over the last couple weeks and pretty much have it where I think it makes the most sense. It's all in laran/GQL.
To touch on your comments:
Syntax: I changed it slightly. You can see what I did here. You'll see a couple differences in there from the spec defined here in 5604. Adding support for LIKE queries was one in particular that I thought was valuable.
Nulls: What I suggested before was harder work on the parser than I felt was necessary. So I left it as you originally had it, which works very well. My suggestion was more clever than it needs to be and more work that I think is worth it. It doesn't prevent a query from containing the actual string 'null' either because you can just quote it.
Aggregates: Yeah, I took an even stronger departure from the original syntax, and for good reason. I took some time to document how I actually implemented aggregates. But I'll explain a bit more here just for reinforcement.
Aggregate queries are a lot more tricky. And there's more than just the filter. There's table joins, grouping, etc. and it's (imho) just too complicated to cram all of that into the query. Hacks like this are required (which restrict the portability of the library). And there's a certain amount of context from the domain model that has to be configured outside of GQL. In the case of Ghost this comes from bookshelf. But it's a general concern.
So, what I did instead was just create the API in a way that allowed all of the grouping, aggregate function calls, and joining to be done outside of gql, and then reference the aggregate value (something like posts_count, which would have been posts.count in what I'll refer to as the 'old' syntax, and posts.$count in the syntax I proposed a couple weeks ago).
I did this by introducing a $having operator that works like this: $having.post_count. I wrote a full example including all the logic for joining, etc. here. Seeing the example will probably help to understand how $having works.
Aggregates also gets us into the topic of joins, so I'll mention that I also added some smarts to help enable that.
Joins: Joins are another thing that need some support separately from the filters.
There's actually three parts to the complete definition of a query.

What fields to return (the * in select *)
What rows to return (determined by where and having clauses)
How tables relate to one another (foreign keys, joins, etc.) within the context of points 1 and 2.

I standardized the API on knex. So defining what fields to return is done that way (using knex.select().
Determining what rows to return is exactly what the GQL string syntax defines. So this is the problem that GQL solves.
Re: how tables relate, it's something that also has to happen outside of GQL. But, because the GQL query tells us what tables are referenced (e.g. comments.author_id or posts.slug, etc.), I added smarts to extract that information from the query. So I wrote a function that returns an array of the tables referenced in the GQL query. There's a full example of how to use that function on the wiki.
I would love to have you take a look at what I've put together. It's pretty complete from the perspective of what I was trying to achieve, which is basically building a GQL library that's complete enough to support full search capabilities within Ghost, while keeping it general-purpose enough to make GQL broadly viable and useful outside of Ghost. I think it does that nicely.
I would have submitted a PR to review it. But it's such a complete overhaul that it didn't seem to make sense.
Talk soon.

This paragraph touches on a lot of different ideas, that I think are most poignant to the direction GQL needs to go in:

Aggregate queries are a lot more tricky. And there's more than just the filter. There's table joins, grouping, etc. and it's (imho) just too complicated to cram all of that into the query. Hacks like this are required (which restrict the portability of the library). And there's a certain amount of context from the domain model that has to be configured outside of GQL. In the case of Ghost this comes from bookshelf. But it's a general concern.

There are a couple of key things to pull out here I think:

Aggregate queries are a lot more tricky. And there's more than just the filter. There's table joins, grouping, etc. and it's (imho) just too complicated to cram all of that into the query.

You're absolutely correct here that the filter parameter of the API has wide reaching consequences on the SQL query. I've got a document I've been working on locally which is trying to work out the various details from both the perspective of doing count filtering (aggregates) and which I was also using to try to understand where permissions fit in (other issue entirely) - this is the relevant snippet from that doc: https://gist.github.com/ErisDS/f3e817e97f50ec039128
When I was originally designing these different query parameters, I didn't pay quite enough attention to the detail of how many aspects of the query filters would need to change. I had where & join covered (just about), plus the special rules for order & group, but I totally missed needing to work with having  clauses. Therefore I'm quite certain the issues you're working through with this are things I missed in the original spec, and that need thinking through and solving.
However, I disagree that it's too complicated to cram it all in. Fundamentally that's the purpose of GQL - to abstract all of that craziness of how SQL works away from the user. The GQL query language is primarily intended for use by theme creators = designers & frontend developers, the MO here is people who don't know how SQL works.
The fact that asking for all the tags with at least one post has such wide ranging effects on the query structure is an SQL implementation detail that I want to hide away, even if it is ridiculously hard to do that. I don't want the end user to have to think about any of that. That's why I don't think that count should have a $ and I definitely don't think that the keyword "having" has any place in the GQL syntax.

Hacks like this are required (which restrict the portability of the library). And there's a certain amount of context from the domain model that has to be configured outside of GQL. In the case of Ghost this comes from bookshelf. But it's a general concern.

The portability of the library is definitely not a primary concern. Knex itself allows for various different underlying databases, so we've already got quite a flexible tool. I think we need to solve problems with the querying possibilities first, and then when all that is nailed, if there's someone interested in making GQL more portable, that'll be great.
It's also worth noting that all of the context from the domain model that's currently configured in GQL is deliberately kept apart from the internal workings because it's clearly a problem that needs to be solved, but again, getting the internals of GQL & the querying working 100% first is more important - we  might find the domain model needs to change yet, once we know what it looks like, it'll be easier to move.
Secondarily, the way that GQL interacts with knex is also identified as not being quite right just yet and there's even an open issue for it. Again, it should be much easier to solve when the internals of GQL is closer to being complete.
In short, I really want to focus on getting the internals right before addressing the interface problems.

Hey Hannah. I appreciate the comments.
I'm with you on all points in terms of where we want to end up. I think we can have a conversation about how we get there. I think we're actually super, super close to being able to just do straight up tags.count for Ghost. And I think we can get 100% there using the internals that I've built without taking away the portability. So let's have a conversation about that. I think we're in really good shape there.
Bottom line is I 100% share your feelings in terms of building GQL to be right for the intended audience. We'll make that happen.
One point I want to bring up quickly is that the JSON in the previous comment on this thread is no longer valid. Here's what it would be given the current GQL change I'm proposing:
This was the old JSON that you posted:
{statements: [
    {prop: 'author.slug', op: '!=', value: 'joe'},
    {
        group: [
            {prop: 'tags.slug', op: '=', value: 'photo'},
            {prop: 'image', op: 'IS NOT', value: null, func: 'or'},
            {prop: 'featured', op: '=', value: true, func: 'or'}
        ], func: 'and'
     }
]}

I translated that to this GQL string:
'!author.slug:joe+(tags.slug:photo, !image:null, featured:true)'
Which becomes this JSON using the new gql.parse():
[
  {$not: {'author.slug': 'joe'}}
  [
    {'tags.slug': "photo"}
    {$or: {$not: {image: null}}}
    {$or: {featured: true}}
  ]
]

I'll follow up on your other comments later today when I have some time.
I'm looking forward to working on this with you Hannah. Cheers!

Hey Hannah. I appreciate the comments.
I'm with you on all points in terms of where we want to end up. I think we can have a conversation about how we get there. I think we're actually super, super close to being able to just do straight up tags.count for Ghost. And I think we can get 100% there using the internals that I've built without taking away the portability. So let's have a conversation about that. I think we're in really good shape there.
Bottom line is I 100% share your feelings in terms of building GQL to be right for the intended audience. We'll make that happen.
One point I want to bring up quickly is that the JSON in the previous comment on this thread is no longer valid. Here's what it would be given the current GQL change I'm proposing:
This was the old JSON that you posted:
{statements: [
    {prop: 'author.slug', op: '!=', value: 'joe'},
    {
        group: [
            {prop: 'tags.slug', op: '=', value: 'photo'},
            {prop: 'image', op: 'IS NOT', value: null, func: 'or'},
            {prop: 'featured', op: '=', value: true, func: 'or'}
        ], func: 'and'
     }
]}

I translated that to this GQL string:
'!author.slug:joe+(tags.slug:photo, !image:null, featured:true)'
Which becomes this JSON using the new gql.parse():
[
  {$not: {'author.slug': 'joe'}}
  [
    {'tags.slug': "photo"}
    {$or: {$not: {image: null}}}
    {$or: {featured: true}}
  ]
]

I'll follow up on your other comments later today when I have some time.
I'm looking forward to working on this with you Hannah. Cheers!

I 100% agree that this is all going in the right direction :+1:
The updated internal JSON spec looks good to me. I think it makes a lot more sense, but it would be great to have it outlined in an issue over GQL

Super. We're off to a great start :)
I'll create an issue with an outline of the changes and we can take it from there.

Just wanted to point out some changes the the string syntax which I've outlined here:
https://github.com/laran/GQL/wiki/GQL-Syntax

Literals and strings are now almost interchangeable. In literals you have to escape , and +. In strings you only need to escape '. Literals in IN clauses also need ] to be escaped.
Whitespace is allowed anywhere. Leading and trailing space is trimmed off literals.
Negation is done with ! instead of -
Double quotes are no longer a special character
A 'LIKE' operator was added with ~. Should be paired with % appropriately.
Dates and values starting with true, false or null can be written as literals

OK, most of those things are improvements to my pretty buggy handling of the intended syntax.
There are two major exceptions:

Negation is done with ! instead of -

This should not change. It was a deliberate design choice based on gmail, google, and other filter interfaces that users have exposure to. ! only means 'not' to a developer.

A 'LIKE' operator was added with ~. Should be paired with % appropriately.

This is new. I think that ~ makes sense for "LIKE" but I'm a developer, so it needs consideration from a user perspective.

Just to be sure you noticed it I'll mention that the negation is also done now by putting the negation character before the property, not the value. So, now it's !created_at:<2016-01-01 instead of what it used to be, which was created_at:-<2016-01-01
One of the observations that I made early on was that with - and the old syntax there was no way to indicate that you want something to equal a negative number. Saying quantity equals negative 1 would have been written quantity:-1. But that would have been interpreted as quantity does not equal  1. Changing that to ! solved that problem.
Then, as I looked at handling negation of not just single values but also clauses putting the negation before the property instead of before the value would allow the syntax to stay consistent.
For example: !created_at:2016-01-01 translates to {$not: {created_at: '2016-01-01'}}.
Likewise: !(featured:true, created_at:>2016-03-01) translates to {$not: [{featured: true}, {$or: {created_at: {$gt: '2016-01-01'}}}]}. The whole clause is negated.
This wasn't possible in a consistent way with the negation character coming before the value because there is no value for clauses. There's just the clause itself as a unit.
I also moved away from not equals via either != or $ne again to keep the idea of negation consistent. Having those in the mix would introduce is not, does not equal or other variations of the language around a simple not depending if it was an IN clause, a simple value or a set of conditions (using parens). The most consistent approach was to put the not operator before the property. That way the syntax is consistent and applies equally to all types of negation.
And, in fact, this is the way google does negation for search conditions with a property (e.g. -site:wordpress.org).
Re: - vs !. I understand where you're coming from. Google does use - for negation. I think it's relevant to point out though that Google searches are never anything but text. The search terms are never the name of a column, for instance. For anything more complicated than a simple match (clauses of conditions, IN queries, counts or other aggregations would fall outside what I'd consider "simple" Google directs you to use the advanced search page. So, with GQL can do we're already pushing the boundaries past what Google's search syntax can do.
Also, Github uses "NOT" for negation. It doesn't use -. So we're already different from Github syntax there.
Lucene, on the other hand [uses both](https://lucene.apache.org/core/2_9_4/queryparsersyntax.html#Boolean operators) NOT and -.
Another thing to consider is that someone that does a lot of front-end work, but who isn't a super-technical person, and who isn't a 'walking compiler' is probably used to seeing - in the context of CSS selectors and HTML attributes. To them - is a separator. It doesn't conceptually translate automatically to boolean logic. So in a way, using - is overloading the character, which makes it less straightforward of a choice for a boolean operator for that audience. It's the kind of thing where they're so used to glossing over hyphens as separators that they might gloss over a hyphen in a GQL string as well. And since they are probably less used to looking at code with a critical eye for syntax, it might be harder for them to spot a bug in their query.
For someone with absolutely zero context of boolean logic or programming syntax I would agree with you that - is probably a better choice though. Their mental model would likely gravitate to thinking of addition and subtraction operators.
And then, of course, you have developers who DO intuitively understand !. I can't think of a language that doesn't use ! to mean NOT.
Another thing is that you'll end up with queries like this featured:true+-created_at:<2016-03-01. There you have the + and the - right next to each other. They seem like inverses because addition and subtraction are inverses. But they mean totally different things. People could get confused into thinking that they should use EITHER the + OR the -.
For instance, we want a query that means "is featured and was not created after 2016-01-01".
The correct syntax (using the - operator) would be featured:true+-created_at:<2016-01-01.
But a less technical person could very easily try to collapse the + and - together to think that - means "AND NOT" and try to write the intended query like this instead featured:true-created_at:<2016-01-01, which would be invalid.
I think having the NOT character being the inverse of the AND character will lead to confusion like this. Using ! better distinguishes NOT from AND.
So, I think it's just worth noting these things as we think things through. What are your thoughts?


Add brotli encoding

See #1964.
According to these Firefox 44 should support brotli:
https://bugzilla.mozilla.org/show_bug.cgi?id=366559
http://puu.sh/kB9KG/9d5b3862b1.png
I couldn't find a demo/test server for this unfortunately.
No signal from Edge or WebKit.
https://github.com/MicrosoftEdge/Status/issues/291

Another proof of support in Firefox 44:
http://bitsup.blogspot.fr/2015/09/brotli-content-encoding-for-firefox-44.html
With a test case:
https://ducksong.com/cgi-bin/nph-bro
As the blog post mentioned:

[edit note - around Oct 6 2015 the token was changed to br from brotli. The token brotli was only ever deployed on nightly builds of firefox 44.]

So the result in garbled in the latest Firefox but that should change quickly.

Another working test case, this one serves with content-encoding: brotli so you can test it in Nightly:
https://http2.cloudflare.com/
From https://groups.google.com/a/chromium.org/d/msg/blink-dev/xdVm8c2GOMQ/R-QXY2UGBwAJ

https://www.bayden.com/test/brotliimg.aspx uses the proper Content-Encoding: br token, if that's useful to you in any way.

Also worth mentioning that Chrome is planning support; see Chrome Bugs: 452335, 472009

Yup, see "chrome_id":"5420797577396224".

Thanks!


[26.x][WFLY-16000] Ensure a secure-deployment with provider configuration can be converted to JSON properly on redeploy

https://issues.redhat.com/browse/WFLY-16000
Upstream: https://github.com/wildfly/wildfly/pull/15240

@fjuma 26.x will needs the OIDC test fix as well.

@bstansberry https://github.com/wildfly/wildfly/pull/15245

Thanks @fjuma


Qa

Coverage increased (+0.1%) to 84.276% when pulling 2b3ba8221b80550daa2b5db8a79bf7582f965118 on qa into 656d7448dce29e3f412e1cab5c548b7e73bb4354 on master.


Ignore the .vsconfig file generated by VS

Reasons for making this change:
The .vsconfig file is automatically generated by VS, it does not need version control, and it will be automatically generated when VS is opened.
Links to documentation supporting these rule changes:
https://devblogs.microsoft.com/setup/configure-visual-studio-across-your-organization-with-vsconfig/

<EMAIL_ADDRESS>

We have an existing Global\VisualStudioCode.gitignore that covers more than just this rule.

We have an existing Global\VisualStudioCode.gitignore that covers more than just this rule.

This is just a file generated by unity when you open VS to edit the code, and does not contain those files that you lock indicate.

I don't think this should be in gitignore.


Fix UI, clean up camera/selection, comments, bugs fixed

Made camera code less bulky by using an array, moved selection code to proper place preventing the need for a redraw variable

Yes, it does. Jorito, what Jay here wants is for the code to ADD an item to the selectedItems list if LShift is down. You've removed the functionality in this pull... Removed a lot of helpful comments, too.


Add FAQs section for GSSoC'21

As this project is shortlisted to accept contributions under GSSoC, we are supposed to include a dedicated FAQ section for GSSoC in README.md after Contribution Guidelines
Refer to FAQs section

I would like to work on this task!
You can assign it to me!


AccountSelectorMulti doesn't work with screen reader

Which package is this issue related to?
ffe-account-selector-react
Describe your issue (screenshots welcome!)
The accountselector does not work with screen reader (VO/Safari) and needs thorough testing and overhauling. Exemple of bugs:

No information is given on that there is alternatives neighter are they read on focus.
Not able to type in input field
Add space event as selector?
role=combobox is on the wrong element, should be on input

What is the expected behavior?
It should be usable with screen reader
What is the actual behavior?
It is not
Steps to reproduce
Use a screen reader on https://design.sparebank1.no/styleguidist/index.html#!/AccountSelectorMulti

Instead of continuing to reinvent the wheel, should we just swap to using downshift?

I second that, if no one else takes it upon them to test that the Downshift examples actually work I will try to do it asap (maybe next week).


fix: Uses catalog slugify

What's the purpose of this pull request?
This PR fixes slug mismatches, thus broken links, between @faststore/api and VTEX catalog.
How it works?
It uses same, the battle tested, slugify function VTEX IO uses for slugifying links. This is now possbile thanks to Gatsby v4.

Note: If you are not using gatsby v4, please upgrade before updating this library.

How to test it?
Make sure all links on base.store are working as intended. Also, I have changed the category name from Computer and Software to Computer & Software. This change used to break other versions of base.store, however, now, it should be working.
References

Slugify implementation on VTEX IO: https://github.com/vtex/rewriter/blob/1ce2010783e0586cab42534ce2fb7a983d8a3a84/node/clients/catalog.ts#L72

Could we add a link to the code to mention where it's copied from?

I copied this from rewriter: https://github.com/vtex/rewriter/blob/1ce2010783e0586cab42534ce2fb7a983d8a3a84/node/clients/catalog.ts#L72


zketcd: use correct root path for root checks

Root checks were making assumptions about the mangled path structure,
causing path_debug builds to fail to create nodes. Instead, check
root paths using a root path computed using the path mangler.
Fixes #52
/cc @shurup

lgtm


Feature: Signal Optimizer explainability

TODO: make sure custom regressors still store coefficients and intercepts

TODO:

[ ] Unit test for the case in the worker function where no model was selected
[ ] Unit testing for a pipeline and not an indivisual estimator (particularly with feature selection)
[ ] Unit test for the case where sklearn returns an invalid coefficient vector (if possible)
[ ] Unit test for the case where sklearn returns an invalid intercept format
[ ] Unit test for the case where multiple models are selected
[ ] Make sure custom regressors store coefficients and intercepts


[CARBONDATA-1398] Support query from specified segments

1. Objective : Support Query from specified segments.
2. Proposed Solution :
A new property will introduce to set the segment no.
User will  set property(carbon.input.segments. <database_name> .<table_name>) to specify segment no.
During CarbonScan data will be read from from specified segments only.
If property is not set, all segments will be caonsidered as default behavior.
3. Syntax Used :
To show all the segments.
It will display one new column at the end that will display the new segment-	           		       id of compacted segment.

Syntax : SHOW SEGMENTS FOR TABLE <table_name>;

		`e.g. => show segments for table carbon_table;`

TO set the segment ids.
Segment ids to which we need to query, can be set to property carbon.input.segments (new) .
Following syntax can be used to set segment ids from client(BEELINE)

Syntax : SET carbon.input.segments.<databese_name>.<table_name> = ;

e.g => SET carbon.input.segments.default.carbontable=1,4,5;
To reset the segment id.
Above property can be set to default behavior as follow.
Following syntax can be used to reset segment ids from client(BEELINE)

Syntax : SET carbon.input.segments.<databese_name>.<table_name> = *;

e.g => SET carbon.input.segments.default.carbontable=*
To reset all properties.
It resets all the properties to default value. So it is recommended to use only when you want to reset all the different properties.

Syntax : RESET;

e.g => reset;

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/222/

Build Failed with Spark 1.6, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/98/

SDV Build Success , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/853/

:+1: I came across the same idea yesterday: query from the specified segment. Happy to see you have already worked on this.
Need to provide the related usage in document.

@xuchuanyin  thanks. I will attach the doc as well.

retest please

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/232/

Build Failed with Spark 1.6, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/108/

SDV Build Fail , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/863/

Build Failed with Spark 1.6, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/123/

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/247/

SDV Build Success , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/878/

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/249/

Build Failed with Spark 1.6, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/125/

SDV Build Success , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/880/

Build Failed with Spark 1.6, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/130/

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/254/

SDV Build Success , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/885/

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/255/

Build Failed with Spark 1.6, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/131/

SDV Build Success , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/886/

Build Failed with Spark 1.6, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/132/

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/256/

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/257/

Build Success with Spark 1.6, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/133/

SDV Build Fail , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/887/

retest this please

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/259/

Build Success with Spark 1.6, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/135/

SDV Build Success , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/888/

SDV Build Fail , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/890/

retest this please

Build Failed with Spark 1.6, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/142/

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/266/

SDV Build Success , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/898/

retest this please

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/272/

Build Success with Spark 1.6, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/148/

SDV Build Success , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/904/

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/307/

Build Success with Spark 1.6, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/182/

Build Success with Spark 1.6, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/183/

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/308/

SDV Build Fail , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/938/

SDV Build Success , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/939/

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/365/

Build Success with Spark 1.6, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/241/

SDV Build Success , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/993/

Build Success with Spark 1.6, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/332/

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/457/

SDV Build Success , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/1085/

SDV Build Fail , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/1192/

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/561/

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/939/

SDV Build Success , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/1554/

@ravipesala  build succeeded and review comment resolved . Please review and merge.

LGTM


Support multiple value callback

Make Callback to interface
Callback now have SingleCallback (original) and MultipleCallback (new)
Added static method Callback.single() & Callback.multiple()
MultipleCallback can set maximum limit of the object queue (The limit is link to the size of list that the Callback can hold, not total amount of call)

Thank you for you contribution. It looks like this PR closes #39. I will merge this into master.


Forge version not grabbing the newest version. needs to manually set.

I was not able to find an efficient way to scrap the forge page for the latest version. Although, SSM does get a direct download and installs. If you need a specific version. Edit ssm.ps1 and find variable $forgeversion = "1.16.3-34.1.25"  You can get the version and build you need from the forge page and just remove the spaces. this should automatically grab the correct one and installs it.


Interactive census group selection

Make table census group selectable and change the point size.

@ericboucher @tetraptych is there an easy way for us to experiment with this to see how it might change result / performance of one of our datasets? would love to experiment with this in incremental steps before we fully implement.


bugfix(FDS-519): [Pickers] Add format based on language

Add format based on language
PR Author Checklist

[x] PR title adheres to Conventional Commits
[x] I have finished reviewing the contents of this PR for accuracy
[x] If needed, I have included a Changeset and it follows Semantic Versioning principles
[x] I have completed all of the above and have enabled auto-merge for this PR

Warnings

:warning:
Please assign someone to merge this PR, and optionally include people who should review.

  Generated by :no_entry_sign: dangerJS against b1a7dd11eebe8dc1e753a7cd89b03feace627502


Prepare for 3.5.0 release

Description

This is based off on #1289. I don't know how to chain PRs across repos in GitHub, so this may need to be cleaned up a bit. Or closed outright and redone.
Related Issue

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] I have run the pre-commit run command to format and lint.
[x] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[x] I have added my name and/or github handle to AUTHORS.rst
[x] I have added my change to CHANGES.rst
[ ] All new and existing tests passed.

@ddabble I merged a few dependency updates since they were pretty minimal. Hopefully that was alright by you. I updated the project for 5.0, dropped 4.1 in #1289. There's a bug fix from August that would be really helpful to my project so I wanted to help things along to make it easier for the next release. There looks to be a couple of other nice features since 3.4.0 as well.

I merged a few dependency updates since they were pretty minimal. Hopefully that was alright by you.

You're more than welcome to do so! Any help maintaining is greatly appreciated 😄

I updated the project for 5.0, dropped 4.1 in #1289.

Nice, I'll take a look (and also check if there are more things from 5.0 this project could benefit from) once I have time, but I'm not sure I will before sometime after new year..

Btw, is it okay if I request reviews from you for some future PRs I have planned for this repo? 🙂

Btw, is it okay if I request reviews from you for some future PRs I have planned for this repo? 🙂

Yeah, feel free to request reviews from me in the future. I can't promise they'll be timely though 😁

Great! 😊

I can't promise they'll be timely though 😁

No worries, and I guess I can also relate to that 😅

This is based off on #1289. I don't know how to chain PRs across repos in GitHub, so this may need to be cleaned up a bit. Or closed outright and redone.

I rebased on master, so it's good 🙂 But yeah, the usual method of setting the base branch to the branch of the PR you're basing it off, doesn't really work across repos, it seems 🤔

Not a big deal. Next time if I want to do that, I'll create the branches on the repo.

@treyhunner @rossmechanic Could one of you publish v3.5.0 to PyPI? 🙂

Done!


[Question] Is depth rectified before the registration?

Hello Thiemo,
I might have gotten it wrong but.. why the depth is not being rectified by the bridge before the depth registration takes place?

because the rectification and registration is done in one step.

Could you please point me to the right DepthRegistrationCPU method where this (lens correction) is happening?

Nevermind, found it, thanks!

It is happening here. The map gives for each coordinate in the rectified image the corresponding coordinate in the input image. This is then used to interpolate the values.


ISPN-10373 Store/Loader Non blocking SPI

https://issues.redhat.com/browse/ISPN-10373
Things required before integration

[x] Add in new BaseStoreTest for SPI
[ ] Fix test suite
[x] Old store/loader adapter
[x] Async store based on new SPI
[x] DummyInMemoryStore based on new SPI
[x] PersistenceManagerImpl based solely on new SPI

For next PR(s)

[ ] Javadoc for SPI
[ ] Support media type conversion
[ ] Document Async implementation
[ ] Add back in slow setting for DummyInMemoryStore

This PR relies upon https://github.com/infinispan/infinispan/pull/8322

@wburns Overall LGTM, but the parser changes for thread-pool-size have broken several tests.

Tests should be fixed now (ie. updated the various xml files)

https://ci.infinispan.org/job/Infinispan/job/PR-8316/28/ is the PR to look at. The most recent I just removed the one commented line.

Updated

Should be updated again :)

Updated, I left the review sections as separate commits for now.

Squashed all the commits down to 1 now that CI was acting good :)

Thanks @wburns


[BUG] glib 0.14.3 fails to typecheck / compile on non-x86 architectures

Version 0.14.3 of the glib crate does not compile on any non-x86 architecture (aarch64, armv7hfp, powerpc64le, s390x).
This commit seems to have introduced code that does not typecheck correctly on non-x86 architectures:
https://github.com/gtk-rs/gtk-rs-core/commit/9b9d47876a5898f5d9c756f8ea0f09bf5c54a204
This is the compiler error message:
error[E0308]: mismatched types
  --> src/variant_iter.rs:88:17
   |
88 |                 s as *const u8 as *const i8,
   |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `u8`, found `i8`
   |
   = note: expected raw pointer `*const u8`
              found raw pointer `*const i8`
error: aborting due to previous error
For more information about this error, try `rustc --explain E0308`.
error: could not compile `glib`

Thanks! Do you want to submit a PR for that? Doing s as *const u8 as *const _ or just s as *const _ should be sufficient here.

I'll verify whether this works and then submit a PR.
Though I wonder why the glib_sys::g_variant_get_child API is different (*const i8 vs *const u8) on x86 vs. non-x86 architectures. That sounds like another issue? I've only ever seen weird i8 vs u8 mismatches like this when mixing-and-matching Rust primitive types (like u8 from bytes) with libc::c_char.

It's for exactly that reason: libc::c_char.

Oh, C is just wonderful. Unsigned vs. signed chars :) I'll have my PR ready in a few minutes.


Fixed #24941 -- Added ModelAdmin.get_exclude() hook

I guess this might need some additions in django/contrib/admin/checks.py (or maybe not, I guess the other methods don't have checks because it's impossible to check them since they aren't static).
By the way, did you see the discussion on django-developers. Maybe you could chime in there since there were some concerns about whether or not this is actually a good idea.

Hi @timgraham!
Looking at checks.py, I think it doesn't check any of the dynamic methods, because as far as I understand, checks are run only once to verify that the configuration of admin in your code is ok. get_exclude or get_fields, etc, are used dynamically, so there is no way to verify that through checks.
I'm gonna post something to django-developers, thanks. I saw the discussion there, and I think it's a worthwhile change. I think improving admin's extensibility in some small ways like that may make developers life a lot easier, so I don't see why we wouldn't introduce that change.

I don't know if the get_exclude() method might be expensive, but it seems we could simplify by storing the result in a local variable to avoid calling it so many times.

A mention in the release notes is also needed.

Thanks @timgraham, I'm gonna work on this later today.

Hi Ola, any chance you could address the comments soon? If not, we can close this and ask someone else to finish it up. Thanks!

Will take a look this week Tim, sorry! Completely slipped from my radar :)
On Tue, Dec 29, 2015 at 4:46 PM, Tim Graham<EMAIL_ADDRESS>wrote:

Hi Ola, any chance you could address the comments soon? If not, we can
close this and ask someone else to finish it up. Thanks!
—
Reply to this email directly or view it on GitHub
https://github.com/django/django/pull/5214#issuecomment-167828061.

Closing due to inactivity. Feel free to send a PR if you have time to return to it.

Continued this PR at https://github.com/django/django/pull/7252.


BUG: Follow btn Not Working

In Home page they suggest some follower but when we click on follow button no change in button What i expected when we click on Follow btn then it will start following and when we click on unfollow then it unfollow to the user.
@SwanandD121 Please assign this issue to me under gssoc-ext, hacktoberfest-accepted, with the level-2.

I will reopen after backend integration


Ý->U instead of Y

thanks for the library! i think i have found a small issue with the mapping; when using python unidecode library (0.04.21)
áéíóůýÁÉÍÓŮÝ -> aeiouyAEIOUY
with latest junicode release, the output is slightly different:
áéíóůýÁÉÍÓŮÝ->aeiouyAEIOUU

unless the packaged jar has different code, it shouldn't be happening:
https://github.com/gcardone/junidecode/blob/master/src/main/java/net/gcardone/junidecode/X00.java#L247
so i'm bit stumped; i can try to build the library (next week however)

I've been a bad maintainer and the current jar is v0.4. I need to release a new jar synced at 45aabffe51c247fe41d0a12a49ab9c269bc89771 or later (which includes a fix for the issue you're seeing). Building your own jar should fix the problem.

Thanks!
On Fri, May 31, 2019, 5:33 AM Giuseppe Cardone<EMAIL_ADDRESS>wrote:

I've been a bad maintainer and the current jar is v0.4. I need to release
a new jar synced at 45aabff
https://github.com/gcardone/junidecode/commit/45aabffe51c247fe41d0a12a49ab9c269bc89771
or later (which includes a fix for the issue you're seeing). Building your
own jar should fix the problem.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/gcardone/junidecode/issues/12?email_source=notifications&email_token=AADEREXDMEPFQP3PPAHRD6LPYDWGJA5CNFSM4HRNC6Q2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWUXILI#issuecomment-497644589,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADEREV7PWGVI2VLL7LVME3PYDWGJANCNFSM4HRNC6QQ
.


[Feature request]: NPagination support size

This function solves the problem (这个功能解决的问题)
Resizing components
Expected API (期望的 API)
<NPagination size="small" />

Similarly, the pagination in NDataTable

想要多小？

How small do you want?

link the button tiny

It seems to be implemented since v2.29.0: https://www.naiveui.com/en-US/light/components/pagination#size.vue
So I guess this issue should be closed?


FLAC/WAV/AIFF option for downloads

Problem
FLAC/WAV/AIFF are the go to file format for DJ´s and audiophiles
Solution
spotdl "link" -o FLAC/WAV/AIFF (like in 2.2.2) or just -FLAC/WAV/AIFF for simplicity

Done in #1244 c879885

Though this issue is closed, .wav is still not supported. Will support be coming in the future?

Will add in #1339

I repeat the question that has already been asked. We currently only have FLAC support. Do you plan to add WAV and AIFF formats? It could be nice to have WAV and AIFF because FLAC is not supported on many DJ devices.

Yes, I am planning to re-add it in the next version.

I repeat the question that has already been asked. We currently only have FLAC support. Do you plan to add WAV and AIFF formats? It could be nice to have WAV and AIFF because FLAC is not supported on many DJ devices.

Yes, I am planning to re-add it in the next version.

Sir, How can I download songs in FLAC format?

I repeat the question that has already been asked. We currently only have FLAC support. Do you plan to add WAV and AIFF formats? It could be nice to have WAV and AIFF because FLAC is not supported on many DJ devices.

Yes, I am planning to re-add it in the next version.

Sir, How can I download songs in FLAC format?

With the option output format set as flac

Is it downloaded originally as a .flac or is it converted from a lossy format later on?


deploy

Description
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] Refactor (refactoring a current feature, method, etc...)
[ ] Code Coverage (adding/removing/updating/refactoring tests)
[ ] New feature (non-breaking change which adds functionality)
[ ] Remove feature (non-breaking change which removes functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Codecov Report
Attention: Patch coverage is 0% with 106 lines in your changes missing coverage. Please review.

Please upload report for BASE (explorer/production@cc1dd1b). Learn more about missing BASE report.

Files with missing lines
Patch %
Lines

src/Generator/Traits/HasTestTrait.php
0.00%
32 Missing :warning:

src/Generator/Traits/FormatterTrait.php
0.00%
10 Missing :warning:

src/Generator/Commands/MigrationGenerator.php
0.00%
7 Missing :warning:

...erator/Commands/TestCases/ApiTestCaseGenerator.php
0.00%
6 Missing :warning:

...erator/Commands/TestCases/CliTestCaseGenerator.php
0.00%
6 Missing :warning:

...Commands/TestCases/FunctionalTestCaseGenerator.php
0.00%
6 Missing :warning:

...rator/Commands/TestCases/UnitTestCaseGenerator.php
0.00%
6 Missing :warning:

...erator/Commands/TestCases/WebTestCaseGenerator.php
0.00%
6 Missing :warning:

src/Generator/Commands/ActionGenerator.php
0.00%
2 Missing :warning:

src/Generator/Commands/ConfigurationGenerator.php
0.00%
2 Missing :warning:

... and 12 more

Additional details and impacted files
@@                  Coverage Diff                  @@
##             explorer/production     #40   +/-   ##
=====================================================
  Coverage                       ?   4.45%
  Complexity                     ?     893
=====================================================
  Files                          ?      99
  Lines                          ?    3186
  Branches                       ?       0
=====================================================
  Hits                           ?     142
  Misses                         ?    3044
  Partials                       ?       0

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


Problem with permalink containing one line only

If I try to generate the code with a permalink that contains one line only, it shows the file from that line up to the end, while we only would show the single line.

What File are you using? can you paste the <script>

You're right. Will be fixed then.

Fixed, you can check it.

Just checked, and it works like a charm 👍
Thanks for the prompt response!


Shared IP Addresses

This may have been implemented already but I am having the following issue and wondered how I would get around it.
We have a number of device that share IP addresses between then.  Such as Virtual Management Addresses for SAN groups.  Currently I can turn off Enforce Uniqueness on the VRF and create an Virtual Interface on each device and assign the shared IP to that interface.  But this results in duplicate IP addresses showing the IPAM (one for each device).
Is there a way to set individual IP addresses so that they can be shared between devices without creating duplicates?

Sounds similar to the concept of stacked switches. I'll mark this as a duplicate of #99 but let me know if you had something different in mind.


AKS Deployment in Azure Stack Hub - From Marketplace - K8s Latest Versions not available

Hi Team,
When I tried deploying AKS in Azure Stack Hub using the marketplace option. It doesn't have Kubernetes latest versions, not even 1.21/1.22/1.23 versions. As in the drop-down list, I can see only 1.13 & 1.14.
We cannot use k8s 1.22 or 1.23 k8s versions if I use Azure stack hub marketplace.
Appreciate your inputs/suggestions. As I am a new user of Azure Stack Hub.

@zohebs341
Thanks for your feedback! We will investigate and update as appropriate.
It would be great if you could add a link to the documentation you are following for these steps? This would help us redirect the issue to the appropriate team. Thanks!

@zohebs341
We are going to close this thread as resolved but if there are any further questions regarding the documentation, please tag me in your reply and we will be happy to continue the conversation.


People Update OH

People Update OH

@bfossen-ce some folks need moving from leg to retired or vice versa and one deleted entry that needs to not be deleted. Other than that all set!

I have updated these requests and we should be good to go


There is no section on "operations on extern objects"

Do we need one in the spec?
The operations are instantiations and method calls.

That would be a nice extension for people relatively new to the P4 language !

I am not sure that what I have in mind would help newcomers: the section would not describe existing extern objects and their APIs, but it would just mention that extern objects can be instantiated and instances can have methods invoked. The spec is probably not the document I would recommend newcomers to read; it is really designed for people who want to implement P4, or to understand finer points of the language.

Sorry,  I wasn't clear 🙄 What I tried to say, for people rather new in implementing P4. It took me some back and forth reading between examples and the spec before I got it totally when starting writing simple P4 targets in proof of concepts....

If you find places where the spec is unclear please file issues.


[!] The target AwesomeProject-tvOSTests is declared twice.

started a new blank react native project
react-native init AwesomeProject
yarn add react-native-lock
react-native link
throws error [!] The target AwesomeProject-tvOSTests is declared twice.
# Uncomment the next line to define a global platform for your project
# platform :ios, '9.0'

target 'AwesomeProject' do
  # Uncomment the next line if you're using Swift or would like to use dynamic frameworks
  # use_frameworks!

  # Pods for AwesomeProject

  target 'AwesomeProject-tvOSTests' do
    inherit! :search_paths
    # Pods for testing
  end

  target 'AwesomeProjectTests' do
    inherit! :search_paths
    # Pods for testing
  end

end

target 'AwesomeProject-tvOS' do
  # Uncomment the next line if you're using Swift or would like to use dynamic frameworks
  # use_frameworks!

  # Pods for AwesomeProject-tvOS

  target 'AwesomeProject-tvOSTests' do
    inherit! :search_paths
    # Pods for testing
  end

end

# Auth0 Lock

pod 'Lock', '~> 1.26'
pod 'Lock/TouchID'
pod 'Lock/SMS'
pod 'Lock/Email'

Same.

Go to the Xcode project, open the project view and remove the tvOS targets from the side menu.

same here

I removed ios/[name].xcodeproj/xcshareddata/xschemes/[name-tvOS].xcscheme
I appreciate the attempt stami but I'm still getting the same error.

@bradyb90 I had the same problem. You have to delete those targets from Xcode, removing those schemes (note the difference to targets) doesn't make any difference. And be sure to do it from Xcode, don't just remove the files.

Ah understood, my mistake. I'll attempt that now. Thank you

For some reason CocoaPods generate a faulty default Podfile using pod init which is what the library relies in order to avoid non-iOS devs mess with native dependencies.
We will try to find a workaround for this but for the meantime you need to edit the generated file ios/Podfile to look like
# Uncomment the next line to define a global platform for your project
# platform :ios, '9.0'

target 'tonypoc' do
  # Uncomment the next line if you're using Swift or would like to use dynamic frameworks
  # use_frameworks!

  # Pods for tonypoc

end

# Auth0 Lock

pod 'Lock', '~> 1.26'
pod 'Lock/TouchID'
pod 'Lock/SMS'
pod 'Lock/Email'

and run pod install --project-directory=ios from the root of your project (or inside iOS folder just pod install)
Also if you want to clean your basic project I'd recommend removing the unused targets as suggested in previous comments, if you build only an iOS app you don't need the tvOS target and the test targets are also useless since most of your testing will be in JS (maybe jest) and not with XCTest

hzalaz, I followed your update here. Both @mypark and myself are also having an issue with the next step in the walkthrough as well. I have a feeling that the link might be the root of the problem. I will provide the separate issue below. Thanks for your time.
https://github.com/auth0/Mobile-Samples.React/issues/11

Success. Thanks for your help. Here is what I did

created a new project using react-native init.
copied the js and img files from the example to my project.
made sure the class in index.ios.js matched my project name
changed the register component to match my project name.
installed gem for cocoapods (gem install cocoapods)
cd to my project

npm install react-native-lock
npm install rnpm-plugin-update (don't know if this was necessary).

opened xcode

removed all targets except my ios target.
added my credentials.
closed xcode

rnpm link react-native-lock
opened the .workspace file
build and run from xcode.

@glebovitz Are you getting an undefined error when you click the "Log in" button from the quickstart Sample Project?

@bradyb90 no, it is working perfectly logging in using my google id.

just delete Podfile like this

Uncomment the next line to define a global platform for your project

platform :ios, '9.0'
target 'AwesomeProject' do
Uncomment the next line if you're using Swift or would like to use dynamic frameworks
use_frameworks!
Pods for AwesomeProject
'node_modules'目录一般位于根目录中
但是如果你的结构不同，那你就要根据实际路径修改下面的:path
pod 'React', :path => '../node_modules/react-native', :subspecs => [
'Core',
'RCTText',
'RCTNetwork',
'RCTWebSocket', # 这个模块是用于调试功能的
# 在这里继续添加你所需要的模块
]
pod "Yoga", :path => "../node_modules/react-native/ReactCommon/yoga"
end

It seems odd that tvOS is created by default to begin with. Shouldn't that be more of an add-on feature for a given project?
Anyways, this is still definitely an issue.

A simple solution: When you call 'react-native link', it creates a podfile. The error you get is an error in the podfile itself. To correct, open the podfile and comment out the duplicate loop:
target 'CollectiveMind-tvOSTests'....end.
Then, call react-native-link again. When you do so, you will be asked if you wish to create a new podfile, don't! Type N, and continue linking. That's what I did, and it worked!

@MatthewAwesome That works very well, easier than opening Xcode and messing around.

@bradyb90 I had the same problem. You have to delete those targets from Xcode, removing those schemes (note the difference to targets) doesn't make any difference. And be sure to do it from Xcode, don't just remove the files.

@stami
I think this might solve my problem. Could you show me how to achieve a 'target' from Xcode? I am in Xcode now. And I see tabs that say "General", "Capabilities", "Resource Tags" and so on. But I can't figure out how to delete tags. I don't see any folder or file that says 'ProjectName-tvOSTests'.

When running pod install you may encounter an error saying that a tvOSTests target is declared twice. This appears to be a bug with pod init and the way that react-native is set up.
Resolution:
Open your Podfile
Remove the duplicate tvOSTests target nested within the main project target
Re-run pod install.

same problem

@DataGreed
Per gnunua's comment above, this looks like an ongoing bug. You will have to comment out a few lines towards the end. It looks like # sign messes up with formatting on GitHub. So I will replace # with //.
This is what my file looks like. This is the very end of Podfile.
The error message went away when I commented out these lines.
`
target 'LondonTubeMap-tvOS' do
// Comment the next line if you don't want to use dynamic frameworks
// use_frameworks!
// Pods for LondonTubeMap-tvOS
// target 'LondonTubeMap-tvOSTests' do
//   inherit! :search_paths
//   // Pods for testing
// end
end
`

Your podfile is need to be like this:
`# Uncomment the next line to define a global platform for your project
platform :ios, '9.0'
target 'learnSQLite' do
Comment the next line if you don't want to use dynamic frameworks
use_frameworks!
Pods for learnSQLite
pod 'SQLite.swift', '~> 0.12.0'

end`


Feature: Specify a different path of composer.json file

Describe the feature
Per the docs:

php-version (optional)

...
If not specified, it looks for the following in order:

The php-version-file input if it exists
A composer.lock file and the platform-overrides.php value
A composer.json file and the config.platform.php value

However, if composer.json file is in a different sub directory, it could not be located correctly.
So it would be better to support specifying a different path of composer.json file.
Please check the latest release

[X] I have checked releases, and the feature is missing in the latest patch version of v2.

Underlying issue
Currently the filepath is hard-coded. It would be better to make it customizable:
https://github.com/shivammathur/setup-php/blob/85a8dfd0c711cf13677391db4c529061ab491414/src/utils.ts#L455-L456
Describe alternatives
No response
Additional context
No response
Are you willing to submit a PR?
Yes

Added in https://github.com/shivammathur/setup-php/commit/84f76b1fc988dcf5f9444a21b9cb53ddf89980a3


[stable/nginx-ingress] Pass correct headers to downstream applications when letting AWS terminate SSL.

What this PR does / why we need it:
The README offers a sample configuration for terminating SSL with an ELB on AWS's side. When this configuration is used, the header X-Forwarded-Proto is rewritten by nginx to always be http (what nginx sees), rather than http or https (what the ELB saw).
Some example behaviors I observed as a result:

Jenkins would redirect to the non-SSL endpoint when logging in, and also show the "It appears that your reverse proxy set up is broken." message in settings.
An internal application could not process POSTs unless they came in over plain HTTP (which caused other issues, as it wanted those POSTs to come in over HTTPS for security).

Setting use-forwarded-headers to true, and use-proxy-protocol to false in the ingress controller config corrects this, so that X-Forwarded-Proto reads http for a plain HTTP session, and https for an HTTPS session.
Since the behavior as-documented seemed broken, I chose to add these two parameters to the documentation.
Which issue this PR fixes
N/A
Special notes for your reviewer:
The link in the documentation was also broken, so I updated it.
I don't know if the broken config is correct in some other context, but I can't think of one, and it seems like it was just oversight.
Checklist

[x] DCO signed
[ ] Chart Version bumped
[ ] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/mychartname])

/hold
See https://github.com/kubernetes/ingress-nginx/pull/6038

stable/nginx-ingress has been deprecated in favor of the upstream ingress-nginx repo. See https://github.com/helm/charts/pull/22823. PRs if still applicable can be re-opened there. Thanks 😊


Issue 19

This PR solves the issue #19
Moreover, it adds a new pf example using the WSCC9 system to test the powerflow solver

@martinmoraga the DCO is missing here ;-)


Fix Download  error when no file is found

Throw an exception and display popup message to user alerting them download failed

Codecov Report

Merging #624 (ed349b6) into master (a5f1eee) will increase coverage by 1.68%.
The diff coverage is 52.50%.

@@             Coverage Diff              @@
##             master     #624      +/-   ##
============================================
+ Coverage     59.88%   61.56%   +1.68%
- Complexity      541      630      +89
============================================
  Files           100      104       +4
  Lines          2064     2261     +197
  Branches        222      263      +41
============================================
+ Hits           1236     1392     +156
- Misses          736      749      +13
- Partials         92      120      +28

Impacted Files
Coverage Δ

...n/java/seedu/programmer/commons/core/Messages.java
0.00% <ø> (ø)

...in/java/seedu/programmer/commons/util/AppUtil.java
88.88% <ø> (ø)

.../seedu/programmer/commons/util/CollectionUtil.java
87.50% <ø> (ø)

...main/java/seedu/programmer/logic/LogicManager.java
38.46% <0.00%> (-8.42%)
:arrow_down:

...grammer/logic/commands/DashboardCommandResult.java
100.00% <ø> (+100.00%)
:arrow_up:

...ogrammer/logic/commands/DownloadCommandResult.java
100.00% <ø> (ø)

...u/programmer/logic/commands/ExitCommandResult.java
100.00% <ø> (ø)

...a/seedu/programmer/logic/commands/HelpCommand.java
100.00% <ø> (ø)

...u/programmer/logic/commands/HelpCommandResult.java
100.00% <ø> (ø)

...a/seedu/programmer/logic/commands/ShowCommand.java
92.85% <ø> (ø)

... and 80 more

Continue to review full report at Codecov.

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


Rebuilding the image from dockerfile on version 2.5.6

I have the following code:
const imageArm64 = new DockerImageAsset(this, 'myproject-arm64', {
            directory: './',
            file: 'myproject-arm64.docker',
            platform: Platform.LINUX_ARM64,
            exclude: ['cdk.out'],
            buildArgs: {
                BUILD_VERSION: MajorMinorVersion + '.' + process.env.CODEBUILD_BUILD_NUMBER,
            },
        });

new ecrdeploy.ECRDeployment(this, 'DeployDockerImageArm64', {
            src: new ecrdeploy.DockerImageName(imageArm64.imageUri),
            dest: new ecrdeploy.DockerImageName(`${props.env?.account}.dkr.ecr.${props.env?.region}.amazonaws.com/myproject:arm64-latest`),
        });

But when the pipeline builds, it generates two Docker Assets, one from DockerImageAsset which builds successfully and another one from the ECRDeployment which fails to build because it doesn't have the other build details I pass on the DockerImageAsset. As far as I understand, shouldn't the ECRDeployment just deploy the image to the dest repo? Why is it building again? I am using the cdk-ecr-deployment on version 2.5.6 and aws-cdk-lib on version 2.42.1

Closing since this is v2. If this still is an issue with v3, please open a new issue.


COFF_Affiliation_TDTM error - Message [hed.TDTM_CourseOffering: execution of AfterUpdatecaused by: System.ListException: List index out of bounds: 1(hed)]."

Issue identified via [CSG Case] (https://org62.lightning.force.com/one/one.app#/sObject/5000M00000haoMkQAI/view)
Based on conversation with @ceiroa yesterday:
The stack trace in the attached file doesn't really have any useful info. I think that's the internal stack trace.
Error loading into target [hed__Course_Offering__c] : Error received from salesforce.com. Fields []. Status code [CANNOT_MODIFY_MANAGED_OBJECT]. Message [hed.TDTM_CourseOffering: execution of AfterUpdatecaused by: System.ListException: List index out of bounds: 1(hed)].
Somewhere in TDTM_CourseOffering we are trying to read from an empty list.
There is only one class that runs on the Course_Offering__c object
(TDTM_CourseOffering is the trigger)
The class is COFF_Affiliation_TDTM
So somewhere in COFF_Affiliation_TDTM we are trying to read the first record from a list that doesn't have records
They could potentially fix it by changing the data they are loading, but very hard to figure out how to change it
It seems like a bug on our side, where we are not checking if the list is empty before trying to read from it

@ceiroa - can you please lurch this for me?

**lurch: add

Tracking W-019067

Included in beta release 1.38 (Beta 4)

Included in production release rel/1.38


pledge stdio, inet and dns on OpenBSD

I see the check fails because of Go 1.22. I can release an update to ossec that lowers the requirements if there is interest..

You meant go 1.20 no ? the CI uses 1.20 whereas we should only support 1.22 and 1.23 at this point.
Can't take care of this but feel free to push a pull request to update the github action so it either uses 1.22 or both 1.22 and 1.23, otherwise I'll do it tomorrow

Thanks !