[Celia/Phil] Option to select 'coaches' or 'carriages'

It would be good to have the option in both the announcement generator and in Live Trains to select if you want it to announce as 'coaches' or 'carriages'.

There's no file for carriages in the ones we have, its only coaches.

Correct, but I did rip out my own "carriages" for Celia from another audio file:
https://github.com/Rail-Announcements/ketech-llpa-announcements/blob/main/custom/Female1/e/carriages.mp3


chore(proto): move optimistic block protos to v1

Summary
This updates the protos used for the auctioneer to be based on the new v1 protos.
Background
We bumped our proto definition versions from v1alpha_ to v1.
Changes

Moved the sequencerblock/optimistic_block file into its own subpackage in order to have sequencerblock.v1.optimisticblock.v1alpha1
Updated to use FilteredSequencerBlock from v1

Breaking Changelist

This shouldn't break anything as none of these protos are used by anything in main currently.

closes

auctioneer isn't shipped yet, maybe this should stay v1alpha1 for now?

The auctioneer stuff remains v1alpha1 here, it is just updated to use the correct (v1) version of everything else.
see: https://github.com/astriaorg/astria/pull/1707/files#diff-816642b078e8e91f48aba99b3f04ffaed46960ef63a4c8d22ae068ffebd9d6f7R3

Have to push back on this naming convention. v1 sequencer block with v1alpha1 optimistic block? We should have probably not nested the optimistic block bits under sequencerblock in this way, but provided a structure like in the protocol APIs.
I am not sure how to best tackle this, but I feel like going with astria.optimisticblock.v1alpha1 (i.e. a sibling instead of a child) that imports astria.sequencerblock.v1 is more natural.
Would like to pull @joroshiba into this.

This is unfortunately lacking an entry in CHANGELOG.md and also imports the wrong code.


Possible Minor Bug: Trailing characters after closing ``` for GHFM fenced code block interpreted differently

Hey,
When adding Markdown to Github issue, if the closing line contains characters after the closing ``` then GitHub does not end the fenced code block, as in:
NSString *str = @"Hello, world!";
```xxx

However, MMMarkdown does end the fenced code block in this case, consuming the trailing xxx after the closing ```:
    NSString *markdownInput = @"```\nNSString *str = @\"Hello, world!\";\n```xxx";
    NSString *htmlOutput = [MMMarkdown HTMLStringWithMarkdown:markdownInput extensions:MMMarkdownExtensionsTables|MMMarkdownExtensionsFencedCodeBlocks|MMMarkdownExtensionsUnderscoresInWords error:NULL];
    NSLog(@"For input '%@' got output '%@'", markdownInput, htmlOutput);

