Read reference object inside path property

In our project, we are using one file using format api specification for swagger ui and api sprout. But in swagger ui, the reference object can be read. But in api sprout reference object cannot be read, maybe this pr will be hopefully help others for cases like me

It would be a great extension to Apisprout to resolve references.
Tried this PR on an Api I have and it failed to validate. The API works fine with Master-bransch and is valid in other tools such as Swagger Hub.
The API is something like this:
paths:   /categories:     get:       parameters:          - $ref: '#/components/parameters/Offset'         - $ref: '#/components/parameters/Limit'
Error message:
`panic: Validating Swagger failed: Found unresolved ref: '#/components/parameters/Offset'
goroutine 1 [running]:
github.com/getkin/kin-openapi/openapi3filter.(*Router).WithSwagger(...)
/go/pkg/mod/github.com/getkin/kin-openapi@v0.1.1-0.20190210195911-82a13f94c08e/openapi3filter/router.go:83
main.load(0x7ffec0fd2f65, 0x16, 0xc000132000, 0x1e8a, 0x208a, 0x0, 0x0)
/apisprout/apisprout.go:311 +0x272
main.server(0xc000130280, 0xc000089650, 0x1, 0x1)
/apisprout/apisprout.go:391 +0x2ba
github.com/spf13/cobra.(*Command).execute(0xc000130280, 0xc000092030, 0x1, 0x1, 0xc000130280, 0xc000092030)
/go/pkg/mod/github.com/spf13/cobra@v0.0.3/command.go:766 +0x2ae
github.com/spf13/cobra.(*Command).ExecuteC(0xc000130280, 0x95fca3, 0xc, 0x0)
/go/pkg/mod/github.com/spf13/cobra@v0.0.3/command.go:852 +0x2c0
github.com/spf13/cobra.(*Command).Execute(...)
/go/pkg/mod/github.com/spf13/cobra@v0.0.3/command.go:800
main.main()
/apisprout/apisprout.go:133 +0x6cb`

It would be a great extension to Apisprout to resolve references.
Tried this PR on an Api I have and it failed to validate. The API works "fine" with Master-branch and is valid in other tools such as Swagger Hub. But using this branch - it won't start.
Cut down version of my API that triggers this error
openapi: 3.0.0
info:
  version: "1"
  title: 'test'
  description: 'test'
servers:
  - description: API Sprout
    url: http://localhost:8000
paths:
  /categories:
    get:
      parameters:
        - $ref: '#/components/parameters/Offset'
        - $ref: '#/components/parameters/Limit'
      responses:
        '200':
          description: OK
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Categories'
components:
  schemas:
    Category:
      type: object
      required:
        - id
        - name
      properties:
        id:
          type: integer
        name:
          type: string
    Categories:
      type: array
      items:
        $ref: '#/components/schemas/Category'
  parameters:
    Id:
      in: path
      name: id
      required: true
      description: The id of the resource.
      schema:
        type: integer
    Offset:
      in: query
      name: offset
      required: true
      schema:
        type: integer
        minimum: 1
    Limit:
      in: query
      name: limit
      schema:
        type: integer
        minimum: 1
      required: true

Error message:
panic: Validating Swagger failed: Found unresolved ref: '#/components/parameters/Offset'

goroutine 1 [running]:
github.com/getkin/kin-openapi/openapi3filter.(*Router).WithSwagger(...)
        /go/pkg/mod/github.com/getkin/kin-openapi@v0.1.1-0.20190210195911-82a13f94c08e/openapi3filter/router.go:83
main.load(0x7ffec0fd2f65, 0x16, 0xc000132000, 0x1e8a, 0x208a, 0x0, 0x0)
        /apisprout/apisprout.go:311 +0x272
main.server(0xc000130280, 0xc000089650, 0x1, 0x1)
        /apisprout/apisprout.go:391 +0x2ba
github.com/spf13/cobra.(*Command).execute(0xc000130280, 0xc000092030, 0x1, 0x1, 0xc000130280, 0xc000092030)
        /go/pkg/mod/github.com/spf13/cobra@v0.0.3/command.go:766 +0x2ae
github.com/spf13/cobra.(*Command).ExecuteC(0xc000130280, 0x95fca3, 0xc, 0x0)
        /go/pkg/mod/github.com/spf13/cobra@v0.0.3/command.go:852 +0x2c0
github.com/spf13/cobra.(*Command).Execute(...)
        /go/pkg/mod/github.com/spf13/cobra@v0.0.3/command.go:800
main.main()
        /apisprout/apisprout.go:133 +0x6cb

Oh so sorry, but thanks so much for your test. Currently this pr just check reference object by relative path and network file

@azharprabudi API Sprout uses kin-openapi for parsing and resolving references. Additionally, in dee2f9ca5163466b49b2c5ebc097cae322332c58 we made a change to allow resolving external references like files and URLs.
If you are sure your use-case is not supported in the latest master code, then I would open a PR against the kin-openapi library instead of trying to fix this in API Sprout itself!

@northlander your example works fine in the latest API Sprout master branch:
# In one terminal tab
$ apisprout test.yaml
🌱 Sprouting test on port 8000
2019/03/10 21:49:16 GET /categories?offset=0 () => 200 (application/json)

# In another
$ http :8000/categories?offset=0
HTTP/1.1 200 OK
Access-Control-Allow-Headers: Accept, Content-Type, Content-Length, Accept-Encoding, X-CSRF-Token, Authorization
Access-Control-Allow-Methods: POST, GET, OPTIONS, PUT, DELETE
Access-Control-Allow-Origin: *
Content-Length: 45
Content-Type: application/json
Date: Mon, 11 Mar 2019 04:49:16 GMT

[
    {
        "id": 0,
        "name": "string"
    }
]

@danielgtaylor last week i tried apisprout using reference object (relative path and network), the openapi library just load them as reference object key and doesnt load the file from relative object

I submit my pr at here to kin openapi, to read $ref file inside path item


Add option to download whole threads with html/css/images

It would be nice to add an option so you can choose to only download the pictures from the thread (like 4scanner does now) or get the full webpage. This would be useful for scanning and downloading threads where you want to have the written posts content and not just the pictures.

Cool. We can use wkhtmltopdf.
I've use it before, it has so many different options: paper sizes, filelinks, header/footers, etc.
The documentation is here: http://wkhtmltopdf.org/usage/wkhtmltopdf.txt

I think that's a good idea but unfortunately it seems like we can't use it in python (without doing direct system call with something like os.system()). I don't really want to have a requirement in 4scanner that can't be installed with pip since it would make it harder for peoples to install and use it.
Using PDF to archive the threads would also mean references to other posts (ex: >>826745264) and features like expanding pictures would stop working. Making it harder to read the threads.
I think the best way would be to archive all the html/css/js and rebuild the page locally so everything would work like the original. This method is a bit inefficient tough because it would download a lot of duplicate stuff since the css/js etc are the same for every thread.
What do you think?

Hm.
OK, how about this: https://pypi.python.org/pypi/pdfkit/0.4.1
Try that and tell me how it goes.

Ok, I'll try playing with it soon. Right now I'm focusing on Issue #3 (and I'm almost done!) and I'll work on this next.

