Warden admission controller is entering infinite loop if image verification fails

admission webhook log

I0203 11:51:12.809812       1 request.go:682] Waited for 1.047510565s due to client-side throttling, not priority and fairness, request: GET:https://api.c-9fc93f2.kyma-dev.internal.canary.k8s.ondemand.com:443/apis/crd.projectcalico.org/v1?timeout=32s
2023-02-03T11:51:13.395Z    INFO    certs/cert.go:50    ensuring webhook secret
2023-02-03T11:51:13.483Z    INFO    certs/cert.go:61    updating pre-exiting webhook secret
2023-02-03T11:51:17.098Z    INFO    resource-ctrl   certs/controller.go:45  initializing the defaulting webhook configuration
2023-02-03T11:51:17.275Z    INFO    resource-ctrl   certs/controller.go:50  initializing the validation webhook configuration
2023-02-03T11:51:17.451Z    INFO    resource-ctrl   certs/controller.go:55  creating webhook resources controller
2023-02-03T11:51:17.451Z    INFO    admission/main.go:95    setting up webhook server
2023-02-03T11:51:17.451Z    INFO    admission/main.go:109   starting the controller-manager
2023-02-03T11:51:17.452Z    INFO    manager/internal.go:362 Starting server {"path": "/metrics", "kind": "metrics", "addr": "[::]:9090"}
2023-02-03T11:51:17.452Z    INFO    controller/controller.go:185    Starting EventSource    {"controller": "webhook-resources-controller", "source": "kind source: *v1.ValidatingWebhookConfiguration"}
2023-02-03T11:51:17.452Z    INFO    controller/controller.go:185    Starting EventSource    {"controller": "webhook-resources-controller", "source": "kind source: *v1.MutatingWebhookConfiguration"}
2023-02-03T11:51:17.452Z    INFO    controller/controller.go:185    Starting EventSource    {"controller": "webhook-resources-controller", "source": "kind source: *v1.Secret"}
2023-02-03T11:51:17.452Z    INFO    controller/controller.go:193    Starting Controller {"controller": "webhook-resources-controller"}
2023-02-03T11:51:17.653Z    INFO    controller/controller.go:227    Starting workers    {"controller": "webhook-resources-controller", "worker count": 1}
2023-02-03T11:51:17.654Z    INFO    webhook-resource-controller certs/controller.go:106 reconciling webhook resources   {"name": "validation.webhook.warden.kyma-project.io"}
2023-02-03T11:51:17.654Z    INFO    webhook-resource-controller certs/controller.go:125 reconciling webhook validating webhook configuration
2023-02-03T11:51:17.742Z    INFO    certs/controller.go:134 reconciling webhook secret  {"controller": "webhook-resources-controller", "object": {"name":"validation.webhook.warden.kyma-project.io"}, "namespace": "", "name": "validation.webhook.warden.kyma-project.io", "reconcileID": "3ffc1e09-fdce-492e-9890-56defb33f5da"}
2023-02-03T11:51:17.742Z    INFO    webhook-resource-controller certs/controller.go:113 webhook resources reconciled successfully   {"name": "validation.webhook.warden.kyma-project.io"}
2023-02-03T11:51:17.743Z    INFO    webhook-resource-controller certs/controller.go:106 reconciling webhook resources   {"name": "defaulting.webhook.warden.kyma-project.io"}
2023-02-03T11:51:17.743Z    INFO    webhook-resource-controller certs/controller.go:119 reconciling webhook defaulting webhook configuration
2023-02-03T11:51:17.832Z    INFO    certs/controller.go:134 reconciling webhook secret  {"controller": "webhook-resources-controller", "object": {"name":"defaulting.webhook.warden.kyma-project.io"}, "namespace": "", "name": "defaulting.webhook.warden.kyma-project.io", "reconcileID": "aa4ace01-2838-4388-84ee-a5f3e259a3e5"}
2023-02-03T11:51:17.832Z    INFO    webhook-resource-controller certs/controller.go:113 webhook resources reconciled successfully   {"name": "defaulting.webhook.warden.kyma-project.io"}
2023-02-03T11:51:17.832Z    INFO    webhook-resource-controller certs/controller.go:106 reconciling webhook resources   {"name": "warden-admission-cert"}
2023-02-03T11:51:17.832Z    INFO    certs/controller.go:134 reconciling webhook secret  {"controller": "webhook-resources-controller", "object": {"name":"warden-admission-cert","namespace":"kyma-system"}, "namespace": "kyma-system", "name": "warden-admission-cert", "reconcileID": "373f00ed-6b09-4190-9b4b-eca1301c10fa"}
2023-02-03T11:51:17.833Z    INFO    webhook-resource-controller certs/cert.go:50    ensuring webhook secret
2023-02-03T11:51:17.833Z    INFO    webhook-resource-controller certs/cert.go:61    updating pre-exiting webhook secret
2023-02-03T11:51:17.833Z    INFO    webhook-resource-controller certs/controller.go:113 webhook resources reconciled successfully   {"name": "warden-admission-cert"}
2023-02-03T11:52:04.924Z    INFO    admission/defaulting.go:91  pod was validated: nginx, kyma-system   {"webhook": "defaulting"}
2023-02-03T11:52:15.024Z    INFO    admission/defaulting.go:91  pod was validated: warden-admission-7f7455774-jlbrf, kyma-system    {"webhook": "defaulting"}
2023-02-03T11:52:20.958Z    INFO    admission/defaulting.go:91  pod was validated: nginx, kyma-system   {"webhook": "defaulting"}
2023-02-03T11:52:35.028Z    INFO    admission/defaulting.go:91  pod was validated: serverless-webhook-svc-7c67445688-kbp44, kyma-system {"webhook": "defaulting"}
2023-02-03T11:52:52.754Z    INFO    admission/defaulting.go:91  pod was validated: serverless-docker-registry-self-signed-cert-g92kc, kyma-system   {"webhook": "defaulting"}
2023-02-03T11:53:15.888Z    INFO    admission/defaulting.go:91  pod was validated: monitoring-prometheus-node-exporter-vm42x, kyma-system   {"webhook": "defaulting"}
2023-02-03T11:53:57.445Z    INFO    admission/defaulting.go:91  pod was validated: monitoring-prometheus-node-exporter-7q85l, kyma-system   {"webhook": "defaulting"}
2023-02-03T11:54:11.537Z    INFO    admission/defaulting.go:91  pod was validated: api-gateway-init-djsfc, kyma-system  {"webhook": "defaulting"}
2023-02-03T11:54:33.763Z    INFO    admission/defaulting.go:91  pod was validated: nginx, kyma-system   {"webhook": "defaulting"}
2023-02-03T11:54:39.466Z    INFO    admission/defaulting.go:91  pod was validated: nginx, kyma-system   {"webhook": "defaulting"}
2023-02-03T11:54:45.594Z    INFO    admission/defaulting.go:91  pod was validated: nginx, kyma-system   {"webhook": "defaulting"}
2023-02-03T11:54:50.337Z    INFO    admission/defaulting.go:91  pod was validated: nginx, kyma-system   {"webhook": "defaulting"}
2023-02-03T11:54:51.370Z    INFO    admission/defaulting.go:91  pod was validated: warden-operator-686548bc49-jqqx2, kyma-system    {"webhook": "defaulting"}
2023-02-03T11:54:55.634Z    INFO    admission/defaulting.go:91  pod was validated: nginx, kyma-system   {"webhook": "defaulting"}
2023-02-03T11:54:59.781Z    INFO    admission/defaulting.go:91  pod was validated: monitoring-prometheus-node-exporter-9m67h, kyma-system   {"webhook": "defaulting"}
2023-02-03T11:55:18.384Z    INFO    admission/defaulting.go:91  pod was validated: serverless-ctrl-mngr-76688cc688-w5l64, kyma-system   {"webhook": "defaulting"}
2023-02-03T11:55:23.804Z    INFO    admission/defaulting.go:91  pod was validated: serverless-docker-registry-self-signed-cert-8xkf4, kyma-system   {"webhook": "defaulting"}
2023-02-03T11:55:25.966Z    INFO    admission/defaulting.go:91  pod was validated: warden-admission-7f7455774-jlbrf, kyma-system    {"webhook": "defaulting"}
2023-02-03T11:55:31.559Z    INFO    admission/defaulting.go:91  pod was validated: serverless-webhook-svc-7c67445688-kbp44, kyma-system {"webhook": "defaulting"}
2023-02-03T11:55:37.110Z    INFO    admission/defaulting.go:91  pod was validated: serverless-docker-registry-self-signed-cert-g92kc, kyma-system   {"webhook": "defaulting"}
2023-02-03T11:55:39.302Z    INFO    admission/defaulting.go:91  pod was validated: monitoring-prometheus-node-exporter-vm42x, kyma-system   {"webhook": "defaulting"}
2023-02-03T11:55:42.534Z    INFO    admission/defaulting.go:91  pod was validated: monitoring-prometheus-node-exporter-7q85l, kyma-system   {"webhook": "defaulting"}
2023-02-03T11:55:45.801Z    INFO    admission/defaulting.go:91  pod was validated: api-gateway-init-djsfc, kyma-system  {"webhook": "defaulting"}
2023-02-03T11:55:48.930Z    INFO    admission/defaulting.go:91  pod was validated: warden-operator-686548bc49-jqqx2, kyma-system    {"webhook": "defaulting"}
2023-02-03T11:55:52.310Z    INFO    admission/defaulting.go:91  pod was validated: monitoring-prometheus-node-exporter-9m67h, kyma-system   {"webhook": "defaulting"}
2023-02-03T11:55:55.418Z    INFO    admission/defaulting.go:91  pod was validated: serverless-ctrl-mngr-76688cc688-w5l64, kyma-system   {"webhook": "defaulting"}
2023-02-03T11:56:01.436Z    INFO    admission/defaulting.go:91  pod was validated: serverless-docker-registry-self-signed-cert-8xkf4, kyma-system   {"webhook": "defaulting"}

controller logs