produces
2015-01-27 18:17:31.434 MarkdownTestMM[81350:7765794] For input '```
NSString *str = @"Hello, world!";
```xxx' got output '
NSString *str = @"Hello, world!";

'

Notice how the trailing xxx after the closing ``` got consumed by MMMarkdown.
I'm not sure which is the "reference implementation" of GHFM - the parsing in GitHub issues or the parsing in MMMarkdown.  But the two parsers behave differently in this case.
The documentation on GHFM is ambiguous about this case: see https://help.github.com/articles/github-flavored-markdown/ .  This doesn't mention what should happen if characters follow the closing ```.
Personally, I favor your approach: I think consuming the xxx trailing the ``` is the best and least-confusing-to-users approach.  But it differs from what GitHub web GHFM parsing does.
So I just wanted to point this out.  I guess it's not so much a bug as a difference in interpretation of the ambiguity in the standard here.
Not trying to be nitpicky, this is just a friendly heads up.  :-)
Best wishes.

Thanks for the report! I changed the behavior to match GitHub's markdown.


Random restart leads activation screen

I read the issue posting guidelines.
Random restart lead to the phone booting to activation screen, after unlocking all apps user apps were deleted but none of the texts/pictures were deleted. The Yalu102 app is gone but cydia and Ifile still there. This was on a Iphone 6 IOS 10.1.1
about ten minutes later the phone restarted and all apps are back as if nothing ever happened....

so what are you trying to do

Did you try touching your mac address or uuid?
Any tweaks?

No tweaks, when it happened I had just used Yalu102 was about 2 minutes after being jailbroken. I'm not trying to do anything I was just posting an issue that I ran into

had this happen before, unsure what may be causing this. has no side effects after rebooting.

no side effects at all other then the apps being in different spots, first time it has happened


ABN import error

While doing from modules import ABN, SingleGPU  I'm getting an error with the following traceback:
Do you have any recommendations how to handle this error?
    from modules import ABN, SingleGPU   File "/home/fedor.kitashov/test_pytorch_10/inplace_abn/modules/__init__.py", line 1, in <module>     from .bn import ABN, InPlaceABN, InPlaceABNSync   File "/home/fedor.kitashov/test_pytorch_10/inplace_abn/modules/bn.py", line 10, in <module>     from .functions import *   File "/home/fedor.kitashov/test_pytorch_10/inplace_abn/modules/functions.py", line 18, in <module>     extra_cuda_cflags=["--expt-extended-lambda"])   File "/home/fedor.kitashov/anaconda3/envs/pytorch10_cuda10_env/lib/python3.6/site-packages/torch/utils/cpp_extension.py", line 645, in load     is_python_module)   File "/home/fedor.kitashov/anaconda3/envs/pytorch10_cuda10_env/lib/python3.6/site-packages/torch/utils/cpp_extension.py", line 814, in _jit_compile     with_cuda=with_cuda)   File "/home/fedor.kitashov/anaconda3/envs/pytorch10_cuda10_env/lib/python3.6/site-packages/torch/utils/cpp_extension.py", line 838, in _write_ninja_file_and_build     check_compiler_abi_compatibility(os.environ.get('CXX', 'c++'))   File "/home/fedor.kitashov/anaconda3/envs/pytorch10_cuda10_env/lib/python3.6/site-packages/torch/utils/cpp_extension.py", line 162, in check_compiler_abi_compatibility     if not check_compiler_ok_for_platform(compiler):   File "/home/fedor.kitashov/anaconda3/envs/pytorch10_cuda10_env/lib/python3.6/site-packages/torch/utils/cpp_extension.py", line 138, in check_compiler_ok_for_platform     which = subprocess.check_output(['which', compiler], stderr=subprocess.STDOUT)   File "/home/fedor.kitashov/anaconda3/envs/pytorch10_cuda10_env/lib/python3.6/subprocess.py", line 356, in check_output     **kwargs).stdout   File "/home/fedor.kitashov/anaconda3/envs/pytorch10_cuda10_env/lib/python3.6/subprocess.py", line 438, in run     output=stdout, stderr=stderr) subprocess.CalledProcessError: Command '['which', 'c++']' returned non-zero exit status 1.
pytorch was install using:
conda install pytorch torchvision cudatoolkit=10.0 -c pytorch
GCC:
Package: gcc
Version: 4:7.3.0-3ubuntu2.1
State: installed
nvidia-smi returns:
NVIDIA-SMI 415.27       Driver Version: 415.27       CUDA Version: 10.0

@owoshch can you try in a console which c++ ?

it returns nothing, as well as which g++
running sudo apt-get install g++ returns
Reading package lists... Done Building dependency tree        Reading state information... Done g++ is already the newest version (4:7.3.0-3ubuntu2.1). 0 upgraded, 0 newly installed, 0 to remove and 204 not upgraded.
I have also already run sudo apt install build-essential

@owoshch as you can see from your error, the issue is that Command '['which', 'c++']' returned non-zero exit status 1, You could redirect c++ to g++.

Thank you!
Running this sudo apt-get install -y gcc-6 g++-6 clang  solved the error


[hi] Add docs/tasks/tools/included/_index.md

Localizes

content/hi/docs/tasks/tools/included/_index.md

This PR is in continuation of hi localization effort: #29353
/language hi

@kaiwalyakoparkar Thanks for contributing : )
Please sign the CLA so your PR can reviewed
https://github.com/kubernetes/community/blob/master/CLA.md

@anubha-v-ardhan I have signed the cla. It still shows that not passed. What should I do? :thinking:

@anubha-v-ardhan I have signed the cla. It still shows that not passed. What should I do?

: D It takes some time to update. Look its yes now. Hurry

/retitle [hi] Add docs/tasks/tools/included/_index.md

@kaiwalyakoparkar Can you squash all the commits into one commit and change the base to dev-1.22-hi.1.
That should make this PR ready to merge.

@anubha-v-ardhan Changes done as you asked for
-[ ] PR is open now
-[ ] Squashed all commits to one
-[ ] Changed the base to dev-i.22-hi.1

@kaiwalyakoparkar Seems like something went wrong and a few other commits commits not related to this PR have crept in. Can you fix it.

@anubha-v-ardhan Oh... I will fix it soon

@anubha-v-ardhan could you please check it now?

/remove-approve

The extra file changes are gone but the commits are still there, you can use git reset --hard HEAD~<no. of commits> and the force push using git push --force to remove unwanted commits.

The extra file changes are gone but the commits are still there, you can use git reset --hard HEAD~<no. of commits> and then force push using git push --force to remove unwanted commits.

 I tried a couple of things but that doesn't seem to work. Do you have any suggestions on how I can do that?
 I tried a couple of things but that doesn't seem to work. Do you have any suggestions on how I can do that?

You need to rebase it too i guess

Umm.. I tried a couple of things but that doesn't seem to work. Do you have any suggestions on how I can do that?

I hope it is

You need to rebase it too i guess

Umm.. I tried a couple of things but that doesn't seem to work. Do you have any suggestions on how I can do that?

I hope it is

I followed this approach:

[ ] git rebase -i <commit id of the last commit (you want all commits above this to be squashed)>
[ ] replacing all the 'pick' with 's' option (except the 1st one, in which all the commit would be merged)
[ ] esc + :x
[ ] write a final commit message!!
[ ] esc + :x
[ ] git push --force-with-lease origin

did you this in this way?

i think so too!! this was your last commit
so, commit id below this one should be good iguess

[ ]  git rebase -i <commit id of the last commit (you want all commits above this to be squashed)>
[ ]  replacing all the 'pick' with 's' option (except the 1st one, in which all the commit would be merged)
[ ]  esc + :x
[ ]  write a final commit message!!
[ ]  esc + :x
[ ]  git push --force-with-lease origin your-branch-name

did you this in this way?

I will try this

@anubha-v-ardhan I tried a couple of techniques. Can you squash them while merging?

@anubha-v-ardhan I tried a couple of techniques. Can you squash them while merging?

@anubha-v-ardhan , i think there might have been some error while squashing!! So maybe we cab use the label, which was suggested by @sftim
What do you think?

the squash was successfull but few commits here are not related to this PR, @kaiwalyakoparkar Did you fetch and merged kubernetes:main to kaiwalyakoparkar:docs/tasks/tools/included/_index.md?

commit id of the last commit

You can use your shell and Git to work out the right place to rebase automatically:
git rebase -i "$( git merge-base HEAD dev-1.22-hi.1 )"

To fix this PR, do that and also change pick to drop for all the unwanted commits.

The commits are not related to this PR and shouldn't be here.
@kaiwalyakoparkar Did you rebased against local main instead of dev-1.22-hi.1?

The commits are not related to this PR and shouldn't be here.
@kaiwalyakoparkar Did you rebase against local main instead of dev-1.22-hi.1?

Unfortunately yes

The commits are not related to this PR and shouldn't be here.
@kaiwalyakoparkar Did you rebase against local main instead of dev-1.22-hi.1?

🤔 even i don't remember changing anything like this!!

Closing this PR to open a new one due to rebasing issues
cc: @sftim @anubha-v-ardhan

Thank you, Do tag the tracking issue in new PR.

here is the tracking issue: https://github.com/kubernetes/website/issues/29353


Customized Security for Users in Premium Workspace

Can you enable customized security settings for the workspace users?  I want people to be able to share reports, but not add or delete members.

Thank you for the feedback! Given that this is not related to docs.microsoft.com, we cannot address the issue in this forum.


Update React version

I've just initialized a Gatbsy starter and can't reproduce your issue. Can you tell me the last command you've run?
This works for me: https://github.com/FilipChalupa/react-use-pwa-install-peer-test/commit/305031d7c38946720bcdd726f0b19c3784446d77

Maybe i'm using peer dependecies wrong.

I am using later React version. It is basically complaining that my version is newer.
I have 17.0.2 but it asks for 17.0.1 if I understand correctly.

I had older npm. After upgrading it and React I get same error as you.

I've updated the package to<EMAIL_ADDRESS>I should work with the latest npm now.


Connection refused when attempting to register user with CA

All went well until this point, received this response. Any help would be appreciated.
I also noticed the CA values.yaml was completely commented-out. Intentional?
2021/02/28 07:20:30 [INFO] TLS Enabled
2021/02/28 07:20:30 [INFO] generating key: &{A:ecdsa S:256}
2021/02/28 07:20:30 [INFO] encoded CSR
Error: POST failure of request: POST https://<IP_ADDRESS>:30180/enroll
{"hosts":["mbp.lan"],"certificate_request":"-----BEGIN CERTIFICATE REQUEST-----\nMIIBQzCB6gIBADBeMQswCQYDVQQGEwJVUzEXMBUGA1UECBMOTm9ydGggQ2Fyb2xp\nbmExFDASBgNVBAoTC0h5cGVybGVkZ2VyMQ8wDQYDVQQLEwZGYWJyaWMxDzANBgNV\nBAMTBmVucm9sbDBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABMzl5juvHE6cNI3J\ncqb51SpVhhj7IDvqARyO4ZbKI4G3bF12+uB/ablYX3W6pD6rgQ0V6HZitUa4pOPF\n9UwdI46gKjAoBgkqhkiG9w0BCQ4xGzAZMBcGA1UdEQQQMA6CDGRlYWR3b29kLmxh\nbjAKBggqhkjOPQQDAgNIADBFAiEA2pGQ462xdmt1h6X5ecLBUYmNVkPuHYDTcBfb\nBanocoUCIDNPLvA4ZqTFdcsTtr7vOhZLZyMCpsm7EgDZbaUwiFui\n-----END CERTIFICATE REQUEST-----\n","profile":"","crl_override":"","label":"","NotBefore":"0001-01-01T00:00:00Z","NotAfter":"0001-01-01T00:00:00Z","CAName":"ca"}: Post "https://<IP_ADDRESS>:30180/enroll": dial tcp <IP_ADDRESS>:30180: connect: connection refused

Hello @rgronback,
First of all sorry for the late response.
Could you share the services and the resources used? I think that the fabric-ca server is not exposed through the node port.

Hello!
No apologies necessary, thanks for the reply.  To reproduce, I did the following starting with Kubernetes cluster reset on local Docker for Desktop on the Mac:

Cloned this repository
Created a 'standard' storage class locally using:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: standard
provisioner: docker.io/hostpath

Got to the step where org1-ca is created and running, all good
Attempted to register peer on org1-ca per next step, got connection refused as indicated above

Here is some detail, let me know if you need anything else:
rgronback@deadwood hlf-operator % kubectl hlf ca register --name=org1-ca --user=peer --secret=peerpw --type=peer
--enroll-id enroll --enroll-secret=enrollpw --mspid Org1MSP
[fabsdk/fab] 2021/03/03 03:13:15 UTC - n/a -> INFO TLS Enabled
[fabsdk/fab] 2021/03/03 03:13:15 UTC - n/a -> INFO generating key: &{A:ecdsa S:256}
[fabsdk/fab] 2021/03/03 03:13:15 UTC - logbridge.(*cLogger).Info -> INFO encoded CSR
Error: enroll failed: enroll failed: POST failure of request: POST https://<IP_ADDRESS>:32747/enroll
{"hosts":null,"certificate_request":"-----BEGIN CERTIFICATE REQUEST-----\nMIH3MIGfAgEAMBExDzANBgNVBAMTBmVucm9sbDBZMBMGByqGSM49AgEGCCqGSM49\nAwEHA0IABN0Wc7d4xkSXjgt0NDCzVEwThf683OMcjmmVKdAlFYD7DCrIW0haSJpl\nWdKrY/d7/QDZulHxPnM4j2NQzCnvVtigLDAqBgkqhkiG9w0BCQ4xHTAbMBkGA1Ud\nEQQSMBCCDmRlYWR3b29kLmxvY2FsMAoGCCqGSM49BAMCA0cAMEQCIBCnXbtMWNeB\no4ooSmAKVBXlWG+92kghVMxZaVNokgXoAiAyCYoWloGUre74L62jNDVaPyCzo88+\n2M4O8dKX3BpLKA==\n-----END CERTIFICATE REQUEST-----\n","profile":"","crl_override":"","label":"","NotBefore":"0001-01-01T00:00:00Z","NotAfter":"0001-01-01T00:00:00Z","ReturnPrecert":false,"CAName":""}: Post "https://<IP_ADDRESS>:32747/enroll": dial tcp <IP_ADDRESS>:32747: connect: operation timed out
rgronback@deadwood hlf-operator % k logs -f org1-ca-6c487bc47f-m5vg5

fabric-ca-server start
2021/03/03 03:09:05 [INFO] Configuration file location: /var/hyperledger/fabric-ca/fabric-ca-server-config.yaml
2021/03/03 03:09:05 [INFO] Starting server in home directory: /var/hyperledger/fabric-ca
2021/03/03 03:09:05 [INFO] Server Version: 1.4.9
2021/03/03 03:09:05 [INFO] Server Levels: &{Identity:2 Affiliation:1 Certificate:1 Credential:1 RAInfo:1 Nonce:1}
2021/03/03 03:09:05 [INFO] Loading CA from /var/hyperledger/fabric-ca/fabric-ca-server-config-tls.yaml
2021/03/03 03:09:05 [INFO] The CA key and certificate files already exist
2021/03/03 03:09:05 [INFO] Key file location: /var/hyperledger/fabric-ca/msp-tls-secret/keyfile
2021/03/03 03:09:05 [INFO] Certificate file location: /var/hyperledger/fabric-ca/msp-tls-secret/certfile
2021/03/03 03:09:05 [INFO] Initialized sqlite3 database at /var/hyperledger/fabric-ca/fabric-ca-server.db
2021/03/03 03:09:05 [INFO] The issuer key was successfully stored. The public key is at: /var/hyperledger/fabric-ca/IssuerPublicKey, secret key is at: /var/hyperledger/fabric-ca/msp/keystore/IssuerSecretKey
2021/03/03 03:09:05 [INFO] Idemix issuer revocation public and secret keys were generated for CA 'tlsca'
2021/03/03 03:09:05 [INFO] The revocation key was successfully stored. The public key is at: /var/hyperledger/fabric-ca/IssuerRevocationPublicKey, private key is at: /var/hyperledger/fabric-ca/msp/keystore/IssuerRevocationPrivateKey
2021/03/03 03:09:05 [INFO] The CA key and certificate files already exist
2021/03/03 03:09:05 [INFO] Key file location: /var/hyperledger/fabric-ca/msp-secret/keyfile
2021/03/03 03:09:05 [INFO] Certificate file location: /var/hyperledger/fabric-ca/msp-secret/certfile
2021/03/03 03:09:05 [INFO] Initialized sqlite3 database at /var/hyperledger/fabric-ca/fabric-ca-server.db
2021/03/03 03:09:05 [INFO] The Idemix issuer public and secret key files already exist
2021/03/03 03:09:05 [INFO]    secret key file location: /var/hyperledger/fabric-ca/msp/keystore/IssuerSecretKey
2021/03/03 03:09:05 [INFO]    public key file location: /var/hyperledger/fabric-ca/IssuerPublicKey
2021/03/03 03:09:05 [INFO] The Idemix issuer revocation public and secret key files already exist
2021/03/03 03:09:05 [INFO]    private key file location: /var/hyperledger/fabric-ca/msp/keystore/IssuerRevocationPrivateKey
2021/03/03 03:09:05 [INFO]    public key file location: /var/hyperledger/fabric-ca/IssuerRevocationPublicKey
2021/03/03 03:09:05 [INFO] Home directory for default CA: /var/hyperledger/fabric-ca
2021/03/03 03:09:05 [INFO] Operation Server Listening on [::]:45615
2021/03/03 03:09:05 [INFO] Listening on https://<IP_ADDRESS>:7054
2021/03/03 03:09:06 [INFO] <IP_ADDRESS>:58356 GET /cainfo 200 0 "OK"
2021/03/03 03:09:12 [INFO] <IP_ADDRESS>:58406 GET /cainfo 200 0 "OK"

rgronback@deadwood hlf-operator % k describe service org1-ca
Name:                     org1-ca
Namespace:                default
Labels:                   app=hlf-ca
app.kubernetes.io/managed-by=Helm
chart=hlf-ca-1.3.0
heritage=Helm
release=org1-ca
Annotations:              meta.helm.sh/release-name: org1-ca
meta.helm.sh/release-namespace:
Selector:                 app=hlf-ca,release=org1-ca
Type:                     NodePort
IP:                       <IP_ADDRESS>
LoadBalancer Ingress:     localhost
Port:                     http  7054/TCP
TargetPort:               7054/TCP
NodePort:                 http  32747/TCP
Endpoints:                <IP_ADDRESS>:7054
Session Affinity:         None
External Traffic Policy:  Cluster
Events:
rgronback@deadwood hlf-operator % k describe pod org1-ca-6c487bc47f-m5vg5
Name:         org1-ca-6c487bc47f-m5vg5
Namespace:    default
Priority:     0
Node:         docker-desktop/<IP_ADDRESS>
Start Time:   Tue, 02 Mar 2021 22:09:03 -0500
Labels:       app=hlf-ca
chart=hlf-ca-1.3.0
heritage=Helm
pod-template-hash=6c487bc47f
release=org1-ca
Annotations:
Status:       Running
IP:           <IP_ADDRESS>
IPs:
IP:           <IP_ADDRESS>
Controlled By:  ReplicaSet/org1-ca-6c487bc47f
Containers:
ca:
Container ID:  docker://ac957d18912877730a368ce2aaa0c99015d9aed0119bd57c07a0851ae643bb8a
Image:         hyperledger/fabric-ca:1.4.9
Image ID:      docker-pullable://hyperledger/fabric-ca@sha256:28f50c6aa4f4642842e706d3ae6dcee181921d03bd30ab2a8b09b66e0349d92f
Port:          7054/TCP
Host Port:     0/TCP
Command:
sh
-c
mkdir -p $FABRIC_CA_HOME
cp /var/hyperledger/ca_config/ca.yaml $FABRIC_CA_HOME/fabric-ca-server-config.yaml
cp /var/hyperledger/ca_config_tls/fabric-ca-server-config.yaml $FABRIC_CA_HOME/fabric-ca-server-config-tls.yaml
  echo ">\033[0;35m fabric-ca-server start \033[0m"
  fabric-ca-server start

State:          Running
  Started:      Tue, 02 Mar 2021 22:09:05 -0500
Ready:          True
Restart Count:  0
Limits:
  cpu:     2
  memory:  4Gi
Requests:
  cpu:      10m
  memory:   256Mi
Liveness:   http-get https://:7054/cainfo delay=0s timeout=1s period=10s #success=1 #failure=3
Readiness:  http-get https://:7054/cainfo delay=0s timeout=1s period=10s #success=1 #failure=3
Environment Variables from:
  org1-ca--ca  Secret     Optional: false
  org1-ca--ca  ConfigMap  Optional: false
Environment:   <none>
Mounts:
  /var/hyperledger from data (rw)
  /var/hyperledger/ca_config from ca-config (ro)
  /var/hyperledger/ca_config_tls from ca-config-tls (ro)
  /var/hyperledger/fabric-ca/msp-secret from msp-cryptomaterial (ro)
  /var/hyperledger/fabric-ca/msp-tls-secret from msp-tls-cryptomaterial (ro)
  /var/hyperledger/tls/secret from tls-secret (ro)
  /var/run/secrets/kubernetes.io/serviceaccount from default-token-rkp94 (ro)

Conditions:
Type              Status
Initialized       True
Ready             True
ContainersReady   True
PodScheduled      True
Volumes:
data:
Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
ClaimName:  org1-ca
ReadOnly:   false
tls-secret:
Type:        Secret (a volume populated by a Secret)
SecretName:  org1-ca--tls-cryptomaterial
Optional:    false
ca-config:
Type:      ConfigMap (a volume populated by a ConfigMap)
Name:      org1-ca--config
Optional:  false
ca-config-tls:
Type:      ConfigMap (a volume populated by a ConfigMap)
Name:      org1-ca--config-tls
Optional:  false
msp-cryptomaterial:
Type:        Secret (a volume populated by a Secret)
SecretName:  org1-ca--msp-cryptomaterial
Optional:    false
msp-tls-cryptomaterial:
Type:        Secret (a volume populated by a Secret)
SecretName:  org1-ca--msp-tls-cryptomaterial
Optional:    false
default-token-rkp94:
Type:        Secret (a volume populated by a Secret)
SecretName:  default-token-rkp94
Optional:    false
QoS Class:       Burstable
Node-Selectors:
Tolerations:     node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
Type     Reason            Age                From               Message

Warning  FailedScheduling  11m (x4 over 13m)  default-scheduler  0/1 nodes are available: 1 pod has unbound immediate PersistentVolumeClaims.
Normal   Scheduled         11m                default-scheduler  Successfully assigned default/org1-ca-6c487bc47f-m5vg5 to docker-desktop
Normal   Pulled            11m                kubelet            Container image "hyperledger/fabric-ca:1.4.9" already present on machine
Normal   Created           11m                kubelet            Created container ca
Normal   Started           11m                kubelet            Started container ca
rgronback@deadwood hlf-operator % k describe service istio-ingressgateway -n istio-system
Name:                     istio-ingressgateway
Namespace:                istio-system
Labels:                   app=istio-ingressgateway
install.operator.istio.io/owning-resource=app-istiocontrolplane
install.operator.istio.io/owning-resource-namespace=istio-system
istio=ingressgateway
istio.io/rev=default
operator.istio.io/component=IngressGateways
operator.istio.io/managed=Reconcile
operator.istio.io/version=1.8.0
release=istio
Annotations:
Selector:                 app=istio-ingressgateway,istio=ingressgateway
Type:                     NodePort
IP:                       <IP_ADDRESS>
LoadBalancer Ingress:     localhost
Port:                     status-port  15021/TCP
TargetPort:               15021/TCP
NodePort:                 status-port  31002/TCP
Endpoints:                <IP_ADDRESS>:15021
Port:                     http2  80/TCP
TargetPort:               8080/TCP
NodePort:                 http2  31003/TCP
Endpoints:                <IP_ADDRESS>:8080
Port:                     https  443/TCP
TargetPort:               8443/TCP
NodePort:                 https  31004/TCP
Endpoints:                <IP_ADDRESS>:8443
Port:                     tls  15443/TCP
TargetPort:               15443/TCP
NodePort:                 tls  31005/TCP
Endpoints:                <IP_ADDRESS>:15443
Session Affinity:         None
External Traffic Policy:  Cluster
Events:

Hi @rgronback , it should work in the latest release, try updating.
If the problem arises again, open the issue or contact me directly, thanks :)

i have the problem when attempting to register user with CA. i get the following logg
[fabsdk/fab] 2021/09/22 08:16:30 UTC - n/a -> INFO TLS Enabled  [fabsdk/fab] 2021/09/22 08:16:30 UTC - n/a -> INFO generating key: &{A:ecdsa S:256}  [fabsdk/fab] 2021/09/22 08:16:30 UTC - logbridge.(*cLogger).Info -> INFO encoded CSR Error: enroll failed: enroll failed: POST failure of request: POST https://<IP_ADDRESS>:32408/enroll {"hosts":null,"certificate_request":"-----BEGIN CERTIFICATE REQUEST-----\nMIIBBjCBrQIBADARMQ8wDQYDVQQDEwZlbnJvbGwwWTATBgcqhkjOPQIBBggqhkjO\nPQMBBwNCAAQ/ZC5mCRzYB7GD3YLoS8d9laVL94vUM8TQFfz53cs8pzR950PW5/+S\nOh9Ld2aP9nV6cUjbOJR4dS12PW7j0EyioDowOAYJKoZIhvcNAQkOMSswKTAnBgNV\nHREEIDAeghx6aGFuZ2Z1bGlkZU1hY0Jvb2stUHJvLmxvY2FsMAoGCCqGSM49BAMC\nA0gAMEUCIQCxNxWD0ynmecCP+gnsHL6FfBrfwlibw079/ZlJOr4wDQIgZVYIBD6z\nxNE5yJYXfaO5p5dqhTQQn+kzLtowOWN4R8Q=\n-----END CERTIFICATE REQUEST-----\n","profile":"","crl_override":"","label":"","NotBefore":"0001-01-01T00:00:00Z","NotAfter":"0001-01-01T00:00:00Z","ReturnPrecert":false,"CAName":""}: Post https://<IP_ADDRESS>:32408/enroll: dial tcp <IP_ADDRESS>:32408: connect: operation timed out

Hi @zhangfuli
Can you confirm if you have access to this IP: <IP_ADDRESS>?
The Kubectl plugin tries to access the URL <KUBERNETES_NODE>:<CA_NODE_PORT> so if you don't have access to the nodes in the Kubernetes cluster, or the IP is internal the Kubectl plugin won't work for you.

My k8s cluster is also on local Docker for Desktop on the Mac. Here is some detail.
(base) zhangfulideMacBook-Pro:hlf-operator-main zhangfuli$ kubectl hlf ca register --name=org1-ca --user=peer --secret=peerpw --type=peer  --enroll-id enroll --enroll-secret=enrollpw --mspid Org1MSP
 [fabsdk/fab] 2021/09/23 03:53:30 UTC - n/a -> INFO TLS Enabled
 [fabsdk/fab] 2021/09/23 03:53:30 UTC - n/a -> INFO generating key: &{A:ecdsa S:256}
 [fabsdk/fab] 2021/09/23 03:53:30 UTC - logbridge.(*cLogger).Info -> INFO encoded CSR
Error: enroll failed: enroll failed: POST failure of request: POST https://<IP_ADDRESS>:31346/enroll
{"hosts":null,"certificate_request":"-----BEGIN CERTIFICATE REQUEST-----\nMIIBBTCBrQIBADARMQ8wDQYDVQQDEwZlbnJvbGwwWTATBgcqhkjOPQIBBggqhkjO\nPQMBBwNCAAR7lfWVMWjOwauo/YhoNdINO6qGBaEMWwxtnoRG8H6ngprcDA8RdGkx\nHfyt1049MYG/XOGfw/1MXe4zk6VWr+vCoDowOAYJKoZIhvcNAQkOMSswKTAnBgNV\nHREEIDAeghx6aGFuZ2Z1bGlkZU1hY0Jvb2stUHJvLmxvY2FsMAoGCCqGSM49BAMC\nA0cAMEQCIDhrVf+BcnJ7wbAsH8iOP13Apx0uHnR/5/PM9ScR1xmiAiAY3NGG4vCw\naig3zpCFLg1IYtooJlR8W9VqsXXFBbHyQw==\n-----END CERTIFICATE REQUEST-----\n","profile":"","crl_override":"","label":"","NotBefore":"0001-01-01T00:00:00Z","NotAfter":"0001-01-01T00:00:00Z","ReturnPrecert":false,"CAName":""}: Post https://<IP_ADDRESS>:31346/enroll: dial tcp <IP_ADDRESS>:31346: connect: operation timed out

(base) zhangfulideMacBook-Pro:hlf-operator-main zhangfuli$ kc describe svc org1-ca
Name:                     org1-ca
Namespace:                default
Labels:                   app=hlf-ca
                          app.kubernetes.io/managed-by=Helm
                          chart=hlf-ca-1.3.0
                          heritage=Helm
                          release=org1-ca
Annotations:              meta.helm.sh/release-name: org1-ca
                          meta.helm.sh/release-namespace:
Selector:                 app=hlf-ca,release=org1-ca
Type:                     NodePort
IP Family Policy:         SingleStack
IP Families:              IPv4
IP:                       <IP_ADDRESS>
IPs:                      <IP_ADDRESS>
LoadBalancer Ingress:     localhost
Port:                     http  7054/TCP
TargetPort:               7054/TCP
NodePort:                 http  31346/TCP
Endpoints:                <IP_ADDRESS>:7054
Port:                     operations  9443/TCP
TargetPort:               9443/TCP
NodePort:                 operations  31950/TCP
Endpoints:                <IP_ADDRESS>:9443
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

(base) zhangfulideMacBook-Pro:hlf-operator-main zhangfuli$ kc describe pod org1-ca-58b7748447-6lblk
Name:         org1-ca-58b7748447-6lblk
Namespace:    default
Priority:     0
Node:         docker-desktop/<IP_ADDRESS>
Start Time:   Thu, 23 Sep 2021 11:49:53 +0800
Labels:       app=hlf-ca
              chart=hlf-ca-1.3.0
              heritage=Helm
              pod-template-hash=58b7748447
              release=org1-ca
Annotations:  <none>
Status:       Running
IP:           <IP_ADDRESS>
IPs:
  IP:           <IP_ADDRESS>
Controlled By:  ReplicaSet/org1-ca-58b7748447
Containers:
  ca:
    Container ID:  docker://948c1bee08280d85bd5ac3af3ccf513820f2828f44101628aba7b789133ed91c
    Image:         hyperledger/fabric-ca:1.4.9
    Image ID:      docker-pullable://hyperledger/fabric-ca@sha256:28f50c6aa4f4642842e706d3ae6dcee181921d03bd30ab2a8b09b66e0349d92f
    Ports:         7054/TCP, 9443/TCP
    Host Ports:    0/TCP, 0/TCP
    Command:
      sh
      -c
      mkdir -p $FABRIC_CA_HOME
      cp /var/hyperledger/ca_config/ca.yaml $FABRIC_CA_HOME/fabric-ca-server-config.yaml
      cp /var/hyperledger/ca_config_tls/fabric-ca-server-config.yaml $FABRIC_CA_HOME/fabric-ca-server-config-tls.yaml

      echo ">\033[0;35m fabric-ca-server start \033[0m"
      fabric-ca-server start

    State:          Running
      Started:      Thu, 23 Sep 2021 11:50:04 +0800
    Ready:          True
    Restart Count:  0
    Limits:
      cpu:     0
      memory:  0
    Requests:
      cpu:      0
      memory:   0
    Liveness:   http-get https://:7054/cainfo delay=0s timeout=1s period=10s #success=1 #failure=3
    Readiness:  http-get https://:7054/cainfo delay=0s timeout=1s period=10s #success=1 #failure=3
    Environment Variables from:
      org1-ca--ca  Secret     Optional: false
      org1-ca--ca  ConfigMap  Optional: false
    Environment:   <none>
    Mounts:
      /var/hyperledger from data (rw)
      /var/hyperledger/ca_config from ca-config (ro)
      /var/hyperledger/ca_config_tls from ca-config-tls (ro)
      /var/hyperledger/fabric-ca/msp-secret from msp-cryptomaterial (ro)
      /var/hyperledger/fabric-ca/msp-tls-secret from msp-tls-cryptomaterial (ro)
      /var/hyperledger/tls/secret from tls-secret (ro)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-97csk (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True
Volumes:
  data:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  org1-ca
    ReadOnly:   false
  tls-secret:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  org1-ca--tls-cryptomaterial
    Optional:    false
  ca-config:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      org1-ca--config
    Optional:  false
  ca-config-tls:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      org1-ca--config-tls
    Optional:  false
  msp-cryptomaterial:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  org1-ca--msp-cryptomaterial
    Optional:    false
  msp-tls-cryptomaterial:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  org1-ca--msp-tls-cryptomaterial
    Optional:    false
  kube-api-access-97csk:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   BestEffort
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason            Age    From               Message
  ----     ------            ----   ----               -------
  Warning  FailedScheduling  8m8s   default-scheduler  0/1 nodes are available: 1 pod has unbound immediate PersistentVolumeClaims.
  Normal   Scheduled         8m6s   default-scheduler  Successfully assigned default/org1-ca-58b7748447-6lblk to docker-desktop
  Normal   Pulled            7m56s  kubelet            Container image "hyperledger/fabric-ca:1.4.9" already present on machine
  Normal   Created           7m56s  kubelet            Created container ca
  Normal   Started           7m56s  kubelet            Started container ca
  Warning  Unhealthy         7m55s  kubelet            Readiness probe failed: Get "https://<IP_ADDRESS>:7054/cainfo": dial tcp <IP_ADDRESS>:7054: connect: connection refused
(base) zhangfulideMacBook-Pro:hlf-operator-main zhangfuli$ kc logs org1-ca-58b7748447-6lblk
> fabric-ca-server start
2021/09/23 03:50:05 [INFO] Configuration file location: /var/hyperledger/fabric-ca/fabric-ca-server-config.yaml
2021/09/23 03:50:05 [INFO] Starting server in home directory: /var/hyperledger/fabric-ca
2021/09/23 03:50:05 [INFO] Server Version: 1.4.9
2021/09/23 03:50:05 [INFO] Server Levels: &{Identity:2 Affiliation:1 Certificate:1 Credential:1 RAInfo:1 Nonce:1}
2021/09/23 03:50:05 [INFO] Loading CA from /var/hyperledger/fabric-ca/fabric-ca-server-config-tls.yaml
2021/09/23 03:50:05 [INFO] The CA key and certificate files already exist
2021/09/23 03:50:05 [INFO] Key file location: /var/hyperledger/fabric-ca/msp-tls-secret/keyfile
2021/09/23 03:50:05 [INFO] Certificate file location: /var/hyperledger/fabric-ca/msp-tls-secret/certfile
2021/09/23 03:50:05 [INFO] Initialized sqlite3 database at /var/hyperledger/fabric-ca/fabric-ca-server.db
2021/09/23 03:50:05 [INFO] The issuer key was successfully stored. The public key is at: /var/hyperledger/fabric-ca/IssuerPublicKey, secret key is at: /var/hyperledger/fabric-ca/msp/keystore/IssuerSecretKey
2021/09/23 03:50:05 [INFO] Idemix issuer revocation public and secret keys were generated for CA 'tlsca'
2021/09/23 03:50:05 [INFO] The revocation key was successfully stored. The public key is at: /var/hyperledger/fabric-ca/IssuerRevocationPublicKey, private key is at: /var/hyperledger/fabric-ca/msp/keystore/IssuerRevocationPrivateKey
2021/09/23 03:50:05 [INFO] The CA key and certificate files already exist
2021/09/23 03:50:05 [INFO] Key file location: /var/hyperledger/fabric-ca/msp-secret/keyfile
2021/09/23 03:50:05 [INFO] Certificate file location: /var/hyperledger/fabric-ca/msp-secret/certfile
2021/09/23 03:50:05 [INFO] Initialized sqlite3 database at /var/hyperledger/fabric-ca/fabric-ca-server.db
2021/09/23 03:50:05 [INFO] The Idemix issuer public and secret key files already exist
2021/09/23 03:50:05 [INFO]    secret key file location: /var/hyperledger/fabric-ca/msp/keystore/IssuerSecretKey
2021/09/23 03:50:05 [INFO]    public key file location: /var/hyperledger/fabric-ca/IssuerPublicKey
2021/09/23 03:50:05 [INFO] The Idemix issuer revocation public and secret key files already exist
2021/09/23 03:50:05 [INFO]    private key file location: /var/hyperledger/fabric-ca/msp/keystore/IssuerRevocationPrivateKey
2021/09/23 03:50:05 [INFO]    public key file location: /var/hyperledger/fabric-ca/IssuerRevocationPublicKey
2021/09/23 03:50:05 [INFO] Home directory for default CA: /var/hyperledger/fabric-ca
2021/09/23 03:50:05 [INFO] Operation Server Listening on [::]:9443
2021/09/23 03:50:06 [INFO] Listening on https://<IP_ADDRESS>:7054
2021/09/23 03:50:13 [INFO] <IP_ADDRESS>:64474 GET /cainfo 200 0 "OK"
2021/09/23 03:50:13 [INFO] <IP_ADDRESS>:64476 GET /cainfo 200 0 "OK"

Hi @zhangfuli
Can you try to access https://<IP_ADDRESS>:32408/cainfo from your MacBook? This issue's due to no connection from the machine where you're running the commands and your Kubernetes cluster.
Also, in the same terminal you're running the enrol command, try to run the following scripts:
curl https://<IP_ADDRESS>:32408/cainfo -k

If it doesn't respond immediately, we can confirm that this error is because of no connectivity to the Kubernetes cluster.

thank you a lot. i cannot access  https://<IP_ADDRESS>:32408/cainfo. but i can access localhost:32408/cainfo. i will troubleshoot problems with my cluster

Hello, I am using Kind for the cluster, and then when executing the following command. Did I miss something? Do I have to do something or setting on Docker desktop? Please shed some light on this. thank you
kubectl hlf ca register --name=org1-ca --user=peer
--secret=peerpw --type=peer
--enroll-id enroll --enroll-secret=enrollpw
--mspid Org1MSP
[fabsdk/fab] 2022/10/29 16:38:20 UTC - n/a -> INFO TLS Enabled
[fabsdk/fab] 2022/10/29 16:38:20 UTC - n/a -> INFO generating key: &{A:ecdsa S:256}
[fabsdk/fab] 2022/10/29 16:38:20 UTC - logbridge.(*cLogger).Info -> INFO encoded CSR
Error: enroll failed: enroll failed: POST failure of request: POST https://<IP_ADDRESS>:30933/enroll
{"hosts":null,"certificate_request":"-----BEGIN CERTIFICATE REQUEST-----\nMIIBAjCBqQIBADARMQ8wDQYDVQQDEwZlbnJvbGwwWTATBgcqhkjOPQIBBggqhkjO\nPQMBBwNCAATsxVa747wAkSHu+Ia0UOlopxnWySmyNXLmz/QzTz5WW+5xP3QW3JlY\ngXgx+I9Kl973vKRW1Jv/mCsUht7+CBMVoDYwNAYJKoZIhvcNAQkOMScwJTAjBgNV\nHREEHDAaghhKb2hhbnMtTWFjQm9vay1Qcm8ubG9jYWwwCgYIKoZIzj0EAwIDSAAw\nRQIhAO909fZEFDR27okDhTMqasg5iRQRdVsuHRBRF3bhHL/DAiA2LTXsiON7pKMh\nGmTRw/vEqbv2Z/VEbNTN13VRD3nBaA==\n-----END CERTIFICATE REQUEST-----\n","profile":"","crl_override":"","label":"","NotBefore":"0001-01-01T00:00:00Z","NotAfter":"0001-01-01T00:00:00Z","ReturnPrecert":false,"CAName":""}: Post "https://<IP_ADDRESS>:30933/enroll": dial tcp <IP_ADDRESS>:30933: connect: operation timed out

The error is because the port is not open.
When on a cloud platform this error can be solved by going to the firewall section in the cloud VM and creating a new firewall rule with the port . Refer Youtube for this on how to open ports in cloud platform.

Launching network "tradereboot":
✅ - Creating namespace "tradereboot" ...
✅ - Provisioning volume storage ...
✅ - Creating fabric config maps ...
✅ - Initializing TLS certificate Issuers ...
✅ - Launching Fabric CAs ...
⚠  - Enrolling bootstrap ECert CA users ...
Error: POST failure of request: POST https://org0-ca.tradetec-1137530645.ap-southeast-1.elb.amazonaws.com:443/enroll
{"hosts":["piyush"],"certificate_request":"-----BEGIN CERTIFICATE REQUEST-----\nMIIBPjCB5gIBADBgMQswCQYDVQQGEwJVUzEXMBUGA1UECBMOTm9ydGggQ2Fyb2xp\nbmExFDASBgNVBAoTC0h5cGVybGVkZ2VyMQ8wDQYDVQQLEwZGYWJyaWMxETAPBgNV\nBAMTCHJjYWFkbWluMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEi8j8fs6vgdq9\nm1IhDTkEDkZ+MOMlTaBLGUGaPOBuRs70CP7T4KX/BRZxdFX7Sf4k3JiqlGJvpwDW\nqpWgC0AAKqAkMCIGCSqGSIb3DQEJDjEVMBMwEQYDVR0RBAowCIIGcGl5dXNoMAoG\nCCqGSM49BAMCA0cAMEQCICRhRR0U3P8H5PV2cs+Yxqm1cB7E5Pw8Rd36NPVtV9DU\nAiBavONt/MD3Lp3QWbefaGhgkjLwMt8PWmHSl/2oDQXtFA==\n-----END CERTIFICATE REQUEST-----\n","profile":"","crl_override":"","label":"","NotBefore":"0001-01-01T00:00:00Z","NotAfter":"0001-01-01T00:00:00Z","ReturnPrecert":false,"CAName":""}: Post "https://org0-ca.tradetec-1137530645.ap-southeast-1.elb.amazonaws.com:443/enroll": dial tcp: lookup org0-ca.tradetec-1137530645.ap-southeast-1.elb.amazonaws.com on <IP_ADDRESS>:53: no such host


disallowImplicitTypeConversion triggered improperly

disallowImplicitTypeConversion is triggered for the following code:
return '' +
    '\'use strict\';+\n\n' +
    '/**\n' +
    ' * Environment configuration (' + envName + ')\n' +
    ' */\n' +
    'module.exports = {\n' +
    '  //Your configuration here\n' +
    '};\n';

This is because of the '' +, but there is clearly no type conversion going on in the code block.

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/24506669-disallowimplicittypeconversion-triggered-improperly?utm_campaign=plugin&utm_content=tracker%2F281640&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F281640&utm_medium=issues&utm_source=github).

What about the concat of envName? That's an implicit conversion.
On Jul 17, 2015 12:04 PM, "Adam Buczynski"<EMAIL_ADDRESS>wrote:

disallowImplicitTypeConversion is triggered for the following code:
return '' +
''use strict';+\n\n' +
'/**\n' +
' * Environment configuration (' + envName + ')\n' +
' */\n' +
'module.exports = {\n' +
'  //Your configuration here\n' +
'};\n';
This is because of the '' +, but there is clearly no type conversion
going on in the code block.
—
Reply to this email directly or view it on GitHub
https://github.com/jscs-dev/node-jscs/issues/1538.

By that logic:
return '\'use strict\';+\n\n' +
    '/**\n' +
    ' * Environment configuration (' + envName + ')\n' +
    ' */\n' +
    'module.exports = {\n' +
    '  //Your configuration here\n' +
    '};\n';

could also be considered an implicit conversion, because you can never know what's inside envName.. But it's not, because envName can be assumed to be a string in this case.
I think the rule should be limited to finding occurrences of '' + var;, which is an obvious implicit conversion to a string.


Remove protocol annotation from file server connector

Thanks @amjadhifthikar for your contribution. It seems like changes in this PR are already merged to master. Hence I am closing this PR.


Show inferred types on hover

TypeScript Version:  Version 2.1.0-dev.20160911
Code
// A *self-contained* demonstration of the problem follows...
interface Test {
    values: string[]
}

const test: Test = {
    values: [] // type: undefined[] on hover
}

When you hover values: [] in VSCode it will show type: undefined[] which in theory one could say - 'working as intended' - but would be great if type could be inferred at this level and show to user string[]

This has been brought up several times in the past, e.g. #3667, #6118, #10484.
The good news is that a fix seems to finally be near: #10610. :tada:


Fix animation mixer breaking animations with redundant check

The animation mixer is breaking animations as described here: https://github.com/godotengine/godot/issues/88428
Shoutout to @monxa and @personalmountains for helping with the fix!  Simply removing the incorrect and redundant check fixes it.
Incorrect reasoning here: https://github.com/godotengine/godot/issues/88428#issuecomment-1950286835
Redundant reasoning here: https://github.com/godotengine/godot/issues/88428#issuecomment-1952559684

@TokageItLab's assessment seems correct, but the demos I mentioned do not seem to raise any get_node errors, yet this check seems to completely break their animations. I'm puzzled.

Ok right, see https://github.com/godotengine/godot/issues/88428#issuecomment-1950286835 which @TCROC linked in the OP. The difference is the value of the p_last_is_property boolean. So this means that has_node_and_resource fails in this case, when what you seem to want is to just prevent get_node from failing.
So you should just check has_node, or add p_last_is_property to has_node_and_resource if it's needed to do all the checks.

diff --git a/scene/animation/animation_mixer.cpp b/scene/animation/animation_mixer.cpp
index 706d210064..eec70e737f 100644
--- a/scene/animation/animation_mixer.cpp
+++ b/scene/animation/animation_mixer.cpp
@@ -661,7 +661,7 @@ bool AnimationMixer::_update_caches() {
 				Ref<Resource> resource;
 				Vector<StringName> leftover_path;

-				if (!parent->has_node_and_resource(path)) {
+				if (!parent->has_node(path)) {
 					if (check_path) {
 						WARN_PRINT_ED(mixer_name + ": '" + String(E) + "', couldn't resolve track:  '" + String(path) + "'. This warning can be disabled in Project Settings.");
 					}

This is a more minimal fix that should still prevent errors when get_node(p_path) fails.

@akien-mga I think it's a problem when resource is not found.
I think it would be straighforward to add a p_last_is_property  argument to has_node_and_resource() and propagate it to the internal get_node_and_resource(), but I am sure you are still double checking for its existence I am sure it is still double checking for existence.
Probably the most intelligent way is to add an optional argument to get_node_and_resource() and get_node() to hide an error.

I wouldn't change get_node (you can always just call has_node first), but get_node_and_resource can simply use has_node.

I would just add this change to this PR:
diff --git a/scene/main/node.cpp b/scene/main/node.cpp
index e814e4f0cd..f827f68def 100644
--- a/scene/main/node.cpp
+++ b/scene/main/node.cpp
@@ -3025,9 +3025,9 @@ Array Node::_get_node_and_resource(const NodePath &p_path) {

 Node *Node::get_node_and_resource(const NodePath &p_path, Ref<Resource> &r_res, Vector<StringName> &r_leftover_subpath, bool p_last_is_property) const {
 	ERR_THREAD_GUARD_V(nullptr);
-	Node *node = get_node(p_path);
 	r_res = Ref<Resource>();
 	r_leftover_subpath = Vector<StringName>();
+	Node *node = get_node_or_null(p_path);
 	if (!node) {
 		return nullptr;
 	}

And then I think it's good to go. It's probably reasonable for get_node_and_resource not to print an error and just return nullptr.

However, since path checking should be enabled by default (to detect errors for invalid path), the following code would be necessary.
if (check_path && !parent->has_node(path)) {
	WARN_PRINT_ED(mixer_name + ": '" + String(E) + "', couldn't resolve track:  '" + String(path) + "'. This warning can be disabled in Project Settings.");
}

@akien-mga Ah, make sense. So just replacing get_node to get_node_or_null is sufficient.

Superseded by #88557 which adds the Node::get_node_and_resource change.
Thanks for the contribution!

Superseded by #88557 which adds the Node::get_node_and_resource change.
Thanks for the contribution!

Absolutely! :)  Glad to help! :)


Need edge driver version 98

I did not find the edge driver version below 99. I need this driver since our electron application which support only the driver versions below 99.

Electron is based on Chromium, not Edge. You will need to use ChromeDriver. Here's some information on locating the correct version: https://chromedriver.chromium.org/downloads/version-selection
This might also be helpful: https://www.electronjs.org/docs/latest/tutorial/using-selenium-and-webdriver


storybook is not working

@rtivital I'm getting this error when trying to start storybook

PS D:\GitHub\mantine-storybook> yarn storybook
yarn run v1.22.18
$ start-storybook -p 7001
info @storybook/react v6.5.9
info
info => Loading presets
info => Using implicit CSS loaders
(node:6184) DeprecationWarning: Default PostCSS plugins are deprecated. When switching to '@storybook/addon-postcss',
r.js:214:10)
    at Array.<anonymous> (D:\GitHub\mantine-storybook\node_modules\loader-runner\lib\LoaderRunner.js:205:4)    at Storage.finished (D:\GitHub\mantine-storybook\node_modules\enhanced-resolve\lib\CachedInputFileSystem.js:55:16)
    at D:\GitHub\mantine-storybook\node_modules\enhanced-resolve\lib\CachedInputFileSystem.js:91:9
    at D:\GitHub\mantine-storybook\node_modules\graceful-fs\graceful-fs.js:123:16    at FSReqCallback.readFileAfterClose [as oncomplete] (node:internal/fs/read_file_context:68:3) {  opensslErrorStack: [ 'error:03000086:digital envelope routines::initialization error' ],
  library: 'digital envelope routines',
  reason: 'unsupported',
  code: 'ERR_OSSL_EVP_UNSUPPORTED'
}

Node.js v17.0.1error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Storybook does not support some node.js versions, use version 16.

ok thanks


[ISSUE] 403 Response when sending data from vgsCollect.sendData

Describe the bug
I have been using the VGS sandbox environment successfully over the last few days, now all of a sudden without any changes, I am getting a 403 error when making to call to VGSCollect.SendDate(path: , extraData: )
To Reproduce
Steps to reproduce the behavior:

Create 1 textfield with Configuration '...'

cardConfiguration.type = .cardNumber
cardConfiguration.isRequiredValidOnly = true
cardConfiguration.validationRules = VGSValidationRuleSet(rules: [
      VGSValidationRulePaymentCard.init(error: VGSValidationErrorType.cardNumber.rawValue, validateUnknownCardBrand: true)
    ])
cardNumberField.configuration = cardConfiguration

Click on Submit UI Button
Make a call to sendData(path: "/post", extraData: extraData)
See this response

failure(403, Optional(42 bytes), Optional(<NSHTTPURLResponse: 0x60000148ccc0> { URL: https://tntoxwh0eeq.sandbox.verygoodproxy.com/post } { Status Code: 403, Headers {
    "Access-Control-Allow-Origin" =     (
        "*"
    );
    "Content-Encoding" =     (
        br
    );
    "Content-Type" =     (
        "application/json"
    );
    Date =     (
        "Tue, 23 Feb 2021 21:26:06 GMT"
    );
    Server =     (
        nginx
    );
    Via =     (
        "1.1 905b63dda002963cf44f2d6e390e1b3f.cloudfront.net (CloudFront)",
        "1.1 c193452bb546"
    );
    "vgs-request-id" =     (
        e20cbe7248d04c448d58c00499120e0c
    );
    "x-amz-apigw-id" =     (
        "bN7lTGM5IAMFnWQ="
    );
    "x-amz-cf-id" =     (
        "F-fJClXHykzbwTPqr8SD3wOCe0myNHeCff9fyNaZfyHOaAt1IDKfuw=="
    );
    "x-amz-cf-pop" =     (
        "IAD50-C2"
    );
    "x-amzn-errortype" =     (
        MissingAuthenticationTokenException
    );
    "x-amzn-requestid" =     (
        "be7e4723-5f6f-45ca-8258-da0714b7bdae"
    );
    "x-cache" =     (
        "Error from cloudfront"
    );
} }), nil)

Expected behavior
A success 200 response which I was getting before
Screenshots
If applicable, add screenshots to help explain your problem.
Environment (please complete the following information):

SDK Version Where can I find this, I guess 1.7.0
iOS Version: iOS 14.2
Xcode Version: 12.2
Device: iPhoneXs Max Simulator
Dependency manager and it's version:

Cocoapods: 1.10.1

Additional context
I'm not sure if this is a temporary error or is it a usage issue or I am doing something wrong ?
Thanks in advance

Hello, @sha8wn.
Thank you for letting us know about the issue. We will try to reproduce it and provide feedback asap.
Could you please provide incoming request data as well with non-private some dummy but valid data?
As you got 403 error it can be related to permissions on VGS dashboard. Please check this.
Further steps might be taken:

Check logs on the dashboard for your <tenant_id>.
Please check this instruction.

Try our latest SDK version (1.7.5).
It has helpful options for debugging. Check this doc.

In you app delegate .init setup loggers.
Here is sample:
 	// Setup loggers in AppDelegate -init as the earliest app entry point.
	override init() {
		super.init()

 		// Enable loggers only for debug!
 		#if DEBUG
 		// Setup VGS Collect loggers:
 		// Show warnings and errors.
		VGSCollectLogger.shared.configuration.level = .warning

 		// Show network session for collect requests.
 		VGSCollectLogger.shared.configuration.isNetworkDebugEnabled = true

		// *You can stop all VGS Collect loggers in app:
		// VGSCollectLogger.shared.disableAllLoggers()
 		#endif
	}

Thanks for your response @EugeneIOs . When you say non private, do you also need the vaultId ? I am testing from the sandbox environment.
When I make the sendData request, I am sending some extra data in this format:
func getVGSPayload() -> [String: Any] {
    return ["user_id": userId, "system_user_id": systemUserId, "system_institution_id": systemInstitutionId]
}

Then I do this:
let extraData = vgsModel?.getVGSPayload() /// function above
EUXLog.log("VGS Payload: \(extraData ?? [String: Any]())")

/// send data to your Vault
vgsView.vgsCollect.sendData(path: "/post", extraData: extraData) { [weak self](response) in

Printing the dummy data I send as extra data from my logs to the console:
VGS Payload: ["mx_user_id": "U-d123cf623-5ecb-6c93-agO5-b8c4f0076ca9", "user_id": "t4Wq2fE4GQ19qGMm64vS", "mx_institution_id": "I-123erf456-wxyz-23d3-8f05-478527r974bx"]

Finally, since this is the sandbox environment and I only send the card data which is 4111 1111 1111 1111.
This was working fine yesterday morning so not sure if something changed
In the mean time, I will update pods as you suggested.
Thank you.

@EugeneIOs - I have updated to 1.7.5 and get more logs and see the following:
⬆ Send VGSCollectSDK request payload:
{
  "system_user_id" : "U-d123cf623-5ecb-6c93-agO5-b8c4f0076ca9",
  "system_institution_id" : "I-123erf456-wxyz-23d3-8f05-478527r974bx",
  "user_id" : "t4Wq2fE4GQ19qGMm64vS",
  "card_number" : "4111111111111111"
}

Then I see the issues:
❗Failed ⬇ VGSCollectSDK request url: https://{sandboxVaultId}.sandbox.verygoodproxy.com/post
❗Failed ⬇ VGSCollectSDK response status code: 403
❗Failed ⬇ VGSCollectSDK response headers:
[
    Content-Encoding : br
    vgs-request-id : 778b5f2fc9e9ac2c50dc7346d3892609
    x-amz-cf-id : 6Tkiengw6Dksk6Pvhhrr4f3g2t6hMvOM0ZJF3UhplOpH9hMFRB02jA==
    Via : 1.1 5451b84324d9bca0bdd03e4c4009ae11.cloudfront.net (CloudFront), 1.1 704aa269718a
    x-amzn-requestid : e85253bc-a513-4791-9839-40becec07017
    x-amz-apigw-id : bPHbDHlpoAMFbSg=
    x-cache : Error from cloudfront
    Server : nginx
    Content-Type : application/json
    Date : Wed, 24 Feb 2021 06:03:50 GMT
    x-amz-cf-pop : IAD50-C2
    Access-Control-Allow-Origin : *
    x-amzn-errortype : MissingAuthenticationTokenException
]
❗Failed ⬇ VGSCollectSDK response extra info:
{"message":"Missing Authentication Token"}

Not sure if I need to add some auth token as I thought this was taken care of by using the vault id ?
And also, this same request was working yesterday morning so I am a little lost on this one.

Thank you for providing more extensive debug information. We are on our way for checking it.

@sha8wn
It seems there is an issue with your routes configuration on the dashboard.
I'm not sure 403 error is related to SDK.
Please contact our support<EMAIL_ADDRESS>and we will try to help you asap.

Alright @EugeneIOs - thanks for your support, I will check with the support team.
Appreciate it.

@sha8wn I will close this issue since it's not related to SDK functionality. Our support team will help you to check Routs Configuration on Dashboard.


Improvement required in Home Page

Describe the bug

An unwanted text is visible on home screen.

The text written in the carousel does not make any sense. (WELCOME TO) what?

Alignment of text is not appropriate.

The bold test needs to be pointer type and must redirect to the home page.

The moving cards under INITIATIVES sections need to be pointer type while hovering

The CSS of JOIN US button is not matching with the rest of the buttons.

To Reproduce
Steps to reproduce the behavior:

Go to Home Page
Click on portions as shown in the screenshots
Scroll down to the required section
See error as shown in the screenshot

Expected behavior
All these bugs needs to be corrected
Screenshots
All screenshots are being attached along with the problem statement
Additional context
I have found the above bugs in the website's home page and want to work on them in order to improve the website.
@smaranjitghose Kindly assign me this.

@smaranjitghose Please have a look at this. Can I work on it?

Hello, @shreyakapoor08,  I'm actually working on the Home Page carousal part. I think @smaranjitghose Sir, will split this one to you on rest of the parts!! Thanks! We should wait for him to avoid any conflicting works on this one! Thanks!

@shreyakapoor08  Can you fix 4,5,6 while @abhu-A-J fixes 1,2,3

@shreyakapoor08 Can you please fix 4,5,6 while @abhu-A-J fixes 1,2,3

Sure :)

@smaranjitghose Issues resolved Kindly check. :)


Build issue with Develop branch

Hi @matth-x , As discussed with you earlier, I was looking for some of the changes you made to the develop branch and wanted to play around but hitting basic Compilation issues, while trying example file SECC . Hitting the following error, any clue to what I am missing?
n file included from /Users/phanigalla/Documents/Arduino/libraries/ArduinoOcpp/src/ArduinoOcpp/MessagesV16/StopTransaction.cpp:5:
/Users/phanigalla/Documents/Arduino/libraries/ArduinoOcpp/src/ArduinoOcpp/MessagesV16/StopTransaction.h:25:10: error: 'vector' in namespace 'std' does not name a template type
std::vector<std::unique_ptr> transactionData;
^~~~~~
/Users/phanigalla/Documents/Arduino/libraries/ArduinoOcpp/src/ArduinoOcpp/MessagesV16/StopTransaction.h:25:5: note: 'std::vector' is defined in header ''; did you forget to '#include '?
/Users/phanigalla/Documents/Arduino/libraries/ArduinoOcpp/src/ArduinoOcpp/MessagesV16/StopTransaction.h:11:1:
+#include
/Users/phanigalla/Documents/Arduino/libraries/ArduinoOcpp/src/ArduinoOcpp/MessagesV16/StopTransaction.h:25:5:
std::vector<std::unique_ptr> transactionData;
^~~
/Users/phanigalla/Documents/Arduino/libraries/ArduinoOcpp/src/ArduinoOcpp/MessagesV16/StopTransaction.h:33:68: error: 'std::vector' has not been declared
StopTransaction(std::shared_ptr transaction, std::vector<std::unique_ptrArduinoOcpp::MeterValue> transactionData);

Hi, thank you for the report. This error wasn't easy to reproduce, but I found a condition where it occurs. Please check out this branch: fix-87


Allow the case insensitive middleware to be added

I'm not 100% about this, but I get an error when using the middleware in typescript and adding this line removes the error.

Coverage remained the same at 98.932% when pulling 1c4af9c24b7e9cd7c2feac7c0c2c68132fe971ef on casras:patch-1 into 925e0f6de3f38326439849c8b62c2ebc7b35be63 on kogosoftwarellc:master.

Can you show the way you're using it?

It's used in a route like following, in a typescript project
get.apiDoc = {   description: "get some x",   tags: ["some tag"],   operationId: "getsomex",   parameters: [     {       name: "y",       in: "query",       type: "string",       description: "some y",       required: true,       "x-express-openapi-case-sensitive": false,     },   ],   responses: {     200: {       description: "Success",       schema: {         $ref: "#/definitions/GetSomeXResponse",       },     },     default: {       $ref: "#/responses/ErrorResponse",     },   }, };
Here "x-express-openapi-case-sensitive": false, is not resolved, and gives this warning/error:
[ts] Type '{ [x: string]: string | string[] | { name: string; in: string; type: string; description: string;...' is not assignable to type 'OperationObject'.
Types of property 'parameters' are incompatible.
Type '{ name: string; in: string; type: string; description: string; required: boolean; "x-express-open...' is not assignable to type '(ReferenceObject | InBodyParameterObject | GeneralParameterObject)[]'.
Type '{ name: string; in: string; type: string; description: string; required: boolean; "x-express-open...' is not assignable to type 'ReferenceObject | InBodyParameterObject | GeneralParameterObject'.
Object literal may only specify known properties, and '"x-express-openapi-case-sensitive"' does not exist in type 'ReferenceObject | InBodyParameterObject | GeneralParameterObject'.

Thanks!  I see the issue now.  I'll publish in a few.


browser and typecheck do not work together

Describe the bug
I want to run both browser and typecheck tests at the same time.
When typecheck is enable the typecheck tests gets included and run in the browser.
Reproduction
https://stackblitz.com/edit/vitest-dev-vitest-rac6tk?file=test%2Ftypes.test-d.ts
System Info
Local:

  System:
    OS: macOS 14.3
    CPU: (8) arm64 Apple M1
    Memory: 1.06 GB / 16.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 18.18.2 - ~/.volta/tools/image/node/18.18.2/bin/node
    Yarn: 1.22.19 - ~/.volta/tools/image/yarn/1.22.19/bin/yarn
    npm: 9.8.1 - ~/.volta/tools/image/node/18.18.2/bin/npm
    pnpm: 8.9.2 - ~/Library/pnpm/pnpm
    bun: 1.0.7 - ~/.bun/bin/bun
  Browsers:
    Brave Browser: <IP_ADDRESS>
    Chrome: 120.0.6099.234
    Safari: 17.3
  npmPackages:
    @vitest/browser: ^1.2.1 => 1.2.1
    vitest: ^1.2.1 => 1.2.1

### Used Package Manager

npm

### Validations

- [X] Follow our [Code of Conduct](https://github.com/vitest-dev/vitest/blob/main/CODE_OF_CONDUCT.md)
- [X] Read the [Contributing Guidelines](https://github.com/vitest-dev/vitest/blob/main/CONTRIBUTING.md).
- [X] Read the [docs](https://vitest.dev/guide/).
- [X] Check that there isn't [already an issue](https://github.com/vitest-dev/vitest/issues) that reports the same bug to avoid creating a duplicate.
- [X] Check that this is a concrete bug. For Q&A open a [GitHub Discussion](https://github.com/vitest-dev/vitest/discussions) or join our [Discord Chat Server](https://chat.vitest.dev).
- [X] The provided reproduction is a [minimal reproducible example](https://stackoverflow.com/help/minimal-reproducible-example) of the bug.

I think this is the same as https://github.com/vitest-dev/vitest/issues/5019

Ok, I see now. It is the same reason, but it can be fixed.


adds new WasmImportLinkAttribute for C# and initial support for mono …

WIP

can I try this out with the nightly wasi-experimental workload? I think CI install scripts will need to be updated.

can I try this out with the nightly wasi-experimental workload? I think CI install scripts will need to be updated.

Yes the CI scripts needs to be updated. I will do that once it works as expected.

Dependent upon https://github.com/dotnet/runtime/issues/95084

There are still some issues with the generated components as they can't be ran. There seems to be something incorrect with the types. But I think we can merge this for now as it doesn't break anything already existing and it allows us to actually build using mono as well and test the code gen with mono.


Move from yarn to pnpm

pnpm is faster, uses less disk space and has amazing monorepo commands. The architecture is a lot better than yarn or npm.
This will allow us to get rid of our Makefile and will improve speed.
Furthermore we can use pnpm recursive link in CI to test against the git HEAD of each package

👍

Done with #821


9 x 12 top and bottom ServoCity plates discontinued

@dcschooley found out they are discountinued.

One idea is to replace with two 9 x 6 plates and connectors.
Better: use a laser cutter

YouDoItElectronics still has it in stock
British website still has it in stock (for now)

These will likely be out of stock as well soon

Using two 4.5x12 inch plates is doable. The hole for the rocker-bogie pivot will be on the seam, which means you are grinding the hole instead of drilling it. Materials for cutting the top and bottom pieces out of acrylic would cost $20-$35, depending on color and where you buy it. (You would need two 12x20 sheets.) With another sheet you can do the entire body in acrylic. I don't know what it would cost to have someone like Sculpteo make them.


Bump version

🗣 Description
This pull request bumps the version so we can build a fresh AMI.
💭 Motivation and context
The previous AMI is getting long in the tooth, so we are overdue for a rebuild.
🧪 Testing
All pre-commit hooks pass.  I also built a staging AMI and deployed it to our staging COOL environment and verified that it functions as expected.
✅ Pre-approval checklist

[x] This PR has an informative and human-readable title.
[x] Changes are limited to a single goal - eschew scope creep!
[x] All relevant type-of-change labels have been added.
[x] I have read the CONTRIBUTING document.
[x] These code changes follow cisagov code standards.
[x] All new and existing tests pass.
[x] Create and test a staging AMI with these changes.

✅ Pre-merge checklist

[ ] Finalize version.

✅ Post-merge checklist

[ ] Create a production AMI with these changes.

Should this be a minor version bump? This seems more like a patch/build bump, but I might be mistaken.

This is the first build after the Lineage PR that changed the base AMI from Buster to Bullseye.  Since the bump didn't happen there, I'm making it happen here.

Should this be a minor version bump? This seems more like a patch/build bump, but I might be mistaken.

This is the first build after the Lineage PR that changed the base AMI from Buster to Bullseye. Since the bump didn't happen there, I'm making it happen here.

Not trying to derail things, but I see the Bullseye change as part of the v1.0.1 tag+release. Am I missing something?

Should this be a minor version bump? This seems more like a patch/build bump, but I might be mistaken.

This is the first build after the Lineage PR that changed the base AMI from Buster to Bullseye. Since the bump didn't happen there, I'm making it happen here.

Not trying to derail things, but I see the Bullseye change as part of the v1.0.1 tag+release. Am I missing something?

Ugh.  You are correct.  I will fix.


Release Google.Cloud.Metastore.V1Alpha version 1.0.0-alpha01

Changes in this release:
Initial release.

Note: although this generates a NetworkName resource that we might want to call ComputeNetworkName, we can do that later with a breaking change once we've got suitable tooling; this is only an alpha API so breaking changes are okay.

Created release for Google.Cloud.Metastore.V1Alpha-1.0.0-alpha01


[Improvement]: Support custom-detailed distinct error subtypes

As far as I can tell, following should work according to the spec. But currently it gives invalid intersection type
type BlobErrorDetail record {|
        int httpStatusCode;
        string azureErrorCode;
|};

type BlobError distinct error<BlobErrorDetail>;

public type ResourceNotFoundDetail record {|
        404 httpStatusCode = 404;
        "ResourceNotFound" azureErrorCode = "ResourceNotFound";
|};

type ResourceNotFound BlobError & distinct error<ResourceNotFoundDetail>

This is because of the default values.
Works when ResourceNotFoundDetail is
public type ResourceNotFoundDetail record {|
    404 httpStatusCode;
    "ResourceNotFound" azureErrorCode;
|};

Related spec issues/discussions - https://github.com/ballerina-platform/ballerina-spec/issues/754, https://github.com/ballerina-platform/ballerina-spec/issues/544#issuecomment-778099662.

Closing this since the behaviour is in-line with what was defined by the spec (at least for now).


Shaking fix for new-location-based components

⚠ All PRs have to be done versus 'dev' branch, so be aware of that, or we'll close your issue ⚠
What kind of change does this PR introduce?

This introduces the "reduce shaking" feature of the older location-based components into gps-new-camera, using exponential smoothing.
Can it be referenced to an Issue? If so what is the issue # ?
How can we test it?
Use the smoothing example from the new-location-based examples.

Summary

Shaking fix not available in new A-Frame location based components.
Does this PR introduce a breaking change?
No
Please TEST your PR before proposing it. Specify here what device you have used for tests, version of OS and version of Browser
Chrome latest on Pixel 3, Android 12
Other information
@kalwalt could you check this before I merge? I also have another couple of fixes I'm aiming to create PRs for, when all these are merged I will probably make a new release. Thanks.

Sorry! Opened this with my other github account. This is nickw1.

I think i will not have the time to test It during these days, maybe next week but i can not promise...

OK no worries!

@kalwalt if it helps, I now have a demo of the "shaking fix" online at
https://hikar.org/sf/aframe/examples/new-location-based/smoothing/
It requires a mobile device to work.
I also have a demo of #484 at
https://hikar.org/sf/aframe/examples/new-location-based/basic2/
(can test on desktop device)
If you don't have time to test these, are you happy if I merge them myself? I'd like if possible to make a new release (while I'm on holiday, back to work next week!) with these, #485 and one or two other things to increase the compatibility between new-location-based and the classic location-based components.
Thanks.

Since i have no time to test and if you think that this will help in some way the location based feature, you can merge It. 🙂

@kalwalt many thanks. Essentially this stops the objects "shaking" by smoothing the sensor readings. This fix was applied to the older location-based components a while ago, but with this PR it's now available in the new-location-based components.


Cose Signature Input

Fixes #147

Do we want more flexibility (protected, vs. unprotected headers)? I seem to recall that we handle unprotected headers too in VC-K. If I'm right, I think we should offer both variants through shorthands

The unprotected headers are not included in the signature input since they're ... well ... not protected by the signature.


[BUG] registering node for new cluster is stuck with "Waiting for cluster agent to connect"

Rancher Server Setup

Rancher version: experienced with 2.8.0, 2.7.9 and 2.6.13
Installation option (Docker install/Helm Chart):

If Helm Chart, Kubernetes Cluster and version (RKE1, RKE2, k3s, EKS, etc):

Proxy/Cert Details:

Information about the Cluster

Kubernetes version: 1.26.11+rke2r1
Cluster Type (Local/Downstream):

downstream cluster, custom cluster

Describe the bug
When creating a new cluster, it is not possible, to finish the registration of new nodes. All steps of the installation procedure seem to be executed, the Rancher UI ends with "Waiting for cluster agent to connect".
The log files at /var/log/pods/cattle-system_cattle-cluster-agent-cryptic-name show the error
2024-01-16T13:36:53.907353181+01:00 stderr F ERROR: https://hostname-removed-for-privary.com/ping is not accessible (OpenSSL/1.1.1l-fips: error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error)
However it is possible without problems to register a new node into an already existing and working cluster.
To Reproduce

Create a new cluster
Use registration command on fresh node
see failure

Result
Expected Result

The node should be registered in the cluster.
Screenshots

Additional context

We could find out what the problem is, but could not yet solve it yet.
We have an entry <8-letter-name>.standby in our searchlist (netplan under ubuntu 22.04).
The rancher-cluster url is rancher-xyz-abcd.<8-letter-name>.standby . As long as we have the domain in our searchlist, we get the openssl error from above (OpenSSL/1.1.1l-fips: error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error). When we change the searchlist to contain another internal domain ( xyz.local ) and reboot the node, then it immediately works and the nodes connect to the rancher cluster.
So it looks like the cattle-cluster-agent somehow adds the domain from the searchlist to the cluster url additionally, which results in an invalid url. We had such a behaviour with .local domains in the searchlist before, but were hoping that .standby does work without problems, as it's not a mdns domain....

We could solve it with the solution from https://github.com/rancher/rancher/issues/16454#issuecomment-1900882798 .

I suggest you get into the pod and print the logs within the init container. And then you may figure out what problems cause your failed deployment.


Create Http info struct

Part of #43
What
Create HTTP info struct which will contain HTTP response information.
Testing
None, this just defines the HTTP struct.
Reviewers
reviewer @ricellis

+1

+1


set theoretic methods always return a geometry

Add a note about the set-theoretic methods always returning a geometry and how to treat that in conditions. Ref https://github.com/Toblerity/Shapely/issues/77
I have no idea if the reference syntax is correct, please verify that!
Also, I am just assuming that what I say is actually true :o)

Coverage remained the same at 79.944% when pulling 6317cd53632581da0890effe0d49849e989349c8 on kannes:patch-1 into 0fe02c43c3cfaff9cc5a32b190723c88ddc95073 on Toblerity:master.


Error: The digest of the reviewed and freshly downloaded crate were different

On some crates I keep getting the following sort of error when I try to run cargo crev review on them:
Error: The digest of the reviewed and freshly downloaded crate were different; i_bS1vb-271a-02WkBOf7D-yGi-t3fsYJ3kco8FKrNY != v_iKtjR6uB7QFaZ0_sOyYIAcDHidjucAjRGvjXOXqq0; /home/icefox/.cargo/registry/src/github.com-1ecc6299db9ec823/randomize-3.0.0-rc.3 != /home/icefox/.cargo/registry/src/github.com-1ecc6299db9ec823/randomize-3.0.0-rc.3.crev.reviewed

This occurs reliably on randomize and axiom, which are totally unrelated.  Not sure what is going on here, since I can review other crates successfully.  I've tried nuking the registry folder but the error still occurs.
Backtrace:
stack backtrace:
   0: failure::backtrace::internal::InternalBacktrace::new::hcb3625a47088b6f7 (0x564b51d18dd8)
   1: <failure::backtrace::Backtrace as core::default::Default>::default::hcff7db86cea2a064 (0x564b51d18f90)
   2: cargo_crev::shared::check_package_clean_state::h0942369bdb5012dd (0x564b513edc38)
   3: cargo_crev::review::create_review_proof::h64adffb3bc722a09 (0x564b51363b56)
   4: cargo_crev::shared::handle_goto_mode_command::hc59aa21ade0c759e (0x564b513f4f9f)
   5: cargo_crev::run_command::hfe66a2e803387847 (0x564b51347a6a)
   6: cargo_crev::main::h318057d9c4548283 (0x564b5134cf53)
   7: std::rt::lang_start::{{closure}}::h98c65638f7c344f3 (0x564b513cabf3)
   8: std::rt::lang_start_internal::{{closure}}::hf367a5a6ae52b0ce (0x564b51d65103)
             at src/libstd/rt.rs:49
      std::panicking::try::do_call::h9d779bc5e27e3284
             at src/libstd/panicking.rs:296
   9: __rust_maybe_catch_panic (0x564b51d6effa)
             at src/libpanic_unwind/lib.rs:80
  10: std::panicking::try::h4af22d9cb0afa351 (0x564b51d65ccd)
             at src/libstd/panicking.rs:275
      std::panic::catch_unwind::hbb68a9ada87bfb97
             at src/libstd/panic.rs:394
      std::rt::lang_start_internal::hba9e09d74440ce4d
             at src/libstd/rt.rs:48
  11: main (0x564b5134d062)
  12: __libc_start_main (0x7f8033e4609b)
  13: _start (0x564b51337a6a)
  14: <unknown> (0x0)

Which version are you using: 0.8.3
How did you install crev: cargo-install cargo-crev
What OS/platform are you running on: Linux, Debian 10 Stable

My initial guess: this crates might self-modifing (so they add source files in ./src via build.rs) or just our logic of which files to ignore is somehow wrong.

It's definitely happening with crates that don't self-modify.  Example: autocfg.
$ cargo crev goto autocfg
Error: The digest of the reviewed and freshly downloaded crate were different; 4lc9vVY0Lry7N__5WNBeHUCCfrz3OXbeaGpfr3xXnFk != okLeq3B1BjroNk0Ijjg8NnODmj_vJg0hW2K_T8OrM2M; /home/icefox/.cargo/registry/src/github.com-1ecc6299db9ec823/autocfg-0.1.6 != /home/icefox/.cargo/registry/src/github.com-1ecc6299db9ec823/autocfg-0.1.6.crev.reviewed

$ find . -type f -exec sha512sum "{}" + > ~/sum1
$ cd ../autocfg-0.1.6.crev.reviewed
$ find . -type f -exec sha512sum "{}" + > ~/sum2
$ diff ~/sum1 ~/sum2
# No output
$ sha512sum -c ~/sum1
./.cargo-ok: OK
./.gitignore: OK
./.travis.yml: OK
./Cargo.toml.orig: OK
./Cargo.toml: OK
./LICENSE-APACHE: OK
./LICENSE-MIT: OK
./README.md: OK
./examples/integers.rs: OK
./examples/paths.rs: OK
./examples/traits.rs: OK
./examples/versions.rs: OK
./src/error.rs: OK
./src/lib.rs: OK
./src/tests.rs: OK
./src/version.rs: OK
./.cargo_vcs_info.json: OK
./Cargo.lock: OK

I've looked at the crev code where it does this check and I don't see what's happening either, though.  Is it possible for walkdir to traverse dirs with the same contents in different orders, maybe?  :thinking:

Is it possible for walkdir to traverse dirs with the same contents in different orders, maybe? ￼

Sound plausible. If you're on it, try adding dbg!() somewhere and compare...

The .cargo/registry/src/github.com-1ecc6299db9ec823/autocfg-0.1.6.crev.reviewed version includes Cargo.lock in the hash and the non-reviewed version doesn't.  Looks like the crate includes its Cargo.lock in the .crate file, whether deliberately or not.  Adding Cargo.lock to cargo_crev::shared::cargo_min_ignore_list() makes this error go away, but I'm not sure whether that is the best solution since sometimes a crate's Cargo.lock is important.

Cargo.lock is ignored for libraries, so ignoring the lockfile is probably fine.

Oh. I see what is happening. There are two ignore-lists - one (full) for crate source that you reviewed, that often generates additional files, and one (min) for a clean copy of crate where cargo should only have added .cargo-ok marker.
https://github.com/dpc/crev/blob/562f5acbb53fcdbc64ccc3b7e3a33a3b9b422cad/cargo-crev/src/unsorted_mess.rs#L106
For some reason I though that ignoring Cargo.lock in full list was a good idea, because it might have got generated during the review. I've missed the fact that some libraries might actually provide it.
I guess the solution is to remove Cargo.lock from the full list, or... possibbly better... attempt calculating checksum with or without it and be happy if any of the two matches. This way if the user actually did cargo build as a part of the review, the newly generated or modified Cargo.toml will not upset digest checker.
The root of the problem is how easy it is to introduce modifications into source directory, just by reviewing it.

Also, maybe we should not fail anything and just display a warning, since this check is nor very reliable. Maybe we shouldn't even bother with that check at all...

Seems like the goal is to ensure that the hash we provide with the proof is the same as what the crate actually contains.  So could we just hash the .crate file instead, or extract a temporary copy into a known location and hash everything that contains?

Is it possible for walkdir to traverse dirs with the same contents in different orders, maybe?

Indeed. Under default settings, walkdir yields directory entries in the order provided by the underlying system APIs. If you need consistent ordering, you can use sort_by to sort by file name. It will need to buffer only entries in each individual directory, and not the whole tree.

@BurntSushi Right not the paths are sorted manually using BTreeMap https://github.com/dpc/crev/blob/master/recursive-digest/src/lib.rs#L109 . Not the best thing for memory consumption, but easy and works.
@icefoxen

Seems like the goal is to ensure that the hash we provide with the proof is the same as what the crate actually contains.

Indeed. It's the last check to confirm that what has been reviewed is actually the same as a fresh copy.

So could we just hash the .crate file instead,

I don't know what .crate is :rofl: . But according to the spec, crev is supposed to make a recursive digest of content of the crate.

or extract a temporary copy into a known location and hash everything that contains?

That's what is being done actually. crev moves the reviewed source code $x to $x.reviewed. Then it makes cargo download a fresh copy of $x. The reason is - some editors leave some *.tmp files and other garbage, and we don't want to hash it.
And then, as a final precaution, we calculate and compare the digest of $x with $x.reviewed. And this is when stuff goes wrong, because in $x.reviewed we ingore Cargo.lock under assumption that it has been manually crated by the reviewer doing cargo build. We also ignore target/ and .cargo-ok which is some weird marker that cargo creates. Unforuntely if the crate already had Cargo.lock this logic is wrong.
I think this whole check is a bit pointless and it just creates problems. When creating the review, we could just hash the fresh copy, and not bother with double checking, under the assumption that cargo will not really lie to us and provide a different copy then the one that reviewer just checked. Right now it's just being paranoid for no good reason. Also, if the text editor left any garbage, then the user is left with this "unclean" error which doesn't help anyone.

Alternatively, it could be made into warning for the user that wants to double check what was the difference. In the future we could display a list of changes between two dirs or something.

I don't know what .crate is

I just meant the autocfg-0.1.6.crate tarball file that cargo downloads from crates.io.  Pretty sure it stashes those somewhere, but I don't recall where.
I'll think about this.  It would be nice to keep some kind of check so that there's some kind of promise that what you review is the same as what is actually in crates.io.

I've implement a fix, and turned it into a warning.


[Impeller] Metal validation errors in blur coverage unit tests

On my M1 mac, when I run impeller_unittests from a host_debug build, I hit metal validation errors on a few unit tests of blur coverage. They look like this:
$ flutter/testing/run_tests.py --quiet --type engine --variant host_debug --engine-filter impeller_unittests --engine-capture-core-dump
...
[ RUN      ] Play/DirectionalGaussianBlurFilterContentsTest.RenderCoverageMatchesGetCoverage/Metal
-[MTLDebugRenderCommandEncoder setFragmentTexture:atIndex:]:2528: failed assertion `Set Fragment Buffers Validation
texture is Memoryless, and cannot be assigned.
'

