text:
Bug: can't discard logs

Describe the bug
Hi.
I've installed file.d as a daemonset in k8s cluster.
It works fine, but I can't filter logs that I don't need (like  request_path: /api/status/liveness).
Here's log example in pretty json (gathered from file.d pod log in debug mode):
{
  "level": "info",
  "ts": "2024-10-01T14:22:39.065764723Z",
  "logger": "fd.k8s_kafka.action.debug",
  "message": "event sample",
  "offset": 4603887,
  "event": {
    "log": "{\"request_path\": \"/api/status/liveness\", \"response_body\": \"\\\"OK\\\"\", \"response_headers\": {\"content-length\": \"4\", \"content-type\": \"application/json\", \"x-request-id\": \"e1afa984-c91e-4ddc-80be-86f29a2471e8\"}, \"status_code\": 200, \"elapsed_ms\": \"0.85ms\", \"logger\": \"det_logger.request_logger\", \"request_id\": \"e1afa984-c91e-4ddc-80be-86f29a2471e8\", \"datetime\": \"2024-10-01T14:22:33.803672Z\", \"message\": \"Processed request with request_id=e1afa984-c91e-4ddc-80be-86f29a2471e8\", \"source_context\": \"/srv/www/.venv/lib/python3.11/site-packages/anyio/_backends/_asyncio.py:859\", \"log_level\": \"info\"}\n",
    "time": "2024-10-01T14:22:33.804016427Z",
    "stream": "stdout",
    "k8s_node": "01-x25",
    "k8s_namespace": "proxy-service",
    "k8s_pod": "proxy-service-8asdf4fd-v9gas",
    "k8s_container": "proxy-service",
    "k8s_pod_label_app.kubernetes.io/name": "proxy-service",
    "k8s_pod_label_pod-template-hash": "86574684fd",
    "k8s_pod_label_app.kubernetes.io/instance": "test",
    "k8s_node_label_kubernetes.io/arch": "amd64",
    "k8s_node_label_node.kubernetes.io/instance-type": "vsphere-vm.cpu-4.mem-16gb.os-linux",
    "k8s_node_label_node.kubernetes.io/role": "worker",
    "k8s_node_label_beta.kubernetes.io/arch": "amd64",
    "k8s_node_label_beta.kubernetes.io/instance-type": "vsphere-vm.cpu-4.mem-16gb.os-linux",
    "k8s_node_label_beta.kubernetes.io/os": "linux",
    "k8s_node_label_kubernetes.io/hostname": "01-x25",
    "k8s_node_label_kubernetes.io/os": "linux",
    "k8s_node_label_node-role.kubernetes.io/worker": "",
    "k8s_node_label_node.cluster.x-k8s.io/esxi-host": "s-asf4-t-esxd1.ex.com"
  }
}

I want to discard logs containing request_path:/api/status/{liveness,readiness}
Here's my configmap:
  pipelines:
    k8s_kafka:
      input:
        type: k8s
        file_config:
          persistence_mode: async
          filename_pattern: "*"
        offsets_file: /data/k8s-offsets.yaml
      actions:
         - type: debug
            interval: 1s
            first: 10
        - type: rename
          override: true
          k8s_pod_label_app: "kubernetes.labels.pod_app"
        - type: json_decode
          field: log
          prefix: "json."
        - type: modify
          logger.name: "file-d"
          application_name: "My-app"
          team.name: "My-team"
          environment: "test"
          kubernetes_cluster: "my.test.cluster.com"
        - type: discard
          match_fields:
            k8s_namespace:
              - default
              - logging
            request_path: ^\/api\/status\/*
            match_mode: or

      output:
        type: kafka
        brokers: [my.broker-1.com:9092, my.broker-2.com:9092]
        default_topic: my-topic

I expect that logs with request_path: /api/status/liveness would be filtered, but they are still sent to kafka.
However logs with k8s_namespace: default are filtered as expected.
What I've tried so far

changing regex, like
request_path: ^/api/status/*
or more explicit:

request_path:
  - "/api/status/liveness"
  - "/api/status/readiness"

adding a separate discard entry, e.g. before renaming:

          - type: discard
            match_fields:
              json\.request_path:
                - "/api/status/liveness"

adding do_if:

          - type: discard
            do_if:
              op: "or"
              operands:
              - op: "equal"
                field: "request_path"
                values: ["/api/status/liveness", "/api/status/readiness"]

adding  one more key 'log':

          - type: discard
            match_fields:
              k8s_namespace:
                - default
                - logging
              log:
                request_path: ^\/api\/status\/*
            match_mode: or

None of that helped.
Troubleshooting
I'd be happy to troubleshoot issue myself and found https://github.com/ozontech/file.d/blob/master/docs/configuring.md#actions-debugging
I'd like to add here, that -http=':9090' is invalid, correct option is --http=:9000
And after applying this configuration I get just:
curl http://1.2.3.4:9000/pipelines/k8s_kafka/2/sample
{"error":"There are no active processors"}

 curl -I http://1.2.3.4:9000/pipelines/k8s_kafka/2/sample
HTTP/1.1 400 Bad Request

Changing digit, like 1/sample, 3/sample won't help.
Additional context
Version: Hi! I'm file.d version=v0.34.0
Platform: k8s
--
I can provide additional info if needed.
Hope to get answer soon.

Hello! Thanks for submitting!
I've checked the configs with the provided log. In the original configmap there are several issues:

match_mode: or should be on the same level as match_fields, not inside of it
the compared value in match_fields is considered a regular expression only if it starts and ends by /, so the value for request_path should be /^\/api\/status\/*/ to execute a regular expression
after applying json_decode plugin with prefix: "json.", your field request_path inside log transforms into json. request_path