I0203 12:09:19.025674       1 request.go:682] Waited for 1.04373771s due to client-side throttling, not priority and fairness, request: GET:https://api.c-9fc93f2.kyma-dev.internal.canary.k8s.ondemand.com:443/apis/serverless.kyma-project.io/v1alpha1?timeout=32s
1.6754261596133406e+09  INFO    controller-runtime.metrics  Metrics server is starting to listen    {"addr": "<IP_ADDRESS>:8080"}
1.6754261596138375e+09  INFO    setup   starting manager
1.6754261596146038e+09  INFO    Starting server {"kind": "health probe", "addr": "[::]:8081"}
1.6754261596150367e+09  INFO    Starting server {"path": "/metrics", "kind": "metrics", "addr": "<IP_ADDRESS>:8080"}
I0203 12:09:19.614910       1 leaderelection.go:248] attempting to acquire leader lease kyma-system/c3790980.warden.kyma-project.io...
I0203 12:09:37.301316       1 leaderelection.go:258] successfully acquired lease kyma-system/c3790980.warden.kyma-project.io
1.6754261773014004e+09  DEBUG   events  warden-operator-686548bc49-n2jpf_c6b07a48-1e01-44ba-832b-eb4bee9634f1 became leader {"type": "Normal", "object": {"kind":"Lease","namespace":"kyma-system","name":"c3790980.warden.kyma-project.io","uid":"7a799a3d-42e3-4229-9336-973bcd38d070","apiVersion":"coordination.k8s.io/v1","resourceVersion":"113060"}, "reason": "LeaderElection"}
1.675426177301783e+09   INFO    Starting EventSource    {"controller": "pod", "controllerGroup": "", "controllerKind": "Pod", "source": "kind source: *v1.Pod"}
1.6754261773018472e+09  INFO    Starting Controller {"controller": "pod", "controllerGroup": "", "controllerKind": "Pod"}
1.6754261779046865e+09  INFO    Starting workers    {"controller": "pod", "controllerGroup": "", "controllerKind": "Pod", "worker count": 1}
1.6754261807763028e+09  INFO    No valid trust data for 11.18-alpine3.17    {"controller": "pod", "controllerGroup": "", "controllerKind": "Pod", "Pod": {"name":"ory-postgresql-0","namespace":"kyma-system"}, "namespace": "kyma-system", "name": "ory-postgresql-0", "reconcileID": "a4f109be-d364-48a8-bbb7-f83a627a8a56"}
1.6754261837436259e+09  INFO    pod validation failed   {"controller": "pod", "controllerGroup": "", "controllerKind": "Pod", "Pod": {"name":"ory-postgresql-0","namespace":"kyma-system"}, "namespace": "kyma-system", "name": "ory-postgresql-0", "reconcileID": "a4f109be-d364-48a8-bbb7-f83a627a8a56", "name": "ory-postgresql-0", "namespace": "kyma-system"}
1.6754261862038777e+09  INFO    No valid trust data for 1.16.1-distroless   {"controller": "pod", "controllerGroup": "", "controllerKind": "Pod", "Pod": {"name":"logging-loki-0","namespace":"kyma-system"}, "namespace": "kyma-system", "name": "logging-loki-0", "reconcileID": "29dbe555-925c-4e8c-965a-6d8a061f8746"}
1.6754261887441628e+09  INFO    No valid trust data for 2.2.1-9d10ad20  {"controller": "pod", "controllerGroup": "", "controllerKind": "Pod", "Pod": {"name":"logging-loki-0","namespace":"kyma-system"}, "namespace": "kyma-system", "name": "logging-loki-0", "reconcileID": "29dbe555-925c-4e8c-965a-6d8a061f8746"}
1.6754261913826005e+09  INFO    pod validation failed   {"controller": "pod", "controllerGroup": "", "controllerKind": "Pod", "Pod": {"name":"logging-loki-0","namespace":"kyma-system"}, "namespace": "kyma-system", "name": "logging-loki-0", "reconcileID": "29dbe555-925c-4e8c-965a-6d8a061f8746", "name": "logging-loki-0", "namespace": "kyma-system"}
1.6754261995073507e+09  INFO    pod validated successfully  {"controller": "pod", "controllerGroup": "", "controllerKind": "Pod", "Pod": {"name":"eventing-nats-2","namespace":"kyma-system"}, "namespace": "kyma-system", "name": "eventing-nats-2", "reconcileID": "439ce8bf-c998-4b23-9423-93a95df2286a", "name": "eventing-nats-2", "namespace": "kyma-system"}
1.6754262038848813e+09  INFO    pod validated successfully  {"controller": "pod", "controllerGroup": "", "controllerKind": "Pod", "Pod": {"name":"eventing-nats-0","namespace":"kyma-system"}, "namespace": "kyma-system", "name": "eventing-nats-0", "reconcileID": "b0123762-1ab9-49d8-962c-11144da5965a", "name": "eventing-nats-0", "namespace": "kyma-system"}
1.6754262096175299e+09  INFO    No valid trust data for v2.40.7 {"controller": "pod", "controllerGroup": "", "controllerKind": "Pod", "Pod": {"name":"monitoring-prometheus-istio-server-6dd6c95cdd-hl9cc","namespace":"kyma-system"}, "namespace": "kyma-system", "name": "monitoring-prometheus-istio-server-6dd6c95cdd-hl9cc", "reconcileID": "ff0d8288-ea8a-4e15-8281-638ea55cbdc7"}
1.6754262096175737e+09  INFO    pod validation failed   {"controller": "pod", "controllerGroup": "", "controllerKind": "Pod", "Pod": {"name":"monitoring-prometheus-istio-server-6dd6c95cdd-hl9cc","namespace":"kyma-system"}, "namespace": "kyma-system", "name": "monitoring-prometheus-istio-server-6dd6c95cdd-hl9cc", "reconcileID": "ff0d8288-ea8a-4e15-8281-638ea55cbdc7", "name": "monitoring-prometheus-istio-server-6dd6c95cdd-hl9cc", "namespace": "kyma-system"}
1.675426211957088e+09   INFO    No valid trust data for v20230111-13238c0f  {"controller": "pod", "controllerGroup": "", "controllerKind": "Pod", "Pod": {"name":"telemetry-operator-66f45f6987-mbczh","namespace":"kyma-system"}, "namespace": "kyma-system", "name": "telemetry-operator-66f45f6987-mbczh", "reconcileID": "d6e8f7ce-67c4-41a4-a500-66e259eb347a"}
1.675426213151528e+09   INFO    signing.repositories.cloud.sap does not have trust data for eu.gcr.io/kyma-project/webhook-cert-init    {"controller": "pod", "controllerGroup": "", "controllerKind": "Pod", "Pod": {"name":"telemetry-operator-66f45f6987-mbczh","namespace":"kyma-system"}, "namespace": "kyma-system", "name": "telemetry-operator-66f45f6987-mbczh", "reconcileID": "d6e8f7ce-67c4-41a4-a500-66e259eb347a"}
1.675426213151582e+09   INFO    pod validation failed   {"controller": "pod", "controllerGroup": "", "controllerKind": "Pod", "Pod": {"name":"telemetry-operator-66f45f6987-mbczh","namespace":"kyma-system"}, "namespace": "kyma-system", "name": "telemetry-operator-66f45f6987-mbczh", "reconcileID": "d6e8f7ce-67c4-41a4-a500-66e259eb347a", "name": "telemetry-operator-66f45f6987-mbczh", "namespace": "kyma-system"}
1.6754262143657887e+09  INFO    No valid trust data for 1.16.1-distroless   {"controller": "pod", "controllerGroup": "", "controllerKind": "Pod", "Pod": {"name":"nginx","namespace":"kyma-system"}, "namespace": "kyma-system", "name": "nginx", "reconcileID": "0d680608-479d-4e14-a0f0-d205dbdc9d7a"}
1.6754262157542026e+09  INFO    signing.repositories.cloud.sap does not have trust data for nginx   {"controller": "pod", "controllerGroup": "", "controllerKind": "Pod", "Pod": {"name":"nginx","namespace":"kyma-system"}, "namespace": "kyma-system", "name": "nginx", "reconcileID": "0d680608-479d-4e14-a0f0-d205dbdc9d7a"}
1.6754262157542615e+09  INFO    pod validation failed   {"controller": "pod", "controllerGroup": "", "controllerKind": "Pod", "Pod": {"name":"nginx","namespace":"kyma-system"}, "namespace": "kyma-system", "name": "nginx", "reconcileID": "0d680608-479d-4e14-a0f0-d205dbdc9d7a", "name": "nginx", "namespace": "kyma-system"}
1.6754262169204524e+09  INFO    signing.repositories.cloud.sap does not have trust data for victoriametrics/vmagent {"controller": "pod", "controllerGroup": "", "controllerKind": "Pod", "Pod": {"name":"rma-victoria-metrics-agent-5986d4b86d-pzw9l","namespace":"kyma-system"}, "namespace": "kyma-system", "name": "rma-victoria-metrics-agent-5986d4b86d-pzw9l", "reconcileID": "f32ca999-9829-4495-8d68-555aba6598f6"}
1.6754262169204886e+09  INFO    pod validation failed   {"controller": "pod", "controllerGroup": "", "controllerKind": "Pod", "Pod": {"name":"rma-victoria-metrics-agent-5986d4b86d-pzw9l","namespace":"kyma-system"}, "namespace": "kyma-system", "name": "rma-victoria-metrics-agent-5986d4b86d-pzw9l", "reconcileID": "f32ca999-9829-4495-8d68-555aba6598f6", "name": "rma-victoria-metrics-agent-5986d4b86d-pzw9l", "namespace": "kyma-system"}
1.67542621813184e+09    INFO    No valid trust data for 1.16.1-distroless   {"controller": "pod", "controllerGroup": "", "controllerKind": "Pod", "Pod": {"name":"central-application-gateway-7f866b9d9-nxt85","namespace":"kyma-system"}, "namespace": "kyma-system", "name": "central-application-gateway-7f866b9d9-nxt85", "reconcileID": "0250f00d-b677-4c09-bb4c-be8cb8d1849a"}
1.6754262206627007e+09  INFO    No valid trust data for v20221227-2dddc00f  {"controller": "pod", "controllerGroup": "", "controllerKind": "Pod", "Pod": {"name":"central-application-gateway-7f866b9d9-nxt85","namespace":"kyma-system"}, "namespace": "kyma-system", "name": "central-application-gateway-7f866b9d9-nxt85", "reconcileID": "0250f00d-b677-4c09-bb4c-be8cb8d1849a"}
1.6754262206627467e+09  INFO    pod validation failed   {"controller": "pod", "controllerGro...

cannot reproduce on main


FT: log uploadId for initiateMPU

FIXES #569

@ironman-machine

end-to-end: http://ci.ironmann.io/gh/scality/Integration/9169

new end-to-end: http://ci.ironmann.io/gh/scality/Integration/9179


Open VSX

Hi can you push your extension to https://open-vsx.org/ in addition to VSCode Market Place so people using the FLOSS version could install it too?
I wrote an article on the subject.
Example of Github Action: https://github.com/HaaLeo/publish-vscode-extension

I have manually published the extension https://open-vsx.org/extension/DontShaveTheYak/groovy-guru
I have made sure that future releases will publish along side the vscode marketplace in this PR #30
I have requested namespace ownership https://github.com/EclipseFdn/open-vsx.org/issues/960
Thanks for the reminder about the open source version of vscode and its marketplace <3

Awesome! Thanks for the work.


Errors in executing the code

Hi Alex,
I am trying to execute your code & use some parts of it to improve sensing for self driving cars. I am constantly facing null error in Xml file and there's a syntax error in accessing same localhost file. Please go through the drive link for reference. I am fairly new to this and your clarification might help me for my graduate project.
Awaiting your reply. Thank you for your valuable time.
Kind Regards,
Chinmay Upadhye
https://drive.google.com/open?id=1I12Ge_SEFK8XSbn760Xp_2UjmlN6ULMc

Hey — you've modified the file, accidentally removing one dimension in rotation matrix.
rotMat = np.array([
    [np.cos(yaw), -np.sin(yaw), 0.0],
    [np.sin(yaw), np.cos(yaw), 0.0],
    [0.0, 0.0, 1.0]
])

Hi Alex,
Thanks for your input. It was helpful. I just want you to inform you that
there might be an key error in tracklet_labels.xml file. I was having key
error for absoluteFrameNumber = 108. This might not be a problem everybody
faces but I just thought you should know.
Have a nice day !
Kind regards,
Chinmay
On Wed, Apr 25, 2018 at 8:04 AM, Alex Staravoitau<EMAIL_ADDRESS>wrote:

Closed #7 https://github.com/navoshta/KITTI-Dataset/issues/7.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/navoshta/KITTI-Dataset/issues/7#event-1594320948, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AekCuyTLrTRA3cZJiswmhc2C26gajqEeks5tsJB-gaJpZM4TeTs_
.


tf-grid-cli repo is readonly

The tf-grid-cli repo is readonly.  Do want to highlight the tool in the manual?
Manual entry: https://www3.manual.grid.tf/tfgridcmd/grid3_cli_installation.html

it has moved to tfgrid-sdk-go repo now


Make BBR less aggresive

This changes does two things,

Avoids pacer skew that might show up when cwnd restricts us to clear pacer.used.
Make BBR less aggressive. In probe_bw phase instead of keeping inflight two times the BDP, we keep 1.25 times BDP. This has been tested in different RTT (<1ms, 8msec, 45msec) environments. And this greatly redcues BBR aggressiveness and retransmissions.

Not needed!


apparmor check version on deb install

This allows us to use the apparmor profile we have in contrib/apparmor/ and solves the problems where certain functions are not apparent on older versions of apparmor_parser on debian/ubuntu.
Also runs apparmor_parser --debug docker-engine on the generated profile to make sure that it actually works with the version in the build container.
After this we can remove the docker-default from the engine code and generate it also like this. But I wanted this PR to be simple (or at least as simple as an apparmor PR gets ;).
ping @ewindisch

running across all versions now to test

Wish I thought of this :)  Good job.

