Support Tuples

In TypeScript, it is possible to define Tuples, which are just arrays with specific types at each index. It would be awesome if JSDoc could understand those as well. Having this would help with mixing TS and JS with JSDoc.
I’m not exactly sure if JSDoc has to follow the Closure Compiler’s standards, but there is an open issue for the same thing there.
This is kind of related to #1073 but slightly different as that issue mentions documenting the elements themselves while my proposal is to allow documenting for the type/shape of an array.
Expected behavior
/**
 * @typedef {[number, number, number]} Vector3
 */

let a = []; // invalid, length is 0 (and don’t know type)
let b = [1]; // invalid, length is 1, should be 3
let c = [1, 2, 3]; // valid
let d = ["hello", 2, 3]; // invalid, index 0 is a string

Current behavior

Right now, the only way to specify this is with a simple number[] array, but this isn’t specific enough. Having this could allow for typing such as Object.entries, which returns a [string, T] (T being the Object’s value type but that’s not too relevant for this).

So, now you can use this approach:
Array<*> & { 0: string, 1: number, length: 2 }

for describing a tuple like [string, number]

Is & supported as an operator in jsdoc? I don't see it at https://jsdoc.app/tags-type.html and #1285 was closed. It's quite a fundamental feature though, so would be nice to have if not.
Btw, there's a stage 1 Tuple proposal, so with the possibility these types end up making it into JS, one might wish to take this into account when naming a similar but different feature as in this issue.

@brettz9

Is & supported as an operator in jsdoc?

I use jsdoc type checking powered by TypeScript and intersection works as expected there. Don't know about native jsdoc support.

If you're using TypeScript, then you can simply use (or in JSDoc-like comments, the same works)
type Vector3 = [number, number, number];

but this issue is to bring support for this syntax in JSDoc itself (without TypeScript).

This is worthy of support.  It's very common to destructure array parameters as tuples.  Call it a "TupleArray" if you're worried about a future Tuple type, but it doesn't really even need a name:
/** @type {[number, number, number]} */
let x = [0, 0, 0];

Or just doing {number[3]} would be awesome too.
Thanks for suggesting this.

The following works in VS code:
/**
 * @template IType
 * @template FnReturnType
 * @typedef {[IType, FnReturnType]} ConditionPair
 */

 // resulting type shown in vscode when ts-check pragma is defined:
 // type ConditionPair2<IType, FnReturnType> = [IType, FnReturnType]

Any news on this feature?
My code relies on tuples (e.g. coordinate points, or many other things), and eslint generates warnings every time I compile my code (it was silent before version 28).

Any news on this feature?
My code relies on tuples (e.g. coordinate points, or many other things), and eslint generates warnings every time I compile my code (it was silent before version 28).

You can use type expressions, as demonstrated in the OP, for simple cases

This is worthy of support. It's very common to destructure array parameters as tuples. Call it a "TupleArray" if you're worried about a future Tuple type, but it doesn't really even need a name:
/** @type {[number, number, number]} */
let x = [0, 0, 0];

This works fine but is there any way to describe the index value, so basically, 0th IDX is firstNum, 1st IDX is secondNum and 2nd IDX is the sum.

@anks333 What do you mean by 'works fine'? This syntax is illegal in jsdoc. Whilst vscode can handle this syntax, the jsdoc CLI cannot.

The issue section here is littered with people who say "JSDoc" but mean "the Typescript JSDoc parser".  I've said it elsewhere but it bears repeating: there have been no significant changes to this repo in 5 years.  The project is effectively dead.  Unfortunately, there are still active projects out there that rely on JSDoc's parser, but you should not expect it to change to keep up with the evolving ecosystem.
(As I've also said before, early work on JSDoc was absolutely vital to the health of the JS/ES/TS ecosystems; it was such an important project and I greatly value the contributions of everyone who worked on it!  But if you don't swim, you die, and this project stopped swimming in 2017.)

The issue section here is littered with people who say "JSDoc" but mean "the Typescript JSDoc parser". I've said it elsewhere but it bears repeating: there have been no significant changes to this repo in 5 years. The project is effectively dead. Unfortunately, there are still active projects out there that rely on JSDoc's parser, but you should not expect it to change to keep up with the evolving ecosystem.
(As I've also said before, early work on JSDoc was absolutely vital to the health of the JS/ES/TS ecosystems; it was such an important project and I greatly value the contributions of everyone who worked on it! But if you don't swim, you die, and this project stopped swimming in 2017.)

So, what do you propose @thw0rted ?