Considering all of the above the condition for the discard should be:
        - type: discard
          match_fields:
            k8s_namespace:
              - default
              - logging
            json\.request_path: /^\/api\/status\/*/
          match_mode: or

Note: since your field has a dot in its name the dot should be shielded by backslash \ because usually it means a path to nested field. E.g. path field.subfield is treated as {"field": {"subfield": "val"} }.
Config 2
request_path:
  - "/api/status/liveness"
  - "/api/status/readiness"

Did not work because of field name, it should be json\.request_path.
Config 3
          - type: discard
            match_fields:
              json\.request_path:
                - "/api/status/liveness"

Might've not worked because the logs you were testing it on did not meet the condition.
Config 4
          - type: discard
            do_if:
              op: "or"
              operands:
              - op: "equal"
                field: "request_path"
                values: ["/api/status/liveness", "/api/status/readiness"]

Did not work because of field name.
In config 5
          - type: discard
            match_fields:
              k8s_namespace:
                - default
                - logging
              log:
                request_path: ^\/api\/status\/*
            match_mode: or

It doesn't work this way. If you need to point a path to field it should be log.request_path. In this particular case it wouldn't help though. The field log is removed after applying json_decode on it, and from the beginning its value was string, not object.

About troubleshooting with http://1.2.3.4:9000/pipelines/k8s_kafka/2/sample. The handler for this endpoint collects currently processed data in the action. I assume at the time of request there were no events in processing.

Also we recommend discard logs as early as possible for better performance. So the config could look like this:
  pipelines:
    k8s_kafka:
      input:
        type: k8s
        file_config:
          persistence_mode: async
          filename_pattern: "*"
        offsets_file: /data/k8s-offsets.yaml
      actions:
        - type: debug
          interval: 1s
          first: 10
        - type: discard
          metric_name: discarded_k8s
          do_if:
            op: "equal"
            field: k8s_namespace
            values: ["default", "logging"]
        - type: json_decode
          field: log
          prefix: "json."
        - type: discard
          metric_name: discarded_parsed
          do_if:
            op: "equal"
            field: json\.request_path
            values: ["/api/status/liveness", "/api/status/readiness"]
        - type: rename
          override: true
          k8s_pod_label_app: "kubernetes.labels.pod_app"
        - type: modify
          logger.name: "file-d"
          application_name: "My-app"
          team.name: "My-team"
          environment: "test"
          kubernetes_cluster: "my.test.cluster.com"

      output:
        type: kafka
        brokers: [my.broker-1.com:9092, my.broker-2.com:9092]
        default_topic: my-topic

There are two discard plugins now, the first discard before decoding json from log to save some CPU and memory, the second discard by parsed field is right after json_decode to save resources on further actions. Also there are two metrics for discard actions, so you can track whether it discards logs or not. Both metrics are counters with label status. If you need additional labels, you can add them using field metric_labels.

Hi, @HeadHunter483!
First of all thanks for such a lightning-fast answer!
Feels like I've bought a paid subscription, not installed an open-source tool :)
Regarding your answer:
TL;DR it works!
        - type: discard
          metric_name: discarded_parsed
          do_if:
            op: "equal"
            field: json\.request_path
            values: ["/api/status/liveness", "/api/status/readiness"]

this block helped.

Thanks for the explanations.
I've searched through documentation but couldn't find explicit info about slashes in regex, escaping dots in keys, etc.
I think it's a good idea to add it to docs, and I can bring a PR. Please suggest an appropriate file/place for that.
Maybe just some more examples?

About troubleshooting with http://1.2.3.4:9000/pipelines/k8s_kafka/2/sample. The handler for this endpoint collects currently processed data in the action. I assume at the time of request there were no events in processing.

Ok, I see.
What's the correct way to troubleshoot via endpoint?
I've tried while true; do curl 1.2.3.4:9000/...; done - but it didn't help, though logs were processed while querying the endpoint.
Maybe file.d is too fast and at the exact moment I do curl nothing is processed?

@d-nemi yeah I think examples is a good place. We have plans on reworking match_fields a bit to make it work together with do_if, so we'll add some more info about dots there too.
About troubleshooting, if you are testing locally by writing one or two logs manually, it could be useful to set more debug plugins right before and after the plugin you are interested in. Also metrics can help, they can be added to any action plugin using metric_name, and you can add values from the log as metric labels by providing field names in array metric_labels.
In that case with match_fields and do_if, you could test by replacing discard plugin with modify plugin. E.g.
        - type: modify
          shouldDiscard: "true"
          do_if:
            op: "equal"
            field: json\.request_path
            values: ["/api/status/liveness", "/api/status/readiness"]

@HeadHunter483,
Thanks for your help!
I'll close the issue.


text:
enable for only a single language or list of languages

Hi 👋🏿 thanks for your work on this plugin.
I've just moved over from luochen1990's plugin and I'm wondering if it's possible to enable this plugin for only a few filetypes primarily since there are only a few languages I use that tend to get a little unmanageable with their parens (e.g. lisps) but for things like lua I don't really need this functionality.

Yeah just change enabled from true to a table of languages you want to enable it for (just like the main nvim-treesitter plugin)
21-Apr-2021 03:22:58 Akin @.***>:

Hi 👋🏿 thanks for your work on this plugin.
I've just moved over from luochen1990's plugin and I'm wondering if it's possible to enable this plugin for only a few filetypes primarily since there are only a few languages I use that tend to get a little unmanageable with their parens (e.g. lisps) but for things like lua I don't really need this functionality.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub[https://github.com/p00f/nvim-ts-rainbow/issues/30], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AIWNSZ3CDDWEZTBFH242G5DTJXZTVANCNFSM43JDXL7A].
[data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEIAAABCCAYAAADjVADoAAAAAXNSR0IArs4c6QAAAARzQklUCAgICHwIZIgAAAaKSURBVHic7Zu9bhtHEMd/cycgUprwDcIUKeMwT+Az3ISMGdNNUlouU4lu7QCRi9SmqpSWy6QRHdqkiwCmniASUqYw9QZUEzOA7ybFrb54e7d7FD8cgH/AhrB7uzv3v9nZmdkhrLHGZciqFtZXjRoSfnK1MT6Vb/pHq5BnYxWLAhCEHeDmlTYJD4FoJeKsYtEPEWsiDNZEGKyJMFj6qaH95k0CqaHaBqpT3SNEOiR6JI3e4TLlWjgROmhVkXgHJEK1VmqwyBHoEA33pN4dLUZCs9SiJtbBt/dBt5nfcTgE2Zf678/nNN8VzJ0IHdyJQJ6RVfv5QOQITR5K/eVwrtPOayKzBZ6itOY1ZyGELho+nNeWmQsR+qpRIwzfoFRKjDoFmXKntQbyif15C4QxcXxrHm75tYnQQXMb4akHCSeodkGG/BsO5V53bJ3voFXhozgCjRBpAZ8WziqMUR5Kvbc/0wucT3MN6KC5DTxzPHYIujvrnjY2Z5fpuCSLB9chY2YiPEg4Ad2el1EzhOxTrCEzkzETEU6boLonjZftWeZ2rt2/00Fkx9p5DZtRmghzOvxZYBOupaJ+MhRoozBGw6/KniblY430iFwZCQBmjQfWTqWCxE9Lz1nmYbNP3+R0L4WEyyi2U3qrjH0qqRFiX1R1b9kkgNEM1T17Z1BKK7w1ooD9E6n3qt7zHLQqbCZ3EW2BVM8DsTTAGqHSZRK8yPMzcmQbYT9NvLW0TM7yfo4Y2z6DUwLe7yBxG6WCAul/5gGtATXQFlvxWAd3Okw29vwI0e2cLXsf2PeRz0sjdNCqQvzW0nUo9V7kHH/QqrCVvJkpDH8X3PIhQwfNIVanK/zM5wTxsxH6Pscn0F3n0INWha34bWkSINWSrfitHrTcMYzSsbfnyX4VfkQEgc29PXFZ5QtNKBOMTU9Cha3kjYsMafS6wEmmwy579jE/YSxfU7XrHLeZtB2a0Ed1z1j+fuH6m4n7y9pk8tREJxGp72CDDAvHHbQqiNpdYfQvkO8I+IVQ/iCUPwj4BeS7tM+2nO64t4hdpvx3uIBbI1TsjP4bWhc9x2bcsm8J/YtAHhHou6w0+o5AHlnJUCpsxsVJnzyZ8t7hEs5PDX3VqBGENiekSibtpqdSf1n4dXTQ7AJ3LSt+j/BPoVSJbIH+Zul5IfVeIRk6aKqleWT+Ta0TPzwL0C78iCCo4J1onc4sWVG1tPWdJECqGQl9oHF1WSlO0qQ4JHuMVq3ypO+c/ukx8az4MtOi+rf3aNuzsxzBnljfdBkskojjTIvI596j7c9m55wTLmxEkowJQts1W5XpgEYsap/FiOz2aKA8d9oJ5WOm7cPFnC5YnT/r2CQ5d93PiTDWM8rI1G+2Ea6eJkpFD1oVRwxgPzWUxwiPC8aB6o85YVChE5f6GbGlg440enYX3MC9NUTtJ8RHcVQ4bhJ207uLDG6Q8LP56lehfEzCzyBfZIfpaTpnAfJkynuHS3ASkR9PqH3Rs3H3umMI8r7CDZRfSfgB5TbKbfP3r8CNHFE77ijULpNPpsrXWNoMX1btpzEJOtaxF2igtFHa2G3CxfqTXFJdMnkZWN+ga2hprbp8eLnXHTMJo5wt4gk9ZRJGLm3QfrOFzWmyy56BHxGykfM15Cfn0HvdMZONKrMdfcdMNqpeWSoh564jT/ar8CLCZHhsR2vkE9ldaIY88dMOPQV54qMJcB5d2uQ49L3fKJOz3Md6Rssz4DPXYPNCu3rQ6pgo8kyVz3yNY9Kzvstko1smeZubXffMV0Lpe42cbPECr/hcKLgCPJZ6zzs2Keli52SsRXZMun+pSEsScu5B0VIfphQR5jx+kdP9bJlkOG7jn5e9hZ8h6ArbBQZvKWQ4rvpOIdwtO2dpIqTeHZEkUSEZr5ulL2F9YebOJyFJolnqqhZZKDICfTDnQhFXtd5yC0XO4Fk6NEToyNe9PNtSvMbr5l3jgkeOR1dTOnSGlAzteFTDjRC6wJB34WFhMdlWfBOITKli1SHBKUh7pcVk56K8atQIgmHp0kBlOjyOSq6c2oQPobzwDOaiuIMtGbMYPIdw94MqOL0MY9Q62LLY88ExaPuDLUGehjGk27jrI31xCOwvqjJnOT9T0PdtRCLKa8kxqkNko/O//ZlCHnRwJ0KlhtAmG8CdoHQQPZq36ruwut992itcvCpwFoH1TZfBmgiDNREGayIMVvfb8CRuX65PSNuSEnnKNdZYJP4DjZfC7F0Ms2cAAAAASUVORK5CYII=###24x24:true###][Tracking image][https://github.com/notifications/beacon/AIWNSZ6XFGNNVL4UV6DYMR3TJXZTVA5CNFSM43JDXL7KYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4M3UQFLA.gif]

@p00f I just tried setting enable = {"dart"} as an example but that doesn't work lua still shows rainbow parentheses 🤔 the README says the key is enable not enabled but I tried using enabled and that just turns the plugin off completely

It is enable indeed. Also, sorry but there's only enable = true and disable = list of languages
https://github.com/nvim-treesitter/nvim-treesitter#modules

@p00f thanks that works, shame it works in that order since to only enable it for a few languages I'd end up having to list all available languages except the one I want 😅 . Anyway thanks for the help.

I came here for the same exact request as @akinsho, it will be great @p00f if there is a way to enable the plugin only for some langauges.

I don't want to implement this on the module side, can you open an issue on the main nvim-treesitter repo and see? If they don't want to then I'll try doing it

I don't want to implement this on the module side, can you open an issue on the main nvim-treesitter repo and see? If they don't want to then I'll try doing it
@ahmedelgabri

Unless I'm missing something why is it needed to be added to treesitter? I actually don't see that useful on the treesitter side but I see it useful here, the reason is I might want treesitter support for more languages than I'd like rainbow parentheses support. Technically I want support for treesitter for everything, but rainbow parentheses support only for lisp like languages.

This is an not a standalone plugin but an nvim-treesitter module:
https://github.com/nvim-treesitter/nvim-treesitter#modules
If they implement this on their side then you can do it to any module given here
https://github.com/nvim-treesitter/nvim-treesitter/wiki/Extra-modules-and-plugins#extra-modules
note that 3 out of the 6 modules mentioned there are outside the nvim-treesitter organization

I think I found a way around this limitation without maintaining a full table of disabled languages.
local parsers = require("nvim-treesitter.parsers")

rainbow = {
  enable = true,
  -- Enable only for lisp like languages
  disable = vim.tbl_filter(
    function(p)
      return p ~= "clojure" and p ~= "commonlisp" and p ~= "fennel" and p ~= "query"
    end,
    parsers.available_parsers()
  )
},

Neat! If that list grows larger you can use
local enabled_list = {"clojure", "fennel", "commonlisp", "query"}
rainbow = {
  enable = true,
  -- Enable only for lisp like languages
  disable = vim.tbl_filter(
    function(p)
        local disable = true
        for _, lang in pairs(enabled_list) do
          if p==lang then disable = false end
        end
        return disable
    end,
    parsers.available_parsers()
  )
},

It would be nice if enable could either be true or a list of languages. The vim.tbl_filter snippet isn't hmm... ergonomic.

source: gharchive/issue

authors: ahmedelgabri akinsho oblitum p00f

license_type: permissive

license_source: github-api


text:
Make paste automatically activated by default.

Hello, Maccy does not paste, what might be the problem and how can I fix it?
installation: brew
Current version: [0.26.2,17]
macOS version: 13.1
keyboard layout: us

https://user-images.githubusercontent.com/44067394/227779654-3d814f46-3403-4356-be4e-1684094e1024.mp4

nvm, the pasting was with option+return, not only return :D
Though it might make sense to enable paste automatically by default.

Duplicate of #500

license: MIT


text:
img crop, the same as APBSN?

I follow the data preparation done by APBSN in which the patch size is 512 and the overlap size is 128, is that right?

Of course you can. However, the repetition of each image (self.repeat) is set based on the quantity of the original images. If you choose to crop the original images, remember to adjust it accordingly. (If you don't adjust it, it's fine, but the number of iterations per epoch will increase, leading to longer training time.)


text:
protoc error: Explicit 'optional' labels are disallowed in the Proto3 syntax

I'm trying to add scripts to generate rust code and encountered this error.
In proto/p4/config/v1/p4info.proto, an optional is used at L314:
312 message SumOfMembers {
313   // the maximum weight of each individual member in a group.
314>  optional int32 max_member_weight = 1;
315 }

When generating codes with protoc, an error occurs (no matter what language is targeted):
# exec protoc via compile_protos.sh with protoc v3.12.4
p4/config/v1/p4info.proto: This file contains proto3 optional fields, but --experimental_allow_proto3_optional was not set.

# exec protoc via update.sh
p4/config/v1/p4info.proto:314:14: Explicit 'optional' labels are disallowed in the Proto3 syntax. To define 'optional' fields in Proto3, simply remove the 'optional' label, as fields are 'optional' by default.
p4/v1/p4runtime.proto: Import "p4/config/v1/p4info.proto" was not found or had errors.
p4/v1/p4runtime.proto:735:3: "config.v1.P4Info" is not defined.

I'm not very familiar with protobuf. Should this optional be removed, or should the flag --experimental_allow_proto3_optional be used after all protoc usage?

@jonathan-dilorenzo, I believe you recently added this field. I suspect the optional qualifier may have slipped in by acident?

optional support was added in proto 3.15
I think we discussed this at the time and decided to keep it.
@duskmoon314 is using protoc v3.12.4 which is very old.
Even the "p4lang toolchain", which is not updated frequently, is using v3.18

Nonetheless, good question. No idea why I put the optional qualifier in there. Let me take an AI to get rid of it (and add a comment about when the field was introduced at the same time).

@duskmoon314 is using protoc v3.12.4 which is very old.

This one is installed via apt, and it is v3.12.4 on Ubuntu 22.04.
But I also see the error when using update.sh. It uses the image p4lang/third-party. There may still be some version issues that need to be fixed.

But I also see the error when using update.sh. It uses the image p4lang/third-party. There may still be some version issues that need to be fixed.

That sounds unlikely. The script is run every time the main branch is updated. This is the latest run, from last week: https://github.com/p4lang/p4runtime/actions/runs/8991480949

Oh, I didn't notice that the last build of that image was two years ago.

This is accurate, but it still comes with protoc v3.18.1:
$ docker run -ti p4lang/third-party:latest protoc --version
libprotoc 3.18.1

It's unlikely anyone is going to update this image unless it is required (e.g., for some CI purposes).

em, I think I got the wrong image. I need to check what's wrong with docker.
Here is the output when I run p4lang/third-party on my machine:
❯ docker pull p4lang/third-party
Using default tag: latest
latest: Pulling from p4lang/third-party
4f53fa4d2cf0: Already exists
6af7c939e38e: Already exists
903d0ffd64f6: Already exists
04feeed388b7: Already exists
fda0447a2aef: Already exists
d542ede27a5b: Already exists
b51b1233ed05: Already exists
c82aee7e3df0: Already exists
dfbd36aecb5f: Already exists
e4a0a292616b: Already exists
2a545cc6126f: Already exists
fddeaa06596f: Already exists
f9b99e89d373: Already exists
4e7b4af9333f: Already exists
a87f1c53893b: Already exists
11b7960c4654: Already exists
846e5f482b63: Already exists
5c787c58e206: Already exists
34599a8d9776: Already exists
a6c7643c8f08: Already exists
Digest: sha256:a0f2e9a741bab06cc8dd478183541c1260ca4e174d954a21af3eb7e63559dd8b
Status: Downloaded newer image for p4lang/third-party:latest
docker.io/p4lang/third-party:latest

❯ docker run -it --rm p4lang/third-party bash
root@aee361934b1f:/# protoc --version
libprotoc 3.6.1

This is not the correct sha for the current p4lang/third-party:latest image.
The correct one is sha256:9c5f3218965dc63c0a03023721a44ea9920067de0ff8a2c69a2d8baac34b1818, as per https://hub.docker.com/repository/docker/p4lang/third-party/general
I am able to pull the same image as you if I provide the same sha explicilty: docker image pull p4lang/third-party@sha256:a0f2e9a741bab06cc8dd478183541c1260ca4e174d954a21af3eb7e63559dd8b. It must be an older version of the image that is still present in the Docker registry, but without a tag.
You could try pulling with the correct sha.

Looks like I replied just as you edited the post. Not sure why you are seeing a stale image by default when you use latest... Does your employer / university use a proxy cache for docker access?

Does your employer / university use a proxy cache for docker access?

I'm using the machine of our lab and the manager added a register-mirror several month ago before granting access to me. I delete that config and can pull the correct image now.
I'm testing update.sh now. Hopes everything works fine.

Thanks for your help. No error occurs now!
I assume the use of this keyword in intentional and close this issue for now.

Let's keep this open until we have also resolved https://github.com/p4lang/p4runtime/issues/482#issuecomment-2108305494.

@jonathan-dilorenzo, would you be able to send a quick follow-up so we can close this?

@jonathan-dilorenzo bump - we want in 1.4.0

authors: antoninbas chrispsommers duskmoon314 jonathan-dilorenzo smolkaj

license_source: bigquery


text:
Invalid 'access_token' provided.

I am not able to find the access_token! I can only find Client ID and Client secret at https://docs.pcloud.com/my_apps/

According to my own experience, you need bath to get the access token

Hello @denilsonc
Please, follow the steps below in order to generate working/valid access_token:
. Register app at: https://docs.pcloud.com/my_apps/
      You will receive: "Client ID" and "Client secret"
. Call: $codeUrl = $pCloudApp->getAuthorizeCodeUrl();
      This will generate oauth2 link, by clicking on the link you will receive "access code".

. Call only once: $accessToken = $pCloudApp->getTokenFromCode($accessCode, $locationID);
      This will provide you with "Access token" you are asking for, for location ID: "1" is for USA ( if your account is in USA ) , "2" is for Europe.
. Call the API procedures by setting:
      $pCloudApp->setAppKey($clientId);
      $pCloudApp->setAppSecret($clientSecret);
      $pCloudApp->setLocationId($locationID);
      $pCloudApp->setAccessToken($accessToken);

repo: pCloud/pcloud-sdk-php


text:
Errors in install

After installing pH7 on a paid hosting service i get these errors.
Fatal error: Uncaught TypeError: strtolower() expects parameter 1 to be string, bool given in /home/novaoutp/public_html/date/_pussy/framework/Server/Server.class.php:165 Stack trace: #0 /home/novaoutp/public_html/date/_pussy/framework/Server/Server.class.php(165): strtolower(false) #1 /home/novaoutp/public_html/date/_pussy/app/Bootstrap.php(78): PH7\Framework\Server\Server::isRewriteMod() #2 /home/novaoutp/public_html/date/index.php(45): PH7\Bootstrap->run() #3 {main} thrown in /home/novaoutp/public_html/date/_pussy/framework/Server/Server.class.php on line 165
I installed via hosting script, got these errors. deleted everything and started again with latest copy, same errors.
PHP7.4

The following function does not return "on" or "off" anymore. It will return true or false. This was changed in PHP 7.4. Comment it out and it works just fine. Btw, make sure you turn GZIP off on your PHP settings.
public static function isRewriteMod(): bool
    {
        // Check if mod_rewrite is installed and is configured to be used via .htaccess
        /*if (!strtolower(getenv('HTTP_MOD_REWRITE')) === 'on') {
            $sOutputMsg = 'mod_rewrite Works!';

            if (Uri::getInstance()->fragment(0) === 'test_mod_rewrite') {
                exit($sOutputMsg);
            }

            $sPage = @file_get_contents(PH7_URL_ROOT . 'test_mod_rewrite');
            return $sPage === $sOutputMsg;
        }*/

        return true;
    }