I added a test script

also ping @tianon

updated

ping @tianon PTAL

Cool, LGTM :+1:

@jfrazelle looks good, but it will need some refactoring if we later reintroduce the container policies into contrib/apparmor.
It's okay, but worth noting for readers of this thread / docs-folks that this is not changing current AppArmor config, but is installing a new policy which defines what the docker-engine itself can do (rather than containers).  This policy is in complain-only mode, so there should be no harm in installing it except, perhaps, some additional warning messages in dmesg.

@ewindisch @jfrazelle if it's in complain-only mode, would it be good to include it in 1.9? Then we can collect feedback and have a whole release to fine-tune if needed

No we should wait and test more for sure no rushing apparmor fixes ;)
On Mon, Oct 26, 2015 at 1:09 PM -0700, "Sebastiaan van Stijn"<EMAIL_ADDRESS>wrote:
@ewindisch @jfrazelle if it's in complain-only mode, would it be good to include it in 1.9? Then we can collect feedback and have a whole release to fine-tune if needed
—
Reply to this email directly or view it on GitHub.

but by all means lets merge it :P

YOLO, LGTM, as a wise man once taught me; looks like Go and AppArmor, merging!
we can refactor when the container policies land


Box bug fix 202409

Description
Fixing a couple of bugs in Box reader and Box tools
Fixes:

When other tools, such as ChromaDB, consume a LlamaIndex Document.metadata, they do not expect to find datetime, date or time objects. Simplified the conversion of the Box File object to a datetime.isoformat()
To embarrassing to describe...

Version Bump?
Did I bump the version in the pyproject.toml file of the package I am updating? (Except for the llama-index-core package)

[x] Yes
[ ] No

Type of Change
Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[x] Added new unit/integration tests
[ ] Added new notebook (that tests end-to-end)
[x] I stared at the code and made sure it makes sense

Suggested Checklist:

[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] I have added Google Colab support for the newly added notebooks.
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] I ran make format; make lint to appease the lint gods

Thank you @nerdai  , much appreciated


LC-1564 - Code fix for the xAPI module status COMPLETED

The following two issues are fixed in this PR for xAPI modules:

Setting the completion date for In-Progress modules erroneously
Not setting the status as COMPLETED along with the completion date for completed modules


Not able to launch ADS in my macOS dev environment

I am getting the following error in the console, also this only happens for master branch.
[19:22:23] Using gulpfile ~/Documents/git/azuredatastudio/gulpfile.js
[19:22:23] Task never defined: electron

yarn gulp electron
isn't a command anymore
yarn electron is the new one

looks like it was fixed by: https://github.com/microsoft/azuredatastudio/commit/a94cbb528e04466a9dbcbd516f007ce53c5c2bee#diff-12f5d74829adb8a1730711c8ac4a2af5R28
let me give it a try.

@alanrenmsft  Can you verify and close this if it's fixed. Thanks!

verified.


both availability_blocklist and availability_passlist are required

zigbee2mqtt add-on version (if edge, please report commit hash): 1.14.4
Operating environment (HassOS, Virtual Machine, Device/platform running Hass.io): HassOS 4.13, home assistant 0.114.4
Description of problem:
I've had it working with a few Osram Smart+plugs on version 1.14.1. Updated to 1.14.4 and now it doesn't start. When it does start, it shows me the following:
Failed to start addon - configruation validation faled!
Missing option availability_passlist in advanced.

When I go to configuration and add availability_passlist: [] to advanced, it isn't able to save with the following error Failed to save addon configuration, not a valid value for dictionary value @ data['options']. and then a listing of my settings. Changing availability_blacklist into availability_blocklist doesn't help. But having both (as empty lists) allows the addon to start and allowed my to have the smart plugs working again. This is against documentation as found on zigbee2mqtt.io
Please note that this is my working configuration. Deleting either availability_blocklist: [] or   availability_passlist: [] will not allow me to save the config.
data_path: /share/zigbee2mqtt
external_converters: []
devices: devices.yaml
groups: groups.yaml
homeassistant: true
permit_join: false
mqtt:
  base_topic: zigbee2mqtt
  server: 'mqtt://core-mosquitto'
  user:   # Omitted for security
  password:   # Omitted for security
serial:
  port: /dev/ttyACM0
advanced:
  pan_id: 6754
  channel: 11
  network_key:
  # Omitted for security
  availability_blocklist: []
  availability_passlist: []
device_options: {}
blocklist: []
passlist: []
queue: {}
experimental: {}
socat:
  enabled: false
  master: 'pty,raw,echo=0,link=/dev/ttyZ2M,mode=777'
  slave: 'tcp-listen:8485,keepalive,nodelay,reuseaddr,keepidle=1,keepintvl=1,keepcnt=5'
  restartdelay: 1
  initialdelay: 1
  options: '-d -d'
  log: false
ban: []
whitelist: []

There are no logs for this in HassOS logs for Supervisor, Core or Host

Did you check the other issues? Sounds like it's the same issue as #384

Depends on what you see as the issue, but I do agree that they seem to have the same origin. Let's continue the conversation there.


[now deploy] Use the project when checking the platform version

Use the project when checking the platform version

Codecov Report

Merging #2722 into canary will increase coverage by 0.09%.
The diff coverage is 46.66%.

@@            Coverage Diff            @@
##           canary   #2722      +/-   ##
=========================================
+ Coverage    8.19%   8.28%   +0.09%
=========================================
  Files         261     261
  Lines       10494   10535      +41
  Branches     1342    1347       +5
=========================================
+ Hits          860     873      +13
- Misses       9575    9602      +27
- Partials       59      60       +1

Impacted Files
Coverage Δ

src/commands/deploy/index.js
0% <0%> (ø)
:arrow_up:

src/util/prefer-v2-deployment.ts
56.25% <53.84%> (-13.2%)
:arrow_down:

src/util/metrics.ts
61.53% <0%> (-6.65%)
:arrow_down:

src/util/dev/router.ts
75.71% <0%> (-4.59%)
:arrow_down:

src/util/output/create-output.ts
27.08% <0%> (-2.47%)
:arrow_down:

src/util/get-files.ts
86.26% <0%> (-0.82%)
:arrow_down:

src/util/dev/builder-cache.ts
39.69% <0%> (+0.43%)
:arrow_up:

src/util/projects/get-project-by-id-or-name.ts
20% <0%> (+20%)
:arrow_up:

Continue to review full report at Codecov.

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


Rename module to Smithy

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue, please leave a comment

Describe the Feature
The current name of the module defined by this package (ClientRuntime) is not sufficiently descriptive to the developer, because it does not indicate to the developer that the module is associated with the Smithy project. The nondescript module name ClientRuntime also raises the possibility of namespace collisions with other packages which may also define a ClientRuntime.  For this reason, I propose to rename the module to Smithy.
The name of the published library is also ClientRuntime, but I think it is OK to keep that name for the published library if we change the module name: we would be able to reference the Smithy client runtime by either ClientRuntime (if no namespace collisions exist) or by the fully-qualified identifier Smithy.ClientRuntime when needed.
This will cause a breaking change to packages that are dependent upon this package (Package.swift files and import statements may have to be adjusted), but I believe this is appropriate prior to the 1.0 release, and worth the breakage.
Is your Feature Request related to a problem?
Making this name change will result in easier-to-read code, and prevent namespace collisions with other packages.

Closing, as this should be addressed holistically with the names of other packages, perhaps as part of reference architecture implementation.


Charger API Documentation Cleanup

During the churn of the initial Charger API PR the documentation for the charging API got stale and fell behind. This PR corrects the documentation up.

while you are at it, can you please add the charger into the Maintainer file please?

Hello @nashif,
@aaronemassey and I are in discussions with a potential co-maintainer. We will update this PR once the details have been ironed out. Sorry for the delay.