I don't have a great solution.  Most of the times I've found myself here, it's because of tsd-jsdoc. Another library I use a lot had pretty extensive JSDoc, so one of their contributors created a build process to turn the comments into Typescript typings, and I helped clean those up.  Some of the more advanced use cases weren't supported by vanilla JSDoc, so we had to get creative, file a few issues with tsd-jsdoc ,etc.  I think I even opened some feature requests here, but I've come to realize it doesn't make sense to expect them to be implemented.
For my specific case, I think this might be the way forward -- drop vanilla JSDoc altogether, and switch to the TS compiler for doc parsing.  For better or worse, TS seems to be the most active dialect of JSDoc.  Of course, for those using other languages (JS/ES, or another derivative that's JSDoc-compatible) that might make less sense.


Istio 1.1.6 multiple pods not in running state

We're trying to set up Kubeflow on a single-node cluster.  We're facing issues with getting the istio-system up and running; upon checking we found the version to be 1.1.6.  This configuration will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.
[2020-07-21 08:03:33.806][23][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] Using deprecated option 'envoy.api.v2.Cluster.hosts' from file cds.proto. This configuration will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.
[2020-07-21 08:03:33.806][23][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] Using deprecated option 'envoy.api.v2.Cluster.hosts' from file cds.proto. This configuration will be removed from Envoy soon.  This configuration will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.
[2020-07-21 08:05:13.304][174][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] Using deprecated option 'envoy.api.v2.Cluster.hosts' from file cds.proto. This configuration will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.
[2020-07-21 08:05:13.304][174][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] Using deprecated option 'envoy.api.v2.Cluster.hosts' from file cds.proto. This configuration will be removed from Envoy soon.  This configuration will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.
[2020-07-21 08:07:34.411][300][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] Using deprecated option 'envoy.api.v2.Cluster.hosts' from file cds.proto. This configuration will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.
[2020-07-21 08:07:34.411][300][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] Using deprecated option 'envoy.api.v2.Cluster.hosts' from file cds.proto. This configuration will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.
[2020-07-21 08:07:34.601][300][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:86] gRPC config stream closed: 14, no healthy upstream
[2020-07-21 08:07:34.601][300][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:49] Unable to establish new stream
2020-07-21T08:07:36.000415Z     info    Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 1 successful, 0 rejected; lds updates: 0 successful, 0 rejected
2020-07-21T08:07:38.000380Z     info    Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 1 successful, 0 rejected; lds updates: 0 successful, 0 rejected
2020-07-21T08:07:39.631779Z     info    Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 1 successful, 0 rejected; lds updates: 0 successful, 0 rejected
2020-07-21T08:07:41.900399Z     info    Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 1 successful, 0 rejected; lds updates: 0 successful, 0 rejected
2020-07-21T08:07:43.631504Z     info    Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 1 successful, 0 rejected; lds updates: 0 successful, 0 rejected
2020-07-21T08:07:45.902027Z     info    Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 1 successful, 0 rejected; lds updates: 0 successful, 0 rejected
2020-07-21T08:07:47.801027Z     info    Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 1 successful, 0 rejected; lds updates: 0 successful, 0 rejected
2020-07-21T08:07:50.000344Z     info    Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 1 successful, 0 rejected; lds updates: 0 successful, 0 rejected
2020-07-21T08:07:51.631599Z     info    Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 1 successful, 0 rejected; lds updates: 0 successful, 0 rejected
2020-07-21T08:07:55.700337Z     info    Envoy proxy is NOT ready: failed retrieving Envoy stats: Get http://<IP_ADDRESS>:15000/stats?usedonly: net/http: request canceled (Client.Timeout exceeded while awaiting headers)
2020-07-21T08:07:57.700877Z     info    Envoy proxy is NOT ready: failed retrieving Envoy stats: Get http://<IP_ADDRESS>:15000/stats?usedonly: net/http: request canceled (Client.Timeout exceeded while awaiting headers)
2020-07-21T08:07:59.900302Z     info    Envoy proxy is NOT ready: failed retrieving Envoy stats: Get http://<IP_ADDRESS>:15000/stats?usedonly: net/http: request canceled (Client.Timeout exceeded while awaiting headers)
2020-07-21T08:08:01.700344Z     info    Envoy proxy is NOT ready: failed retrieving Envoy stats: Get http://<IP_ADDRESS>:15000/stats?usedonly: net/http: request canceled (Client.Timeout exceeded while awaiting headers)
2020-07-21T08:08:03.800317Z     info    Envoy proxy is NOT ready: failed retrieving Envoy stats: Get http://<IP_ADDRESS>:15000/stats?usedonly: net/http: request canceled (Client.Timeout exceeded while awaiting headers)
2020-07-21T08:08:05.800336Z     info    Envoy proxy is NOT ready: failed retrieving Envoy stats: Get http://<IP_ADDRESS>:15000/stats?usedonly: net/http: request canceled (Client.Timeout exceeded while awaiting headers)
2020-07-21T08:08:07.900297Z     info    Envoy proxy is NOT ready: failed retrieving Envoy stats: Get http://<IP_ADDRESS>:15000/stats?usedonly: net/http: request canceled (Client.Timeout exceeded while awaiting headers)
2020-07-21T08:08:09.700335Z     info    Envoy proxy is NOT ready: failed retrieving Envoy stats: Get http://<IP_ADDRESS>:15000/stats?usedonly: net/http: request canceled (Client.Timeout exceeded while awaiting headers)
2020-07-21T08:08:11.800381Z     info    Envoy proxy is NOT ready: failed retrieving Envoy stats: Get http://<IP_ADDRESS>:15000/stats?usedonly: net/http: request canceled (Client.Timeout exceeded while awaiting headers)
2020-07-21T08:08:13.800404Z     info    Envoy proxy is NOT ready: failed retrieving Envoy stats: Get http://<IP_ADDRESS>:15000/stats?usedonly: net/http: request canceled (Client.Timeout exceeded while awaiting headers)
2020-07-21T08:08:15.800309Z     info    Envoy proxy is NOT ready: failed retrieving Envoy stats: Get http://<IP_ADDRESS>:15000/stats?usedonly: net/http: request canceled (Client.Timeout exceeded while awaiting headers)
2020-07-21T08:08:17.700327Z     info    Envoy proxy is NOT ready: failed retrieving Envoy stats: Get http://<IP_ADDRESS>:15000/stats?usedonly: net/http: request canceled (Client.Timeout exceeded while awaiting headers)
2020-07-21T08:08:20.000261Z     info    Envoy proxy is NOT ready: failed retrieving Envoy stats: Get http://<IP_ADDRESS>:15000/stats?usedonly: net/http: request canceled (Client.Timeout exceeded while awaiting headers)
2020-07-21T08:08:22.100260Z     info    Envoy proxy is NOT ready: failed retrieving Envoy stats: Get http://<IP_ADDRESS>:15000/stats?usedonly: net/http: request canceled (Client.Timeout exceeded while awaiting headers)

istio-pilot (container: istio-proxy)
2020-07-21T08:07:15.491801Z     info    FLAG: --applicationPorts="[]"
2020-07-21T08:07:15.491898Z     info    FLAG: --binaryPath="/usr/local/bin/envoy"
2020-07-21T08:07:15.491904Z     info    FLAG: --concurrency="0"
2020-07-21T08:07:15.491909Z     info    FLAG: --configPath="/etc/istio/proxy"
2020-07-21T08:07:15.491914Z     info    FLAG: --connectTimeout="1s"
2020-07-21T08:07:15.491918Z     info    FLAG: --controlPlaneAuthPolicy="NONE"
2020-07-21T08:07:15.491923Z     info    FLAG: --controlPlaneBootstrap="true"
2020-07-21T08:07:15.491927Z     info    FLAG: --customConfigFile=""
2020-07-21T08:07:15.491931Z     info    FLAG: --datadogAgentAddress=""
2020-07-21T08:07:15.491935Z     info    FLAG: --disableInternalTelemetry="false"
2020-07-21T08:07:15.491940Z     info    FLAG: --discoveryAddress="istio-pilot:15010"
2020-07-21T08:07:15.491944Z     info    FLAG: --domain="istio-system.svc.cluster.local"
2020-07-21T08:07:15.491949Z     info    FLAG: --drainDuration="45s"
2020-07-21T08:07:15.491954Z     info    FLAG: --envoyMetricsServiceAddress=""
2020-07-21T08:07:15.491958Z     info    FLAG: --help="false"
2020-07-21T08:07:15.491962Z     info    FLAG: --id=""
2020-07-21T08:07:15.491966Z     info    FLAG: --ip=""
2020-07-21T08:07:15.491970Z     info    FLAG: --lightstepAccessToken=""
2020-07-21T08:07:15.491974Z     info    FLAG: --lightstepAddress=""
2020-07-21T08:07:15.491978Z     info    FLAG: --lightstepCacertPath=""
2020-07-21T08:07:15.491982Z     info    FLAG: --lightstepSecure="false"
2020-07-21T08:07:15.491987Z     info    FLAG: --log_as_json="false"
2020-07-21T08:07:15.491991Z     info    FLAG: --log_caller=""
2020-07-21T08:07:15.491995Z     info    FLAG: --log_output_level="default:info"
2020-07-21T08:07:15.491999Z     info    FLAG: --log_rotate=""
2020-07-21T08:07:15.492016Z     info    FLAG: --log_rotate_max_age="30"
2020-07-21T08:07:15.492020Z     info    FLAG: --log_rotate_max_backups="1000"
2020-07-21T08:07:15.492024Z     info    FLAG: --log_rotate_max_size="104857600"
2020-07-21T08:07:15.492029Z     info    FLAG: --log_stacktrace_level="default:none"
2020-07-21T08:07:15.492036Z     info    FLAG: --log_target="[stdout]"
2020-07-21T08:07:15.492040Z     info    FLAG: --parentShutdownDuration="1m0s"
2020-07-21T08:07:15.492046Z     info    FLAG: --proxyAdminPort="15000"
2020-07-21T08:07:15.492051Z     info    FLAG: --proxyLogLevel="warning"
2020-07-21T08:07:15.492055Z     info    FLAG: --serviceCluster="istio-pilot"
2020-07-21T08:07:15.492059Z     info    FLAG: --serviceregistry="Kubernetes"
2020-07-21T08:07:15.492063Z     info    FLAG: --statsdUdpAddress=""
2020-07-21T08:07:15.492068Z     info    FLAG: --statusPort="0"
2020-07-21T08:07:15.492077Z     info    FLAG: --templateFile="/etc/istio/proxy/envoy_pilot.yaml.tmpl"
2020-07-21T08:07:15.492081Z     info    FLAG: --trust-domain=""
2020-07-21T08:07:15.492085Z     info    FLAG: --zipkinAddress=""
2020-07-21T08:07:15.492096Z     info    Version<EMAIL_ADDRESS>2020-07-21T08:07:15.492210Z     info    Obtained private IP [<IP_ADDRESS>]
2020-07-21T08:07:15.492250Z     info    Proxy role: &model.Proxy{ClusterID:"", Type:"sidecar", IPAddresses:[]string{"<IP_ADDRESS>", "<IP_ADDRESS>"}, ID:"istio-pilot-67f9bd57b-dvvbm.istio-system", Locality:(*core.Locality)(nil), DNSDomain:"istio-system.svc.cluster.local", ConfigNamespace:"", TrustDomain:"cluster.local", Metadata:map[string]string{}, SidecarScope:(*model.SidecarScope)(nil), ServiceInstances:[]*model.ServiceInstance(nil), WorkloadLabels:model.LabelsCollection(nil)}
2020-07-21T08:07:15.492262Z     info    PilotSAN []string(nil)
2020-07-21T08:07:15.494626Z     info    Effective config: binaryPath: /usr/local/bin/envoy
configPath: /etc/istio/proxy
connectTimeout: 1s
discoveryAddress: istio-pilot:15010
drainDuration: 45s
parentShutdownDuration: 60s
proxyAdminPort: 15000
serviceCluster: istio-pilot
statNameLength: 189

2020-07-21T08:07:15.495095Z     info    Monitored certs: []string{"/etc/certs/key.pem", "/etc/certs/root-cert.pem", "/etc/certs/cert-chain.pem"}
2020-07-21T08:07:15.497859Z     info    Static config:
admin:
  access_log_path: /dev/null
  address:
    socket_address:
      address: <IP_ADDRESS>
      port_value: 15000
static_resources:
  clusters:
  - circuit_breakers:
      thresholds:
      - max_connections: 100000
        max_pending_requests: 100000
        max_requests: 100000
        max_retries: 3
    connect_timeout: 1.000s
    hosts:
    - socket_address:
        address: <IP_ADDRESS>
        port_value: 8080
    name: in.8080
  - circuit_breakers:
      thresholds:
      - max_connections: 100000
        max_pending_requests: 100000
        max_requests: 100000
        max_retries: 3
    connect_timeout: 1.000s
    hosts:
    - socket_address:
        address: <IP_ADDRESS>
        port_value: 15010
    http2_protocol_options: {}
    name: in.15010
  - circuit_breakers:
      thresholds:
      - max_connections: 100000
        max_pending_requests: 100000
        max_requests: 100000
        max_retries: 3
    connect_timeout: 1.000s
    hosts:
    - socket_address:
        address: istio-telemetry
        port_value: 15004
    http2_protocol_options: {}
    name: mixer_report_server
    type: STRICT_DNS
    dns_lookup_family: V4_ONLY
  listeners:
  - address:
      socket_address:
        address: <IP_ADDRESS>
        port_value: 15003
    filter_chains:
    - filters:
      - config:
          access_log:
          - config:
              path: /dev/stdout
            name: envoy.file_access_log
          http_filters:
          - config:
              default_destination_service: istio-pilot.istio-system.svc.cluster.local
              service_configs:
                istio-pilot.istio-system.svc.cluster.local:
                  disable_check_calls: true
                  mixer_attributes:
                    attributes:
                      destination.service.host:
                        string_value: istio-pilot.istio-system.svc.cluster.local
                      destination.uid:
                        string_value: kubernetes://istio-pilot-67f9bd57b-dvvbm.istio-system
                      destination.namespace:
                        string_value: istio-system
                      destination.ip:
                        bytes_value: AAAAAAAAAAAAAP//Culdmw==
                      destination.port:
                        int64_value: 15003
                      context.reporter.kind:
                        string_value: inbound
                      context.reporter.uid:
                        string_value: kubernetes://istio-pilot-67f9bd57b-dvvbm.istio-system
              transport:
                check_cluster: mixer_check_server
                report_cluster: mixer_report_server
                attributes_for_mixer_proxy:
                  attributes:
                    source.uid:
                      string_value: kubernetes://istio-pilot-67f9bd57b-dvvbm.istio-system
            name: mixer
          - name: envoy.router
          route_config:
            name: "15003"
            virtual_hosts:
            - domains:
              - '*'
              name: istio-pilot.istio-system.svc.cluster.local
              routes:
              - decorator:
                  operation: v1
                match:
                  prefix: /
                route:
                  cluster: in.8080
                  timeout: 0.000s
          stat_prefix: "15003"
        name: envoy.http_connection_manager
    name: "15003"
  - address:
      socket_address:
        address: <IP_ADDRESS>
        port_value: 15011
    filter_chains:
    - filters:
      - config:
          access_log:
          - config:
              path: /dev/stdout
            name: envoy.file_access_log
          codec_type: HTTP2
          http2_protocol_options:
            max_concurrent_streams:<PHONE_NUMBER>
          http_filters:
          - config:
              default_destination_service: istio-pilot.istio-system.svc.cluster.local
              service_configs:
                istio-pilot.istio-system.svc.cluster.local:
                  disable_check_calls: true
                  mixer_attributes:
                    attributes:
                      destination.service.host:
                        string_value: istio-pilot.istio-system.svc.cluster.local
                      destination.uid:
                        string_value: kubernetes://istio-pilot-67f9bd57b-dvvbm.istio-system
                      destination.namespace:
                        string_value: istio-system
                      destination.ip:
                        bytes_value: AAAAAAAAAAAAAP//Culdmw==
                      destination.port:
                        int64_value: 15011
                      context.reporter.kind:
                        string_value: inbound
                      context.reporter.uid:
                        string_value: kubernetes://istio-pilot-67f9bd57b-dvvbm.istio-system
              transport:
                check_cluster: mixer_check_server
                report_cluster: mixer_report_server
                attributes_for_mixer_proxy:
                  attributes:
                    source.uid:
                      string_value: kubernetes://istio-pilot-67f9bd57b-dvvbm.istio-system
            name: mixer
          - name: envoy.router
          route_config:
            name: "15011"
            virtual_hosts:
            - domains:
              - '*'
              name: istio-pilot.istio-system.svc.cluster.local
              routes:
              - decorator:
                  operation: xDS
                match:
                  prefix: /
                route:
                  cluster: in.15010
                  timeout: 0.000s
          stat_prefix: "15011"
        name: envoy.http_connection_manager
      tls_context:
        common_tls_context:
          alpn_protocols:
          - h2
          tls_certificates:
          - certificate_chain:
              filename: /etc/certs/cert-chain.pem
            private_key:
              filename: /etc/certs/key.pem
          validation_context:
            trusted_ca:
              filename: /etc/certs/root-cert.pem
        require_client_certificate: true
    name: "15011"
  - address:
      socket_address:
        address: <IP_ADDRESS>
        port_value: 15005
    filter_chains:
    - filters:
      - config:
          access_log:
          - config:
              path: /dev/stdout
            name: envoy.file_access_log
          http_filters:
          - config:
              default_destination_service: istio-pilot.istio-system.svc.cluster.local
              service_configs:
                istio-pilot.istio-system.svc.cluster.local:
                  disable_check_calls: true
                  mixer_attributes:
                    attributes:
                      destination.service.host:
                        string_value: istio-pilot.istio-system.svc.cluster.local
                      destination.uid:
                        string_value: kubernetes://istio-pilot-67f9bd57b-dvvbm.istio-system
                      destination.namespace:
                        string_value: istio-system
                      destination.ip:
                        bytes_value: AAAAAAAAAAAAAP//Culdmw==
                      destination.port:
                        int64_value: 15005
                      context.reporter.kind:
                        string_value: inbound
                      context.reporter.uid:
                        string_value: kubernetes://istio-pilot-67f9bd57b-dvvbm.istio-system
              transport:
                check_cluster: mixer_check_server
                report_cluster: mixer_report_server
                attributes_for_mixer_proxy:
                  attributes:
                    source.uid:
                      string_value: kubernetes://istio-pilot-67f9bd57b-dvvbm.istio-system
            name: mixer
          - name: envoy.router
          route_config:
            name: "15005"
            virtual_hosts:
            - domains:
              - '*'
              name: istio-pilot.istio-system.svc.cluster.local
              routes:
              - decorator:
                  operation: v1
                match:
                  prefix: /
                route:
                  cluster: in.8080
                  timeout: 0.000s
          stat_prefix: "15005"
        name: envoy.http_connection_manager
      tls_context:
        common_tls_context:
          alpn_protocols:
          - http/1.1
          tls_certificates:
          - certificate_chain:
              filename: /etc/certs/cert-chain.pem
            private_key:
              filename: /etc/certs/key.pem
          validation_context:
            trusted_ca:
              filename: /etc/certs/root-cert.pem
        require_client_certificate: true
    name: "15005"
  - address:
      socket_address:
        address: <IP_ADDRESS>
        port_value: 15007
    filter_chains:
    - filters:
      - config:
          access_log:
          - config:
              path: /dev/stdout
            name: envoy.file_access_log
          http_filters:
          - config:
              default_destination_service: istio-pilot.istio-system.svc.cluster.local
              service_configs:
                istio-pilot.istio-system.svc.cluster.local:
                  disable_check_calls: true
                  mixer_attributes:
                    attributes:
                      destination.service.host:
                        string_value: istio-pilot.istio-system.svc.cluster.local
                      destination.uid:
                        string_value: kubernetes://istio-pilot-67f9bd57b-dvvbm.istio-system
                      destination.namespace:
                        string_value: istio-system
                      destination.ip:
                        bytes_value: AAAAAAAAAAAAAP//Culdmw==
                      destination.port:
                        int64_value: 15007
                      context.reporter.kind:
                        string_value: inbound
                      context.reporter.uid:
                        string_value: kubernetes://istio-pilot-67f9bd57b-dvvbm.istio-system
              transport:
                check_cluster: mixer_check_server
                report_cluster: mixer_report_server
                attributes_for_mixer_proxy:
                  attributes:
                    source.uid:
                      string_value: kubernetes://istio-pilot-67f9bd57b-dvvbm.istio-system
            name: mixer
          - name: envoy.router
          route_config:
            name: "15007"
            virtual_hosts:
            - domains:
              - '*'
              name: istio-pilot.istio-system.svc.cluster.local
              routes:
              - decorator:
                  operation: v1
                match:
                  prefix: /
                route:
                  cluster: in.8080
                  timeout: 0.000s
          stat_prefix: "15007"
        name: envoy.http_connection_manager
    name: "15007"

2020-07-21T08:07:15.498104Z     info    PilotSAN []string(nil)
2020-07-21T08:07:15.498175Z     info    Starting proxy agent
2020-07-21T08:07:15.498415Z     info    Received new config, resetting budget
2020-07-21T08:07:15.498498Z     info    Reconciling retry (budget 10)
2020-07-21T08:07:15.498520Z     info    watching /etc/certs/key.pem for changes
2020-07-21T08:07:15.498541Z     info    Epoch 0 starting
2020-07-21T08:07:15.498583Z     info    watching /etc/certs/root-cert.pem for changes
2020-07-21T08:07:15.498603Z     info    watching /etc/certs/cert-chain.pem for changes
2020-07-21T08:07:15.498642Z     info    Envoy command: [-c /etc/istio/proxy/envoy.yaml --restart-epoch 0 --drain-time-s 45 --parent-shutdown-time-s 60 --service-cluster istio-pilot --service-node sidecar~<IP_ADDRESS>~istio-pilot-67f9bd57b-dvvbm.istio-system~istio-system.svc.cluster.local --max-obj-name-len 189 --allow-unknown-fields -l warning]
[2020-07-21 08:07:15.526][23][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] Using deprecated option 'envoy.api.v2.Cluster.hosts' from file cds.proto. This configuration will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.
[2020-07-21 08:07:15.526][23][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] Using deprecated option 'envoy.api.v2.Cluster.hosts' from file cds.proto. This configuration will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.
[2020-07-21 08:07:15.526][23][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] Using deprecated option 'envoy.api.v2.Cluster.hosts' from file cds.proto. This configuration will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.
2020-07-21T08:07:16.223118Z     warn    Epoch 0 terminated with an error: signal: killed
2020-07-21T08:07:16.223157Z     warn    Aborted all epochs
2020-07-21T08:07:16.223272Z     warn    Failed to delete config file /etc/istio/proxy/envoy-rev0.json for 0, remove /etc/istio/proxy/envoy-rev0.json: no such file or directory
2020-07-21T08:07:16.223295Z     info    Epoch 0: set retry delay to 200ms, budget to 9
2020-07-21T08:07:16.423493Z     info    Reconciling retry (budget 9)
2020-07-21T08:07:16.423589Z     info    Epoch 0 starting
2020-07-21T08:07:16.423694Z     info    Envoy command: [-c /etc/istio/proxy/envoy.yaml --restart-epoch 0 --drain-time-s 45 --parent-shutdown-time-s 60 --service-cluster istio-pilot --service-node sidecar~<IP_ADDRESS>~istio-pilot-67f9bd57b-dvvbm.istio-system~istio-system.svc.cluster.local --max-obj-name-len 189 --allow-unknown-fields -l warning]
[2020-07-21 08:07:16.449][144][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] Using deprecated option 'envoy.api.v2.Cluster.hosts' from file cds.proto. This configuration will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.
[2020-07-21 08:07:16.449][144][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] Using deprecated option 'envoy.api.v2.Cluster.hosts' from file cds.proto. This configuration will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.
[2020-07-21 08:07:16.449][144][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] Using deprecated option 'envoy.api.v2.Cluster.hosts' from file cds.proto. This configuration will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.
2020-07-21T08:07:17.416145Z     warn    Epoch 0 terminated with an error: signal: killed
2020-07-21T08:07:17.416180Z     warn    Aborted all epochs
2020-07-21T08:07:17.416303Z     warn    Failed to delete config file /etc/istio/proxy/envoy-rev0.json for 0, remove /etc/istio/proxy/envoy-rev0.json: no such file or directory
2020-07-21T08:07:17.416322Z     info    Epoch 0: set retry delay to 400ms, budget to 8
2020-07-21T08:07:17.816491Z     info    Reconciling retry (budget 8)
2020-07-21T08:07:17.816576Z     info    Epoch 0 starting
2020-07-21T08:07:17.816690Z     info    Envoy command: [-c /etc/istio/proxy/envoy.yaml --restart-epoch 0 --drain-time-s 45 --parent-shutdown-time-s 60 --service-cluster istio-pilot --service-node sidecar~<IP_ADDRESS>~istio-pilot-67f9bd57b-dvvbm.istio-system~istio-system.svc.cluster.local --max-obj-name-len 189 --allow-unknown-fields -l warning]
[2020-07-21 08:07:17.844][223][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] Using deprecated option 'envoy.api.v2.Cluster.hosts' from file cds.proto. This configuration will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.
[2020-07-21 08:07:17.844][223][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] Using deprecated option 'envoy.api.v2.Cluster.hosts' from file cds.proto. This configuration will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.
[2020-07-21 08:07:17.844][223][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] Using deprecated option 'envoy.api.v2.Cluster.hosts' from file cds.proto. This configuration will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.
2020-07-21T08:07:19.019258Z     warn    Epoch 0 terminated with an error: signal: killed
2020-07-21T08:07:19.019291Z     warn    Aborted all epochs
2020-07-21T08:07:19.019426Z     warn    Failed to delete config file /etc/istio/proxy/envoy-rev0.json for 0, remove /etc/istio/proxy/envoy-rev0.json: no such file or directory
2020-07-21T08:07:19.019445Z     info    Epoch 0: set retry delay to 800ms, budget to 7
2020-07-21T08:07:19.819731Z     info    Reconciling retry (budget 7)
2020-07-21T08:07:19.819889Z     info    Epoch 0 starting
2020-07-21T08:07:19.820044Z     info    Envoy command: [-c /etc/istio/proxy/envoy.yaml --restart-epoch 0 --drain-time-s 45 --parent-shutdown-time-s 60 --service-cluster istio-pilot --service-node sidecar~<IP_ADDRESS>~istio-pilot-67f9bd57b-dvvbm.istio-system~istio-system.svc.cluster.local --max-obj-name-len 189 --allow-unknown-fields -l warning]
[2020-07-21 08:07:19.846][337][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] Using deprecated option 'envoy.api.v2.Cluster.hosts' from file cds.proto. This configuration will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.
[2020-07-21 08:07:19.846][337][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] Using deprecated option 'envoy.api.v2.Cluster.hosts' from file cds.proto. This configuration will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.
[2020-07-21 08:07:19.846][337][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] Using deprecated option 'envoy.api.v2.Cluster.hosts' from file cds.proto. This configuration will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.
2020-07-21T08:07:20.710799Z     warn    Epoch 0 terminated with an error: signal: killed
2020-07-21T08:07:20.710832Z     warn    Aborted all epochs
2020-07-21T08:07:20.710964Z     warn    Failed to delete config file /etc/istio/proxy/envoy-rev0.json for 0, remove /etc/istio/proxy/envoy-rev0.json: no such file or directory
2020-07-21T08:07:20.710985Z     info    Epoch 0: set retry delay to 1.6s, budget to 6
2020-07-21T08:07:22.311177Z     info    Reconciling retry (budget 6)
2020-07-21T08:07:22.311260Z     info    Epoch 0 starting
2020-07-21T08:07:22.311317Z     info    Envoy command: [-c /etc/istio/proxy/envoy.yaml --restart-epoch 0 --drain-time-s 45 --parent-shutdown-time-s 60 --service-cluster istio-pilot --service-node sidecar~<IP_ADDRESS>~istio-pilot-67f9bd57b-dvvbm.istio-system~istio-system.svc.cluster.local --max-obj-name-len 189 --allow-unknown-fields -l warning]
[2020-07-21 08:07:22.335][452][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] Using deprecated option 'envoy.api.v2.Cluster.hosts' from file cds.proto. This configuration will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.
[2020-07-21 08:07:22.335][452][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] Using deprecated option 'envoy.api.v2.Cluster.hosts' from file cds.proto. This configuration will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.
[2020-07-21 08:07:22.335][452][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] Using deprecated option 'envoy.api.v2.Cluster.hosts' from file cds.proto. This configuration will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.
[2020-07-21 08:07:22.855][452][critical][assert] [external/envoy/source/common/common/posix/thread_impl.cc:42] assert failure: rc == 0.
2020-07-21T08:07:22.919504Z     warn    Epoch 0 terminated with an error: signal: killed
2020-07-21T08:07:22.919539Z     warn    Aborted all epochs
2020-07-21T08:07:22.919666Z     warn    Failed to delete config file /etc/istio/proxy/envoy-rev0.json for 0, remove /etc/istio/proxy/envoy-rev0.json: no such file or directory
2020-07-21T08:07:22.919684Z     info    Epoch 0: set retry delay to 3.2s, budget to 5
2020-07-21T08:07:26.119800Z     info    Reconciling retry (budget 5)
2020-07-21T08:07:26.119890Z     info    Epoch 0 starting
2020-07-21T08:07:26.119991Z     info    Envoy command: [-c /etc/istio/proxy/envoy.yaml --restart-epoch 0 --drain-time-s 45 --parent-shutdown-time-s 60 --service-cluster istio-pilot --service-node sidecar~<IP_ADDRESS>~istio-pilot-67f9bd57b-dvvbm.istio-system~istio-system.svc.cluster.local --max-obj-name-len 189 --allow-unknown-fields -l warning]
[2020-07-21 08:07:26.145][574][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] Using deprecated option 'envoy.api.v2.Cluster.hosts' from file cds.proto. This configuration will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.
[2020-07-21 08:07:26.145][574][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] Using deprecated option 'envoy.api.v2.Cluster.hosts' from file cds.proto. This configuration will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.
[2020-07-21 08:07:26.145][574][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] Using deprecated option 'envoy.api.v2.Cluster.hosts' from file cds.proto. This configuration will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.
[2020-07-21 08:07:26.810][574][critical][assert] [external/envoy/source/common/common/posix/thread_impl.cc:42] assert failure: rc == 0.
2020-07-21T08:07:26.835909Z     warn    Epoch 0 terminated with an error: signal: killed
2020-07-21T08:07:26.835945Z     warn    Aborted all epochs
2020-07-21T08:07:26.836107Z     warn    Failed to delete config file /etc/istio/proxy/envoy-rev0.json for 0, remove /etc/istio/proxy/envoy-rev0.json: no such file or directory
2020-07-21T08:07:26.836128Z     info    Epoch 0: set retry delay to 6.4s, budget to 4
2020-07-21T08:07:33.236332Z     info    Reconciling retry (budget 4)
2020-07-21T08:07:33.236415Z     info    Epoch 0 starting
2020-07-21T08:07:33.236474Z     info    Envoy command: [-c /etc/istio/proxy/envoy.yaml --restart-epoch 0 --drain-time-s 45 --parent-shutdown-time-s 60 --service-cluster istio-pilot --service-node sidecar~<IP_ADDRESS>~istio-pilot-67f9bd57b-dvvbm.istio-system~istio-system.svc.cluster.local --max-obj-name-len 189 --allow-unknown-fields -l warning]
[2020-07-21 08:07:33.263][677][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] Using deprecated option 'envoy.api.v2.Cluster.hosts' from file cds.proto. This configuration will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.
[2020-07-21 08:07:33.263][677][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] Using deprecated option 'envoy.api.v2.Cluster.hosts' from file cds.proto. This configuration will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.
[2020-07-21 08:07:33.263][677][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] Using deprecated option 'envoy.api.v2.Cluster.hosts' from file cds.proto. This configuration will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.
2020-07-21T08:07:34.024497Z     warn    Epoch 0 terminated with an error: signal: killed
2020-07-21T08:07:34.024530Z     warn    Aborted all epochs
2020-07-21T08:07:34.024635Z     warn    Failed to delete config file /etc/istio/proxy/envoy-rev0.json for 0, remove /etc/istio/proxy/envoy-rev0.json: no such file or directory
2020-07-21T08:07:34.024653Z     info    Epoch 0: set retry delay to 12.8s, budget to 3
2020-07-21T08:07:46.824801Z     info    Reconciling retry (budget 3)
2020-07-21T08:07:46.824886Z     info    Epoch 0 starting
2020-07-21T08:07:46.824960Z     info    Envoy command: [-c /etc/istio/proxy/envoy.yaml --restart-epoch 0 --drain-time-s 45 --parent-shutdown-time-s 60 --service-cluster istio-pilot --service-node sidecar~<IP_ADDRESS>~istio-pilot-67f9bd57b-dvvbm.istio-system~istio-system.svc.cluster.local --max-obj-name-len 189 --allow-unknown-fields -l warning]
[2020-07-21 08:07:46.858][787][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] Using deprecated option 'envoy.api.v2.Cluster.hosts' from file cds.proto. This configuration will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.
[2020-07-21 08:07:46.858][787][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] Using deprecated option 'envoy.api.v2.Cluster.hosts' from file cds.proto. This configuration will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.
[2020-07-21 08:07:46.858][787][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] Using deprecated option 'envoy.api.v2.Cluster.hosts' from file cds.proto. This configuration will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.
2020-07-21T08:07:47.830200Z     warn    Epoch 0 terminated with an error: signal: killed
2020-07-21T08:07:47.830242Z     warn    Aborted all epochs
2020-07-21T08:07:47.830379Z     warn    Failed to delete config file /etc/istio/proxy/envoy-rev0.json for 0, remove /etc/istio/proxy/envoy-rev0.json: no such file or directory
2020-07-21T08:07:47.830399Z     info    Epoch 0: set retry delay to 25.6s, budget to 2
2020-07-21T08:08:13.430640Z     info    Reconciling retry (budget 2)
2020-07-21T08:08:13.430714Z     info    Epoch 0 starting
2020-07-21T08:08:13.430773Z     info    Envoy command: [-c /etc/istio/proxy/envoy.yaml --restart-epoch 0 --drain-time-s 45 --parent-shutdown-time-s 60 --service-cluster istio-pilot --service-node sidecar~<IP_ADDRESS>~istio-pilot-67f9bd57b-dvvbm.istio-system~istio-system.svc.cluster.local --max-obj-name-len 189 --allow-unknown-fields -l warning]
[2020-07-21 08:08:13.458][896][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] Using deprecated option 'envoy.api.v2.Cluster.hosts' from file cds.proto. This configuration will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.
[2020-07-21 08:08:13.458][896][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] Using deprecated option 'envoy.api.v2.Cluster.hosts' from file cds.proto. This configuration will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.
[2020-07-21 08:08:13.458][896][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] Using deprecated option 'envoy.api.v2.Cluster.hosts' from file cds.proto. This configuration will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.
2020-07-21T08:08:14.120787Z     warn    Epoch 0 terminated with an error: signal: killed
2020-07-21T08:08:14.120820Z     warn    Aborted all epochs
2020-07-21T08:08:14.120946Z     warn    Failed to delete config file /etc/istio/proxy/envoy-rev0.json for 0, remove /etc/istio/proxy/envoy-rev0.json: no such file or directory
2020-07-21T08:08:14.120966Z     info    Epoch 0: set retry delay to 51.2s, budget to 1
2020-07-21T08:09:05.321098Z     info    Reconciling retry (budget 1)
2020-07-21T08:09:05.321149Z     info    Epoch 0 starting
2020-07-21T08:09:05.321185Z     info    Envoy command: [-c /etc/istio/proxy/envoy.yaml --restart-epoch 0 --drain-time-s 45 --parent-shutdown-time-s 60 --service-cluster istio-pilot --service-node sidecar~<IP_ADDRESS>~istio-pilot-67f9bd57b-dvvbm.istio-system~istio-system.svc.cluster.local --max-obj-name-len 189 --allow-unknown-fields -l warning]
[2020-07-21 08:09:05.346][1016][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] Using deprecated option 'envoy.api.v2.Cluster.hosts' from file cds.proto. This configuration will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.
[2020-07-21 08:09:05.346][1016][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] Using deprecated option 'envoy.api.v2.Cluster.hosts' from file cds.proto. This configuration will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.
[2020-07-21 08:09:05.346][1016][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] Using deprecated option 'envoy.api.v2.Cluster.hosts' from file cds.proto. This configuration will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.
[2020-07-21 08:09:06.324][1016][critical][assert] [external/envoy/source/common/common/posix/thread_impl.cc:42] assert failure: rc == 0.
2020-07-21T08:09:06.425215Z     warn    Epoch 0 terminated with an error: signal: killed
2020-07-21T08:09:06.425244Z     warn    Aborted all epochs
2020-07-21T08:09:06.425319Z     warn    Failed to delete config file /etc/istio/proxy/envoy-rev0.json for 0, remove /etc/istio/proxy/envoy-rev0.json: no such file or directory
2020-07-21T08:09:06.425329Z     info    Epoch 0: set retry delay to 1m42.4s, budget to 0

istio 1.1 was EOL a year ago: https://istio.io/blog/2019/announcing-1.1-eol/. Please upgrade, we cannot help support ancient versions. Its very likely this is fixed since then


Task21 codacy unused private

[790] - https://transfer.sh/gSPID/jdi-dark-tests.tar.gz

[790] - Allure report on Netlify: https://5e6a75a772473d01d65274af--jdi-dark.netlify.com

requested additional go through project to catch unused variables, unreachable code etc...


Remove, or fix, GoogleAnalyticsMetrics extension for MW 1.39

The GoogleAnalyticsMetrics extension seems like it can't work yet with MediaWiki 1.39, because it uses monolog 1.x, while MediaWiki 1.39 requires monolog 2.2. Here's the error message when you try to install it via Composer:
Your requirements could not be resolved to an installable set of packages.
  Problem 1
    - Root composer.json requires google/apiclient 2.2.1 -> satisfiable by google/apiclient[v2.2.1].
    - google/apiclient v2.2.1 requires monolog/monolog ^1.17 -> found monolog/monolog[1.17.0, ..., 1.27.1] but it conflicts with your root composer.json require (^2.2).

So, I assume this extension needs to be fixed, or removed from Canasta.
CC @tosfos

WikiTeq is in the process of updating all our maintained extensions for 1.39. I bumped priority on this one. We'll let you know once it's resolved.

Okay, cool. By the way, I just happened to see this - Google's "Universal Analytics" is going away next year:
https://support.google.com/analytics/answer/11583528?hl=en
I have no idea if this affects this extension, but I figured I should note it.

Right now it's scheduled for removal from Canasta 1.3.0 (which is waiting for MW 1.39 to release) but we can always add it in Canasta 1.3.1.

Excellent! Is the monolog version already updated, or is this patch preparing for that? (Basically, I want to know if I can close this issue.)

My guess is that Composer will already pull the correct monolog version. We still need to issue a PR to include the new extension version though. https://github.com/CanastaWiki/Canasta/blob/975a5b39f132c2a3658c67a181f2375563a5fb9d/Dockerfile#L284

@yaronkoren Simply making a PR for Canasta to use the Google Analytics Metrics commit hash that @tosfos linked to will be sufficient for this issue to be resolved.

Alright, that sounds good. Well, I think as far as the underlying code is concerned, this issue is now resolved.

By the way, I just discovered that Canasta already has a patch to get rid of its monolog version requirement, just so GoogleAnalyticsMetrics can work:
https://github.com/CanastaWiki/Canasta/blob/master/_sources/patches/core-fix-composer-for-GoogleAnalyticsMetrics.diff
So I guess this fix wasn't really necessary, since we could always have just kept/updated this patch. But this solution is definitely better.


🐛Bug : The color of the Khalti scope UI button does not alter as anticipated.

Describe the bug
The Khalti scope UI button color does not change as expected.
Expected behavior
The button color should be Colors.purple but it is not changing it is kind of weird ☹.
Screenshots

This is KPG-v1 and this version of SDK is no longer maintained and already in the deprecation schedule.
Please upgrade to KPG-v2 checkout version


Implement TryMap operator

What's in this PR:

when implementing helper subscription classes (Inner) for operators, there was a lot of code duplication. I attempted to extract the common pieces into base classes (@spadafiva you may want to take a look)
tweaked the Map implementation a little — the tests were failing in compatibility mode (cc @MortyMerr)
tweaked the DropWhile implementation to match Apple's Combine behavior when requesting elements using a Subscription instance
Implemented TryMap with tests. TryMap reuses most of the Map's logic, so not many tests were needed.

@spadafiva I've addressed your feedback, can you take a look?

@broadwaylamb Once you've got it merged in, ping me if you remember so that I can update my PRs based on the changes from this one.

@MortyMerr Can you take a look at this so the @broadwaylamb can merge?  I'm holding off on updating some of my PRs until this is resolved so that I don't have to refactor them again later.


Could not find a working container runtime strategy

Expected Behaviour
Postgres Container should start
Actual Behaviour
Postgres Container did not start
Testcontainer Logs
Error: Jest: Got error running globalSetup - C:\Users\carbo\Projects\twin-premium-api\Tests\Integration\setup.ts, reason: Could not find a working container runtime strategy
at getContainerRuntimeClient (C:\Users\carbo\Projects\twin-premium-api\node_modules\testcontainers\build\container-runtime\clients\client.js:64:11)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
at async PostgreSqlContainer.start (C:\Users\carbo\Projects\twin-premium-api\node_modules\testcontainers\build\generic-container\generic-container.js:54:24)
at async PostgreSqlContainer.start (C:\Users\carbo\Projects\twin-premium-api\node_modules@testcontainers\postgresql\build\postgresql-container.js:34:47)
at async initPostgres (C:\Users\carbo\Projects\twin-premium-api\Tests\Integration\setup.ts:12:22)
at async Promise.all (index 0)
at async init (C:\Users\carbo\Projects\twin-premium-api\Tests\Integration\setup.ts:7:5)
at async C:\Users\carbo\Projects\twin-premium-api\node_modules@jest\core\build\runGlobalHook.js:109:13
at async waitForPromiseWithCleanup (C:\Users\carbo\Projects\twin-premium-api\node_modules@jest\transform\build\ScriptTransformer.js:160:5)
at async ScriptTransformer.requireAndTranspileModule (C:\Users\carbo\Projects\twin-premium-api\node_modules@jest\transform\build\ScriptTransformer.js:808:16)
Steps to Reproduce

Windows but ran tests in WSL2
Docker version 24.0.7 and NodeJS version v20.12.1
npx jest --config ./src/Tests/Integration/it.jest.json src/Tests/Integration/Agency/agency.it.spec.ts
Error: Jest: Got error running globalSetup - C:\Users\carbo\Projects\twin-premium-api\Tests\Integration\setup.ts, reason: Could not find a working container runtime strategy

Environment Information

Operating System: Windows Subsystem For Linux
Docker Version: 24.0.7
Node version: v20.12.1
Testcontainers version: ^10.9.0

What is MSW?
Did you execute the tests as a WSL process? This path here C:\Users\carbo\Projects\twin-premium-api\Tests\Integration\setup.ts, reason: Could not find a working container runtime strategy looks like a Windows process, there will not be an OOTB integration between the Windows host and Docker within WSL if Docker Desktop is not used.

What is MSW?
Did you execute the tests as a WSL process? This path here C:\Users\carbo\Projects\twin-premium-api\Tests\Integration\setup.ts, reason: Could not find a working container runtime strategy looks like a Windows process, there will not be an OOTB integration between the Windows host and Docker within WSL if Docker Desktop is not used.

I run docker on WSL, and I executed all the commands on WSL and not Windows, but you're right, the path seems different, I'll verify it again though

Please reopen the issue if it persists

I'm having this problem in my GitLab pipelines with v10.9 and v10.10, and with debuguer I can't find the problem

Same here in Gitlab, using the following job configuration:
test:
  stage: test
  extends: .test_application
  services:
    - name: docker:dind
      alias: docker
      # explicitly disable tls to avoid docker startup interruption
      command: ['--tls=false']
  variables:
    DOCKER_HOST: 'tcp://docker:2375'
    DOCKER_TLS_CERTDIR: ''
    DEBUG: testcontainers*
  only:
    - merge_requests

I am getting Could not find a working container runtime strategy when I am trying to start the testcontainer in jest's globalSetup


usort: 1.0.7 -> 1.0.8

Diff: https://github.com/facebook/usort/compare/refs/tags/v1.0.7...v1.0.8
Changelog: https://github.com/facebook/usort/blob/1.0.8/CHANGELOG.md
Description of changes

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 316817 run on x86_64-linux 1

8 packages built:

ufmt (python311Packages.ufmt)
ufmt.dist (python311Packages.ufmt.dist)
usort (python311Packages.usort)
usort.dist (python311Packages.usort.dist)
python312Packages.ufmt
python312Packages.ufmt.dist
python312Packages.usort
python312Packages.usort.dist


feat: Adding the french translation to the app [WIP]

[Work in progress]
I've added translation into your app, there is still the menus part to do but its usable
Thanks,
@gpatarin

Good job

My mistakes were merged early : (
Sorry, please re-submit the PR after you finish. Thanks


derive CanJsonLog (TaggedTrans tag t m) instance

It used to be derived in time-warp-nt, but was removed along with the
dependency on ether.

Mac build failing (linker issues?), restarted, but I think it's good enough.


Check for full inventory missing

Hy,
I really like your plugin, but when an inventory is full, trading is possible. But after the trade, the traded items are gone, due to a full inventory. (dropping wont work for my, dont know why..)
Please add a check for this.
Reguards
Peda1996

Hey, thanks for your bug report via GitHub. I will add a option there, to cancel a trade then in the config.yml ;)

Can you please provide  a .jar download, as I can't compile it on my own.
But, i started to create a pom.xml, and afterwards i started to realize, that CodingAPI has no repo ^^
There is my pom.xml
`

4.0.0
de.codingair
TradeSystem
1.0.5
jar

<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>

TradeSystem
Bukkit/Spigot - Trade - Plugin

spigot-repo
https://hub.spigotmc.org/nexus/content/repositories/snapshots/

vault-repo
http://nexus.hc.to/content/repositories/pub_releases

ess-repo
http://repo.ess3.net/content/groups/essentials

    <!-- For Github Repos -->
    <repository>
        <id>jitpack.io</id>
        <url>https://jitpack.io</url>
    </repository>

<dependencies>
    <!--Spigot API-->
    <dependency>
        <groupId>org.spigotmc</groupId>
        <artifactId>spigot-api</artifactId>
        <version>1.12.2-R0.1-SNAPSHOT</version>
        <scope>provided</scope>
    </dependency>
    <!--Bukkit API-->
    <dependency>
        <groupId>org.bukkit</groupId>
        <artifactId>bukkit</artifactId>
        <version>1.12.2-R0.1-SNAPSHOT</version>
        <scope>provided</scope>
    </dependency>
    <!--Vault API-->
    <dependency>
        <groupId>net.milkbowl.vault</groupId>
        <artifactId>VaultAPI</artifactId>
        <version>1.7</version>
        <scope>provided</scope>
    </dependency>

    <!--essentials API-->
    <dependency>
        <groupId>net.ess3</groupId>
        <artifactId>Essentials</artifactId>
        <version>2.13-SNAPSHOT</version>
    </dependency>
</dependencies>

`

I never work with maven, so I need to take look into it.

Don't know if you can do something with that: https://github.com/CodingAir/CodingAPI

Oh, you should really have a look into dependency managenment things, they are very useful when working with other developers.

Hey, I'm nearly done with that issue. Would you like to preview it? Add me on discord: CodingAir#0281 ;)


Intercept and present mouse clicks and scrolls

As in #114 and pull request #162 , this one is up-to-date as of today's state of the master branch.
The changes were taken from #162 and are mostly the same. This build works for me.

Any updates?


Expose TimeIntervals Interfaces (trials, epochs)

NeuroConv supports conversion of CSV and Excel data to TimeIntervals neurodata types:
https://neuroconv.readthedocs.io/en/main/conversion_examples_gallery/text/csv.html
https://neuroconv.readthedocs.io/en/main/conversion_examples_gallery/text/excel.html
This includes trials, epochs, and custom TimeIntervals tables. These are very common in neurophysiology experiments. We should allow a user to select a CSV/Excel interface and then specify a path to the CSV/Excel file with the correct column headers. This assumes that timestamps are already aligned or will be aligned in a separate downstream step.
In a future iteration, we could also have a page where users can copy and paste a time intervals table into the app and edit it in the app.

Summarized and moved to https://github.com/NeurodataWithoutBorders/nwb-guide/issues/847
Re-open again whenever this starts active development


Fix for Issue 494 - ICOS retrieval with multiple dataset source error

This updates the ICOS retrieve_atmospheric function to differentiate between the multiple datasets returned by the ICOS Python library for different dataset sources such as EU ObsPack, ICOS, InGOS. A new dataset_source key has been added to the metadata to track the source. You can also now pass a dataset_source argument to the retrieve_atmospheric function and to search_surface.
Documentation has been updated and the ipython Sphinx directive used to run cells of the tutorial in place during documentation build, will see how this goes, it might need some tweaking.
I've also updated the workflow yaml to only run the docs build job when something is pushed to devel. This should reduce the amount of runtime on the actions and save a load of unecessary work.

This should close #494 and #548

This test tests/retrieve/icos/test_retrieve_icos.py::test_icos_retrieve_and_store fails for me locally. Looks like the same is happening the CI as well.
...
assert first_expected_metadata.items() <= first_obs_metadata.items()
E       AssertionError: assert dict_items([('species', 'co2'), ('instrument', 'ftir'), ('site', 'wao'),
...

Codecov Report

Merging #552 (a557a82) into devel (a70b15e) will increase coverage by 0.07%.
The diff coverage is 92.00%.

:exclamation: Current head a557a82 differs from pull request most recent head cc533b3. Consider uploading reports for the commit cc533b3 to get more accurate results

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@            Coverage Diff             @@
##            devel     #552      +/-   ##
==========================================
+ Coverage   78.24%   78.31%   +0.07%
==========================================
  Files         172      172
  Lines       12799    12813      +14
==========================================
+ Hits        10015    10035      +20
+ Misses       2784     2778       -6

Impacted Files
Coverage Δ

openghg/retrieve/_search.py
83.50% <ø> (ø)

openghg/retrieve/icos/_retrieve.py
90.05% <81.81%> (-1.46%)
:arrow_down:

openghg/standardise/meta/_attributes.py
95.67% <100.00%> (ø)

tests/retrieve/icos/test_retrieve_icos.py
100.00% <100.00%> (ø)

openghg/_version.py
39.54% <0.00%> (+2.54%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

This test tests/retrieve/icos/test_retrieve_icos.py::test_icos_retrieve_and_store fails for me locally. Looks like the same is happening in the CI as well.
...
assert first_expected_metadata.items() <= first_obs_metadata.items()
E       AssertionError: assert dict_items([('species', 'co2'), ('instrument', 'ftir'), ('site', 'wao'),
...

OK that's fixed, it was a wierd issue when comparing the metadata dictionaries.

Looks great - I just have a few clarifications I'd like around how this functions:
* Is this pulling all available data which matches and storing all of it?

* Is it possible to specify which of the dataset_sources you want to retrieve?

Yeah this will pull all available data and store it.
Yeah you can pass the dataset_source argument and it'll only pull the data you want.


Beam geometry

Restored the geometry accessor property to simplify Beam API
Geometry is now created on first call to beam.geometry rather than automatically. This allows creating a TimberAssembly in contexts where geometry is not available or not of interest (e.g. cadwork).

What type of change is this?

[ ] Bug fix in a backwards-compatible manner.
[ ] New feature in a backwards-compatible manner.
[x] Breaking change: bug fix or new feature that involve incompatible API changes.
[ ] Other (e.g. doc update, configuration, etc)

Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

[x] I added a line to the CHANGELOG.md file in the Unreleased section under the most fitting heading (e.g. Added, Changed, Removed).
[x] I ran all tests on my computer and it's all green (i.e. invoke test).
[x] I ran lint on my computer and there are no errors (i.e. invoke lint).
[ ] I added new functions/classes and made them available on a second-level import, e.g. compas_timber.datastructures.Beam.
[ ] I have added tests that prove my fix is effective or that my feature works.
[ ] I have added necessary documentation (if appropriate)

n a

Updated Beam's docstring. Couldn't find any references in the docs. However, get_geometry still shows as method of Beam (inherited from Part) I would have to sort that out in COMPAS core at some point.
BTW, since compas_timber continues to rely on unreleased changes to COMPAS, I added the exact commit I'm currently based on to requriements.txt and in order to test you'd need to install using pip install -r requirements-dev.txt. Maybe better in a new env so to not mess up any other working projects that use COMPAS LTS.

@funkchaser ping :)


custom build directory

Is it possible to specify custom build directory?
This would be super useful when binaryDir tag is set in CMakePresets (https://cmake.org/cmake/help/latest/manual/cmake-presets.7.html)

Currently it's not possible (SA will create 'build' directory "$GITHUB_WORKSPACE/build"). I agree that it could be useful, I will try to add it soon. Thanks!

After reading a bit about the presets, wouldn't setting the cmake_args action input with "--preset xxx" or -b xxx as another way of specifying output dir be sufficent?
Is that something that you had in mind?

I did not work to pass -B build --preset <preset_name> I got weird errors so I made a new preset with build as build directory which works fine

Closing the issue then


[docs] Updated the link to StackOverflow

Instead of "TestCafe" selected "questions with the TestCafe tag", because it is precisely what one will see when clicks the link.

@testcafe-build-bot \retest


Only lint .mjs files

It appears that scratch-js/index.css, added as part of the ask/answer implementation, is causing ESLint to fail--it is trying to lint it. This PR ensures that ESLint is only run on .mjs files.

Weird! I'm actually getting an error when running eslint both before and after this commit. :/
c:\Users\PullJosh\Code\scratch-js>npm run lint

><EMAIL_ADDRESS>lint c:\Users\PullJosh\Code\scratch-js
> eslint 'scratch-js/**.mjs'

Oops! Something went wrong! :(

ESLint: 6.8.0.

No files matching the pattern "'scratch-js/**.mjs'" were found.
Please check for typing mistakes in the pattern.

(Even before this commit I was getting the same error but with 'scratch-js/**'.)

@PullJosh Apparently you need to use double quotes for the path name on Windows. Try it now!


Add documentation

Documented high level functions.

Thanks @cschu :)

Thanks @cschu :)

I think I found my niche. I'm here to nitpick on typos XD

@lkuchenb can be merged?


Unreasonably slow nufft1 and nufft2 evaluations for large grid sizes

After updating to the newest version of (CPU-only) jax-finufft, large scale nufft evaluations are waaay too slow compared to what they were before. This is easily reproducible, at least on my end, by installing newest jax-finufft and, for example, jax-finufft 0.0.2 and running the code below:
import numpy as np
import jax
from jax_finufft import nufft1, nufft2
from datetime import datetime
jax.config.update('jax_platform_name', 'cpu')  # Default to CPU

M = 100000
#N = (384, 384, 384)  # Fast as it should be
N = (512, 512, 512)  # Waaaay too slow

x = 2 * np.pi * np.random.uniform(size=M)
y = 2 * np.pi * np.random.uniform(size=M)
z = 2 * np.pi * np.random.uniform(size=M)
c = np.random.standard_normal(size=M) + 1j * np.random.standard_normal(size=M)

print("{} Performing NUFFT1".format(datetime.now().strftime("%H:%M:%S")))
f = nufft1(N, c, x, y, z, eps=1e-6, iflag=1)
print("{} Done".format(datetime.now().strftime("%H:%M:%S")))

print("{} Performing NUFFT2".format(datetime.now().strftime("%H:%M:%S")))
ff = nufft2(f, x, y, z, eps=1e-6, iflag=1)
print("{} Done".format(datetime.now().strftime("%H:%M:%S")))

Here, for the newer jax-finufft version the 512^3 calculation is unreasonably slow while the 384^3 is behaving as expected taking around 5 minutes and 10 seconds, respectively, on my machine. For the older jax-finufft version both versions of the above code take around 10 seconds as expected.
I have no idea if the problem is on my end, or if this is something to do with jax (as obviously the jax versions are different for the new and old jax-finufft installations) or jax-finufft, but if someone could take a closer look at this it would be appreciated.

I can't reproduce this issue. Using the GitHub main version of jax-finufft and jax v0.4.19, here is the runtime that I get for your 5123 sample code on the machines that I have access to:

On my M1 MacBook: 9 seconds
On my Linux workstation at work: 2.5 seconds

In both cases, I get approximately the same runtime for both nufft1 and nufft2.
Unfortunately I don't have much to suggest besides trying to reinstall everything with a fresh environment or something like that!

Thanks for testing this. If nothing else, it is good to know that the problem is on my end.
I'll close this issue and continue troubleshooting.

Sounds good. Please do report back if you figure out what's going on or if you find any other clues!


Updated docs for Docker wiki article

I cleaned up some of the Docker instructions with things I thought may be helpful for others.
For How-to-run-with-Docker.md
Start by downloading for your platform: Mac, Windows, or Linux. Once you have Docker installed, simply create the various config.json files for your different accounts (e.g. configs/config-account1.json) and then create a Docker image for PokemonGo-Bot using the Dockerfile in this repo.
cd PokemonGo-Bot
docker build -t pokemongo-bot .

You can verify that the image was created with:
docker images

To run PokemonGo-Bot Docker image you've created, simple run:
docker run --name=pokemongobot-acct1 --rm -it -v $(pwd)/configs/config-account1.json:/usr/src/app/configs/config.json pokemongo-bot

To run PokemonGo-Bot Docker image in the background, replace --rm with -d in the line above.   Then check the logs with:
docker logs -f pokemongobot-acct1
If you want to run multiple accounts with the same Docker image, simply specify different config.json and names in the Docker run command.
Do not push your image to a registry with your config.json and account details in it!
If you would like to run the PokemonGo-Bot image and have it autoupdate the local OpenPoGoBotWeb directory, run:
docker run -it -v $(pwd)/web:/usr/src/app/web -v $(pwd)/configs/config.json:/usr/src/app/configs/config.json --rm --name=pokemongobot-acct1 pokemongo-bot

Again, to run PokemonGo-Bot Docker image in the background, replace --rm with -d in the line above.
TODO: Add configuration for running multiple Docker containers from the same image for every bot instance, and a single container for the web UI.

Thank you for this.
I have not used Docker a whole lot other than kicking some dev servers up, so forgive me.
This seems like a fairly small thing to use a Docker container for, could you explain the appeal please?
Unless you are a madman with 25+ bots... 😮

Who called madman? Here i am!

I prefer docker containers when I run code from other people. It sandboxes
things so you dont have to comb through all the code or worry about things
affecting your system. It's also good if you want to run a VPN inside of it
and prevent IP leakage out your main interface (good for torrents, etc).
Plus it's somewhat cross platform, so say Windows people don't need to
install Python, dependencies, etc and can instead just docker pull (app)
from the hub.
But yea, I'm sure you get the idea :)
On Wed, Aug 3, 2016, 5:51 PM Spencer Carstens<EMAIL_ADDRESS>wrote:

Thank you for this.
I have not used Docker a whole lot other than kicking some dev servers up,
so forgive me.
This seems like a fairly small thing to use a Docker container for, could
you explain the appeal please?
Unless you are a madman with 25+ bots... 😮
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/PokemonGoF/PokemonGo-Bot/issues/2549#issuecomment-237386011,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANAIScdKsfbCZrONx4JBHApFPmZQauKqks5qcQ1DgaJpZM4JcIDi
.

Also docker provides some useful features like --restart=always and etc

What exactly is $(pwd)? Is it relative path to folder or absolute?

@ksawerykarwacki
it's abs path to current folder.

@refast still doesn't work for me, getting error #2532

@ksawerykarwacki

@refast but which section because as I understand docker is linux on windows in my case so i should follow linux or windows installation or the one of docker?

@ksawerykarwacki
You should follow windows section.
The point is that you should clone repo and install python with all requirements in windows env to build docker image.
In a perfect world you would just pull image by name and run it.

@ksawerykarwacki: @refast @middleagedman, I believe the issue may be encountered by users running docker toolbox on windows instead of docker for windows. The two handle vitalization differently and as such the volume directory mounting is different. Perhaps the wiki should be updated to reflect this as well.
From https://docs.docker.com/engine/tutorials/dockervolumes/
In addition to creating a volume using the -v flag you can also mount a directory from your Docker engine’s host into a container.
$ docker run -d -P --name web -v /src/webapp:/opt/webapp training/webapp python app.py
If you are using Docker Machine on Mac or Windows, your Docker Engine daemon has only limited access to your OS X or Windows filesystem. Docker Machine tries to auto-share your /Users (OS X) or C:\Users (Windows) directory.
So, you can mount files or directories on OS X using:
docker run -v /Users/<path>:/<container path> ...
On Windows, mount directories using:
docker run -v /c/Users/<path>:/<container path> ...
NOTE: For Windows docker users the path must originate from the c/Users folder, otherwise file permissions in the directory being mounted will not pass through.
And personally I have had more success changing utilizing the following docker file and run command structure. It allows me to designate the config file through the command to the .py via -cf.
Dockerfile
FROM python:2.7-onbuild

ARG timezone=Etc/UTC
RUN echo $timezone > /etc/timezone \
    && ln -sfn /usr/share/zoneinfo/$timezone /etc/localtime \
    && dpkg-reconfigure -f noninteractive tzdata

RUN apt-get update \
    && apt-get install -y python-protobuf

VOLUME ["/usr/src/app/web","/usr/src/app/configs"]

ENTRYPOINT ["python", "pokecli.py"]

Docker Run
docker run --name=pgo-botname1 -v /c/Users/<username>/PokemonGo-Bot/web:/usr/src/app/web -v /c/Users/<username>PokemonGo-Bot/configs:/usr/src/app/configs -d -it pokemongo -cf configs/config-UsernameBasic.json
Mounting the /web volume allows all my dockers to deposit the user info being gathered into one central shared folder that can then be accessed by the web viewer.
I hope this is helpful

Could you also add the note from #2418 - where the data dir needs to be mounted in for the location cache to work.
Cheers

I also suggested changes in #2437 to clarify the examples, run the web interface with nginx and some rtfm for mounting volumes between hosts and containers. Any chance this could get merged as well?

If I get time this week I'll create a docker image in docker hub and people who have docker can just docker pull it.


Update README.md to include build / run steps

I made this a draft PR because we should test it out and make sure everything still works. @rmshkv and I made a few changes on the ADF side (and possibly in examples/adf-mom6, so there might be another PR coming?); there are still a couple of random scratch directories where the data hasn't been copied to campaign yet, but for now I think ADF will be happy reading the existing data and won't try to write anything anywhere it has read-only permissions.


Contents of resource_common/node_modules in created JARs

Hello!
When I build a theme, for example the starter theme, in the JAR file under /theme/keycloakify-starter/login/resources/resources_common/node_modules/ I see some Angular packages.
Are these angular files actually used by the themes? Would it be possible to configure the build script to ignore them while creating the JAR file?
These Angular files are triggering some security scans in our Keycloak Image, because it contains an old Angular 1.8 JS version.
Thanks in advance o7

Awesome, thank you for the answer. Ill finish updating my theme from v6 to v7 and give that option a go.

Feel free to reopen if you are still having problems


reorients to ALB1876

removes map link; removes timeline.js; re-writes page content

The diff is too big to navigate to the about.md, but it's the only thing I saw that looks like it still needs some work:

The project’s major accomplishment was a database compiled from the punch cards used by Professor Haynes McMullen in his decades-long research into American Libraries before 1876. The contents of this database are now being made available to researchers as a data set in X; a simple view of this data can be searched and browsed on this site.

We should probably just say "The contents of this database are now available to be searched and browsed on this site."

The Davies Project also compiled an extensive bibliography and a collection of transcriptions, as well as a collection documenting the history of the Princeton University Library.

I believe the libweb2 site has been crawled by Archive-It, but not yet cataloged in ASpace (I can't find it in Pulfalight). So maybe linking to the current site (http://libweb2.princeton.edu/rbsc2/libraryhistory/main.html) for now is the right thing to do? Ultimately, linking to the finding aid would be best.


Add tenant overrides config

Creates a secret that stores the override configs data.
Enables setting specific limits to different tenants.
Ref: https://cortexmetrics.io/docs/guides/overrides-exporter/

Thanks,
I might be of interest to some people that we also automatically mount the override config and provide the necessary arguments when enabling it via tenantOverridesConfig.enabled


multi Context problem

Hi all,
i'm new on Behat.
I already search in doc..
I would like to have a  single context per each scenario.

this is my behat.yml

If i do behat --append-snippets. He create unsion.tmp files with the function in my bootstrap folder, instead of creating them in the right files.
If I try to write the functions in the right files myself, when I go to run the Behat command, it gives me the
"undefined"

Unison seems to be some sort of file synchronisation thing? It's not something Behat is doing natively...

Unison seems to be some sort of file synchronisation thing? It's not something Behat is doing natively...

First of all thanks for your reply..
Yeah i use unison strategy in docker-sync
I use symfony docker behat 3.1


added missing required EventTarget param in useEventListener example

Problem:
useEventListener example was missing the required EventTarget Param

Nice catch, thank you! 🙌

@all-contributors please add @prsnnami for doc


update deps

ran npm update

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


add unit test coverage report

we should look to add unit test coverage reporting to the CI for the project. This should help encourage contributors to pay attention to the unit test framework and at least write some tests for newly contributed code.

I did some review and testing of several unit test frameworks that support rust including kcov, grcov and tarpaulin with the following findings:

tarpaulin seems to be one of the most popular frameworks for rust. It only supports testing on Linux platforms which is kind of limiting where some of the contributors to this project are running MacOS and Windows. Also, I found it buggy when running tests against projects that use sub-process modules like assert_cmd.
kcov supported both Linux and MacOS but not Windows. Installing the binaries was a bit cumbersome and required a fair bit of time to set up (looks like all the tools required recompile from source or something). Once I got it working it did produce decent looking reports but still seemed somewhat buggy when reporting coverage for sub-process modules like assert_cmd
grcov by comparison was relatively easy to install (2 or 3 dependent packages needed, but where quick to install). The test environment was a bit cumbersome to set up, requiring the install of rust nightly and defining a global env variable to be created prior to running the tests, and requiring multiple command / operations to generate user readable reports (ie: cargo clean, cargo test, grcov -t html, etc.). However, it produced visually appealing reports that were pretty accurate based on my initial assessment. Finally, the docs proclaim that it supports Linux, MacOS and Windows. I've only tested MacOS so far though. Also, I saw no noticeable performance impact to running the instrumented tests vs the non-instrumented tests.

Based on these findings I propose we use grcov as the tool of choice for this change.


[WFLY-2667] Allow batch job repositories to be overridden in the jboss-all.xml

I've currently only tested this manually as I'm trying to figure out a good way to test from a test case. Good as in reliable and not fragile :)

Windows Build 1465 is now running using a merge of 1aa7789ee27ec1fe5ef69d546b9d681a45db6a09

Linux with security manager Build 1313 is now running using a merge of 1aa7789ee27ec1fe5ef69d546b9d681a45db6a09

Linux Build 6386 is now running using a merge of 1aa7789ee27ec1fe5ef69d546b9d681a45db6a09

Linux with security manager Build 1313 outcome was FAILURE using a merge of 1aa7789ee27ec1fe5ef69d546b9d681a45db6a09
Summary: Tests passed: 655, ignored: 308; exit code 1 (new) Build time: 0:03:04
Build problems:
Process exited with code 1

Linux Build 6386 outcome was FAILURE using a merge of 1aa7789ee27ec1fe5ef69d546b9d681a45db6a09
Summary: Tests passed: 655, ignored: 308; exit code 1 (new) Build time: 0:03:31
Build problems:
Process exited with code 1

Windows Build 1465 outcome was FAILURE using a merge of 1aa7789ee27ec1fe5ef69d546b9d681a45db6a09
Summary: Tests passed: 655, ignored: 308; exit code 1 (new) Build time: 0:04:52
Build problems:
Process exited with code 1

Linux with security manager Build 1314 is now running using a merge of bd8c8186b615cf43b7f7123f4f3d6093458d2940

Linux Build 6387 is now running using a merge of bd8c8186b615cf43b7f7123f4f3d6093458d2940

Windows Build 1466 is now running using a merge of bd8c8186b615cf43b7f7123f4f3d6093458d2940

Linux with security manager Build 1314 outcome was SUCCESS using a merge of bd8c8186b615cf43b7f7123f4f3d6093458d2940
Summary: Tests passed: 825, ignored: 317 Build time: 0:05:03

Windows Build 1466 outcome was SUCCESS using a merge of bd8c8186b615cf43b7f7123f4f3d6093458d2940
Summary: Tests passed: 2857, ignored: 373 Build time: 0:47:33

Linux Build 6387 outcome was SUCCESS using a merge of bd8c8186b615cf43b7f7123f4f3d6093458d2940
Summary: Tests passed: 2856, ignored: 373, muted: 1 Build time: 0:47:37

I added the "hold" label pending discussion of when this should go in.

It could into either I'd think. I've only tested it locally though. If we're more comfortable in 10.x I'm fine with that. I'll see if I can get a test together soon too that will be a reliable test.

I marked this for 10.x for now. I mentioned on the JIRA doing another feature in 9 would require quite a sales job, and your last comment would not get you Salesperson of the Year honors. ;)


the sleep(UINT32_MAX) has exited on OpenWRT instantly

The sleep(UINT32_MAX) has exited instantly on OpenWrt. This fix will work forever :-)

I forgot to mention, that sleep(INT32_MAX) is working correctly, only the greater values are problematic. It's definetly not a busy loop. The for loop around the sleep is just some extra pedantry:

serial2mqtt could run longer than than 68 years :-)
theoretically signal handlers could interrupt sleep (currently we don't use signal handlers, but this solution is future proof)

If you have any concerns, please let me know.

Or we can use a more idiomatic way:
for (;;)
{
    pause();
}


Add API generator as JSON meta files

Related plugins

[X] plugin-vue

[ ] plugin-vue-jsx

Description
As a developer using Vite and Vue, I would love to see a plugin that would be able to extract the API of my components and expose them in a standard way using some kind of JSON/YAML files.
Basically I would love to see a standard emerge that capture similar information as you can see with vuetify or quasar but ideally such API description should become a standard rather than a custom format for each library.
Also ideally once such format became a standard, we could envision website generators using that as input for API documentation.
Suggested solution

vuetify example format
quasar example format

Alternative
No response
Additional context
No response
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

Sorry for the cross posting but I initially suggested here in the vite project. But it better match the vue plugin...

Thanks for your idea. We actually already have vue-component-meta in Volar.
I think it would be better to have this feature in the community project than in the official plugin for now.

Thanks for the pointer. I'm still not sure how to use it on existing vue.js bundles but definitely a step toward the end goal.
Ideally, I would love to see it become a standard practice, hence having it provided at the core would help the adoption unless similar capabilities could be derived from a generated umd.
To be fully transparent, I'm looking to streamline the integration process of any vue.js library out there into a trame component by generating the corresponding Python code via some automation tool. So anything that could extract props/events/docs/directive information into a usable form would go a long way...
Thanks again for getting back to me about that suggestion.


[Cider2] Remove Cider 1

Part of #1913
More details to come. Non-exhaustive todolist
TODO:

[x] Finish replacing all the debugger functionality

[x] Separate convergence logic
[x] So much printing logic
[ ] ~Add watchpoint disabling/enabling since that's a thing now~ (Not necessary for this PR)

[ ] ~Add debugger tests~ (Not necessary for this PR)
[x] Fud stuff

[x] Replace fud2 debugger path
[x] Remove fud2 old interpreter path
[x] Update fud2 cider 2 path to fit the new calls
[x] Fix the cider2 test suite
[x] Remove og fud interpreter/debugger path and maybe add a note/warning

[x] CI tests (??? this is gonna be a trashfire)
[ ] Documentation

[x] Readme (just linkts to docs, pretty bare bones)
[x] Setup info (fud2)
[x] Usage examples in the Calyx docs

The core functionality of the debugger now works! There are a number of things that still need polish or are partially implemented (printing ref cells for instance). But I think this is enough to constitute a reasonable MVP since I want to unblock people who are stuck on this.
The main things to figure out are:

What to do with the original fud path which now will no longer work?
What to do with the CI tests given that not all programs work with Cider 2 yet (mostly fixed-point ones and the tests that write undef vals to registers)?

Marking this as ready for review finally since I think this constitutes a reasonable MVP for now! I elected to just skip over the polybench tests rather than wait for the fud2 fix.

Gonna press the big button now!


Rename Robocorp to Sema4.ai

Still few Robocorp references left.

LGTM

Thanks for fixing the typo :)


do nothing when trying to reset with the same content which is already present

I've encountered a case of https://github.com/adobe/brackets/issues/11826 and this fixes it (don't necessarily fix all possible cases but it is at least something)
cc @nethip @petetnt

@zaggino it would be awesome if you can add a test case.

Most likely fixes things like zaggino/brackets-git#1274 to some extent. Looks good to me.

@ficristo test added, i've tested that it fails before and passes after the fix too

Nice fix @zaggino . LGTM.
Note: I am going ahead with the merge. Travis is failing because of the API limit issues.

Thanks @zaggino

test added

@zaggino great job, thank you.


New naming

This enables the ability for anyone at any time to simply suggest a name with no vote rather than being forced to vote.

Coverage increased (+0.0004%) to 91.988% when pulling e71bf1b0ac2ac3318344805fabae01a7fb586436 on new-naming into a86889ed27e7ae89ce24c0890c53d27cf20cc72d on master.

Code looks good.
(I haven't actually tried it in dev mode because of the difficulty of switching between branches based on bootstrap4 and master.)

Tried it out in dev mode. Looks fine. (I had to switch branches for other reasons. But I'm finding it painful to move from bootstrap4 to master. I end up having to rebuild the VM.)


[release-1.10] e2e flakiness: vault addon incorrectly using StdoutPipe

Same as https://github.com/cert-manager/cert-manager/pull/5795, but for the branch release-1.10.
/kind flake
NONE

Thank you for fixing this
/approve
/lgtm

/retest


C6011 warning from WIL header file

See #124 for core repro steps. To repro this case, do:
#include <wil/result.h>

In result.h, there are two lines that trigger warnings such as this one:
C6011: Dereferencing NULL pointer 'Temp_value_#7840'. ...

The analyzer didn't like this:
https://github.com/microsoft/wil/blob/adae42be8f45bdbf0fa50aca000fd8bf2063fff5/include/wil/result.h#L409-L412
The null check is right there, so this looks like a false positive. This makes the analzyer happy:
if (auto pNewRaw = details::ProcessHeapAlloc(0, sizeof(Node)))
{
    auto pNew = new (pNewRaw) Node{ threadId };


Update financetime.js

This change ensures that midnight time represented as 00:00:00 is handled correctly.

Cheers. I will update an example to reproduce the issue then will merge it in.
Thanks for the contribution!

@andredumas you can use snippet #58.


test: Updates to YAML file for TS cypress tests inclusions

Description
This PR makes updates to yaml files to include test files with ts or js extention
Type of change

New feature (non-breaking change which adds functionality)

Checklist:

[X] My code follows the style guidelines of this project
[X] I have performed a self-review of my own code
[X] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[X] My changes generate no new warnings
[X] I have added tests that prove my fix is effective or that my feature works
[X] New and existing unit tests pass locally with my changes

/ok-to-test sha=6afccf3

/ok-to-test sha=6afccf325244d50c15d7e663a19c3545201fd97c

/ok-to-test sha=6afccf3


fix(kdf_operations): reduce wasm log verbosity in release mode

Only log pre-cast responses on wasm in debug mode.
CI integration test log zip size:

before integration: 28.5 KB
after integration: 134 KB

@CharlVS Could we at some point refactor komodo_defi_framework to use dart logging instead of the callback function? Using dart logging allows for log levels, so we can leave verbose and debug logs in the code without it flooding the log files in release mode.
The print statement that I changed looks like something useful in debugging, but it is probably not necessary in release mode. We could leave statements like that in using log.fine, along with additional log statements in that vein, without having to worry about affecting the size of the logs (assuming that the default threshold is LogLevel::INFO).
I used dart logging in komodo_wallet_build_transformer, so there are examples of changing the log output location and using the log levels to change the verbosity level of the logs.

Changing the output log stream to stdout
Using FINE for verbose/debugging logs and severe for exceptions


Unparser's approach to emitting comments is fragile

When unparsing an AST, Unparser can take an optional array of Parser::Source::Comment objects. It is assumed that the comments all come from the same Ruby source file, and that they are sorted in order of occurrence.
When emitting code, Unparser tracks the source range (Parser::Source::Range) for the node last emitted. When the end of a line is reached, it looks at the comments, compares their source ranges to that of the node just emitted, and sees if there is a comment not yet emitted, which belongs at the end of the node.
This approach is really only good for one thing: round-tripping ASTs which were parsed from a single Ruby source file.
It breaks down if you take nodes which were parsed from different source files (or from code strings), combine them in a new AST, and unparse them.
It breaks down if you take an AST parsed from a file, modify some nodes, and then unparse it, since the newly synthesized nodes don't have source maps. (And neither should they -- there is nothing in the source buffer which corresponds to them in a meaningful way.)
It breaks down if you synthesize an AST completely from scratch, but want comments to appear in the source code which is produced from that AST.
It would be better if there was metadata attached to nodes indicating whether a comment appears directly after that node. That would be robust. When replacing nodes in an AST, you could copy the comment metadata over to the new nodes, and the comments would come out in the right place.
You could combine nodes which were parsed from different source files (or strings), and all the comments would come out in the right places.
You could synthesize ASTs from scratch, attach comment metadata wherever you liked, then unparse, and the comments would come out in the right places.
Unfortunately, parser doesn't attach that metadata to nodes. It does, however, have Parser::Source::Comment::Associator, which takes an AST and a comment array, and produces a hash relating AST nodes to adjacent comments.
A hash like that is much better than a comment array. If you combine nodes parsed from different sources into a new AST, you can simply merge the comment hashes. Easy. Flexible. Robust.
If you synthesize nodes, you can add entries to the comment hash as desired. Again: easy, flexible, and robust.
Or, if you are replacing nodes in an existing AST, you can remove the entry in the comment hash for the old node, and add an equivalent entry for the new node.
The problem is that this would be a backwards-incompatible change! Unless we added a new entry point... or just detected whether the comments parameter is an array or a hash?

I'm fine with backwards incompatible changes. Unparser is pre 1.x so semver is shifted. Bumping from 0.2.x to 0.3.x is totally fine for me to account for the different API.

How do you feel about passing in comments as a { node => [comments] } hash rather than an array?
Perhaps as a convenience, if someone passes in a comment array returned by Parser::CurrentRuby.parse_with_comments, we can automatically run Parser::Source::Comment::Associator on it to get the hash?

I do not like convenience at all. When there is a better API, lets use it, bump vesion and kill the old immediately.
For better comment reproduction, do you need anything else than node -> [comments] API? Maybe we should than pass an object that does exactly that #call(node) -> [comments] avoiding primitive infection in the API.
By default we can pass an object that always unconditionally returns [] fixing branches in the implementation.
Nobody can forsee the best API, so it might be a good idea to start with passing the hash directly, and once the improvement works look into constrainin the provided API via wrapping the hash. Or leave the hash intact if the wrapper has more than a #call.

One complication: Parser::AST::Nodes are immutable and hash by value, not identity... but metadata like source maps are not included in the hash code. This was a deliberate decision on the part of the designer, and it was a good decision, but it means that using a simple { node => [comments] } hash doesn't work. You could have 2 different (send nil :puts (lvar :a)) nodes, which come from completely different locations in the source, and have different comment metadata, but they will hash to the same key/val entry.
I think your idea of #call(node) is good: someone could pass something as straightforward as proc { |node| comment_hash[node.object_id] }, or they could use some custom class if desired.

I have made a lot of progress on this issue. It turns out that just #call is not enough -- we need to know if a comment appeared before or after a node, etc. I have introduced a new Unparser::Comments class which tracks the correspondence between AST nodes and comments. I think you will like it.
However, it turns out that my other PR related to parenthesizing arithmetic expressions needs to finish before this one -- because visit_on_side will be used by this one also. (It turns out that when emitting comments, you need to do things slightly different on the left side of a binary operator.)

However, it turns out that my other PR related to parenthesizing arithmetic expressions needs to finish before this one -- because visit_on_side will be used by this one also. (It turns out that when emitting comments, you need to do things slightly different on the left side of a binary operator.)

You could rebase this PR on top of the other one, I'll remember to merge them in order.

@alexdowad As this is not an actionable issue, and no input pattern is currently reported that breaks commend reproduction I'll close this issue.
If you want to work on improving the flexibiltiy of the comment reproduction, be my guest. But I assume you stopped thinking about using unparser in rubocop so its likely also in your intention to close this issue.