Support deep objects for query parameters with deepObject style

Background
Many applications expect deeply nested objects in input parameters, see the discussion in swagger-ui starting from this comment: https://github.com/swagger-api/swagger-ui/issues/4064#issuecomment-357417513 In LoopBack, we are running into this problem too, see https://github.com/strongloop/loopback-next/pull/1679.
Consider a filter parameter defined as follows:
parameters:
 filterParam:
   in: query
   name: filter
   schema:
     type: object
   style: deepObject
   explode: true
   description: Options for filtering the results
   required: false

Let's say the user wants to provide the following value, for example by entering a JSON into the text area rendered by swagger-ui:
{
  "name": "ivan",
  "birth-date": {
    "gte": "1970-01-01"
  }
}

At the moment, the OpenAPI Specification v3 does not describe how to encode such value in a query string. As a result, OpenAPI clients like swagger-ui don't know how to handle this input - see the discussion in https://github.com/swagger-api/swagger-js/issues/1385 for an example.
Proposal
The following query string should be created by swagger-js client for the input value shown above.
filter[name]=ivan&filter[birth-date][qte]=1970-01-01

The proposed serialization style is supported by https://www.npmjs.com/package/qs, which is used by http://expressjs.com as the default query parser, which means that a vast number of Node.js API servers are already expecting this serialization style.
I am not sure if there is any existing formal specification of this format, I am happy to look into that once my proposal gets considered as acceptable in principle.
Additional information
Existing issues that are touching a similar topic:

style: form + object looses the parameter name? #1006
Are indexes in the query parameter array representable? #1501

Two older comments from swagger-js that may be relevant:
https://github.com/swagger-api/swagger-js/pull/1140

Limitations:
deepObject does not handle nested objects. The specification and swagger.io documentation does not provide an example for serializing deep objects. Flat objects will be serialized into the deepObject style just fine.

https://github.com/swagger-api/swagger-js/pull/1140#issuecomment-333017825

As for deepObject and nested objects - that was explicitly left out of the spec, and it's ok to just Not Support It™.

Are there any other examples of these nested deepObjects outside of Express? The more widespread a pattern, the more likely it is to be considered. Myself, I have an aversion to passing such a complicated object in the query string. Any insight into why Express even landed on this pattern?

We were a bit stuck when allowing the deepObject style.  We understood that users wanted this capability but there is no standard definition of what that serialization format looks like.  We had a few choices, allow it and define our own standard and hope implementations followed it.  Don't allow it because there are no standards, or add it in, say nothing about its format and hope that a default serialization format emerges.
If we can get some confidence that the qs package is becoming a defacto standard and we can create an accurate description of the serialization, then I have no issue recommending that we include that description in a future minor release of the spec.

What about the URL max length limits? I think one of the reasons why a standard for object serialization in the URL is hard to materialize is because of the URL max length problem, the URL just wasn't intended to pass data in this way.  Depending on the browser and/or server software being used the URL max length varies but in general it is small when compared to how much data can be transmitted with other methods like POST or PUT.  It certainly would work for small objects but people tend to inadvertently abuse these kinds of APIs by passing bigger than allowed payloads.

@rmunix regarding URL max length problems, I was very happy to see the HTTP SEARCH method draft RFC revived last month: https://tools.ietf.org/html/draft-snell-search-method-01

Are there any other examples of these nested deepObjects outside of Express? The more widespread a pattern, the more likely it is to be considered. Myself, I have an aversion to passing such a complicated object in the query string. Any insight into why Express even landed on this pattern?

http://esbenp.github.io/2016/04/15/modern-rest-api-laravel-part-2/
I use a modified version of https://github.com/esbenp/bruno referenced in the article above in a few apis, it's extremely useful for including related data and search filtering. I'm not really sure how to define those in a spec. I do appreciate that the url strings could get silly long to the point of failing if abused, but without this sort of thing searches and such would have to be actioned as POST requests or limited to basic GET request params.  It seems to me no ones really come up with a holy grail API solution for complex search queries so it's a bit of a free for all at the moment.

Ruby on Rails
Seems to use the same approach.
Reference: https://edgeapi.rubyonrails.org/classes/Hash.html#method-i-to_query
Source code: https://github.com/rails/rails/blob/b5302d5a820b078b6488104dd695a679e5a49623/activesupport/lib/active_support/core_ext/object/to_query.rb#L61-L86
Example code:
require "activesupport"

data = {
  "name" => "David",
  "nationality" => "Danish",
  "address" => {
    "street" => "12 High Street",
    "city" => "London",
  },
  "location" => [10, 20],
}
print data.to_query("person")

Produces the following query string, I have urldecoded and reformatted it for better readability:
person[address][city]=London&
person[address][street]=12+High+Street&
person[location][]=10&
person[location][]=20&
person[name]=David&
person[nationality]=Danish

Notice that array items are using an empty index, i.e. person[location][]=10, instead of person[location][0]=10.

Not API specific, but jQuery can generate nested array url params from objects.
http://api.jquery.com/jquery.param/

Arrrgh, hit that wall, too.... great example of a not so obvious limitation that might kill your whole project dev setup and workflow.

Ran into the same problem (using Rails), also with a parameter allowing for dynamic filtering.
The funny thing is, that swagger-editor does generate deeper nested objects as placeholder text for the parameters text area when clicking "try it out":
      - in: query
        name: filter
        schema:
          type: object
          properties:
            boolean_param:
              type: boolean
              nullable: true
            some_enum_of_types:
              type: array
              items:
                type: string
              nullable: true
          default: {}
        style: deepObject

results in
{
  "boolean_param": true,
  "some_enum_of_types": [
    "string"
  ]
}

which will be silently ignored. I know that this is actually a bug in swagger-editor, but it shows that it would be more consistent to allow deeper nested objects.

What needs to be done to move on with this @earth2marsh? You asked for a couple examples outside of Express, which I think have been provided in the messages above. I can help out writing some of the needed documents for this in a PR if that helps.

Does someone have a proposal of how we can fix the OpenAPI specification to allow it to tell tooling which flavour of deepNesting object serialization to use?
If someone wants to tackle this, here are some things to consider when creating the proposal:

Which serialization flavors exist?  Will they be enumerated in the spec?
Will it be required that all tooling support all flavours?
If not, what should tooling do when it hits a flavour it doesn't support?
Do we have commitment from tooling implementors to implement this feature?

Which serialization flavors exist? Will they be enumerated in the spec?

I hope I'm understanding what you're asking correctly, but based on the comments above
input
parameters:
 filterParam:
   in: query
   name: filter
   schema:
     type: object
   style: deepObject
   explode: true
   description: Options for filtering the results
   required: false

{
  "name": "ivan",
  "birthdate": {
    "gte": "1970-01-01"
  }
}

should result in
output
filter[name]=ivan&filter[birthdate][qte]=1970-01-01

The main difference seems to be in how nested arrays are handled. There seem to be slight differences between PHP, Node and Ruby on Rails.
Both PHP and qs* seem to favor the &numbers[0]=5&numbers[1]=10 syntax
$params = array(
  'filter' => array(
      'numbers' => array(5, 10)
  )
);

echo http_build_query($params);
// => filter%5Bnumbers%5D%5B0%5D=5&filter%5Bnumbers%5D%5B1%5D=10

var qs = require('qs');

var result = qs.stringify({
  filter: {
    numbers: [0, 10]
  }
});

console.log(result);
// => filter%5Bnumbers%5D%5B0%5D=0&filter%5Bnumbers%5D%5B1%5D=10

In normal non-nested use the Node built-in querystring and Swagger favor &numbers=5&numbers=10:
var querystring = require("querystring");

var result = querystring.encode({
  numbers: [5, 10]
});

console.log(result);
// => numbers=5&numbers=10

Combined by the comment @bajtos' comment about Ruby's implementation, this leaves us in a scenario where there are three different outputs for this given input for filter:
{
  "name": "ivan",
  "birthdate": {
    "gte": "1970-01-01"
  },
  "numbers": [5, 10]
}

&filter[name]=ivan
&filter[birthdate][gte]=1970-01-01
&filter[numbers]=5
&filter[numbers]=10

&filter[name]=ivan
&filter[birthdate][gte]=1970-01-01
&filter[numbers][0]=5
&filter[numbers][1]=10

&filter[name]=ivan
&filter[birthdate][gte]=1970-01-01
&filter[numbers][]=5
&filter[numbers][]=10

Seeing that different languages and implementations are already out there, I don't think we can pick one over the other. (Eg PHP's parse_str doesn't work with 1, while Ruby's won't parse 2).
qs seems to support all three of these flavors in parsing.
Re: your comment Oct 29 2018

If we can get some confidence that the qs package is becoming a defacto standard and we can create an accurate description of the serialization, then I have no issue recommending that we include that description in a future minor release of the spec.

Seeing the ~22 million weekly downloads, I think it's safe to say that qs has become the defacto query string parser in Node JS.
I don't know enough about the governance of the project nor the extended OpenAPI family of projects to make any comments about the other questions mentioned.

I concur and second, @rijkvanzanten...
&filter[name]=ivan
&filter[birthdate][gte]=1970-01-01
&filter[numbers][]=5
&filter[numbers][]=10

This format is rather important! It would allow for an array of arrays (PHP) or an array of objects (Node).

Couldn't query params be defined in the same way as body objects by specifying a schema?  I'll add my thought about serialization after the example.
So, as an example:
params = {
  some_query_object: {
    hello: "world",
    foo: [
      { value: "blerg" },
      { value: "blah" }
    ],
    bar: [1, 2, 3]
  }
}

jQuery.param(params)

Serializes to this query string:
 some_query_object[hello]=world
&some_query_object[foo][0][value]=blerg
&some_query_object[foo][1][value]=blah
&some_query_object[bar][]=1
&some_query_object[bar][]=2
&some_query_object[bar][]=3

And, I would expect to be able to write something like this:
paths:
  "/api/example":
    post:
      produces:
        - application/json
      parameters:
        - name: some_query_object
          in: query
          description: The object in the query string
          required: false
          schema:
            "$ref": "#/definitions/some_query_object"
definitions:
  some_query_object:
    type: object
    properties:
      hello:
        type: string
      foo:
        type: array
        items:
          "$ref": "#/definitions/nested_object"
      bar:
        type: array
        items:
          type: string
  nested_object:
    type: object
    properties:
      value:
        type: string

In regards to query string serialization, the only case OpenAPI really needs to account for is the various array assignment types (The python example above is clearly type: string so can be ignored).
I would suggest adding a single option arrayAssignmentType.
It only applies to arrays.  Not objects/maps.
I'm not sure if it should be a global option or per property.  Global should be fine as its generally enforced by frameworks/libraries.
arrayAssignmentType would have the the following options:
direct (or traditional like in jQuery param docs), where the values are assigned directly to the key:
item=a&item=b
OR
obj[item]=a&[item]=b

accessor, where values are assigned via an [] or [int] accessor:
item[]=a&item[]=a
OR
obj[item][1]=a&item[2]=b
OR
obj[item][]=a&obj[item][]=b
OR
obj[item][1]=a&[item][2]=b
OR
obj[][value]=a&obj[][value]=b
OR
obj[1][value]=a&obj[2][value]=b