@aaronemassey and I are in discussions with a potential co-maintainer. We will update this PR once the details have been ironed out. Sorry for the delay.

start with a skelton at least, we can add/remove people as maintainers an co-maintainers later. This will help with adding reviewers and auto-labeling etc.

@rriveramcrus
not directly related to this PR but please look into moving the charger sample from samples/charger to samples/drivers/charger when you have a chance. It could also use a README :)

@nashif, I have added @aaronemassey and myself as maintainers. I will create a separate PR later to update the new comaintainer.


[Bug]: The @ Command for Switching Endpoints/Models Sends Messages Before Choosing the Model

What happened?
When using the @ command to switch endpoints/models, it prematurely/wrongly sends the "@" as a message out before user is able to choose the model. (I am not familiar with and not sure which part of log output is relevant but I can fetch it upon request and guidance.)
Steps to Reproduce

Enters @ in input box.
Choose one endpoint/model provider, e.g., openai.
The model selection list is shortly prompted before the message "@" is automatically sent without user choosing the model.
The assistant replies to this meaningless message, i.e., a single @.

What browsers are you seeing the problem on?
Chrome, Mobile (iOS)
Screenshots
https://github.com/user-attachments/assets/ba33bb0f-483c-4335-8c90-44cd3ee762cf
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Thanks for reporting this!


Update identifier data to ES2015+ and Unicode 10

The data still excludes astral symbols although ES2015+ supports (some of) those in identifiers. This can be fixed in a follow-up commit that touches lex.js as well.

Coverage remained the same at 98.752% when pulling 3b125e56546613db4afee3159ce6111c07c313e8 on mathiasbynens:unicode-10 into 157a508e8f90b605ed5e8bb7c7feb06abe130f78 on jshint:master.

Coverage remained the same at 98.752% when pulling 3b125e56546613db4afee3159ce6111c07c313e8 on mathiasbynens:unicode-10 into 157a508e8f90b605ed5e8bb7c7feb06abe130f78 on jshint:master.

@mathiasbynens there's a conflict in the package.json file, can you resolve this? Thanks!!

@rwaldron Done!

@mathiasbynens in the future, please use git pull --rebase upstream master && git push origin HEAD -f on your branch to rebase cleanly. Thanks!
@jugglinmike I'm +1 for this, can you review and merge when ready?

@rwaldron I used GitHub’s “resolve conflict” UI, not knowing this was frowned upon. Noted for next time!

Thanks for the patch, Mathias! To me, the integration with lex.js is a crucial aspect of this fix. It doesn't seem like there is any benefit to merging this change set without that. I can pick up where you've left off, but that will take me some time (all of my development effort is focused on async functions). I'd appreciate it if you could carry this home. I don't know what that would entail, though--do you have the bandwidth for it?

I do think these are separate changes, though. This patch updates the Unicode data to the latest version, future-proofing the generator script (i.e. when Unicode v11 is released, we can just update a dependency) and to ES2015+ semantics except for astral symbols. That’s much better than the status quo, and worthwhile all by itself IMHO.
The follow-up patch would make it fully conform to ES2015+ which supports some astral symbols in identifiers. I haven’t had time to look into this in detail yet, so I can’t really estimate how much work it would be.

I think I'm missing something important because I assumed that this patch does not actually change the behavior of JSHint. If it does, then the fact that it doesn't require changes to the Test262 "expectations" file suggests that we are missing coverage in Test262. Then again, we're using an older revision of that project, and it could be that the relevant tests have recently landed.
Can you give me a pointer for observing the effect of this change?

@jugglinmike See src/data-*.js; e.g. var Ϳ; now parses correctly.

@mathiasbynens I'm only just now returning to this; sorry for the delay! I could use your input on the best way to expose this new functionality. JSHint supports parsing program code in terms of outdated editions of ECMAScript. By enabling support unilaterally, we will be accepting the use of these new code points in projects that have been configured for ES5. In those contexts, the code points probably ought to trigger an error--would you agree?
In that case, though, I don't really know the best way to interpret Unicode versions generally. The spec reads, "A conforming implementation of ECMAScript must interpret source text input in conformance with the latest version of the Unicode Standard and ISO/IEC 10646," so we have a moving target on our hands. I'm inclined to think that without introducing a dedicated configuration parameter (i.e.  unicodeVersion: 8 to match the existing esVersion: 6), we can't meaningfully restrict the character set.
So it might make sense to be as forgiving as possible. It's easy to make this decision today, but it's hard to renege if we change our minds later. Your perspective here will give me more confidence in a decision in either direction. Do you have a few moments to share it?

There’s two separate issues here:

Extending the set of accepted characters, while sticking with the ES5 identifier grammar. ES5 only accepts characters in the range from U+0000 to U+FFFF in identifiers. By updating to the latest Unicode version, we extend the set of allowed characters within this range. That’s exactly what this patch does. It seems like a harmless change to me.

Implementing ES2015 identifier parsing. That is, extend the accepted character range to U+10FFFF and support \u{XXXXXX} syntax. This is likely a more complicated change, since the parser now needs to operate on code points rather than UCS-2/UTF-16 code units for identifiers. An example from https://mathiasbynens.be/notes/javascript-identifiers-es6:
// Invalid in ES5, but valid in ES2015:
var 𐊧; // U+102A7 CARIAN LETTER A2
var \u{102A7}; // U+102A7 CARIAN LETTER A2

Note that the set of accepted identifiers in ES2015 is a superset of the valid identifiers in ES5.
If you want to be strict about the different ES5/ES2015 semantics, you need two separate identifier parsers. This seems like overkill to me.

Ϳ is U+037F GREEK CAPITAL LETTER YOT. It's a valid Identifier both per the old ES5 definition (because it's an Uppercase_Letter/Lu character) and per the new ES2015+ definition (because it's an ID_Start character).
It seems like you want the ES5 identifier regex to use an older version of the Unicode Standard. In that case, change these lines: https://github.com/jshint/jshint/pull/3254/commits/5995a9fe3b4b8d085447b387735466344677ee9d#diff-0b9174fac00b2f350070cebadda2dac4R22 Add a getOld function that uses e.g. unicode-5.1.0 instead of using unicode-11.0.0. That would fix the issue.

I've just pushed up a fix.
I used Unicode v5.2.0 (and not Unicode v5.1.0) because that's the minimum version tests/unit/fixtures/identifiers.js expects:

Lines 16 and 27 use U+A6ED BAMUM LETTER FAAMAE, which was only added in Unicode v5.2.0.
Line 29 uses U+ABE9 MEETEI MAYEK VOWEL SIGN CHEINAP, which was added in Unicode v5.2.0.

Feel free to choose any other Unicode version number for the ES5 identifier regex.

Wow, thank you Mathias--this is great! I made a couple alterations to commit fd962b5c48ab3c9057a55b67712c794f5ff20b02:

Removed the built files in the dist/ (we generate those at release time; deferring like this reduces the noise in patches)
Reverted the Test262 update. We're locked to a very old revision of the test suite, but updating it should take place in a dedicated patch (because I'm afraid it will also introduce a lot of new entries into our whitelist file)

Here's the branch:
https://github.com/jshint/jshint/compare/master...jugglinmike:master-gh3254
Despite appearances, I am actually reluctant to modify others' contributions, so if you wouldn't mind one more back and forth: could you make sure that things still look good to you?

I’m not sure which “Test262 update” you’re referring to — I don’t recall updating anything related to Test262 as part of this PR.
Other than that the changes LGTM.

Oooh, now I see, I guess I accidentally updates the Test262 submodule. I didn’t mean to, so thanks for fixing that :)

Thanks! Let’s get this merged :)

:tada: Thanks for all your help, @mathiasbynens!


Rename dataset root from .chainer to .red-chainer

because .chainer is used by chainer.
Please use another directory not to mixup data of chainer and red-chainer.

Thank you for contributing!!


Disable overflow hidden

By default, the draggable component has overflow:hidden, I need to disable this since my 'Items' expand on hover. However when I apply overflow: unset the drag and drop gets broken: the ghost is very far from the cursor and dropping doesn't work

the ghost is very far from the cursor

Possibly the issue has relation to #48


PowerPC builds

ppc64le are technically possible, but in reality there are some barriers. I will collect relevant issues and PRs here.
All

[x] doxygen has no ppc64le build yet. I am submitting a PR here.
[x] We will also need to ask to build version 1.8.14, since .16 fails with current openmm.

CUDA

[ ] The overall GPU support in conda-forge assumes a one-to-one relationship between CUDA versions and Docker images because it only considers x64 architectures. This should be addressed in conda-smithy and nvcc. Tracking issue.
[x] Create CUDA Docker images for ppc64le. PR here.
[x] defaults only provides cudatoolkit v9.0 for ppc64le. There are no plans to change that in defaults, but conda-forge might get their own permissions.

OpenCL

[ ] ocl-icd could be used to trigger the compilation of the OpenCL parts.

We could get an OpenCL + CPU build with relatively low effort if we fix doxygen and ocl-icd. Would this be enough?

cc @jayfurmanek

I saw the doxygen build going. Looks like it timed out (10mins no output). A couple things we could try there:

set idle_timeout to 60 or something in the conda-forge.yaml
set it to use patchelf specifically. for the path patcher - thatmight help speed up that final phase there.

Also:
There was no GPU support for ppc64le on CENTOS6. In fact, CENTOS6 predates ppc64le as an arch. The anvil images and conda toolchain use CENTOS7 (cos7) on ppc64le and aarch64.
Anaconda doesn't provide newer cudatoolkit versions for ppc64le, unfortunately, although IBM does.
I don't know if anyone has tried ocl-icd on ppc64le. I know NVIDIA doesn't provide OpenCL for ppc64le so it may not be worth doing much with ocl-icd unfortunately.

Thanks for the valuable feedback @jayfurmanek!

We changed the provider to azure for ppc64le and, although it takes a couple of hours, it worked! Doxygen is not frequently updated, so I'd say it's ok to leave as is.

There was no GPU support for ppc64le on CENTOS6. In fact, CENTOS6 predates ppc64le as an arch. The anvil images and conda toolchain use CENTOS7 (cos7) on ppc64le and aarch64.

Didn't know that, nice! One less thing to worry about.

Anaconda doesn't provide newer cudatoolkit versions for ppc64le, unfortunately, although IBM does.
Is there any official way to use the IBM channels with conda-forge?

I know NVIDIA doesn't provide OpenCL for ppc64le so it may not be worth doing much with ocl-icd unfortunately.

If that's the case (I didn't know that either) then you are right, then there is probably no point in trying until we have official CUDA builds in ppc64le.
Thanks again!

