RBE: sh_test test script for should be prefixed with ./

Setup a simple sh_test like this
sh_test(
    name = "test",
    test = "test.sh",
    args = ["$(location :xyz)", XYZ_SHA256],
)

And try to run it against BuildBuddy RBE and we would get this error
> buck2 test --unstable-allow-all-tests-on-re :test
✗ Fail: root//:test (0.0s)
---- STDOUT ----

---- STDERR ----
Remote Execution Error (GRPC-SESSION-ID)

Caused by:
    0: RE: execution with digest 62cfd1c66c57c0bf30244ff00330e8b66b16fea36157863f068beed06232fe9f:142
    1: Error was returned on the stream by RE
    2: exec: "test.sh": executable file not found in $PATH
Build ID: 2561efc4-7feb-4dfd-afb6-ce0907d9df05
RE: GRPC-SESSION-ID
Jobs completed: 3. Time elapsed: 1.1s.
Tests finished: Pass 0. Fail 1. Fatal 0. Skip 0. Build failure 0
1 TESTS FAILED
  ✗ root//:test
exit 32

Inspecting the Command proto gave me something like this
{
  "arguments":  [
    "test.sh",
    "buck-out/v2/gen/root/213ed1b7ab869379/__xyz__/out/xyz.txt",
    "72036ae48c55d632cc333cac04c78be336b0c76f39b225d023e218efe077ab1b"
  ],
  "platform":  {
    "properties":  [
      {
        "name":  "OSFamily",
        "value":  "Linux"
      },
      {
        "name":  "container-image",
        "value":  "docker://gcr.io/flame-public/rbe-ubuntu20-04:latest"
      },
      {
        "name":  "recycle-runner",
        "value":  "true"
      },
      {
        "name":  "workload-isolation-type",
        "value":  "firecracker"
      }
    ]
  }
}

So the shell session thought test.sh to be a binary in $PATH and tried to find it, but couldn't.
Dirty patching prelude with this allowed the test to pass on RBE:
prelude> git diff
diff --git a/sh_test.bzl b/sh_test.bzl
index cec8c21..f17bbda 100644
--- a/sh_test.bzl
+++ b/sh_test.bzl
@@ -18,7 +18,7 @@ def sh_test_impl(ctx: "context") -> ["provider"]:

     if ctx.attrs.test != None:
         if type(ctx.attrs.test) == "artifact":
-            args.add(ctx.attrs.test)
+            args.add(cmd_args(["./", ctx.attrs.test], delimiter = ""))
         elif type(ctx.attrs.test) == "dependency":
             run_info = ctx.attrs.test.get(RunInfo)
             if run_info != None:

Test result
> buck2 test --unstable-allow-all-tests-on-re :test
File changed: root//
File changed: root//.watchman-cookie-Sons-Laptop.local-906-1241
File changed: prelude//sh_test.bzl
6 additional file change events
run_from_project_root: False
✓ Pass: root//:test (4.1s)
---- STDOUT ----

---- STDERR ----

Build ID: 6a77c261-a327-4c97-8759-a02ea6a165ed
RE: GRPC-SESSION-ID
Jobs completed: 12 K. Time elapsed: 6.5s. Cache hits: 100%. Commands: 3001 (cached: 3001, remote: 0, local: 0)
Tests finished: Pass 1. Fail 0. Fatal 0. Skip 0. Build failure 0

That sounds reasonable, did you want to send a PR?

I was not sure about what would be the right solution for this problem.
Adding a ./ prefix in starlark code fixed it for me, but that's probably the wrong solution for windows users 🤔. I was also wondering if there is a more generic solution inside the cmd_args implementation when printing out an artifact input.
If you are happy with the change as-is, let me create a PR 👍

Ultimately, I think what I am looking for is a set of tests to run against to quickly validate changes like this.

Yeah, a more principled fix may be for us to render paths to artifacts with
no leading slashes as ./artifact, assuming unix paths (that information is
available when rendering paths).
That’s probably easier than this, I can take a look unless you’d like to.
I’m not at a computer right now, resolve_source might be a good keyword to
get started with
On Mon, 15 May 2023 at 21:07, Son Luong Ngoc @.***>
wrote:

I was not sure about what would be the right solution for this problem.
Adding a ./ prefix in starlark code fixed it for me, but that's probably
the wrong solution for windows users 🤔. I was also wondering if there is
a more generic solution inside the cmd_args implementation when printing
out an artifact input.
If you are happy with the change as-is, let me create a PR 👍
—
Reply to this email directly, view it on GitHub
https://github.com/facebook/buck2/issues/255#issuecomment-1548414455,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AANIHVRQEWB6GRSW6AVPTS3XGJ5G5ANCNFSM6AAAAAAYAR37GY
.
You are receiving this because you commented.Message ID:
@.***>

It's bedtime for me in EU but I will take a look if I have the time tomorrow 👀
If anyone else is interested, feel free to beat me to it 🤗

I don't think this was fixed.
I still have to apply the same workaround today otherwise my remote executor will complain
✗ Fail: root//:test (0.5s)
---- STDOUT ----

---- STDERR ----
Error: runc: runc create failed: unable to start container process: exec: "./<source test.sh>": stat ./<source test.sh>: no such file or directory: OCI runtime attempted to invoke a command that was not found

Referencing RE API https://github.com/bazelbuild/remote-apis/blob/eafa1b0d7883ffef6520cfd5fd5ff7731b7d55d7/build/bazel/remote/execution/v2/remote_execution.proto#L558-L573, I think it's reasonable to expect ./ to signal to remote executor that we are using relative path here and are not looking up test.sh in $PATH.
It would be nice if you folks could publish your tests for prelude, that way I could help add a test to verify the RE API request.

Yeah, that makes sense, that change was only for local, I'm not sure what I was thinking.
I'll put up a fix.


build  error

when i try build via xcode. i getting below error code ?
/Users/xxx/Documents/mergen/mergen.xcodeproj One of the paths in DEVELOPMENT_ASSET_PATHS does not exist: /Users/xxx/Documents/mergen/mergen/Preview
is this normal ?

Ensure that the 'Preview' directory and the 'Preview Contents' directories exist. If they don't, create them.

@jansuz, worked for me. @sametsazak could you just add this hint inside the Readme.md? From my perspective a lot of people using this application do not handle X-Code projects normally. And props for the tool - helped me a lot 👍

@jansuz thank you. I forgot to add 'Preview' and the 'Preview Contents' directories. Fixing soon.

Done.


CORS issue when sending from FrontEnd application to OpenTelmetryCollector via Treafik Ingress

What happened?
Steps to Reproduce
instrument.ts code:
import { WebTracerProvider } from '@opentelemetry/sdk-trace-web';
import { getWebAutoInstrumentations } from '@opentelemetry/auto-instrumentations-web';
import { CompositePropagator, W3CBaggagePropagator, W3CTraceContextPropagator } from '@opentelemetry/core';
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http';
import { BatchSpanProcessor } from '@opentelemetry/sdk-trace-base';
import { registerInstrumentations } from '@opentelemetry/instrumentation';
import { ZoneContextManager } from '@opentelemetry/context-zone';
const { Resource } = require('@opentelemetry/resources');
const { SemanticResourceAttributes } = require('@opentelemetry/semantic-conventions');

const exporter = new OTLPTraceExporter({
    url: "https://optel-collector-test.apps-test.com/v1/traces",
    headers: {
    'Content-Type': 'application/json',
    }
});
const provider = new WebTracerProvider({
    resource: new Resource({
        [SemanticResourceAttributes.SERVICE_NAME]: 'front-end-recipe-instrut',
    }),
});
provider.addSpanProcessor(new BatchSpanProcessor(exporter));
provider.register({
    contextManager: new ZoneContextManager(),
    propagator: new CompositePropagator({
        propagators: [new W3CBaggagePropagator(), new W3CTraceContextPropagator()],
    }),
});

const api = require("@opentelemetry/api");
function runQuery() {
    let tracer = api.trace.getTracer("my-tracer");
    let span = tracer.startSpan("expensive-query");
    // ... do cool stuff
    span.end();
}

registerInstrumentations({
    instrumentations: [
        getWebAutoInstrumentations({
            // load custom configuration for xml-http-request instrumentation
            '@opentelemetry/instrumentation-xml-http-request': {
                propagateTraceHeaderCorsUrls: [
                    /.+/g,
                ],
            },
            // load custom configuration for fetch instrumentation
            '@opentelemetry/instrumentation-fetch': {
                propagateTraceHeaderCorsUrls: [
                    /.+/g,
                ],
            },
        }),
    ],
});

collector
spec:
  config: |
    receivers:
      otlp:
        protocols:
          grpc:
          http:
            include_metadata: true
            endpoint: "<IP_ADDRESS>:4318"
            cors:
              allowed_origins: ["*"]
              allowed_headers: ["*"]
              max_age: 7200

Curl works as expected - returns 200
curl -i -X OPTIONS https://optel-collector-test.apps-test.com/v1/traces -X POST --header 'Content-Type: application/json'  -d @span-new.json

HTTP/2 200
content-length: 21
content-type: application/json
date: Fri, 12 May 2023 16:48:21 GMT
access-control-allow-headers: true
access-control-allow-origin: *
strict-transport-security: max-age=86400
{"partialSuccess":{}}

Expected Result
Data is sent to Collector
Actual Result
CORS error as per screen shot

Additional Details
As per screen shot OPTIONS method is sent before POST request and fails with a CORS error.
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://optel-collector-test.apps-nonprod.tnt.com/v1/traces. (Reason: header ‘content-type’ is not allowed according to header ‘Access-Control-Allow-Headers’ from CORS preflight response)

How ideas can we prevent this from happening?
OpenTelemetry Setup Code
No response
package.json
No response
Relevant log output
No response

I think this might be better suited to an issue on collector repo... but you should be able to remove the allowed_headers: block entirely because Content-Type is on the default safelist.
Also FWIW, I've generally seen more reliable behavior when adjusting the allowed_origins slightly to include the http protocols, like this:
      http:
        include_metadata: true
        endpoint: "<IP_ADDRESS>:4318"
        cors:
          allowed_origins:
            - http://*
            - https://*

Hi, thanks will do. Just in the process of debugging but using Istio as ingress works as expected but using Traefik fails with the Cors errors. Seems to be if Origin header does not match anything in allowed_origins, you will get no CORS in return from backend Otel collector.


feat: Follow up on the GPT-1106 version

Checklist

[X] I believe the idea is awesome and would benefit the framework
[X] I have searched in the issue tracker for similar requests, including closed ones

Detailed Description

https://platform.openai.com/docs/guides/text-generation

新增字段
response_format, seed, ...
受影响模块

[x] Log模块
[x] Cache模块

done.


Change the depth equal to the shallow equal

Coverage decreased (-0.3%) to 84.155% when pulling b3d629da58413ea8ce63b211a39308605281cc8a on dev into 5eff27205f7fbe6337cfc35dbbf74694b6a4d737 on master.


ACM-15320 Remove hard coded local-cluster from App UI

https://issues.redhat.com/browse/ACM-15320

