Dev PR for sprint ending 2021-09-24

Lots of big changes, including:

#1180 in preparation for the entity resolution / harvesting overhaul (See #639)
#1176 removing the Frictionless Data Packages outputs.
#848 meaning that we now have 2001-2019 for both EIA-860 and EIA-923.
Removed some modules that were no longer being maintained.

Before merging into main:

[ ] Fix the broken Read The Docs builds. They are running out of memory setting up the software environment.
[ ] Fix the broken GitHub Actions CI tests. For some reason, it's hanging also while setting up the testing environment, and eventually timing out after 6 hours, which is the max allowed time.

The fact that Read the Docs and GitHub Actions both seem to be having trouble getting the test environment installed at the same time seems suspicious.
However, the fact that it cropped up almost simultaneously on different branches in our repo seems to suggest that it's not because of our code. Like we didn't change something that broke it.
Maybe something about how our dependencies relate to each other has changed, and is making it much harder for pip to figure out what versions to install?

Attempting to pin setuptools<58 in pyproject.toml seems to have had no impact on the GitHub Actions CI or the RTD builds. 😢

🎉 After removing several dependencies that we've just obviated, including goodtables-pandas-py which had the problem with 2to3 still being used in its dependency simpleeval, the tests are running for real again and the RTD builds are working!
Sadly, they are also failing with a CHECK constraint violation in the plants_eia860 table, which is weird because I can definitely run both the fast and full tests locally and I get no such problem.

Of course it turns out that Simon has run into this already, and has some notes on his TIL blog about how to build whatever version of SQLite you want from source for testing purposes. However, this seems more involved than I'd hoped, and so I think I will give the setup-miniconda GitHub Action a shot first. This would also mean that our testing environment would more closely resemble the way we tell users to set things up (with conda), and the way we set things up in our Docker container for distribution, and the way we typically work with the software locally. Which would probably help keep everything more coherent and predictable in the long run. But I'll definitely make a note of the fact that SQLite 3.32.0 or later appears to be a requirement for PUDL to work with the current type checking constraints enabled.


Inferring SB_IO with D_IN_0 from $TBUF cells

I've been playing with inference of SB_IO from $_TBUF_ cells and encountered a few problems. Afaics it boils down to the following test case:
module test(input din, en, output dout, inout io);
  assign io = en ? din : 1'bz, dout = io;
endmodule

yosys -p 'synth_ice40 -blif tristate.blif' tristate.v
arachne-pnr -o tristate.asc tristate.blif