I just checked pdfkit but it seems like I still need to install wkhtmltopdf to be able to use it :(

Try looking at one of these: https://stackoverflow.com/questions/23359083/how-to-convert-webpage-into-pdf-by-using-python

A cool idea would also be to combine 4scanner with https://github.com/bibanon/BASC-Archiver

I'll check it out, thanks!


Change demo project to a submodule

We would like the demo repo to be more independent from the main repo.
A good solution for this would be to convert it to a submodule.
We could also add multiple submodules if needed.
We previously moved away from submodules (#82) so we need to make sure the side effects are minimal.

This is actually a great idea.
To complement some thoughts bout this:
Maybe stating a main project for getting started - for me it was unclear if this was the getting started  or the mnist demo for the extension-   Right now the readme mnist demo is under contributing and not under the project demo github link , found this is confusing.
Let me know if I can help you somehow with this 👍


Can’t run

The project can’t run on my Vivado 2019
Some drive letters are not correct
And hex file missing .
Can you post the bitstream as well
Thanks
Regards

Thanks for the report! Do you have any logs you can attach? The .hex file is included, but I wonder if the path is absolute instead of relative.

Initially once open the project file is read only .
Secondly the drive paths are not on the directory
Third the hex file is not available
I’ll get a screen shot later for you

That's helpful, thanks. I've tried changing the hex file's settings in the project to use a relative path. I'm setting up a clean windows VM to test it and see if it will work before committing. I'll keep you updated.

Thank you so much

I’ll try it today and see if it works

So I managed to display on the HDMI screen .
Awesome

It Mario is not running around 🥱

the code is good .
just need to make the mario runing .
it runs once you reset the esp32 so have to figure that out .

Great! I'll still check on my VM and figure out how to get the project to be machine independent.
For getting Mario to move around, there's a line in the sprite compositor right now that checks on FPGA pin B12, or ESP32 GPIO27, and only moves Mario when that signal is asserted. You can either comment out that code or write a program for the ESP32 that sets the signal to HIGH.
I probably should have worked on that on a separate branch.

Cool let me try that .

Thanks again. I think I found all of the issues with external file references and intermediate build products. I've linked the pull request I've made thanks to your efforts!

I have tried it today it works fine perfectly great work .


Updated documentation and added docker runtime check.

test_fuzzy_compile failed simply due to a timeout. You can re-run the action if you'd like, but the occasional timeout due to randomly generating very large workflows is expected and fine. Okay to merge in my opinion.


[Dubbo-1691] Add unit tests for MulticastRegister #1691

What is the purpose of the change
Add unit tests for MulticastRegister.
Fix #1691 , the MulticastRegister parts.
Brief changelog

Add unit tests for MulticastRegister
add some comments to methods
fix some typo

Verifying this change
Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Make sure there is a GITHUB_issue filed for the change (usually before you start working on it). Trivial changes like typos do not require a GITHUB issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[x] Format the pull request title like [Dubbo-XXX] Fix UnknownException when host config not exist #XXX. Each commit in the pull request should have a meaningful subject line and body.
[x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[x] Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add integration-test in test module.
[x] Run mvn clean install -DskipTests & mvn clean test-compile failsafe:integration-test to make sure unit-test and integration-test pass.
[x] If this contribution is large, please follow the Software Donation Guide.

The reason that I did not correct them is they have some public method related to names, if modified, the public interface will be damaged.

@satansk I think it is safe to change the typos you mentioned in the MulticastRegistry, because they are private variables. What public interface will be damaged?

@ralf0131 sorry for my mistake, they are private, so I will correct them.


related resource filter can depend on a side-effect

Given this policy based largely on the examples from #541 (and the code that fixed it), an exception will be triggered.
policies:
  - name: related-rds-test
    description: |
      If databse is using default security group, adjust the retention.
    resource: rds
    filters:
      - type: security-group
        match-resource: true
        key: "GroupName"
        value: "default"
    actions:
      - type: retention
        days: 14

Specifically, this will happen any time match-resource is True and key doesn't start with “tag:”.
Traceback (most recent call last):
  File "cloud-custodian/c7n/policy.py", line 167, in run
    resources = self.policy.resource_manager.resources()
  File "cloud-custodian/c7n/query.py", line 152, in resources
    return self.filter_resources(resources)
  File "cloud-custodian/c7n/manager.py", line 63, in filter_resources
    resources = f.process(resources, event)
  File "cloud-custodian/c7n/filters/related.py", line 96, in process
    return [r for r in resources if self.process_resource(r, related)]
  File "cloud-custodian/c7n/filters/related.py", line 70, in process_resource
    self.data['value'] = self.get_resource_value(
  File "cloud-custodian/c7n/filters/core.py", line 274, in get_resource_value
    self.expr = jmespath.compile(self.k)
AttributeError: 'SecurityGroupFilter' object has no attribute 'k'

The policy passes validation.
The problem is
https://github.com/capitalone/cloud-custodian/blob/master/c7n/filters/related.py#L69
self.get_resource_value() can depend on self.k in some cases, but that’s only set up as a side-effect of calling self.match().
Just calling self.match(None) first will set up the properties then bail, which seems to work, but also seems like a hack.
Moving lines 68-70 down below the for loop also seems to work, but I'm unsure of the impact. (The calls to self.match() could be influenced by the change to self.data['value'].)

i think the issue is that it should be using the passed in key/k instead of self.k


Improving cache hit ratio

My company recently deployed the serverless image handler, and it was a breeze - nice work! One thing we've noticed that has been a little surprising is a lower than expected CloudFront cache hit ratio, and we'd love to be able to get the Lambda costs down. My assumption is that the serverless image handler is caching at each CloudFront edge location, so for a given image requested from several places around the globe, it will need to hit the lambda multiple times. Over time, those cached items will expire and will need to be re-hydrated again. Is that correct?
Assuming that's what's going on, a couple options come to mind for optimizing the hit ratio:

Cache the converted images in S3, rather than relying solely on the CloudFront cache. Storage costs would be higher, but it would need to hit the lambda exactly once for a given set of image parameters. This would obviously require some fundamental changes to the serverless-image-handler.

For a lighter approach, would CloudFront Origin Shield solve this problem? Would need to crunch the numbers to evaluate cost implications, but it seems like it exists for this sort of use case.

Thanks in advance for any guidance, and please let me know if there are any other options I am not considering.

Hi @ddonahue99 , do you have any experience with the CloudFront Origin Shield? I'm just thinking about using it too to at least somehow limit the Lambda execution count/time..

Hi @Buthrakaur - Since posting this, I've made a few changes that have greatly improved the hit ratio, including enabling Origin Shield (which resulted in a modest improvement).
The more notable impact, however, was modifying the CloudFront cache settings. I bumped the TTL up to the max (1 year) and changed the cache key to not include the origin and accept headers. From what I could tell, the accept header is part of the cache key by default for the AUTO_WEBP setting, which makes sense, because depending on the client, the response could be webp or jpeg or whatever other fallback you specify. If you are not using AUTO_WEBP, the response will always be the same, so it doesn't make sense to have roughly one cache entry per major browser:
Example of how accept headers vary by browser:
firefox = image/webp,*/*
safari = image/webp,image/png,image/svg+xml,image/*;q=0.8,video/*;q=0.8,*/*;q=0.5
chrome = image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8

With all of these changes, my application was hovering around a 70-75% hit ratio and is now closer to 96%.
Ultimately, the better solution for optimizing the hit ratio would be to permanently cache the output in S3. I'd still love to see that as a built-in option to this template. 🙏

Hi!
Noticed another possible improvement:
Current cache policy (the one provided by current version of serverless-image-handler), enables gzip compression which in turn adds the "accept-encoding" header to the cache key. But origin (resizing lambda) won't use it (¿am I missing something?) which makes sense because we are working with already compressed image-formats.
Notice that cloudfront enables auto compression only on image/svg+xml (see this) which also makes sense.
So, with current cache policy, two almost "equivalent" requests (from cloudfront's cache key perspective), except for the accept-encoding: gzip header presence, will generate different entries on the cache.
Please read this: "Cache Hit Ratio - Remove Accept-Encoding header when compression is not needed".

Hi @ddonahue99 , I am seeing that TTL configuration is already one year when image on s3 doesn't provide one: see this.
When s3 file provides a ttl it will use that one: see this.
Cloudfront will honor cache-control header from origin when it provides one.
Maybe... I am missing something? Please give us some details (I am currently working on improve hit ratio too).

Notice: making modifications to allow optional Origin Shield on the solution, is a little complicate on the current CDK definition (or at least I can't figure out a simple way). But a solution's user can modify the provided template.yaml to add it. It's as simple as:
  BackEndImageHandlerCloudFrontApiGatewayLambdaCloudFrontToApiGatewayCloudFrontDistribution03AA31B2:
    Type: AWS::CloudFront::Distribution
    Properties:
      DistributionConfig:
        ...
        Origins:
          - CustomOriginConfig:
            ...
+           OriginShield:
+             Enabled: true
+             OriginShieldRegion: us-west-2
            ...

As a simple workaround, I suggest to the mantainers adding it to the documentation.

One other possible optimization [0].
The following applies when we have NOT enabled a Default Fallback Image.
Thumbor requests without id [1] (such as "/fit-in/120x120/") are forwarded to the origin.
The Lambda backend receives the request and processes it with a 500 error including a message "Expected uri parameter to have length >= 1, but found "" for params.Key". In the first place, I would like to say that I think this an erroneous behavior because it isn't an error from the processing lambda but from the requester. I think that it should be handled as a 400 or arguably a 404 status code [2]. But that's a topic for another issue.
The important thing here is that we could avoid making a request to the origin, just using a CloudFront Function (o a Lambda@Edge extension) matching the incorrect path.
I'll show an example:
+  BackEndCfnFunctionFB18E3BF:
+    Type: AWS::CloudFront::Function
+    Properties:
+      Name: fastNotFoundResponseFunction
+      AutoPublish: true
+      FunctionCode:
+        Fn::If:
+          - CommonResourcesEnableCorsConditionA0615348
+          - Fn::Join:
+              - ""
+              - - |-
+                  function handler(event) {
+                    // Notice: cannot modify body on fast responses from Cloudfront Functions. But we should be ok with that.
+
+                    if (event.request.method == 'GET') {
+                      var fastNotFoundPathsRegex = new RegExp('^/fit-in/[0-9]+x[0-9]+/?$');
+
+                      if (fastNotFoundPathsRegex.test(event.request.uri)) {
+                        return {
+                          statusCode: 404,
+                          statusDescription: 'Not Found',
+                          headers: {
+                            'content-type': { value: 'application/json' },
+                            'access-control-allow-methods': { value: 'GET' },
+                            'access-control-allow-headers': { value: 'Content-Type, Authorization' },
+                            'access-control-allow-credentials': { value: 'true' },
+                            'access-control-allow-origin': { value: '
+                - Ref: CorsOriginParameter
+                - |-
+                  ' }
+                          }
+                        };
+                      }
+                    }
+
+                    return event.request;
+                  }
+          - |-
+            function handler(event) {
+              // Notice: cannot modify body on fast responses from Cloudfront Functions. But we should be ok with that.
+
+              if (event.request.method == 'GET') {
+                var fastNotFoundPathsRegex = new RegExp('^/fit-in/[0-9]+x[0-9]+/?$');
+
+                if (fastNotFoundPathsRegex.test(event.request.uri)) {
+                  return {
+                    statusCode: 404,
+                    statusDescription: 'Not Found',
+                    headers: {
+                      'content-type': { value: 'application/json' },
+                      'access-control-allow-methods': { value: 'GET' },
+                      'access-control-allow-headers': { value: 'Content-Type, Authorization' },
+                      'access-control-allow-credentials': { value: 'true' }
+                    }
+                  };
+                }
+              }
+
+              return event.request;
+            }
+      FunctionConfig:
+        Comment: Returns not-found responses to some already know to be existent but frequently requested paths.
+        Runtime: cloudfront-js-1.0
      ...
  BackEndImageHandlerCloudFrontApiGatewayLambdaCloudFrontToApiGatewayCloudFrontDistribution03AA31B2:
    Type: AWS::CloudFront::Distribution
    Properties:
      DistributionConfig:
        ...
        DefaultCacheBehavior:
          ...
+          FunctionAssociations:
+            - EventType: viewer-request
+              FunctionARN:
+                Fn::GetAtt:
+                  - BackEndCfnFunctionFB18E3BF
+                  - FunctionARN
          ...

Notice:

CloudFront Functions cannot include a response body (only headers and status code are allowed). Lambda@Edge allows that (but I am staying with CloudFront Functions for simplicity and speed).
returning 404 as previously discussed.

Of course, this approach can also be applied to some other previously know to be always invalid/not existent (but frequently requested) paths.
As with optionally enabling Origin Shield (see my previous message), enabling this code based on EnableDefaultFallbackImageParameter value is a little complication on the current CDK definition (or at least I can't figure out a simple way). But readers can make a custom modification of the base template.yaml.
[0] = being strict, the proposal here is not a cache optimization: CloudFront Functions are run before using cache. But might avoid making requests to the origin, which, in the end, achieves the same.
[1] = and maybe no-Thumbor requests too, I don't know because I don't use them, and I know almost nothing about them.
[2] = notice that current cloudfront's configuration caches 500 status code responses for ten minutes, where as it caches 400/404 status code responses for only ten seconds.

As a picture is worth a thousand words, these are my results (invocations on backend lambda) after applying all these things at the same time; sorry that was what I did, so I cannot show them one at a time.
That is:

removing "accept" header from cache key PLUS
disabling gzip compression (removing accept-encoding from cache key) PLUS
enabling Origin Shield PLUS
using CloudFront Functions to answer incorrect but yet frequently requested paths (I am not using "Default Fallback Image", my consumers resolve that, but that's only my case).

Initial peak is attributable to old caches invalidation due to cache key conformation being modified.

But @ddonahue99 proposal of caching converted images on s3 would be a very important improvement, because CloudFront's caches (I understand that this applies to POPs, Regional and Shield caches) will discard less popular objects (please read this)

@fvsnippets It looks like you made a really meaningful dent, nice work and thank you for sharing all of your findings! I'm going to have to investigate the Accept-Encoding and fallback image tweaks on my end as well. It's been a while since we've revisited the configuration, but our hit ratio is still hovering around the low-to-mid 90s, so there's some more room for improvement.
If the AWS team is open to allowing for permanent caching in S3, I still agree that would have the biggest impact over the long-term. This solution is not the most efficient as-is for performance/cost at scale.

maybe i'm wrong, but the main issue with doing straight serving from s3 in cloudfront is how to map the cloudfront cache key to a filename, especially when using things like AUTO_WEBP (and especially once AUTO_WEBP also does AUTO_AVIF ;)) without adding the runtime cost of another lambda edge call (time, and money).
I suppose it could be dealt with by the image handler, by having it check a CACHE_BUCKET once it has fully resolved all parameters, and immediatly prior to actually loading the image from the SOURCE BUCKET and performing operation.
if present, return it, as if it had been through the entire process, and if not, proceed and store the output to the CACHE_BUCKET.
it does mean, it will not do CDN => CACHE_S3? => API-GW, but instead CDN => API-GW => CACHE_S3, so you wont save on the api-gw calls, but you /will/ save on customer wait time for items that are already processed once.

Maybe it can be enabled only under certain circumstances (AUTO_WEBP not enabled, etc) and only for certain paths (e.g. Thumbor resize). I understand that CloudFront allows the latter by using origin groups (but I haven't read enough/have experience on that topic to tell for sure).

I think my main concern is with not storing already processed items is, if i upload nice and juicy 10mb pngs as source images, it takes 5-10 seconds to turn it into an avif (after bumping sharp to .30 and adding it as a valid format) which is not going to be a smooth experience to the end user.
But honestly i have no idea what number of cache-evictions i would be looking at under normal circumstances (just started playing with this lib), but my site does have a few hundreds of thousands of images, and with 8 size variants for each, in 3 potential formats (avif, webp, jpg) it does add up, especially if it also adds a cachekey pr accept-header variant, (which for /some/ internet explorer/edge variants seem to include every office program installed)
If anyone has/is willing to share some experience on this, that would be great.
I was wondering if maybe a cloudfront function could be used to “normalize” the accept header into, maybe, only the optimal image/ prefix the client can understand, and use that as the cache key?

For what its worth, i tried adding this to the backend-end-construct.ts

    // Add a cloudfront Function to normalize the accept header
    const normalizeAcceptHeaderFunction = new Function(this, 'Function', {
      functionName: `normalize-accept-headers-${Aws.REGION}`,
      code: FunctionCode.fromInline(`
            function handler(event) {
              if (event.request.headers && event.request.headers.accept && event.request.headers.accept.value) {
                var resultingHeader = "image/jpg";
                var acceptheadervalue = event.request.headers.accept.value;
                if (acceptheadervalue.indexOf('image/avif') > -1) {
                  resultingHeader = 'image/avif';
                } else if (acceptheadervalue.indexOf('image/webp') > -1) {
                  resultingHeader = 'image/webp';
                }
                event.request.headers.accept = { value: resultingHeader };
              }
              return event.request
          }

      `),
    });```

and wired it up further down

const cloudFrontDistributionProps: DistributionProps = {
comment: 'Image Handler Distribution for Serverless Image Handler',
defaultBehavior: {
origin: origin,
compress: false,
allowedMethods: AllowedMethods.ALLOW_GET_HEAD,
viewerProtocolPolicy: ViewerProtocolPolicy.HTTPS_ONLY,
originRequestPolicy: originRequestPolicy,
cachePolicy: cachePolicy,
functionAssociations: [{
function: normalizeAcceptHeaderFunction,
eventType: FunctionEventType.VIEWER_REQUEST,
}]

And it does seem to work, for the AutoWebP scenario, where you just want to return the best possible representation the client can consume.

Ie

curl -H "accept: image/webp,image/gif" https://xxx.cloudfront.net/fit-in/800x800/sample-10mb.png -vvv --output /dev/null
gives a cache miss on first access (and hits afterwards) but

curl -H "accept: image/webp,image/jpg,image/*" https://xxx.cloudfront.net/fit-in/800x800/sample-10mb.png -vvv --output /dev/null
gives a cache-hit because the accept header is rewritten to just `image/webp`

Now, i realize this will probably conflict with other features, and request-specific requests for formats. Ie if you explicitly ask for a jpg in the transformations, it would cache it with an the image/web accept header, but....i suppose it will still actually RETURN content type image/jpg, and the filename/path part will already make it unique for requests that ask for transformation to jpg. Unsure if this is a problem, really...

It would be super nice to have a comprehensive guide of things to do for people who are just getting started with "improving cache hit ratio", I can see several improvements are mentioned above, but I'm not sure how that should translate in "configuration updates". Could someone clarify if/what should be done?

We will evaluate adding to the Implementation Guide some information on this subject.

Hi AWS team,
I am bringing this task to your attention as I think it is an absolute must to improve the cache ratio. This task has been open for two years already and no steps have been taken to improve it. We have 50+ websites where we use this image handler and are running high costs because of this.
In this task I read a lot of improvements from small to big and there are even many PR's ready to be checked like this one. Could you please prioritize this?

hi everyone! I started working on S3 caching today using a hash of image request info as an additional key.
It works by checking s3 in the lambda function before performing processing.
here's the basic approach: https://github.com/wonathanjong/sls-img-cache
let me know what y'all think :)

Also I'm not going to do this now but I believe that the

best implementation would be:

to create an origin group behind cloudfront (primary is s3 and secondary is api gateway)
when making requests to cloudfront distribution, you base64 encode the request
after processing a new image in lambda, store the image in s3 with the base64 encoded string as the key
then, when request is made to cloudfront, it is first routed to the s3 bucket with the base64 encoded string key
if s3 returns a 404, fallback to secondary origin which is api gateway and handles dynamically processing the image.


Texture bleeding for tiled maps 🐛

We are currently experiencing the issue described here.
This needs to be fixed as part of the TiledMapManager.

This is rather a pipeline problem than a libgdx issue.


temporarily sold out of Cloud Bigtable in this zone

GCB: https://console.cloud.google.com/cloud-build/builds;region=us-east1/0898b0b2-ec10-48b7-96f6-5738cd2d3b4e;tab=detail?project=cloud-cpp-testing-resources
Raw: https://storage.googleapis.com/cloud-cpp-community-publiclogs/logs/google-cloud-cpp/main/a77384029967e29a8aba67e688a8a9ea45b4dc91/fedora-37-bazel-integration-daily/log-0898b0b2-ec10-48b7-96f6-5738cd2d3b4e.txt

google/cloud/bigtable/tests/instance_admin_integration_test.cc:129: Failure
Value of: instance_2
Expected: code is equal to OK and message is anything
  Actual: 144-byte object <A0-6F 03-58 E2-7F 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 ... 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00>, whose status is CANCELLED: Operation successfully rolled back : Not enough servers to allocate the requested nodes. We have temporarily sold out of Cloud Bigtable in this zone. Our support team has been notified and will be bringing more resources on board. Please try a different zone or try again later., with a code that isn't equal to OK, but a message that is anything

This is mostly an "external" failure, although, if it is an ongoing possibility then we should probably handle it more gracefully.
Still, there was a follow-on error that we should address in google/cloud/bigtable/tests/instance_admin_integration_test.cc:
  auto instance_1 = instance_1_fut.get();
  auto instance_2 = instance_2_fut.get();
  EXPECT_STATUS_OK(instance_1);
  EXPECT_STATUS_OK(instance_2);

  EXPECT_EQ(instance_1->name(), name_1);
  EXPECT_EQ(instance_2->name(), name_2);

The EXPECT_STATUS_OK() calls should be ASSERT_STATUS_OK() if we're going to unconditionally dereference the instances.

Getting the same error
Step #3: google/cloud/bigtable/tests/instance_admin_integration_test.cc:130: Failure
Step #3: Value of: instance_2
Step #3: Expected: code is equal to OK and message is anything
Step #3: Actual: 144-byte object <50-F9 01-A4 E8-7F 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 ... 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00>, whose status is CANCELLED: Operation successfully rolled back : Not enough servers to allocate the requested nodes. We have temporarily sold out of Cloud Bigtable in this zone. Our support team has been notified and will be bringing more resources on board. Please try a different zone or try again later., with a code that isn't equal to OK, but a message that is anything
Step #3:

Build FAILURE: integration-daily https://console.cloud.google.com/cloud-build/builds;region=us-east1/6e057656-5a72-4913-9ed8-6753036694f8?project=936212892354

I think this is the admin api: instance_admin_integration_test


stim integration in the CssCodeCircuit class

(method) to_stim_circuit() generates the two stim circuits for the two logical '0' and '1' and an additional list of measurement data to be used by the get_counts_via_stim
(method) get_counts_via_stim() calls self.to_stim_circuit() to generate the stim circuit for one of the logicals ('0' by default) and generates sample strings in the qiskit format

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


updated readme file to document how to change the default mount_point.

I found myself in a situation that I had to change the default mount_point. As I didn't find this in the Readme, I thought I should open this PR to help others who want to do this.
Thank you so much for your work.

Thanks!


Why is RigidBody2D's friction clamped to 0.0 to 1.0?

Godot version: Godot_v3.0-rc1
Godot allows you to go and raise the friction much higher if you us Physics2DServer. Why is it clamped in the node?

The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older issues that are not bugs on the main issue tracker.
If you are interested in developing this into a feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!


Extension update: Mouse helper

Added Smoothing animation option for the mouse cursor extension

Game Preview
https://liluo.io/games/c1ef6005-d51f-4c35-8f7f-6b306593c4b6
Project Files
mouse-helper-update.zip

Might be a bug with the example, when I enable the smooth it works, when I disable it the smooth is still there.
@tristanbob have you faced a similar problem with the checkbox in the past?


Bubble up errors while loading Resources

Errors are bubbled up to the app via a new NavigatorDelegate method:
navigator(_:didFailToLoadResourceAt:url:withError)

No breaking changes to the Navigators client-facing APIs.
This solves issue https://github.com/readium/swift-toolkit/issues/398.
The 2nd commit depends on PR https://github.com/readium/GCDWebServer/pull/11. It is not strictly required but it is nice to have, because it attaches the underlying error to the GCDWebServerErrorResponse.

ugh the build fails because of that GCDWebServer PR. Let me know what you think of it, and if needed I can just nuke the 2nd commit in this PR.

The changes to HTTPServer are breaking the semantic versioning. We could either switch the base branch to v3, or maintain the old HTTPServer APIs with fallbacks. What do you prefer?

🤔 I have not looked into v3 so I don't know what changes it entails on our end. If migrating to v3 is not going to be a big effort, maybe that's doable.
For the other option, do you mean having HTTPServer include both versions of the api, meaning:
// new
func serve(at endpoint: HTTPServerEndpoint,
           handler: @escaping (HTTPServerRequest) -> Resource,
           failureHandler: FailureHandler?) throws -> URL
// old
func serve(at endpoint: HTTPServerEndpoint, handler: @escaping (HTTPServerRequest) -> Resource) throws -> URL

where basically the old one simply calls the new one with a nil failureHandler (perhaps in a protocol extension)?

I plan to release at least one other minor version from develop before v3 is released.

👍 In this case the 2nd option with fallbacks might be better. It would be preferable for us to be able to use this new stuff sooner rather than later. (And I'd prefer to avoid targeting develop for our production builds 😅 )

That's right, keeping the old APIs and just forwarding the calls to the new ones could be enough here. 👌

I am looking into the errors on the "Local" and "SPM" checks, but the build log is truncated and very hard to browse. I have a hunch these errors are maybe on the TestApp (which I am no longer using), because the actual toolkit actually compiles fine locally.
I wonder if the build logs could be improved, perhaps with xcpretty? we've been using it and it makes the build logs much clearer because it highlights the errors and it is more succinct for the commands that succeed.  IIRC it is provided by GitHub out of the box, so I could try adding it to the xcodebuild commands.

I was able to build the TestApp and fix all the regressions 😅 I also fixed a couple easy warnings in the TestApp.
I ended up adding xcpretty since it was very simple to do so and the benefits are big. There's a night and day difference in how the logs are easier to read (before | after). It did help in diagnosing the problem from the logs, which was not possible before. There's some script-code duplication in the workflow, but hopefully that can be done at some other time.

I changed the NavigatorDelegate API to /.../ require a non optional href, as it identifies a particular resource. This is to be consistent with the same Kotlin API.

I tested my code with this change and the errors I was observing are still being reported, so this should be ok, I think. But I do worry though that the failureHandler calls where the HTTPServerRequest::href is nil (here, here and here) are now not going to reach the navigator side since we filter for a non-optional href.

But I do worry though that the failureHandler calls where the HTTPServerRequest::href is nil (here, here and here) are now not going to reach the navigator side since we filter for a non-optional href.

These are outside the scope of broken publication resources, so they should not be reported with NavigatorDelegate.didFailToLoadResourceAt. If they occur, there's probably something wrong in the app itself which should be fixed by the integrator.
Although I would be open to add a global fallback failure handler directly in the GCDHTTPServer type, that applications could provide when creating the server.

These are outside the scope of broken publication resources, so they should not be reported with NavigatorDelegate.didFailToLoadResourceAt. If they occur, there's probably something wrong in the app itself which should be fixed by the integrator.
Although I would be open to add a global fallback failure handler directly in the GCDHTTPServer type, that applications could provide when creating the server.

I was even just thinking something like another "catch all" delegate method to do something like this
guard let href = href else {
    self.delegate?.epubNavigatorViewModel(self, didFailWithError: error)
    return
}
self.delegate?.epubNavigatorViewModel(self, didFailToLoadResourceAt: href, withError: error)

I did not propose it because it's still unclear to me when the case of a nil href actually happens.  In any case I agree this is beyond the scope of Resource loading fails. We'd also be risking delegate callback pollution. 😅
Thanks for merging the PR! 🎉


Allow to configure path to bash-language-server

When using a version manager like nvm VS Code will not have the npm I am using in the PATH, only the shell. Since I have many versions of node/npm installed, I would like to tell the VS Code extension to use a specific one. This could also be useful for debugging.

@felixfbecker This is a great idea. I'd be more than happy to accept a PR adding it 👍


DB and API for Squeeze bot points

Background:
Some bots will have reward points associated with them. We will therefore need to store these points per bot in the DB, calculate the points when a new bot record is created and retrieve the points for active and completed bots.
Figma | Notion
Done when

[ ] We can store the following fields per bot in the DB on the bot server:

[ ] ezEth points
[ ] Eigenlayer points
[ ] squeeze points

[ ] The FE can retrieve these values for a specific bot (note that not all bots will have points, so a separate API endpoint may make more sense)
[ ] The points are calculated when a new bot record is created. Exact formula tbd, but it will depend on leverage and the deposit amount

https://gist.github.com/rootedbox/e0b5bb036ec6ebc217b322d9a6c9d9f1
code needed to be added to any robot that needs points.


[Bug]: syntax error when creating a table contains column with geometry datatype

ODC version
ODC421
OB version
Oceanbase4.1.0
What happened?
There is a syntax error when creating a report, but the sql is executed successfully

What did you expect to happen?
execution succeed
How can we reproduce it (as minimally and precisely as possible)?
Execute the following sql
create table if not exists `t1_g` (
	`id` int(11),
	`name` varchar(18),
	`g` geometry not null
)
default charset=utf8mb4
default collate=utf8mb4_general_ci;
create index `t1_g_idx1` on `t1_g` (`g` ASC);

Anything else we need to know?
No response
Cloud
No response

geometry is a new datatype involved in OceanBase 4.x, our parser ignore it, we may add this syntax to fix this bug

pass


File type param uses wrong name in both docs UI and when sending test request from docs.

Grape swagger is working brilliantly for all my endpoints apart from this one that requires a File param. The grape api endpoint works fine and all params validate when I call the api from my own code but the auto generated swagger docs are not working right with this one param. Here's the param validation code:
params :requires_pdf_data do
    requires :data, type: Rack::Multipart::UploadedFile, desc: 'Mulitpart file upload accepts application/pdf'
end

And here's a screenshot of how swagger shows that param:

When I call the endpoint from my own code it works perfectly but from swagger it always says that the data param is missing. Is this a bug or am I missing something? Any ideas?

Is there code in grape-swagger or swagger-ui that is wrongly labelling the param "body" when it's called "data" in the param validation?

I would compare the HTTP requests next.

@dblock Hi. Yeah, tried that and the "body" param doesn't even feature in the POST params sent when you click the "try it out!" button. So not only is the "data" param being wrongly named it is also not being sent in the POST form data.

I have the same issue. Did someone fixed it?

I'm not sure, if it is relevant to swagger-1.2, but in 2.0 for file uploads the param_type must be formData, the type must be file and consumes must be either multipart/form-data or application/x-www-form-urlencoded, maybe setting this would fix it …

It works. Thanks.


Move metadata organization business rules away from metadata assembler

This issue is imported from pivotal - Originaly created at Jan 16, 2020 by Michiel Kodde
In #170401380, I wondered why all organization metadata for a given language must be present in order to display them in the metadata. Turned out this is part of the SAML specification.
We (Thijs and myself) observed the current location where this rule is enforced might not be the best. As we are losing data that might be usefull elsewhere? Or maybe the assembler should not be concertned with applying these rules.
Come up with a better solution for this, or at least document this rule in the assembler if we are not going to offload this logic elsewhere.
For some context see:
https://www.pivotaltracker.com/story/show/170401380/comments/210472845

The logic was moved to the decorators (sp and Idp). And the template uses a verification method to inform if the organization data should be shown on the metadata. (Michiel Kodde - Aug 11, 2020)


TextInput inside Swiper fires onFocus when swiping

Hi!
Thanks for the awesome library.
The below issue is happening out of the box with react-native-swiper. I'm not sure if this is related to general ScrollView behavior, but it does not make sense to me.
        <Swiper style={styles.wrapper} showsButtons={true}>
          <View style={styles.slide1}>
            <Text style={styles.text}>Hello Swiper</Text>
          </View>
            <TextInput
              style={{backgroundColor:'white', width: 300, height: 40}}
              onFocus={ () => alert('focused')}
              onBlur={ () => alert('blurred')}
            />
          <View style={styles.slide3}>
            <Text style={styles.text}>And simple</Text>
          </View>
        </Swiper>

When swiping, if you drag on top of TextInput, it will focus it, then blur it.
See gif

I also tried the above with just using ScrollView and got it to replicate sometimes (not always).
Any thoughts on this?

@petrgazarov ever get anywhere with this? running into this consistently :/

I'm running in to something similar, wonder if this could be taken a look at?

Anyone make any progress with this? Thanks


GPS cannot update location

Hi there, Installed this addon but I still cannot get a GPS location.
I know that my GPS only operates at a BAUD of 4800,
Upon booting my PI, I run
cat /dev/ttyUSB0
And I get no output. Then if I run,
stty -F /dev/ttyUSB0 4800 followed by cat /dev/ttyUSB0
I instantly get the NMEA data.
I have set a BAUD of 4800 in your addon settings, however I am afraid it might not actually be setting the port for a BAUD of 4800.
Do you have any ideas for this?
Thanks

Thanks for reporting this. Let me look into it quickly. :)

Thanks,
Also, using Raspberry PI 4, and using the onboard UART for GPS, I am getting the following.
s6-rc: info: service s6rc-oneshot-runner: starting s6-rc: info: service s6rc-oneshot-runner successfully started s6-rc: info: service fix-attrs: starting s6-rc: info: service fix-attrs successfully started s6-rc: info: service legacy-cont-init: starting s6-rc: info: service legacy-cont-init successfully started s6-rc: info: service legacy-services: starting s6-rc: info: service legacy-services successfully started setserial: can't set serial info: Operation not permitted s6-rc: info: service legacy-services: stopping s6-rc: info: service legacy-services successfully stopped s6-rc: info: service legacy-cont-init: stopping s6-rc: info: service legacy-cont-init successfully stopped s6-rc: info: service fix-attrs: stopping s6-rc: info: service fix-attrs successfully stopped s6-rc: info: service s6rc-oneshot-runner: stopping s6-rc: info: service s6rc-oneshot-runner successfully stopped
,
Thanjs

Could you turn on debugging and try again? See if we get more information.

Hi there,
I've had another look at this and now something strange is hapenning. My GPS used to work, I could get a stream via
cat /dev/ttyS0
However, now it is just spitting out a bunch of garbage.
Is it possible this addon has changed some settings on my GPS as there is no other logical explanation for this.
Thanks

Please see the video
https://github.com/corvy/ha-addons/assets/71812804/f3b08df3-1f53-4326-a8df-a15dd62d81a7

Seems like the serial port settings is wrong somehow.
What is the output of
stty < /dev/ttyUSB0

Output is
-bash: /dev/ttyUSB0: No such file or directory
This is now a directly connected RS232 GPS and it was working with cat /dev/ttyS0
Something strange has happened as now the output is as above, and no wiring or anything has changed?

Sorry, do the same with the right tty device :)
stty < /dev/ttyS0
You probably have to stop the addon before so the device is not busy.
After, you could try the following to see if you get proper NMEA sentences again.
stty -F /dev/serial0 raw 4800 cs8 clocal -cstopb

When attempting to start, I get the following.
s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service legacy-cont-init: starting
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-services successfully started
**Setting up serial device with the following: /dev/ttyS0 9600 cs8 clocal -cstopb
setserial: can't set serial info: Operation not permitted**
s6-rc: info: service legacy-services: stopping
s6-rc: info: service legacy-services successfully stopped
s6-rc: info: service legacy-cont-init: stopping
s6-rc: info: service legacy-cont-init successfully stopped
s6-rc: info: service fix-attrs: stopping
s6-rc: info: service fix-attrs successfully stopped
s6-rc: info: service s6rc-oneshot-runner: stopping
s6-rc: info: service s6rc-oneshot-runner successfully stopped

Any ideas?

Hello! This all seems a bit odd.
Are you able to get sane NMEA sentences from the serial device from the host now? When you force it to 4800 baud speed?
If you stop the addon, go to the host terminal and run the following
stty -F /dev/ttyS0 raw 4800 cs8 clocal -cstopb
cat /dev/ttyS0

Add sudo in front if not root. Does that work?

Also made a small change to the add-on now. It seems that GPSD daemon does not use the set serial speed unless I specify it on start. Added that now, and I am able to change my speed using the options. So please try to update to 2024.2.0 and set the serial port information and speed in config and try again. 4800 should work now I hope.
Fingers crossed. :)

Since the update, it cannot connect to MQTT.
2024-02-20 14:23:35,751 - MQTT Publisher - WARNING - Disconnected from MQTT broker. Attempting reconnection...
2024-02-20 14:23:35,752 - MQTT Publisher - INFO - Trying to reconnect to MQTT broker (attempt 1 of 10)...
2024-02-20 14:23:57,752 - MQTT Publisher - WARNING - Disconnected from MQTT broker. Attempting reconnection...
2024-02-20 14:23:57,752 - MQTT Publisher - INFO - Trying to reconnect to MQTT broker (attempt 1 of 10)...
2024-02-20 14:24:14,244 - MQTT Publisher - INFO - Published 11 updates in the last 2.0 minutes
2024-02-20 14:24:19,754 - MQTT Publisher - WARNING - Disconnected from MQTT broker. Attempting reconnection...
2024-02-20 14:24:19,755 - MQTT Publisher - INFO - Trying to reconnect to MQTT broker (attempt 1 of 10)...
2024-02-20 14:24:41,748 - MQTT Publisher - WARNING - Disconnected from MQTT broker. Attempting reconnection...
2024-02-20 14:24:41,748 - MQTT Publisher - INFO - Trying to reconnect to MQTT broker (attempt 1 of 10)...
2024-02-20 14:25:01,758 - MQTT Publisher - WARNING - Disconnected from MQTT broker. Attempting reconnection...
2024-02-20 14:25:01,758 - MQTT Publisher - INFO - Trying to reconnect to MQTT broker (attempt 1 of 10)...
2024-02-20 14:25:23,752 - MQTT Publisher - WARNING - Disconnected from MQTT broker. Attempting reconnection...
2024-02-20 14:25:23,752 - MQTT Publisher - INFO - Trying to reconnect to MQTT broker (attempt 1 of 10)...
2024-02-20 14:25:44,757 - MQTT Publisher - WARNING - Disconnected from MQTT broker. Attempting reconnection...
2024-02-20 14:25:44,757 - MQTT Publisher - INFO - Trying to reconnect to MQTT broker (attempt 1 of 10)...
2024-02-20 14:26:06,749 - MQTT Publisher - WARNING - Disconnected from MQTT broker. Attempting reconnection...
2024-02-20 14:26:06,749 - MQTT Publisher - INFO - Trying to reconnect to MQTT broker (attempt 1 of 10)...
2024-02-20 14:26:14,352 - MQTT Publisher - INFO - Published 11 updates in the last 2.0 minutes
2024-02-20 14:26:28,755 - MQTT Publisher - WARNING - Disconnected from MQTT broker. Attempting reconnection...
2024-02-20 14:26:28,755 - MQTT Publisher - INFO - Trying to reconnect to MQTT broker (attempt 1 of 10)...
2024-02-20 14:26:49,754 - MQTT Publisher - WARNING - Disconnected from MQTT broker. Attempting reconnection...
2024-02-20 14:26:49,754 - MQTT Publisher - INFO - Trying to reconnect to MQTT broker (attempt 1 of 10)...
2024-02-20 14:27:11,753 - MQTT Publisher - WARNING - Disconnected from MQTT broker. Attempting reconnection...
2024-02-20 14:27:11,754 - MQTT Publisher - INFO - Trying to reconnect to MQTT broker (attempt 1 of 10)...
2024-02-20 14:27:33,753 - MQTT Publisher - WARNING - Disconnected from MQTT broker. Attempting reconnection...
2024-02-20 14:27:33,753 - MQTT Publisher - INFO - Trying to reconnect to MQTT broker (attempt 1 of 10)...
2024-02-20 14:27:54,754 - MQTT Publisher - WARNING - Disconnected from MQTT broker. Attempting reconnection...
2024-02-20 14:27:54,754 - MQTT Publisher - INFO - Trying to reconnect to MQTT broker (attempt 1 of 10)...
2024-02-20 14:28:14,356 - MQTT Publisher - INFO - Published 11 updates in the last 2.0 minutes
2024-02-20 14:28:16,754 - MQTT Publisher - WARNING - Disconnected from MQTT broker. Attempting reconnection...
2024-02-20 14:28:16,755 - MQTT Publisher - INFO - Trying to reconnect to MQTT broker (attempt 1 of 10)...
2024-02-20 14:28:38,756 - MQTT Publisher - WARNING - Disconnected from MQTT broker. Attempting reconnection...
2024-02-20 14:28:38,756 - MQTT Publisher - INFO - Trying to reconnect to MQTT broker (attempt 1 of 10)...
2024-02-20 14:28:59,753 - MQTT Publisher - WARNING - Disconnected from MQTT broker. Attempting reconnection...
2024-02-20 14:28:59,754 - MQTT Publisher - INFO - Trying to reconnect to MQTT broker (attempt 1 of 10)...
2024-02-20 14:29:20,755 - MQTT Publisher - WARNING - Disconnected from MQTT broker. Attempting reconnection...
2024-02-20 14:29:20,755 - MQTT Publisher - INFO - Trying to reconnect to MQTT broker (attempt 1 of 10)...
2024-02-20 14:29:42,754 - MQTT Publisher - WARNING - Disconnected from MQTT broker. Attempting reconnection...
2024-02-20 14:29:42,755 - MQTT Publisher - INFO - Trying to reconnect to MQTT broker (attempt 1 of 10)...
2024-02-20 14:30:04,754 - MQTT Publisher - WARNING - Disconnected from MQTT broker. Attempting reconnection...
2024-02-20 14:30:04,754 - MQTT Publisher - INFO - Trying to reconnect to MQTT broker (attempt 1 of 10)...

Thanks

Might be a good thing. Seems that maybe we have a working GPSD now.
Looks like the connection worked sometimes (published 11 updates). Did you get a mqtt device device_tracker.gps_location in HA?
Do you see anything in the MQTT logs? Which mqtt broker do you use? Is it local on HA?
Also try to enable debug just to see if we get more info.

Ok, sorry.  I got confused as I am running 2 separate instances of HA at 2 different locations. My apologies.
All looks good now. It does look like I now have an entity with a published GPS location.
I do however have another question; how can I change the "Update Interval" of the location? Say send a GPSD update or location update to MQTT every 2 minutes for example.
Also, just a suggestion. Could you also provide additional entities for GPS speed, Long, Lat, and time etc published to MQTT so these show as separate entities?
Thanks again!

Thats very good news! :)
The addon publishes to MQTT every 10 seconds, if it has a fixed position to post. If there is no fix, no publish will happen. You can increase or decrease this if you like in the advanced settings by setting a preferred seconds amount in the addon.

The information you are looking for is available as attributes to the "device_tracker.gps_location". You can get these as separate entities if you do not want to use the attributes directly.
One way is to add via HACS: https://github.com/gjohansson-ST/attribute_as_sensor (not tried myself)
Or you could add it to configuration.yaml directly with the following code:
template:
  - sensor:
      - name: speed
        state: "{{ state_attr('device_tracker.gps_location', 'speed') }}"
        unit_of_measurement: "m/s"
      - name: lat
        state: "{{ state_attr('device_tracker.gps_location', 'latitude') }}"
      - name: lon
        state: "{{ state_attr('device_tracker.gps_location', 'longitude') }}"

I can have a think about if it is something we could add to advanced options for a future release.
Thanks for getting back to me and hope you enjoy the addon-on for your use case.

Hello, if you are fine with it I will close this ticket now. Please take contact if you need further assistance!
Best regards
Stian

Yes,
Thank you


Publish version 1.0

Crossbeam hasn't changed much in a long time. It may be time to publish 1.0 :)
My opinion is that all crates except for crossbeam-epoch have "peaked" and reached maturity. The thing about crossbeam-epoch is that its API is still not perfect and needs some improvement, mainly around custom collectors. But, even considering that, the API hasn't changed in a very long time, so why not just go for 1.0? If we decide to actually change it in the future, we can bump to 2.0.
I proposed we do the following now:

Bump minimum required Rust version to 1.36.0 (the one with MaybeUninit).
Fix CI.
Decide what to do with #416
Merge #431
Delete deprecated Backoff::is_complete().
Bump all crate versions to 1.0 and publish.

What does everyone think?

Exciting! SGTM. :)

Oooh, very excited for this!
The one point I think warrants some discussion is the MSRV policy, which I know is a topic many people have opinions on. As we've seen several times with CI breaking, other crates do not consider MSRV a part of their stability guarantee, so saying just "1.36" is inevitably going to cause us headache down the line. If that line is in the README, we need to commit to it for all of 1.0. Of course, if we don't commit to this, then we're a part of the problem. There isn't a good solution to this at the moment I think, but the least painful path probably lies in not committing to a particular version for the entire time of 1.0.
This has also been discussed in the past in https://github.com/crossbeam-rs/crossbeam/pull/428#issuecomment-542269227, https://github.com/crossbeam-rs/crossbeam/pull/458#issuecomment-576079793, and https://github.com/crossbeam-rs/crossbeam/pull/495#issuecomment-623162147.
My suggestion here is to say something like

Crossbeam supports stable Rust releases going back at least six months, and every time the minimum supported Rust version is increased, a new minor version is released. Currently, the oldest supported version is 1.36.

This is definitely a weakly held opinion, and is mostly motivated by the several issues we have seen over the past months (and years) where CI breaks, or where PRs need to make somewhat awkward workarounds to avoid bumping MSRV (maybe-uninit being an example). Not to mention all the ways in which we don't actually have the stated MSRV when different features are used (like alloc).

@jonhoo Good point, I agree with that. We should stop considering bumping MSRV a breaking change.

Agreed. That's roughly similar to the policy I use in core crates (msrv bumps only in minor versions and be somewhat conservative about it in general). I think six months is a decent spot.

I also agreed. (and "six months" sounds reasonable to me.)
Also, I'd propose:

Adjust Atomic::null()'s cfg to avoid #452 being a breaking change.
Change std feature to depend on alloc feature (alloc crate is available on 1.36, see https://github.com/crossbeam-rs/crossbeam/pull/368#discussion_r283091668 for why it was previously separated)
Remove deprecated Error::description impls.

In the same spirit with #452, I think custom allocators should also be integrated into the API.  It will greatly improve crossbeam's applicability to, e.g., embedded systems programming.  But will surely break backward compatibility.  I wish we will make it happen before reaching 1.0.

@jeehoonkang It might take a bit until allocator support is fully fleshed out, but it's not a problem if we publish 2.0 for crossbeam-epoch and consequently for crossbeam as soon as that is merged.
I currently don't have time to help work on that or review PRs. Would you perhaps like to take charge of crossbeam-epoch and keep improving it without being blocked on me?

It may be worthwhile to consider any changes to crossbeam-queue—I know that #277 and #338 raised questions on how to structure the API. If more specialized SPSC/MPSC/etc. queues are to be added in the future, that should be taken into account before stabilizing.
Out of curiosity, I assume the plan is to release crossbeams-skiplist at some point after 1.0?

Out of curiosity, I assume the plan is to release crossbeam-skiplist at some point after 1.0?

I'll be honest - I don't have the time to push it over the finish line :( But if anyone is interested in doing that, please go ahead! Really, anyone could do it - it just needs docs and that's all. The implementation is solid and finished.

It may be worthwhile to consider any changes to crossbeam-queue—I know that #277 and #338 raised questions on how to structure the API. If more specialized SPSC/MPSC/etc. queues are to be added in the future, that should be taken into account before stabilizing.

#277 didn't provide benchmark numbers that would warrant radically changing the crossbeam-queue crate, IMO. It would also be unfortunate to block stabilization on that if crossbeam-circbuf could simply be another competing crate.
#338 is yet another thing that is simply overflowing my plate :( But I've been meaning to get back to it. It doesn't need to block stabilization because it can be added to the crate after publishing 1.0 simply as a new feature.

Related issue about possible breaking changes for 1.0: #256.

Should a concurrent hash map be done for 1.0? Using similar algorithms from folly, c++, or java etc.

I think it's pretty unlikely that a concurrent hash map will be completed and agreed upon for a 1.0. Not to mention that adding something like that can be done without a breaking change :)

Related issue about possible breaking changes for 1.0: #256.

It's been nearly two years since #256 opened, so some may be outdated, but the five breaking changes mentioned in that issue there are:

Change the signature of Select::recv() and Select::send()
Use the word "closed" instead of "disconnected"
Rename Token
Make SendError and RecvError single-variant enums
Rename Timeout error variants to Empty/Full

I personally like 1 and 5. (I don't have a strong opinion as to which of the signatures proposed by 1 should be adopted.)
For 2, I don't have a strong opinion, but I'm starting to feel that rename makes sense given that "close" is used in most places except (soft-deprecated) std mpsc. (btw, @stjepang's async-channel crate also uses "close")
For 3, given that mio didn't finally rename it, probably we don't have to do it.
For 4, it does not seem to be a common pattern, so I tend to prefer not to do it.

Update - Here is a list of the remaining (breaking) changes I'm aware of:
Open issues

crossbeam-channel

Change the signature of Select::recv and Select::send (https://github.com/crossbeam-rs/crossbeam/issues/256#issuecomment-444604397)

crossbeam-epoch

Custom allocator support (https://github.com/crossbeam-rs/crossbeam/issues/503#issuecomment-631143806)
This may be postponed to 2.0.

crossbeam-utils

Should park_timeout report the reason for their return (timeout or unpark)? (#601)

I tend to accept them, but I'm not very clear about what APIs to add.
@jeehoonkang @Vtec234 Any thoughts about these (or some of these) changes?
Changes pending as breaking
They are accepted but blocked because they are breaking changes.

crossbeam-utils

Remove deprecated AtomicCell::compare_and_swap (#619)

crossbeam-epoch

Seal Pointer trait (#620)
Remove deprecated Atomic::compare_and_set(_weak), CompareAndSetOrdering, CompareAndSetError (#628)

crossbeam-skiplist
There are no plans to publish skiplist as part of crossbeam 1.0.
See #635 for release of skiplist

Update - Here is a list of the remaining (breaking) changes I'm aware of:
Open issues

crossbeam-channel

Change the signature of Select::recv and Select::send (https://github.com/crossbeam-rs/crossbeam/issues/256#issuecomment-444604397)

crossbeam-epoch

Custom allocator support (https://github.com/crossbeam-rs/crossbeam/issues/503#issuecomment-631143806)
This may be postponed to 2.0.

crossbeam-utils

Should park_timeout report the reason for their return (timeout or unpark)? (#601)

I tend to accept them, but I'm not very clear about what APIs to add.
@jeehoonkang @Vtec234 Any thoughts about these (or some of these) changes?
Changes pending as breaking
They are accepted but blocked because they are breaking changes.

crossbeam-utils

Remove deprecated AtomicCell::compare_and_swap (#619)

crossbeam-epoch

Seal Pointer trait (#620)
Remove deprecated Atomic::compare_and_set(_weak), CompareAndSetOrdering, CompareAndSetError (#628)

crossbeam-skiplist
There are no plans to publish skiplist as part of crossbeam 1.0.
See #635 for release of skiplist

I wish crossbeam-utils becomes 1.0. I think it has a quite stable API.
I wish crossbeam-epoch doesn't become 1.0 yet. We have many things to resolve, including but not limited to custom allocator, hazard pointer support (#221), ... I wish this crate evolves more freely with pre-1.0 versioning.

I wish crossbeam-utils becomes 1.0. I think it has a quite stable API.
I wish crossbeam-epoch doesn't become 1.0 yet. We have many things to resolve, including but not limited to custom allocator, hazard pointer support (#221), ... I wish this crate evolves more freely with pre-1.0 versioning.

@jeehoonkang

I think it has a quite stable API.

Agreed.
Also, I think crossbeam-queue is probably just as stable. Only one breaking change (#548) has been made since it was published. There are discussions about adding versions optimized for specific use cases like #338, but they are not changes to existing APIs. Personally, I think it makes sense to provide it as another (more experimental) crate for now.

We have many things to resolve, including but not limited to custom allocator, hazard pointer support (#221), ... I wish this crate evolves more freely with pre-1.0 versioning.

Ok! So considering that the stability is different per sub crate, it seems to be better to publish as 1.0 in order from stable sub crates.
For now, I would like to select crossbeam-utils and crossbeam-queue as crates that the first stabilize.
I think crossbeam-channel is also basically stable enough, but it's not clear about select/Select.
I'm not very familiar with crossbeam-deque so I'm not sure about its stability, but considering its main use cases and there are relatively few crates that depend directly on it, we probably don't need to stabilize it in a hurry.
What do you think?

@jeehoonkang

I think it has a quite stable API.

Agreed.
Also, I think crossbeam-queue is probably just as stable. Only one breaking change (#548) has been made since it was published. There are discussions about adding versions optimized for specific use cases like #338, but they are not changes to existing APIs. Personally, I think it makes sense to provide it as another (more experimental) crate for now.

We have many things to resolve, including but not limited to custom allocator, hazard pointer support (#221), ... I wish this crate evolves more freely with pre-1.0 versioning.

Ok! So considering that the stability is different per sub crate, it seems to be better to publish as 1.0 in order from stable sub crates.
For now, I would like to select crossbeam-utils and crossbeam-queue as crates that the first stabilize.
I think crossbeam-channel is also basically stable enough, but it's not clear about select/Select.
I'm not very familiar with crossbeam-deque so I'm not sure about its stability, but considering its main use cases and there are relatively few crates that depend directly on it, we probably don't need to stabilize it in a hurry.
What do you think?

Actually, I'm planning to propose a large restructuring of crossbeam-queue (and other crates)... :) May I ask if we could decide when to stabilize it after that?

Actually, I'm planning to propose a large restructuring of crossbeam-queue (and other crates)... :) May I ask if we could decide when to stabilize it after that?

@jeehoonkang

crossbeam-queue (and other crates)

Is crossbeam-utils included in "other crates"? (you said it has a quite stable API)
In either case, I'm fine with postponing the stabilization of those crates.

@jeehoonkang

crossbeam-queue (and other crates)

Is crossbeam-utils included in "other crates"? (you said it has a quite stable API)
In either case, I'm fine with postponing the stabilization of those crates.

@taiki-e sorry for being confusing.  I think crossbeam-utils is good to go for 1.0, but the others are not.

@taiki-e sorry for being confusing.  I think crossbeam-utils is good to go for 1.0, but the others are not.


Added a warning note in tf.where documentation for 'NaN' gradient issue with workaround

This is to solve the issue nan gradient when tf.where is used #38349

@anorak-k Can you please address Ubuntu Sanity errors? Thanks!

@alextp Sorry, again for some reason I couldn't run the sanity on my local it just gets stuck in step 2. Have fixed the issues. Should run fine now.

@alextp The sanity passed but was failing in Ubuntu CPU build. Now fixed the bug. I am new to this. Apologies and thank you for your patience.

@anorak-k no need to thank me for patience; our testing infra is very flaky and slow and we should be apologizing :-)

@alextp is there a way to run all these checks in my local before I push my change. That way it is much more easier.

I wish...
On Fri, Apr 17, 2020 at 8:54 AM Maadesh Sivakumar<EMAIL_ADDRESS>wrote:

@alextp https://github.com/alextp is there a way to run all these
checks in my local before I push my change. That way it is much more easier.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tensorflow/tensorflow/pull/38467#issuecomment-615323660,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAABHRIAKBMCRIBOAF63J7DRNB3SFANCNFSM4MGJVUIQ
.

--

Alex

I'm not TBAALi<EMAIL_ADDRESS>签名由 网易邮箱大师 定制 On 04/18/2020 00:02, Alexandre Passos wrote: I wish... On Fri, Apr 17, 2020 at 8:54 AM Maadesh Sivakumar<EMAIL_ADDRESS>wrote: > @alextp https://github.com/alextp is there a way to run all these > checks in my local before I push my change. That way it is much more easier. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > https://github.com/tensorflow/tensorflow/pull/38467#issuecomment-615323660, > or unsubscribe > https://github.com/notifications/unsubscribe-auth/AAABHRIAKBMCRIBOAF63J7DRNB3SFANCNFSM4MGJVUIQ > . > -- - Alex — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

@anorak-k Any update on this PR? Thanks!

It has been 14 days with no activity and the awaiting response label was assigned. Is this PR still valid? Assigning the stalled label. Please comment to reassure me that this is still being worked on.

I'm going to go ahead and close this PR, because it seems to have stalled. If you're still interested in pursing this (and responding to my comments), please feel free to reopen!

Can i revive it and resolve if someone isn't?


New tutorial: Object tracking using CellProfiler

This is a new imaging tutorial written by @jkh1 with also a new set of tools integrated by @sunyi000. It's a relatively simple workflow, hopefully not very hard to review... And we need to deliver it by Friday, so we will try to incorporate the feedback asap. Thank you :)

@gallardoalba could you take a look at this? :)

Congrats @beatrizserrano.

:tada: :tada: Awesome @beatrizserrano! And thanks for the reviews @hexylena and @gallardoalba


Dynamically loading locales broken for application build

Command
build
Is this a regression?

[X] Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was
16
Description
Since angular 2 came out there have been ongoing discussions about the best way to load locales if you don't know the locale ahead of time.  For example, my company supports over 200 locales so importing each one at the top of the file is not realistic.  The most recent accepted workaround was to do the below.  Now with esbuild this no longer works.  Is there an accepted way to do this now?
          /* webpackMode: "lazy-once" */
          /* webpackChunkName: "i18n-base" */
          /* webpackExclude: /(^en)\.js/ */
          /* webpackExclude: /\.d\.ts$/ */
          `<EMAIL_ADDRESS>        ).then(
          module => {
            registerLocaleData(module.default, localeId);
            resolve();
          },
          () => {
            import(
              /* webpackMode: "lazy-once" */
              /* webpackChunkName: "i18n-base" */
              /* webpackExclude: /(^en)\.js/ */
              /* webpackExclude: /\.d\.ts$/ */
              `@/../node_modules/@angular/common/locales/${localeId.split('-')[0]}.mjs`
            )
              .then(module => {
                registerLocaleData(module.default, localeId);
                resolve();
              })
              .catch((e) => {
                console.error(e);
                //Need to fall back to something
                return this.handleEnglishLocale(localeId, resolve, reject);
              });

Minimal Reproduction
ng build after having a service that tries to load locale dynamically.
Exception or Error
Failed to resolve module specifier '<EMAIL_ADDRESS>
Your Environment
17.0.8

Anything else relevant?
No response

The previously mentioned pattern was never officially supported since it was a feature specific to Webpack. Esbuild necessitates that imports be statically analyzable for processing.
Nevertheless, you can achieve the desired outcome by referencing each locale lazily in a manner compatible with all bundlers. The following is equivalent to what Webpack was doing during the build process.
function loadLocale(locale: string) {
  return {
     'en': () => import('@angular/common/locales/en'),
     'fr': () => import('@angular/common/locales/fr'),
     'de': () => import('@angular/common/locales/de'),
  }
}

You could also do something like
const localeData = await import(`../node_modules/@angular/common/locales/${localeId}.mjs`);

Hey, based on my understanding how building works your first suggestion will work similar to what webpack does

The previously mentioned pattern was never officially supported since it was a feature specific to Webpack. Esbuild necessitates that imports be statically analyzable for processing.
Nevertheless, you can achieve the desired outcome by referencing each locale lazily in a manner compatible with all bundlers. The following is equivalent to what Webpack was doing during the build process.
function loadLocale(locale: string) {
  return {
     'en': () => import('@angular/common/locales/en'),
     'fr': () => import('@angular/common/locales/fr'),
     'de': () => import('@angular/common/locales/de'),
  }
}

but could you explain a bit more solution from your last comment?

You could also do something like
const localeData = await import(`../node_modules/@angular/common/locales/${localeId}.mjs`);

Won't esbuild generate as many chunks as there are locales in node_modules/@angular/common/locales/ directory with this approach? So it's not exactly what webpack does with "magic comments". Or am i missing something here?

For the moment I moved on to other issues.  I don't think it's reasonable to have to manually import 250 cultures as we are an actual enterprise application that has to work globally.  It is too bad something could not have been done on angular's side to actually make what I assume is a common functionality supportable.  I did try ../node_modules... but no matter what path I try it either fails during build time or during runtime.

@jasedwards FWIW we're investigating using the Intl API to drop the requirement for those locale files.

this is not just about the locales that angular ships but any kind
I ported our product to Angular 17.x with now the new application builder but that had quite some changes which are quite horrible if you ask me. I also added here:
https://github.com/evanw/esbuild/issues/700#issuecomment-1954426114
a comment about that, the thing is that now you need to hard code languages or locales, if that are 10 or 20 then it is doable
But maintaining this is horrible (i now need to check constantly when i update 3 or 4 3rd party components/packages if they have new language/locale files)
And yes for Angular this is not doable because i think it could be up to 1000 files..
As you can read in the above comment, i left angular to be dynamic (because of the many files and because angular at least is already a esm module, not a commonjs that needs to be wrapped).
But i notice that that has more problems, because now the import statement is not rewritten at all and i need to take care of the base ref of the page my self and make sure it download the correct file..:
https://github.com/Servoy/servoy-eclipse/commit/cb3ffb323028f08411a0a028780efbb3f1748224#diff-9252feff0331dcff3d2e09667dc94116340079476026a6ab44a5b522af22eb3aR166
besides that i also need to tweak the server side because mjs files that are now downloaded don't have by default the correct mime type set...
So not supporting dynamically loading of modules based does cause code explosion and maintenance nightmare..


Log Backup Task Randomly Paused due to Failed to get Initial Snapshot

Bug Report

What version of TiKV are you using?
v6.5.x, but I guess this impacts all released versions (v6.5, v7.1, v7.5). (Maybe not for master because #16008 refines the retry strategy.)
What operating system and CPU are you using?
Irrelative.
Steps to reproduce
Start a log backup task in the cluster. Maybe trigger some merges or restarting TiKV.
What did you expect?
Log backup should run normally.
What did happened?
It encountered a fatal error:
retry time exceeds: and error and error failed to get initial snapshot:
failed to get the snapshot (region_id = ...):
Error during requesting raftstore: message: "read index not ready, reason can not read index due to merge, region ..." read_index_not_ready { reason: "can not read index due to merge" region_id: ... }:
failed to get initial snapshot: failed to get the snapshot (region_id = ...):
Error during requesting raftstore: message: "read index not ready, reason can not read index due to merge, region ..." read_index_not_ready { reason: "can not read index due to merge" region_id: ... }:
failed to get initial snapshot: failed to get the snapshot (region_id = ...):
Error during requesting raftstore: message: "read index not ready, reason can not read index due to merge, region ..." read_index_not_ready { reason: "can not read index due to merge" region_id: ... }

Or, sometimes:
retry time exceeds: and error and error failed to get initial snapshot:
failed to get the snapshot (region_id = ...):
Other Error: [components/backup-stream/src/event_loader.rs:320]: message 'CaptureChange' dropped for region ...: oneshot canceled: failed to get initial snapshot:
failed to get the snapshot (region_id = ...):
Other Error: [components/backup-stream/src/event_loader.rs:320]: message 'CaptureChange' dropped for region ...: oneshot canceled: failed to get initial snapshot:
failed to get the snapshot (region_id = ...):
Other Error: [components/backup-stream/src/event_loader.rs:320]: message 'CaptureChange' dropped for region ...: oneshot canceled

/label-remove affects-8.1


Refactor Queries and Actions.

Where we are
The original intention of the Wallaby api was to give ruby developers a familiar api to Capybara and to create human readable tests. This is an example of such a test:
test "some web page", %{session: session} do
  session
  |> visit("some_page.html")
  |> find(".a-form")
  |> fill_in("Name", with: "Chris")
  |> click_button("Submit")

  assert session
  |> find(".header")
  |> text == "Welcome Chris!"
end

This api is certainly friendly but I believe it has a lot of drawbacks. The first issue is that its not consistent. find accepts css while other actions such as fill_in accept either label text, the name of the field, or the id of the element. Using the id tends to be confusing because you don't use css selector like #some-input you use the id value like some-input. Different actions have different query semantics. These issues require Developers to learn each actions semantics and constricts their ability to solve problems when a use case deviates from convention.
A deeper problem, and one that affects me as a maintainer, is that actions are coupled to queries. This means that if we want to update or add functionality to the query engine, we have to make sure that it works with all of the actions. Updating the query engine to find elements by text or to find a certain number of elements becomes difficult to test in each action. Its also why we have multiple ways of doing the same thing. For instance click_button and click_link do effectively the same thing. They click elements. But because both of those actions are coupled to querying we need to support 2 different functions.
A byproduct of this tight coupling is that test code is much harder to re-use. In practice I've found my tests to be brittle and I've struggled to combat that with the current api.
Where I want us to go
I believe that a necessary step to grow and maintain Wallaby is to separate queries from actions. This PR is a step towards that. For instance the test above would now look like this:
test "some web page", %{session: session} do
  session
  |> visit("some_page.html")
  |> find(css(".a-form"))
  |> fill_in(text_field("Name"), with: "Chris")
  |> click(button("Submit"))

  assert session
  |> find(css(".header"))
  |> text == "Welcome Chris!"
end

This change may seem verbose but it actually opens us up to writing much more maintainable tests. for instance we could extract each of those queries to an attribute or function call. That way when our presentation layer changes we only need to update our test code in a single location.
Any other query parameters will now be part of the query itself.
css(".some-css", text: "With this text", count: 3)
css(".some-hidden-css", visible: false)

radio_button("My fancy radio button")

By extracting the query logic from our actions we can drastically reduce the footprint of Action api. Actions will accept queries. That means you can use css queries with fill_in or textfield queries with find, etc.
All of the action logic has been moved to a new module called Browser. The Browser is the entry point for interacting with, you guessed it, the browser. If you've used Ecto this pattern will probably be familiar to you.
How are we gunna get there?
I'm keeping everything backwards compatible for now. The existing query actions (which I refer to as "extended actions") will be moved to their own module. The release after this release (which will hopefully be the 1.0 release) will make the extended actions opt-in.
There are still a few things to finish up but you should be able to start trying out the new functionality in your existing applications. Please try this out and let me know what you think. I'd really appreciate the feedback.
Todos

[x] Finish adding tests and documentation
[ ] Add deprecation notices to extended actions.
[ ] Move extended actions to their own module
[x] Update Wallaby::DSL
[x] Rename StatelessQuery to Query
[ ] Update README
[x] Rebase and squash commits

I like this API change/new API. As you note, it'll hopefully get people to extract methods for finding specific things which will lead to DRYer tests and it's what I do when writing rspec feature specs anyhow (mostly encapsulated in something like page objects there), so I think it's a good change.
I also think it's a good change as query and action should not be mixed as you mentioned as well, they are 2 different concerns. While capybara's API is very convenient that also leads to some shortcomings and separating these 2 different things is more in the spirit of elixir, or so I believe.
So, big :+1: from me!

Thanks @PragTob. I would definitely love some help writing tests for the existing actions, updating documentation, making sure that the browser operations are chainable, etc. I think the last "big" thing is to add some deprecation warnings to the existing actions and to make sure that the actions handle errors from the driver correctly. Specifically we need to be matching on more then just {:ok, result} in the actions. Going forward the driver shouldn't be responsible for throwing errors. The Browser should be doing that.

I'm going to go ahead and merge in what I have now. I think we're at a point where we can work on the remaining issues in parallel. I'll create issues in case others want to contribute.

:tada:
I'll see if I can really dig up the time, as my the first part of my simplecov work is done I might even.
Thanks a lot! :)

One of the things that has always bugged me about Capybara is exactly that inconsistency you mention. Because of it, even after using Capybara for a few years, I still forget sometimes which type of specifier a method requires and I have to look it up.  I don't mind at all that it is mildly more verbose; by being more clear and consistent, it also helps devs who are new to the test framework.  So 👍 👍  for the API choice.


Add more styling properties or document it

I wanted to style menu items to change hover background color, font, paddings. I use styled components so I just added typical code:
const StyledMenuItem = styled(MenuItem)`
  &:hover {
    background: ${styleConstants.selectionColor};
  }
  padding: 0 6px;
`

In component's render() function:
<StyledMenuItem onClick={onDownloadCSV}>Download CSV</StyledMenuItem>

That didn't work as styled were applied to <li> element and I need to style  element inside <li>. I've added 'a' tag:
const StyledMenuItem = styled(MenuItem)`
  a {
    &:hover {
      background: ${styleConstants.selectionColor};
    }
    padding: 0 6px;
  }
`

It still didn't work. I had to append '!important;' to each rule due to higher specificity of css styles. I could fix it with the following code:
const StyledMenuItem = styled(MenuItem)`
  && {
    a {
      &:hover {
        background: ${styleConstants.selectionColor};
      }
      padding: 0 6px;
    }
  }
`

But I thing it should be reflected in the documentation or some ability to style menu items should be implemented.

For pseudo-classes, you may have to use as many & as you need, or use the !important rule:
styled.div`
  & { ... } /* .foo {} */
  && { ... } /* .foo.foo {} */
  &&& { ... } /* .foo.foo.foo {} */
`

Otherwise, you can use inline styles for custom styling with a stateless functional component.

Updated documentation
https://github.com/trendmicro-frontend/react-dropdown/blob/master/README.md#custom-styling


Theme Switching Support: Add a Light Theme

Perfect function! I've been looking for a program like this for a long time. I hope you can support theme switching, as I prefer a light theme instead of the dark one. It would be great to add a button in the bottom left corner to toggle between light and dark themes.

Awesome! Glad you're digging the function! 🙌
And you're totally right, a theme switch would be sweet.  We'll definitely look at adding a light theme and a toggle (bottom left corner sounds like a good spot!) in the next release. Thanks for the suggestion! ✨


Make inputTextArea show placeholder

Related forum issue: https://forum.babylonjs.com/t/gui-inputtextarea-placeholder-does-not-work/46196

Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s).
To prevent this PR from going to the changelog marked it with the "skip changelog" label.


CryptoNet upgrade 5.0.0

Just upgraded packages and i think the new CryptoExchange.Net upgrade might be the issue for all the client errors im getting on Bitmex.Net but not sure. Appreciate any help, code was working :(.

Yep, new release has a lot of changes. PR are welcome, I'm a bit busy to maintain this library now


clarifying when ignoring is not required

Reasons for making this change:
clarifying when ignoring is not required anymore
Links to documentation supporting these rule changes:

https://www.gravitywell.co.uk/latest/mobile/posts/useful-.gitignore-file-for-xcode-explained/
https://developer.apple.com/library/content/documentation/Xcode/Conceptual/RN-Xcode-Archive/Chapters/xc4_release_notes.html#//apple_ref/doc/uid/TP40016994-CH3-SW2

@Coeur thanks!


Combo dropdown export

@mcbouslog found a couple of issues with the current export formatter, relating to combo and dropdown tasks, specifically:

if a combo task contains a multiple task, only one selected value was exported instead of all
if a dropdown task was answered with a custom string value, option and value were exported incorrectly.

Review checklist

[ ] First, the most important one: is this PR small enough that you can actually review it? Feel free to just reject a branch if the changes are hard to review due to the length of the diff.
[ ] If there are any migrations, will they the previous version of the app work correctly after they've been run (e.g. the don't remove columns still known about by ActiveRecord).
[ ] If anything changed with regards to the public API, are those changes also documented in the apiary.apib file?
[ ] Are all the changes covered by tests? Think about any possible edge cases that might be left untested.

LGTM