Thanks very much for reporting this type error due to the usage of PHP 7.4+ type declaration and strict type check in Server.class.php
This issue has been fixed in git commit https://github.com/pH7Software/pH7-Social-Dating-CMS/commit/88c58904a65c015309fab4bef9a3f4d9118a0cd5
The patch is available in the 18.x branch and will be available in the next release.


text:
Suggestions: Mass mail / Modal Popup

The ability for admin to send a mass mail to all the users. This may be problematic if there is lets say 2000 users for argument sake, because your IP and/or domain may get registered for spamming ??
Alternative (Safer Option I think)
Ability for Admin to place a temporary Modal Popup message to be displayed once the user login, to relay information deemed necessary or important by Admin to the site users

Thanks for the suggestion @Nigrini! Yes, something like sometimes FB or others do for privacy or other warning or informative messages users have to know. However, users have to log in to your website in order to see that message.

Ohh Yes for sure - The popup only to be displayed for the registered users

Something like this perhaps ?
https://github.com/dinbror/bpopup/


text:
Regex support

I was thinking, since Google doesn't turn up any authoritative Regex Swift libraries, Regex would be a good idea. I haven't heard of any way to write out a Regex pattern without it being escaped, but oh well. I was thinking of adding a prefix operator, "/", that takes a String, so you would define a Regex literal like this:
let a: Regex = /"[0-9]*"