Which should of course be equivalent to:
module test(input din, en, output dout, inout io);
  SB_IO #(
    .PIN_TYPE(6'b 1010_01),
    .PULLUP(1'b 0)
  ) iobuf (
    .PACKAGE_PIN(io),
    .OUTPUT_ENABLE(en),
    .D_OUT_0(din),
    .D_IN_0(dout)
  );
endmodule

But arachne-pnr produces the following error for BLIF generated from the first Verilog code:
tristate.blif:14: fatal error: toplevel inout port 'io' not connected to SB_IO PACKAGE_PIN

The BLIF generated by Yosys looks reasonable imo:
.model test
.inputs din en io
.outputs dout io
.names $false
.names $true
1
.names $undef
.gate $_TBUF_ A=din E=en Y=io
.attr src "tristate.v:2"
.names io dout
1 1
.end

I thought I might try to add an example.
ali@ali-debian:~/Code/Verilog/ice40/test$ arachne-pnr -d 1k -P qn84 -p cap.pcf cap.blif -o cap.asc
seed: 1
device: 1k
read_chipdb +/share/arachne-pnr/chipdb-1k.bin...
supported packages: cb121, cb132, cb81, cm121, cm36, cm49, cm81, qn84, swg16tr, tq144, vq100
read_blif cap.blif...
cap.blif:18: fatal error: toplevel inout port 'BTN[0]' not connected to SB_IO PACKAGE_PIN
module cap (CLK_3P3_MHZ, LED, BTN);
input CLK_3P3_MHZ;
inout reg [3:0] BTN;
output reg [3:0] LED;
always@(posedge CLK_3P3_MHZ) begin
LED = BTN;
end
endmodule // cap
ali@ali-debian:~/Code/Verilog/ice40/test$ cat cap.blif
Generated by Yosys 0.6+1 (git sha1 c89f61c, clang 3.5.0-10 -fPIC -Os)
.model cap
.inputs CLK_3P3_MHZ BTN[0] BTN[1] BTN[2] BTN[3]
.outputs LED[0] LED[1] LED[2] LED[3] BTN[0] BTN[1] BTN[2] BTN[3]
.names $false
.names $true
1
.names $undef
.gate SB_DFF C=CLK_3P3_MHZ D=BTN[0] Q=LED[0]
.attr src "cap.v:6|/usr/local/bin/../share/yosys/ice40/cells_map.v:2"
.gate SB_DFF C=CLK_3P3_MHZ D=BTN[1] Q=LED[1]
.attr src "cap.v:6|/usr/local/bin/../share/yosys/ice40/cells_map.v:2"
.gate SB_DFF C=CLK_3P3_MHZ D=BTN[2] Q=LED[2]
.attr src "cap.v:6|/usr/local/bin/../share/yosys/ice40/cells_map.v:2"
.gate SB_DFF C=CLK_3P3_MHZ D=BTN[3] Q=LED[3]
.attr src "cap.v:6|/usr/local/bin/../share/yosys/ice40/cells_map.v:2"
.end

Hi,
I am having the same issue with arachne-pnr and tristate buffers. Below is an example.v code:
module top (
        input  clk,
        inout LED1, LED2, LED3, LED4, LED5
);
        localparam LOG2DELAY = 22;
        reg [LOG2DELAY-1:0] counter = 0;
        reg [1:0] outcnt = 0;

        always@(posedge clk) begin
                if (counter == 0) begin
                        case (outcnt)
                          2'b00: outcnt <= 2'b01;
                          2'b01: outcnt <= 2'b10;
                          default: outcnt <= 2'b00;
                        endcase
                end
                counter <= counter + 1;
        end

        assign LED5 = outcnt[0] ? 1'bz : outcnt[1];
endmodule

I tried to compile this code with the icestick.pcf and Makefile files from the examples/icestick folder included in the source of icestorm. Yosys performs good and generates successfully example.blif but arachne-pnr shows the error:
arachne-pnr -d 1k -o example.asc -p icestick.pcf example.blif
seed: 1
device: 1k
read_chipdb +/share/arachne-pnr/chipdb-1k.bin...
  supported packages: cb121, cb132, cb81, cm121, cm36, cm49, cm81, qn84, swg16tr, tq144, vq100
read_blif example.blif...
example.blif:196: fatal error: toplevel inout port 'LED1' not connected to SB_IO PACKAGE_PIN
Makefile:11: recipe for target 'example.asc' failed
make: *** [example.asc] Error 1

arachne-pnr is a bit picky regarding the top level port declarations. You should only declare a port as inout if your are actually using it as inout. In this case you are not using LED1..LED4 at all. So you can declare them as either input or output and everything will be fine. You are using LED5 as a tristate output, but do not use its value when you tristate it. So it is sufficient to declare it as output:
module top (
        input  clk,
        output LED1, LED2, LED3, LED4, LED5
);
        localparam LOG2DELAY = 22;
        reg [LOG2DELAY-1:0] counter = 0;
        reg [1:0] outcnt = 0;

        always@(posedge clk) begin
                if (counter == 0) begin
                        case (outcnt)
                          2'b00: outcnt <= 2'b01;
                          2'b01: outcnt <= 2'b10;
                          default: outcnt <= 2'b00;
                        endcase
                end
                counter <= counter + 1;
        end

        assign LED5 = outcnt[0] ? 1'bz : outcnt[1];
endmodule

When you are actually using LED5 as tristate inout, then the safest way to do that right now is by manually instantiating an SB_IO cell. See for example raspi_io in this code: https://github.com/cliffordwolf/icotools/blob/master/icosoc/common/icosoc_raspif.v

Thanks, manually instantiating the SB_IO effectively solves the problem. Here is a dummy example program with bidirectional port. It compiles well with the mentioned Makefile.
module top (
        input  clk,
        output LED1, LED2, LED3, LED4,
        inout LED5
);
        localparam LOG2DELAY = 22;
        reg [LOG2DELAY-1:0] counter = 0;
        reg [1:0] outcnt = 0;
        reg dummy;

        always@(posedge clk) begin
                if (counter == 0) begin
                        case (outcnt)
                          2'b00: outcnt <= 2'b01;
                          2'b01: outcnt <= 2'b10;
                          default: outcnt <= 2'b00;
                        endcase
                end
                counter <= counter + 1;
        end

        assign LED1 = dummy;

        SB_IO #(
          .PIN_TYPE(6'b 1010_01),
          .PULLUP(1'b 0)
        ) led_io (
          .PACKAGE_PIN(LED5),
          .OUTPUT_ENABLE(outcnt[0]),
          .D_OUT_0(outcnt[1]),
          .D_IN_0(dummy)
        );
endmodule

@cliffordwolf I have one problem with your original example: the generated $TBUF drives two toplevel ports.  My original intention was to treat explicitly instantiated SB_IO and $TBUF similarly, and I only allow them to drive a single toplevel port.

Disregard the mistakenly sent previous message.  I have a plan for all of this now.


consistent member names

The struct types are growing more complicated, and I find it confusing to understand what is local state and what is struct state.
A review of recent commits is needed, and some rules formalising the use of struct and associated member variable naming have to be written down.

As a preliminary comment before a review, I'm in favour of having struct used over class when the member variables are public and read/writable with no or little private state. Mutable record-like aggregates would fall into this category.
If something is written up as a struct, then the public fields shouldn't (clearly, only IMO) be decorated with underscores or the like.

I'm closing this because neither of us has had the will to engage with it.


DEP 22- Suggestion

User may not be aware of Ocean/Aquarius keyword, we should try to write in a generic way.
2.one example how to used DefaultResolver, DEX resolver, Squid Resolver should be there ,it will help the developer to write code easily.

https://github.com/DEX-Company/DEPs/commit/4f2fc8ddc91c18d160792ec832f8a2ac6ddab70b

https://github.com/DEX-Company/DEPs/commit/bba3be5872d566a229c6009dda7f2494d2375377

The word Ocean itself I think it is impossible to avoid because we point on it and use it. But squid, aquarius etc I agree. So I have changed a bit. Now it looks better. So assuming, can close the task?


Update README.md

This update is requested in reference to the issue #33552
[Under the heading "Obtain and Import the Library", the link incorrectly refers to the micro_speech.zip package instead of a person_detection example.]
So I updated the "Obtain and Import the Library" section on  the micro_speech.zip [now: person_detection_example.zip].

please combine #33582 with this PR

in reference to issue #33552 .... Just like the person detection .zip name in the magic-wand documentation the same problem is present.

@rthadur would you please check this out: when I click on the person_detection.zip link after update this pops out:
`
This XML file does not appear to have any style information associated with it. The document tree is shown below.

NoSuchKey
The specified key does not exist.

No such object: tensorflow-nightly/github/tensorflow/tensorflow/lite/experimental/micro/tools/make/gen/arduino_x86_64/prj/person_detection/person_detection.zip

`

@rthadur Why close #33582 ? The magic_wand has the same problem as person_detection in README.md

@rthadur Please check the update made to the README.md and tell me if its fine now

This should include the changes from #33582?

Yes, the link for person_detection is fixed. Also themagic-wand documentation needs this same fix as #33582 suggests. You can include the changes from #33582 here in #33579.

I have added the magic_wand.zip issue just like the person_detection as requested....

@mihaimaruseac PLease check the updated README.md the rquested line is removed.

Hello. I'm trying to check a magic wand example. But I cannot download magic_wand.zip on the README.md.


add ednote

Change Request number: ninjs CR 10-07
Standard to be changed: ninjs
Standard’s version to be changed: 1.1
Description of the change: (free-text)
Add an "ednote" property of type "string".
Rationale for the change:
The ednote contains a note that is intended to be read by internal staff at the receiving organisation, but not published to the end-user; in this example it conveys some optional information about the release condition imposed by the element:
"ednote" : "Note to editors: STRICTLY EMBARGOED. Not for public release until 12noon on Friday, October 23, 2016."
Formalised change request: (spec table etc.)
Name: ednote
Definition: A note that is intended to be read by internal staff at the receiving organisation, but not published to the end-user.
Data type: string

JAYSON:
Hmmm. we will likely not use this feature but the change is not adding any unnecessary complexity to the standard, so I am okay with this change.

Voted in 1.2 on oct 16 2019


hostmetrics does not associate any k8s attributes (missing k8s.node.name, etc.)

After adding the hostmetrics receiver, I do not see any attributes to associate new metrics to a particular node. Verifying this by visualizing the events in honeycomb. Is there a configuration that allows associating the node name to hostmetrics? My use-case here is to cover some stats that are not covered by kubeletstats (CPU load, etc.)
My values file is as follows:
mode: daemonset
fullnameOverride: otel-collector-agent

image:
  repository: "otel/opentelemetry-collector-k8s"

# Required to use the kubeletstats cpu/memory utilization metrics
clusterRole:
  create: true
  rules:
    - apiGroups:
        - ""
      resources:
        - nodes/proxy
      verbs:
        - get

extraEnvs:
  - name: HONEYCOMB_API_KEY
    valueFrom:
      secretKeyRef:
        name: honeycomb
        key: api-key

presets:
  hostMetrics:
    enabled: true
  # enables the k8sattributesprocessor and adds it to the traces, metrics, and logs pipelines
  kubernetesAttributes:
    enabled: true
    extractAllPodLabels: true
    extractAllPodAnnotations: true
  # enables the kubeletstatsreceiver and adds it to the metrics pipelines
  kubeletMetrics:
    enabled: true
  logsCollection:
    enabled: true

config:
  receivers:
    jaeger: null
    zipkin: null
    hostmetrics:
      collection_interval: 30s
      scrapers:
        load:
          cpu_average: true # divide by number of cores, better for generalized figures to alert on
    kubeletstats:
      collection_interval: 30s
      metric_groups:
        - pod
        - node
        - volume
      extra_metadata_labels:
        - k8s.volume.type
      metrics:
        k8s.node.uptime:
          enabled: true
        k8s.pod.uptime:
          enabled: true
        k8s.pod.cpu_limit_utilization:
          enabled: true
        k8s.pod.cpu_request_utilization:
          enabled: true
        k8s.pod.memory_limit_utilization:
          enabled: true
        k8s.pod.memory_request_utilization:
          enabled: true
    prometheus:
      config:
        scrape_configs:
          - job_name: opentelemetry-collector # self metrics
            scrape_interval: 300s
            static_configs:
              - targets:
                  - ${env:MY_POD_IP}:8888
  exporters:
    debug:
      verbosity: detailed
      sampling_initial: 5
      sampling_thereafter: 200
    otlp:
      endpoint: "api.honeycomb.io:443"
      headers:
        "x-honeycomb-team": "${env:HONEYCOMB_API_KEY}"
    otlp/k8s-metrics:
      endpoint: "api.honeycomb.io:443"
      headers:
        "x-honeycomb-team": "${env:HONEYCOMB_API_KEY}"
        "x-honeycomb-dataset": "k8s-metrics"
    otlp/k8s-logs:
      endpoint: "api.honeycomb.io:443"
      headers:
        "x-honeycomb-team": "${env:HONEYCOMB_API_KEY}"
        "x-honeycomb-dataset": "k8s-logs"
  processors:
    filter/ottl:
      error_mode: ignore
      metrics:
        datapoint:
          - 'resource.attributes["k8s.volume.type"] != nil and resource.attributes["k8s.volume.type"] != "persistentVolumeClaim"'
  service:
    pipelines:
      traces:
        receivers: [otlp]
        exporters: [otlp]
      metrics:
        exporters:
        - otlp/k8s-metrics
        processors:
        - memory_limiter
        - batch
        - filter/ottl
      logs:
        exporters: [otlp/k8s-logs]

ports:
  jaeger-compact:
    enabled: false
  jaeger-thrift:
    enabled: false
  jaeger-grpc:
    enabled: false
  zipkin:
    enabled: false

@dosu thats a good thought, but the chart already generates a configuration that includes the k8sattributes processor in the metrics pipeline
# Source: opentelemetry-collector/templates/configmap-agent.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: otel-collector-agent-agent
  namespace: otel
  labels:
    helm.sh/chart: opentelemetry-collector-0.102.0
    app.kubernetes.io/name: opentelemetry-collector
    app.kubernetes.io/instance: release-name
    app.kubernetes.io/version: "0.107.0"
    app.kubernetes.io/managed-by: Helm

data:
  relay: |
    exporters:
      debug:
        sampling_initial: 5
        sampling_thereafter: 200
        verbosity: detailed
      otlp:
        endpoint: api.honeycomb.io:443
        headers:
          x-honeycomb-team: ${env:HONEYCOMB_API_KEY}
      otlp/k8s-logs:
        endpoint: api.honeycomb.io:443
        headers:
          x-honeycomb-dataset: k8s-logs
          x-honeycomb-team: ${env:HONEYCOMB_API_KEY}
      otlp/k8s-metrics:
        endpoint: api.honeycomb.io:443
        headers:
          x-honeycomb-dataset: k8s-metrics
          x-honeycomb-team: ${env:HONEYCOMB_API_KEY}
    extensions:
      health_check:
        endpoint: ${env:MY_POD_IP}:13133
    processors:
      batch: {}
      filter/ottl:
        error_mode: ignore
        metrics:
          datapoint:
          - resource.attributes["k8s.volume.type"] != nil and resource.attributes["k8s.volume.type"]
            != "persistentVolumeClaim"
      k8sattributes:
        extract:
          annotations:
          - from: pod
            key_regex: (.*)
            tag_name: $$1
          labels:
          - from: pod
            key_regex: (.*)
            tag_name: $$1
          metadata:
          - k8s.namespace.name
          - k8s.deployment.name
          - k8s.statefulset.name
          - k8s.daemonset.name
          - k8s.cronjob.name
          - k8s.job.name
          - k8s.node.name
          - k8s.pod.name
          - k8s.pod.uid
          - k8s.pod.start_time
        filter:
          node_from_env_var: K8S_NODE_NAME
        passthrough: false
        pod_association:
        - sources:
          - from: resource_attribute
            name: k8s.pod.ip
        - sources:
          - from: resource_attribute
            name: k8s.pod.uid
        - sources:
          - from: connection
      memory_limiter:
        check_interval: 5s
        limit_percentage: 80
        spike_limit_percentage: 25
    receivers:
      filelog:
        exclude:
        - /var/log/pods/otel_otel-collector-agent*_*/opentelemetry-collector/*.log
        include:
        - /var/log/pods/*/*/*.log
        include_file_name: false
        include_file_path: true
        operators:
        - id: container-parser
          max_log_size: 102400
          type: container
        retry_on_failure:
          enabled: true
        start_at: end
      hostmetrics:
        collection_interval: 30s
        root_path: /hostfs
        scrapers:
          cpu: null
          disk: null
          filesystem:
            exclude_fs_types:
              fs_types:
              - autofs
              - binfmt_misc
              - bpf
              - cgroup2
              - configfs
              - debugfs
              - devpts
              - devtmpfs
              - fusectl
              - hugetlbfs
              - iso9660
              - mqueue
              - nsfs
              - overlay
              - proc
              - procfs
              - pstore
              - rpc_pipefs
              - securityfs
              - selinuxfs
              - squashfs
              - sysfs
              - tracefs
              match_type: strict
            exclude_mount_points:
              match_type: regexp
              mount_points:
              - /dev/*
              - /proc/*
              - /sys/*
              - /run/k3s/containerd/*
              - /var/lib/docker/*
              - /var/lib/kubelet/*
              - /snap/*
          load:
            cpu_average: true
          memory: null
          network: null
      kubeletstats:
        auth_type: serviceAccount
        collection_interval: 30s
        endpoint: ${env:K8S_NODE_NAME}:10250
        extra_metadata_labels:
        - k8s.volume.type
        metric_groups:
        - pod
        - node
        - volume
        metrics:
          k8s.node.uptime:
            enabled: true
          k8s.pod.cpu_limit_utilization:
            enabled: true
          k8s.pod.cpu_request_utilization:
            enabled: true
          k8s.pod.memory_limit_utilization:
            enabled: true
          k8s.pod.memory_request_utilization:
            enabled: true
          k8s.pod.uptime:
            enabled: true
      otlp:
        protocols:
          grpc:
            endpoint: ${env:MY_POD_IP}:4317
          http:
            endpoint: ${env:MY_POD_IP}:4318
      prometheus:
        config:
          scrape_configs:
          - job_name: opentelemetry-collector
            scrape_interval: 300s
            static_configs:
            - targets:
              - ${env:MY_POD_IP}:8888
    service:
      extensions:
      - health_check
      pipelines:
        logs:
          exporters:
          - otlp/k8s-logs
          processors:
          - k8sattributes
          - memory_limiter
          - batch
          receivers:
          - otlp
          - filelog
        metrics:
          exporters:
          - otlp/k8s-metrics
          processors:
          - memory_limiter
          - batch
          - filter/ottl
          - k8sattributes
          receivers:
          - otlp
          - prometheus
          - hostmetrics
          - kubeletstats
        traces:
          exporters:
          - otlp
          processors:
          - k8sattributes
          - memory_limiter
          - batch
          receivers:
          - otlp
      telemetry:
        metrics:
          address: ${env:MY_POD_IP}:8888

@dfsdevops the k8sattributes processor works by associating incoming telemetry, specifically the Resource or request context IP, with the kubernetes metadata it is remembering.
In the case of hostmetrics telemetry there isn't anything on in data to associate it to the kubernetes data. It has been a while since I ran the hostmetrics receiver on k8s (kubeletstats has always covered my needs), but I don't believe it is able to get per-pod metrics - all the metrics it collectors are for the entire node.
Is there a specific attribute you'd like to set for this data? Maybe the resourcedetection would better suit your needs if you're trying to add stuff like k8s.node.name.

@TylerHelmuth thank you for clarifying, this could be a misunderstanding on my part. I thought it was able to associate a bare minimum of metadata in the way kubeletstats on the daemonset instances did the same. k8s.node.name is the most important for me as nearly everything else in my metrics has that, being able to cross-reference it would be useful, right now there is nothing in the event that distinguishes each node from one another in kubeletstats, I'm surprised there isn't something like at least a hostname attribute already baked into the hostmetrics preset. I will try messing around with resourcedetection or some other way to manually associate the node name to the data (maybe via the env var?).
Here's an example of what one of the metrics looks like as an event in honeycomb currently, only four columns with no way for me to tie it back to a specific node. Ideally everything in this metric would have a common attribute I could use cross-reference and merge everything I possibly can into a single honeycomb event because high-cardinality is encouraged by the platform. I know thats more of a honeycomb-specific thing but I thought it might help provide context.

I found a configuration I am happy with.
Explanation: Firstly, I removed the preset because I don't want everything it's sending over and it wasn't clear how to disable it from the preset, for now I'm only enabling load.
I created a separate pipeline to add the k8s.node.name attribute via an env var source in a resourcedetection processor. Then used the forward connector to send it into the main metrics pipeline so it's otherwise unified with those processors/exporters.
mode: daemonset
fullnameOverride: otel-collector-agent

image:
  repository: "otel/opentelemetry-collector-k8s"

# Required to use the kubeletstats cpu/memory utilization metrics
clusterRole:
  create: true
  rules:
    - apiGroups:
        - ""
      resources:
        - nodes/proxy
      verbs:
        - get

extraEnvs:
  - name: HONEYCOMB_API_KEY
    valueFrom:
      secretKeyRef:
        name: honeycomb
        key: api-key
  - name: OTEL_RESOURCE_ATTRIBUTES
    value: "k8s.node.name=$(K8S_NODE_NAME)"

extraVolumes:
  - name: hostfs
    hostPath:
      path: /

extraVolumeMounts:
  - name: hostfs
    mountPath: /hostfs
    readOnly: true
    mountPropagation: HostToContainer

presets:
  # enables the k8sattributesprocessor and adds it to the traces, metrics, and logs pipelines
  kubernetesAttributes:
    enabled: true
    extractAllPodLabels: true
    extractAllPodAnnotations: true
  # enables the kubeletstatsreceiver and adds it to the metrics pipelines
  kubeletMetrics:
    enabled: true
  logsCollection:
    enabled: true

config:
  connectors:
    forward:
  receivers:
    jaeger: null
    zipkin: null
    hostmetrics:
      collection_interval: 30s
      root_path: /hostfs
      scrapers:
        load:
          cpu_average: true # divide by number of cores, better for generalized figures to alert on
    kubeletstats:
      collection_interval: 30s
      metric_groups:
        - pod
        - node
        - volume
      extra_metadata_labels:
        - k8s.volume.type
      metrics:
        k8s.node.uptime:
          enabled: true
        k8s.pod.uptime:
          enabled: true
        k8s.pod.cpu_limit_utilization:
          enabled: true
        k8s.pod.cpu_request_utilization:
          enabled: true
        k8s.pod.memory_limit_utilization:
          enabled: true
        k8s.pod.memory_request_utilization:
          enabled: true
    prometheus:
      config:
        scrape_configs:
          - job_name: opentelemetry-collector # self metrics
            scrape_interval: 300s
            static_configs:
              - targets:
                  - ${env:MY_POD_IP}:8888
  exporters:
    debug:
      verbosity: detailed
      sampling_initial: 5
      sampling_thereafter: 200
    otlp:
      endpoint: "api.honeycomb.io:443"
      headers:
        "x-honeycomb-team": "${env:HONEYCOMB_API_KEY}"
    otlp/k8s-metrics:
      endpoint: "api.honeycomb.io:443"
      headers:
        "x-honeycomb-team": "${env:HONEYCOMB_API_KEY}"
        "x-honeycomb-dataset": "k8s-metrics"
    otlp/k8s-logs:
      endpoint: "api.honeycomb.io:443"
      headers:
        "x-honeycomb-team": "${env:HONEYCOMB_API_KEY}"
        "x-honeycomb-dataset": "k8s-logs"
  processors:
    resourcedetection:
      detectors:
        - env
    filter/ottl:
      error_mode: ignore
      metrics:
        datapoint:
          - 'resource.attributes["k8s.volume.type"] != nil and resource.attributes["k8s.volume.type"] != "persistentVolumeClaim"'
  service:
    # telemetry:
    #   logs:
    #     level: debug
    pipelines:
      traces:
        receivers: [otlp]
        exporters: [otlp]
      metrics/hostmetrics:
        receivers: [hostmetrics]
        processors:
          - resourcedetection
        exporters: [forward]
      metrics:
        receivers:
          - otlp
          - prometheus
          - forward
          - kubeletstats
        exporters:
          - otlp/k8s-metrics
          # uncomment the following line to enable debug logging for metrics
          # - debug
        processors:
          - memory_limiter
          - batch
          - filter/ottl
          - k8sattributes
      logs:
        exporters: [otlp/k8s-logs]

ports:
  jaeger-compact:
    enabled: false
  jaeger-thrift:
    enabled: false
  jaeger-grpc:
    enabled: false
  zipkin:
    enabled: false


Job arguments support

Jobs can have arguments. E.g.
update_trackers:
  cron: "* * * * *"
  class: Trackers::BatchUpdateJob
  description: Update active trackers
  args:
    argname: "value"

I'm really looking forward to using it. But it conflicts with the current chained job implementation.
It doesn't work due to "perform" method which checks if "worker_id" is defined and acts differently. ActiveJob passes arguments to the same variable. And "worker_id" becomes an object {"argname"=>"value"} rendering this method incalid.
This pull request is a nasty type check that solves the issue for this specific case. What would be the right way to solve it to enable arguments in chained jobs?
@vinted/backend

So I guess what you really want is to have:
update_trackers:
  cron: "* * * * *"
  class: Trackers::BatchUpdateJob
  description: Update active trackers
  args:
    argname: "value"

update_trackers2:
  cron: "* * * * *"
  class: Trackers::BatchUpdateJob
  description: Update active trackers
  args:
    argname: "value2"

This will not work. One of chained jobs benefits is it reduces posibility of two chains running same time.
It is done by cleaning up arguments for other chains https://github.com/vinted/core/blob/2ed3e279fa1d95e6b12406886b309367b8cce22e/app/lib/jobs/chained.rb#L79-L88
So we have some race condition which chain will be running at any time update_trackers or update_trackers2. I think it is even possible to starve one chain completely even if another does not have any work to do.

I guess you can have several almost identical  jobs, each calling interactor with argument. There is some code duplication, also all these jobs would be running in parallel, which may or may not be a problem for your case.

You are right in terms of what I want to achieve. I want many chains to run in parallel.
Extend and copy/paste the job class was the first iteration :D
=============
This part I didn't understood:
"It is done by cleaning up arguments for other chains"
I've expected every chain has it's own queue. And cleans up only it's own unfinished jobs. Isn't it true?
@tomaszulgis

Yes, each class ATM has only one chain.

Ok one caveat I am looking at core implemntation, maybe here it is different

Ok one caveat I am looking at core implemntation, maybe here it is different

Seems to be the same in this implementation as the redis key is dependant on the job's class


Bug: Sync channel returns RecvError

Minimal test case:
extern crate coio;

use coio::Scheduler;
use coio::sync::mpsc;

fn main() {
    Scheduler::new().run(|| {
        let (tx, rx) = mpsc::sync_channel(1);
        let h = Scheduler::spawn(move|| {
            tx.send(1).unwrap();
        });

        assert_eq!(rx.recv().unwrap(), 1);

        h.join().unwrap();
    }).unwrap();
}

The program would panic with message:
thread 'Processor #0' panicked at 'called `Result::unwrap()` on an `Err` value: RecvError', ../src/libcore/result.rs:746
note: Run with `RUST_BACKTRACE=1` for a backtrace.
thread '<main>' panicked at 'called `Result::unwrap()` on an `Err` value: Any', ../src/libcore/result.rs:746

This could be fixed by
extern crate coio;
extern crate env_logger;

use coio::Scheduler;
use coio::sync::mpsc;

fn main() {
    env_logger::init().unwrap();

    Scheduler::new().run(|| {
        let (tx, rx) = mpsc::sync_channel(1);
        let h = Scheduler::spawn(move|| {
            // 2. Push 1 into the queue and push <main> into the work queue
            tx.send(1).unwrap();

            // 3. Force yield the current coroutine,
            //    which will let the receiver have a chance to be waken up and read data
            Scheduler::sched();
        });

        // 1. The <main> coroutine block itself into the wait list
        assert_eq!(rx.recv().unwrap(), 1);

        h.join().unwrap();
    }).unwrap();
}

The official implementation of sync channel, the try_recv method will return Disconnected if it is the last one.
So when the last SyncSender is dropped, the receiver will always return Disconnected even if there are items remain in the queue.

I'm currently debugging SIGSEGV (segmentation fault) issue...
It currently happens everytime we use std::sync::Mutex. And since it's
used in the MPSC channels you can't even run a Scheduler anymore.
For instance for the "test_join_basic" test:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb61ffb40 (LWP 17763)]
0x8001a5dd in coio::sys::mutex::Mutex::new () at
../src/libstd/sys/unix/mutex.rs:27
27    ../src/libstd/sys/unix/mutex.rs: Datei oder Verzeichnis nicht
gefunden.
(gdb) bt
#0  0x8001a5dd in coio::sys::mutex::Mutex::new () at
../src/libstd/sys/unix/mutex.rs:27
#1  0x8001a5a7 in coio::sys_common::mutex::Mutex::new () at
../src/libstd/sys/common/mutex.rs:28
#2  0x8001a56a in coio::sync::mutex::StaticMutex::new () at
../src/libstd/sync/mutex.rs:333
#3  0x80028994 in coio::sync::mutex::Mutex<T>::new
(t=VecDeque<Box<coio::coroutine::Coroutine>> = {...}) at
../src/libstd/sync/mutex.rs:194
#4  0x80090f4e in
coio::sync::mpsc::channel<core::result::Result<i32, Box<Any>>> () at
src/sync/mpsc.rs:139
#5  0x8009094c in
coio::scheduler::Scheduler::spawn_opts<closure,i32> (f=closure,
opts=Options = {...}) at src/scheduler.rs:236
#6  0x80090860 in coio::scheduler::Scheduler::spawn<closure,i32>
(f=closure) at src/scheduler.rs:227
#7  0x80090442 in fnfn () at src/scheduler.rs:488
#8  0x80090274 in fnfn () at src/scheduler.rs:277
#9  0x80090240 in fnfn () at src/lib.rs:138
#10 0x8008ffc8 in fnfn () at ../src/libstd/panic.rs:260
#11 0x8008ff8f in coio::sys_common::unwind::try::try_fn<closure>
(opt_closure=0xb7d69d4c "") at
../src/libstd/sys/common/unwind/mod.rs:127
#12 0x801238d8 in __rust_try ()
#13 0x801202d7 in sys_common::unwind::inner_try::he7c37ff3388a08c5Ndt ()
#14 0x8008ff16 in coio::sys_common::unwind::try<closure> (f=closure
= {...}) at ../src/libstd/sys/common/unwind/mod.rs:123
#15 0x8008fd3b in coio::panic::recover<closure,()> (f=closure =
{...}) at ../src/libstd/panic.rs:260
#16 0x8008fcd0 in coio::try<(),closure> (f=closure = {...}) at
src/lib.rs:137
#17 0x8008fbba in fnfn () at src/scheduler.rs:277
#18 0x80090740 in coio::boxed::F.FnBox<A>::call_box
(self=0xb641b100, args=0) at ../src/liballoc/boxed.rs:541
#19 0x800bdd8b in coio::boxed::Box<FnBox<A, Output = R>+
'a>.FnOnce<A>::call_once (self=Box<FnBox<()>>, args=0) at
../src/liballoc/boxed.rs:550
#20 0x800bd940 in coio::coroutine::coroutine_initialize
(f=0xb66ea100) at src/coroutine.rs:44
#21 0x800bd8b3 in
coroutine::coroutine_initialize::h5c5e3a3bfb20b522LVd () at
../src/libcore/raw.rs:159
#22 0x00000000 in ?? ()

Is it possible that this is caused by context-rs, or are you sure that
it works with x86? Could it be that the memory isn't mmap()ed correctly?
I can't think of any other reason that would otherwise cause a SIGSEGV
even though only so little stack space is used.

I don't think so. You can run the cargo test in context-rs and you will find that all the tests are going to trigger SIGSEGV.
Yep, I am sure that is not work on x86.

Ah good idea! I didn't think of this...
Maybe we should add a method to the Scheduler that works just like Scheduler::ready(coro) but yields to the coro if it's on the same Processor? Or would it still break if they run on 2 different Processors?
I mean: I think it should still break if 2 different Processors are used. So... Should we really adopt the standard Rust channel semantics? Why are they even using this weird Disconnected state? Shouldn't a channel be empty before a Disconnected is returned? IMHO that would make a lot more sense...

I spent some time on reading the source code of the official implementation of mpsc channel, and I think it too complicated to reinvent this wheel. The behavior should have been discussed in RFC, so I think it is Ok to use it. Also, you cannot reproduce it with threads.
use std::thread;
use std::sync::mpsc;

fn main() {
    let (tx, rx) = mpsc::sync_channel(1);
    let t = thread::spawn(move|| {
        tx.send(1).unwrap();
    });

    t.join().unwrap();

    rx.recv().unwrap();
}

It always works because the official implementation will actually park the thread.

I've read it too now...
So we either have to use the same thing as std (ACKs), or we have to wait until the queue is empty before we trigger a Disconnected result.
The former case will be a lot slower (btw: the std implementation uses Mutex?! Wow. :disappointed: ) and the latter case is dangerous because we don't want to wait until the overwhelmed receiver is finished even though all senders are already gone.
I think we should invent something ouselves here, because it can't be that complicated if even the std. implementation is using a Mutex for this - we can't really make it any worse right? :neutral_face:

Yep. I agree.


/agent/api/v1/configs/{write_relabel_configs}

https://github.com/prometheus/prometheus/blob/edfe657b54057e427469a2151153d305270662a4/scrape/scrape.go#L738

Hi there! Do you mind clarifying what this issue is about? It's not clear from the title and descripiton.


LDAP Auth - Malformed UTF 8

Running bookstack v0.28.3, installed via the ubuntu script on a fresh LXC container.  PHP 7.2.24-0ubuntu<IP_ADDRESS>, hosted on apache (http) with an nginx proxy (https) in front of it.
After submitting any password (correct or incorrect) for a valid user, an InvalidArgumentException is thrown: Malformed UTF-8 characters, possibly incorrectly encoded.  Any password for an invalid user displays the normal "these credentials do not match our records"
Attempting to bind against Active Directory, not native LDAP.
My relevant config file, heavily edited but still similar:
AUTH_METHOD=ldap

LDAP_SERVER=<IP_ADDRESS>:389
LDAP_BASE_DN=ou=users,dc=example,dc=com
<EMAIL_ADDRESS>LDAP_PASS='test one test two'

LDAP_USER_FILTER=(&(sAMAccountName=${user}))
LDAP_VERSION=3

LDAP_ID_ATTRIBUTE=BIN;objectGUID
LDAP_EMAIL_ATTRIBUTE=mail
LDAP_DISPLAY_NAME_ATTRIBUTE=cn

LDAP_USER_TO_GROUPS=true
LDAP_GROUP_ATTRIBUTE="memberOf"
LDAP_REMOVE_FROM_GROUPS=false

LDAP_DUMP_USER_DETAILS=false

Per #1961 I have confirmed that LDAP_VERSION is 3, and that LDAP_ID_ATTRIBUTE is indeed BIN;objectGUID.  No luck.  One possible lead is that the AD server is rather old...perhaps too old for bookstack?  Please advise, and thanks for the help!

Thanks for opening this on a new issue @rocnetBinarian.
Could you post the full Exception while LDAP_DUMP_USER_DETAILS=false is set?  Would be good to know exactly when this occurs, and hopefully that full exception detail should indicate what property this is thrown at.
Debugging details can be found here:
https://www.bookstackapp.com/docs/admin/debugging/

Here ye be!

Thanks

Thanks @rocnetBinarian, Is your LDAP_DUMP_USER_DETAILS definitely set to false or undefined when that error shows?
That error contains JsonDebugException which I would not set to see if that option was false.

It is definitely set to false.  I just tried commenting it out entirely as well, and same issue.

@rocnetBinarian On the broken instance, do you have any files within the bootstrap/cache/?
If you have a bootstrap/cache/config.php file then your config may have been cached at the framework level. Can just delete that file if so.

Since the last comment on this issue is relatively old I'm going to close this. If the issue remains and is something you still require to be fixed please open a new issue, referencing this one.

Since the last comment on this issue is relatively old I'm going to close this. If the issue remains and is something you still require to be fixed please open a new issue, referencing this one.


..

..

@BenMukebo, Hello, thanks for your comments, I have a question regarding the description part of each project, since the Figma template shows a specific text, should I leave the mobile and written description for all projects and customize the title and image What would change for each project when clicking on "see project"?


Changed binary (executable) file name in Cargo.toml

Hi! I changed Cargo.toml to save the output of binary with file name “sptplay”.  You can recommend another name, too.
It makes running application easier.

Hi, thanks for the PR but I don't have any plans of changing the binary name anytime soon


Is network HW requirement "contains" or "equals", i.e. these NICs and no other?

# Select by vendor and device name
network:
  - type: eth

Does this requirement mean no other NICs are allowed on the machine? If that's so, how would one express other NICs are allowed? And if this means other NICs are allowed, how would one express that this NIC and no other is allowed on the guest?
We're trying to enlarge the pool of machines available for a particular plan. The plan lists 2 type: eth entries under network, and it's not clear what is the expectation - the user is fine with "at least these, don't care about the rest", that would enlarge the pool of available boxes, but is that aligned with the specification? And how would we express the other case, no matter which one would it be?
Edit: the same applies to disk:
disk:
  - size: '>= 2 GB'
  - size: '>= 20 GB'

Only these two disks, or can the machine have 10 disks, but two must match this requirement?

If the current expectation is that this will give you 2 and only 2 nics:
- eth
- eth

Then to keep backwards compatibility with that expectation and at the same time allow less strict requirements to the number of NICs, we could just add a count field to network:
network:
  - type: eth
    count: ">=2"

Unfortunately, count: ">=2" does not say anything about the number of allowed type: not-so-much-eth NICs.
network:
  - type: eth
    count: ">= 2"
  - type: .*
    count: ">= 0"

Feels weird :/


Why does automatic completion is PascalCase not kebab-case?

Why does automatic completion is PascalCase not kebab-case? need me to configure anything? thanks

I use neovim, completion plugin is nvim-cmp
this is my config
lspconfig.volar.setup {
  filetypes = {
    "javascript",
    "javascriptreact",
    "typescript",
    "typescriptreact",
    "vue"
  },
  init_options = {
    languageFeatures = {
      completion = {
        defaultTagNameCase = "kebabCase",
        defaultAttrNameCase = "camelCase"
      }
    }
  }
}

I also try vscode, it's no probrem

You can config "volar.completion.preferredTagNameCase": "kebab" to the IDE settings.


WaniKani content update

WaniKani has updated their levels. @Bennycopter, could you pick up the changes, please?

Fixed by https://github.com/Bennycopter/WaniKani-Wallpaper-Generator/pull/2


[NSTask] Cleanup environment after task is launched

Currently the environment is deallocated before the task is launched. This results in memory being overwritten, and a corrupt environment. @ddunbar suggested moving the defer up a scope. I've added a few tests to verify the correctness of the environment.

@swift-ci please test


(Debug)Extension Development, Start Without Debugging

VSCode Version:
OS Version:

Steps to Reproduce:

Don't have a launch.json
Debugging a debug-extension.

Press Strg + F5 (German shortcut)/Start Without Debugging
noDebug of LunchRequestArguments is not set, when launchRequest of the extension is called
 interface LaunchRequestArguments {
        /** If noDebug is true the launch request should launch the program without enabling debugging. */
        noDebug?: boolean; // is undefined
        /** Optional data from the previous, restarted session.
            The data is sent as the 'restart' attribute of the 'terminated' event.
            The client should leave the data intact.
        */
        __restart?: any;
    }

If you have a launch.json, noDebug is set.

launchRequest is a Method of LoggingDebugSession.
CALLSTACK:

Does this issue occur when all extensions are disabled?: Yes/No

Do you need more information?

How exactly do you debug an extension development scenario without a launch.json? I do not think we even support this. Can you share how you do this exactly?
If I just "Start without debugging" for a regular javascript file the noDebug is properly passed.

I debug my debugging extension. I don't have one launch.json for my extension debug process but I have one for debugging my extension.
Or in other words: The test-workspace, where the debugging of my extension is running on, has no launch.json.
extensioDevelopment
|-.vscode
|   |-launch.json
|-src
|-TestWorkspace
|   |-.vsocde
|       |-No-launch.json
|-package.json

@peni4142 the your steps are misleading:
Your workspace where you are debugging the extension has a launch.json, but the workspace where you are testing the running extension has no launch.json, correct?

correct

I can not reproduce this.
What are you doing differently than me

I have a freshly generated vscode extension repository
F1 > start without debugging
noDebug is passed in the launch request. I verified that breakpoints do not get hit

Sry I was sick.
Ans sry was my bad in that function:
resolveDebugConfiguration(folder: WorkspaceFolder | undefined, config: IExtendedDebugConfiguration, token?: CancellationToken): ProviderResult<DebugConfiguration>
:-/


Generate swaths start with a angle and point ?

Great project. I am wondering if it would be possible to provide a point and bearing (A+) that the software uses to build the swaths? In our farming operating the autonomous tractor will need to drive on existing AB lines that have been there for a long time already. It's ok to drive off existing tracks to turn on headlands etc but the straight line swath should match existing tracks. Any way to achieve this? Thanks

Hi @benboughton1, thanks!
Creating the swaths with a point and an angle is not supported, although it shouldn't be difficult to add it.
Either way, if you already have the AB tracks, my recommendation would be to create your own swaths by hand, and then use the route planner and path planner modules to generate the coverage path. If you use the swath generator module, swaths may not be perfectly aligned with your previous AB-lines.

Great thanks I will give that a go!Sent from my iPhoneOn 27 Jun 2024, at 10:55 PM, Gonzalo Mier @.***> wrote:
Hi @benboughton1, thanks!
Creating the swaths with a point and an angle is not supported, although it shouldn't be difficult to add it.
Either way, if you already have the AB tracks, my recommendation would be to create your own swaths by hand, and then use the route planner and path planner modules to generate the coverage path. If you use the swath generator module, swaths may not be perfectly aligned with your previous AB-lines.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

So I have some parallel lines to use for swaths. How should I best go about generating swaths? Should I convert these to a json string and use your parser? If so where can I find an example json as a template please?


[ConstraintSystem] Don't attempt property wrapper fixes for key path …

…dynamic member lookup
If this is an attempt to fetch members through key path dynamic member lookup
let's not try to apply any property wrapper related fixes because modifying
base type would not change the result.
Resolves: SR-12520
Resolves: rdar://problem/61911108

@swift-ci please smoke test

@swift-ci please build toolchain

Linux Toolchain (Ubuntu 16.04)
Download Toolchain
Git Sha - 6bdd534a9cdf31318d8166b7b6e8e99d24485756
Install command
tar zxf  swift-PR-31412-364-ubuntu16.04.tar.gz
More info

macOS Toolchain
Download Toolchain
Git Sha - 6bdd534a9cdf31318d8166b7b6e8e99d24485756
Install command
tar -zxf  swift-PR-31412-510-osx.tar.gz --directory ~/


Investigate Type checking behavior when using Unions in Left position of chain

Following of (https://github.com/gcanti/fp-ts/issues/528#issuecomment-407789826) (re-copied here):
Well, changing to the following somehow doesn't break Chain2<URI> interface:
class Left<L, A> {
  chain<M, B>(f: (a: A) => Either<M, B>): Either<L | M, B> {
    return this as any
  }
}
class Right<L, A> {
  chain<M, B>(f: (a: A) => Either<M, B>): Either<L | M, B> {
    return f(this.value)
  }
}

// Chain2<URI> instance
export interface Chain2<F extends URIS2> extends Apply2<F> {
  readonly chain: <L, A, B>(fa: Type2<F, L, A>, f: (a: A) => Type2<F, L, B>) => Type2<F, L, B>
}
const chain = <L, M, A, B>(fa: Either<L, A>, f: (a: A) => Either<M, B>): Either<L | M, B> => {
  return fa.chain(f)
}
const either: Chain2<URI> = { chain }

const result = left(123).chain(() => left('foo')) // Either<string | number, {}> - handy
const result2 = either.chain(left(123), () => left('foo')) // error - as expected

But why?

I think it's structural, (We're thinking too nominally).
Typescript does not defer type checking, so it typechecks the actual types and as there's no constraints on those types; they are structurally 'equals'.
So it typechecks..


Caption always inside image (left)

Is there a way to have the captions always on the bottom left of the image?
In this example here (https://fotorama.io/examples/captions/) the first picture is exactly how I would like to have it:

The second picture shows the problem: The caption is not left bottom of the image but left bottom of the container which results in a misplaced caption:

The desired result would be:

Also for the third picture which is portrait it is not ideal:

Better would be:

So the caption container should get the same "left" as the image:

As the image changes its size (and so its "left") when changing into kiosk mode (F11 in most browsers) or change windows size, the same should happen to the "left" of the caption container.

Trying to achieve the same thing here, but I can't get my head around where this is applied in the JS.
I've duplicated the 'captions' items and created a 'titles' so that I could render titles for each image in addition to the caption, all from data-attributes. Just trying to get them positioned relative to the image seems to be my biggest stumbling block.


Fixes bug where debug did not imply sampled

It is true the b3-propagation spec suggests debug implies sampled.
This leniently parses a missing X-B3-Sampled header as long as
X-B3-Flags: 1 is present.
Fixes #661

What is the reasoning to handle this in the builder and not in the sampled() method ?
Extraction from the B3-headers should work correctly with this PR, but I expect this assertion would fail:
assertThat(context.toBuilder().debug(true).sample(null).build().sample()).isTrue();

What is the reasoning to handle this in the builder and not in the
sampled() method ?

because the context is immutable, so there's no need to conditionally
consider this at runtime (the extra logic isn't needed). debug is very edge
case and it is also distracting to have the most used code (sampled) have
to make decisions for something rarely used and also implies a fixed
decision. So it is mainly about what we are optimizing for.. I don't like
optimizing for the odd things.

Extraction from the B3-headers should work correctly with this PR, but I
expect this assertion would fail:
assertThat(context.toBuilder().debug(true).sample(null).build().sample()).isTrue();
debug is already a very edge-case feature, one that almost no-one uses.
When it is used, it is often used alongside the sampled flag.
for example, the chrome plugin does this.. that's why this issue itself
wouldn't hit many. So, let's keep in mind the likelihood of it ever being
set in this way.
I added propagation tests, for the off-chance.

Now, in your test case, you are talking about a trace context manually
changed, in a strange order, which is even more edge case..
For example, sampled isn't set to null after a decision is made. A decision
is persistent in the trace once made. It basically doesn't make sense even
if it made sense to manually change a context.
Sorry this particular line is getting more attention than a lot of the
codebase :) I'm going to stop explaining now and hope I answered.. still
lots to do!


LitsView bottom border doesn't appear on some items

Hi!

Versions
react:16.2.0
react-native:0.55.1
native-base:2.7.2

OS

Android (I'm not using expo)

Expected Behavior

All items in the ListView should display the bottom border

Actual Behavior

There are items which does not show the bottom border randomly

I need to make the UI look consistent. Hope someone could help me with this.

Is this screenshot from emulator?

yes. It is

Check this over device, it works as expected

I checked this on an actual device and this is how it looks,

I have put up this example on snack https://snack.expo.io/ryJW335rQ
Works fine


golangci-lint: limit concurrency and never colorize

Changes

I am hoping, it would reduce the number of time the check fails…
Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:

[ ] Includes tests (if functionality changed/added)
[ ] Includes docs (if user facing)
[x] Commit messages follow commit message best practices

See the contribution guide for more details.
Double check this list of stuff that's easy to miss:

If you are adding a new binary/image to the cmd dir, please update
the release Task to build and release this image.

Reviewer Notes
If API changes are included, additive changes must be approved by at least two OWNERS and backwards incompatible changes must be approved by more than 50% of the OWNERS, and they must first be added in a backwards compatible way.

Also bumping the deadline looks like.  Does colorizing slow CLI stuff down?  TIL
/approve

Also bumping the deadline looks like. Does colorizing slow CLI stuff down? TIL

I am assuming it might slow stuff down by a tiny tiny bit :stuck_out_tongue_closed_eyes: but it's just a guess really…

/lgtm
Let's see if this helps with the timeouts that are happening in #2544


Double (Or Increase) the number of Hotkey Swaps Available

With the new availability to swap the achievement diary cape teleports the default 10 hotkey swaps doesn't let you use all the diary cape teles with a hotkey (it has 1-9 and A-G for a total of 16 options).
It seems like 20 would be a nice number of hotkey swaps to handle all Diary cape and Max Cape Teles as well as a few extra for whatever.
If it was possible to add an unlimited number of hotkeys with an add button that would be even better, but I assume just going from 10-20 would be easier.

Haha, I did count the total number of swaps and figured someone would ask for it. Didn't expect it to happen in less than 24 hours though.
I'd probably just up it to 20. Few people need that many and arbitrary numbers of hotkeys would mean I'd have to split the UI between the config panel and a custom side panel, or something like that. Awkward, and more work.

added in 2.5.4


docs: fix wrong MockFunctions.md log result

It seems a little strange to me. Why are we showing the first and second arguments of the first function call (lines 108-109 of the MockFunctions.md). It would be more correct to write .calls[0][0] and .calls[1][0] to show the first argument of function

calls.
MockFunctions.md typo fixed

Summary
It fixes documentation typo. Therefore, the reader will correctly understand the text if we fix this typo.
Test plan
http://prntscr.com/15t2xmb

Codecov Report

Merging #11588 (f90b795) into master (7be63ef) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master   #11588   +/-   ##
=======================================
  Coverage   69.00%   69.00%
=======================================
  Files         312      312
  Lines       16331    16331
  Branches     4730     4730
=======================================
  Hits        11269    11269
  Misses       5034     5034
  Partials       28       28

Continue to review full report at Codecov.

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

Same as #11556

Hmm, yeah. Thanks. I didn't notice it.


Airdrop hunter address, one person and one address created 111 multi-signatures,Here are 18 of them I reported

The airdrop hunter used the 0x20c05cf93223e39d75b6266b4044e2e5c588d089 mainnet wallet to create 111 multi-signature addresses, and all of them received high token rewards,The query link is https://etherscan.io/address/0x20c05cf93223e39d75b6266b4044e2e5c588d089?method=Create__Proxy__With__Nonce~0x1688f0b9
Querying an address through the Ethereum browser has created 111 multi-signature addresses, and all of them have transactions. The query link is https://etherscan.io/address/0x20c05cf93223e39d75b6266b4044e2e5c588d089?method=Create__Proxy__With__Nonce~0x1688f0b9
0xf7525aCAd4cAc16e4f4b873E514cB4Ef171D7d69
0x30cd6Df997D3c153624FcC560823A32E8886D69A
0x199aa8a209884FfB1e0849eAeB072BCe573bf871
0x8cb1f9ad02E57eca18065d83efDFB6fF0C57392c
0x8cb1f9ad02E57eca18065d83efDFB6fF0C57392c
0xf7525aCAd4cAc16e4f4b873E514cB4Ef171D7d69
0x30cd6Df997D3c153624FcC560823A32E8886D69A
0xf03A139c3d0D26a07E2939204aE7f3EA1DbD9919
0x8F6a8cBAcb7aab99d80c39eaC0a412653756f83A
0x7C3D8bc495b7d2Dcc995A3A0dC6444480483988c
0x47d1EC908b261aDf318F16D52752eEc0B2C38bE6
0xADCa2254b9B40a48Ef44140482E912a03cBc7f5d
0x56515294Acc335ED825d640Cc5dfF615ffeD132C
0x70C9Fd1651Ca952314965764012ab63e60Fd4Eb9
0xeAe5e0d63285f24F3a089fDB6a0082Ff6801eBA1
0x521Fe1BD7DEC39362809caC1a237629d458e459b
0x692a7D771c69bf1664690b5A072E04f14254AecE
0x1D02F0a433a999A777d1b11311C4bc9fac33Af65
Reasoning
The airdrop hunter used the 0x20c05cf93223e39d75b6266b4044e2e5c588d089 mainnet wallet to create 111 multi-signature addresses, and all of them received high token rewards,The query link is  https://etherscan.io/address/0x20c05cf93223e39d75b6266b4044e2e5c588d089?method=Create__Proxy__With__Nonce~0x1688f0b9
Methodology
Querying an address through the Ethereum browser has created 111 multi-signature addresses, and all of them have transactions. The query link is  https://etherscan.io/address/0x20c05cf93223e39d75b6266b4044e2e5c588d089?method=Create__Proxy__With__Nonce~0x1688f0b9
they all call  Create__Proxy__With__Nonce
My Safe Address
0x04b9f219331e4586Ae35cff9065eFc2A09F29751

After the above addresses are queried, most of them have only one transaction, which is not registered from the repeater. All of them are 0x20c05cf93223e39d75b6266b4044e2e5c588d089 to each contract address. A very small Ethereum transaction, an obvious behavior of brushing. For example hash(0x02a530e0678f8e52d21e8c7bc869f09e1a40c661df6ea808c859c929783b508c,0xbe86ea3506cf29e30b18573d8e99f4d04b4dd08579143c7a1c879a2e8e483e2b,0x76751487af76962e239c9f55a34738211f27cdeed4ad752b3bad04fa1ed2dd410x06985b4cb0545ccb9928ce19ec9f3424952b536680122260eee24fe44034e2ed)

This report is incomprehensible, please structure it properly and explain your reasoning in a way that can be followed.

The reason I make the judgment as a witch is because the contract creators all use their own creation addresses to transfer 0.001e to the small-value addresses, and the source of funds is their own main address. From this point of view, it can be judged that this is not a repeater. If the repeater creates the address and the resource source address is not the same. And all addresses have similar small-amount transaction behavior, and most addresses only have this small-amount transaction, which is the basis for my judgment

And as can be seen below, the address of the execution transaction (exec Transaction) and the creation address have a source of funds relationship. The creation address is marked with e for the source of funds address. One person has created hundreds of contract addresses, and the funds of the execution address also come from the creation of the address. address. If it has something to do with repeaters. The execution address should execute contracts created by multiple different addresses, but only execute contracts created by this address, which is too unreasonable

0x30cd6df997d3c153624fcc560823a32e8886d69a
0x199aa8a209884ffb1e0849eaeb072bce573bf871
0x8cb1f9ad02e57eca18065d83efdfb6ff0c57392c
0x30cd6df997d3c153624fcc560823a32e8886d69a
0xf03a139c3d0d26a07e2939204ae7f3ea1dbd9919
0x7c3d8bc495b7d2dcc995a3a0dc6444480483988c
0xadca2254b9b40a48ef44140482e912a03cbc7f5d
0xeae5e0d63285f24f3a089fdb6a0082ff6801eba1
0x521fe1bd7dec39362809cac1a237629d458e459b
0x1d02f0a433a999a777d1b11311c4bc9fac33af65
The addresses I copied all had only one small transaction, which was completely in line with witch behavior. And all are the same amount, the contract creator and transfer address are different, excluding the possibility of a repeater.

I'm unable to follow your reasoning for at least the following 2 Safes
https://gnosis-safe.io/app/eth:0x47d1EC908b261aDf318F16D52752eEc0B2C38bE6/transactions/history
https://gnosis-safe.io/app/eth:0xf7525aCAd4cAc16e4f4b873E514cB4Ef171D7d69/transactions/history
Hence there is a chance your report would eliminate legit usage.


Audio Output Streams

We could use cpal for cross platform audio I/O. Currently it only supports audio output, however I believe they're open to adding support for input - we just need someone to need it enough to actually implement it (and then also implement synchronised duplex streams).
Audio is processed on its own thread and so should likely have its own model->update->render architecture in the same way that the graphics thread has its own model->update->draw.
mod audio {
    struct Model {}

    fn model(app: &AppAudio) -> Model {}
    fn update(app: &AppAudio, model: Model, event: AudioEvent) -> Model {}
    fn render(app: &AppAudio, model: &Model, buffer: Buffer) -> Buffer {}
}

One issue that comes to mind with this structure is that the render stage in audio tends to require mutable access to the model in order to step forward the phase of oscillators or step forward a playhead over a buffer of samples. A user could get around this using Cell or RefCell but this kind of feels like it defeats the purpose.
The AudioEvent enum might look something like this:
enum AudioEvent {
    /// The sample rate of the target `Buffer` has changed.
    SampleRate(f64),
    /// The number of channels per buffer has changed.
    Channels(usize),
    /// The default output device changed.
    DefaultDevice(Device),
    /// A new device was detected.
    DeviceAdded(Device),
    /// A device was removed.
    DeviceRemoved(Device),
}

Similarly to App, AppAudio should act as a general application context but with methods related to audio rather than windowing. Methods might include:

Device enumeration
Default device
Current stream format (sample rate, channels, default sample format / bit depth)

Come to think of it, the device info might even be more useful on the GUI thread, as it is normally via some sort of GUI interaction that devices are viewed or selected.

Another thing worth considering is that, unlike the main graphics thread, it is not uncommon for a user to require multiple audio stream threads at once, occasionally even via different devices.
E.g. the user may want an input stream from one device, process it and sum it onto an output stream via a different device (using some kind of interpolation to synchronise them).
Almost always these streams are interacted with and owned via the main GUI thread, or at least some thread other than the audio streams themselves.
For these reasons it probably makes sense to provide the API for spawning, playing, pausing and dropping streams via the App type itself. E.g. when spawning a stream, a StreamId or StreamHandle can be returned to the user so that they may store it in their Model for reference.

Closed by #26.


Removing Runas User ID causes validation error on save

Setup

Rancher version: 2.7.5
Rancher UI Extensions: none
Browser type & version: 116.0.5845.111 (Official Build) (64-bit) (Windows 11)

Describe the bug
removing Security Context "Runas User ID" causes error in UI
To Reproduce

open cluster
select workloads
Select Create
choose Deployment
on container-0 provide image (e.g nginx:latest)
select Security Context
Enter 33 in "Run as User ID"
Save
Edit Config for workload just created
Under Security Context remove 33 from "Run as User ID"

Result
Deployment in version "v1" cannot be handled as a Deployment: json: cannot unmarshal string into Go struct field SecurityContext.spec.template.spec.containers.securityContext.runAsUser of type int64

Expected Result
Config change should be saved
Note:
When removing the number single quotes are left behind causing the failure.
If I edit yaml and remove ID then it saves correctly
Tested on 2.7.5 and 2.7.7-rc4 - both have issue

Tested on final 2.7.7 and issue is still there.
Problem is when deleting value the empty value is being set to an empty string


Fixes for cognitive services; Fixed issue #6054; Private virtual methods should be included in ApiView

Fixes #6054

Ping :).


Major Component selection / material being used.

Decide what material should be used as prototype and then decide for final product.

We already have a similar issue


Unify and Automate maintenance of multiple logging targets

This PR is to automate the creation of specific images for multiple logging targets.
Each target may have different Dockerfile, fluent.conf or plugins requirements.
Plugins may be added as gem install instructions in the Dockerfile, or provided as
ruby file in the respective plugins folder.
The aproach is copied from the fluentd/fluentd-docker-image repository, using
a  modified Makefile and Ruby templates.
Checklist:

[x] Create directory structure for multiple logging targets
[x] Create Dockerfile template for sample logging targets
[x] Create fluent.conf template for sample logging targets
[ ] Create Automated Docker hub repo for this repository
[ ] Create Tests to validate generated docker images
[ ] Create Travis pipeline to run Tests
[x] Add Documentation on available tags and maintenance

I suggest to use the image name fluent/fluentd-kubernetes, Please advise.

@tyranron I love your Makefile, please help review this PR
@edsiper as discussed yesterday.

PS: I'm not using -onbuild, so I can remove the dummy fluent.conf that was at the root of the docker-image folder, I do however have to add the command to copy the plugins from the plugin folder.
This causes .gitkeep to be copied into the plugins folder as well, I haven't tested if this causes an error or not.

If you would like to test the images built by this script, I have pushed them all here:
https://hub.docker.com/r/so0k/fluentd-kubernetes/tags/

.dockerignore may be your friend for the gitkeep.

I thought about adding .dockerignore but... I was worried about another make target & template to worry about... but I think this can just be a simple copy everywhere thing.

Done, dockerignore added which will ignore .gitkeep at any level

Added cloudwatch based on @icereval's work:

https://github.com/kubernetes/charts/pull/211
https://github.com/18F/cg-deploy-kubernetes/tree/master/images/fluentd-cloudwatch

@c-knowles - what does the stackdriver setup look like?

@repeatedly - can you please advise on what is missing to get this merged?

@so0k looking good! Stackdriver setup is very similar to your work. It adds fluent-plugin-google-cloud gem as per the gcp contrib image and then the outputs taken from k8s addons. Judging from the work that's gone on there recently it looks like stackdriver team will take ownership of that image.
My implementation is a sort of merge of the work there and here. For example they don't have the kubernetes custom parser. I'm running it outside of GCP with no stackdriver agent present so I also need to add credentials in. There are a few other useful bits contained there which we don't have here, either we could attempt to add those here or get the basics in and I can submit another PR once this one is done.

I think a 2nd PR from you once this is merged is the best way forward.. may take a while though
I also wonder if it's ok to merge this without the automated testing at first..

@frsyuki - need review and advise on how to get this merged

@c-knowles - if you want to add your changes you can add it to https://github.com/honestbee/fluentd-kubernetes, I'll cherry pick to this branch
I set up the fully automated docker build: https://hub.docker.com/r/honestbee/fluentd-kubernetes/

fyi: I will make sure to review this today

any update?

Based on comments in https://github.com/fluent/fluentd-kubernetes-daemonset/issues/6 I'm no longer sure there is a want to have Stackdriver/GCP logging added. The one thing I would add is that the official image is tailored a bit more towards those running on GCP whereas we're running on AWS. Plus they don't even add some things like the Kubernetes metadata filter which seems almost essential here. Maybe they will make it more agnostic but in the meantime I wouldn't mind adding support. @edsiper @so0k any particular thoughts?

@c-knowles I'm not at all familiar with the stackdriver logging and if anyone else is using it while not on GCP, although it might be good for anyone if you are willing to add your work into this central location so anyone can built on top of it?

@c-knowles
My general perception when talking with different people from different organizations, is that Kubernetes metadata is a fundamental piece for them, not just Google.
Anyways I would like to hear more about more if the filter is generating some issues, so we can consider a way to disable it in the templates generation.

Right now the metadata gem is in a shared gems folder so it's included for all builds and it shouldn't be hard to make exceptions to that rule
However I don't think that is what @c-knowles means as he said k8s metadata gem is essential to a fluent shipping container actually

you are right, I misunderstood.

@edsniper, yes sorry if my comment was confusing. I meant the official image does not container the k8s metadata filter but from what I have seen it is pretty much essential. It is one reason to consider a stackdriver build here as well.
Sounds like we're good to add it then, will submit a PR.


added serialport library as a dependency

When trying to use the serial port accessory:
Loading 0 platforms...
Loading 1 accessories...
module.js:338
throw err;
^
Error: Cannot find module 'serialport'
at Function.Module._resolveFilename (module.js:336:15)
at Function.Module._load (module.js:286:25)
at Module.require (module.js:365:17)
at require (module.js:384:17)
at Object. (/Users/mifi/Desktop/homebridge/accessories/GenericRS232Device.js:3:18)
at Module._compile (module.js:434:26)
at Object.Module._extensions..js (module.js:452:10)
at Module.load (module.js:355:32)
at Function.Module._load (module.js:310:12)
at Module.require (module.js:365:17)
added serialport library as a dependency

This dependency was removed because it didn't support the new NodeJS version 4.x. Has it been updated? See #183 for some discussion.

Ohh. Well I'm using node v4.1.1 on OSX and can confirm it's working. Don't know about raspberry pi

Looks like they fixed the issue: https://github.com/voodootikigod/node-serialport/issues/578
Let's give this a shot.


Bug affiliated with package-name

Not able to track this one down, there is no error logging on this one that I can find. App exits at launch without notice. changing the package-name fixes it. changing the package name back to a previously 'broken' package name will again keep the app from launching without any error.

This would be broken
{
"name": "app",
"version": "1.0.0",
}
this would not be
{
"name": "app-1",
"version": "1.0.0",
}
changing it back would break again is there some kind of caching going on or something? Ive even tested to see if it was a problem with the npm repository but noting there.

Okay I am closer to solving this one. I have old application updates in the pendingUpdatePath, removing the old files from application support path will fix this. I want to find a way to prevent this from happening if a bad update is published.

This else if is closing the applciation when it belives there is an update in progress
but this isn't always the case. In my case I had published updates that where broken and
somehow ended up in this state indefinitely. I am not entirely sure what the best approach would be from here.
} else if(ctx.updateInProgress) {   // This can happen if the user tries to re-launch the app while an update is   // currently in progress. In that case just close and wait.   process.exit(0); }

Hey, sorry about this. There is a known issue where if the updater crashes for some reason it can leave it in an "inprogress" state and keep looping that way. Its not ideal at all. We've had issues where electron itself can crash in certain cases, most recently there is a problem with allocating Buffers that the updater triggers due to downloading a lot of things at the same time. For reference see:
https://github.com/atom/electron/releases/tag/v0.33.2
So first off make sure you're using version 0.33.2 or greater. Also there is some cacheing that happens in the users appData dir, which should be near the log files. You can try clearing those out. If you are able to give me access to your app code so I can try to reproduce the issue that would help also.
But finally, there needs to be a more robust mechanism for when the update fails. Such that it doesn't get caught in a loop and has a way to basically to a full clean / re-install. I've been working on error reporting and error handling but in the case where the electron process just segfaults and stops suddenly there is not easy solution.
But if you can get me a code sample and I can reproduce it then I can probably try to help you get a simpler fix.

@jaunkst You can email me directly if you want to share code or debug over a screen share session. Just let me know.

@justinmchase thanks for the update. Currently I am just assuming it's all bad and clearing the update cache if the application is started and the file is flagged as inprogress. I think if we could check for another running instance and if the file is in progress then exit and if no instance is running and the file is in progress then assume the data is bad and full install?

Yes exactly. We need a global mutex to do this properly however. Fortunately this feature was just added to electron 5 days ago :)
https://github.com/atom/electron/pull/3145
I may be able to use this to give a much more robust instance management system. The only limitation is that it seems like it will force the app to become single instanced... which frankly isn't that bad.

:+1:
I would be okay with that, why don't we update and emit the INPROGRESS so we can let the developer decide the action to take for multi-instance / single-instance until we can resolve the issue for both scenarios?
command.js
			fs.unlink(pendingUpdatePath, function (err, valid) { 				that.emit('updateInProgress'); 			})
main.js
    updater.on('updateInProgress', function () {        // some more robust action to take depending on my use-case.        app.quit();     })

may want to rename the event though for brevity :)

If the developer uses the single process api we were talking about earlier, then the only time the 'updateInProgress' event would fire would be in the case where there was a problem and the updater exited unexpectedly.
I also need to cover the case where the update fails, and just launches the app as is, instead of getting caught in a loop of constantly trying to update.

any thoughts on handling when the update fails ?

There's a pull request for you to take a look at.
https://github.com/EvolveLabs/electron-updater/pull/36

Fixed by #36


v1.2 bugfixes

[x] ci build is broken
[ ] coin outputs not always marked as spent in a multi-transaction block
[x] Forking fails if the blockstake output used for block creation is defined in the fork to switch to
[ ] add timestamp and transaction order for explorer transaction
[ ] Unencrypted wallets block api registration on startup
[x] Consensus set hangs when closing
[x] 1 of 3 block creators for goldchain is incomplete
[x] Check for block creation transactions fails in case of a fork

Going to close this issue and remove it form the project. As discussed a couple of weeks ago, we do not require this kind of aggregation issue. It created extra burden on the developers by needing to maintain this extra list of project-related issues, while it does not add anything extra (given that for a project you can already filter on labels, e.g. type_bug).


Often get waitpid() -1 in CI

We often get an error like the following in the CI, which is kind of annoying because it makes tests to fail randomly. Rerunning the job does fix it. So it may be a race condition?
Error: Error: waitpid(), code: -1, description: Unknown error -1
OSSUnixSystemAccessor(Object)>>error:
OSSUnixSystemAccessor>>strerror:message:
[ returnValue := self
	primitiveWaitpid: childPidInteger
	statusPointer: statusPointer
	options: WNOHANG.
returnValue = -1
	ifTrue: [ self strerror: returnValue message: 'waitpid()' ].
returnValue = 0
	ifTrue: [ ^ nil ].	"If waitpid() was invoked with WNOHANG set in options, it has at least one child process specified by pid for which status is not available, and status is not available for any process specified by pid, 0 is returned.
		That means...status is not available for childPidInteger..probably hasn't finished yet."
returnValue = childPidInteger
	ifTrue:
		[ "If wait() or waitpid() returns because the status of a child process is available, these functions shall return a value equal to the process ID of the child process for which status is reported.
			This means...status is available. It has finished. "
		answer := statusPointer platformLongAt: 1.
		^ answer ] ] in OSSUnixSystemAccessor>>waitpidNoHang:
BlockClosure>>ensure:

Well, we have found a solution for this. There are two main reasons for this issue:

There are potential race conditions in the callers of waitpidNoHang:. This method calls the function waitpid which in turn will wait for the finished child and unregister it from the child table in the OS process. This means that we cannot call twice waitpid for the same process, what would generate an error.
waitpid man's page is ambiguous with respect of the usage of the WNOHANG option. Our finally hypothesis (confirmed by the code and the tests) is that waitpid ignores the first argument if WNOHANG is specified, and returns with ANY child process id. This means that, in combination with the previous issue, it may happen that calling waitpid for process X will unregister process Y, what will make fail a subsequent call to waitpid from Y.

Wow. Great catch @guillep. Excellent!!!
But I have a doubt. It's likely the "parent" process is the VM process, right? Imagine I do use WNOHANG.  So each OSSUnixSubprocess finishedChildProcesses dictionary may be holding results of other OSSUnixSubprocess instances? (note that variable is instanceSide, not classSide).
If that's true then that won't work I think


[AzureMonitorExporter] fix test dependency

Fixes #33403
Changes

add dependency Microsoft.AspNetCore.Mvc.Testing for net7.0
remove dependency Microsoft.AspNetCore.Mvc.Testing for netcoreapp3.1
enable skipped tests (disabled in #32814)

API change check
API changes are not detected in this pull request.


Fix search functionality from a tag list page.

When you search from the tag list page.

Need to create a separate page that search redirects to. (ex should search through all posts, then show results on separate page)


Espressif-IDE JTAG debugging (no device found) (IDFGH-8618)

Answers checklist.

[X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
[X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report
Hello. I have purchased ESP32-S3 Devkit (https://docs.espressif.com/projects/esp-idf/en/latest/esp32s3/hw-reference/esp32s3/user-guide-devkitc-1.html ) and I am trying to setup debugging.
I have setup Espressif-IDE and read some instructions on the internet (it seemed quite simple on how to get it debugger running).
I have imported a "hello_world" project, created a new Configuration:
Most settings were auto filled so I left them as it is just for now.

I plug the micro USB cable to USB port (not the UART since I want to use built in JTAG debugger on the ESP32-S3)
When I try to start debugging session, I get the following error:
Open On-Chip Debugger  v0.11.0-esp32-20211220 (2021-12-20-15:43)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
adapter speed: 20000 kHz

Flashing C:/Espressif/frameworks/esp-idf-v4.4.2/workspace/hello_world/build/partition_table/partition-table.bin at 0x8000
Error: no device found
Error: unable to open ftdi device with vid 0403, pid 6010, description '*', serial '*' at bus location '*'
Error: no device found
Error: unable to open ftdi device with vid 0403, pid 6014, description '*', serial '*' at bus location '*'
** OpenOCD init failed **
shutdown command invoked
** Flashing Failed **
-1
Started by GNU MCU Eclipse
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Assertion failed!

Program: C:\Espressif\tools\openocd-esp32\v0.11.0-esp32-20211220\openocd-esp32\bin\openocd.exe
File: ../src/jtag/core.c, Line 343

Expression: jtag_trst == 0

What I think might be wrong:
I have a feeling that the issue might be due to my Debugger configration.
The selected Board is :
ESP32-S3 chip (via ESP-PROG)

but I dont think that is correct since I do not use ESP-PROG board. I know that the ESP32-S3 have built in jtag debugging capabilites and should not need ESP-PROG.
I read that here:
https://docs.espressif.com/projects/esp-idf/en/latest/esp32s3/api-guides/jtag-debugging/index.html#jtag-debugging-configuring-target
In my Config options, the following options are set:
-s ${openocd_path}/share/openocd/scripts -f interface/ftdi/esp32_devkitj_v1.cfg -f target/esp32s3.cfg

I also think the above is not correct. Documentation ( https://docs.espressif.com/projects/esp-idf/en/latest/esp32s3/api-guides/jtag-debugging/index.html#jtag-debugging-configuring-target ) suggests to set the target to:
openocd -f board/esp32s3-builtin.cfg

hence I have changed my Config options to :
-s ${openocd_path}/share/openocd/scripts -f interface/ftdi/esp32_devkitj_v1.cfg -f board/esp32s3-builtin.cfg

Trying to debug with updated config option I get different error:
Open On-Chip Debugger  v0.11.0-esp32-20211220 (2021-12-20-15:43)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
adapter speed: 20000 kHz

Warn : Interface already configured, ignoring
C:\Espressif\tools\openocd-esp32\v0.11.0-esp32-20211220\openocd-esp32\share\openocd\scripts/interface/esp_usb_jtag.cfg:7: Error: invalid command name "espusbjtag"
in procedure 'script'
at file "embedded:startup.tcl", line 26
at file "C:\Espressif\tools\openocd-esp32\v0.11.0-esp32-20211220\openocd-esp32\share\openocd\scripts/board/esp32s3-builtin.cfg", line 9
at file "C:\Espressif\tools\openocd-esp32\v0.11.0-esp32-20211220\openocd-esp32\share\openocd\scripts/interface/esp_usb_jtag.cfg", line 7

Could someone point me in the right direction and help me understand how to setup debugging for the ESP32-S3 devkit?

UPDATE
I have solved the issue by changing the Config options:
-s ${openocd_path}/share/openocd/scripts -f interface/esp_usb_jtag.cfg -f board/esp32s3-builtin.cfg

I must selected the esp_usb_jtag.cfg and esp32s3-builtin.cfg . The dafault settings assume you are using ESP-PROG

@krupis did you reboot the module? is there any sequence on rebooting?

@krupis did you reboot the module? is there any sequence on rebooting?

Hey. Are you having issues yourself or trying to help me ? :) Since I have already solved this issue, I assume you are having some issues?


Update GA4 Web docs

Proposed changes

add clarity around "Order Completed" event
clarify that customers will need to add the "Purchase" action to their mappings in order for Segment to map "Order Completed" to GA4's "Purchase" event

Merge timing

ASAP once approved

closing as this has no changes now.


MediaPlayer Notification largeIcon Low Resolution on Android API 33

1 - Describe the bug
The largeIcon used in the notification on Android API level 33 appears with very low resolution. This is when the notificationLayout is MediaPlayer.
2 - Provide us as much information as possible
I've tried with the largeIcon being a Network, File, and Resource media source type and the image appears equally low-quality on all methods.
Additionally, this doesn't seem to be an issue on lower versions of Android.

To help us to understand your issue, provide with your bug report all the relevant informations, such as:

Your plugins list inside the file pubspec.yaml (at least all notification plugins)
I'm not using any other notification plugins

What platform did you found the issue
Android API level 33

What devices did you found the issue
Google Pixel 5

How are you creating the notification

      NotificationContent(
        id: MEDIA_NOTIFICATION_ID,
        channelKey: NotificationChannels.MEDIA.channelKey!,
        title: title,
        body: body,
        notificationLayout: NotificationLayout.MediaPlayer,
        locked: true,
        largeIcon: backgroundImageUrl,
        category: NotificationCategory.Transport,
      );

3 - How To Reproduce the Error
Steps to reproduce the behavior:

Display a MediaPlayer notification with a largeIcon set on it on Android API level 33.
Notice the image appears very low-resolution, even if the image is large / high-quality.

4 - Expected behavior
The image appears high-quality
5 - Screenshots
Not needed.
6 - Additional context
Not needed.

I couldn't reproduce this error. Can you take a print screen of this issue and send me your notification creation method?

Here it is on API 32 (good):

And here it is on API 33 (bad):

Creating the notification:
      NotificationContent(
        id: MEDIA_NOTIFICATION_ID,
        channelKey: NotificationChannels.MEDIA_CHANNEL_KEY,
        title: 'Test title',
        body: 'Test body',
        notificationLayout: NotificationLayout.MediaPlayer,
        autoDismissible: false,
        largeIcon: 'resource://drawable/test',
        category: NotificationCategory.Transport,
        locked: true,
      );

And then I'm just calling createNotification with that.

I'm trying to find an Android 13 device to test it out. I'll post my tests here soon. But for now, you can try using asset images instead of native resources.

@praxder praxder Did you get any solution for the issue? if yes can you explain? i also having the same problem.

We've had enough issues with awesome_notifications that we pivoted away from using it.


@tf.function in TF2.x

Where is tf.function defined?
Where can I see its implementation?
How can it be invoked (as a decorator) when we compile the model using TF.Keras?

@Alok-Ranjan23

& 2) Please refer to this link for the function details.
When you compile a keras model it is invoked internally until and unless you specify the run_eagerly argument to be true.

For any further queries on this kindly open a stackoverflow issue for this as it is not a bug or feature request, Please post this kind of support questions at Stackoverflow. There is a big community to support and learn from your questions.
Thanks!


adding systemtest for new router policy feature

Signed-off-by: Jan Kalinic<EMAIL_ADDRESS>Type of change
adding systemtest for a new feature

Update/write design documentation in ./documentation/design
Write tests and make sure they pass
Update documentation
Check RBAC rights for Kubernetes / OpenShift roles
Try your changes from Pod inside your Kubernetes and OpenShift cluster, not just locally
Reference relevant issue(s) and close them after merging
Update CHANGELOG.md

@enmasse-ci run tests testcase=InfraTestStandard#testRouterMaxMessageSize test_only


Add new FAQ - "What happens to my money if Opire disappears?"

Context
We've seen some code owners having concerns about using Opire due to bad experiences with others platforms that offered similar services than us.
For example, other platforms stole funds and closed after that, making the affected code owners distrustful about installing Opire.
Proposal
Opire works in a way that will make it impossible for users to lose money even if the project disappears, but we don't talk about it anywhere. We should include at least a new FAQ entry to talk about it and clear up doubts.

This repo is using Opire - what does it means? 👇💸Everyone can add rewards for this issue commenting /reward 100 (replace 100 with the amount)💪 If someone starts working on this issue to earn the rewards, they can comment /try to let everyone know!🙌 And when they open the PR, they can comment /claim #5 either in the PR description or in a PR's comment👀 Also, everyone can tip any user commenting /tip 20 @RubenRuCh (replace 20 with the amount, and @RubenRuCh with the user to tip)If you want to learn more, go to our documentation

/reward 20

/try

/try

/try

/try

/try

/tip 1 @RubenRuCh


[stable/prometheus-adapter] Enhancements

What this PR does / why we need it:
Ports my changes from closed PR to stable/prometheus-adapter.

Add readiness and liveness probes
Adds ability to disable default rules and add custom rules
Adds affinity, nodeSelector, tolerations
Adds a NOTES.txt and .helmignore per standard
Adds securityContext to reduce pod permissions
Adds ability to customize service values
Fixes fullnameOverride
Reduces logLevel as it was way too verbose.
Minor cleanup to sort values in README and in values.yaml and fix typos

Which issue this PR fixes : N/A
Special notes for your reviewer:
@mattiasgees

/assign @unguiculus

/ok-to-test

/lgtm

@kevtaylor Yes, it works for me. You're right that it should be labels and not label. I'm guessing it depends on Helm and Kubernetes version whether it ignores that or errors. I did not write the original chart that added that though. You're welcome to submit a PR to address it.

@steven-sheehy Will do. Thanks


Update tests.yml for Azure Pipelines

API change check
API changes are not detected in this pull request.


Add https support

Added https support
Added unit tests
Refactored existing files to facilitate unit tests

@psycofdj changes implemented.


Pods not installing this library

Hi I am getting this error while installing through pods, this suddenly stopped. Can you please help as this app is in Appstore now and have to release the update.
[!] /usr/bin/git clone https://github.com/CodeEagle/LNNotificationsUI.git /var/folders/hv/xz_d5sf534s2t3c_xb2fx_4h0000gn/T/d20160316-6150-1kzwn8e --single-branch --depth 1 --branch 0.0.1
Cloning into '/var/folders/hv/xz_d5sf534s2t3c_xb2fx_4h0000gn/T/d20160316-6150-1kzwn8e'...
remote: Repository not found.
fatal: repository 'https://github.com/CodeEagle/LNNotificationsUI.git/' not found

Ok i installed it using this reference link 'https://github.com/LeoNatan/LNNotificationsUI/issues/18'
By solution given by ironseb
pod 'LNNotificationsUI', :git => "https://github.com/LeoNatan/LNNotificationsUI.git"
Can you confirm if this is okay :)

Hi,
CocoaPods is not supported. So I cannot comment if correct because I am not familiar with CocoaPods.
Consider using Carthage.


Override the toString method in data classes in turms-client-js

JSON.stringify() should be good enough.


⚠ DSO-API has degraded performance

In cf7731b, DSO-API ($SITE_URL_DSOAPI) experienced degraded performance:

HTTP code: 200
Response time: 9267 ms

Resolved: DSO-API performance has improved in 7ae7631 after 6 minutes.


[WIP]AC: support prediction to annotation conversion

@eaidova If everything is okay, could you please merge it?

@vladimir-dudnik could you please approve?

@eaidova is it still WIP?

is it still WIP?

already not WIP :)


(refactor) make the experiment logs more meaningful

Signed-off-by: ksatchit<EMAIL_ADDRESS>
What this PR does / why we need it:

Improves the ansible logs for experiments to make it more pythonic. Makes following enhancements:

Remove PLAY start/recap to EXPERIMENT
Removes host info & task status (we only use localhost)
Add timestamped task banner (instead of elapsed time) & change prefix from TASK to STEP keeping with intent of the playbook

Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #1031
Checklist

[ ] Does this PR have a corresponding GitHub issue?
[ ] Have you included relevant README for the chaoslib/experiment with details?
[ ] Have you added debug messages where necessary?
[ ] Have you added task comments where necessary?
[ ] Have you tested the changes for possible failure conditions?
[ ] Have you provided the positive & negative test logs for the litmusbook execution?
[ ] Does the litmusbook ensure idempotency of cluster state?, i.e., is cluster restored to original state?
[ ] Have you used non-shell/command modules for Kubernetes tasks?
[ ] Have you (jinja) templatized custom scripts that is run by the litmusbook, if any?
[ ] Have you (jinja) templatized Kubernetes deployment manifests used by the litmusbook, if any?
[ ] Have you reused/created util functions instead of repeating tasks in the litmusbook?
[ ] Do the artifacts follow the appropriate directory structure?
[ ] Have you isolated storage (eg: OpenEBS) specific implementations, checks?
[ ] Have you isolated platform (eg: baremetal kubeadm/openshift/aws/gcloud) specific implementations, checks?
[ ] Are the ansible facts well defined? Is the scope explicitly set for playbook & included utils?
[ ] Have you ensured minimum/careful usage of shell utilities (awk, grep, sed, cut, xargs etc.,)?
[ ] Can the limtusbook be executed both from within & outside a container (configurable paths, no hardcode)?
[ ] Can you suggest the minimal resource requirements for the litmusbook execution?
[ ] Does the litmusbook job artifact carry comments/default options/range for the ENV tunables?
[ ] Has the litmusbooks been linted?

Special notes for your reviewer:

As discussed with @nsathyaseelan , adopting these changes would need us to :

Use derived facts in task banners to let us know the values (the values wont be indicated by default unless verbose options are provided)
Use appropriate fail conditions on tasks to avoid "difficult-to-trace" errors which may prompt re-runs w/ verbose enabled.

Ex: Logs (w/ a failure):
2020-01-02 16:20:29.742176 ************ BRACE YOURSELF, EXPERIMENT BEGINS! ************

2020-01-02 16:20:35.611786 Step: Gathering Facts

2020-01-02 16:20:35.973729 Step: Identify the chaos util to be invoked

2020-01-02 16:20:36.009072 Step: include_vars

2020-01-02 16:20:36.052815 Step: Construct chaos result name (experiment_name)
included: /utils/runtime/update_chaos_result_resource.yml for <IP_ADDRESS>

2020-01-02 16:20:36.310008 Step: Generate the chaos result CR to reflect SOT (Start of Test)

2020-01-02 16:20:37.684443 Step: Apply the chaos result CR
included: /utils/common/status_app_pod.yml for <IP_ADDRESS>

2020-01-02 16:20:38.534299 Step: Checking whether application pods are in running state

2020-01-02 16:20:39.285647 Step: Get the container status of application.
included: /chaoslib/powerfulseal/pod_failure_by_powerfulseal.yml for <IP_ADDRESS>

2020-01-02 16:20:39.577773 Step: Generate the powerfulseal deployment spec from template

2020-01-02 16:20:40.505129 Step: Setup powerfulseal to initiate random pod chaos

fatal: [<IP_ADDRESS>]: FAILED! => {"changed": true, "cmd": "kubectl apply -f powerfulseal.yml -n default", "delta": "0:00:00.769650", "end": "2020-01-02 16:20:40.485634", "failed_when_result": true, "msg": "non-zero return code", "rc": 1, "start": "2020-01-02 16:20:39.715984", "stderr": "error: unable to recognize \"powerfulseal.yml\": no matches for kind \"Deployment\" in version \"apps/v1beta1\"", "stderr_lines": ["error: unable to recognize \"powerfulseal.yml\": no matches for kind \"Deployment\" in version \"apps/v1beta1\""], "stdout": "configmap/policy unchanged", "stdout_lines": ["configmap/policy unchanged"]}

2020-01-02 16:20:40.544636 Step: set_fact
included: /utils/runtime/update_chaos_result_resource.yml for <IP_ADDRESS>

2020-01-02 16:20:41.357351 Step: Update the chaos result CR to reflect EOT (End of Test)

2020-01-02 16:20:42.141086 Step: Apply the chaos result CR

2020-01-02 16:20:42.143455 ************ RELAX, EXPERIMENT BEGINS! ************