The naming can be worked out later.
In regards to the accessor option, it would be interesting to see if various frameworks support both formats ([]  vs [1]).  I would expect the answer is both based on how JQuery serializes params:
$.param({ a: [1, 2, 3] })
"item[]=1&item[]=2&item[]=3 "

$.param({ item: [{ x: 'a' }, { x: 'b'}, { x: 'c'}] })
"item[0][x]=a&item[1][x]=b&item[2][x]=c"

I think the default value should be arrayAssignmentType: accessor just because that format is more explicit in how arrays are defined (...also "to accommodate modern scripting languages and frameworks such as PHP and Ruby on Rails" — jQuery docs lols)

Ok, I just tested how Rails handle the different array accessors in the query string:
?item=1&item=2&item=3
# { 'item' => '3' }

?item[]=1&item[]=2&item[]=3
# { 'item' => ['1', '2', '3'] }

?item[1]=1&item[2]=2&item[3]=3
# { 'item' => { '1' => '1', '2' => '2', '3' => '3' } }

So, @darrelmiller, following on from my previous comment, perhaps there can be 4 options for arrayAssignmentType... direct (or traditional), emptyAccessor, numericAccessor, dynamicAccessor.  Again, the naming is up for debate, it's more about the concept.
Likewise, perhaps arrayAssignmentType should be both a global option and a per-property option, to account for all scenarios.

Thank you all for pushing this discussion forward ❤
@br3nt's proposal seems very reasonable to me.

perhaps there can be 4 options for arrayAssignmentType... direct (or traditional), emptyAccessor, numericAccessor, dynamicAccessor. Again, the naming is up for debate, it's more about the concept.

It's not clear to me what is the difference between numericAccessor and dynamicAccessor, but that's a minor detail that can be figured out while working on the actual spec proposal.

perhaps arrayAssignmentType should be both a global option and a per-property option, to account for all scenarios.

+1
Do we want this option to be per-property (i.e. inside a schema definition) or per-parameter (i.e. inside an operation parameter definition)?
I prefer the later.
If we allow arrayAssignmentType on per-property basis, then we can end up with different properties using different array assignment types. That feels too complicated to me.
?q[hello]=world
# arrayAssignmentType: numericAccessor
&q[foo][0]=blerg
&q[foo][1]=blah
# arrayAssignmentType: emptyAccessor
&q[bar][]=1
&q[bar][]=2
&q[bar][]=3

Anyhow, if there is a need for this extra complexity, then perhaps we can allow arrayAssignmentType at three levels?

global
specific to an operation parameter
specific to a property in a schema

The part important for me is that property-level or parameter-level setting should overwrite any globally-defined setting.

Thanks everyone for the input here.  This is exactly the type of information we needed, but didn't have when were originally defining the deepObject style.
I am a little concerned about the potential complexity for tooling to support a range of different formats, especially now we are talking about defining it at different levels and allowing overloading.  I wonder if this is unnecessary complexity.
There are two major use-cases for being able to define how an object is serialized in the query string.

In client tooling where it is necessary to construct a URL so an API can be called.
In server side tooling to parse a URL and reconstruct a parameter value as an object.

If we go down the path of creating configuration parameters that reflect how a particular library/language/platform does the serialization then we are leaking implementation details through the OpenAPI description.  This is somewhat defeating what OpenAPI is trying to do.
There doesn't seem to be a big a variation in formats as I once believed and I wonder if there is value in OpenAPI just picking the most compatible format and completely specifying it.  From what I can tell it would be possible for us to add wording to the specification that would allow us to say deepObject follows these rules:
A parameter named q that has a value that looks like this,
{
    hello: "world",
    foo: [
      { value: "blerg" },
      { value: "blah" }
    ],
    bar: [1, 2, 3]
  }

would serialize as
? q[hello]=world&q[foo][0][value]=blerg&q[foo][1][value]=blah&q[bar][0]=1&q[bar][1]=2&q[bar][2]=3

This assumes that all numeric keys are references to elements of an array and all textual keys are references to elements of a map.  The keys could be optionally quoted to allow keys for maps to be numbers.
The use of the empty indexer seems problematic to me because URL query parameters usually do not have an order that is semantically significant but array values usually are ordered.
If we assume most frameworks support both the numeric accessor and the empty accessor, then limiting deepObject to just using the numeric accessor should provide reasonable compatibility.  It does appear this would be a problem for Rails.  Some kind of OpenAPI specific parser would be needed to support the deserialization process.  However, whichever format we pick, one or more platforms are going to have to do work to support it.
I do think that having a few platforms need to build libraries to conform to a consistent approach is a better long term outcome than creating a parameterization system that effectively describes the platform.  If we did that we might as well create styles for rubyDeepObject, phpDeepObject, nodeDeepObject
I do however recognize there is a need to retroactively describe an API that has selected a non-standard serialization format.  There is a solution to that.  Instead of using the style parameter which is designed to be quick an easy way to identify a common serialization style, you can use content and a media type.
parameters:
  - name: q
    content:
      application/vnd.ruby.deepObject: {}

The purpose of media types is to describe semantics, syntax and serialization of data going over the wire.  Normally, they are used for request and response bodies.  However, OpenAPI allows defining a content object for parameters also.  This also allows defining a schema if it is necessary to identify if a particular property is an object or an array when the syntax in the URL does not disambiguate.
In the past I was not a fan of OpenAPI picking a winner when it comes to the serialization format.  However, considering the impact of the alternative approach, I have to wonder if it is the right thing to do.   How would people feel if OpenAPI explicitly described a format for deepObject and required using content and a custom media type to describe parameters that don't match that standard?

Hey guys,
I've been ready & trying different things for some time now, but can't get the standard JSONAPI sparse fieldsets params to work with swagger-ui...
JSONAPI specifies a way to fetch only required attributes of the included resources. E.g.:
fields[resource1]=attrib1,attrib2,attrib3&fields[resource2]=attrib1
// example:
fields[person]=first_name,last_name,age&fields[address]=city,full_address,latitude,longitude

This all works for my endpoints, but no matter how I format the payload I enter in SwaggerUI and/or setup the swagger JSON, I can't get it to work...
For example, using the endpoint(s) works like that:
curl -X GET "http://localhost:5000/person/39?include=address,address.country&fields[person]=first_name,last_name,age&fields[address]=city,full_address,latitude,longitude"

Tried different swagger JSON setups (e.g.with deepObject etc), and payloads in the swagger-ui text field (e.g.: {person: "first_name,last_name,age", address: "city,full_address,latitude,longitude"}), but no success for now...
Part of the complication is that the object / hash keys (model / resource name) are dynamic: they depend on the included resources (in the compound document) and I can't statically describe the schema definition.
Any ideas? Help is appreciated!
PS: Using Grape (https://github.com/ruby-grape/grape/) and the Netfix fast_jsonapi (https://github.com/Netflix/fast_jsonapi).

@darrelmiller, picking one format rather than a more versatile solution will do more harm than good.
It will alienate the frameworks that don't support whatever format is chosen.  Using the example of numeric array accessors...
ASP.NET apps would be excluded as they use what I described as direct or traditional style array assignment.  ASP.NETs qs format is more similar to:
?q.hello=world&q.foo.0.value.=blerg&q.foo.1.value=blah&q.bar=1&q.bar=2&q.bar=3

JS frameworks which use the qs library, like ExpressJS and LoopBack, will also be excluded.  As per the qs documents:

Any array members with an index of greater than 20 will instead be converted to an object with the index as the key. This is needed to handle cases when someone sent, for example, a[999999999] and it will take significant time to iterate over this huge array.

E.g:
?foo[21]=bar
{"foo":{"21":"bar"}}

However, qs supports both the direct or traditional style and the emptyAccessor.  E.g:
?foo=bar&foo=baz
{"foo":["bar","baz"]}

?foo[]=bar&foo[]=baz
{"foo":["bar","baz"]}

Would tooling implements be expected to parse foo[21] as an array or a map? Is that fair?  Why stop at 20?  It's kind of arbitrary.  At least the empty array accessor [] is consistent.  It's always an array which gets populated based on the order of the query string.
PHP apps would be fine as PHP arrays work basically like hashes/maps.
Picking one option over another tells frameworks that their decisions are right or wrong. I don't think that's the job of OpenAPI Specifications.  A better place to decide on standardization would be in a W3C proposal where the community could come to a consensus together.
Your concern about additional complexity is fair enough.  However, I think using only content media types sweeps the problem under the rug a little.  Small frameworks would be disadvantaged by this decision.
I think it reasonable to expect some minimum support from OpenAPI Specification for the array accessor styles of foo[]=a, foo[0]=a and foo=a&foo=b and it's not unreasonable to expect tooling implementers to support these three styles.
I think it would also be reasonable to assume that most (if not all) frameworks would offer consistent array accessor parsing functionality.  As such a global option specifying array accessor styles would be sufficient to tell tooling which to use (rather than on a per-property or per-path basis which I agree is way too complex).
I don't think the above could be considered as leaking framework functionality into the OpenAPI-Specification.
Anything more complex than the above, then I also agree that content media types would be a good solution.

My apologies for not responding for while.  This may seem to be to simplistic considering the complexity of other comments, but what if content (each qs param value)  be subject to JSON.parse/JSON.stringify subject to URL/URI decoding/encoding as needed with whitespace removal.
For example:
{
"name": "ivan",
"birthdate": {
"gte": "1970-01-01"
},
"numbers": [5, 10]
}
can have whitespace removed as
{"name":"ivan","birthdate":{"gte":"1970-01-01"},"numbers":[5,10]}
encoded as
?param1=%7B%22name%22%3A%22ivan%22%2C%22birthdate%22%3A%7B%22gte%22%3A%221970-01-01%22%7D%2C%22numbers%22%3A%5B5%2C10%5D%7D
It may be possible that only certain characters need to be encoded (e.g. ampersand as %26)

param1=%7B%22name%22%3A%22ivan%22%2C%22birthdate%22%3A%7B%22gte%22%3A%221970-01-01%22%7D%2C%22numbers%22%3A%5B5%2C10%5D%7D

Thats pretty much the same as defining param1 as a string then decoding and objectifying the string which is how I'm getting around the issue for now.
The problem with that approach is there's no way in the spec to tell what a valid object/array would be for param1 or that param1 should even be an object/array.

param1=%7B%22name%22%3A%22ivan%22%2C%22birthdate%22%3A%7B%22gte%22%3A%221970-01-01%22%7D%2C%22numbers%22%3A%5B5%2C10%5D%7D

In LoopBack, we support both style. When the parameter is described as array or object with style: deepObject, then:

First, we let qs to parse [] notation into an object or an array. If this returns an object value then we are done.
Otherwise if the query provides a string value, then we deserialize the value from JSON.

See https://github.com/strongloop/loopback-next/blob/d1eef59928fe8afb56e8bfce3d04e1e3a656ae2b/packages/rest/src/coercion/coerce-parameter.ts#L169-L200

The problem with that approach is there's no way in the spec to tell what a valid object/array would be for param1 or that param1 should even be an object/array.

Yes, the spec does not provide any means how to express this style. However, I can imagine adding e.g. a new style variant to describe JSON-serialized values.
For example:
   in: query
   name: filter
   schema:
     type: object
   style: json
   description: Options for filtering the results
   required: false

Yes, the spec does not provide any means how to express this style. However, I can imagine adding e.g. a new style variant to describe JSON-serialized values.
For example:
   in: query
   name: filter
   schema:
     type: object
   style: json
   description: Options for filtering the results
   required: false

Something like that would be useful, I wonder if it could be expanded to somehow use a schema for validity of the JSON object?

@ewrayjohnson

what if content (each qs param value) be subject to JSON.parse/JSON.stringify subject to URL/URI decoding/encoding as needed with whitespace removal.
For example:
{
  "name": "ivan",
  "birthdate": {
    "gte": "1970-01-01"
  },
  "numbers": [5, 10]
}

can have whitespace removed as
{"name":"ivan","birthdate":{"gte":"1970-01-01"},"numbers":[5,10]}

encoded as
?param1=%7B%22name%22%3A%22ivan%22%2C%22birthdate%22%3A%7B%22gte%22%3A%221970-01-01%22%7D%2C%22numbers%22%3A%5B5%2C10%5D%7D

I believe this particular use case is already covered by the content keyword instead of schema/style/explode.
parameters:
  - in: query
    name: param1
    content:
      application/json:
        schema:
          type: object
          properties:
            name:
              type: string
              example: ivan
          ...

This would be using this feature extensively. We have many use cases where the user needs this feature

To be able to document things, I've been using the following, which is not ideal:
parameters:
  - schema:
    type: string
  in: query
  name: 'filter[search][eq]'

This is a particular problem with standards like jsonapi.org.

@kurko What problems did you have with this flat-nested-syntax (name : 'filter[search][eq]') ?
I am doing the same. The only problem I have had with this so far was that we cannot use anyOf when using this flat naming scheme compared when using a real object. Other than that, I would prefer using that syntax, because it is shorter.

@ahx you won't be able to use tools to automatically validate your requests, unless they cast the string into some sort of dictionary/hash/object. For instance, with Ruby (I'm trying out Committee gem for request validations), that spec would be converted to { "filter[search][eq]" => "value" } (note the string as key) whereas in fact it would need to be:
{
  filter: {
    search: {
      eq: "value"
    }
  }
}