I would also add the =~ operator, a subscript lookup on strings, and almost all of Ruby's stuff for regexes, which you can find by searching for "regexp" on this page: http://www.ruby-doc.org/core-2.2.0/String.html
One question is whether or not to use iOS's existing regular expression class, NSRegularExpression. I don't know a lot about it, but it seems to reasonable to just make extension methods for it as needed, and perhaps subclass it as we need in the future.
Thoughts?

Since there's a lot of stuff that we can do with regexps, we should consider starting a new library/framework, something like a Swift version of RegExKit meets ruby (and maybe more).
And yes, using NSRegularExpression it's the most reasonable option in order to offer a consistent interface to the iOS/OS X frameworks.

authors: michaeleisel pNre

repo: pNre/ExSwift


text:
in-memory ServiceProvider

I think it would be very useful to have an InMemoryServiceProvider to mock a service provider in tests. This would simplify the task of test writing quite a lot. Currently I'm using a CouchServiceProvider using a mocked CouchDB to get this result, but it's uselessly cumbersome

If you think it's a good idea I can probably make a quick pull request, just tell me what you think

ServiceProvider, you mean ProfileService? In any case, it's certainly a good idea to have some in memory mock.

yes, ProfileService, sorry! Should I build it into pac4j-core or a new pac4j-mem?

Let's put that in the pac4j-core module, for now, to avoid having too many modules.

ok thanks! Sorry for my annoying questions, but what's the most appropriate path? would org.pac4j.core.util.inMemoryProvider be ok?

I would say: org.pac4j.core.profile.service.InMemoryProfileService.

is it ok to extend AbstractProfileService<CommonProfile> or should I create an InMemoryProfile?

I think it's better to keep the generic: InMemoryProfileService<U extends CommonProfile>...

authors: eroux leleuj


text:
feat: allow ffi bindings to set spec version

This allows for clients to build multi version compatible interfaces via the FFI bindings.
I wasn't so sure about creating a new enum for the SpecificationVersion that is exposed to the c interface.
Alternatively, we could expose the underlying PactSpecification enum. Let me know what you prefer.

There is also a PactSpecification enum in pact_matching_ffi, so that will make 3 of them. Feels like the wrong thing to do, maybe we can just add pact_matching_ffi as a dependency.

Or just add the #[repr(C)] annotation to the one in the models. I think that just forces the memory layout to conform to C.

Interesting, from the Rust docs:

Warning: There are crucial differences between an enum in the C language and Rust's field-less enums with this representation. An enum in C is mostly a typedef plus some named constants; in other words, an object of an enum type can hold any integer value. For example, this is often used for bitflags in C. In contrast, Rust’s field-less enums can only legally hold the discrimnant values, everything else is undefined behavior. Therefore, using a field-less enum in FFI to model a C enum is often wrong.

I guess this is because on the other side you can assign any integer value to the enum

I've just made the change. It compiles and works in the go consumer I have, so I think it's 🆗

I'll think I'll change it to use the one from pact_matching_ffi so there is no FFI influences in the core Rust code.

so there is no FFI influences in the core Rust code.

This feels right. I think conceptually, there's a translation layer between the FFI bindings and the core - which would avoid bleeding the subtleties between the two types of enums.

Cool, thanks Ron. I'll leave this with you then? Do you want to merge it in and fix or want me to address?

I can do it, you'll just need to check it works ok

👍
On Mon, 3 May 2021, 11:06 am Ronald Holshausen, @.***>
wrote:

I can do it, you'll just need to check it works ok
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/pact-foundation/pact-reference/pull/98#issuecomment-830977165,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAANFDEXBIT2XCZWIWQGI6DTLXZJRANCNFSM43746CQA
.

Sorted with a feature flag: 82711d6

source: gharchive/pull-request

authors: TimothyJones mefellows uglyog

repo: pact-foundation/pact-reference

license: mit


text:
Madge doesn't show Require.JS Plugins

HI, I just found that madge doesn't show Require.JS Plugins like require-text, require-async.
Is it a bug? or not supported feature?
If it is not supported feature, can you add this to future plan?

Couldn't madge at least list (i.e. no need to introspect) those dependencies?
It seems to be using amdetective which does list those dependencies.
TIA

authors: mooyoul teehemkay

repo: pahen/madge


text:
New component

Hi @paireks
I create a component to separate meshes by color with materials assigned for rendering purpose.
I update Grasshopper reference from V6 to V7 because this is necessary , and because there are difference between the two versions i changed this line in Tools code:

The baking must be done from custom preview to bake the materials as well.

This is the GHA file:
dotbimGH.zip

Hey!
Great! You can do a pull request :)
Only thing is that if this requires to bump up GH then probably it should go to 2.0.0 version, as it can break someones workflow.

I update the component and it work faster, pull request sent

authors: paireks seghier

repo: paireks/dotbimGH


text:
Pleblist

Database
Single table for now
id, int, primary_key
stream_id, int, foreign key to tb_stream.id
youtube_id, varchar, 64, nonnullable
date_added, datetime, nonnullable
date_played, datetime, nullable

Implemented in 795da1dc77d29d78e6d97857e13370e02b75dea9
API
/pleblist/list
Get a list of pleblist songs for the current stream. Return 404 if no stream is active.
Implemented in 2b260be372a6c15095b9fe584ea36458aba9e1e8
/pleblist/list/<stream_id>
Get a list of pleblist songs for the given stream id.
Implemented in 2b260be372a6c15095b9fe584ea36458aba9e1e8
/pleblist/add
Add a song to the pleblist.
Uses the youtube_id value from a POST request.
This should require some sort of authentication before going through.
Implemented in 2b260be372a6c15095b9fe584ea36458aba9e1e8
/pleblist/next
Skip to the next song in the pleblist.
This should require some sort of authentication before going through
Structure added in 2b260be372a6c15095b9fe584ea36458aba9e1e8. Still lacking implementation.
/pleblist/blacklist
Adds the current song to the blacklist and skip to the next song in the pleblist.
This should require some sort of authentication before going through.
Structure added in 2b260be372a6c15095b9fe584ea36458aba9e1e8. Still lacking implementation.
Youtube frontend
Simple youtube player covers 70% of the area.
Under or above the youtube player, place two buttons:
Skip - Skip the current song (uses the /pleblist/next api call)
Blacklist - Skip and blacklist the current song (uses the /pleblist/blacklist api call)
A list of songs in the playlist on the right side.
Design

Base design added in c890b2b010bffb3e6ec293e7445d3ffc16d8e3ad
Donation list frontend
Simply connect to the streamtip API, fetch new donations and parse any youtube links.
Should we parse the youtube link and make sure  it's available in sweden?
Then we need $$$ for a proper youtube API Key Kappa
Design

Base system implemented, add future features as separate issues.

repo: pajlada/tyggbot


text:
fix: ignore more world types

Addresses https://github.com/ATremonte/Discord-Level-Notifications/issues/5

@pajlada Agree Collections.disjoint is more readable 👍
If we want to change $O(n)$ to $O(1)$ down the line, we can either do the retainAll approach or do a bunch of individual Set#contains checks.

As for the empty case, my solution handles it, but your test had some problems causing the failure:

retainAll is not a supported operation on emptySet() (due to immutability)
#clone is not publicly defined for normal Set

Instead, EnumSet.noneOf should've been used, and the test cases pass: https://github.com/iProdigy/DinkPlugin/commit/6e5e4e61b78606219ce50edf5df1188312feca19
That said, this is not performance critical code, so this micro-optimization doesn't matter

repo: pajlads/DinkPlugin


text:
Builders should have occam smoke tests

Currently, we test new versions of the builder.toml in the full builder and (soon) base builder with smoke tests that pack create-builder and then pack build a set of sample apps. These smoke tests are slow, not parallelized, and do not cover all of the language families the builders support.
Each builder should have smoke tests that test each of the language families within the builder. The tests should check that the expected buildpack is the one that passed detection (e.g. Ruby buildpack detects on a rackup sample app).
By implementing the tests with occam, we get the benefit that the tests can be run in parallel so we'd end up with better test coverage without slowing down our workflows.
Defining a parameterized github action that accepts a list of buildpacks/language families andpack builds would make it simpler to keep this testing consistent across the different builders.

Closing in favor of issues on specific builder repos.

repo: paketo-buildpacks/builder


text:
Should --locked be a default argument for the cargo build pack?

My coworker and I ran into an unexpected issue today, a dependency in our stack had a different version of the crate then the main library but this was fine when built locally because the lock file resolved to a version that both libraries could use.
However, we found out that unlike cargo build, cargo install doesn't use the lock file by default, causing two different versions of the library to installed during build.
We fixed it by adding --locked to the build args, however it seems like that's the behaviour you would always want anyway? Since the detect requires you to have a lock file, seems surprising that we wouldn't use it.