I'm guessing the test is passing on CI and failing locally because these tests are pinned to an intel machine on CI.
These tests might have been affected by recent changes in this area like https://github.com/flutter/engine/pull/47576, and https://github.com/flutter/engine/pull/48149, but may also have been hitting validation errors before those changes?

The default texture descriptor is device transient, see https://github.com/flutter/engine/blob/900ce09b08b2549762990edb07cbacec689e7247/impeller/entity/contents/filters/gaussian_blur_filter_contents_unittests.cc#L117-L119
This needs to be updated to be device private. FYI @gaaclarke


New gcc-cross w/ GCC for ARM

Dockerfile is extended to use a git version of crosstool-ng in order to build a more recent set of compilers. The compiler *.configs have been adapted w/ a ct-ng oldconfig and moved to build/new. Files for ct-ng-1.23 are moved to build/old, the ones prior to that to build/even-older (which can probably be deleted as it doesn't run on Ubuntu 18.04.
The config files within build/new have been tested, seem to work, and now contain gfortran. After changing kernel version and disabling Ada, Objective C/C++, and Go, the new PPC config from #127 also seems to work.
Uploading to s3 storage and the installation procedure is not tested. There is also a clone of admin-daily-builds.sh that should build all cross-compilers (also not tested).
With the ct-ng oldconfig, I was prompted for a number of version choices for kernel, libc, and pre-requisite libraries for GCC. I tweaked this a little to successfully build the compilers, but largely have no idea what impact this might have. Especially the kernel version seems arbitrary.

Ha, was thinking the same thing https://github.com/grooverdan/compiler-explorer-image/commit/6b37b8f7efdfba8e17e2f887e1c66fe3cab23c6e.
Totally agree with old/even-older/1.22.0, even with the patch I added in the commit, the arm/avr compilers generate a SIGFPE during the compilation of ppl-0.11.2. Even powerpc-4.8.5 fails in gcc-final with cfns.gperf:101:1: error: 'const char* libc_name_p(const char*, unsigned int)' redeclared inline with 'gnu_inline' attribute.
All except the arm64 ones (failed in binutils/zlib/configure script being truncated - just odd) of new/1.23.0 managed to compile on ct-ng-git/latest.
Only needed to remove ADA from the PPC64 builds in #127 like https://github.com/grooverdan/compiler-explorer-image/commit/fafcbfaca1c8dc75e44c94813cf6940321992c57, and thanks for testing.
Been testing with:

 for a in *.config; do b=${a%.config}; docker rm $b;   docker run --name $b -v gcc-cross-opt:/opt/.build mattgodbolt/gcc-cross:latest ./build.sh ${b%%-*} ${b#*-}; done

note: haring a volume of just /opt/.build/tarballs would of been much less prone to conflicts in tools and /opt/.build/$arch.

@grooverdan I like the idea of naming the config directories after the ct-ng version, makes things a lot clearer. From a previous exchange with @mattgodbolt I seem to remember that the cross-compilers are not (re-)built automatically at fixed times. Instead the build is run once, the resulting compilers than used from that point on. So I wasn't too worried about rebuilding all the previous versions/architectures since they are there already.
I also didn't bother with patching anything or looking into errors during compilation. It either worked or it didn't. I stopped after tweaking the config files to ct-ng.
You say the arm64 compilers did not build for you? I'm pretty sure I tested them with the changes in my branch. Also, a colleague of mine has been asking about the latest compilers for Power, but I thought I don't touch those and rather leave that to you.

note: haring a volume of just /opt/.build/tarballs would of been much less prone to conflicts in tools and /opt/.build/$arch.

I'm afraid I don't understand this comment here.

Ok. I'll put my commit as a separate PR. Questions about what you have here that I'll incorporate:

set -exuo pipefail will probably include that in build.sh
admin-cross-builds.sh - was this from @mattgodbolt ? I missed the bit that triggers all the builds so I guess this is it. Probably could generate the compiler list from the (functional?) config files.
like the apt-get clean/check
what does installing python-dev achieve?

Arm64 failures might of been as a result of me sharing the /opt/.build as a volume between concurrently running docker images. Testing it again now.
If your colleague wants anything in particular in the latest Power compilers please leave a note on #127 or email me.

* `set -exuo pipefail` will probably include that in build.sh
* admin-cross-builds.sh - was this from @mattgodbolt ? I missed the bit that triggers all the builds so I guess this is it. Probably could generate the compiler list from the (functional?) config files.

I added admin-cross-builds.sh in the hope it would make building the cross-compilers a little simpler. It's adopted from admin-daily-builds.sh that is in repository. Generating a list from the config files might be a nice idea. I guess that really depends on how often/when the cross-compilers will in the end be built. That's not my call.

* like the apt-get clean/check

I had to add this because I had failing apt-get's without that. Possibly because some bits of the Dockerfile had been cached and it was using outdated package lists. I'm guessing here since I don't know how docker works in detail. So it may not be necessary.

* what does installing python-dev achieve?

Don't know? I copied whatever ct-ng suggested as necessary packages to build it on Ubuntu.

If your colleague wants anything in particular in the latest Power compilers please leave a note on #127 or email me.

Nothing in particular, just updated plain compilers.

Hi @dbroemmel - thanks for this! Sorry I haven't looked at this earlier. Will try to get to it tonight and then see how the builds pan out!

Yes, definitely having a list of the "expected" builds this should support is handy... the admin-cross-builds.sh is the thing I probably need the most. Though its name is misleading I think (I wouldn't run it on the admin node), but that's far from the point :) Thanks for the reply. If @dbroemmel doesn't have anything to add I'll steal the configurations from admin-cross-builds and run them

From the gcc-cross/build/{1.22.0,1.23.0,latest} directories I was crudely running:
for a in *config; do
   b=${a%.config}
  docker rm $b
  docker run --name $b -v gcc-cross-opt:/opt/.build/tarballs mattgodbolt/gcc-cross:latest ./build.sh ${b%%-*} ${b#*-}
done

gcc-cross-opt was a created (docker volume create gcc-cross-opt) to avoid duplicate downloads. Never got to making a nicer script like above.
Hack and use as you see fit.

Fabulous! Thanks @grooverdan!

I have to pack up for the night, but tried something similar, and:
++ basename gcc-cross/build/1.22.0/avr-4.6.4.config
+ a=avr-4.6.4.config
+ b=avr-4.6.4
+ docker run --rm -v gcc-cross-opt:/opt/.build/tarballs mattgodbolt/gcc-cross:latest ./build.sh avr 4.6.4 s3://compiler-explorer/opt/
++ pwd
+ ROOT=/opt
....
[INFO ]  Installing MPFR for host: done in 23.53s (at 03:47)
[INFO ]  =================================================================
[INFO ]  Installing PPL for host
[EXTRA]    Configuring PPL
[EXTRA]    Building PPL
[ERROR]    /opt/.build/src/ppl-0.11.2/src/Row.inlines.hh:118:23: error: unknown array size in delete
...
[ERROR]  >>  For more info on this error, look at the file: 'build.log'
[ERROR]  >>  There is a list of known issues, some with workarounds, in:
[ERROR]  >>      'crosstool-ng-1.22.0/docs/B - Known issues.txt'
[ERROR]
[ERROR]  (elapsed: 5:14.49)
[05:15] / make[1]: *** [build] Error 2
/opt/crosstool-ng-1.22.0/ct-ng:152: recipe for target 'build' failed
/opt/crosstool-ng-1.22.0/ct-ng:155: recipe for target 'build.4' failed
make: *** [build.4] Error 2

so, sadly doesn't look like it's working (unless I'm running a bad build here?) Any thoughts?

Its not you, I get the same fault. Seems to have been a consequence of moving to bionic. I did change the FROM to 16.04, took out my 1.22.0 patch, and gcc-cross/build/1.22.0/avr-4.6.4.config will build. I'm assuming the rest will follow suit.
Other fails are: https://github.com/mattgodbolt/compiler-explorer-image/pull/129#issuecomment-435324350. While it would be nice to make these old compilers I suspect the bionic gcc has just been updated too much to cope with some older source trees. Even the 1.23.0/*{6.3.0|7.1.0}* trigger a compile failure that was found the ct-ng issue tracker (that's fixed in latest/*{6.4.0|7.3.0}). Might need to maintain mattgodbolt/gcc-cross:16.04 for reproducing older compilers.
The only new configurations builds are the ones in gcc-cross/build/latest, and those definitely build.

@mattgodbolt I had a quick look if there's anything in this PR not already included by #127, #130, or #131. As @grooverdan said it's only the 'convenience script'. I modeled the script after one of yours and found that easier to then control which versions to build. Since you are initiating those builds this is up to you how to do this (I remember when first looking at the collection of scripts I didn't find one building the cross-compilers, c.f. https://github.com/mattgodbolt/compiler-explorer/pull/948#discussion_r201007721, https://github.com/mattgodbolt/compiler-explorer/pull/948#discussion_r202525564).
So, no need to merge this one, I'll close it.
Thanks for the comments and merging the other PRs.


Corrected Typo - 'couchbase' to 'couchdb'.

Our documentation states that users should set their log source to couchdb in one instance, but then contradicts itself in saying it should be set to 'couchbase' later. This pull request is fixing this small typo to make the documentation less confusing.
What does this PR do?
Fix a typo in the Couchbase documentation
Motivation
A customer was confused from the typo. Fixing it should hopefully help others not fall for the same issue.
Ticket: https://datadog.zendesk.com/agent/tickets/309575
Additional Notes

Review checklist (to be filled by reviewers)

[ ] Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
[ ] PR title must be written as a CHANGELOG entry (see why)
[ ] Files changes must correspond to the primary purpose of the PR as described in the title (small unrelated changes should have their own PR)
[ ] PR must have changelog/ and integration/ labels attached

I think it's a mistake in the README and in the conf.yaml example that should be changed instead 🤔

Closing, as it seems this has already been fixed via #5977.


Rule: Disallow unused block params.

Given the following:
{{#foo-bar as |blah|}}
  Stuff goes here, but doesn't use block param at all.
{{/foo-bar}}

We should error indicating that the block param was not used (roughly the same as an unused variable in JS linters).

Going to take a stab at this.

Awesome!

hey @halfdan , did you begin to work on this rule?

I can take this if no one is working on it 🚢

@duggiefresh - I believe https://github.com/rwjblue/ember-template-lint/pull/88 is for this.

Oh sweet, then I'll search for something else. Thanks, Rob!

closed in https://github.com/rwjblue/ember-template-lint/pull/88


how to write regular expression with $ char

i have the following String "/^(00213|+213|0)(5|6|7)[0-9]{8}$/" as regular expression and when i test it i get the following error
Error compiling to JavaScript:
main.dart:2:35:
Error: A '$' has special meaning inside a string, and must be followed by an identifier or an expression in curly braces ({}).
  if(RegExp("/^(0)(5|6|7)[0-9]{8}$/").hasMatch('0795826193')){
                                  ^
Error: Compilation failed.

any solution please ??

use a leading r : r"/^(0)(5|6|7)[0-9]{8}$/"


Does not work with

http://jsfiddle.net/oa88xcdc/

The above fiddle only makes sense for Chrome (and a few other browsers), as it is the only browser that supports <input type="date"> for now. Unfortunately, this means that the input needs to be reverted to type="text", for this plugin to work in Chrome.
It certainly would be nice to be able to support the semantic type="date" input, but Chrome's date picker would probably just confuse the user anyway, as there would be two ways to select a date from a calendar view (clicking the down arrow Chrome displays).

see this SO post http://stackoverflow.com/questions/11320615/disable-native-datepicker-in-google-chrome

I was interested in this for mobile use.  If I'm not mistaken, defining input type date, time, or datetime on an input field will allow users to use native pickers on their phone if available, which is admittedly a better experience on a phone than the bootstrap datetime picker.
Perhaps through some combination of what @Eonasdan recommended I could get this to work?  I'm worried that if I hide the prompt will this also hide the picker that appears on a mobile device?
Also, I'm having trouble with testing this implementation in a time only picker (format: 'LT').  When I try to use input type = 'time', I get the error:
The specified value '08:01 AM' does not conform to the required format.  The format is 'HH:mm', 'HH:mm:ss' or 'HH:mm:ss.SSS' where HH is 00-23, mm is 00-59, ss is 00-59, and SSS is 000-999.
I can get this picker to work if I set the format option to  'HH:mm', but then I loose the AM/PM picker which I preferred.  Any ideas/thoughts on what I'm trying to do?


Why is ground-truth label all zero in irl_cost calculation?

in train_util.py:
def calc_loss(neighbors, ego, ego_regularization, scores, weights, ego_gt, neighbors_gt, neighbors_valid):
    mask = torch.ne(ego.sum(-1), 0)
    neighbors = neighbors[:, 0] * neighbors_valid
    cmp_loss = F.smooth_l1_loss(neighbors, neighbors_gt, reduction='none')
    cmp_loss = cmp_loss * mask[:, 0, None, :, None]
    cmp_loss = cmp_loss.sum() / mask[:, 0].sum()

    regularization_loss = F.smooth_l1_loss(ego_regularization, ego_gt, reduction='none')
    regularization_loss = regularization_loss * mask[:, 0, :, None]
    regularization_loss = regularization_loss.sum() / mask[:, 0].sum()

    label = torch.zeros(scores.shape[0], dtype=torch.long).to(scores.device)
    irl_loss = F.cross_entropy(scores, label)

    weights_regularization = torch.square(weights).mean()

    loss = cmp_loss + irl_loss + 0.1 * regularization_loss + 0.01 * weights_regularization

    return loss

When calculating the irl_loss, the ground-truth label is set to all zero, why? Shouldn't the label come from datasets ego trajectory?

I  have the same question with you, I think the predict ego trajectory which is closest to gt should be set to 1.

See #5. We did not include the gt ego trajectory in the tree generation, so the gt label is the generated trajectory closet to gt.
Thank you for your reply. But I still can't understand that all of the elements in label is set to zero，how to identify which ego trajectory is closet to gt

The elements in the ego trajectory tree have already been sorted in data processing, so the one closest to gt is at index 0.

The elements in the ego trajectory tree have already been sorted in data processing, so the one closest to gt is at index 0.

So, shouldn't label[0] be set to 1, with all other elements set to 0?

The label is actually the target index, which means for all data in the batch, the ground-truth index (label) is 0.

The label is actually the target index, which means for all data in the batch, the ground-truth index (label) is 0.

Thank you for your reply. I understand.

Thank you for reply!


Missing declared license

Type: Missing
Summary:
Missing declared license
Details:
Missing license
Resolution:
SharePoint Framework EULA in EULA folder
Affected definitions:

loader-cased-file 1.8.2

@capfei should we curate this if under a EULA?


Update alter-role-transact-sql.md

Microsoft Docs do not have examples on how to use special roles like dbmanager and loginmanager. Azure SQL Database does not have dbcreator server-level role, it has instead this special role named dbmanager.

@alberto-morillo : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Hi @AndreasWolter - Is this something you can help validate as appropriate to add to our documentation?
https://docs.microsoft.com/en-us/sql/t-sql/statements/alter-role-transact-sql?view=sql-server-ver15

@alberto-morillo : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Thanks for submitting these additions, @alberto-morillo!

Thank you for the corrections made.

@alberto-morillo - Did you mean to close this PR?

Thank you @VanMSFT.  The motivation to add this example come from 2 forum threads (1 on stackoverflow and 1 from Microsoft QA). Blessings for you. Have a great day!

Thanks, @alberto-morillo - I re-opened the PR, and will have it reviewed. Thanks for your time.

@ktoliver : Thanks for your contribution! The author(s) have been notified to review your proposed change.


有个问题，试了下其他类型图片，效果并不好，是否只适用于mpii数据集上图片？

This network is trained for single person pose estimation. If your input is a image with multiple persons, the detection would be bad.

I understand. The Image need target detection first, thanks


docs: add backup ADR

Add a very brief ADR of how backups can be implemented.

This is done and could be merged, right?