Remove hard coded local-cluster through out the code. Find the hub cluster by looking for the label local-cluster: true
Removed layouts.js - code no longer used, replaced by PatternFly topology
Removed DiagramViewer.js - code no longer used, replaced by PatternFly topology
Removed status.js - code no longer used, replaced by PatternFly topology
Removed application-queries.ts - code no longer used, replaced by App table performance work?
diagram-helpers-argo.js - removed function showArgoApplicationSetLink() as it's no longer used
search.ts - removed functions getRemoteArgoFilters(), queryRemoteArgoApps() as it's no longer used
diagram-helpers.js - removed function createDeployableYamlLink() as it's no longer used
filtering.js - removed funtions filterNodes(), filterRelationshipNodes() as it's no longer used

@KevinFCormier can you review again? Thanks!

/lgtm


Restore rancher from single docker, can not connect with gitlab: net/http: TLS handshake timeout

What kind of request is this (question/bug/enhancement/feature request):
when restore rancher,I need to set rancher with a new domain name
Steps to reproduce (least amount of steps as possible):
Backups and restoration ,Reference documents:
https://docs.rancher.cn/docs/rancher2/backups/restorations/single-node-restoration/_index
Result:
all things is ok,etcd data is ok
but can not connect with gitlab,and can not git pull code and build
Other details that may be helpful:
Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI):
2.3.2
Installation option (single install/HA):
single
docker logs -f container_name

- errors:
2020/11/18 14:17:55 [ERROR] Unknown error: Get https://git.xxxxxxx.com/api/v4/projects/k8s-java%!F(MISSING)ycf-privilege%!F(MISSING)privilege-web/repository/branches?per_page=100: net/http: TLS handshake timeout

output:

Docker version (use docker version):

Client: Docker Engine - Community
 Version:           19.03.13
 API version:       1.40
 Go version:        go1.13.15
 Git commit:        4484c46d9d
 Built:             Wed Sep 16 17:03:45 2020
 OS/Arch:           linux/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.13
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.13.15
  Git commit:       4484c46d9d
  Built:            Wed Sep 16 17:02:21 2020
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.3.7
  GitCommit:        8fba4e9a7d01810a393d5d25a3621dc101981175
 runc:
  Version:          1.0.0-rc10
  GitCommit:        dc9208a3303feef5b3839f4323d9beb36df0a9dd
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

close it, fixed it. is not rancher's bug.
we change  linux kernel version 4.19 => 3.10, it's ok!


kube-state-metrics timing out with agent v6.1.0-6.1.4 / v5.23.0

We've just switched from agent v5 using our own YAML to v6.1.0 using the Helm chart and we appear to have hit the same problem as https://github.com/kubernetes/charts/issues/1466. We deploy kube-state-metrics separately rather than bundle it as a helm dependency. For that we're on 1.2.0.
After the upgrade, most things are working ok but kube state metrics are not coming through any more when non of the rest of the system has changed.
This is what we see in the logs:
datadog-master-rcd8v datadog [ AGENT ] 2018-04-05 04:33:04 UTC | ERROR | (runner.go:276 in work) | Error running check kubernetes_state: [{"message": "HTTPConnectionPool(host='<IP_ADDRESS>', port=8080): Read timed out. (read timeout=1)", "traceback": "Traceback (most recent call last):\n  File \"/opt/datadog-agent/bin/agent/dist/checks/__init__.py\", line 332, in run\n    self.check(copy.deepcopy(self.instances[0]))\n  File \"/opt/datadog-agent/embedded/lib/python2.7/site-packages/datadog_checks/kubernetes_state/kubernetes_state.py\", line 196, in check\n    self.process(endpoint, send_histograms_buckets=send_buckets, instance=instance)\n  File \"/opt/datadog-agent/embedded/lib/python2.7/site-packages/datadog_checks/checks/prometheus/mixins.py\", line 350, in process\n    for metric in self.scrape_metrics(endpoint):\n  File \"/opt/datadog-agent/embedded/lib/python2.7/site-packages/datadog_checks/checks/prometheus/mixins.py\", line 314, in scrape_metrics\n    response = self.poll(endpoint)\n  File \"/opt/datadog-agent/embedded/lib/python2.7/site-packages/datadog_checks/checks/prometheus/mixins.py\", line 467, in poll\n    response = requests.get(endpoint, headers=headers, stream=True, timeout=1, cert=cert, verify=verify)\n  File \"/opt/datadog-agent/embedded/lib/python2.7/site-packages/requests/api.py\", line 72, in get\n    return request('get', url, params=params, **kwargs)\n  File \"/opt/datadog-agent/embedded/lib/python2.7/site-packages/requests/api.py\", line 58, in request\n    return session.request(method=method, url=url, **kwargs)\n  File \"/opt/datadog-agent/embedded/lib/python2.7/site-packages/requests/sessions.py\", line 508, in request\n    resp = self.send(prep, **send_kwargs)\n  File \"/opt/datadog-agent/embedded/lib/python2.7/site-packages/requests/sessions.py\", line 618, in send\n    r = adapter.send(request, **kwargs)\n  File \"/opt/datadog-agent/embedded/lib/python2.7/site-packages/requests/adapters.py\", line 521, in send\n    raise ReadTimeout(e, request=request)\nReadTimeout: HTTPConnectionPool(host='<IP_ADDRESS>', port=8080): Read timed out. (read timeout=1)\n"}]

I've confirmed <IP_ADDRESS> is the correct pod IP address; as mentioned none of that side of things has changed so the AD seems to still be working.
I went to the datadog pod in question and did a little investigation on the timing:
time curl -v --silent --output /dev/null --show-error --fail <IP_ADDRESS>:8080/metrics

The curl responds fine with content but I've never got it to go below 1 second. However, it appears 1 second is hard coded:
https://github.com/DataDog/integrations-core/blob/69e3a575ff5d9dc62703b9b9f7789d98e91a2ec5/datadog-checks-base/datadog_checks/checks/prometheus/mixins.py#L472
The payload is ~11214 bytes on that cluster. I tried increasing resources to the kube state metrics pod but wasn't able to get it to go any faster - the stats for the kube-state-metrics container show it's not even using close to its allocated cpu/memory.
I'm not sure how best to deal with this, as a start the timeout could be configurable but perhaps there are some overall plans to deal with this in some better way.

Timings from other users in https://github.com/kubernetes/kube-state-metrics/issues/257 appear to indicate up to 10 seconds is not unusual.

@c-knowles Thanks for opening this issue! We will review to increase the value of the timeout here. The details you sent are most helpful in that end.
We will also get back to you on the support case we have in parallel, thanks for your patience again here!

Indeed, this is a regression from 6.0.x:
We used to query the payload with no timeout https://github.com/DataDog/datadog-agent/blob/6.0.x/cmd/agent/dist/checks/prometheus_check/prometheus_check.py#L425
And we introduced a 1 second timeout in 6.1.x: https://github.com/DataDog/integrations-core/blob/master/datadog_checks_base/datadog_checks/checks/prometheus/mixins.py#L476
I'll open a PR to move this timeout up to 10 seconds. Sorry for the inconvenience.

We are seeing this issue on agent v6.1.1

The PR was now merged, so the timeout should be set to 10 seconds in future release 6.1.4

Also ran into this problem when I was using v6.1.3. I just upgraded to the just released v6.1.4 and it seems to still be using the 1 second timeout.
Read timed out. (read timeout=1)

I think 6.1.4 was a security patch release so it was planned for 6.1.4 but didn't make it as the security issue got pushed quicker.

The same applies for agent 5.23.0.
Are you guys backporting the fix to it?

I was having the same issue running with 12.6.5230, downgrading worked for me, thanks @c-knowles. Is there a plan to rollout the fix on 5.x?

Thanks for the inclusion of the 5.22.3 docker tag - I've got an open support issue and they weren't able to tell me which version introduced it so i could pin to work around it.

Is there going to be a 6.1.5 with this fix? Right now the basic "getting started" instructions for kubernetes and docker are broken due to this.

Fixed with dd-agent 5.24.0 (docker tag 12.6.5240).

"fixed" they now occasionally complete within the timeout - HPA monitoring graph between agent 5.22.3 and now "latest" 5.24.0

Hmm, but what about the 6.x line?

Support did provide this as a workaround and it has been successful for me:
# Modifies line 477 increasing the timeout to 20
kubectl exec <dd-agent_podname> -- sed -i '477s/timeout=10/timeout=20/' /opt/datadog-agent/embedded/lib/python2.7/site-packages/datadog_checks/checks/prometheus/mixins.py

# Prints line to verify that the timeout has been changed
kubectl exec <dd-agent_podname> -- sed -n 477p /opt/datadog-agent/embedded/lib/python2.7/site-packages/datadog_checks/checks/prometheus/mixins.py

# For Agent v5: Kills the collector process without restart the container
kubectl exec <dd-agent_podname> -- pkill -TERM -F /opt/datadog-agent/run/dd-agent.pid

# For Agent v5: Trigger Supervisord to reread its configuration thereby restarting the collector process
kubectl exec <dd-agent_podname> -- pkill -HUP -F /opt/datadog-agent/run/datadog-supervisord.pid

# For Agent v6: Restarts the agent without restarting the container
kubectl exec <dd-agent_podname> -- s6-svc -t /var/run/s6/services/agent/

As i run my agents in a daemonset i've added the following to my pod specs to work around this issue.
    spec:
      containers:
      - image: datadog/docker-dd-agent
        name: dd-agent
        lifecycle:
          postStart:
            exec:
              command:
                - "/bin/sh"
                - "-c"
                - >
                  sed -i '477s/timeout=10/timeout=20/' /opt/datadog-agent/embedded/lib/python2.7/site-packages/datadog_checks/checks/prometheus/mixins.py &&
                  pkill -TERM -F /opt/datadog-agent/run/dd-agent.pid;
                  sleep 3;
                  pkill -HUP -F /opt/datadog-agent/run/datadog-supervisord.pid;```

All, I apologize for the delay!
It seems like the agent 6 does not handle the output of kube-state when it's too large (tied to the size of the cluster, the version of kube-state and the metrics available as well).
We are actively investigating this and will keep you updated as soon as we make progress.
Thank you for your patience.

Could we override the timeout ourselves? Previously we could configure kubernetes_state.yaml .instances[].timeout.
I was referred to this PR as a reference. https://github.com/DataDog/integrations-core/pull/1604 How do I use this in my datadog agent?

Configurable timeout being added here https://github.com/DataDog/integrations-core/pull/1790

The prometheus endpoint from the kube-state-metrics pod causes some issues in large clusters.

Sometimes, the issue comes from the time spent when querying the metrics, which cause the current 10 second timeout to exceeded. In that case, the option added in https://github.com/DataDog/integrations-core/pull/1790 should help setting it up higher, once we could release it.
Else, the data fetched from the pod can be to large for the agent to handle, in that case, the timeout is of no use to fix this. Another way though would be by sharding the kube-state-metrics deployment. It can be done specifying in different deployments different namespaces and collectors through these options of the kube-state-metrics app:

      --collectors string                Comma-separated list of collectors to be enabled. Defaults to "cronjobs,daemonsets,deployments,endpoints,horizontalpodautoscalers,jobs,limitranges,namespaces,nodes,persistentvolumeclaims,persistentvolumes,pods,replicasets,replicationcontrollers,resourcequotas,services,statefulsets"
      --namespace string                 namespace to be enabled for collecting resources

This should split the workload across different hosts, and should work better.
Note that this sharding could also help in case of high timeout.
Let us know if that helps. We'll update this issue once we could release the timeout option.

@c-knowles large in number of metrics, so a good indicator could be the pod count there.
Anyway, could you sum-up the current state here ? We changed the default timeout to 10 so if your KSM pod answers in less than 10 seconds, and has a small enough payload, it should be good.
If it isn't, best would be for us to assist you through a support ticket, if you haven't opened one already, so that we can share your logs and make advices based on this.

In case you want to try sharding, maybe the best would be to get a prometheus payload from the kube-state-metrics pod, and look into the number of lines relative to different namespaces, and different k8s objects.
For instance, a simple shard could be to have a KSM pod for namespace default and collector pods, and, a pod for the other namespaces and collectors, as it's often the greatest source of metrics

@antoinepouille, the problem is still how large is large? We assumed it was metric count but it’s hard to know how much we should shard by when you say some payloads can cause problems. How many metrics are we talking?? Our kube state metrics endpoint returns within 10 seconds every time during our testing and our production DD agent v5 works perfectly. But so far with agent v6 every version we tried so far doesn’t work at all, even ones that apparently have the new timeout.
I think there’s one other problem which obscures this one - the one reported in the helm chart repo that auto discovery seems to be intermittent at least for kube state metrics.

@c-knowles
I'm sorry not to give you the exact info you are looking for. The number of metrics depend on a lot of factors, and it's hard to predict by advance.
So that we have more info to help you, and so help you faster, could you give me the case ID of the support ticket you opened (or a new one), and send there a new flare from a host which had some kube-state-metrics submission issues?
In 6.4, the prometheus timeout will be configurable, which might be sufficient. But let's confirm that with data from a flare.

About your other issue, I had a look in the helm chart repository, and could find these issues which are all closed. Is there another one open by another author maybe?
An issue with autodiscovery would usually rather belong to our datadog-agent repo.
I'll also have a look if you could link me the issue you just mentioned

@antoinepouille yes I agree but specifically with reference to Else, the data fetched from the pod can be to large for the agent to handle, in that case, the timeout is of no use to fix this. Is too large 10/100/1000 metrics? What order of magnitude are you talking about? 10/100/1000kB? Without knowing that we don't have any clue how much we need to shard by and as our deployment count expands, when we'll sudden go over this invisible/undocumented Datadog limit.
The case ID containing our flares is 99814. It's mixed in with some other problems because of several other agent instability issues.
The issue I referenced is https://github.com/kubernetes/charts/issues/1466, not created by us but shows it's not just us who occasionally experience AD not working as it should. That issue is also closed due to being "stale" (but we think it still exists). Actually while we tried to setup some sharding here, the AD for kube state metrics was not picked up for several hours.

@c-knowles Thank you. I'll investigate your different issues and come back with more information as soon as I can. Thanks again for your patience here

For the limit, the issue would be with the number of metrics your agent is submitting.
Currently, the limit is 3.2MB for deflate (zlib) compressed payloads, and 62MB for the decompressed payload. 11MB should pose no issues there. I'll second check in your flare for more info

@c-knowles I had a new look in the ticket, and remembered the discussion.
Given the info we have, the issue here would not be with the payload, but with the timeout: if it can go up to 8 seconds, it's likely it can go over 10 seconds at some moments, causing the missing metrics. How does this explanation sounds to you?
Then, moving the timeout to 30 seconds should solve this issue, without sharding.
It might not be true in a cluster 5 times as big, as the limit for the payload may be reached, and then necessitate a sharding. It's still in our plans to investigate how to handle that without sharding, but it'll not be short term.
The configurable timeout for all prometheus checks, including kube-state-metrics will be out in 6.4.0, from this PR https://github.com/DataDog/integrations-core/pull/1790
Does all this makes sense in your opinion? Let us know if you think we can help further here

Regarding the issue with the kube-state-metrics deployment from the helm chart, it might indeed be broken, since it has not be updated for some time.
We are currently doing a revamp from the helm chart, so I'll throw a word so that we also fix/update this kube-state-metrics deploy in the same movement.

@antoinepouille just wanted to make sure 11MB was a typo - our payload in this repo was ~11 kilobytes.

FYI, on a dev cluster we're running 6.3.1 which has a default timeout of 10 seconds but it also doesn't work as expected.
I've separated into support ticket 154424 so it's not tangled with some other issues.

@c-knowles Yes, sorry for the mix up here… So, it's way below the threshold level and should be OK.
For the configurable timeout, we'll be building you an image as soon as we can finish reviewing the changes. You should be able to test this out in the next days, hopefully it'll solve the issue, else we'll get back to it with more info

About the chart issue, I joined one of our engineers, who couldn't replicate it with datadog chart 0.18.0and kube-state-metrics chart 0.8.0. We'll need more info to help on this. Could you please open up a new support case with more context, and ask it for an immediate escalation? We'll be able to reach to you from there also.

@c-knowles datadog/agent-dev:backport-1790 is 6.3.1 including the option for a configurable endpoint, from this PR https://github.com/DataDog/integrations-core/pull/1790. Let me know if you need a jmx image also.
Could you test this out, set a higher timeout and see if this behaves better with the kube-state-metrics prometheus metrics?

@antoinepouille thanks! We've just tried that on a dev cluster but no luck. I hit an issue with AD which was my own misunderstanding in 154421. However, after unblocking that I now have this returned from agent status:
    kubernetes_state
    ----------------
      Core Check Loader:
        Check kubernetes_state not found in Catalog

      JMX Check Loader:
        check is not a jmx check, or unable to determine if it's so

      Python Check Loader:
        No module named kubernetes_state

But this from agent configcheck on the same pod:
=== kubernetes_state check ===
Source: Kubernetes pod annotation
Instance 1:
kube_state_url: http://<IP_ADDRESS>:8080/metrics
tags:
- helm_release:kube-state-metrics-deployments
- image_tag:v1.3.1
- image_name:k8s.gcr.io/kube-state-metrics
- docker_image:k8s.gcr.io/kube-state-metrics:v1.3.1
- kube_container_name:kube-state-metrics
- kube_service:kube-state-metrics-deployments
- app_name:kube-state-metrics
- kube_deployment:kube-state-metrics-deployments
- kube_namespace:kube-system
- short_image:kube-state-metrics
~
Init Config:
{}
Auto-discovery IDs:
* docker://eb2b34a53089e77bb18480f2640ad36f0a5c12d943f884bad0b8266647ee0284

@c-knowles There might have an issue with loading the kubernetes_state check code there, strange.
Did you send a flare to one of the support tickets you have open? That'd be useful to have a look to the agent's logs.

@antoinepouille Not sure if any of the flares I've sent specifically include that as there seems to be several issues at play here. However, 154421 was sent from the same cluster using your dev backport build.

@c-knowles I had a look into this flare, but it seems like the kube-state-metrics pod isn't present on this host, so the check isn't loaded. Would that be possible for you to send a flare from a host where a kube-state-metrics pod is present?
Thanks!

@antoinepouille ok will send another now.

@c-knowles I just fixed the image. Some of our tooling was not aligned correctly, and the agent couldn't find it.
On my end, I could deploy it, and auto-discover a KSM pod.
Could you have a new try? It's behind the same tag.
Let us know if that work, and if setting manually the timeout helps

@antoinepouille appears to be running for now, although it has done before with previous images just intermittently so not sure yet if it's stable. Will leave it for a while, I think it may still suffer from some AD bug as the kube state metrics are not always picked up.

@c-knowles
Yup, best to leave it for some time. How does it look now?

Similar problems I’m afraid, intermittent at best. Sometimes every 20 seconds as usual with a much older agent but then sometimes dozens of minutes until the next step reported. Data is still returned way under ten seconds. Not sure if the memory leak I reported is contributing to the issue, maybe the agent reporting is one of the unlucky ones so will check that.

@c-knowles if you are running the kubernetes_state on the same node that is having the kubelet memory issues, then it's likely to be linked.
We built the 6.3.3rc1 which should give important with the "memory leak" (mainly this PR https://github.com/DataDog/integrations-core/pull/1872), and I just built this image datadog-agent:backport-1790-633rc1 which includes the configurable prometheus timeout.
Could you try this new image, and see if that helps, for any of these issues?

Will launch that now and see what happened overnight.

Great, keep us updated 👍
As a note, we already identified a CPU utilization issue with this RC1, but it should be safe enough to use in the context of the kubelet check, which should be way lower

@antoinepouille No luck overnight unfortunately, those pods have been going for 8 hours and the one on the same node as kube state metrics has 16 restarts in that time.
I checked a notebook we have about this collection issue and the node in question has the gradual memory increase and them last event is OOM. Currently we've assigned 512MB and can see it gets up to that. I'll send another flare to 154424 now.

@c-knowles Looking into your account, I could only find an image with image tag 6.2.1-backport_1732-0, and none such as backport-1790-633rc1. Has it a different name, or used in a different account?
16 restarts during 8 hours is one every 30 minutes. Is that a lower rate than before? Could you notice a difference there in the memory usage?
Could you give us more details about your tests (such as the timeframe and the image used) so that we can have a closer look into this on your account? Some links could also help there
Also, would that be possible for you to test again, and send us flares with images 6.3.2, and 6.3.3? That'll help see if there's an improvement, or if we can't see a real change there.
6.3.3 was just released, so you should be able to use it to see if there's an improvement around the kubelet check performance.
Since its released, we'll also build you a custom image based on 6.3.3 to add the configurable prometheus timeout as another new backport.

@antoinepouille we definitely have metrics for image_tag: backport-1790-633rc1 for the last day or so, e.g. docker.mem.rss. I'll deploy 6.3.3 now and see if we fare any better.

Bump, this is still an issue with at least 6.4.1 although it does seem to have gotten slightly better.

@c-knowles are you still encountering challenges here?

Since we are now at the version 6.11, I will close this issue.
Feel free to reach out if you still encounter this issue @c-knowles
Thanks!


issue #941 - force the use of TLSv1.2

As recommended at https://www.hl7.org/fhir/security.html#http
Signed-off-by: Lee Surprenant<EMAIL_ADDRESS>

I confirmed it still works if you enabled HTTP (though its still not recommended)


No button to get back to home page from contact us page.

As there is no button to get back to the home page from the contact us page. Would be glad to contribute under gssoc21.

Created a PR regarding this issue.

can i work on this issue?

It has been resolved now. So i don't think it is required.


Update version for the next release (v0.14.0)

This PR is auto-generated.
The automated script updates the version of meilisearch-dotnet to a new version: "v0.14.0"

bors merge


Suggestions for #140

rename DeployEstopVerifier and change vm.startBroadcast() and vm.broadcast()
move common functions to base contract
simulate scheduled calls to avoid finding out they'll fail later
add a codeblock language
add --broadcast flag
fix simulation, error on unset env var

@intoverflow feel free to press the merge button if these suggestions look good to you.

This is terrific. I've tested the entire flow against Anvil and it works as advertised. I've also confirmed that every scheduled update gets simulated (using vm.prank()) before being scheduled, and that the --broadcast flag works as intended. Very nicely done


feat(wasmtime-cli): restore support for wasi http module

Within the wasmtime CLI, the current default behavior is to only inject the synchronous functions to linkers. This will add a flag called --async that will inject the asynchronous one instead.
This is required in order to enable back the wasi-http module because it has been implemented only with async functions. Additionally, it will help the async support code path to be tested as async should be enabled by default in the future.
This will enable back the wasi-http module within the wasmtime CLI. We will make the bindgen synchronous through the tokio executor available in wasmtime.

This isn't the correct approach - instead, wasmtime-wasi::preview2::in_tokio should be made pub, and and the wasmtime-wasi-http crate should use that to implement a sync bindgen trait by wrapping the async bindgen trait.
futures::executor isnt the right executor to use with wasmtime-wasi, it will fall over if not used with tokio.

@pchickey and @elliottt, this is ready to be reviewed.

Looks like there is some sort of cargo issue that happens when building the cli, which doesnt happen in the usual set of tests that runs before the merge queue runs the full set. Put the string prtest:full in a commit message to get the full test suite running each time you push.

@pchickey, now tests are passing. I had to ignore the wasi-http tests on Windows as there were failing. I plan on further debugging those after PR #6877 lands.

@alexcrichton and @pchickey, could wasi-http be enabled back in the wasmtime v13 release branch, please? Otherwise, there will be no release with module support for this.

AFAIK that was the plan yeah, so seems reasonable to me. The process for doing so would require a PR to the release-13.0.0 branch of Wasmtime. @eduardomourar are you ok doing that?


[Q] Training the all the components together.

Hey, thanks for releasing the code. I came across this after reading the paper. I just wonder if you ever tried training the whole model together and how it performed compared to the 2 stage approach. Maybe it is just me missing in the paper, but I don't see a clear comparison although everything else is quite clear, especially with the Appendix. Thanks again.

The w/o augmentation in our ablation study is pretty much training all components together. We didn't specifically test training together, but we believe there should be no difference between training everything together and w/o augmentation because in most TTS systems the decoder not depend on the gradient of variance predictor (there is a nograd operation after the text encoder output). When the decoder converges, the predictor should also converge, the same as in stage 2 of training, but we are not sure exactly what will happen.
You can also train two stages together with augmentation. It is not impossible to apply the duration-invariant data augmentation when you train them E2E, although you will need the decoder output with stretched or compressed representations to reconstruct the mel-spectrogram. If your decoder is not well-trained, however, this will derail the predictor and make it converge slower maybe to a worse minimum, so I don't believe it should be better than 2-stage training as there is a nograd operation to the predictor (i.e., no other components need the gradient from predictor). If you do not apply nograd operation, I don't know what will happen. You may try it and see. I believe there is a reason why nograd operation is applied in most TTS systems between the variance predictor and the rest of the components.


How to install binary correctly via proxy?

We have a closed connection environment during our builds via Jenkins, so we can't go to the internet to get external things. When we use npm install the node-sass package will download the binary from github.
Because of our solution we use the proxy setting in our Jenkins file: npm config set proxy http://ip-address. It seems like that is ok, expect we receive a 504 (gateway timeout) status code: tunneling socket could not be established, statusCode=504
We saw the binary redirect (302) us to a AWS environment. We can't open the proxy for that, because the whole world can connect with us ;-)
Does anyone have an idea what we can do more?

We have generate a workaround for our pipeline to open AWS in our proxy, but specified to the specific AWS environment with a wildcard for the hash. Hopefully we are future proof!


super.onStop() is called after current class

I signed it!

Thank you for the PR, and my apologies for being tardy in processing it.


TestCase Passes when it is actual failure

I am pretty new to XCtest and I am from Testing background, still trying to grab hold of swift and XCtest.
Issue: I have updated the Pod yesterday, since then I am seeing my test passing even though it is a fail(Only when multiple tests are run from a class), it is all good when that specific test is run(ie. the test fails).
I am using :
extension XCTestCase {

    func waitForHittable(element: XCUIElement, waitSeconds: Double, file: String = #file, line: UInt = #line) {
        let existsPredicate = NSPredicate(format: "hittable == true")
        expectation(for: existsPredicate, evaluatedWith: element, handler: nil)

        waitForExpectations(timeout: waitSeconds) { (error) -> Void in
            if (error != nil) {
                let message = "Failed to find \(element) after \(waitSeconds) seconds."
                self.recordFailure(withDescription: message,
                    inFile: file, atLine: line, expected: true)
            }
        }
}

What I found was that when multiple tests are run and method is called , if it is actual failure in second testcase then the test just proceeds as if nothing happened and it passes (self.recordFailure seems not working as expected for second one).But on the other hand if the actual failure is in first test the testcase fails.
I have another machine with a bit older version of XCTest-Gherkin(around a month older version) and all is working as expected.Seems like the recent latest commit has broken something.
Not sure If this issue has something to do with #48 (May be similar)

Hi,
I can't reproduce this on the latest master (ref 7717628)
I'm using this test case to try to see the issue:
class FailingSecondTest: XCTestCase {

    func test0() {
        return
    }

    func test1() {
        self.expectation(description: "expectation")

        waitForExpectations(timeout: 1) { (error) -> Void in
            if (error != nil) {
                self.recordFailure(withDescription: "Test Failed",
                                   inFile: #file, atLine: #line, expected: true)
            }
        }
    }

    func test2() {
        self.expectation(description: "expectation")

        waitForExpectations(timeout: 1) { (error) -> Void in
            if (error != nil) {
                self.recordFailure(withDescription: "Test Failed",
                                   inFile: #file, atLine: #line, expected: true)
            }
        }
    }
}

but I get test0 passing, and test1 and test2 both fail as expected.
Can you product a test case which can be dropped into the pod's example project so I can reproduce it please?

(I'll try to reproduce #48 - it does look like they might be the same issue)

OK, I've tried this test case (in the UI test target) and it behaves as expected (i.e. 1 passing test, and then 2 failing ones).
extension XCTestCase {

    func waitForHittable(element: XCUIElement, waitSeconds: Double, file: String = #file, line: UInt = #line) {
        let existsPredicate = NSPredicate(format: "hittable == true")
        expectation(for: existsPredicate, evaluatedWith: element, handler: nil)

        waitForExpectations(timeout: waitSeconds) { (error) -> Void in
            if (error != nil) {
                let message = "Failed to find \(element) after \(waitSeconds) seconds."
                self.recordFailure(withDescription: message,
                                   inFile: file, atLine: line, expected: true)
            }
        }
    }
}

class FailingSecondTest: XCTestCase {

    func test0() {
        return
    }

    func test1() {
        let element = XCUIApplication().buttons["hunter1"]
        self.waitForHittable(element: element, waitSeconds: 1)
    }

    func test2() {
        let element = XCUIApplication().buttons["hunter2"]
        self.waitForHittable(element: element, waitSeconds: 1)
    }
}

This seems much closer to your original code, can you modify this so that it shows your issue please?

@nap-sam-dean  yep when you write test as you mentioned above without gherkin and steps it works fine.The issue is when we use Gherkin as below:
I have tried the below using Gherkin:
Swift feature file like:
class Demo: XCTestCase {
func test0(){
Given("App is opened")
}
func test1(){
    Given("App is opened")
}
func test2(){
    Given("App is opened")
}

}
and steps definitions goes like:
class LoginStepDefiner : StepDefiner {
override func defineSteps() {
    step("App is opened"){
        let element = XCUIApplication().buttons["hunter2"]
        self.test.waitForHittable(element: element, waitSeconds: 1)
    }
}

}
Test Result for above code:
The first test fails , but next 2 test passes
Like: Test2(Fail as expected)
Test1(Pass- Not Expected: Expected is failure)
Test0(Pass- Not Expected: Expected is failure)
I have added XCTestFail for func waitForHittable as:
Added XCTFail  to fail test when recordFailure passes the failed test
extension XCTestCase {
func waitForHittable(element: XCUIElement, waitSeconds: Double, file: String = #file, line: UInt = #line) {
    let existsPredicate = NSPredicate(format: "hittable == true")
    expectation(for: existsPredicate, evaluatedWith: element, handler: nil)

    waitForExpectations(timeout: waitSeconds) { (error) -> Void in
        if (error != nil) {
            let message = "Failed to find \(element) after \(waitSeconds) seconds."
            self.recordFailure(withDescription: message,
                               inFile: file, atLine: line, expected: true)
             XCTFail(message) // Added to fail test when recordFailure passes the failed test
        }
    }
}

}

Hey @SpeedyNassir - if your fix has worked for you can we close this issue?
Though I would recommend totally replacing self.recordFailure with XCTFail and passing in the line and file as well i.e. just use XCTFail(message, file: file, line: line) instead of the self.recordFailure line.

Closing issue, Similar is tracked under #48


otel: plan out new signals and their attributes

This needs to include:
From Alec's original issue desc: PubSub - count per topic, subscriber cursor, etc.
From Brad: counts for all the event types, queue depth (useful for most or all of the queues, probably)
Broadly speaking, the task here is to create a list of metrics + the attributes to include for each metric. We want as few metrics as possible, with the bulk of our analysis being performed by segmenting signals by attribute.

Gonna go ahead and mark this as done since we are finally at the finish line on all the core metrics :D


Update README.md

fix typo

I signed it!)
Att,
Deividi Cavarzan
41 99563272
2016-03-30 11:52 GMT-03:00 googlebot<EMAIL_ADDRESS>
Thanks for your pull request. It looks like this may be your first
contribution to a Google open source project. Before we can look at your
pull request, you'll need to sign a Contributor License Agreement (CLA).
[image: :memo:] Please visit https://cla.developers.google.com/
https://cla.developers.google.com/ to sign.
Once you've signed, please reply here (e.g. I signed it!) and we'll
verify. Thanks.

If you've already signed a CLA, it's possible we don't have your
GitHub username or you're using a different email address. Check your
existing CLA data https://cla.developers.google.com/clas and verify
that your email is set on your git commits
https://help.github.com/articles/setting-your-email-in-git/.
If you signed the CLA as a corporation, please let us know the
company's name.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/googlesamples/android-architecture/pull/12#issuecomment-203470966

Good catch thanks!


sv-dkl example timing out with pytorch-1.0

I am seeing an increasing number of builds (example) being aborted in test_examples with the error that No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself. on the pytorch-1.0 branch. This seems to mostly get triggered in python examples/contrib/gp/sv-dkl.py.
The problem usually resolves if we rebuild, but it is worth investigating as we are not seeing this on the dev branch. If the issue is due to #1421, we should make this test example faster so as not to stall the build.
python examples/contrib/gp/sv-dkl.py --epochs=1 --num-inducing=4
No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.
Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received

I've seen a couple stalled builds on dev branch recently, so this may merely be a Travis issue. I'll grab details next time I see this.

I think the issue is most likely that the torchvision dataloader is deadlocking in pytorch-1.0 for some reason. I'm still investigating it.

I have tried various assumptions in #1612 without successful. Here are my observations:

This seems like a DataLoader problem: I disable forward and backward, failed travis can be seen  at https://travis-ci.org/uber/pyro/jobs/465717303.
Because vae example also requires MNIST dataloader but it didn't fail in Travis. I thought that the torchvision Normalize transform might be the problem. However, the problem is still happened when I removed it. :(
The loss in failed run is different from the loss in passed run by a small margin. Loss is consistent in failed run and also consistent in passed run.

The loss in failed run is different from the loss in passed run by a small margin. Loss is consistent in failed run and also consistent in passed run.

Maybe we can try shuffle=False and see if that at least gives the same loss.

It seems that there is a regression in conditional function. In the commit which I mentioned above (about DataLoader problem), I forget to disable forward pass of test function. So DataLoader might not be a problem. I'm investigating more.

Finally, I can isolate the slowness: nn.Conv2d.

When test passes (line 1158): it took 0.00779986381531s.
When test fails (line 1121): it took 0.7628870010375977s.

This topic might be relevant.

Finally, I can isolate the slowness: nn.Conv2d.

Wow..great job debugging this! I wish this could have been fixed in release, because it seems like a serious regression (not so much for Pyro, but other users).

@neerajprad It just happens on Travis. I can't replicate it locally even when I install PyTorch from pip: https://download.pytorch.org/whl/cpu/torch-1.0.0-cp36-cp36m-linux_x86_64.whl :(


Using default arguments when nothing is injected

Using NewType (or Key) is a great way to inject configuration into classes, but there are cases where there is a sane default that is rarely overridden. In these cases it would be nice to have a way to define the default value close to where it is used.
Injector currently does not consider default values unless @noninjectable is used, but @noninjectable does not allow configuration to be injected when the default is not to be used.
Is there a way to do this? If not, what are your thoughts on the topic?
The following is an example of how it would be useful:
SleepTime = NewType('SleepTime', float)

class WaitStrategy:

    @inject
    def __init__(self, sleep_time: SleepTime = 1.0) -> None:
        self._sleep_time = sleep_time

Making Injector consider default arguments might get unwanted consequences for optional arguments (where None is the default), so it's possible that a new decorator would be a better solution for this.

That being said, using the default values would be intuitive in most cases.

+1 on always respecting the function-definition default for any type which has not had an injectable configure for it explicitly. The current behavior is, in effect, silently overriding the default of every optional argument. If I have a function with the argument my_var: Optional[str] = None and I call it without supplying a value for my_var, I expect my_var to be None, not the empty string!

#116 is also related to that.

I'd like to understand the use case for the parameter to both be injectable and have a default value. As I can't think of any I'd welcome any information here.
Raising an exception when injectable parameter (no matter if its type was bound explicitly or not) with default value is encountered seems like an option to me to avoid confusion and make things clear(er).

@jstasiak, the short answer from me is primarily for configuration.
My use case was that I had some default string/numeric configuration that normally shouldn't be overridden, except with specific values for integration tests.

While raising for a default value would remove the confusion, it might also complicate setup in tests when injector is not used. I believe that fixing the issue described in #116 would remove most of the risk of confusion here as well, since default values are primarily used for "value types".


zpm install has long hang at the end due to analytics

I just did a zpm install (running version 0.3.0) and there was a long hang at the end with:
%objlasterror=/* ERROR #6059: Unable to open TCP/IP socket to server www.google-analytics.com:80 */
@evshvarov suggested:
We had this analytics. I think we can remove it or turn it off, as we have better approaches now. Could you please create an issue?

This is still an issue.

Actually, there's a simple solution:
zpm "config set analytics 0"
Just need this better documented.

This is hard to resolve given the ObjectScript single-threaded model.  What do you think about lowering the timeouts?

Added some documentation about the speedup from "config set analytics 0" here:
https://github.com/intersystems/ipm/wiki/02.-CLI-commands#config


Preprocessing file missing for AGENDA data

I notice there's no data folder for Agenda dataset, so this preprocessing file is also not exist agenda/data/generate_input_agenda.py. Would you please confirm everything is uploaded? Thank you very much.

I meet the same problem, too. Could you please upload the missing folder in Agenda? @leoribeiro Thanks~

I meet the same problem, too. Could you please upload the missing folder in Agenda? @leoribeiro Thanks~


code asks for input twice, help me get rid of it pls

import numpy as np
import matplotlib.pyplot as plt
from findiff import FinDiff
from scipy.sparse.linalg import inv
from scipy.sparse import eye, diags
import matplotlib.animation as animation

#input: V, output: psi

#print('hi')
#calculation of schrodingers eqn according to t:

# Input parameters
Nx = 500

#defining space & time variables
xmin = -5
xmax = 5
Nt = 500
tmin = 0
tmax = 60
k = 1

# Calculate grid, potential, and initial wave function
x_array = np.linspace(xmin, xmax, Nx)
t_array = np.linspace(tmin, tmax, Nt)

#arbitrarily defining V so i have something to work with; actual values will later be determined by use input
def V():
      String = str(input("Whats  your potential?\n"))
      command = """def f(x):
          return """ + String
      exec(command, globals())

      return f(x_array)

# Converting V to a diagonal matrix
Vmatrix = diags(V())

#calculation of small psi
psi = np.exp(-(x_array+2)**2)

# Calculating deltat, deltax
dt = t_array[1] - t_array[0]
dx = x_array[1] - x_array[0]

# Find H
H = -0.5 * FinDiff(0, dx, 2).matrix(x_array.shape) + Vmatrix

# Apply boundary conditions to the Hamiltonian
H[0, :] = H[-1, :] = 0
H[0, 0] = H[-1, -1] = 1

# Calculate U
I_plus = eye(Nx) + 1j * dt / 2. * H
I_minus = eye(Nx) - 1j * dt / 2. * H
U = inv(I_minus).dot(I_plus)

# making a list of all the calculations
psi_list = []
for t in t_array:
    psi = U.dot(psi)
    psi[0] = psi[-1] = 0
    psi_list.append(np.abs(psi))

fig, ax = plt.subplots()

ax.set_xlabel("x [arb units]")
ax.set_ylabel("$|\Psi(x, t)|$", color="C0")

ax_twin = ax.twinx()
ax_twin.plot(x_array, V(), color="C1")
ax_twin.set_ylabel("V(x) [arb units]", color="C1")

line, = ax.plot([], [], color="C0", lw=2)
ax.grid()
xdata, ydata = [], []

def run(psi):
    line.set_data(x_array, np.abs(psi)**2)
    return line,

ax.set_xlim(x_array[0], x_array[-1])
ax.set_ylim(0, 1)

ani = animation.FuncAnimation(fig, run, psi_list, interval=10)

plt.show()

i cant get the actual code running but just by looking at it can't see anything obvious asides we ask for the potential under strings and then reuse strings later so that may trigger it to ask again

cant really see how to fix it asides from re-writing the user defined potential

cant really see how to fix it asides from re-writing the user defined potential

it was because in the original code whenever I wanted to use V I'd just called the whole function V() all over again. Solved it by defining VV = V(), and then using VV in place of V() so as to only call the function once
mport matplotlib.pyplot as plt
from findiff import FinDiff
from scipy.sparse.linalg import inv
from scipy.sparse import eye, diags
import matplotlib.animation as animation

#input: V, output: psi

#calculation of schrodingers eqn according to t:

# Input parameters
Nx = 500

#defining space & time variables
xmin = -5
xmax = 5
Nt = 500
tmin = 0
tmax = 60
k = 1

# Calculate grid, potential, and initial wave function
x_array = np.linspace(xmin, xmax, Nx)
t_array = np.linspace(tmin, tmax, Nt)

#defining V
def V():
      String = str(input("Whats  your potential?\n"))
      command = """def f(x):
          return """ + String
      exec(command, globals())
      print(f(x_array))
      return f(x_array)

VV = V()

# Converting V to a diagonal matrix
Vmatrix = diags(VV)

#calculation of small psi
psi = np.exp(-(x_array+2)**2)

# Calculating deltat, deltax
dt = t_array[1] - t_array[0]
dx = x_array[1] - x_array[0]

# Find H
H = -0.5 * FinDiff(0, dx, 2).matrix(x_array.shape) + Vmatrix

# Apply boundary conditions to the Hamiltonian
H[0, :] = H[-1, :] = 0
H[0, 0] = H[-1, -1] = 1

# Calculate U
I_plus = eye(Nx) + 1j * dt / 2. * H
I_minus = eye(Nx) - 1j * dt / 2. * H
U = inv(I_minus).dot(I_plus)

# making a list of all the calculations
psi_list = []
for t in t_array:
    psi = U.dot(psi)
    psi[0] = psi[-1] = 0
    psi_list.append(np.abs(psi))

fig, ax = plt.subplots()

ax.set_xlabel("x [arb units]")
ax.set_ylabel("$|\Psi(x, t)|$", color="C0")

ax_twin = ax.twinx()
ax_twin.plot(x_array, VV, color="C1")
ax_twin.set_ylabel("V(x) [arb units]", color="C1")

line, = ax.plot([], [], color="C0", lw=2)
ax.grid()
xdata, ydata = [], []

def run(psi):
    line.set_data(x_array, np.abs(psi)**2)
    return line,

ax.set_xlim(x_array[0], x_array[-1])
ax.set_ylim(0, 1)

ani = animation.FuncAnimation(fig, run, psi_list, interval=10)

plt.show()


Is this repo dead?

Thanks for the great repo!
I see lots of unanswered questions, plus a PR I would like to use that has been waiting for months... If this isn't going to be maintained, is AlexNek the new official maintainer?
His fork at https://github.com/AlexNek/BlazorSortableList seems more current with .NET 8 support, plus he seem to control the nuget package which is how everyone will want to use this.
If that's the case please clarify on the readme so people can understand what they should be using, and where they should be contributing. As it stands I can't use this and people are wasting effort. Thanks. :)
@burkeholland @AlexNek

In the beginning, I just want to make this project better. My changes were really big for the pull request and the most important change is the architectural concept. I try to add everything I think is useful, but in my fork not much user activity. I can improve the project as long as I know your wishes. I love Blazor and created some other controls.
I cannot say anything about this repo state.

@AlexNek It's cool that you've done such work. do you plan to solve issues of this project in your fork (for example, add nesting)?

As long as I can see the needs, I can try to solve them. But there must be a tendency. If only one person needs something - it is one problem, if many, it is another.
Implementing list nesting is not so simple. We need to have a similar Blazor control and add some action mapping.
But in general, only your activity will contribute to the development of the project.

I also needed nesting, for what it's worth.
I ended up going with MudBlazor, which is overkill for this one problem since that's a whole UI opinionated framework, and it also isn't as nice visually this project.
I would have preferred to use this but I didn't get that "this is a healthy product that definitely has a clear maintainer" type of vibe. ;)

Thanks for the feedback.
new issue

Try the develop branch, please. Is it what you want?

Yes, it is

Great, thank you. Have you seen any moving bug? I want to test it long time as sometimes I did not understand the moving.


Update go, remove deprecations and house-keeping

Update to 1.19, including the images used in Dockerfiles
Staticcheck runs now for every (relevant) project in this repo
Update staticcheck (looks like this is not detected by Dependabot, we missed out on a few versions)
io/ioutil is deprecated (actually since 1.16), it can be replaced with functions from os and io
Fix some other stuff found by staticcheck

Now the CI fails. 😢

Yeah, that's on me though, I'll fix it :D


Spotbugs 2.0 breaks if Guava is on the plugin classpath

If spotbugs-gradle-plugin 2.0 is used in addition to any other plugin that uses an older Guava on the classpath, the build can fail as this plugin has somehow forced Gradle's Guava off of Gradle's classpath.
I have a reproducer at https://github.com/isker/spotbugs-guava-failure.  See build.gradle for all that's needed to trigger this failure.
@oehme notes that this is due to the usage of many internal worker APIs and ClassLoader manipulation in this plugin, for example:
https://github.com/spotbugs/spotbugs-gradle-plugin/blob/1a72b92c9d537e868f36930b648dfb2c1113e809/src/main/java/com/github/spotbugs/internal/spotbugs/SpotBugsExecutor.java#L14-L28
https://github.com/spotbugs/spotbugs-gradle-plugin/blob/1a72b92c9d537e868f36930b648dfb2c1113e809/src/main/java/com/github/spotbugs/internal/spotbugs/SpotBugsWorkerManager.java#L8-L10
This is a blocker to upgrading Gradle to 6.0 in any project that uses spotbugs and an older Guava on the buildscript classpath, as there is a 5.x deprecation warning that is fixed only in version 2.0 of this plugin on this line: https://github.com/spotbugs/spotbugs-gradle-plugin/blob/bb58cf371129e65da05101a4b1409a7e97548c36/src/main/java/com/github/spotbugs/internal/SpotBugsReportsImpl.java#L14
A potential workaround is to force resolution to a higher version of Guava (ideally the same one used in Gradle itself) on the buildscript classpath.

This classpath issue is reported continuously, such as #119, #120, #128 and #147
And the ideal solution is also known as @oehme mentioned.
What we need is a contribution to realize. This is a volunteer project, have a try if you have time!

IIRC from #57 and #100 , javaExec is the only practical option; that is because the spotbugs tool itself carries stateful information from static initialization that persists in a dormant worker API daemon.
Worker API would be nice but unless the statefulness mentioned by @Vampire in #100 is fixed then Worker API is probably not an option.

I didn't read the whole history here, just got here because of the mention. As I said in #100 already, I think a combination of worker API with javaExec should be used. That way you get parallelism by usage of the worker and needed isolation by usage of javaExec.

I'll close this inactive issue. If you could reproduce this with the latest release, please feel free to reopen.


mate

@drPapus First stage of verification passed, official domain is mate.academy as far as I verified. This is just an informational note. Pull request is still in the review. I appreciate your patience while waiting for the final decision.

@drPapus Regrettably, I have to close the request without merging, because this organization is a training center, not a college, nor a university. Please ensure that you are familiar with this repository rules located at the bottom of this page.
Please apply for an appropriate licensing option (which may also be free) at https://www.jetbrains.com/community/education/#courses.
Thank you for your understanding!


Update paragraphizer to use ChatCompletion API with gpt-3.5-turbo.

The first commit was written by GPT-4 at my request. The second commit is me editing the prompts a bit (and removing the stop tokens, which are, redundant in the ChatCompletion context.)
I have done very rough testing. Using this code with GPT-4 (change the model name to "gpt-4") gives nice paragraphs (n=1 test), although they can be a bit short. GPT-3.5 gives even shorter paragraphs (often just one sentence.) I'm not sure it's actually wrong, but it might need some guidance in the prompt about how big a paragraph should be.

I'll give it a try and see if I notice any issues.
It'd make sense to set up a simple benchmark of paragraphizing cases, given that I have so many instances already (just have to strip out the extra stuff), to properly test out prompts+engines. Some day...


[Deployment] How can I deploy the bot to somewhere like heroku for it to run 24\7?

I already deployed the files to heroku and created a procfile.
I set the Dyno to level 1 of worker
But the bot is offline.
Does anyone know what can I do to use the bot in heroku or somewhere else for free 24\7 uptime?
Procfile : worker: java -Dnogui=true -jar JMusicBot-0.2.10.jar
Bot Version :  JMusicBot-0.2.10
config.txt : /////////////////////////////////////////////////////////
// Config for the JMusicBot                            //
/////////////////////////////////////////////////////////
// Any line starting with // is ignored                //
// You MUST set the token and owner                    //
// All other items have defaults if you don't set them //
// Open in Notepad++ for best results                  //
/////////////////////////////////////////////////////////
// This sets the token for the bot to log in with
// This MUST be a bot token (user tokens will not work)
// If you don't know how to get a bot token, please see the guide here:
// https://github.com/jagrosh/MusicBot/wiki/Getting-a-Bot-Token
token =
// This sets the owner of the bot
// This needs to be the owner's ID (a 17-18 digit number)
// https://github.com/jagrosh/MusicBot/wiki/Finding-Your-User-ID
owner =
// This sets the prefix for the bot
// The prefix is used to control the commands
// If you use !!, the play command will be !!play
// If you do not set this, the prefix will be a mention of the bot (@Botname play)
// If you make this blank, the bot will not use a prefix
prefix = "-"
// If you set this, it modifies the default game of the bot
// Set this to NONE to have no game
// Set this to DEFAULT to use the default game
// You can make the game "Playing X", "Listening to X", or "Watching X"
// where X is the title. If you don't include an action, it will use the
// default of "Playing"
game = "Playing Your Songs"
// If you set this, it will modify the default status of bot
// Valid values: ONLINE IDLE DND INVISIBLE
status = ONLINE
// If you set this to true, the bot will list the title of the song it is currently playing in its
// "Playing" status. Note that this will ONLY work if the bot is playing music on ONE guild;
// if the bot is playing on multiple guilds, this will not work.
songinstatus=true
// If you set this, the bot will also use this prefix in addition to
// the one provided above
altprefix = "dj/"
// If you set these, it will change the various emojis
success = "🎶"
warning = "💡"
error = "🚫"
loading = "⌚"
searching = "🔎"
// If you set this, you change the word used to view the help.
// For example, if you set the prefix to !! and the help to cmds, you would type
// !!cmds to see the help text
help = help
// If you set this, the "nowplaying" command will show youtube thumbnails
// Note: If you set this to true, the nowplaying boxes will NOT refresh
// This is because refreshing the boxes causes the image to be reloaded
// every time it refreshes.
npimages = false
// If you set this, the bot will not leave a voice channel after it finishes a queue.
// Keep in mind that being connected to a voice channel uses additional bandwith,
// so this option is not recommended if bandwidth is a concern.
stayinchannel = true
// This sets the maximum amount of seconds any track loaded can be. If not set or set
// to any number less than or equal to zero, there is no maximum time length. This time
// restriction applies to songs loaded from any source.
maxtime = 0
// This sets an alternative folder to be used as the Playlists folder
// This can be a relative or absolute path
playlistsfolder = "Playlists"
// By default, the bot will DM the owner if the bot is running and a new version of the bot
// becomes available. Set this to false to disable this feature.
updatealerts=true
// Changing this changes the lyrics provider
// Currently available providers: "A-Z Lyrics", "Genius", "MusicMatch"
// At the time of writing, I would recommend sticking with A-Z Lyrics or MusicMatch,
// as Genius tends to have a lot of non-song results and you might get something
// completely unrelated to what you want.
// If you are interested in contributing a provider, please see
// https://github.com/jagrosh/JLyrics
lyrics.default = "A-Z Lyrics"
// These settings allow you to configure custom aliases for all commands.
// Multiple aliases may be given, separated by commas.
//
// Example 1: Giving command "play" the alias "p":
// play = [ p ]
//
// Example 2: Giving command "search" the aliases "yts" and "find":
// search = [ yts, find ]
aliases {
// General commands
settings = [ status ]
// Music commands
lyrics = []
nowplaying = [ np, current ]
play = [p]
playlists = [ pls ]
queue = [ list ]
remove = [ delete ]
scsearch = []
search = [ ytsearch ]
shuffle = []
skip = [ voteskip ]
// Admin commands
prefix = [ setprefix ]
setdj = []
settc = []
setvc = []
// DJ Commands
forceremove = [ forcedelete, modremove, moddelete ]
forceskip = [ modskip ]
movetrack = [ move ]
pause = []
playnext = []
repeat = []
skipto = [ jumpto ]
stop = []
volume = [ vol ]
}
// If you set this to true, it will enable the eval command for the bot owner. This command
// allows the bot owner to run arbitrary code from the bot's account.
//
// WARNING:
// This command can be extremely dangerous. If you don't know what you're doing, you could
// cause horrific problems on your Discord server or on whatever computer this bot is running
// on. Never run this command unless you are completely positive what you are running.

What can I do?

I also tried to use a Procfile that looks like this : worker: java -jar target/bot-1.0-jar-with-dependencies.jar (template)
but it still did not work.

You need filesystem access & permissions, their free their doesn't allow it afaik

So how should I do it?

You can't host a bot for free. The universe doesn't give us free energy, so hosters can't provide you free computing power.

So how can I do it (even if its paid)


chore: Add Sherif to CI to lint monorepo config

Following on from #6354
We cannot currently upgrade to TS 5.2+ since typescript-eslint v5 is incompatible (see this StackOverflow post). I've added pnpm overrides to remove the extremely old eslint/typescript-eslint versions added by CRA v4.

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

Comparison is base (c6d5f53) 0.00% compared to head (9da8fd2) 86.36%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff            @@
##           main    #6376       +/-   ##
=========================================
+ Coverage      0   86.36%   +86.36%
=========================================
  Files         0       87       +87
  Lines         0     2876     +2876
  Branches      0      802      +802
=========================================
+ Hits          0     2484     +2484
- Misses        0      328      +328
- Partials      0       64       +64

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


ERROR: Downloading linutil on aarch64 when script is executed.

Describe the bug
The script fails when it is executed on a CPU based on aarch64 processor.
To Reproduce
Run the ´curl´ command on a computer or container running over a ARM-based CPU
Expected behavior
Launch the dashboard and allow to install the components.
Screenshots

The script was executed in the following environment:

podman version 5.2.2
registry.fedoraproject.org/fedora:latest
CPU Apple M1 Pro

The prebuilt binary distribution is for amd64 only. You'll have to clone the repo and build from source until that changes


FQDN proxy stops forwarding traffic

The FQDN proxy can get into a state where forwarding no longer occurs. Comparing a cilium-sysdump before and after reveals:

No difference in any datapath plumbing
Equivalent gops-stack for FQDN code, both are blocking on IO wait

However, the reported proxy statistics are very different. While this problem is occurring:
        "proxy-statistics": [
          {
            "allocated-proxy-port": 18064,
            "location": "egress",
            "port": 8053,
            "protocol": "dns",
            "statistics": {
              "requests": {},
              "responses": {}
            }
          },
          {
            "allocated-proxy-port": 18064,
            "location": "egress",
            "port": 8053,
            "protocol": "dns",
            "statistics": {
              "requests": {},
              "responses": {}
            }
          }
        ],

After restarting cilium-agent to resolve the issue:
        "proxy-statistics": [
          {
            "allocated-proxy-port": 32463,
            "location": "egress",
            "port": 8053,
            "protocol": "dns",
            "statistics": {
              "requests": {
                "denied": 146,
                "forwarded": 40,
                "received": 186
              },
              "responses": {
                "forwarded": 40,
                "received": 40
              }
            }
          },
          {
            "allocated-proxy-port": 32463,
            "location": "egress",
            "port": 8053,
            "protocol": "dns",
            "statistics": {
              "requests": {},
              "responses": {}
            }
          }
        ],

Found in logs:
message="Releasing proxy port [...] failed"
    error="Can't release proxy port: proxy cilium-dns-egress on [...] has refcount 0"

Focusing on the refcount 0 error message present in the log, we looked at the logics for nRedirects in pkg/proxy/proxy.go. The logics seems sane in the proxy layer itself, but maybe we call RemoveRedirect() incorrectly.
In particular, we call it from RemoveProxyRedirect() in daemon/daemon.go, in turn called from pkg/endpoint/bpf.go. In the latter file, in runPreCompilationSteps(), we call addNewRedirects() conditionally (and it increments the refcount eventually), but removeOldRedirects() (decrementing) not under the same conditions.
So maybe we could be decrementing even if we don't validate the if e.desiredPolicy != nil && e.desiredPolicy.L4Policy != nil && e.desiredPolicy.L4Policy.HasRedirect(), i.e. even if we don’t increment the refcount first? More investigation needed to see how the redirect add/remove works.


MRTB-8: To set inactive using bot

I want to set inactive subscriptions
Acceptance criteria:
/stop command added

#21


Should be able to use Type at runtime

For Cur, we should be able to use Type at runtime.
Test:
#lang racket/base
(require turnstile/examples/dep-ind)

(Type 0)

Expected: Produces a runtime representation of (Type 0)
Actual: Displays "; Type: Cannot use type at run time"

Ah oops yeah. I fixed some of the types but not others. I'll check all of them.

fixed in https://github.com/stchang/macrotypes/commit/a90dcb7279d3ed86b388d04ea2ef0cadd428a568


Create NPM command to generate new sub package

Sub-packages require a certain setup to be consistent across the project. To ensure this, let's have a script that uses inquirer to ask question regarding type of sub package (core, helper, reporter, runner or service) and name etc.

@christian-bromann I would like to pick this one.

@andriilazebnyi awesome. So basically I wanted an easy way to generate a new package. Even though I said, let's use unquirer I guess it is sufficient enough to have a command like:
$ npm run create <name> <type>
# e.g. npm run create allure reporter
# name = name of the sub package
# type = /(reporter|service|runner)/

It then generates all boilerplate files (similar to the xml reporter right now) + a test directory with an example test.

@christian-bromann Sounds good. Can you please assign this task on me as I don't have such permissions?

Implemented by #45


import failed

Do you see an error in the terminal? I can't tell what's wrong from just these screenshots. Could be a bug in the manager.

I found the problem, because I use python 3.9

Your ComfyUI application encountered a problem during startup, preventing the successful import of the rgthree-comfy custom node module. This issue is due to incorrect usage of the glob.glob function in the init.py file. Specifically, the glob.glob function was incorrectly passed a keyword argument named root_dir, which is actually not part of the glob.glob function.
To resolve this issue, you need to modify the code in the rgthree-comfy module:
1.Open the init.py File:
Locate the file at E:\new_ComfyUI\ComfyUI\ComfyUI\custom_nodes\rgthree-comfy_init_.py.
2.Modify the Problematic Line of Code:
Find the line of code causing the error (line 98).
Change the glob.glob call in this line to the correct format. You need to combine the directory path directly with the wildcard, instead of using the root_dir parameter.
3.Correct glob.glob Call Example:
The original code might look something like this:
for file in glob.glob('.py', root_dir=DIR_PY) + glob.glob('.js', root_dir=os.path.join(DIR_DEV_WEB, 'js')):
It should be modified to something like the following format:
for file in glob.glob(os.path.join(DIR_PY, '.py')) + glob.glob(os.path.join(DIR_DEV_WEB, 'js', '.js')):
4.Save the File and Restart ComfyUI:
Save the changes made to the init.py file.
Restart the ComfyUI application for the changes to take effect.


Edited Code, the typoes

For understanding clearly, I edited some remarks.
The expert can understand those without any remarks.
But, someone maybe be going to be confused.
Please check this.
Thanks.

I re-sent a pull-request.
I edited typoes and parameters for the test functions.

The original version of the tests pass. However in this case you have changed the expected results of the tests, but the underlying code remains the same, so the new tests will fail. If you want to add clarifying parentheses, I'll happily merge that, but as-is this PR will break the build.
The actual calculation is not (left + width)/2, it's left + (width/2), which is equivalent to left + width/2 using the standard order of operations. See the implementation.

I agree that everything was correct before, so no part of this PR should be merged.

Um.. now, I understood.
I thought those are a couple of X, Y points of the bounding box.
Then, these remarks don't need parentheses like left + (width/2).
Sorry about misunderstanding.
Thanks.


Marked NOQUEUE as QUEUEID

Related to #150. Marked NOQUEUE as QUEUEID.
Now string
NOQUEUE: reject: RCPT from <EMAIL [IP]: 450 4.2.0 <EMAIL>: Recipient address rejected: Greylisted for 30 seconds; from=<ADDRESS> to=<EMAIL> proto=ESMTP helo=<ADDRESS>
will have a field postfix_queueid: NOQUEUE and postfix_status: reject.

Sorry for the long delay, I was busy doing other stuff.
I refactored your PR a bit, since I don't see any reason to put the postfix_action value into a different named variable. I also updated all tests that contain NOQUEUE to actually verify that it's extracted.
Thanks for your contribution.


Use a more useful internal representation for NamespaceableNames

After #689 we keep in memory a keyword like :foo/bar as the String "foobar" with boundary = 3.
This is convenient at point of allocation and when comparing name and namespace, but one thing we frequently want to do with keywords is turn them into complete strings for printing, querying, or storage. To do that we end up constructing a new string:
    fn fmt(&self, f: &mut Formatter) -> ::std::fmt::Result {
        if self.0.is_namespaced() {
            let (ns, name) = self.0.components();
            write!(f, ":{}/{}", ns, name)
        } else {
            write!(f, ":{}", self.0.name())
        }
    }

If we were to keep the backing string in this composed format, we'd be able to implement AsRef<str> and print directly from the backing string, at the cost of two more bytes.

I have a commit that addresses the namespace divider solidus. I wasn’t happy with my work to add the prefix, but every little helps.

Partly addressed by #713.


Change strikethrough styling of visited topics from left nav pane.

Is your feature request related to a problem? Please describe.
Strikethrough styling of visited topics from left nav pane is little annoying for visitors, The main problem is that Rader/visitor cant just go through  list already covered topics to revise through or in case he is searching something specific.
Describe the solution you'd like
to mark a topic visited, we can instead style the topic little differently than strikethrough, maybe little blue or purple or italicize the text... ( suggestions welcome )
I currently consider styling them little lighter color then other topics.
Describe alternatives you've considered
I thought of checkboxes, but those might make UI messy. Also I doubt the need of marking the visited topics, as several other standard docs don't have such feature yet.
Additional context
Add any other context or screenshots about the feature request here:

I would be grateful if this Issue gets assigned to me along with the hacktoberfest label!

What you you think about checkboxes @XavierChanth ?

I don't see a need for this since:

Adding checkboxes increases the number of clicks required by the user, when at present this is already done for you.
The site is statically served, I would like to avoid adding unnecessary complexity.

So instead we can add something like visited anchor tag styling?
(Visited links show up purple, others show up blue, something similler i wish to say)

@Shubhambawner Feel free to work on this. I'm interested to see what you will do with this. I can see that the strikethrough can be a bit aggressive. If you could figure out a way to show that a portion of the code lab has been completed without adding unnecessary complexity and an increase of clicks by a user, that would be really cool!

@TylerTrott  there is no update yet. Could let me try as well, please assign this to me.

There is some delay as I was engaged with some other issues herein. But however the work is in progress


How to make a HTTP Post request to a server side function (JavaScript) passing the parameters inside the request body?

There is a scenario where we need to call a JavaScript server-side function we developed, and one of its parameters is a list of numbers which can be very long in some cases. According to the documentation (http://orientdb.com/docs/2.0/orientdb.wiki/OrientDB-REST.html#function) the parameters are passed in the URL of the HTTP Post request, but we're afraid we'll have to break the process into many requests due to URL length constraints. Is there a way to invoke a function in the way we are doing, but instead passing the parameters in the body of the HTTP request? That would cost only a single round trip to the server. Thanks in advance.

It's quite easy to support, let me see if we can do that quickly

Just in time to be in 2.1-rc4 ;-) You can now use it by passing a JSON as request payload. Example:
{ "name": "Jay", "surname": "Miner" }

The mapping in this case will be not positional, but by parameter name.

Whoa, that was fast. Thank you very much, lvca!

;-)

Hah, great. We were just looking for this. Thanks for the amazingly quick implementation (even if it was in the past)

;-)

Hello everyone. How can I access to he parameter desired (eg: name) within the function?
Thank you


[AMORO-1341] [Flink]: Support UnifiedCatalog to contain Mixed format table in Flink Engine

Why are the changes needed?

Close #1341.
Brief change log

Add a new FlinkCatalog for the amoro type, including mixed format tables
Add a new FlinkCatalogFactory to create FlinkCatalog
Add a new DynamicTableFactory to create dynamic source and sink of Mixed-hive mixed-iceberg tables

How was this patch tested?

[x] Add some test cases that check the changes thoroughly including negative and positive cases if possible

[ ] Add screenshots for manual tests if appropriate

[x] Run test locally before making a pull request

Documentation

Does this pull request introduce a new feature? (yes / no) yes
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented) docs

We really need this feature.  Did this pr mean flink engine support paimon and mix_paimon?
including: read and write paimon and mix_paimon


autocomplete error: TypeError: Cannot read property 'originX' of undefined

Bug, feature request, or proposal:
Getting an error when using the example code provided at https://material.angular.io/components/component/autocomplete
What is the expected behavior?
Should work like demo
What is the current behavior?
Error is thrown when field receives focus
What are the steps to reproduce?
Providing a Plunker (or similar) is the best way to get the team to see your issue.
Plunker template: http://plnkr.co/edit/o077B6uEiiIgkC0S06dd
What is the use-case or motivation for changing an existing behavior?
It should work or give a better error
Which versions of Angular, Material, OS, browsers are affected?
Material 2.0.0-beta.2
Angular 4.0.0-beta.7
Is there anything else we should know?

It is worth noting here that taking your TS file from the actual source does work so it is probably just an issue with documentation.

@starksds The plunker demo from the docs site is working as expected for me. Can you link to a plunker repro case?

Ok, so I actually couldn't get it to work with the src code or with what is in the plunkr demo.
 Can you also paste a fuller stack trace of the error you're getting?

@kara the error was due to missing the BrowserModule in a lazy loaded route.  I'll recreate and add the stacktrace.

Uncaught TypeError: Cannot read property 'originX' of undefined
at t._getOriginConnectionPoint (vendor.js:2537)
at t.recalculateLastPosition (vendor.js:2537)
at t._resetPanel (vendor.js:2492)
at e.project (vendor.js:2492)
at e._next (vendor.js:4780)
at e.next (vendor.js:10)
at e.notifyNext (vendor.js:16)
at e._next (vendor.js:4141)
at e.next (vendor.js:10)
at e._emitFinal (vendor.js:1798)
at e._emit (vendor.js:1798)
at e._next (vendor.js:1798)
at e.next (vendor.js:10)
at e.object.i [as _next] (vendor.js:1417)
at e.__tryOrUnsub (vendor.js:10)

@kara so after further testing it appears to be related to having the devtools open in a docked window (and taking up most of the screen). this is reproducible on the material demo component site and plunkr

Autocomplete also doesn't work on iPhone 6s (and possibly others too). The options list never shows.

@kara

@starksds Thanks for the clarification!  Seeing it now too when I open Devtools and make the viewport really small. My hunch is that it's related to this PR:  https://github.com/angular/material2/pull/3189.
None of the positions fit, so it's crashing. We should be using the first position as a default. Can you test again against your app once it gets in?

@kara I can certainly test once the code is merged up.  Any ideas when the next release is going to be?

@kara

@starksds This looks fixed to me on master, so I'm closing. Should be out with the next release.

So when will this part rectified?????

@kara Thanks for moving forward on this fix. When can we expect these changes to be released?

@whyao it's unclear when beta 3 will be released, but likely soon after ng-conf (this week).  I haven't had a chance to verify it yet though.

Verified. It has been fixed.


[BUG] invalid tag name with iterators in --gdb mode

Describe the bug
$ cat example.pyx
def use_an_iterator(iterator):
    return (x for x in iterator)
$ cython3 --version
Cython version 3.0.0
$ cython3 -3 example.pyx
$ cython3 -3 --gdb example.pyx

Error compiling Cython file:
------------------------------------------------------------
...
def use_an_iterator(iterator):
^
------------------------------------------------------------

example.pyx:1:0: Compiler crash in DebugTransform

Compiler crash traceback from this point on:
  File "Cython/Compiler/Visitor.py", line 182, in Cython.Compiler.Visitor.TreeVisitor._visit
  File "/usr/lib/python3.11/site-packages/Cython/Compiler/ParseTreeTransforms.py", line 4033, in visit_ModuleNode
    self.visit_FuncDefNode(nested_funcdef)
  File "/usr/lib/python3.11/site-packages/Cython/Compiler/ParseTreeTransforms.py", line 4093, in visit_FuncDefNode
    self.tb.start(arg.name)
  File "/usr/lib/python3.11/site-packages/Cython/Debugger/DebugWriter.py", line 42, in start
    self.tb.start(name, attrs or {})
  File "src/lxml/saxparser.pxi", line 841, in lxml.etree.TreeBuilder.start
  File "src/lxml/saxparser.pxi", line 769, in lxml.etree.TreeBuilder._handleSaxStart
  File "src/lxml/apihelpers.pxi", line 179, in lxml.etree._makeSubElement
  File "src/lxml/apihelpers.pxi", line 1754, in lxml.etree._tagValidOrRaise
ValueError: Invalid tag name '.0'

Code to reproduce the behaviour:
def use_an_iterator(iterator):
    return (x for x in iterator)

Expected behaviour
No response
OS
linux
Python version
3.11.4
Cython version
No response
Additional context
This happens only if python lxml package is installed.
I reduced it to the simple function above, but this happens a lot in sagemath source code.

So the origin of this is: I've used function arguments with names like .0 and .1 as a way of passing arguments into generator expressions. This is by analogy with Python where
>>> [locals() for _ in range(1)]
[{'.0': <range_iterator object at 0x7f9a4732c150>, '_': 0}]

(exact behaviour likely somewhat version dependent).
It looks like these don't play well with the debug output writer.
It's probably fairly simple to fix either by renaming the arguments or by excluding them from the debug output. I don't know much about the --gdb so I don't really know what the appropriate solution is. But one of those solutions should work.

This issue is also affecting pyarrow, FWIW

We defined the XML format ourselves, I think, but changing it now brings in compatibility problems.
I think excluding these arguments is probably ok for now.

I would like to look into fixing this issue, as it blocks building debug builds for certain projects based on scikit-build which passes --gdb argument to cython automatically.

@oleksandr-pavlyk I've assigned it to you. Hopefully it should be reasonably simple, but less us know how you get on.


[WIP] Basic tests for UsersTab add user button

Coverage decreased (-0.01%) to 99.045% when pulling 018d2ea4c728a671411ff7f1673c593983131dad on aviav:add-membership-button-first-specs into 966a98f4b786a2fb3fa7d209346a0b8dd6b40335 on codevise:master.

Coverage decreased (-0.01%) to 99.045% when pulling 018d2ea4c728a671411ff7f1673c593983131dad on aviav:add-membership-button-first-specs into 966a98f4b786a2fb3fa7d209346a0b8dd6b40335 on codevise:master.

Coverage increased (+0.002%) to 99.069% when pulling 696518a05301c7b6380b38493a8c17826bb1315c on aviav:add-membership-button-first-specs into dfc049d6782532e836796a5183afdcabf20b5482 on codevise:master.

Coverage increased (+0.002%) to 99.069% when pulling 81e8c5bc8dfce139d10f5bbfe2c02f46a7696fd4 on aviav:add-membership-button-first-specs into 48b540bc402c1ac04e539e1607daef3a2530b8ab on codevise:master.

Coverage increased (+0.002%) to 99.069% when pulling 81e8c5bc8dfce139d10f5bbfe2c02f46a7696fd4 on aviav:add-membership-button-first-specs into 48b540bc402c1ac04e539e1607daef3a2530b8ab on codevise:master.

Coverage decreased (-0.02%) to 99.048% when pulling 824c8e44ea1c9d584de786635409bf7b47b81106 on aviav:add-membership-button-first-specs into 48b540bc402c1ac04e539e1607daef3a2530b8ab on codevise:master.

Coverage decreased (-0.02%) to 99.048% when pulling 824c8e44ea1c9d584de786635409bf7b47b81106 on aviav:add-membership-button-first-specs into 48b540bc402c1ac04e539e1607daef3a2530b8ab on codevise:master.

Coverage increased (+0.003%) to 99.07% when pulling 824c8e44ea1c9d584de786635409bf7b47b81106 on aviav:add-membership-button-first-specs into 48b540bc402c1ac04e539e1607daef3a2530b8ab on codevise:master.

Coverage increased (+0.003%) to 99.07% when pulling 824c8e44ea1c9d584de786635409bf7b47b81106 on aviav:add-membership-button-first-specs into 48b540bc402c1ac04e539e1607daef3a2530b8ab on codevise:master.

Coverage increased (+0.003%) to 99.063% when pulling 6f5445849e97dc66a3352409bfe2f6ba50872302 on aviav:add-membership-button-first-specs into 3d3480625394e5ec3b2b4f2fc6e9d6241499bded on codevise:master.


GoToDefinition is not available in [metadata] files

VSCode Version: 1.5.2
OS Version: Windows 7 x64

Steps to Reproduce:

Have a C# project with the content:
class Foo
{
    System.Collections.Generic.List<int> bar;
}

Invoke F12 GoToDefinition on List to be taken to the metadata file for List`1 (public class List<T> : IList<T>...

In this file, GoToDefinition is not an option on IList<T> and pressing F12 on it does nothing.

Other language service things like tooltips are also not available.

Tracking as OmniSharp/omnisharp-vscode#771


Bump version of google benchmark to 1.7.1

This fixes issues with thread safety analysis on clang and an unused variable error.
Signed-off-by: Nikolai Morin<EMAIL_ADDRESS>

I understand, then it would probably be for the best if I close this PR and open another one when I get around to it, ok?

I understand, then it would probably be for the best if I close this PR and open another one when I get around to it, ok?

Sounds great, thank you.


Update Cake.Issues

Update Cake.Issues to 0.7.x which is build against Cake 0.33.0

FYI: this will be taken care of automatically by the AddinDiscoverer. When all addins referenced by Cake.Recipe support Cake 0.33.0 the automated tool will submit a PR to upgrade all addins at once and also update the version of Cake used to build Cake.Recipe.
The progress is monitored in #313. As of this writing, two addins are preventing upgrading to 0.33.0: Cake.Graph and Cake.AppVeyor.

@Jericho Cake.Graph have already been updated to Cake 0.33.0, so something seems to be wrong here.
It even say so in the Audit docs as well: https://github.com/cake-contrib/Home/blob/master/Audit_for_Cake_0.33.0.md

@AdmiringWorm thanks for pointing this out. I’ll investigate.

@AdmiringWorm the latest version of Cake.Graph nuget package is marked as prerelease and the AddinDiscoverer specifically excludes prerelease packages as far as updating the references in Cake.Recipe is concerned. Prerelease packages are not excluded in the markdown report you previously linked.
The reason why this nuget package was flagged as prerelease is because it's depending on RazorLight 2.0.0-beta1 which itself is prerelease.
This explains why the addin is indicated as supporting Cake 0.33.0 in the markdown and Excel reports but it is not considered as supporting Cake 0.33.0 as far as updating Cake.Recipe is considered.

On a separate but related note: this is not the first time that prerelease package have caused headaches. I've had several discussions with various people on Gitter and it has come up here, here and here
I also raised an issue a little while ago where I started a discussion about what the AddinDiscoverer should do with prerelease packages. I welcome ideas and feedback.

FYI: new version of AddinDiscoverer has been released and Cake.Graph is now properly considered as "compatible with Cake 0.33.0".
Cake.AppVeyor is now the only addin preventing Cake.Recipe from upgrading to Cake 0.33.0

This has been rebased and merged here: https://github.com/cake-contrib/Cake.Recipe/commit/145432b04265818acd837cd50ebe9a50b91f5623


update firefox download logic for new download system

Yeah, so, this changed:
https://ftp.mozilla.org/pub/firefox/releases/latest/README.txt

:+1:


Feature Request: Delete a word

Thanks for this wonderful plugin. It really helps with Obsidian-craft.
One element I miss from Dynalist and Workflowy was the capacity to blast a hashtag (ALT-enter). While we don't need to mirror that exactly, it would be useful to have a hotkey that could delete a word if the cursor is inside it (including a hashtag). This would be a wonderful pruning tool for the vault.

I like the idea and isn't too hard to implement given the feature set already existing.
Has been implemented in version 1.2 :)


pip install fails by not finding psycopg2-binary==2.8.4

Describe the bug
Running pip install label-studio==1.1.0 in a venv it fails with
WARNING: Discarding https://files.pythonhosted.org/packages/00/7b/a623f49b3248957e7eaaac52eba1117209775d54e7a8501c460473a7ba4f/psycopg2-binary-2.8.4.tar.gz#sha256=3a2522b1d9178575acee4adf8fd9f979f9c0449b00b4164bb63c3475ea6528ed (from https://pypi.org/simple/psycopg2-binary/) (requires-python:>=2.7,!=3.0.*,!=3.1.*,!=3.2.*,!=3.3.*). Command errored out with exit status 1: python setup.py egg_info Check the logs for full command output.
ERROR: Could not find a version that satisfies the requirement psycopg2-binary==2.8.4 (from label-studio) (from versions: 2.7.4, 2.7.5, 2.7.6, <IP_ADDRESS>, 2.7.7, 2.8, 2.8.1, 2.8.2, 2.8.3, 2.8.4, 2.8.5, 2.8.6, 2.9, 2.9.1)
ERROR: No matching distribution found for psycopg2-binary==2.8.4

To Reproduce
Steps to reproduce the behavior:
pip install label-studio==1.1.0
Environment (please complete the following information):

OS: macOS 11.4 (20F71)
Label Studio Version 1.1.0
Python version: 3.9
pip version: 21.2.3

Hey! Got the same issue but found the solution by creating a new conda environment and installing it in it. Worked fine afterwards. Hope it helps

I solved it by using python 3.8 instead.