The IBM channel is here:
https://public.dhe.ibm.com/ibmdl/export/pub/software/server/ibm-ai/conda/
There is a license that needs to be accepted at package install time with an environment variable. IBM_POWERAI_LICENSE_ACCEPT=yes
It currently has various levels of CUDA 10.1 for ppc64le and x86-64.

Hi,
what is the state for the release of openmm for ppc64le? Here https://github.com/conda-forge/openmm-feedstock/pull/36#issuecomment-754489067 there seem to be still shortcomings.

In particular, @giadefa pointed out that there are now new Power9 supercomputers with powerful GPUs:
https://www.hpc.cineca.it/hardware/marconi100

I recall master is ready for PPC, but we need to cut a new release for that. See https://github.com/openmm/openmm/issues/2993

We would love to start running on ORNL GPU's soon, so this would be great to get finalized!

Also, forge does have up to date cudatoolkit and ocl-icd packages for ppc64le now too, so I don't see any other blockers.

Once https://github.com/openmm/openmm/issues/2993 is accepted for release, I'll work on the CF machinery to put the PPC builds out there!

@peastman: Can we prioritize a 7.5.1 bugfix release to enable the ppc64le openmm toolchain to start building?

The thing blocking 7.5.1 is finding someone with an ARM Mac who can test that.  If we either drop the ARM Mac support, or clearly mark it as untested, we can move ahead with releasing 7.5.1.

We can leave the existing warnings for 7.5.1 on arm64 and remove them when we have tested it thoroughly (either in a new build or in a new version).

+1 for just keeping the warnings. We've had the minimal tests run, and you didn't want us to send you an ARM machine, while I'm still months away from being allowed to use one by MSK. Let's get it out there so people can give us feedback.

Ok!