It's funny you mention this. I was just reading something about this difference in behavior over the weekend. I knew about the --locked flag but wasn't really aware of what it did exactly (the description in --help isn't very clear).
I'm glad you mentioned this as I was leaning towards including it in the defaults as well. It sure seems like we should be trying to build with the exact set of dependencies from the lock file. Having someone else mention this a well makes me more confident to add it to the defaults.
It kind of makes me wonder if cargo install is the right choice of command to use. This is the second surprising difference between cargo build and cargo install that I've hit with the buildpack. The other was related to building a full workspace. Anyway, I'd be curious to get your thoughts on that as well. Is cargo install what you'd expect here? or would it make more sense to use cargo build?

IIRC the problem with cargo build is not knowing where the binaries end up. In cargo2nix we solved this by using json output from cargo and parsing it. Cargo install side steps that problem.
On a relatedish note though, I'd still like to find a way to build the test binaries and have them in the built image, so maybe cargo build would get me closer to that

Yes, we are pulling out binary names from cargo metadata already so it's probably not too much work to support cargo build as well. I will open a separate issue.

repo: paketo-community/cargo


text:
Add whitelist/blacklist support

Currently, .launch file is created for all JavaExec tasks. Whitelist/blacklist support would be very useful especially when the default JavaExec task should be overridden with more sane defaults.

Sweet. Thanks @qinfchen.
Btw, it looks like the release is made on GH, but is not published to bintray yet. https://plugins.gradle.org/m2/com/palantir/launchconfig/gradle-launch-config-plugin Do you guys plan to publish it soon?

we are fixiing the plugin name to comply with baseline gradle plugin spec.  https://github.com/palantir-baseline/gradle-launch-config-plugin/pulls

authors: mingyukim qinfchen


text:
no-floating-promises not being reported in VSCode (Works via CLI)

Bug Report

TSLint version:  5.11.0
TypeScript version: 3.1.3
Running TSLint via:  VSCode
VSCode version: 1.28.2
TSLint extension version: 1.0.40

TypeScript code being linted
class MyClass {

    async test() : Promise<string> {
        return "new";
    }

    test2() {
       // not awaiting this so should error.
       this.test();
    }
}

with tslint.json configuration:
{
    "rules": {
        "no-floating-promises": true,
        "semicolon": true
    }
}

Actual behavior
When running via CLI, works as expected with error: ERROR: /home/me/code/scratch/app.ts[10, 8]: Promises must be handled appropriately
However via VSCode, no problems are reported. Other rules work OK.

Expected behavior
Promises must be handled appropriately error should show in VScode.

Heya @Recodify - this is a known issue with the TSLint VS Code extension. It won't run "typed" rules (rules that require full information from TypeScript instead of just the basic AST information) for performance concerns. https://github.com/Microsoft/vscode-tslint/issues/70
You can try out the experimental plugin if you'd like: https://github.com/microsoft/typescript-tslint-plugin/

Thanks for the quick response @JoshuaKGoldberg, Makes sense. Happy to close this.

authors: JoshuaKGoldberg Recodify

repo: palantir/tslint


text:
Have option to not add space to autocompletion suggestions

Currently if an option has autocompletion function that returns a list of paths (reachable from current working directory), then when there is only one path left in list so TAB accepts it, click automatically appends a space after the slash. Say you type ("|" represents the cursor):
mycommand.py some/path|TAB

and the TAB allows for completion because there is only one option ["some/path_to_file/"], you get a space before the cursor:
mycommand.py some/path_to_file/ |

Needless to say this is non-standard and almost never what user expects or desires. Is there a way to configure a click option to not append space, or to patch click so there is no space inserted after the completion?

cf #1403

I don't think this is the right solution to the issue, and want to avoid adding more switches for things. That said, #1622 redesigns the completion system and makes it much easier to customize how completions are returned.

authors: davidism dimbleby schollii

repo: pallets/click


text:
Fix using non-strings as anchors

Previously, non-strings passed to _anchor would be converted to strings. Restore this ability. The logic is the same as in url_quote.
Fixes: #5206
Checklist:

[x] Add tests that demonstrate the correct behavior of the change. Tests should fail without the change.
[x] Add or update relevant docs, in the docs folder and in code.
[x] Add an entry in CHANGES.rst summarizing the change and linking to the issue.
[x] Add .. versionchanged:: entries in any relevant code docs.
[x] Run pre-commit hooks and fix any issues.
[x] Run pytest and tox, no tests failed.

Passing a non-string as an anchor was never intentionally supported, you were relying on undefined behavior. I don't plan to add a warning back in just to then remove it again. It's the same result either way here: you need to pass a string.

Except, we're not passing bytes, we're passing integers (or any other object with a __str__). This seems to be unintended behavior justified post-hoc. And what is the advantage? The API becomes more cumbersome, since you must add explicit conversions, even though we know what the end type must be. Other arguments to this same function are converted implicitly. For example, if you have
@flask.route('/<foo>')
def bar(foo):
    ...

you can then write
url_for('.bar', 5)

and the argument will be implicitly converted to a string.

repo: pallets/flask


text:
Support digest_size when using blake2s or blake2b

Hi, currently I cannot find a way to set the digest_size when using blake2s or blake2b.
Can someone point me in the direction of maybe subclassing the HMACAlgorithm? Thanks

You would implement a custom SigningAlgorithm then pass it to the signer.
https://github.com/pallets/itsdangerous/blob/6567d656f0386cfe647c9ad5cdfc59e68150487c/src/itsdangerous/signer.py#L15-L28
https://github.com/pallets/itsdangerous/blob/6567d656f0386cfe647c9ad5cdfc59e68150487c/src/itsdangerous/signer.py#L136

authors: awiprayitno davidism

repo: pallets/itsdangerous


text:
aclose root_render_func in generate_async

fixes #1956

Checklist:

[ ] Add tests that demonstrate the correct behavior of the change. Tests should fail without the change.
[ ] Add or update relevant docs, in the docs folder and in code.
[x] Add an entry in CHANGES.rst summarizing the change and linking to the issue.
[ ] Add .. versionchanged:: entries in any relevant code docs.
[ ] Run pre-commit hooks and fix any issues.
[x] Run pytest and tox, no tests failed.

Superseded by #1950

authors: davidism graingert

repo: pallets/jinja


text:
Expose new path used to compute new url in RequestRedirect

The RequestRedirect exception is raised with new_url set to
the computed URL that should be redirected to, but we don't
expose the path that was used to compute the URL in the exception
so depending code needs to urlparse() the URL even though
werkzeug already has the path and can pass it along in the exception.
Referring to this example code:
    def resolve_endpoint(self, environ, path, method):
        """Resolve endpoint from the url map.

        :environ Environment: The environment.
        :path str: The request path.
        :method str: The request method.
        :returns str: The endpoint from the url map.
        """

        urls = url_map.bind_to_environ(environ)
        try:
            endpoint, _ = urls.match(path, method=method)
            return endpoint
        except routing.RequestRedirect as e:
            r = urlparse(e.new_url)
            return resolve_endpoint(environ, r.path, method)
            # FIXME: this could be e.new_path if RequestRedirect passed path
            # return resolve_endpoint(environ, e.new_path, method)
        except (wexc.NotFound, wexc.MethodNotAllowed):
            pass

        return None

What situation do you need this in?

In this case it's a WSGI middleware that uses werkzeg's routing module for matching routes to know when to apply a specific logic. The module does a great job to match URLs but we need to handle cases where URLs contain a trailing slash or double slashes in the middle of the URL.
Example: Lets say we want to match /some/cool/url we also need to match //some/cool/url, /some/cool/url/ and /some//cool/url – works great in the current form but we could optimize away the extra urlparse() per request if werkzeug exposed the URL path it wants to redirect to and not only giving us the full URL in the RequestRedirect exception.

You could disable merge_slashes, strict_slashes, and redirect_defaults if you don't want to cause redirects and just want them to match the endpoint. You'll presumably end up with the redirects anyway once you route in the app, which would result in this logic running multiple times (the first when you match without redirects and apply it, the the second after you redirect then match and apply again). Also note that redirects can happen for other reasons, such as the rule itself being a redirect, and redirects can go to more places than the current host or subdomain. So it's not clear this would be usable in all cases.
If you're calling match in middleware, then calling it again in the actual app to do routing, then presumably the performance of a single urlsplit call is insignificant. But if it is significant, you can also do much simpler fast string operations to get the path: path url.partition("/")[2].partition("#")[0].partition("?")[0].

This is how the Map and Rule is setup, with this and the resolve_endpoint() above we can have it return cool as endpoint for all the URLs in my previous comment, and if it returns None we just pass the request directly to the application without intercepting it.
url_rules = [
    routing.Rule('/some/cool/url', methods=['POST'], endpoint='cool'),
]
url_map = routing.Map(
    rules=url_rules,
    strict_slashes=False,
    merge_slashes=True,
    redirect_defaults=False,
)

authors: davidism tobias-urdin

repo: pallets/werkzeug


text:
Some of the Greys are a Little Green.

For e.g. --color-brand-grey-lightest

@nathanyoung just wanted to make sure you saw this. I am seeing the same thing. very apparent in the table, where we use grey-lightest.

The grey is meant to be a little green, not simply neutral greys. I want the greys to be on the warm side. As we get into more use cases, I can reduce the level of green if we find it's too much.
Still yet to be determined if we should offer zebra striping for the table.

authors: JCarmine juanfabrega nathanyoung

repo: palmetto/palmetto-components


text:
ASCII Colors in Message Supported?

Is ASCII color decoding supported in hl if it is in the message? I know this worked for me at some point.
Command
hl --color always filename.log --since -1d

Output in Terminal
Aug 19 04:04:07.798 PM EDT |INF| "[\u001b[1mINFO \u001b[0m] [\u001b[34mMainThread\u001b[0m] [\u001b[36m__init__.py         \u001b[0m:\u001b[36m1706\u001b[0m] \u001b[1mFinished processing state st_aws_job_standby exit callbacks.\u001b[0m"

Unfortunately, it never had proper support for colors in either messages or field values.
But to improve readability of messages and field values with newline and tab characters, they were printed as-is, without any processing.
One of the side effects of such a simple approach was some sort of "support" for ANSI colors.
But this "support" came with a lot of problems, including ambiguous output of messages/fields containing spaces, quotes, and other special characters. Sometimes it was impossible to parse them (even visually by a human) and understand where a field or message starts and ends, and what the exact value is.
Also, passing arbitrary control characters could have dangerous effects, because they could contain terminal control sequences other than just changing colors, and thus corrupt the output.
So now both fields and messages are printed unambiguously, enclosed in the most appropriate quotes as needed, and with proper escaping for special characters that might corrupt the output or cause confusion.
There is some unfinished work to improve formatting of long messages and fields, as well as values containing some newline and tab formatting, but this does not yet address support for ANSI colors in values.
It seems that ideally to support ANSI colors in values, the ANSI escape sequences should be parsed and only safe sequences should be processed, all others should be ignored and discarded. And it should probably be turned on/off by a separate option, since it is not obvious which variant of output is desired.
I will think about adding support for ANSI colors in values when I have some time.
But in the meantime, I would recommend that you investigate whether it is possible to handle this problem from the other side. It looks like you already have some logs that are supposed to be structured, at least they have a log level and some special formatting that could itself be replaced with JSON or logfmt format. This wrapping of unstructured and colored logs into a message field of structured logs seems unnatural. Presumably the log level information is lost at this point, as well as the benefits of structured logging, which allows you to filter/search/query by key/value pairs.
If it is not possible to change the format of the logs in your case, could you please describe why and what is the usage scenario and logging configuration which that leads to this wrapping?
If anyone else needs this feature, please let me know as well. The more usage scenarios that require this feature, the more likely it will be implemented soon.

Thanks for the information! I will try to remove those coloring stuff using regex.

repo: pamburus/hl


text:
使用getHTML() 得到的HTML，里面流程图不是解析后的

怎么在getHTML()获得HTML,流程图是绘制好的SVG

I would also be interested to learn how to get the HTML, would like to save both HTML and markdown

you can use jqurry to select the element, and then $().innerHTML

authors: AlmogRnD MaLuns wanglide


text:
[BUG] DataFrameGroupBy.apply can return Series

Describe the bug
Calling apply on a grouped DataFrame - ie a DataFrameGroupBy object - usually returns a DataFrame, and this is correctly typed in the stubs. However, if the callable being applied returns a scalar rather than a DataFrame or Series, then apply will in turn return a Series. This is documented in example 3 in the docs for GroupBy.apply.
To Reproduce
Toy example:
df = pd.DataFrame({"col1": [1, 2, 3], "col2": [4, 5, 6]})
result: pd.Series = df.groupby('col1').apply(lambda x: x.sum().mean())
assert(isinstance(result, pd.Series))

This code runs correctly and the assertion succeeds, but mypy gives "Incompatible types in assignment (expression has type "DataFrame", variable has type "Series[Any]")".
Please complete the following information:

OS: MacOS
OS Version: 12.5
python version: 3.9.9
mypy version: 0.971
version of installed pandas-stubs: 1.4.3.220718

Additional context
It's not obvious how this could be fixed. I tried using overload to give different return types depending on the type of Callable passed:
    @overload
    def apply(self, func: Callable[[DataFrame], Union[DataFrame, Series]], *args, **kwargs) -> DataFrame: ...
    @overload
    def apply(self, func: Callable[[DataFrame], Union[Scalar, Sequence]], *args, **kwargs) -> Series: ...

and this correctly lints the example above, but fails in at least one particular circumstance: Pandas special-cases the built-in functions sum, max and min when passed to apply, replacing them with their numpy equivalents, so the above code causes the test in https://github.com/pandas-dev/pandas-stubs/blob/main/tests/test_frame.py#L558 to fail.

Can you overload those functions specifically?  No idea if a Literal would work on these functions.

This is a bit tricky.  I have something that works now.

authors: Dr-Irv bashtage danielroseman

repo: pandas-dev/pandas-stubs


text:
konga update service error

when I use https to connect kong admin(https://localhost:8444)
everything is ok but when I edit service's description I got error:
`error: Error (E_VALIDATION) :: 1 attribute is invalid
error: duplicate key value violates unique constraint "konga_kong_services_service_id_key"
at Connection.parseE (/app/node_modules/sails-postgresql/node_modules/pg/lib/connection.js:539:11)
at Connection.parseMessage (/app/node_modules/sails-postgresql/node_modules/pg/lib/connection.js:366:17)
at Socket. (/app/node_modules/sails-postgresql/node_modules/pg/lib/connection.js:105:22)
at emitOne (events.js:116:13)
at Socket.emit (events.js:211:7)
at addChunk (_stream_readable.js:263:12)
at readableAddChunk (_stream_readable.js:250:11)
at Socket.Readable.push (_stream_readable.js:208:10)
at TCP.onread (net.js:601:20)
Invalid attributes sent to undefined:
• service_id
• A record with that service_id already exists (e4614d2c-0bf0-413d-b551-657a2ea4991a).`
kong version: 1.2.0
konga image : pantsel/konga:latest

kong'db is postgresql

@chenxuefeng1207 , use pantsel/konga:next, until the release makes it to master

@pantsel  I try the konga:next but got the same error .

@pantsel  I create a new service ant edit it's description is ok ,but for old service is not ok

I know the reason ,beacause konga_kong_service's kong_node_id is the primiray key of konga_kong_nodes, so http and https connection is two connect, it's kong_node_id is different,
update the konga_kong_service's kong_node_id for https's kong_node_id,then everything is ok!

repo: pantsel/konga


text:
can't create a route kong

HI everyone
i recently added a service with kong with this command:
curl -v -XPOST \

http://localhost:8001/services
-H 'Content-Type: application/json'
-d '{"name":"api1","retries":1,"host":"httpbin.org"}'

and it worked.
now i want to create a route to receive the response for incoming requests and i've used this command:
curl -i -XPOST
http://localhost:8001/routes
-H 'Content-Type: application/json'
-d '{"name":"api1-route", "protocols": ["http", "https"], "methods": ["GET"],"hosts": ["popularowl.com"], "paths": ["/api1"], "strip_path": true, "preserve_host": false, "service": {"id":"873c5cd8-26ff-4dd1-a3a4-e0c48ad72f18"} }'
BUT it gave me this instead of creating a route:
{"strategy":"postgres","message":"schema violation (name: unknown field)","name":"schema violation","fields":{"name":"unknown field"},"code":2}
and it doesn't create a route!
can anyone help please

@AliShelby , what version of Kong/Konga are you using?

kong version: 0.14.1

From 0.14.0 onwards, Konga is ONLY compatible with Kong >= 1.0.0
If you're on an older Kong version , use this branch
or konga:legacy from docker hub instead.
It is mentioned in the compatibility section of the README.md

I'm not using konga for kong
i write the commands on terminaal ubuntu

Ok then, maybe you got confused.
This is not Kong's repo.
This is Konga's one.
You may want to ask Kong related questions there.

oh my bad
thanks

authors: AliShelby pantsel


text:
Efficient training on OOS datasets

I'm curious if there are any examples of fine-tuning the model, either using the transformers version or, ideally the galai library directly. I assume it's not too different from any other model but I'd still feel more confident doing so with some examples.
I'd also be curious to know if there are examples or attempts at training this model specifically to answer questions based on a person's understanding, i.e. either:

Using a dataset where the outputs are the model's own outputs adjusted to be understandable by that person or
Using a dataset of writing and conversation from that person to hopefully pick-up on speech patterns that make sense to them.

I've been toying around with this idea using scibert and a t5 trained on a similar corpus but this model seem superior to both.

Also curious about good examples of fine-tuning Galatica model... I would be interested in fine-tuning the model for research problems in biology.

repo: paperswithcode/galai


text:
Include ommers_hash in SealedBlock

Describe the feature
In the following function:
https://github.com/paradigmxyz/reth/blob/0f254e16a50a6d39543fe59590227a09fd0e21bb/crates/consensus/common/src/validation.rs#L196-L208
the ommers_hash is calculated inside the function using the calculate_ommers_root method. Why not directly integrate directly this ommers_hashfield into the SealedBlock structure. This could be useful in this function on the one hand but also in other future implementations, what do you think?
Additional context
No response

the ommers hash is now redundant but I'm wondering why the calculate_ommers_root does not check for an empty input list
https://github.com/paradigmxyz/reth/blob/0f254e16a50a6d39543fe59590227a09fd0e21bb/crates/primitives/src/proofs.rs#L104-L108
we also have some debt here where the same consts are defined twice
https://github.com/paradigmxyz/reth/blob/0f254e16a50a6d39543fe59590227a09fd0e21bb/crates/primitives/src/proofs.rs#L14-L20
https://github.com/paradigmxyz/reth/blob/0f254e16a50a6d39543fe59590227a09fd0e21bb/crates/primitives/src/constants/mod.rs#L98-L105

the ommers_hash is calculated inside the function using the calculate_ommers_root method. Why not directly integrate directly this ommers_hashfield into the SealedBlock structure.

it's already part of the header, here we just confirming that the field in the header is actually correct

not sure about the todo, looks outdated/wrong

@mattsse I see, so I propose to solve that by:

Removing the outdated todo comment
Checking for empty [Header] list in calculate_ommers_root in order to return properly the EMPTY_ROOT directly without calling the encode_list unnecessarily
Eliminating the constants from the proof.rs file to keep only those in the crate primitives and standardize everything

What do you think?

without calling the encode_list unnecessarily

yeah newer blocks will benefit from that because this will prevent encoding an empty list header

Eliminating the constants from the proof.rs file to keep only those in the crate primitives and standardize everything

sgtm
this comment is also wrong:
https://github.com/paradigmxyz/reth/blob/0f254e16a50a6d39543fe59590227a09fd0e21bb/crates/primitives/src/constants/mod.rs#L103-L105
because this is the hash of an empty trie
and also, this function is unused and can be removed
https://github.com/paradigmxyz/reth/blob/0f254e16a50a6d39543fe59590227a09fd0e21bb/crates/primitives/src/proofs.rs#L95-L101

Hey if this issue is free, i can take it :)

authors: DoTheBestToGetTheBest mattsse tcoratger

repo: paradigmxyz/reth


text:
chore: Move FillTxEnv::fill_tx_env into SignedTransaction trait and implement in TransactionSigned

Closes https://github.com/paradigmxyz/reth/issues/12182
Moves fill_tx_env into the SignedTransaction trait and implements it in TransactionSigned

I have a pr ready that I can stack right on top of this when merged, for removing op code from the rest of SignedTransaction impl

authors: emhane garwahl


text:
Keyboard Shortcuts on tablets with Wireless Keyboards?

Once Chrome IDE works on mobile devices (that do not have a fixed hardware keyboard), will all the keyboard shortcuts we add in naturally be ignored (no conflicts) for normal use?  Also, will those same shortcuts naturally become available if the user pairs their device with a wireless (Bluetooth) keyboard?
NOTE: Issue #70 is loosely related.

This issue is loosely related to #159 but of itself is less a UX issue than a technical one.

authors: PropGit urbantumbleweed

repo: parallaxinc/ChromeIDE


text:
Add new source cookie util & add set call to IdentityX login route

This will use the login source being sent to the login component to set the cookie value for login source.  This will be used at later steps in the identity x process to send along source information.
In this example it will now set the identity-x-source: comments so that later on when the user authenticates or updates their profile it would know that the login source was commenting and can adjust the promoCode &or products accordingly.

 Implement "article_comments" promo code


text:
Split up preferenceCenterUrl URL parameters

https://my.auntminnie.com/unsubscribe-from-newsletter/?email={{${email_address} |%2[…]dit&braze_int_id={{${braze_id}}}&braze_ext_id={{${user_id}}}
vs
https://my.auntminnie.com/unsubscribe-from-newsletter/?email={{${email_address} |%2[…]dit&braze_int_id={{${braze_id}}}&braze_ext_id={{${user_id}}}

 Change to the AuntMinnie LFTE template footer.


text:
[Solvers][Mesh] Add CFL condition calculation to solvers

This PR adds the ability in each time-dependent solver to properly calculate the CFL timestep restriction. Currently, all solvers will only do this calculation once, after the initial condition is set. Aside from being slightly more robust when starting timestepping, this may be useful in the future for some timesteppers to adapt the timestep size.
This PR also addresses #25.

Using max velocity instead of dt ~ min(h/(lambda*N^2)) will be pessimistic

Would you prefer calculating min(h/lambda) over all elements over computing min(h) and max(lambda)?

I think so. Sorry for not noticing that before.

Sounds good. No reason we cant do that with a small tweak. I also need to update some golden norms. Some have shifted slightly enough that units tests are failing.

authors: noelchalmers tcew

repo: paranumal/libparanumal


text:
Panic with vdso mapping

Regarding the panic, it occurs at if l.Location.Mapping.File == "[vdso]" { ... } https://github.com/parca-dev/parca-agent/blob/main/pkg/symbol/symbol.go#L82. The mapping is nil for some reason &{ID:24 Mapping:<nil> Address:85858880 Line:[] IsFolded:false mappingIDX:0}.
Originally posted by @marselester in https://github.com/parca-dev/parca/pull/2955#discussion_r1195316691

Should be fixed.

repo: parca-dev/parca-agent


text:
client: added linting & test

Added linting to the project (it actually already had it, I just didn't use it as it would change to many files).
Ran yarn run format which runs the included eslint and prettier (which has pluggins formated for svelte language so I don't know if we can actually use opstooling-js-style for this case)
Added playwright tests to the project.
Now it run tests on a headless browser verifying that the implementation works correctly.
Added CI step for running these new steps.

@rzadp could you please review it again? I have added tests also to this PR

repo: paritytech/substrate-matrix-faucet


text:
contracts: Use pre image pallet to store contract code

When loading contract code from storage we don't know its size before loading. This results in the side effect that we need to pre-charge assuming a maximum sized contract and adjust after loading. This can get quite costly for nested call stacks or just for contracts that call many other contracts and do nothing else.
To fix this issue we should leverage the preimage pallet which will allow us to know the size before loading.

We are mainly interested in this QueryPreimage  that exposes a len and fetch method and PreImageRecipient to note (aka store a preimage)

There are no concerns that doing an extra io to fetch the len of the preimage reduce the overall benefits of the pallet?

Having to do another storage item access to get the length vs. overcharging is the trade off we have to decide here.

Also, What about simply storing the len in the CodeInfo struct?

I was just thinking: Why re-implement something that already exist. But since we have to load the CodeInfo anyways we can just put the value there and get the info basically for free.

that's what  I did here ->
https://github.com/paritytech/substrate/pull/14523https://github.com/paritytech/substrate/pull/14523
if we merge it fast I think we can just re-use @agryaznov 's v12 migration and add the extra field in there

authors: athei pgherveou

repo: paritytech/substrate


text:
Networking roadmap

Here are some steps that I have in mind for the network crate, ordered in order to have a smooth transition. Feel welcome to comment.

[x] Make Service and ServiceEvent generic over the message type, and send/receive messages instead of Bytes objects.
[x] Add a trait in network-libp2p that is implemented on Message and allows retrieving the RequestId.
[x] Make network-libp2p/src/custom_proto/handler.rs open a new substream for each request. Whether to wait for an answer and how to associate substreams with requests is done using the trait mentioned in the previous point. (#1517)
[ ] Remove the Clogged event.
[ ] (blurry) Rewrite network/src/protocol.rs as a libp2p NetworkBehaviour. Instead of passing a RegisteredProtocol to network-libp2p, one can pass a NetworkBehaviour. Move network-libp2p/src/custom_protocol to network. The messages generated by the API of network-libp2p's Service would be the events generated by the network behaviour. We would also require a trait in addition to NetworkBehaviour so that we can register discovered nodes to the behaviour.
[ ] Move some logic from the protocol.rs NetworkBehaviour into the ProtocolsHandler, such as the Status message. After this point, #1518 and #1702 can be tackled.
[x] Extract the gossiping from protocol.rs to use a different protocol from the rest (the rest meaning things such as block or header requests).
[x] (blurry) Use libp2p's floodsub, episub or gossipsub instead of consensus_gossip (#366).
[ ] Change everything to use futures and messages passing instead of Arcs (#834), and use tokio-timer instead of maintain_peers, tick or garbage_collect.
[ ] Merge network and network-libp2p?

Later:

[ ] Remove backwards compatibility for #1517.
[ ] Remove the RequestId from network::message::Message and let libp2p do the ID assignment.

The current step is more or less "Rewrite network/src/protocol.rs as a libp2p NetworkBehaviour" now.
For this step, I'm going to change a bit the API of substrate-network-libp2p.
At the moment, it is an opaque state machine where you open/close connections with remote, and read/write messages.
After this step, the ServiceTask struct would accept two template parameters: a discovery protocol, and a gossiping protocol. They would both be defined by traits in substrate-network-libp2p. The discovery protocol would generate events that are then indirectly reflected on the gossiping protocol, and the gossiping protocol would generate events that are propagated to the outside of the ServiceTask.
The text mentions "Move network-libp2p/src/custom_protocol to network.", but I wouldn't do that in the end. The substrate-network-libp2p crate would provide implementations of the discovery and gossiping traits that could be used by whatever code uses substrate-network-libp2p.

@tomaka Do you need help with "Rewrite network/src/protocol.rs as a libp2p NetworkBehaviour"?

The first step was https://github.com/libp2p/rust-libp2p/pull/1046 in libp2p. Once a libp2p version is published I'll finish my work in progress PR.

I'm going to close this issue, as half of it is implemented and only #2374 is still important.

authors: gterzian tomaka


text:
[tracking] clean up dependeny licenses

cargo license tells us we have a bit of cleaning up to:
GPL 3
The following leak the GPL-3.0 into our substrate (other than our local ones) – but are under our control:
parity-util-mem, fdlimit, kvdb-memorydb, parity-util-mem, parity-bytes, kvdb-rocksdb, kvdb, kvdb-web,
And the following are pulled in:

[x] webpki– Customm ISC afaid...
[x] ring – Custom License, I understand to be ISC, is that correct?
[x] target_info – MIT
[ ] fuchsia-cprng (via rand 0.4.6, through tempdir in sc-client-db), which I can't really find the appropriate License definition for, but  we should really upgrade rand because it dropped the dependency already

ring uses an ISC license for all new code, but it is based on BoringSSL, which is a fork of OpenSSL.

according to wikipedia fuchsia is " BSD, MIT, Apache License 2.0"

authors: DemiMarie-parity gnunicorn


text:
[Feature] StakeTracker P1 - VotersList

Original issue: https://github.com/paritytech/substrate/issues/12719
Splitting up https://github.com/paritytech/substrate/pull/12744
polkadot companion: https://github.com/paritytech/polkadot/pull/6527
Terminology
Approval stake - a sum of all the nominator/nomination pools stakes that are backing this validator + self-stake.
Goals
The original goal of this series of PR's is to introduce a list of validators sorted by their approval stake, therefore eliminating the need for Max Validator Intentions parameter. This way we'll be able to look into top x validators in the list to get a set of electable ones.
While doing that we also introduce a concept of EventListeners into Staking, that would allow us to hook into various staking methods acting upon emitted events. In this particular case this allows us to delegate the sorted list maintenance to a 3rd party EventListener.
Technical details
This PR introduces a new Staking-related abstraction called OnStakingUpdate that basically provides the ability to subscribe to certain events that Staking fires and act upon them.

/// A generic staking event listener.
/// Note that the interface is designed in a way that the events are fired post-action, so any
/// pre-action data that is needed needs to be passed to interface methods.
/// The rest of the data can be retrieved by using `StakingInterface`.
pub trait OnStakingUpdate<AccountId: Clone, Balance: Copy> {
	/// Fired when the stake amount of someone updates.
	///
	/// Also called when someone stakes for the first time. (TODO: is it? this is why we need unit
	/// tests for this pallet alone).
	///
	/// This is effectively any changes to the bond amount, such as bonding more funds, and
	/// unbonding.
	fn on_stake_update(who: &AccountId, prev_stake: Option<Stake<AccountId, Balance>>);
	/// Fired when someone sets their intention to nominate, either new, or existing one.
	fn on_nominator_update(who: &AccountId, prev_nominations: Vec<AccountId>);
	/// Fired when someone sets their intention to validate, either new, or existing one.
	fn on_validator_update(who: &AccountId);
	/// Fired when someone removes their intention to validate, either due to chill or nominating.
	fn on_validator_remove(who: &AccountId); // only fire this event when this is an actual Validator
	/// Fired when someone removes their intention to nominate, either due to chill or validating.
	fn on_nominator_remove(who: &AccountId, nominations: Vec<AccountId>); // only fire this if this is an actual Nominator
	/// fired when someone is fully unstaked.
	fn on_unstake(who: &AccountId); // -> basically `kill_stash`
}

The first event listener implementing this interface, also introduced in this PR, is called pallet-stake-tracker which currently takes care of maintaining VoterList (a sorted list of nominators and validator's self-stake), effectively moving this logic out of Staking. It's also supplying Staking with a read-only version of this list, which is currently implemented by adding some defensive checks into insert/updated/remove methods.
Some other things that were introduced in this PR include:

Staking tests that verify the correct OnStakingUpdate events are being fired with the right arguments.
A read-only wrapper for SortedListProvider, that stubs out update/insert/remove methods and only leaves unsafe methods to allow for easier benchmarking/testing/migrations.
CurrencyToVote moved from frame_support to primitives/staking.

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable-int
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2228060

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2228055

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2228054

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2228232

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2228226

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable-int
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2228237

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable-int
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2229254

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2229244

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2229249

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2229247

@kianenigma This does not have dedicated tests for StakeTracker yet, but it runs Staking tests against StakeTracker and it all works. Separate unit-tests for tracker are going to be introduced, however I think we shall retain the Staking part of those tests too as Staking relies on the outcome of the VotersList.
There is one test that is failing: https://github.com/paritytech/substrate/pull/13079/files#diff-64c049b4e94a55bdeaf757c725cf7d1df623b754557af4ced157024a943c4703R5145 that I think has to be removed.
As discussed in Frame channel before - we don't want to cater for un-decodables due to MaxNominations decrease, this should be accompanied by a migration. And it simplifies the code by quite a bit.

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2231096

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2231687

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2231791

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2231796

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2231794

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2231790

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2231795

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable-int
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2231801

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-each-crate
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2231805

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-each-crate
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2231806

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable-int
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2232141

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2232279

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2236668

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2236715

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2236716

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2240227

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2240332

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-each-crate
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2240346

bot rebase

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2240804

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-each-crate
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2240819

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2251243

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2251242

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2251241

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable-int
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2258467

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable-int
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2258632

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable-int
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2263044

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2263221

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2263223

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2263222

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable-int
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2266485

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2266480

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2266479

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2266478

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable-int
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2273770

bot rebase

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2276620

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2276621

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2276619

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2276733

bot rebase

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2285417

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2285412

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2285415

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2285416

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable-int
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2373323

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable-int
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2373429

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2373515

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-each-crate
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2373529

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2373514

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2374253

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2374252

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-each-crate
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2374267

bot rebase

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable-int
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2374442

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2374636

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2374637

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2374638

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2375753

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2375752

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-each-crate
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2375767

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2376435

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2376534

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2378779

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2378780

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2378778

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2379571

bot rebase

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2405775

bot rebase

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2406071

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2406072

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2406070

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-each-crate
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2411630

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-each-crate
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2411770

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2411809

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2412004

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2412005

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2427992

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2449417

bot rebase

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2450449

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2450448

bot rebase

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2485624

bot rebase

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2510734

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2510733

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-each-crate
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2515361

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-each-crate
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2517349

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-each-crate
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2517398

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-each-crate
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2519867

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-each-crate
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2521748

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable-int
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2521890

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2521883

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable-int
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2521941

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2521935

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2521936

bot rebase

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2548673

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2548671

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2548672

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2566054

bot rebase

bot rebase

I will re-open this from a new PR, based on your commits. Thank you Roman for your contribution 💯

@kianenigma I'm planning to finish this up in a new PR coming from my fork sometime soon.

authors: kianenigma paritytech-cicd-pr ruseinov


text:
node: Reintroduce --validator cli flag

Conflicts with #3348 but I think I prefer this one instead, because realistically no one will actually pass --no-validator and full nodes will be unnecessarily running validator code.

Sorry when I wrote this I didn't see you were already working on #3348 (I had no internet).