I have to check whether none of the tools I'm using isn't trying to hack this and convert to an object. Haven't got to that point yet in development.

@kurko Hey, I am also using Ruby 🚀 This is a known issue for committe, but this was solved in [openapi_first](https://github.com/ahx/openapi_first) (which is an alternative to committee created by myself 👋 )

We needed to support filters like these in our API, so I've written this code:
https://github.com/PaulWay/django_filter_deep_object_param
It's kind of a copy and paste, and I'm still working on tests and better documentation.  But hopefully that can be a basis of some of the work to support deep object querying.  I'm also completely open to any suggestions on how to do this better :smile:
It works for us particularly because PostgreSQL 11 and above support deep querying into JSON objects, but it also supports queries through Django relationships.

We needed to support filters like these in our API, so I've written this code:
https://github.com/PaulWay/django_filter_deep_object_param
It's kind of a copy and paste, and I'm still working on tests and better documentation.  But hopefully that can be a basis of some of the work to support deep object querying.  I'm also completely open to any suggestions on how to do this better :smile:
It works for us particularly because PostgreSQL 11 and above support deep querying into JSON objects, but it also supports queries through Django relationships.

The double underscore delimiter is not foolproof when properties/relations contain leading or trailing underscores.  I suggest a character not valid in loopback property/relation names but valid in url query string preferably without encoding (possibly a tilde or believe it or not a period).  Caveat:  All this is just off the top of my head late at night with no research.

Good thinking @ewrayjohnson - good checks to do.
This cannot prevent possible exploration of the database schema using Django's relations, and there are security implications.  It all depends on the field you're querying and how you're expressing your relations in Django.

In JSON:API, we would like do design QueryParam filter like this and https://github.com/json-api/json-api/issues/1445:
GET /authors?page[articles][offset]=10&page[articles][limit]=5 <-- Nested object

GET /comments?filter[post]=1,2&filter[author]=12 <-- Primitive array inside the object

So:

I think nested object is useful for more powerful API design
About the primitive array inside deep objects, as this comment said, we should fine some way to let users customize the representation

In JSON:API, we would like do design QueryParam filter like this and https://github.com/json-api/json-api/issues/1445:
GET /authors?page[articles][offset]=10&page[articles][limit]=5 <-- Nested object

GET /comments?filter[post]=1,2&filter[author]=12 <-- Primitive array inside the object

So:

I think nested object is useful for more powerful API design
About the primitive array inside deep objects, as this comment said, we should fine some way to let users customize the representation

Spring also supports deep objects using dot-notation, i.e. GET /authors?page.articles.offset=10&page.articles.limit=5
When going forward with this proposal, what would be a really great addition would be the option to skip the root parameter name. This would neatly solve #445:
paths:
  /pageable-endpoint:
     get:
         parameters:
            - name: query
               in: query
               schema:
                   type: string
            - name: page
               in: query
               required: false
               schema:
                   $ref: '#/components/schemas/Page'
               # option to skip 'page' in the effective query parameter name here
               style: deepObject
components:
   schemas:
      Page:
         type: object
         properties:
           page:
              type: integer
           items:
              type: integer

could result in
GET /pageable-endpoint?query=foo&page=5&items=100

instead of
GET /pageable-endpoint?query=foo&page.page=5&page.items=100

@creckord

When going forward with this proposal, what would be a really great addition would be the option to skip the root parameter name. This would neatly solve (some aspects of) #445:
...
could result in
GET /pageable-endpoint?query=foo&page=5&items=100

This particular example is already supported by style: form + explode: true (which is the default style for query params) rather than deepObject.

@hkosova

This particular example is already supported by style: form + explode: true (which is the default style for query params) rather than deepObject.

Ah, good to know. Then it's just the Java+okhttp client generator that does not support this particular style.
What would happen with that style if the Page schema had nested object-type properties?

@creckord

What would happen with that style if the Page schema had nested object-type properties?

Undefined behavior / not supported.
Nested structures should ideally be handled by deepObject, which is what this discussion is about.

Hi,
On a project I'm working on, we are trying to encore these filters.
We tried style: form, explode: true and style: deepObject, explode: true without luck.
{
  persona: [
    'positionner_1er',
    'vendre',
    'selectionner',
    'maximiser',
    'positionner_2e'
  ],
  type: [ 'programme', 'parcours', 'activite', 'capsule' ],
  theme: [
    'ressources-humaines',
    'numerique',
    'marketing-com',
    'vente',
    'finance',
    'gestion',
    'innovation'
  ],
  difficulte: [ 'avance', 'debutant', 'intermediaire' ],
  region: [
    'outaouais',
    'mauricie',
    'bas-saint-laurent',
    'laurentides',
    'province-du-quebec',
    'abitibi-temiscamingue',
    'capitale-nationale',
    'montreal',
    'centre-du-quebec',
    'chaudiere-appalaches',
    'cote-nord',
    'estrie',
    'gaspesie-iles-de-la-madeleine',
    'lanaudiere',
    'laval',
    'monteregie',
    'nord-du-quebec'
  ],
  duree_intervalle: [ '*-3600', '3600-10800', '10800-28800', '28800-230400', '230400-*' ],
  dispo_dans_catalogue: true
}

We need an encoding like this:
filters[persona][]=positionner_1er&filters[persona][]=vendre&filters[persona][]=selectionner&filters[persona][]=maximiser&filters[persona][]=positionner_2e&filters[type][]=programme&filters[type][]=parcours&filters[type][]=activite&filters[type][]=capsule&filters[theme][]=ressources-humaines&filters[theme][]=numerique&filters[theme][]=marketing-com&filters[theme][]=vente&filters[theme][]=finance&filters[theme][]=gestion&filters[theme][]=innovation&filters[difficulte][]=avance&filters[difficulte][]=debutant&filters[difficulte][]=intermediaire&filters[region][]=outaouais&filters[region][]=mauricie&filters[region][]=bas-saint-laurent&filters[region][]=laurentides&filters[region][]=province-du-quebec&filters[region][]=abitibi-temiscamingue&filters[region][]=capitale-nationale&filters[region][]=centre-du-quebec&filters[region][]=chaudiere-appalaches&filters[region][]=cote-nord&filters[region][]=estrie&filters[region][]=gaspesie-iles-de-la-madeleine&filters[region][]=lanaudiere&filters[region][]=laval&filters[region][]=monteregie&filters[region][]=nord-du-quebec&filters[duree_intervalle][]=%2A-3600&filters[duree_intervalle][]=3600-10800&filters[duree_intervalle][]=10800-28800&filters[duree_intervalle][]=28800-230400&filters[duree_intervalle][]=230400-%2A

But all with deepObject our params end-up overwritting each other:
filter[persona]=positionner_1er&filter[persona]=vendre&filter[persona]=selectionner&filter[persona]=maximiser&filter[persona]=positionner_2e&filter[type]=programme&filter[type]=parcours&filter[type]=activite&filter[type]=capsule&filter[theme]=ressources-humaines&filter[theme]=numerique&filter[theme]=marketing-com&filter[theme]=vente&filter[theme]=finance&filter[theme]=gestion&filter[difficulte]=avance&filter[difficulte]=debutant&filter[difficulte]=intermediaire&filter[region]=outaouais&filter[region]=mauricie&filter[region]=bas-saint-laurent&filter[region]=laurentides&filter[region]=province-du-quebec&filter[region]=abitibi-temiscamingue&filter[region]=capitale-nationale&filter[region]=centre-du-quebec&filter[region]=chaudiere-appalaches&filter[region]=cote-nord&filter[region]=estrie&filter[region]=gaspesie-iles-de-la-madeleine&filter[region]=lanaudiere&filter[region]=laval&filter[region]=monteregie&filter[region]=nord-du-quebec&filter[duree_intervalle]=*-3600&filter[duree_intervalle]=3600-10800&filter[duree_intervalle]=10800-28800&filter[duree_intervalle]=28800-230400&filter[duree_intervalle]=230400-*&filter[dispo_dans_catalogue]=true&sort=created_at&append=pourcentage_complete

Just chiming in, that on https://github.com/GetDKAN/dkan we have settled on what I guess I'll call "qs style" serialization for complex GET requests. FWIW this style essentially has native support in PHP and additional support in core Symfony libraries. Struggling with the same issues as everyone, probably going to add some minimal parameters and just add narrative text for now, pointing people to the JSON schema and suggestions for how to serialize.

Five years later, this feature request is still relevant. Any news on this ?

waiting for "qs style" serialization feature

@mbraz You are waiting for the feature in what tooling? Docs, testing, code generators?  Here's how you could describe it in the specification.
parameters:
 filterParam:
   in: query
   name: filter
   schema:
     type: object
   style: deepObject
   x-deepObject-style: qs
   explode: true
   description: Options for filtering the results
   required: false

I just made that extension up.  That's how we are going to move forward here.
The best way to get a feature into the specification is to propose an extension to a tooling creator, or PR a tool with support.  Adoption of the the extension will be what demonstrates the value and allows us to bring the feature into the specification.
If you really don't want to go the extension route, you could do this as an alternative.
parameters:
 filterParam:
   in: query
   name: filter
   content:
     text/vnd.qs-serialization: {}
   description: Options for filtering the results
   required: false

In this case I invented a new text based media type for describing the contents of the filter value.  Media types are not usually used for describing query parameter values, but it is technically allowed by OAS.

Hi, wait in swagger to use in NestJS applications. I'll try
text/vnd.qs-serialization...
Em dom., 5 de mar. de 2023 às 14:34, Darrel @.***>
escreveu:

@mbraz https://github.com/mbraz You are waiting for the feature in what
tooling? Docs, testing, code generators? Here's how you could describe it
in the specification.
parameters:
filterParam:
in: query
name: filter
schema:
type: object
style: deepObject
x-deepObject-style: qs
explode: true
description: Options for filtering the results
required: false
I just made that extension up. That's how we are going to move forward
here.
The best way to get a feature into the specification is to propose an
extension to a tooling creator, or PR a tool with support. Adoption of the
the extension will be what demonstrates the value and allows us to bring
the feature into the specification.
If you really don't want to go the extension route, you could do this as
an alternative.
parameters:
filterParam:
in: query
name: filter
content:
text/vnd.qs-serialization: {}
description: Options for filtering the results
required: false
In this case I invented a new text based media type for describing the
contents of the filter value. Media types are not usually used for
describing query parameter values, but it is technically allowed by OAS.
—
Reply to this email directly, view it on GitHub
https://github.com/OAI/OpenAPI-Specification/issues/1706#issuecomment-1455153914,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA23VEFTQ4RDD3XPBOU4H5DW2TFDTANCNFSM4F257XBQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

I think the simplest way to allow folks to experiment with different approaches would be to implement #1502 (Support for arbitrary query strings).  That would let folks define entirely custom serialization, perhaps based on media types as @darrelmiller suggests, without having to work around the spec's mechanisms for supporting more common serialization forms.

https://github.com/abbasudo/laravel-purity
This is extremely necessary! I can't convert to format query parameter
filters[is_publish][$contains]=true

@POMXARK let's keep it respectful, the maintainers don't owe you anything. You're welcome to submit a PR or make and share a third-party package if this is so important to you, we're all just doing our best here.
FWIW I'm not a JS developer but I would still strongly vote for standardizing around "qs style" as it's very intuitive and close enough to other serialization methods to work with in different languages. It should be recognized though that there is really no way to do nested query objects in a GET query string that will be straightforward to document.

@dafeder thanks for your comment!

It should be recognized though that there is really no way to do nested query objects in a GET query string that will be straightforward to document.

Yeah, this is why I'm pushing for #1502 in version 3.2 of the spec.  It's not ideal, but it gets the OpenAPI spec details out of the way and lets folks do their own serialization for the entire query string, including by just setting the whole thing to content: {application/x-www-form-urlencoded: {...}} and serializing the way we do application/x-www-form-urlencoded bodies.  Which would also allow creating 3rd-party extensions to handle alternate query string formats, which is not possible right now because there is no place in any Object where you could easily put such an extension.

Any updates on this?

@DustinCai see my comment above about 3.2.  We're getting 3.0.4 and 3.1.1 out the door right now, then 3.2 should be a relatively quick release is we want to keep it small (and then do a 3.3 if 3.2 is well-received).  I'd hoped to get 3.2 done by the end of the year, but 3.0.4 and 3.1.1 have taken a bit longer so maybe January or (hopefully) at worst February.
I know that solution (#1502) might not be what you're looking for, but there are too many possible different formats and too many competing demands.  Allowing people to define their own query string formats (media types) for the whole query string will unblock experimentation, particularly if combined with a media type registry per #3771.

Is there actually a situation where someone wants the query parameter specified as a deepObject to be keys with url encoded values that are themselves JSON? I feel like I'm misunderstanding the issue, because I've never heard of that as being something that anyone actually wants. foo[bar][baz]=buz has been the standard way of encoding "nested" query parameters for pretty much my entire career. At a minimum, it would serve every modern web setup better if that was the one option chosen as opposed to foo=%7B%22bar%22:%20%22buz%22%7D which is just wildly strange to me.
The other flaw with that is that it's ambiguous. For instance, our filters support name="{Fred" and name[eq]="Fred". But I can't tell if the user is actually typing json into the search box, to look for a thing with the name {"eq": "Fred"}, or if they are asking for the thing with the name equal to "Fred". So I can't even add server side logic to properly handle this.
If the default was foo[bar]=baz, I could detect which format was which, translating that to foo={"bar": "baz"} in some preprocessor.
I think I must be understanding because I can't really conceive of how thousands of other people haven't hit on this same issue up to now. Is there a solution I'm not aware of?

@zachdaniel it's mostly that deepObject is intentionally under-specified, which was intended to allow experimentation and possibly future expansion.  But there isn't really an obvious way to have tools try out different things here.
In any event, please take a look at the just-released-yesterday 3.0.4 (release notes) and 3.1.1 (release notes) releases, as they both contain a substantial rewrite and dramatic expansion (with multiple new appendices added to the spec) of the parameter and form serialization rules.

Will check it out. I also may have been wrong about the form style. I think I still haven't figured out how to get the format I'm looking for yet.

I still don't see something hinting at what, to me, would be the most common option. What is the way to tell it that a query parameter with nested schemas should be encoded as foo[bar][baz]=buz. I cannot find it. Or are you saying there is just no standard way to do this and individual tools (swagger UI) in this case will just do whatever they want?

I get it from the spec perspective, but ultimately as someone maintaining a framework offering automatic swagger UI generation, this one singular sticking point issue is causing users to decide not to use swagger UI at all. It has (for them) a sort of all-or-nothing effect because they want to expose this to API consumers. I may be able to figure something out along the lines of detecting a request coming through swagger UI's "try it out" feature (maybe some way to put in a header to all of those requests for example), which would allow me to then do special query parameter decoding.
I think I'm primarily taking umbrage with SwaggerUI at this point, not the spec. I can't imagine a world where anyone wants a query parameter to be URI encoded JSON. I get it that it's unspecified, but thats a weird choice. Not much left to do here on this issue, and looking forward to a resolution to #1502 as potentially opening a path here.

I think I'm primarily taking umbrage with SwaggerUI at this point, not the spec.

Yeah we can't help you with that, I'm afraid!

I can't imagine a world where anyone wants a query parameter to be URI encoded JSON.

Oh, I've seen it.  I can't say I'd recommend it, but I've definitely seen it.  I've also seen JSON documents embedded in JSON strings.  People do some astonishing things...

EDIT: nevermind, that won't work either because I still can't tell the difference between the value being a string of valid JSON and a query parameter encoded by swagger UI 😢

I'm not quite sure where the JSON complaint comes in, though.  Is SwaggerUI treating deepObject as an instruction to encode like JSON?  It is definitely not supposed to do that.

As far as I can tell, it's when I have a deepObject where a value is an object. It ends up encoded as field="{"some": "json"}"

@zachdaniel huh.  Well, the spec does not define behavior for that case, so on the one hand, we can't say that's wrong.  But also if they've chosen to do that, that's thier own decision and they don't need anything from us if they want to make a different decision.  As far as the spec is concerned,  the behavior of deepObject with properties that are themselves objects or arrays is undefined, so anything that a tool does is entirely under their own control (and unlikely to be portable).

@zachdaniel although if this is an application/x-www-form-urlencoded request body, they might be applying the Encoding Object's logic for serializing JSON objects as embedded JSON?  That's the only thing I can think of that might be going on (and, despite having extensively researched and mostly re-written that entire part of the spec over the last few months, i can't recall exactly how those requirements would interact).


Can you tell me what the 'anchor_path' variable means in train.py file? when I want to train my dataset , what should I write in the anchor file? thanks

I think that means the structure of the CNN，it has another file named tiny_yolo_anchors wich represent a smaller model.


Added render_unmentioned_fields attribute to FormHelper

Hi Andrew,
After checking your code I found that what you were doing wasn't actually right in what I would expect render_unmentioned_fields to do. I've added a patch in dev branch that renders fields not mentioned in the layout, no matter if there is a Meta class or not defined. Feel free to test it and give me feedback on it.
Cheers, thanks
Miguel


Docker image 'nanoserver-insider-powershell': Documentation outdated or image problem

Steps to reproduce
The docs here state the following example:
docker run -it microsoft/nanoserver-insider-powershell 'C:\program files\powershell\powershell' -c '$psversiontable'

Expected behavior
Advertised example works and displays version information.
Actual behavior
docker: Error response from daemon: container 204a5e6784a7f7bbadc8095b72efb518475121a0277f3d3e566e46856e8ec921 encountered an error during CreateProcess: failure in a Windows system call: The system cannot find the file specified. (0x2) extra info: {"CommandLine":"'C:\\program files\\powershell\\powershell' -c '$psversiontable'","User":"ContainerUser","WorkingDirectory":"C:\\","Environment":{"PSCORE":"C:\\Program Files\\PowerShell\\PowerShell.exe","ProgramFiles":"C:\\Program Files"},"EmulateConsole":true,"CreateStdInPipe":true,"CreateStdOutPipe":true,"ConsoleSize":[30,120]}.

PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

I am using a physical PC with Windows 10 Pro - April 2018 Update (version 1803 build 17134.1).
My Docker version is the one I posted above.
In my post I was using PowerShell.
On CMD we have to change the syntax a bit (cmd doesn't understand ' to enclose arguments):
C:\>docker run --rm -it microsoft/nanoserver-insider-powershell "C:\program files\powershell\powershell" -c "$psversiontable"
WARNING: Appended Windows PowerShell PSModulePath

Name                           Value
----                           -----
PSVersion                      6.0.0-beta
PSEdition                      Core
GitCommitId                    v6.0.0-beta.5
OS                             Microsoft Windows 10.0.16257
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

Thanks @mlocati The single quotes in cmd.exe were the problem, I kept using cmd.exe to avoid having to decorate the sample script from the PSSA issue with double single-quotes for escaping. Sorry, this was my fault, I should've remember this gotcha.


Hide the attached live preview window when the detached live preview is opened

This is part of #189. We need to add functionality that will hide the attached preview when the detached live preview is open. When the attached live preview is hidden it should still be updated as the document changes.

Fixed with https://github.com/AJDBenner/brackets-browser-livedev/pull/5


Ported Acey-Ducey to Pascal

Hey Jeff (@coding-horror),
Would you be willing to include Pascal as an option?
If so, many thanks!!
I'll also be attempting to port it into both Pascal and ObjectPascal.
Cheers,
Gus

Well, the idea was to port the code to modern, living languages -- not totally sure Pascal fits that bill?

Hey Jeff (@coding-horror),
Humm, I was kinda hoping that you were a bit more informed of the reach that Delphi and Free Pascal/Lazarus have.
I'm aware it's not the new kids mojo, but there is still loads of interest in Object Pascal through both Delphi and FPC/Lazarus.
And with FPC/Lazarus being able to compile to, almost, every architecture under the sun, it's getting more relevant.
But, it's your final decision and if you say you don't want it, I'll be ok with it. Just, please, don't blame it on a very dated notion that Pascal is dead (And right on the 26th anniversary of Delphi :smile:)
Cheers,
Gus

I used to write Delphi code back in the day, so I am definitely familiar.. it's just difficult to make a case that this is a language with a future? 🤷♂

Let's keep this discussion at  https://github.com/coding-horror/basic-computer-games/issues/15 for now

10-4

You're more inclined on this code being in a parallel repository. Closing.
In the context of you wanting to donate, I completely agree.


(hotfix) Pylon: replace WehHDFS URLs in REST server responses

cherry-picked from master

Coverage remained the same at 51.626% when pulling 453f76d4f97083fe8345330025017683f65d5082 on qixcheng/pylon/replace-webhdfs-in-rest-server into b0db1b0d7ff63b115f55384e22ce1befd197f54a on pai-0.8.y.

Coverage remained the same at 51.626% when pulling 453f76d4f97083fe8345330025017683f65d5082 on qixcheng/pylon/replace-webhdfs-in-rest-server into b0db1b0d7ff63b115f55384e22ce1befd197f54a on pai-0.8.y.


neardeath icons boiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

Please check for duplicates or similar issues before creating this issue.
nope
What is your suggestion, and why should it be implemented?
Neardeath icons. Opposite as the winning icons as in #52 and well, dont expect alot. Bet if this is planned!

fr im gonna sleep, goodbye! so i expect the messages from now on being like 2 hours.

already a thing


What is the purpose of this file?

https://github.com/nandorojo/expo-firestore-offline-persistence/blob/68a860c890dbb3a4f35dd5a37dc8ead46992a38c/src/storage.ts#L1

This file is a no-op. It isn’t used and is going to get deleted.


WPF Xaml error in Accordion Item

Program starts, but I get error message, in AccordionItem.xaml, line 316:

The property "IsExpanded" is not a DependencyProperty. To be used in markup, non-attached properties must be exposed on the target type with an accessible instance property "IsExpanded". For attached properties, the declaring type must provide static "GetIsExpanded"  and "SetIsExpanded" methods.

XAML lines that show problem are:
<ControlTemplate.Triggers>
    <Trigger Property="IsExpanded" Value="True">

Also, to start program I removed toolkit-related stuff, but it's unrelated to this issue

I cut out and pasted ControlTemplate.Triggers fragment and error is now gone. Guess it is Visual Studio


Update DisplayLink to version 4.0.0

After making all changes to the cask:

[ ] brew cask audit --download {{cask_file}} is error-free.
[ ] brew cask style --fix {{cask_file}} left no offenses.
[x] The commit message includes the cask’s name and version.

Release Notes are available here:
http://assets.displaylink.com/live/downloads/release-notes/f1034_	DisplayLink+USB+Graphics+Software+for+OS+X+and+macOS+4.0.0-Release+Notes.txt

Sorry, wrong checksum -- calculated it for the .dmg and not for the .zip.


Beard support

Hey there. I just recently found your package and am totally in love with it.
Once it's a pretty major facial feature - are there any plans to add bears soon?

Hi, this project is based on the assets shared from https://www.figma.com/community/file/829741575478342595
Unfortunately, it doesn't have good-looking beard options for the moment, so we won't support that until the designer update it


Laverna 404

Just attempted to install Laverna (on Banana Pi, fresh install Debian Jessie minimal). No error during DPlatform install; however attempting to access Laverna in browser results in:

404 Not Found
nginx/1.6.2

Thanks to report this nginx http issue. I see an incorrect directory, this is probably that.


docs: select field custom component example fixed and improved

Description

I discovered a few things in this documentation code snippet that cost me time to figure out. I think the improvements are valid for most users.
There were also minor errors that needed fixing.
Fixes:

A typo where CustomSelectProps was declared in camelCase but referenced in PascalCase.
The callback value in onChange is potentially null, e.g., when clearing the select.

Regarding the onChange parameter, I think we should also change the Interface to add null:
export type SelectInputProps = Omit<SelectField, 'options' | 'type' | 'value'> & {
  // …
  onChange?: (value: Option|null) => void
  // …
}

Please let me know how to proceed with this one :)
Improvements:

Typescript types clarifying the expected output of the .filter function.
CSS classes as used in the default UI to make the example a drop-in replacement. We could also use fieldBaseClass here.

[x] I have read and understand the CONTRIBUTING.md document in this repository.

Type of change

[x] This change requires a documentation update

Checklist:

[ ] I have added tests that prove my fix is effective or that my feature works
[ ] Existing test suite passes locally with my changes
[ ] I have made corresponding changes to the documentation

@barthy-koeln this all looks great 👍 except I don't think we should include null in the onChange handler because it does not match the function's type. If you can revert that change then I think this is mergable. Looks like it was missing the argument, though.

For the record to use null you should include an option with the value of null to achieve this.

The issue is that ReactSelect has null in its type definition and its documentation:
onChange = (
    newValue: OnChangeValue<Option, IsMulti>,
    actionMeta: ActionMeta<Option>
)

export type OnChangeValue<Option, IsMulti extends boolean> = IsMulti extends true
    ? MultiValue<Option>
    : SingleValue<Option>

export type SingleValue<Option> = Option | null;

They use it when clearing the select, for example using the built-in clear button that is enabled in Payload UI by default:
  clearValue = () => {
    const { selectValue } = this.state;
    this.onChange(valueTernary(this.props.isMulti, [], null), {
      action: 'clear',
      removedValues: selectValue,
    });
  };

Which means that the current example for a custom select in the Payload docs throws errors when clearing the input.
onChange={(o) => setValue(o.value)}

react-dom.development.js:4312 Uncaught TypeError: Cannot read properties of null (reading 'value')
    at onChange (IconSelectComponent.tsx:61:123)
    at useStateManager-7e1e8489.esm.js:36:7
    at Select2._this.onChange (Select-aecb2a80.esm.js:1177:7)
    at Select2._this.clearValue (Select-aecb2a80.esm.js:1251:13)
    at Select2._this.onClearIndicatorMouseDown (Select-aecb2a80.esm.js:1378:13)
    …

Ok interesting, thank you for pointing this out. I think the move here then is to adjust the Payload types accordingly to match React Select. I would expect that TS is throwing an error in your onChange handler because Option is never null according to Payload. Are you getting any type errors from your change?

No, interestingly it doesn't throw any errors for comparisons with, null and undefined even with strictNullChecks.
Here's a simplified example
const num: number = 3

if (num === null) {
  console.info('this one is fine')
}

if (num === 'string') {
  console.info('this one is not')
}

See the output in the TypeScript Playground.
Should I extend this PR to also adapt the types?

@jacobsfletch just a careful ping to see if I can further support here.

Docs will be reworked for 3.0. Feel free to PR after release.


Feature Request : Module for dumping GMSA Credentials as NTLM

I am using this python script https://github.com/micahvandeusen/gMSADumper which helps me dump the GMSA credentials in NTLM format if the user has the ReadGMSAPassword attribute in bloodhound

#614


Revised version

Learned a lot about Go and how maps aren't thread safe. Still lots of clean up to do...

Whoops wrong branch...


Provide "YellowStar" as a reusable component.

🗒 General
I noticed YellowStar is a component that is created many times across the code base and thought that it makes sense to either export it from catalog-react alternative keep the color in the theme? I see the change of the color is changed in multiple places already and it would be nice to keep it consistent.
https://github.com/backstage/backstage/blob/b6af1b73fcd5774d5f4b29860c3844b214018df6/plugins/catalog-react/src/components/FavoriteEntity/FavoriteEntity.tsx#L29-L33
https://github.com/backstage/backstage/blob/8f16051d466e21d6d33f2b5b47f32fb8ec911dad/plugins/techdocs/src/home/components/Tables/actions.tsx#L24-L28
https://github.com/backstage/backstage/blob/e1460a97c64a7ed7283f8363e82fca9eb6e0f44b/plugins/catalog/src/components/CatalogTable/CatalogTable.tsx#L56-L60
💻 Usage
In any situations where I would like to use a star icon, just visually or with functionality (Button).

Linking #https://github.com/backstage/backstage/issues/9948 here. We duplicated this ahead of catalog 1.0 since we didn't really like the existing API. As far as I can tell the most popular way forward right now is the FavoriteEntity.Icon option

@djamaile we're happy to move forward with adding FavoriteEntity.Icon if that's something you'd like to implement! Otherwise I think it's best that we merge your PR tbh

@Rugvip feel free to merge for now, currently on vacation. Will be back in the week of 2nd of May, will put this issue on my list 👍

Still wanting to do FavoriteEntity.Icon or is system icons the way forward? @Rugvip


feature request: automated tree file formatting

Automatically convert from
VS Code has a nice tree generator: Ascii Tree Generator plug in, but even using that can be a bit tedious converting to and from tree syntax. Bulloak doing this conversion for you would be quite nice.
The plugin allows you to use hashtags for tree structures and automatically converts it into the nice tree.

# when there is a condition
## it should revert
# when there isn't the condition
## when sender is authorized
### it should update the state

IMO this would be more readable:
HashPairTest
  It should never revert.
  When first arg is smaller than second arg
    It should match the result of `keccak256(abi.encodePacked(a,b))`.
  When first arg is bigger than second arg
    It should match the result of `keccak256(abi.encodePacked(b,a))`.

than that:
HashPairTest
# It should never revert.
# When first arg is smaller than second arg
## It should match the result of `keccak256(abi.encodePacked(a,b))`.
# When first arg is bigger than second arg
## It should match the result of `keccak256(abi.encodePacked(b,a))`.

Essentially if we could have bulloak tree working like this, all pain points related to the tree formatting would be gone :sparkles:


SDIT-1402: 🔧 Move to new preprod prison api in cloud platform

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

Comparison is base (6a9b988) 87.00% compared to head (3bdcf70) 87.00%.
Report is 1 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff            @@
##               main     #752   +/-   ##
=========================================
  Coverage     87.00%   87.00%
  Complexity     3436     3436
=========================================
  Files           357      357
  Lines         11916    11916
  Branches        998      998
=========================================
  Hits          10367    10367
  Misses         1083     1083
  Partials        466      466

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


[1.18.2] [Apotheosis-1.18.2-5.6.1] Startup Crash: java.lang.NoClassDefFoundError: shadows/placebo/network/MessageProvider

Using Forge [40.1.76]
Small Fail Box:
The game crashed whilst initializing game
Error: java.lang.NoClassDefFoundError: shadows/placebo/network/MessageProvider
crash-2022-09-08_01.31.20-client.txt
I also attempted to remove Twilight Forest and re-run, still failed, I got something slightly different:
java.lang.NoClassDefFoundError: shadows/placebo/recipe/NBTIngredient
crash-2022-09-08_01.33.30-client.txt
So then, I dropped everything but Apotheosis, and got the same thing as the first time:
The game crashed whilst initializing game
Error: java.lang.NoClassDefFoundError: shadows/placebo/network/MessageProvider
Dropped down to zero mods (Just 1.18.2+Forge), game loads.
Upped back to everything but Apotheosis (38 mods, + Optifine), game loads.
Issue persists for (at least) Versions:
Apotheosis-1.18.2-5.6.1
Apotheosis-1.18.2-5.6.0
Apotheosis-1.18.2-5.5.1
... and...
Apotheosis-1.18.2-5.3.4
Rolled back to Forge 40.1.0 (Recommended Build)... no dice.
Sighed heavily, and went back to the Curseforge page to see if anyone else was having issues.
Re-read description. Mod Requires "Placebo."
Placebo Downloaded.
Issue fixed.
/Sigh
Thanks for joining me on this journey. If one could highlight the Pre-Requisite Mods a little more boldly (or move the requirement to the top of the description), it'd help tired people like me.

You either have two placebo jars installed (which is usually what I see causing this) or you have a reallllly old placebo version.


[incubator/rundeck] Environmental variables for Deployment not taken from values.yaml

Describe the bug
A clear and concise description of what the bug is.
The environment variable RUNDECK_GRAILS_URL created in deployment.yaml is not taken from the value listed in values.yaml.
Version of Helm and Kubernetes:
Which chart:
incubator/rundeck
What happened:
What you expected to happen:
Deployment.yaml RUNDECK_GRAILS_URL inherited from values.yaml
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know:

I have a similar issue with DB connection variables. The chart is not really solid, I might gave a go at it soonish...

I believe this PR would address the issue you identified.
https://github.com/helm/charts/pull/16007
Thanks!


Add a review policy

This is an attempt to try to capture what I think should be guidelines for merging and reviewing, based on some of the discussion from the 2024-03-14 meeting.
I placed this within an outline of other team documentation I think we should have to give context to where it fits in. I expect to have these other sections filled in the future.
This explicitly does not cover how "final approval" is given by teams like the lang team, which I think will need a separate process.
Closes #25

@rfcbot poll "t-spec approve"

Maybe rfcbot doesn't fully work yet.

@JoelMarcey You have to make sure the T-spec label is applied, otherwise rfcbot doesn't know which team to ping. Also, it can take ~10 minutes for it to respond since it is currently polling (once infra sets up the webhook, it should be immediate).
@rfcbot poll "t-spec approve"

🤷 Bot now seems confused. Here are checkboxes:

[ ] @JoelMarcey
[x] @ehuss
[ ] @m-ou-se
[ ] @pnkfelix


Change of spec 0038-OLIQ

Change of spec (0038-OLIQ-liquidity_provision_order_type.md) to cover special case when LP peg would lead to negative product value
PR

The spec change is done.


IEC integration failure

System Health details
Core - 2024.11.3
Frontend - 20241106.2
IEC - 0.0.43
Checklist

[X] I have enabled debug logging for my installation.
[X] I have filled out the issue template to the best of my ability.
[X] This issue only contains 1 issue (if you have multiple issues, open one issue for each issue).
[X] This issue is not a duplicate issue of any previous issues..

Describe the issue
IEC data not available
integration used to work but stopped working
removing the integration and reinstalling it didn't fix the issue (successfully received the IEC OTP)
the integration used to display entities automatically but does not display any entities now
the attached debug log (with redacted personal info) shows several errors (at the end of the log)
Reproduction steps

update IEC integration to the latest version
add integration
enter ID and OTP
enable log

Debug logs
2024-12-05 19:28:15.883 WARNING (SyncWorker_0) [homeassistant.loader] We found a custom integration iec which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2024-12-05 19:28:27.874 INFO (SyncWorker_8) [homeassistant.util.package] Attempting install of iec-api==0.4.10
2024-12-05 19:28:40.296 INFO (MainThread) [homeassistant.setup] Setting up iec
2024-12-05 19:28:40.296 INFO (MainThread) [homeassistant.setup] Setup of domain iec took 0.00 seconds
2024-12-05 19:28:40.296 DEBUG (MainThread) [custom_components.iec.coordinator] Initializing IEC Coordinator
2024-12-05 19:28:40.298 DEBUG (MainThread) [custom_components.iec.coordinator] Loading API token from config entry
2024-12-05 19:28:40.298 DEBUG (MainThread) [custom_components.iec.coordinator] Checking if API token needs to be refreshed
2024-12-05 19:28:40.299 DEBUG (MainThread) [iec_api.commons] HTTP GET: https://iecapi.iec.co.il/api/customer/contract/xxxxxxxxx
2024-12-05 19:28:43.217 DEBUG (MainThread) [iec_api.commons] HTTP GET Response <200>: {"data":{"contracts":[{"address":"my address","contractId":"my contract","dueDate":"1900-01-01","totalDebt":0.0,"frequency":2,"status":1,"fromPativteProducer":true,"cityCode":"city code","cityName":"city name","streetCode":"street code","streetName":"street name","houseNumber":"xx","debtForInvoicesDueDateNotPassed":0.0,"isTouz":false,"smartMeter":true,"producerType":1,"isDomestic":true},{"address":"2nd address - previous contract","contractId":"contract2","dueDate":"1900-01-01","totalDebt":0.0,"frequency":2,"status":2,"fromPativteProducer":false,"cityCode":"xxxxx","cityName":"city name","streetCode":"xxx","streetName":"street name","houseNumber":"X","debtForInvoicesDueDateNotPassed":0.0,"isTouz":false,"smartMeter":false,"producerType":1,"isDomestic":true}],"contractAmount":2,"totalToPay":0.0},"reponseDescriptor":{"isSuccess":true,"code":"0","description":""}}
2024-12-05 19:28:43.218 DEBUG (MainThread) [iec_api.commons] HTTP GET: https://iecapi.iec.co.il/api/content/en-US/calculators/gadget
2024-12-05 19:28:43.497 DEBUG (MainThread) [iec_api.commons] HTTP GET Response <200>: {"gadget_Calculator_Rates":{"lastUpdated":"2024-02-01T00:00:00Z","homeRate":0.5252,"generalRate":0.5252,"vat":17.0},"gadget_Calculator_Actions":{"additionalInfo":[{"displaySettings":[],"link":"/en/email-invoice/","icon":"https://ieccontent.iec.co.il//media/bnwhvv1d/mail_v2.svg","description":"Receipt of invoice by email"}]},"electric_Devices":[{"name":"Washing machine","calculationResolution":1,"powerUnit":4,"power":1.5,"avarageDurationTimeOfOperationInMinutes":60.0},{"name":"Small refrigerator","calculationResolution":1,"powerUnit":3,"power":40.0,"avarageDurationTimeOfOperationInMinutes":1440.0},{"name":"Large refrigerator","calculationResolution":1,"powerUnit":3,"power":80.0,"avarageDurationTimeOfOperationInMinutes":1440.0},{"name":"Electric water heater (\"boiler\")","calculationResolution":1,"powerUnit":4,"power":2.5,"avarageDurationTimeOfOperationInMinutes":60.0},{"name":"Cooking, grilling and baking oven","calculationResolution":1,"powerUnit":4,"power":2.0,"avarageDurationTimeOfOperationInMinutes":60.0},{"name":"Electric stove top","calculationResolution":2,"powerUnit":4,"power":6.0,"avarageDurationTimeOfOperationInMinutes":50.0},{"name":"Shabbat hot plate","calculationResolution":1,"powerUnit":3,"power":400.0,"avarageDurationTimeOfOperationInMinutes":60.0},{"name":"Electric heater","calculationResolution":1,"powerUnit":4,"power":2.0,"avarageDurationTimeOfOperationInMinutes":60.0},{"name":"Air-conditioner","calculationResolution":1,"powerUnit":2,"power":2.0,"avarageDurationTimeOfOperationInMinutes":60.0},{"name":"Tumble dryer","calculationResolution":1,"powerUnit":4,"power":3.0,"avarageDurationTimeOfOperationInMinutes":60.0},{"name":"Dishwasher for 6-8 sets of dishes","calculationResolution":1,"powerUnit":4,"power":1.0,"avarageDurationTimeOfOperationInMinutes":60.0},{"name":"Dishwasher for 12-14 sets of dishes","calculationResolution":1,"powerUnit":4,"power":1.5,"avarageDurationTimeOfOperationInMinutes":60.0},{"name":"Dishwasher","calculationResolution":1,"powerUnit":4,"power":1.5,"avarageDurationTimeOfOperationInMinutes":60.0},{"name":"Incandescent lamp","calculationResolution":1,"powerUnit":3,"power":100.0,"avarageDurationTimeOfOperationInMinutes":60.0},{"name":"\"Regular\" fluorescent lamp","calculationResolution":1,"powerUnit":3,"power":300.0,"avarageDurationTimeOfOperationInMinutes":60.0},{"name":"\"Regular\" halogen lamp","calculationResolution":1,"powerUnit":3,"power":200.0,"avarageDurationTimeOfOperationInMinutes":60.0},{"name":"LED lamp","calculationResolution":1,"powerUnit":3,"power":15.0,"avarageDurationTimeOfOperationInMinutes":60.0},{"name":"Microwave oven","calculationResolution":2,"powerUnit":4,"power":1.5,"avarageDurationTimeOfOperationInMinutes":2.0},{"name":"Electric kettle","calculationResolution":2,"powerUnit":4,"power":2.2,"avarageDurationTimeOfOperationInMinutes":3.0},{"name":"Vacuum cleaner","calculationResolution":2,"powerUnit":4,"power":1.0,"avarageDurationTimeOfOperationInMinutes":10.0},{"name":"Iron","calculationResolution":2,"powerUnit":4,"power":2.0,"avarageDurationTimeOfOperationInMinutes":45.0},{"name":"Food processor","calculationResolution":2,"powerUnit":4,"power":0.5,"avarageDurationTimeOfOperationInMinutes":15.0},{"name":"Toaster oven","calculationResolution":2,"powerUnit":4,"power":1.2,"avarageDurationTimeOfOperationInMinutes":15.0},{"name":"Television set","calculationResolution":1,"powerUnit":3,"power":200.0,"avarageDurationTimeOfOperationInMinutes":60.0},{"name":"Hair dryer","calculationResolution":2,"powerUnit":4,"power":1.0,"avarageDurationTimeOfOperationInMinutes":10.0},{"name":"Electric blanket","calculationResolution":1,"powerUnit":3,"power":100.0,"avarageDurationTimeOfOperationInMinutes":60.0},{"name":"Personal computer","calculationResolution":1,"powerUnit":3,"power":120.0,"avarageDurationTimeOfOperationInMinutes":60.0}],"title":"Calculators BY Device","seoModel":{"title":"","additionalInfo":[]},"unavailable_Service_Alerts":[]}
2024-12-05 19:28:43.502 DEBUG (MainThread) [iec_api.commons] HTTP GET: https://iecapi.iec.co.il/api/content/en-US/content/tariffs/contentpages/homeelectricitytariff
2024-12-05 19:28:43.517 DEBUG (MainThread) [iec_api.commons] HTTP GET Response <204>:
2024-12-05 19:28:43.517 WARNING (MainThread) [iec_api.commons] Failed call: (Code 204): No Content
2024-12-05 19:28:43.518 ERROR (MainThread) [custom_components.iec.coordinator] Failed updating data. Exception: object of type 'NoneType' has no len()
2024-12-05 19:28:43.527 ERROR (MainThread) [custom_components.iec.coordinator] Traceback (most recent call last):
  File "/config/custom_components/iec/coordinator.py", line 647, in _async_update_data
  File "/config/custom_components/iec/coordinator.py", line 385, in _update_data
  File "/config/custom_components/iec/coordinator.py", line 191, in _get_kva_tariff
  File "/config/deps/lib/python3.12/site-packages/iec_api/iec_client.py", line 511, in get_kva_tariff
  File "/config/deps/lib/python3.12/site-packages/iec_api/static_data.py", line 93, in get_kva_tariff
  File "/config/deps/lib/python3.12/site-packages/iec_api/static_data.py", line 42, in _get_tariffs
  File "/config/deps/lib/python3.12/site-packages/iec_api/commons.py", line 125, in send_get_request
  File "/config/deps/lib/python3.12/site-packages/iec_api/commons.py", line 92, in parse_error_response
2024-12-05 19:28:43.528 DEBUG (MainThread) [custom_components.iec.coordinator] Finished fetching Iec data in 3.230 seconds (success: False)
2024-12-05 19:28:43.528 ERROR (MainThread) [custom_components.iec] Failed to fetch initial data: Failed Updating IEC data
2024-12-05 19:28:43.563 INFO (MainThread) [homeassistant.components.sensor] Setting up iec.sensor
2024-12-05 19:28:43.564 ERROR (MainThread) [homeassistant.components.sensor] Error while setting up iec platform for sensor
  File "/config/custom_components/iec/sensor.py", line 335, in async_setup_entry
2024-12-05 19:28:43.567 INFO (MainThread) [homeassistant.components.binary_sensor] Setting up iec.binary_sensor
2024-12-05 19:28:43.567 ERROR (MainThread) [homeassistant.components.binary_sensor] Error while setting up iec platform for binary_sensor
  File "/config/custom_components/iec/binary_sensor.py", line 70, in async_setup_entry

Diagnostics dump
No response

It's related to IEC change in KVA calculation. Try again sometime laterr


Withdraw all funds not working correctly - removing open orders significantly delayed, available funds showing negative balance and fee reserve not being withdrawn

After withdrawing all funds. Note the negative balance in the top bar, open orders still showing and fee reserve still there.

After quite a few minutes delay the negative balance was removed as well as the open orders, but fee reserve is still showing

It takes a second for open orders to be cancelled, it's done on zeroX side and the UI is informed, I saw a negative balance for less than one second. Then my open orders were removed and I saw the below.

looks to be working how it should. Closing


Add Qwik component templates

Hello @Giuliano1993. Can I work on this?

Hello @Renzodef ! Yes of course! I'm assigning this to you! Thank you!


Added support for log file headers

Added property initialFileContents to DDLogFileManagerDefault to support headers in log files.
Override implementation of initialFileContents to insert header text at the beginning of every log file created by the createNewLogFile: method.
New Pull Request Checklist

[x] I have read and understood the CONTRIBUTING guide

[x] I have read the Documentation

[x] I have searched for a similar pull request in the project and found none

[x] I have updated this branch with the latest master to avoid conflicts (via merge from master or rebase)

[ ] I have added the required tests to prove the fix/feature I am adding

[ ] I have updated the documentation (if necessary)

[ ] I have run the tests and they pass

[ ] I have run the lint and it passes (pod lib lint)

This merge request fixes / refers to the following issues: ...
Pull Request Description
We wish to include the version and build date of our application at the beginning of the log files generated by CocoaLumberjack. I have not been able to find any obvious way of doing this so I propose adding an initialFileContents property to DDLogFileManagerDefault which the  createNewLogFile: method then uses as an argument for the 'contents' parameter (instead of nil) when calling createFileAtPath:contents:attributes:
The intention is to achieve something which is possible in NLog (though NLog is a very different beast), using LayoutWithHeaderAndFooter.

Codecov Report

Merging #998 into master will decrease coverage by 0.08%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master     #998      +/-   ##
==========================================
- Coverage   25.85%   25.76%   -0.09%
==========================================
  Files          22       22
  Lines        3528     3539      +11
==========================================
  Hits          912      912
- Misses       2616     2627      +11

Impacted Files
Coverage Δ

Classes/DDFileLogger.h
0% <ø> (ø)
:arrow_up:

Classes/DDFileLogger.m
0% <0%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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

Looks good, but I would rename initialFileContents with something like logFileHeader.

However, adding "Header" for file logger is really discouraged.
It is not the point for a file logger.
File logger can gather logs into a file. Ok, it is a content of a file.
Next, if you like to post-process file, you can ( before archiving or sending to your server ) append header, footer, any type of stars, whistles, bells etc. You can also add your best poem or quote of the day.

I see what you say @lolgear , but at the same time by default it will be empty. So it looks good to me.


[GEP-21]: provider-local single-stack ipv6 implementation

What this PR does / why we need it:
See https://github.com/gardener/gardener/pull/8574
Which issue(s) this PR fixes:
Fixes https://github.com/gardener/gardener/issues/7051
Special notes for your reviewer:
Release note:

added ipv6 single-stack support

Thank you @nschad for your contribution. Before I can start building your PR, a member of the organization must set the required label(s) {'reviewed/ok-to-test'}. Once started, you can check the build status in the PR checks section below.

/ok-to-test

I deployed containers with the changes in the local setup and tried to create an IPv4 shoot.
The pod vpn-seed-server is in CrashLoopBackOff.
I see the following log messages:
2023-10-04 16:01:47 WARNING: file '/srv/secrets/vpn-server/tls.key' is group or others accessible
2023-10-04 16:01:47 OpenVPN 2.6.5 aarch64-alpine-linux-musl [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
2023-10-04 16:01:47 library versions: OpenSSL 3.1.2 1 Aug 2023, LZO 2.10
2023-10-04 16:01:47 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2023-10-04 16:01:47 sitnl_send: rtnl: generic error (-101): Network unreachable
2023-10-04 16:01:47 RESOLVE: Cannot resolve host address: <IP_ADDRESS>: (Name has no usable address)

On shoot side the vpn pod is running, but there are no log messages.
I didn't do any further debugging.
Did that work for you?

I deployed containers with the changes in the local setup and tried to create an IPv4 shoot. The pod vpn-seed-server is in CrashLoopBackOff. I see the following log messages:
2023-10-04 16:01:47 WARNING: file '/srv/secrets/vpn-server/tls.key' is group or others accessible
2023-10-04 16:01:47 OpenVPN 2.6.5 aarch64-alpine-linux-musl [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
2023-10-04 16:01:47 library versions: OpenSSL 3.1.2 1 Aug 2023, LZO 2.10
2023-10-04 16:01:47 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2023-10-04 16:01:47 sitnl_send: rtnl: generic error (-101): Network unreachable
2023-10-04 16:01:47 RESOLVE: Cannot resolve host address: <IP_ADDRESS>: (Name has no usable address)

On shoot side the vpn pod is running, but there are no log messages. I didn't do any further debugging. Did that work for you?

Have you tested this with the changes in gardener/gardener? Otherwise I don't know if that works without having IP_FAMILIES set

Have you tested this with the changes in gardener/gardener? Otherwise I don't know if that works without having IP_FAMILIES set

Ah, that's the problem. In case IP_FAMILIES is not set, IPv4 should be the default. Otherwise, we can not merge this PR before the changes of https://github.com/stackitcloud/gardener/tree/feature/shoot-ipv6 are merged to g/g.

https://github.com/stackitcloud/gardener/tree/feature/shoot-ipv6

It's actually stackitcloud:feature/shoot-ipv6-rebased (notice the -rebased). I can add some defaulting code here no problem but the IP_FAMILIES are definitely defaulted over at g/g. We figured the 3 PR's will be merged together anyway. But I don't have a strong opinion about it and I do not mind adding another check here, maybe with some TODO later for clean up?

https://github.com/stackitcloud/gardener/tree/feature/shoot-ipv6

It's actually stackitcloud:feature/shoot-ipv6-rebased (notice the -rebased). I can add some defaulting code here no problem but the IP_FAMILIES are definitely defaulted over at g/g. We figured the 3 PR's will be merged together anyway. But I don't have a strong opinion about it and I do not mind adding another check here, maybe with some TODO later for clean up?

With IPv4 as default there is no dependency to g/g. If you just switch the if and else path, there shouldn't be a clean up necessary.

I didn't see the related PR yet:
https://github.com/gardener/gardener/pull/8574

@axel7born thanks for your feedback. I've incorporated your suggestions. PTAL :)

/lgtm

@axel7born should we go ahead and merge this PR?

@axel7born should we go ahead and merge this PR?

I think, @DockToFuture would like to have a look.


Accessing the Docker socket on ACI

Is there a way to access the Docker socket on the host when deploying containers? The infrastructure I'm using requires such setup.

@GalacticLion7 Thank you for reaching out, can you please help share the documentation link you are referencing so that we can better assist you.
Also, please note that this channel (the Azure Docs repository) is only for driving improvements related to the Azure documentation.
Please revert back with the documentation link so that we can assist you further. Thank you.

@GalacticLion7 Since we have not heard back from you we will now proceed to close this thread. However if you can share additional information regarding the documentation you are referring and circle back on this thread , we will gladly reopen the issue and continue the discussion. Thank you.


New ipfs.io website

:tada:
Currently deployed to ipfs at https://ipfs.io/ipfs/Qme5m1hmmMbjdzcDeUC2LtHZxAABYtdmq5mBpvtBsC8VL5/

@adambrault (and everyone else) this looks amazing!

This looks amazing! and we shipped it live today at the internet archive!
We were very constrained on time (5m only for everything) so we couldn't make a big deal out of it, but we shipped it.
We may re-ship it again tomorrow, :)

It looks awesome, I have two very small complains:

jquery.min.js is fetched from google's CDN not IPFS
/theme/images/hero-text-bg.png weights almost a 1M which is more than half of loading size of the website.

Apart from that (which is really minor and will be very easy to fix), :heart: .

Great work, love the new site! A minor issue I noticed was that the links to the blog are currently broken. The href has an extra dot in there, e.g. linking to /.blog/17-distributions instead of /blog/17-distributions. I tried looking into the branch and fix it myself but haven't been able to find anything, yet.

@mk thank you very much for catching that.

Latest version is at https://ipfs.io/ipfs/Qme5m1hmmMbjdzcDeUC2LtHZxAABYtdmq5mBpvtBsC8VL5/

Scratch that. Pasted the wrong link. This is the version reflecting the changes above: QmVaAzC4JBwsp7cHxVSFkqSJtaXsLcz8mo4o4dCpuQ5auy

@adambrault looks like docs/ lost an index.html: https://ipfs.io/ipfs/QmVaAzC4JBwsp7cHxVSFkqSJtaXsLcz8mo4o4dCpuQ5auy/docs

@jbenet good catch. not sure how I did that but it's back now :)
https://ipfs.io/ipfs/QmQkVAnFNJP2i717BeeL58b4rNTzgFtNeDkhM21axLKY2K/docs

Great work!
Was this merged? I'm seeing the new site on ipfs.io -- can this be closed?

@RichardLitt imo, it could be merged.
The latest version is not what's on ipfs.io though.
https://ipfs.io/ipfs/QmQkVAnFNJP2i717BeeL58b4rNTzgFtNeDkhM21axLKY2K/

@lgierth i think the site right now is not the latest? o/

It's what's on master -- not sure what else the latest might be :)

@lgierth the link @adambrault put up there is different, i think?
@adambrault is what produced that link not master?


[Discussion] Replacing libsolv with pubgrub

I'm not sure what requirements there are for dependency solving in this project, but https://github.com/pubgrub-rs/pubgrub is a pretty mature and pure-rust solver.

RPM has a custom versioning scheme, NEVRA (name-epoch-version.release.architecture) to be exact.
To use pubgrub this will require it to support such versioning scheme. The solver must prefer packages with the same release as the system's release. Currently libsolv (and in extension, DNF) does this.

pubgrub operates on dependencies via a Version trait, so most probably the NEVRA scheme could be customly implemented

Might be viable then. I'll look into it more with @windowsboy111 once we get the time.

Oh by the way, can pubgrub solve dependencies by file?


Cannot run on M1 with Oh My Zsh installed

Attempting to run the instructions for an M1 mac results in the following error on my machine whether running in a bash shell or in zsh.
Error: Oh My Zsh can't be loaded from: /bin/bash. You need to run zsh instead.
Here's the process tree:

 PPID   PID COMMAND
    1 33088 /System/Applications/Utilities/Terminal.app/Contents/MacOS/Terminal
33088 33518 login -pf armstrys
33518 33519 -zsh
33519 33594 /bin/bash ./run-mac.sh --model 7b

Run as"zsh ./run-mac.sh"

Thanks for the quick response! That's the one combo I hadn't tried yet and it worked.


have korulsi be considered a herb for atleast bank (BSO)

🐛 Bug Report
Name says it all

Looks like it affects more then just herbs, based on conversations with others it also affects the enhanced potions for herblore, and the seeds are not in farming


Update animation

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#291  👈
#290
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @ksharma-xyz and the rest of your teammates on  Graphite


markdown not working?

I've created a simple markdown page to show some code blocks under "content\docs" folder. filename is called "index.md" with simple markdown in it. I try to hit route /docs and I renders the / index page but not the markdown. in the _site output folder, I see that the route has the code for the homepage. I'm using the Stone template as a test. please advise.

had a typo in the filename under pages\docs. please disregard. thank you!


Support cuDNN v4

cuDNN v4 is now available.
https://developer.nvidia.com/cudnn

This issue is fixed via #756


Support for GHC

I forked WebVM here and am trying to get GHC working. With this Dockerfile I'm getting errors like this after startup:
/opt/ghc/9.10.1/lib/ghc-9.10.1/bin/./ghc-9.10.1: error while loading shared libraries: libHShaskeline-<IP_ADDRESS>-161b-ghc9.10.1.so: cannot open shared object file: No such file or directory

And errors like this in the JavaScript console:
TODO: READLINK PATH /proc/self/exe LEN 4096

and finally
Fault addr 0, ip 556b9106

Thanks for reporting this, we'll investigate this when we can. The readlink message is most likely not the problem, so I'll update the title to reflect this.

Thanks for your patience, GHC is now working on the currently deployed version of WebVM, please be aware that due to CDN caching it might take a while for the updated version to be available everywhere.

/opt/ghc/9.10.1/lib/ghc-9.10.1/bin/./ghc-9.10.1: error while loading shared libraries: libHShaskeline-<IP_ADDRESS>-161b-ghc9.10.1.so: cannot open shared object file: No such file or directory

The initial problem is actually quite obvious and not a WebVM bug. The libraries for GHC are installed in /opt which is not part of the standard library path. The same error would happen in native. To fix this you need to add this environment variable
LD_LIBRARY_PATH=/opt/ghc/9.10.1/lib/ghc-9.10.1/lib/i386-linux-ghc-9.10.1/

A few additional fixes were also required to our syscalls implementation, but nothing major. Thanks for reporting this.

It's not obvious to me why I have to set LD_LIBRARY_PATH myself here, this seems like a WebVM-specific implementation detail. I don't agree that the same thing happens natively, since I have a similar setup using container2wasm and this Dockerfile, and I don't have to touch LD_LIBRARY_PATH anywhere to get that to work (you can see that here). In any case, thanks for your extremely helpful response!

You are right, LD_LIBRARY_PATH is not required since the executable uses RUNPATHs internally. These were not working correctly due to the missing /proc/self/exe symlink.
The problem is now fixed and the application can start correctly without defining any additional environment variable. Don't forget to rebase your fork on the updated webvm repo, proc was not previously mounted.
As usual take into account that the CDN might cache the older build for a few days.


vividl not finding update from 0.7 to 0.7.1

I'm using 0.7 on Windows 11 and when I do a search for updates, vividl is not finding that there's a 0.7.1, even though 0.7.1 has been out for a month now.

Sorry for this, should be fixed now.


Where is the "I2C Accelerometer" on the github?

The "SPI Accelerometer Sampler" and "I2C Acceleromenter Sample" of the "lowLevelDevice Capability" (https://docs.microsoft.com/zh-cn/windows/iot-core/develop-your-app/embeddedmode#lowleveldevice-capability) are both link to the same website after jump to the github website. They all both link to the: https://github.com/Microsoft/Windows-iotcore-samples/tree/develop/Samples/Accelerometer. Where is the "I2C Accelerometer" on the github?

文档详细信息
⚠ 请勿编辑此部分。 docs.microsoft.com ➟ GitHub 问题链接必须具有此部分。

ID: 17c2bf9d-6b31-6748-90ac-68f1f472e3ff
Version Independent ID: f305b967-06d9-cdc7-5a1c-a699485b9bc7
Content: Embedded mode - Windows IoT
Content Source: windows-iotcore/develop-your-app/EmbeddedMode.md
Service: unspecified
GitHub Login: @lilyhou
Microsoft Alias: lihou

It is the same sample.


Rat in Maze

I want to  add solution of rat in maze problem  in cpp

I can solve this question in C++, please specify some details of the question, like if the rat has limited moves or not, whether the rat can move in all four directions or only right and down. You can assign me.

I can solve this question in C++. Specify whether the rat can move in all 4 directions or only down and right and assign me.

I can solve this question in C++. Please specify whether the rat can move in all 4 directions or only down and right and assign me.

I would love to contribute in this issue.

I can provide the most optimized solution, Please assign this issue to me.


[Feat]: Workflow for commenting on PR Raised

Is your feature request related to a problem? Please describe.
Yes, the feature request is related to a problem. When contributors raise pull requests (PRs) in a project, it is crucial to provide immediate acknowledgment and feedback to encourage collaboration and maintain transparency. However, manually commenting on every PR can be time-consuming for maintainers, leading to delays and inconsistency in communication. This can result in contributors feeling undervalued or discouraged from further participation.
Describe the solution you'd like
This solution introduces a new GitHub Actions workflow that automatically comments on new and updated pull requests. This feature aims to streamline the contribution process by providing contributors with immediate feedback and guidance upon creating or updating their pull requests.

@thestarsahil please assign me this issue under gssoc'24

This season we are looking for major problem and solution containing level 3
Please look onto some other major problem
Thanks !


Redeem function Step 1: Clarify / Change what the TDT ID is, where to get it

When you use the Redeem function (https://dapp.test.tbtc.network/redeem) in Step 1 it asks "What was your TDT ID?".
It is unclear for a user what the TDT ID is. If that is the User's Ethereum Address, it should say so. TDT ID is confusing.
If it is not the Ethereum Address, it should clearly guide to where to find it.

The TDT id is clearly noted at the end of the deposit flow, but is an awkward component anyway. As I mentioned in #243 which was centered around the same thing, we're looking at giving users better tools for managing their deposits, and phasing the TDT id into the background instead of making it the primary user approach to referencing a deposit is a core part of that. You can see some early work in this department in #222.
Thanks for the detailed thoughts!

Same thoughts. I actually did not jot down my TDT ID at the end of the flow and now I have problem doing a redemption. Intuitively, the TDT ID should be the ERC721 tokenID that can be easily found on etherscan.

I assume some people will sell their tBTC. Whoever buys that and wants to redeem, should be able to do it. How would that person find the TDT? In any case, it makes it complicated.

How would that person find the TDT? In any case, it makes it complicated.

Yep, definitely something that's on the radar. I'm closing issues around this as the goal of phasing TDT ids into the background is captured in 222---will announce on Discord when the work from that starts rolling out so folks can give thoughts!


Error while import bootstrap

I get an error when I try to import bootstrap. Version: "^4.0.0-beta",
ERROR in ./~/bootstrap/dist/js/bootstrap.js
Module parse failed:
...\src\main\frontend\node_modules\bootstrap\dist\js\bootstrap.js this.state.current.addBlock is not a function
You may need an appropriate loader to handle this file type.
TypeError: this.state.current.addBlock is not a function

Module file:
import React from 'react';
import ReactDOM from 'react-dom';

import "../style/app.scss";

import "jquery";
import "popper.js";
import "bootstrap";

My webpack:
const PATHS = {
    source: path.join(__dirname, 'app'),
    output: path.join(__dirname, '../../../target/classes/static')
};

const common = {
    entry: [
        PATHS.source
    ],
    output: {
        path: PATHS.output,
        publicPath: '',
        filename: 'bundle.js'
    },
    module: {
        loaders: [{
            exclude: /node_modules/,
            loader: 'babel'
        }, {
            test: /\.css$/,
            loader: 'style!css'
        }, {
            test: /\.scss$/,
            loader: 'style!css!resolve-url-loader!sass'
        }, {
            test: /\.jpg|png$/,
            loader: "file?name=[path][name].[ext]"
        },{
            test: /\.woff(2)?(\?v=[0-9]\.[0-9]\.[0-9])?$/,
            loader: "url-loader?limit=10000&mimetype=application/font-woff"
        }]
    },
    resolve: {
        extensions: ['', '.js', '.jsx']
    },
    plugins: [
        new webpack.ProvidePlugin({
            jQuery: 'jquery',
            $: 'jquery',
            'window.jQuery': 'jquery',
            "Tether": 'tether',
            Popper: ['popper.js', 'default']
            // In case you imported plugins individually, you must also require them here:
            // Util: "exports-loader?Util!bootstrap/js/dist/util",
            // Dropdown: "exports-loader?Dropdown!bootstrap/js/dist/dropdown",
        })
    ]
};

I'm not sure bootstrap is compatible with React you should use : https://reactstrap.github.io/

When I use alpha version, everything is right

React is not a cause, without import it, the problem still have

Perhaps you should try dropping tether, seeing how its gone from betas? 🤔

Tether has been removed from Bootstrap since our first beta

The probable cause was the version of webpack and babel. Now, everything works great

@leebake Can i know what version of webpack and babel are you using. I am still facing the same error while trying to reference bootstrap css
Uncaught Error: Module parse failed: /Applications/ReactProjects/adiddav1/node_modules/bootstrap/dist/css/bootstrap.css Unexpected token (7:5)
You may need an appropriate loader to handle this file type.
|  /
| /! normalize.css v3.0.3 | MIT License | github.com/necolas/normalize.css */
| html {
|   font-family: sans-serif;
|   -webkit-text-size-adjust: 100%;

It is not a problem with webpack/babel version. Probalby ,you have to add loader for css
https://getbootstrap.com/docs/4.0/getting-started/webpack/#importing-styles
Please also look at the my webpack config