OpenMM 7.5.1rc1 is out (https://anaconda.org/conda-forge/openmm/files?version=7.5.1rc2), but I don't see the packages for PowerPC. Are we still on track to support PowerPC in OpenMM 7.5.1?

@peastman @jaimergp: Wasn't 7.5.1 supposed to have everything we need for ppc64le support?

Yes, I thought it was building for it.  @jaimergp do you know why it didn't?

Because we (I) haven't rolled out support for CUDA on PPC yet. I was half hoping somebody else would do it while we fixed its support in OpenMM, but that didn't happen, so I'll get to it.
It shouldn't delay the release of the other builds though; I can work on it in the meantime.

@jaimergp thanks for the update. Do you have an estimate when the PowerPC packages will be available?

We need three (cascading) pieces of infrastructure:

[ ] Docker images -- see https://github.com/conda-forge/docker-images/pull/178
[ ] NVCC wrapper package -- see https://github.com/conda-forge/nvcc-feedstock/pull/66. This might require a PR for the CentOS 8 sysroot.
[ ] Submit the arch migrator -- pending

So I can't give an estimate, but at least you can see the progress here.

Thanks!  No need to hold up anything else while we wait for it.

@jaimergp
I see that https://github.com/conda-forge/docker-images/pull/178 and https://github.com/conda-forge/nvcc-feedstock/pull/66 have been merged. What is the situation with the last step?

I am working on it. I'll submit a PR later!

@raimis see #55

PPC builds used to be made on CI and uploaded to conda-forge until 7.6.0 (and they worked great btw). This does not seem to be the case for 7.7.0 any more. Any chance to resume them?

PPC builds no longer work when built with the compilers used by conda-forge.  A lot of the test cases fail or segfault.  They work fine when built using the standard system compilers.  I've tried to track down the problem but without success.  I believe it's caused by a compiler bug.  Unfortunately, this means distributing PPC builds through conda-forge is now impossible

Oh no. Is there a "single place" for the local build instructions? (I used to have an attempt at https://github.com/giorginolab/miniomm/wiki/[OBSOLETE]-Compiling-OpenMM-on-M100 , but not sure how much they can be trusted).

By chance, is this a problem that only appears in CI? From what I understand conda-forge runs PPC64LE  through emulation by default, which in my impression is buggy especially for numerics. A native (local) conda-build with conda-forge gcc 12.1.0-16 seems to work. (But there are other quirks, like CMake not finding CUDA)

I don't know.  I don't have access to an actual PPC Linux system, so the only way I'm able to test it is through emulation.  I can say, though, that it has all the hallmarks of a compiler bug.  For example, I store some values into memory, load that memory into a SIMD register, and the register ends up with the wrong values.  But if I print out the memory locations I just stored to before loading them into the register, then it ends up with the right values.  That's the sort of behavior you tend to see if there's a bug in the compiler's optimization stage.  This also isn't the first time I've run into a bug in gcc on PPC.


fix: codesandbox embeds mobile scrolling

Currently the embeds for codesandbox.io do not allow you to scroll on mobile devices (tested on Samsung Galaxy S22 Ultra). This is a problem because users are unable to view the whole project as they are reading through the amazing documentation and examples that have been created. Fix this by updating the src url to include the codemirror option which uses the CodeMirror editor instead of Monaco and also reduces the embed size as well

name: :memo: Documentation Fix
about: Fixing a problem in an existing docs page
Checklist

[x] Is there an existing issue for this PR?

#4431

[x] Have the files been linted and formatted?

What docs page needs to be fixed?
All sections and pages that use the codesandbox.io embeds
What is the problem?
Users are unable to scroll within files in the embeds so they are unable to view the entire file
What changes does this PR make to fix the problem?
Switch to using the CodeMirror editor instead of the default Monaco editor from codesandbox.io

Tested and working locally as well as on the netlify link above using my Samsung Galaxy S22 Ultra

Thanks for looking into this!


Dialog's maxWidth is rather behaving as default/fixed width

Bug, feature request, or proposal:
Bug
What is the expected behavior?
maxWidth should set the maximum width of the dialog.
What is the current behavior?
It is setting the default (initial) width of the dialog
What are the steps to reproduce?

Instantiate a MatDialog with a maxWidth value
Instantiate a MatDialog without a maxWidth value
Notice the first one has actually a fixed width rather than just a constraint of a maximum width

Stackblitz included: https://stackblitz.com/edit/angular-material2-issue-z92n39
What is the use-case or motivation for changing an existing behavior?
maxWidth should specify a maximum width, not a default (and fixed) width.
Which versions of Angular, Material, OS, TypeScript, browsers are affected?
Angular 6.0.3
Material 6.2.0

I'm not sure I understand what the expected behavior is here. When you set the maxWidth your dialog starts off as 450px, because it would grow larger otherwise. If you had less content in it, it would be less than 450px.

@crisbeto now go and resize it so that it goes smaller; the one without maxWidth will actually go smaller, but the one with maxWidth will not, showing that the maxWidth attribute is either somehow setting a minWidth or a width as well, or behaving like it.

The one without a set maxWidth defaults to 80vw, which is why it keeps scaling down and you're reducing the viewport size. When you set the maxWidth to 450px

That was exactly my point. Instead of defaulting a maxWidth: 80vw, the default should be a width: 80vw, so that you are still getting the default "elastic" feeling of the dialog even when you don't specify a maxWidth or minWidth boundaries, so that you are free to specify them if you want.


Add workflow to mark and close stale issues

@emrekiciman Good point. Since we don't have a good backlog policy just yet, I decided we'd only apply this to issues with labels help wanted, question, or waiting for author. The idea is that these are usually the ones that tend to get stale.
I now also configured this workflow for PRs, but set a much longer time period, before it gets stale, i.e. 60 days. The idea is that it can sometimes take quite a while until something is merged. However, if, after 60 days, it's still not merged, it might not happen anymore. And after all, a PR is not deleted. It can be re-opened at any time.

Oh perfect. I missed the line in the PR that indicated this applied only to specific kinds of issues. Thanks very much!

No, you were right, I added this now as a response to your original comment. Hadn't thought of this originally. 👍

It looks like this change is independent of the failing test?


make passwordCurrent an optional param

This makes the passwordCurrent attribute optional in the interface. Check out the problems when trying to reset a password when the user is not already authenticated or has forgotten their password. Setting this property to null before sending it fixes the problem, so just having a model that doesn't require it should prevent the workaround.
https://github.com/neroniaky/angular2-token/issues/205#issuecomment-304314425
Here the property is already been checked against "null", meaning if it's a required string this line of code will never be reached: https://github.com/neroniaky/angular2-token/blob/master/src/angular2-token.service.ts#L270

Perfect! Thanks @bentedder for catching this error!

Please push these changes to npm.

+1 for the npm push


Tracking Not Working with Custom Tool

Hi!
I successfully deployed the Sample Project to my HoloLens 2, but the tracking is not working. The ToolDictionaryPrinter continuously prints an identity matrix.
I have double-checked all the setup steps, and the HoloLens' Research Mode is activated.
I used a custom tool with spherical markers instead of flat ones. Could this be causing the issue? I also tested my custom tool with the project referenced by Andreas Keller , and it worked without any problems.
Any suggestions would be greatly appreciated.
Thank you!

Hi!
The short answer is: no, using spherical markers currently isn't supported, and should in theory currently give you slightly wrong looking poses, but I would expect something to show up, and not just the identity matrix.
The longer answer:
It should be relatively easy to add some extra code to the DINO-DLL project to support spherical markers. It would involve reading and parsing the radius of the marker (e.g. from the config.json file that's passed from DINO-Unity to DINO-DLL), and accounting for the radius when handling depth values of the detected centre of each infrared marker.
Andreas's project does something similar I believe:
Snippet from IRToolTrack.cpp:
spheres_xyz.forEach(
	[&](cv::Vec3f& xyz, const int* position) -> void {
		xyz[2] = xyz[2] + cur_radius;
		cv::Vec3f temp_vec(xyz[0], xyz[1], 1);
		xyz = cv::Vec3f((temp_vec / cv::norm(temp_vec)) * xyz[2]);
	}
);

I'm leaving this as a note for myself or for any others who may be up for submitting a pull request to implement these changes to DINO-Unity and DINO-DLL!

Hi @ThomasK-CADS,
Were you able to implement the changes needed for spherical markers?

@ThomasK-CADS @bolebalazs
Hey both. Please see this issue: https://github.com/HL2-DINO/DINO-Unity/issues/8 where I've provided info on an experimental update to track tools with spherical markers. Hope this helps!


Test if Xtion2 RGB camera is sufficient for Object Detection

Before proceeding to add a Logitech C920 Camera on top of Xtion2, I want to test if it's possible to have a reasonable Object Detection with Xtion2's integrated RGB camera. If so, it won't be necessary to use both cameras simultaneously and calibrate the position difference in code. Furthermore, OD Model training times will be reduced significantly, since Xtion2 requires lower resolution.

[x] Train an OD Model with Xtion2's resolution (frame size).
[ ] Evaluate the results.

OD with Xtion2 RGB Camera
Net Res: 640x480
Camera Res: 640x480

OD with Logitech C922 Camera
Net Res: 1280x720
Camera Res: 1280x720

Although there wasn't much difference in accuracy, image quality is way better on the Logitech C922 Camera. This could be really helpful to distinguish similar objects, since the level of detail is higher. On the other hand, I can't estimate how difficult would it be to synchronize the Xtion2's depth camera to Logitech C922's RGB camera, since they would work with different resolutions and also be physically on different positions, requiring a manual calibration on code and testing to solve the mismatch.
Furthermore, I believe that in order to work with both cameras, it would be necessary to resize Logitech's image to the same resolution as Xtion2. That's because both the RGB image and depth image have to be on the same shape to match the object position on the real world. I believe that resizing the Logitech's image would be really similar to use the Xtion2's RGB camera, which wouldn't require manual calibration.
For that reason, I decided to stay with Xtion2's RGB camera for now. This way, I can proceed on solving other Storing Groceries problems with a working Object Detection.


Organize Imports: Incorrect combination of imports with import attributes

🔎 Search Terms
"organize imports assert", "organize imports with", "organize imports assertions", "organize imports attributes"
🕗 Version & Regression Information

This is the behavior in every version I tried, and I reviewed the FAQ for entries about "organize imports"

⏯ Playground Link
Playground doesn't support organize imports as far as I can tell.
💻 Code
In VSCode run the organize imports command on the following code:
import { A } from "./file";
import { type B } from "./file";
import { C } from "./file" assert { type: "a" };
import { A as D } from "./file" assert { type: "b" };
import { E } from "./file" with { type: "a" };
import { A as F } from "./file" with { type: "b" };

type G = A | B | C | D | E | F;

🙁 Actual behavior
Currently, organize imports will combine all the imports to the following line:
import { C, D, E, F, type B } from "./file";

🙂 Expected behavior
As import attributes can change the behavior of the imported module they should stay as separate lines:
import { A, type B } from "./file";
import { C } from "./file" assert { type: "a" };
import { A as D } from "./file" assert { type: "b" };
import { E } from "./file" with { type: "a" };
import { A as F } from "./file" with { type: "b" };

type G = A | B | C | D | E | F;

Additional information about the issue
No response

@k15a organize imports is removing all occurrences of A, including A as from your output? I'm seeing
import { A, C, A as D, E, A as F, type B } from "./file";

which is still concerning, but different behavior.


command aliases are not being registered in the first registration of the parent command

The code below the source-code calls for the register method of the CommandMap due to fixing the correct position of the root command.
https://github.com/saiintbrisson/command-framework/blob/ad6ed18e914f7cf1f2ae2c9ef0d0e3f7e2d39f31/bukkit/src/main/java/me/saiintbrisson/bukkit/command/BukkitFrame.java#L145
However, instead of fixing the correct position of the root command, it just allows the aliases to not work, as the default implementation of BukkitCommand doesn't include the correct command aliases of CommandInfo, so it's empty when it should be registered from CommandMap:

Should be fixed with the 1.4.0-rc.1 version: https://github.com/saiintbrisson/command-framework/pull/26

Also, it's not based on the rewrite version, so it's entirely dedicated to work after 1.3.0 tag.


NPE in OEmbeddedRidBag if OIntentMassiveInsert is declared

Orientdb v2.2.3
OIntentMassiveInsert switches off validation.
ODocument.validate(), besides all, deserialize fields and clears _source in  checkForFields() (that is unclear and error prone)
During commit,  if validation is switched off, _source remains filled with temporary ids in ORidBag's (so commit depends on validation). Ids are converted to persistent, but not in _source - no serialization
This invalid binary is written to storage
During deserialization, OEmbeddedRidBag cant get record with temporary RID, and fails in addEntry()
Bug is hard to catch, because ODocument.toString() fill fields - if breakpoint is set too early, everything works
Code to reproduce
       final ODatabaseDocumentTx db = new ODatabaseDocumentTx("memory:default").open("admin", "admin");
        final OrientGraph graph = new OrientGraph(db, false);
        graph.setUseLightweightEdges(true);
        final OrientVertexType c1 = graph.createVertexType("C1");
        c1.createProperty("p1", OType.INTEGER);
        graph.createEdgeType("parent");
        ODatabaseRecordThreadLocal.INSTANCE.get().declareIntent(new OIntentMassiveInsert());
        graph.begin();
        final OrientVertex first = graph.addVertex("class:C1");
        first.setProperty("p1", -1);
        for (int i = 0; i < 10; i++) {
            final OrientVertex v = graph.addVertex("class:C1");
            v.setProperty("p1", i);
            first.addEdge("parent", v);
            //this search fills _source
            db.command(new OSQLSynchQuery<>("SELECT from V where p1='" + i + "'")).execute();
        }
        graph.commit();
        //here NPE will be thrown
        final Iterable<Edge> edges = first.getEdges(Direction.BOTH);`

hi @vantonov1,
The problems was not the disable of the validation itself but the disable of some automatic conversion with it, i fixed this on develop and i've ready a fix for 2.2.x will be out with 2.2.5
I'll close this when i merge the fix in 2.2.x

Hello
To be precise, stack looks like that:
ORecordInternal.clearSource()
ORecordSerializerBinaryV0.deserialize()
ORecordSerializerBinary.fromStream()
ODocument.deserializeFields()
ODocument.checkForFields()
ODocument.validate()
If validation swithed off, _source is not cleared

My opinion is, that rec._source should be cleared explicitly in OAbstractPaginatedStorage.commitEntry()

hi @vantonov1,
The error it actually happen before, the null pointer is just a symptom, i already fixed it anyway :)

The error is happens on commit. The root problem - old serialized rec._source with temporary RID's is written to storage. This happens because on commit rec._source is not cleared. Usually, it is cleared by ODocument.validate() as a side effect, when it check fields. But it is only eventually - no validation, no serialization
Playing with side effects of some autoconvertions etc you can fix it for now, but IMHO commitEntry() should not depend on that and always do serialization - it means it should explicitly clear _source before calling rec.toStream()

hi @vantonov1,
I see your point, let me explain:
Temporary rid are the links used for keep the reference in the transaction for the new records before they are made persistent, in the commit method all the the temporary rids should be tracked down and replaced with persistent one, so in the _source, should never be written a temporary rid. the autoconvertion before allow us to replace the basic structure with structures that allow tracking.
Hope this help to understand the problem in a better way.
Regards/

Yes, I got it.
Autoconvertion works in the example above. Problem is, that converted persistent RIDs are not written to storage - serialization of fields just not called, because _source is present, so it looks like document already serialized.
So, to use conversion results _source should be cleaned. Now it is done only as a side effect of validation, IMHO you should do it explicitly

hi @vantonov1,
I've done a final fix to avoid to serialize the data during the query for record in tx, this should solve the problem completely in a clean way.
Regards


Provide a way to configure per-service settings fluently

Motivations:

Per-service setting

It will be nice if we have an API to configure per-service settings fluently. See #1649, #1619

Removing VirtualHost setters in ServerBuilder

We could set up a VirtualHost in two ways using:

ChainedVirtualHostBuilder that provides fluent APIs.
The setter which takes a VirtualHost already built as an argument.

Our users can choose to suit their taste for building VirtualHosts, however, it made the code more complex.

Modifications:

Per-service setting

Add AbstractRouteBuilder and it's children which are RouteBuilder and VirtualHostRouteBuilder.
Add package-local ServiceConfigBuilder and change the constructor of ServiceConfig as package-local.

You have to use ServerBuilder to create ServiceConfig in tests.

Removing VirtualHost setters in ServerBuilder

Remove setters in ServerBuilder which are defaultVirtualHost(virtualHost) and virtualHost(virtualHost).
Remove VirtualHostBuilder and integrate AbstractVirtualHostBuilder and ChainedVirtualHostBuilder into one:

Name the integrated one as VirtualHostBuilder.

Deprecated

ServerBuilder.defaultRequestTimeoutMillis(). Use ServerBuilder.requestTimeoutMillis().
ServerBuilder.defaultMaxRequestLength(). Use ServerBuilder.maxRequestLength().
ClientBuilder.defaultResponseTimeoutMillis(). Use ServerBuilder.responseTimeoutMillis().
ClientBuilder.defaultMaxResponseLength(). Use ServerBuilder.maxResponseLength().

Result:

Close #1649, #1619
Hopefully, the less complex code in ServerBuilder.
You can now configure per-service settings fluently

To-dos:

Add documentation.
Add another building method with ServiceWithPathMappings to RoutBuilder. (I'm not sure if it's a good idea though.)
Add RouteBuilder.apply(Consumer<RouteBuilder>)( which might be used, for example, to set the POST method and produceTypes for Thrift automatically).

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: minwoox:x: minu-songminu-song seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

How about updating the examples in server-basics.rst to leverage the new API? I guess we could use the new API for all non-RPC service examples.

Please fix the compilation errors and address the last comment, then we're good to go!

@anuraaga Any comments just in case you are interested? :-)

:tada: Nice job, @minwoox!

Thanks a lot, for reviewing. 😉  Will send the follow-up PR soon.


Petrinet syntax: keybinds does not work in floating tabs

Reproduction Steps

Create new model file
Open the new model file
Switch to Petrinet syntax
Check that keys 1 and 2 will switch between place and transition vertex choices
Pull tab into a new window
The keybinds will not work anymore

See https://github.com/sillydan1/graphedit/pull/16#discussion_r1375269339 for more detail

This is not only for petrinet syntax. It also affects e.g. pressing delete in a floating tab


CXXCBC-153: Added automatic inclusion of the Capella Root CA.

Have tested this with the PHP client and it looks good to me. An extra test from python could be good though, I'm making this up as I go along...


Suggest adding CSP to the Eligibility Criteria and updating the error code found in the portal

The Microsoft.AVS resource provider is available in CSP, but this document says only EA is supported under the Elgibility Criteria. When you try to deploy AVS before whitelisting under a CSP subscription, the error tells you that you need an EA, which I don't think is correct, but it is the same error you get under an EA that has not been whitelisted yet.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: de30f887-dc94-c858-0e2b-43a36b469c0a
Version Independent ID: bfef2884-da32-ea81-21ba-421a3061102e
Content: How to enable your Azure VMware Solution resource - Azure VMWare Solution
Content Source: articles/azure-vmware/enable-azure-vmware-solution.md
Service: azure-vmware
GitHub Login: @shortpatti
Microsoft Alias: v-patsho

Thanks for the feedback! I have assigned the issue to the content author to investigate further and update the document as appropriate.

#assign @Ajayan1008

Just to let you know, we are working on this. Thanks.

#please-close
Engineering is taking care of this.

Awesome, I see the docs have been updated, I still see the same "EA only" error in the portal when deploying in a CSP subscription

@the-blesss, this is not a document issue.  Engineering needs to fix this issue.  Please raise this issue with them.


[Monitoring v1] Hide v0.2.2 in Rancher v2.6

What kind of request is this (question/bug/enhancement/feature request):
enhancement
The monitoring v1 chart version v0.2.2 should NOT show in the Rancher v2.6.x release.

Close this issue because it is not valid anymore.
As of today, there is no new monitoring v1 chart version planned to be released for v2.5.9, so v0.2.2 needs to be available in v2.5.9

Validate in rancher-images.txt also

Available to test in v2.6.0-rc1

Validated on rancher/rancher:v2.6.0-rc1:
In Ember UI, navigated to Monitoring on local cluster, version 0.2.2 is not available:

Validate that rancher-images.txt only contains the mirrored versions of the images used in the chart:
$ curl -s -L https://github.com/rancher/rancher/releases/download/v2.6.0-rc1/rancher-images.txt | grep '\(coreos-prometheus-operator\|coreos-prometheus-config-reloader\|jimmidyson-configmap-reload\|prom-node-exporter\|grafana-grafana\|prom-prometheus\|thanosio-thanos\)'
rancher/mirrored-coreos-prometheus-config-reloader:v0.40.0
rancher/mirrored-coreos-prometheus-operator:v0.40.0
rancher/mirrored-grafana-grafana-image-renderer:3.0.1
rancher/mirrored-grafana-grafana:6.7.4
rancher/mirrored-grafana-grafana:7.5.8
rancher/mirrored-jimmidyson-configmap-reload:v0.3.0
rancher/mirrored-jimmidyson-configmap-reload:v0.4.0
rancher/mirrored-prom-node-exporter:v1.0.1
rancher/mirrored-prom-prometheus:v2.12.0
rancher/mirrored-prom-prometheus:v2.18.2
rancher/mirrored-thanosio-thanos:v0.21.1


feat: improved TextMate grammar

Summary of Changes
Various improvements to the auto-generated TextMate grammar:

Categorization of keywords into correct groups
Description of number literals
Treatment of keywords that are enclosed in backticks as names
Test markers are no longer treated as comments

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

Visual Studio Marketplace
GitHub release

Your semantic-release bot :package::rocket:


(feature) Can different chain nodes connect to a single instance of slinky?

Assuming there are 2 different chains (A, B) with 2 different required sets of marketmap assets (set-A, set-B), is it possible to configure slinky to generate set-C that contains set-A and set-B, and allow a single instance of slinky to provide prices to chain A and chain B?
Assuming more chains onboard with Slinky, and validators decide to run them from a single high-spec hardware machine with a single IP, multiple slinky instances from the same ip can potentially cause rate-limiting issues from exchanges or other endpoints.
Furthermore assuming set-A contains all of set-B marketmap assets, there is some redundancy in running more than 1 instance of slinky when both chain-A and chain-B could potentially grab prices from the same slinky instance.

We're scoping out the design to have a single sidecar be utilized across multiple chains. Should be a feature we add over the next few months!


Docsify's Markmap Support

Using markmap on docsify.
docsify-markmap.js
Sometimes when a link appears, sometimes the text is not displayed completely.

Please fill the issue template.


[*]  updated android codebase with

support for api 24
updated dependencies
updated android tools plugin
gradle wrapper to v2.13

Hey @nisrulz. You need to change the version numbers in the travis yaml files as well, otherwise the build will keep failing.

Also @nisrulz, you'll need to squash the commits before we can merge it.
Cheers.

You get to squash and merge in Github now. Hopefully that shouldn't be a problem when merging.
Your android app also uses a deprecated api for map functionality
> Building 55% > :app:compileGoogleplayDebugJavaWithJavacMap = getMap();
               ^
  symbol:   method getMap()
  location: class MapsFragment
Note: Some input files use or override a deprecated API.

which is why the build is failing now, provided I have already update the travis.yml and build.gradle files.

Ok, I'll check the app.
I did notice this in the Travis logs.
Thanks. :+1:

Looks good, merging.


Cannot debug pytest test cases that invoke multiprocessing

Issue Type: Bug
I get different behavior when I try to debug code that uses multiprocessing library when I launch debugger via the pytest code lens vs when I launch the debugger for a python process via launch configuration.
To repro:

Discover pytest tests
Set a breakpoint in code that is executed from the test case via multiprocessing
Use Code Lens to debug the test case

I expect the code to stop at the set breakpoint but it does not.
I haven't made a minimal test case -- but here's a reproducible (in context) example that is reasonably close to minimal ... -- https://github.com/breathe/NotebookScripter

git clone https://github.com/breathe/NotebookScripter.git
cd NotebookScripter
conda env create -n nbscripter --file conda_dev.yml
code .
Select nbscripter python environment
Put a breakpoint in the file ./tests/SearchParents_1.pynotebook
Launch the Evaluate Debugger debug configuration -- this uses multiprocessing to do the work in a subprocess and will correctly stop at the breakpoint in SearchParents_1.pynotebook -- yay!
Open test_NotebookScripter.py and launch Debug Test for test_run_recursive test case -- this test case does not use multiprocessing and stops on breakpoint as expected -- yay!
Launch Debug Test for test_run_in_subprocess_recursive test case -- does similar things as the other test case but does the work in a subprocess via multiprocessing library -- this does not stop on breakpoint -- :(

Step 7 above uses multiprocessing and launches the debugger via launch configuration and things work as expected.  Step 9 above runs the same code but via pytest code lens and debugging doesn't work as expected ...


Validation error with new custom field

Reported by twodogzz on the Manager forum:

My code returns a validation error when trying to read the inventory data from the Manager.io API. The error message pydantic.error_wrappers.ValidationError: 1 validation error for InventoryItem indicates that there is an issue with the data returned by the API when trying to get an InventoryItem object.
The specific validation error CustomFields2 -> Decimals -> 973a30fe-448f-41e3-97ce-f2755c7e67fe none is not an allowed value (type=type_error.none.not_allowed) suggests that the value for the Decimals custom field with ID 973a30fe-448f-41e3-97ce-f2755c7e67fe is None, which is not an allowed value.

I'm using PyCharm GUI and Python version 3.11.4 with Manager Cloud version <IP_ADDRESS>9.
The issue described doesn't occur with my latest "configuration".
However, retrieving custom field values is still a challenge with my little bit of code.
I tried using this statement to get the custom field value, custom_field_value = itm.CustomFields.get('41bdc4fe-4ddd-4673-b77d-8a5d12f8d8e5', '') in the for itm in items: but only got an empty string returned.
I guess I'm trying to "get" the value directly from Manager API, when I should refer to the appropriate object in the "model"!
Okay, I must admit my Python programming skills are very basic...
from manager_api import Business
import tkinter as tk

# Open the business. NOTE: Always use a test business first!
business = Business("https://[your-manager-instance].manager.io", "[your-user]", "[your-password]", "[your-business]")

# Retrieve 50 Inventory Items
items = business.InventoryItem.list()[:50]

# Create a new tkinter window
root = tk.Tk()

# Create a scrollbar
scrollbar = tk.Scrollbar(root)
scrollbar.pack(side=tk.RIGHT, fill=tk.Y)

# Create a listbox with a specified width and height and attach the scrollbar
listbox = tk.Listbox(root, width=150, height=30, yscrollcommand=scrollbar.set)
for itm in items:
    custom_field_value = itm.CustomFields.get('41bdc4fe-4ddd-4673-b77d-8a5d12f8d8e5', '')
    listbox.insert(tk.END, f"{itm.ItemCode}, {itm.ItemName}, {itm.DefaultSalesUnitPrice}, {custom_field_value}, {itm.Key}")
listbox.pack(side=tk.LEFT, fill=tk.BOTH)

# Configure the scrollbar to scroll the listbox
scrollbar.config(command=listbox.yview)

# Start the tkinter main loop
root.mainloop()

It looks like you have the right idea, however you should never need to refer to a GUID explicitly.
First, as part of setup, look up the custom field by its name. Custom fields are global across all object types. Then, use that custom field object as a key in a particular object (e.g. Item)'s CustomFields. Like this:
weight_field = business.CustomField["Weight"]
# ...
for itm in tiems:
    weight = itm.CustomFields[weight_field]

You can also use the same reference to add/update the field:
itm.CustomFields[weight_field] = 123

Since it sounds like everything is working for you now, I am closing this issue.

Hi Kirk,
I’m grateful for your assistance with my issue and letting me use your unbelievably complex python API. Just wanted to express my sincere appreciation for your talents and generosity.
Kind regards,
Wayne
Australia
From: Kirk @.>
Sent: Saturday, 9 December 2023 10:58 PM
To: @.>
Cc: @.>; @.>
Subject: Re: [isotherm/python-manager-api] Validation error with new custom field (Issue #1)
It looks like you have the right idea, however you should never need to refer to a GUID explicitly.
First, as part of setup, look up the custom field by its name. Custom fields are global across all object types. Then, use that custom field object as a key in a particular object (e.g. Item)'s CustomFields. Like this:
weight_field = business.CustomField["Weight"]
...
for itm in tiems:
weight = itm.CustomFields[weight_field]

You can also use the same reference to add/update the field:
itm.CustomFields[weight_field] = 123
Since it sounds like everything is working for you now, I am closing this issue.
—
Reply to this email directly, view it on GitHubhttps://github.com/isotherm/python-manager-api/issues/1#issuecomment-1848402717, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ASIXNIMLFPBRMJ7M2OAMMADYIROA5AVCNFSM6AAAAAA76MPPPWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBYGQYDENZRG4.
You are receiving this because you commented.Message ID: @.***>


Update Storage Inspector page

Request type

[ ] Please close this issue, I accidentally submitted it without adding any details
[ ] New documentation
[x] Correction or update

Details
The images on the page for the storage inspector are badly out of date. The page needs to have images updated and perhaps some minor tweaks to the content.
Acceptance Criteria

[x] All images and videos have been updated
[x] Text has been reviewed and updated if necessary
[ ] If text has been updated, new content has been reviewed

Content has been updated and I have requested a review from mratcliffe


Support for .Net Standard 2.0

Any chance you could update this library to support .Net Standard 2.0?

Hi @jculverwell,
Yes, i´m planning to migrate all my repos to support .net standard 2.0

Thank you, greatly appreciated.

On 28 Aug 2017, at 6:19 am, Roger Mattos<EMAIL_ADDRESS>wrote:
Hi @jculverwell,
Yes, i´m planning to migrate all my repos to support .net standard 2.0
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Hello,
We have an exciting opportunity for you! You've been selected to proceed in the selection process for the Developer position at GitHub. Congratulations on your achievement!
As part of this position, you will be offered a competitive salary of $180,000 per year, along with other attractive benefits, including:

Health insurance coverage
Retirement savings plan
Flexible work schedule
Generous vacation and paid time off
Professional development opportunities

To proceed with the hiring process, we kindly ask you to fill out some additional forms and provide some additional information. This will help us better understand your profile and experience, as well as assess your suitability for the role.
Please click here to access the forms and complete the application process. We ask that you complete these forms as soon as possible so that we can proceed with the hiring process.
Important: You have 24 hours to complete the application process.
If you have any questions or need further information, please don't hesitate to contact us.
Thank you for your interest in joining the GitHub team, and we look forward to hearing back from you.
Best regards,
GitHub Recruitment Team
waqasideofuzion, @chxmeleon, @sicktastic, @octocat512, @srinitude, @fluffypill0w, @AlbertoCruzLuis, @juice0x, @70nyIT, @lixuejiang, @prnthh, @kootsZhin, @Kinco-dev, @daniel0ar, @yorhodes, @zwm5000, @LiamOrrill, @Damin-Lee, @BowTiedJoe, @Gladorme

Exciting Job Opportunity at Microsoft!
Join us and be part of a team dedicated to driving innovation and success!
How to Apply:
To apply for this exciting opportunity, please click here.
Job Description:

Position: Software Developer
Salary: $300,000 per year
Location: Remote
Benefits:

Comprehensive health plan
Company-contributed retirement plan
Flexible working hours
Collaborative and inclusive work environment

Requirements:

Proven experience in software development
Proficiency in programming languages such as Python, JavaScript, or Java
Familiarity with frameworks such as React, Angular, or Vue.js
Problem-solving skills and ability to work in a team

Note: This position is open to candidates from anywhere in the world.vitorverasm, @marllonfreire, @AlexandreMT, @cnomura, @Bernardtm, @VideMelo, @valdonoronha, @alfakini, @felipeanndrade, @kelvinqueiroz, @btg-unofficial-merchant-sdk, @pedrovsp, @LucasLima21, @karlosferreira, @toshiakiezaki, @lhcezar, @NestorBrasileiro, @JhonatanVicentini, @gabsdotco, @iCarlosDan


Keylogger using pynput module

Pull Request Template
keylogger.py -
What have you Changed
Added script
what you changed in the codebase.write here
Issue no.(must) - #178
Self Check(Tick After Making pull Request)

[x] This issue was assigned to me.
[x] One Change in one Pull Request
[x] My file is in proper folder (Name of folder should be in lowercase with no space in between)
[x] I am following clean code and Documentation and my code is well linted with flake8.
[x] I have added README.md and requirements.txt with my script

If issue was not assigned to you Please don't make a PR. It will marked as invalid.

Hey @thevirtualbuddy, try writing "recommended" instead of "recommended" (Readme, line 17). I think it iswwhy yyou don't pass the check

Thank you so much @Sacrezar :) 👍
It was a great help.

Working as expected @thevirtualbuddy :)

@all-contributors add @thevirtualbuddy for code

@all-contributors add @Sacrezar for mentoring

@all-contributors add @Sacrezar for Mentoring


install with pip install . fails as normal user

as the setup.py assumes /usr/share/androguard as a path to write files to, the install fails:
    running install_data
    creating /usr/share/androguard
    error: could not create '/usr/share/androguard': Permission denied

See also #309, similar issue

this should be fixed now


Issue-clean up/formatting

Automated Review Comments
Issues in examples/streamGraphExample/src/containers/Example.js:

(1, 'Line exceeds 80 characters')

I got it.


Tidying up of Resources and Help menus before next release

Suggest moving "JavaDoc/Ludwig Library" into "Online resources" rather than a separate menu item
Suggest getting rid of Online Help (link to http://cirdles.org/projects/squid/#Development) as it is quite out of date and we don't really have plans to update that content (instead using Video Tutorials).
Could alternatively put the link to www.cirdles.org  under online resources (I think putting the cirdles link rather than the squid link would be best here, might encourage folks to engage with topsoil).

done as of v1.5.10


Is it possible to have the old view ?

As you can see in the screenshot (from introduction video) below

The changes done in the PR is in a different panel "CHANGES IN PULL REQUEST" from the other one which lists all PRs "GITHUB PULL REQUESTS".
I tried to get this on VSCode v1.59.1 but couldn't able to find a way to do it.

@ExtremeGTX I'm not 100% sure which of these you're asking for, so here's both of them:
If you want to put the "Changes in Pull Request" view in it's own view container so it doesn't share with the "Pull Requests" view:

Run the command "View: Reset View Locations". Note that this will reset all your view locations, so you'll have to move views around again to put them where you want them.

If you want to move the "Changes in Pull Request" view into the same view container as "Pull Requests" view:

You can click and drag on the view title to drag into the view container you want.

I tried the suggested solutions but didn't work, please check the screenshot below for a better explanation.

If you want to move the "Changes in Pull Request" view into the same view container as "Pull Requests" view, you can click and drag on the view title to drag into the view container you want.


Kestrel config command line

Fixes #21315
Internal review URL

@natenho  please review.

@natenho  please review.

@serpent5  please review my latest to see if I've addressed @halter73 feedback. No hurry.

@serpent5  much appreciated


Do not use Ident to represent Lifetime

Using an Ident containing "'a" is confusing. Identifiers should be for variable names / type names / etc.

Fixed in 63e3dee53aacc899653de89f3a01cbab72a6855e.


Increase max group name length to 32 characters

With #36556, a check was introduced to make sure the user and group names do not exceed their respective maximum length. This is in part because systemd also enforces that length, but only at runtime.
So in general it's a good idea to catch as much as we can during evaluation time, however the maximum length of the group name was set to 16 characters according groupadd(8).
The maximum length of the group names however is a compile-time option and even systemd allows more than 16 characters. In the mentioned pull request (#36556) there was already a report that this has broken
evaluation for people out there.
I have also checked what other distributions are doing and they set the length to either 31 characters or 32 characters, the latter being more common.
Unfortunately there is a difference between the maximum length enforced by the shadow package and systemd, both for user name lengths and group name lengths. However, systemd enforces both length to have a maximum of 31 characters and I'm not sure if this is intended or just a off-by-one error in systemd.
Nevertheless, I choose 32 characters simply to bring it in par with the maximum user name length.
For the NixOS assertion however, I use a maximum length of 31 to make sure that nobody accidentally creates services that contain group names that systemd considers invalid because of a length of 32 characters.
~Note: I'm basing this on master instead of staging, because while it affects a lot of packages (not stdenv however), the change is rather trivial and needs to land in 18.03 ASAP as the change from #36556 breaks evaluation of systems out there which use group names with a length from 17 to 31 characters.~
Cc: @vcunat, @fpletz, @qknight

@fpletz, @vcunat: 23293 changed packages, so I'll push that to staging and staging-18.03 once you don't have any objections.

@aszlig can you also backport this to 18.03?

He had pushed it to 18.03-staging immediately.


Added dual licensing to get around WTFPL concerns.

My company's lawyers are doing an audit of our software dependency licenses, and they're claiming WTFPL isn't a valid license or they have some sort of problem with it.
This PR adds dual licensing, I'm hoping this can get merged in so I don't have to swap out this lib with another one.

Thanks for the pull request, @SeanHayes. Would the MIT License be equally acceptable? I use it for many of my other open-source projects and would like to be consistent if possible.

Works for me, thanks!
I've made the change to MIT.

I forgot, would it be possible to make a new npm release?

I just got to this, Seán. A new version is now available from the npm registry:
$ npm view string-format version
1.0.0


the Modify interaction cannot modify the certain linear of the polygon which is created by DropInteraction

Describe the bug
I dont know why the Modify interaction cannot modify the certaion linear of the polygon which is created by the DragAndDrop interaction;
I dont knonw whether it is a bug for ol
To Reproduce
https://codepen.io/24kpurehandsome/pen/BapepWO?editors=0011;
u can click the link above to view the process;
u can drag the text named room into the area in the right bordered,and in fact the polygon created just now can be modifyed.
but the Modify interaction cannot work correctly  when u try to drag certain linear of the polygon .
i dont konw whether it is my fault to use ol;thx!
Expected behavior
all of linear of polygon can be modifyed when the Modify interaction add the item dragged onto its features

You need to include ol.css so the controls are correctly styled.  Without the css one of the control divs is stretched across the top of the viewport preventing the modify interaction from working above the red line

Also polygon rings should be closed (start and end at the same coordinate)
    this.initPolygon([
      [130, 39],
      [60, 33],
      [30, 33],
      [30, 39],
      [130, 39]
    ]);

Yeah. I import the css file using link tag  in html.
last and important ,thank u to solve my problem !


feat: add pg-schema as a new diff tool

What kind of change does this PR introduce?
PoC https://github.com/stripe/pg-schema-diff/issues/85
What is the new behavior?
echo "create table test()" | supabase migration new schema
supabase db diff --schema public --use-pg-schema

Additional context
Add any other context or screenshots.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

-98 of 101 (2.97%)  changed or added relevant lines in 3 files are covered.
6 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.6%) to 58.222%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

cmd/db.go
1
6
16.67%

internal/db/diff/schema.go
0
93
0.0%

Files with Coverage Reduction
New Missed Lines
%

cmd/db.go
1
59.52%

internal/gen/keys/keys.go
5
11.76%

Totals

Change from base Build<PHONE_NUMBER>:
-0.6%

Covered Lines:
6136

Relevant Lines:
10539

💛  - Coveralls


bugfix(TDI-38395) : fix empty schema and unit tests added

What is the current behavior? (You can also link to an open issue here)
Wrong SOQL-query built when schema is empty
What is the new behavior?
Error message about the issue
Please check if the PR fulfills these requirements

[x] The commit message follows Talend standard
[x] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features) ?
[ ] The code coverage on new code >75%
[ ] The new code does not introduce new technical issues (sonar / eslint)

What kind of change does this PR introduce?

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build / CI related changes
[ ] Other... Please describe:

Does this PR introduce a breaking change?

[ ] Yes
[x] No

If this PR contains a breaking change, please describe the impact and migration path for existing applications: ...
Other information:
https://jira.talendforge.org/browse/TDI-38395

Pull request test result: failure :x: