Internal Server error

Hi! Looks like the dashboard doesn't load! As I went in codewars page today I got this message:

then tried a different browser and got this as I tried logging-in:

however, when I checked status page there appear to be no issue... which isn't correct as I still get the server error above!

Thanks

Yes, it has been noticed.
Nevertheless, thank you for your report! I will try to bring attention of admins to the issue, even though I believe they also already noticed.

@vanessa2186 is this error still happening for you?

@VanessaGreene  looks like is all good now!  👍

it still happens for me after submitting the task which I got accepted.  When I tried to check other solutions it shows internal server error which blocks me to check other solutions

Can you please share with us screenshots or a video to try the reproduce the case? Thank you!

Can you please share with us screenshots or a video to try the reproduce the case? Thank you!

It shows "Internal Server Error" by simply clicking "Submit button" and View Solutions.

Hi! Yes, it looks like the issue is back when submitting katas... 🙁

Hi, I also have an Internal Server error every time I submit a kata - But it is saved as submitted in my profile.

As soon as you log in to codewars we are greeted by this error.

No, still Internal Server error every time I submit a kata.

Apologies for late reply! Looks like it's back for me! It takes me right to the solution page upon submission 👍
Thanks!

Ok... it's happening again! I give up.... 🙁

problem while opening any link inside codewars

 problem while opening any link inside codewars

I have the same problem.

I've just signed up, and I get it on the dashboard and the practice page. I managed to get the practice page to load once, but scrolling down it produced the internal server error message.

I've been getting the internal server error every day for about a week, when solving an issue.

Hi everyone! Thank you for all your patience over the past few days. We experienced several temporary outages on some of our services, which have prevented you from accessing Codewars or submitting your Kata solutions.
Our engineering team has established the root cause of this issue and determined that it was caused by one of our third-party services experiencing both failures and urgent maintenance in the past few days.
We are monitoring this situation and preparing to make necessary changes in the unfortunate case that we continue to experience issues.
Further information can be found here: https://codewarsstatus.com/incidents/2r36twmzxr15

well how can i fix it
for gods sake please stop this error

well how can i fix it

You won't be able to; this is one for them.

looks like a lot of people have this. same thing was yesterday and the day before.
its happening after i submit a solution to kata. (solution gets submitted though). also happens when i try to see other solutions.

Just joined and I get this error when trying to go to either Home or Practice. Dead in the water for now...

This issue is back, loading the dashboard on Chrome / Windows gives me the same internal server error.
Good luck with the fix!

Same here when trying to log in

Our team is investigating reports of outages, we hope to be back up and running shortly. We apologize for the inconvenience this has caused. If you are encountering other issues, please contact<EMAIL_ADDRESS>

Hi all, we have now recovered from this outage, this was caused by an external service experiencing outages. You can read more at https://codewarsstatus.com/incidents/cr7v1x71xmq1. If you encounter further issues, please contact our support team at<EMAIL_ADDRESS>

The issue has been noticed and engineering team has been notified. Someone will get to work on this, but currently there is no ETA.

I managed to get to one of admins and things got a bit better, but still wonky. Errors are still common, but some pages mostly work. But for example the search page is difficult to show.
I can keep bugging admins but i am afraid that they can be difficult to reach during weekend :)


UNKNOWN: Project 'project:user-vmtest2' when run cosign upload blob

Description
I follow the documentation here https://docs.sigstore.dev/cosign/working_with_blobs/#blobs-in-oci-registries but failed.
bash-4.2$ echo "my first artifact" > artifact
bash-4.2$ cosign upload blob -f artifact gcr.io/user-vmtest2/artifact
Uploading file from [artifact] to [gcr.io/user-vmtest2/artifact:latest] with media type [text/plain]
Error: GET https://gcr.io/v2/token?scope=repository%3Auser-vmtest2%2Fartifact%3Apush%2Cpull&service=gcr.io: UNKNOWN: Project 'project:user-vmtest2' not found or deleted.
main.go:74: error during command execution: GET https://gcr.io/v2/token?scope=repository%3Auser-vmtest2%2Fartifact%3Apush%2Cpull&service=gcr.io: UNKNOWN: Project 'project:user-vmtest2' not found or deleted.

I'm not sure if I miss something or gcr.io/user-vmtest2/artifact does not exist.
Version
bash-4.2$ cosign version
  ______   ______        _______. __    _______ .__   __.
 /      | /  __  \      /       ||  |  /  _____||  \ |  |
|  ,----'|  |  |  |    |   (----`|  | |  |  __  |   \|  |
|  |     |  |  |  |     \   \    |  | |  | |_ | |  . `  |
|  `----.|  `--'  | .----)   |   |  | |  |__| | |  |\   |
 \______| \______/  |_______/    |__|  \______| |__| \__|
cosign: A tool for Container Signing, Verification and Storage in an OCI registry.

GitVersion:    v2.0.1
GitCommit:     unknown
GitTreeState:  unknown
BuildDate:     unknown
GoVersion:     go1.20.2
Compiler:      gc
Platform:      linux/amd64

This is meant to be a placeholder for an image that you manage. You can follow a guide like https://cloud.google.com/container-registry/docs/quickstart to create a test artifact


USoundWaveProcedural lacks the QueueAudio function

USoundWaveProcedural lacks the QueueAudio function. How can I play base64-encoded sound like C++?

Make a wrapper function that is BlueprintCallable to expose it to C#

Expose it to C# through a wrapper function that is BlueprintCallable


Chrome does not support MP4 video recording?

Uncaught Error: This browser does not support MP4 video recording, please try again in Chrome.
    at Object.beginVideoRecord (CanvasCapture.ts:305:11)

Perhaps Chrome doesn't support it but I find that unlikely. Maybe it's something strange about my setup, I've tried disabling all extensions as I know that can be a source of pain but the error persists.
Chrome version: Version 108.0.5359.98 (Official Build) (x86_64)
Is this only a problem on my machine? Or perhaps a recent update has broken the browserSupportsMP4 function?
Thanks for your time

Chrome should support SharedArrayBuffer but you still need to set the dev server headers as explained in Caveats.
I use Vite for development, and this is what I did to make it work:
// vite.config.js (this file needs to be at the project root)

import { defineConfig } from "vite";

export default defineConfig({
  server: {
    headers: {
      "Cross-Origin-Embedder-Policy": "require-corp",
      "Cross-Origin-Opener-Policy": "same-origin",
    },
  },
});

thanks for the answer @cdaein, I've added a more descriptive error message to help resolve this issue.
closing this, as mp4 is working in Chrome currently: https://apps.amandaghassaei.com/canvas-capture/demo/


indexer/time/run/millis metric doesn't work

It is always zero. This is interesting because the default duration (in TaskStatus) is -1.

Current name of this metric is task/run/time, and it is already fixed.

@noddi is this a bug, as the fig shows, index task's duration is always 0,

Druid version: 0.9.0
Problem:

Hi

I think that this bug is fixed. I have tested, and the column duration it is not more 0


Unable to upgrade dnspy - checksum mismatch

I'm having issues running choco upgrade dnspy -y.
Chocolatey v0.10.11
Upgrading the following packages:
dnspy
By upgrading you accept licenses for the packages.

You have dnspy v5.0.7 installed. Version 5.0.9 is available based on your source(s).

Progress: Downloading dnspy 5.0.9... 100%

dnspy v5.0.9
dnspy package files upgrade completed. Performing other installation steps.
File appears to be downloaded already. Verifying with package checksum to determine if it needs to be redownloaded.
Error - hashes do not match. Actual value was '4571CCF630C408B0AF5E01ABC012C1B9354733C33DC1F5C70903169F0C0F065C'.
Downloading dnspy
  from 'https://github.com/0xd4d/dnSpy/releases/download/v5.0.0/dnSpy.zip'

Progress: 0% - Saving 84.58 KB of 23.82 MB
Progress: 0% - Saving 169.58 KB of 23.82 MB
Progress: 1% - Saving 254.58 KB of 23.82 MB
Progress: 1% - Saving 339.58 KB of 23.82 MB
Progress: 1% - Saving 424.58 KB of 23.82 MB
Progress: 2% - Saving 509.58 KB of 23.82 MB
Progress: 2% - Saving 594.58 KB of 23.82 MB
Progress: 2% - Saving 679.58 KB of 23.82 MB
Progress: 3% - Saving 764.58 KB of 23.82 MB
Progress: 3% - Saving 849.58 KB of 23.82 MB
Progress: 3% - Saving 934.58 KB of 23.82 MB
Progress: 4% - Saving 1019.58 KB of 23.82 MB
Progress: 4% - Saving 1.08 MB of 23.82 MB
Progress: 4% - Saving 1.16 MB of 23.82 MB
Progress: 5% - Saving 1.24 MB of 23.82 MB
Progress: 5% - Saving 1.33 MB of 23.82 MB
Progress: 5% - Saving 1.41 MB of 23.82 MB
Progress: 6% - Saving 1.49 MB of 23.82 MB
Progress: 6% - Saving 1.58 MB of 23.82 MB
Progress: 6% - Saving 1.66 MB of 23.82 MB
Progress: 7% - Saving 1.74 MB of 23.82 MB
Progress: 7% - Saving 1.83 MB of 23.82 MB
Progress: 8% - Saving 1.91 MB of 23.82 MB
Progress: 8% - Saving 1.99 MB of 23.82 MB
Progress: 8% - Saving 2.07 MB of 23.82 MB
Progress: 9% - Saving 2.16 MB of 23.82 MB
Progress: 9% - Saving 2.24 MB of 23.82 MB
Progress: 9% - Saving 2.32 MB of 23.82 MB
Progress: 10% - Saving 2.41 MB of 23.82 MB
Progress: 10% - Saving 2.49 MB of 23.82 MB
Progress: 10% - Saving 2.57 MB of 23.82 MB
Progress: 11% - Saving 2.66 MB of 23.82 MB
Progress: 11% - Saving 2.74 MB of 23.82 MB
Progress: 11% - Saving 2.82 MB of 23.82 MB
Progress: 12% - Saving 2.9 MB of 23.82 MB
Progress: 12% - Saving 2.99 MB of 23.82 MB
Progress: 12% - Saving 3.07 MB of 23.82 MB
Progress: 13% - Saving 3.15 MB of 23.82 MB
Progress: 13% - Saving 3.24 MB of 23.82 MB
Progress: 13% - Saving 3.32 MB of 23.82 MB
Progress: 14% - Saving 3.4 MB of 23.82 MB
Progress: 14% - Saving 3.49 MB of 23.82 MB
Progress: 14% - Saving 3.57 MB of 23.82 MB
Progress: 15% - Saving 3.65 MB of 23.82 MB
Progress: 15% - Saving 3.73 MB of 23.82 MB
Progress: 16% - Saving 3.82 MB of 23.82 MB
Progress: 16% - Saving 3.9 MB of 23.82 MB
Progress: 16% - Saving 3.98 MB of 23.82 MB
Progress: 17% - Saving 4.07 MB of 23.82 MB
Progress: 17% - Saving 4.15 MB of 23.82 MB
Progress: 17% - Saving 4.23 MB of 23.82 MB
Progress: 18% - Saving 4.32 MB of 23.82 MB
Progress: 18% - Saving 4.4 MB of 23.82 MB
Progress: 18% - Saving 4.48 MB of 23.82 MB
Progress: 19% - Saving 4.57 MB of 23.82 MB
Progress: 19% - Saving 4.65 MB of 23.82 MB
Progress: 19% - Saving 4.73 MB of 23.82 MB
Progress: 20% - Saving 4.81 MB of 23.82 MB
Progress: 20% - Saving 4.9 MB of 23.82 MB
Progress: 20% - Saving 4.98 MB of 23.82 MB
Progress: 21% - Saving 5.06 MB of 23.82 MB
Progress: 21% - Saving 5.15 MB of 23.82 MB
Progress: 21% - Saving 5.23 MB of 23.82 MB
Progress: 22% - Saving 5.31 MB of 23.82 MB
Progress: 22% - Saving 5.4 MB of 23.82 MB
Progress: 23% - Saving 5.48 MB of 23.82 MB
Progress: 23% - Saving 5.56 MB of 23.82 MB
Progress: 23% - Saving 5.64 MB of 23.82 MB
Progress: 24% - Saving 5.73 MB of 23.82 MB
Progress: 24% - Saving 5.81 MB of 23.82 MB
Progress: 24% - Saving 5.89 MB of 23.82 MB
Progress: 25% - Saving 5.98 MB of 23.82 MB
Progress: 25% - Saving 6.06 MB of 23.82 MB
Progress: 25% - Saving 6.14 MB of 23.82 MB
Progress: 26% - Saving 6.23 MB of 23.82 MB
Progress: 26% - Saving 6.31 MB of 23.82 MB
Progress: 26% - Saving 6.39 MB of 23.82 MB
Progress: 27% - Saving 6.47 MB of 23.82 MB
Progress: 27% - Saving 6.56 MB of 23.82 MB
Progress: 27% - Saving 6.64 MB of 23.82 MB
Progress: 28% - Saving 6.72 MB of 23.82 MB
Progress: 28% - Saving 6.81 MB of 23.82 MB
Progress: 28% - Saving 6.89 MB of 23.82 MB
Progress: 29% - Saving 6.97 MB of 23.82 MB
Progress: 29% - Saving 7.06 MB of 23.82 MB
Progress: 29% - Saving 7.14 MB of 23.82 MB
Progress: 30% - Saving 7.22 MB of 23.82 MB
Progress: 30% - Saving 7.3 MB of 23.82 MB
Progress: 31% - Saving 7.39 MB of 23.82 MB
Progress: 31% - Saving 7.47 MB of 23.82 MB
Progress: 31% - Saving 7.55 MB of 23.82 MB
Progress: 32% - Saving 7.64 MB of 23.82 MB
Progress: 32% - Saving 7.72 MB of 23.82 MB
Progress: 32% - Saving 7.8 MB of 23.82 MB
Progress: 33% - Saving 7.89 MB of 23.82 MB
Progress: 33% - Saving 7.97 MB of 23.82 MB
Progress: 33% - Saving 8.05 MB of 23.82 MB
Progress: 34% - Saving 8.13 MB of 23.82 MB
Progress: 34% - Saving 8.22 MB of 23.82 MB
Progress: 34% - Saving 8.3 MB of 23.82 MB
Progress: 35% - Saving 8.38 MB of 23.82 MB
Progress: 35% - Saving 8.47 MB of 23.82 MB
Progress: 35% - Saving 8.55 MB of 23.82 MB
Progress: 36% - Saving 8.63 MB of 23.82 MB
Progress: 36% - Saving 8.72 MB of 23.82 MB
Progress: 36% - Saving 8.8 MB of 23.82 MB
Progress: 37% - Saving 8.88 MB of 23.82 MB
Progress: 37% - Saving 8.96 MB of 23.82 MB
Progress: 37% - Saving 9.05 MB of 23.82 MB
Progress: 38% - Saving 9.13 MB of 23.82 MB
Progress: 38% - Saving 9.21 MB of 23.82 MB
Progress: 39% - Saving 9.3 MB of 23.82 MB
Progress: 39% - Saving 9.38 MB of 23.82 MB
Progress: 39% - Saving 9.46 MB of 23.82 MB
Progress: 40% - Saving 9.55 MB of 23.82 MB
Progress: 40% - Saving 9.63 MB of 23.82 MB
Progress: 40% - Saving 9.71 MB of 23.82 MB
Progress: 41% - Saving 9.79 MB of 23.82 MB
Progress: 41% - Saving 9.88 MB of 23.82 MB
Progress: 41% - Saving 9.96 MB of 23.82 MB
Progress: 42% - Saving 10.04 MB of 23.82 MB
Progress: 42% - Saving 10.13 MB of 23.82 MB
Progress: 42% - Saving 10.21 MB of 23.82 MB
Progress: 43% - Saving 10.29 MB of 23.82 MB
Progress: 43% - Saving 10.38 MB of 23.82 MB
Progress: 43% - Saving 10.46 MB of 23.82 MB
Progress: 44% - Saving 10.54 MB of 23.82 MB
Progress: 44% - Saving 10.62 MB of 23.82 MB
Progress: 44% - Saving 10.71 MB of 23.82 MB
Progress: 45% - Saving 10.79 MB of 23.82 MB
Progress: 45% - Saving 10.87 MB of 23.82 MB
Progress: 46% - Saving 10.96 MB of 23.82 MB
Progress: 46% - Saving 11.04 MB of 23.82 MB
Progress: 46% - Saving 11.12 MB of 23.82 MB
Progress: 47% - Saving 11.21 MB of 23.82 MB
Progress: 47% - Saving 11.29 MB of 23.82 MB
Progress: 47% - Saving 11.37 MB of 23.82 MB
Progress: 48% - Saving 11.45 MB of 23.82 MB
Progress: 48% - Saving 11.54 MB of 23.82 MB
Progress: 48% - Saving 11.62 MB of 23.82 MB
Progress: 49% - Saving 11.7 MB of 23.82 MB
Progress: 49% - Saving 11.79 MB of 23.82 MB
Progress: 49% - Saving 11.87 MB of 23.82 MB
Progress: 50% - Saving 11.95 MB of 23.82 MB
Progress: 50% - Saving 12.04 MB of 23.82 MB
Progress: 50% - Saving 12.12 MB of 23.82 MB
Progress: 51% - Saving 12.2 MB of 23.82 MB
Progress: 51% - Saving 12.28 MB of 23.82 MB
Progress: 51% - Saving 12.37 MB of 23.82 MB
Progress: 52% - Saving 12.45 MB of 23.82 MB
Progress: 52% - Saving 12.53 MB of 23.82 MB
Progress: 52% - Saving 12.62 MB of 23.82 MB
Progress: 53% - Saving 12.7 MB of 23.82 MB
Progress: 53% - Saving 12.78 MB of 23.82 MB
Progress: 54% - Saving 12.87 MB of 23.82 MB
Progress: 54% - Saving 12.95 MB of 23.82 MB
Progress: 54% - Saving 13.03 MB of 23.82 MB
Progress: 55% - Saving 13.11 MB of 23.82 MB
Progress: 55% - Saving 13.2 MB of 23.82 MB
Progress: 55% - Saving 13.28 MB of 23.82 MB
Progress: 56% - Saving 13.36 MB of 23.82 MB
Progress: 56% - Saving 13.45 MB of 23.82 MB
Progress: 56% - Saving 13.53 MB of 23.82 MB
Progress: 57% - Saving 13.61 MB of 23.82 MB
Progress: 57% - Saving 13.7 MB of 23.82 MB
Progress: 57% - Saving 13.78 MB of 23.82 MB
Progress: 58% - Saving 13.86 MB of 23.82 MB
Progress: 58% - Saving 13.94 MB of 23.82 MB
Progress: 58% - Saving 14.03 MB of 23.82 MB
Progress: 59% - Saving 14.11 MB of 23.82 MB
Progress: 59% - Saving 14.19 MB of 23.82 MB
Progress: 59% - Saving 14.28 MB of 23.82 MB
Progress: 60% - Saving 14.36 MB of 23.82 MB
Progress: 60% - Saving 14.44 MB of 23.82 MB
Progress: 60% - Saving 14.53 MB of 23.82 MB
Progress: 61% - Saving 14.61 MB of 23.82 MB
Progress: 61% - Saving 14.69 MB of 23.82 MB
Progress: 62% - Saving 14.77 MB of 23.82 MB
Progress: 62% - Saving 14.86 MB of 23.82 MB
Progress: 62% - Saving 14.94 MB of 23.82 MB
Progress: 63% - Saving 15.02 MB of 23.82 MB
Progress: 63% - Saving 15.11 MB of 23.82 MB
Progress: 63% - Saving 15.19 MB of 23.82 MB
Progress: 64% - Saving 15.27 MB of 23.82 MB
Progress: 64% - Saving 15.36 MB of 23.82 MB
Progress: 64% - Saving 15.44 MB of 23.82 MB
Progress: 65% - Saving 15.52 MB of 23.82 MB
Progress: 65% - Saving 15.61 MB of 23.82 MB
Progress: 65% - Saving 15.69 MB of 23.82 MB
Progress: 66% - Saving 15.77 MB of 23.82 MB
Progress: 66% - Saving 15.85 MB of 23.82 MB
Progress: 66% - Saving 15.94 MB of 23.82 MB
Progress: 67% - Saving 16.02 MB of 23.82 MB
Progress: 67% - Saving 16.1 MB of 23.82 MB
Progress: 67% - Saving 16.19 MB of 23.82 MB
Progress: 68% - Saving 16.27 MB of 23.82 MB
Progress: 68% - Saving 16.35 MB of 23.82 MB
Progress: 69% - Saving 16.44 MB of 23.82 MB
Progress: 69% - Saving 16.52 MB of 23.82 MB
Progress: 69% - Saving 16.6 MB of 23.82 MB
Progress: 70% - Saving 16.68 MB of 23.82 MB
Progress: 70% - Saving 16.77 MB of 23.82 MB
Progress: 70% - Saving 16.85 MB of 23.82 MB
Progress: 71% - Saving 16.93 MB of 23.82 MB
Progress: 71% - Saving 17.02 MB of 23.82 MB
Progress: 71% - Saving 17.1 MB of 23.82 MB
Progress: 72% - Saving 17.18 MB of 23.82 MB
Progress: 72% - Saving 17.27 MB of 23.82 MB
Progress: 72% - Saving 17.35 MB of 23.82 MB
Progress: 73% - Saving 17.43 MB of 23.82 MB
Progress: 73% - Saving 17.51 MB of 23.82 MB
Progress: 73% - Saving 17.6 MB of 23.82 MB
Progress: 74% - Saving 17.68 MB of 23.82 MB
Progress: 74% - Saving 17.76 MB of 23.82 MB
Progress: 74% - Saving 17.85 MB of 23.82 MB
Progress: 75% - Saving 17.93 MB of 23.82 MB
Progress: 75% - Saving 18.01 MB of 23.82 MB
Progress: 75% - Saving 18.1 MB of 23.82 MB
Progress: 76% - Saving 18.18 MB of 23.82 MB
Progress: 76% - Saving 18.26 MB of 23.82 MB
Progress: 77% - Saving 18.34 MB of 23.82 MB
Progress: 77% - Saving 18.43 MB of 23.82 MB
Progress: 77% - Saving 18.51 MB of 23.82 MB
Progress: 78% - Saving 18.59 MB of 23.82 MB
Progress: 78% - Saving 18.68 MB of 23.82 MB
Progress: 78% - Saving 18.76 MB of 23.82 MB
Progress: 79% - Saving 18.84 MB of 23.82 MB
Progress: 79% - Saving 18.93 MB of 23.82 MB
Progress: 79% - Saving 19.01 MB of 23.82 MB
Progress: 80% - Saving 19.09 MB of 23.82 MB
Progress: 80% - Saving 19.17 MB of 23.82 MB
Progress: 80% - Saving 19.26 MB of 23.82 MB
Progress: 81% - Saving 19.34 MB of 23.82 MB
Progress: 81% - Saving 19.42 MB of 23.82 MB
Progress: 81% - Saving 19.51 MB of 23.82 MB
Progress: 82% - Saving 19.59 MB of 23.82 MB
Progress: 82% - Saving 19.67 MB of 23.82 MB
Progress: 82% - Saving 19.76 MB of 23.82 MB
Progress: 83% - Saving 19.84 MB of 23.82 MB
Progress: 83% - Saving 19.92 MB of 23.82 MB
Progress: 83% - Saving 20 MB of 23.82 MB
Progress: 84% - Saving 20.09 MB of 23.82 MB
Progress: 84% - Saving 20.17 MB of 23.82 MB
Progress: 85% - Saving 20.25 MB of 23.82 MB
Progress: 85% - Saving 20.34 MB of 23.82 MB
Progress: 85% - Saving 20.42 MB of 23.82 MB
Progress: 86% - Saving 20.5 MB of 23.82 MB
Progress: 86% - Saving 20.59 MB of 23.82 MB
Progress: 86% - Saving 20.67 MB of 23.82 MB
Progress: 87% - Saving 20.75 MB of 23.82 MB
Progress: 87% - Saving 20.83 MB of 23.82 MB
Progress: 87% - Saving 20.92 MB of 23.82 MB
Progress: 88% - Saving 21 MB of 23.82 MB
Progress: 88% - Saving 21.08 MB of 23.82 MB
Progress: 88% - Saving 21.17 MB of 23.82 MB
Progress: 89% - Saving 21.25 MB of 23.82 MB
Progress: 89% - Saving 21.33 MB of 23.82 MB
Progress: 89% - Saving 21.42 MB of 23.82 MB
Progress: 90% - Saving 21.5 MB of 23.82 MB
Progress: 90% - Saving 21.58 MB of 23.82 MB
Progress: 90% - Saving 21.66 MB of 23.82 MB
Progress: 91% - Saving 21.75 MB of 23.82 MB
Progress: 91% - Saving 21.83 MB of 23.82 MB
Progress: 92% - Saving 21.91 MB of 23.82 MB
Progress: 92% - Saving 22 MB of 23.82 MB
Progress: 92% - Saving 22.08 MB of 23.82 MB
Progress: 93% - Saving 22.16 MB of 23.82 MB
Progress: 93% - Saving 22.25 MB of 23.82 MB
Progress: 93% - Saving 22.33 MB of 23.82 MB
Progress: 94% - Saving 22.41 MB of 23.82 MB
Progress: 94% - Saving 22.49 MB of 23.82 MB
Progress: 94% - Saving 22.58 MB of 23.82 MB
Progress: 95% - Saving 22.66 MB of 23.82 MB
Progress: 95% - Saving 22.74 MB of 23.82 MB
Progress: 95% - Saving 22.83 MB of 23.82 MB
Progress: 96% - Saving 22.91 MB of 23.82 MB
Progress: 96% - Saving 22.99 MB of 23.82 MB
Progress: 96% - Saving 23.08 MB of 23.82 MB
Progress: 97% - Saving 23.16 MB of 23.82 MB
Progress: 97% - Saving 23.24 MB of 23.82 MB
Progress: 97% - Saving 23.32 MB of 23.82 MB
Progress: 98% - Saving 23.41 MB of 23.82 MB
Progress: 98% - Saving 23.49 MB of 23.82 MB
Progress: 98% - Saving 23.57 MB of 23.82 MB
Progress: 99% - Saving 23.66 MB of 23.82 MB
Progress: 99% - Saving 23.74 MB of 23.82 MB
Progress: 100% - Saving 23.82 MB of 23.82 MB
Progress: 100% - Completed download of C:\Users\IEUser\AppData\Local\Temp\chocolatey\dnspy\5.0.9\dnSpy.zip (23.82 MB).
Download of dnSpy.zip (23.82 MB) completed.
Error - hashes do not match. Actual value was '4571CCF630C408B0AF5E01ABC012C1B9354733C33DC1F5C70903169F0C0F065C'.
ERROR: Checksum for 'C:\Users\IEUser\AppData\Local\Temp\chocolatey\dnspy\5.0.9\dnSpy.zip' did not meet '9930E3B3E460D3082F23ABD7EBFB1C00B6666667F9D7CC03C03EA6B3C6AB404B' for checksum type 'sha256'. Consider passing the actual checksums through with --checksum --checksum64 once you validate the checksums are appropriate. A less secure option is to pass --ignore-checksums if necessary.
The upgrade of dnspy was NOT successful.
Error while running 'C:\ProgramData\chocolatey\lib\dnspy\tools\chocolateyinstall.ps1'.
 See log for details.

Chocolatey upgraded 0/1 packages. 1 packages failed.
 See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).

Failures
 - dnspy (exited -1) - Error while running 'C:\ProgramData\chocolatey\lib\dnspy\tools\chocolateyinstall.ps1'.
 See log for details.

@mikemadden42 The dnspy package is managed by the chocolatey community, and its maintainer is not very responsive. Therefore, the FlareVM project officially uses a private dnspy.flare package. If you are using FlareVM with an older version of dnSpy, please uninstall the dnSpy package, and install the new dnSpy.flare package instead.


Process unexpectedly closed with status 255

Traceback (most recent call last):
  File "/home/voter/agherman-voter/main.py", line 7, in <module>
    with TorBrowserDriver(tbb_dir, tor_cfg=cm.USE_STEM) as driver:
  File "/home/voter/.local/lib/python3.10/site-packages/tbselenium/tbdriver.py", line 103, in __init__
    super(TorBrowserDriver, self).__init__(
  File "/home/voter/.local/lib/python3.10/site-packages/selenium/webdriver/firefox/webdriver.py", line 67, in __init__
    super().__init__(command_executor=executor, options=options)
  File "/home/voter/.local/lib/python3.10/site-packages/selenium/webdriver/remote/webdriver.py", line 208, in __init__
    self.start_session(capabilities)
  File "/home/voter/.local/lib/python3.10/site-packages/selenium/webdriver/remote/webdriver.py", line 292, in start_session
    response = self.execute(Command.NEW_SESSION, caps)["value"]
  File "/home/voter/.local/lib/python3.10/site-packages/selenium/webdriver/remote/webdriver.py", line 347, in execute
    self.error_handler.check_response(response)
  File "/home/voter/.local/lib/python3.10/site-packages/selenium/webdriver/remote/errorhandler.py", line 229, in check_response
    raise exception_class(message, screen, stacktrace)
selenium.common.exceptions.WebDriverException: Message: Process unexpectedly closed with status 255

import tbselenium.common as cm
from tbselenium.tbdriver import TorBrowserDriver
from tbselenium.utils import launch_tbb_tor_with_stem

tbb_dir = "/home/voter/tor-browser/"
tor_process = launch_tbb_tor_with_stem(tbb_path=tbb_dir)
with TorBrowserDriver(tbb_dir, tor_cfg=cm.USE_STEM) as driver:
    driver.load_url("https://check.torproject.org")

tor_process.kill()

Tor /home/voter/tor-browser/
Geckodriver 0.31
PATH set
Nothing running on :9050
The setup instructions are horrible btw. :thumbsup:

The setup instructions are horrible btw. 👍

PRs are welcome, unhelpful comments like these are not.


didSelectRowAtIndexPath not work

If I do simple tap on cell, didSelect/willSelect rowAtIndexPath in UITableViewDelegate not called. Only after long press on cell didSelect/willSelect was called

I got the same issue, didSelect rowAtIndexPath in UITableViewDelegate is not called when tapping on a cell. However I closed simulator and close Xcode also, then open Xcode and run app again, it would work well...

I got the same issue. when i swipe to left and reloadData，then cellContent disappear。then didSelect rowAtIndexPath not work


empty *.d.ts definitions in e.g. rxjs/add/observable/from.d.ts in version 5.0.0-alpha-14

trying to use rxjs with angular2 (which includes 5.0.0-alpha-14 internally) and getting this
import "rxjs/add/observable/form";
(18,8): error TS2656: Exported external package typings file
'/node_modules/rxjs/add/observable/from.d.ts' is not a module. Please contact the package author to update the package definition.

Is this issue https://github.com/ReactiveX/RxJS/issues/1010 ?

yes, closing, thank you


Rename repository to cluster-api-provider-equinix-metal

Packet is now Equinix Metal, so it would be great if we could get the repository renamed

This repo has been renamed.

/close


Version issue

'tertiaryLabel' is only available in iOS 13.0 or newer
Using Fastis 3.1.0
class FastisConfig

Hi, Fastis is also supported from iOS +13.0
If you have any problem with the implementation, attach a code snippet or error


Pass project as a positional argument rather than an option

Current:
osf -p abc12 clone

Proposed:
osf clone abc12

Along the lines of https://github.com/dib-lab/osf-cli/issues/108#issuecomment-328540650 , it would be more ergonomic to mimic the interface of git when sensible.

Sounds good if we automatically "run" osf init as well when clone'ing. The thinking behind the current (tedious) way of specifying the project is that it at least is uniform across all commands. If we can remove the need to explicitly mentioning the project that would be great.


Issue With Some Images

I'm having issues with some images...
when using the simplest of tests it returns the error:
Error: Unable to save image:
Attached is an example photo that does not process.
20160205_195534.zip

Do you have a code sample?

it breaks in my normal/used code on the site so I did a test with your basic implementation code and it breaks there as well and generates that error message.
`include($_SERVER['DOCUMENT_ROOT'].'/js/SimpleImage.php');
try {
$img = new abeautifulsite\SimpleImage($_SERVER['DOCUMENT_ROOT'].'/image.jpg');
$img->auto_orient()->save($_SERVER['DOCUMENT_ROOT'].'/result.jpg');
} catch(Exception $e) {
echo 'Error: ' . $e->getMessage();
}`

This is what I saw using your test image:
Warning: imagecreatefromjpeg(): gd-jpeg, libjpeg: recoverable error: Invalid SOS parameters for sequential JPEG in SimpleImage/src/abeautifulsite/SimpleImage.php on line 1233

Warning: imagecreatefromjpeg(): 'test.jpg' is not a valid JPEG file in SimpleImage/src/abeautifulsite/SimpleImage.php on line 1233

Which led me to discover this setting. After a9fc06b, the image is saved as expected. Thanks for reporting this.

thanks so much! 💃


Bitwise operations show negative signed values for immediates with first bit set

I have a 32-bit MIPS instruction of 30 63 ff 00, which binja disassembles as andi $v1, $v1, -0x100. In theory, this is equivalent to andi $v1, $v1, 0xff00, which would likely be more readable as a bitwise mask.
Would it make more sense to display values for bitwise operations with immediate values as their unsigned version instead? I can't think of many situations where and/or/xor'ing with a negative value is more understandable than the unsigned value.

The display type can now be change by the user. Rather than close I'm going to modify to reflect the real way we will fix this issue.

This has been fixed for a while now.


Create minimal integration test and/or example working with crates.io

This issue will track what needs to be added for a minimal example of the proxy working with crates.io to check a crate and allow or deny it based on a sigstore parameter (ex. a license type, a valid signature) specified by a (dummy) policy. I would like to solicit input on the plans for / implementations of these parts (maybe I missed something that is already working or maybe my conception of some of the goals are completely off!).
As a subset of the larger proxy architecture, it would cover these component interactions:

Implementation is needed (or possibly already present) for:

A dummy policy to specify when to allow a crate to be (downloaded, interacted with, etc.) - by "dummy" I mean as simple as possible and potentially hardcoded temporarily. I assume the "policy" that takes on this role is the kind defined in opa-client and that this differs from the "policy" included in seedwing.toml - is this right? I am trying to figure out what this would look like. Are the license files (here, here) from opa-client the best example? How are these created? Also, maybe the examples I am pointing to already work just fine with some flow that I haven't discovered yet, in which case no need to make a separate dummy policy.

Interaction with sigstore. I see there's currently a submodule for this, which is blank at the moment. However, it looks like sigstore (rekor) interaction is already happening via repositories/crates/api/v1/mod.rs - what differentiates the sigstore submodule from what's going on in the api? What is the purpose of getting this Rekor entry as part of the download()?

A request from the "build pipeline" to kick off this whole flow - how is this meant to take place via something like cargo that doesn't know about the proxy? I had imagined the proxy would be a wrapper for something like cargo, but since the proxy is a server with various endpoints, it looks like there is a different plan.

Thoughts on the above are greatly appreciated. @bobmcwhirter

I am trying to figure out what this would look like. Are the license files (here, here) from opa-client the best example? How are these created?

The wasm module was created by doctrine, and there is a test target if the policies need to be modified. We can copy/move the Makefile into this repository if needed.

So yah, the existing code can be ignored as appropriate. The current sigstore integration was me just verifying that I was able to sign a crate outside of this workflow, and then SHA it and find the sig(s) upon fetch.
I do think the sigstore sig-fetching should probably be on the policy-engine side of things.
With regards to integration with cargo, I think there's two routes:

As a transparent-ish HTTP proxy

[http]
debug = false               # HTTP debugging
proxy = "host:port"         # HTTP proxy in libcurl format

By setting the default (or other) repos to the proxy URL

[registry]
default = "…"        # name of the default registry
token = "…"          # authentication token for crates.io

both via https://doc.rust-lang.org/cargo/reference/config.html and probably set via a .cargo/config.toml either under the CI's $HOME or within the project dir itself.
The method I was aiming for would mean not wrapping or PRing changes to upstream cargo.

How we deal with git crates? No idea!

Thanks for the replies, @bobmcwhirter @danbev . As is usually the case, your answers have germinated more questions.

The current sigstore integration was me just verifying that I was able to sign a crate outside of this workflow, and then SHA it and find the sig(s) upon fetch.

Sounds like a lot of the functionality we need is already there, then, just needing to be moved to the policy engine and then the results used to allow or deny, perhaps under evaluate()?

With regards to integration with cargo, I think there's two routes ...

Thanks for outlining the two possible routes for cargo integration. I need to study the cargo config a bit to familiarize, and then form more questions. Is the in-toto work following one of the two models described? Or does it modify cargo (I see some cargo r commands)? Or is this work completely separate from the seedwing proxy and so it doesn't matter?

How we deal with git crates? No idea!
I see git dependencies mentioned here, is this speaking to that problem or am I conflating two things?

I also have some higher-level questions about the roles of the different repos in play and OPA, and around the policy format itself.

I haven't yet worked with OPA. Are we offloading evaluation of whether a particular crate matches a specified policy for the seedwing-proxy to OPA, or is this meant to be done in the seedwing code (ex. with policyengine.evaluate())? What is the role of OPA? Is there some notion of a non-OPA policy for the seedwing proxy? Why are the policies wasm modules? I think this is the biggest chunk where I'm missing something, so I'm going to be reviewing OPA docs, but any context is helpful.

How does the source-distributed in-toto work relate to the seedwing-proxy? How does cargo-verify.rs relate to a policy evaluation? Are these doing any overlapping or complementary things?

How does the seedwing-policy repo relate to the opa-client (which also deals with policies)? As @danbev mentioned, doctrine actually creates the policies, which are then ... sent to the code in one of these other repos? Something else?

wrt git dependencies, I'm wondering how we can intercept and apply policy. I'm unfamiliar with how cargo actually fetches dependencies from a git URL. Is that something we can proxy? Dunno!
seedwing-policy is my nascent attempt to do something a bit better than OPA. I find Rego and OPA a bit.. tedious and overgeneralized.  It may go nowhere, but if it works, I'd like -proxy to be able to at least alternatively use -policy.
The doctrine repo was intended, kinda sorta, to hold authored policies. The idea being that folks could meld together some centrally-authored policies, along with their local organization exceptions or adaptations.
No reason more than a single person needs to write a policy defining "OSI-approved licenses" etc.  A policy library.

I also wonder if the [patch] section of cargo config can be used, at least for git dependencies.
But are we creating too much busywork for users to integrate? If we can aim for minimally-invasive to a build, that'd be best, I suspect.

If we can aim for minimally-invasive to a build, that'd be best, I suspect.

:+1:

Yah -policy would be a replacement for OPA. And then we'd need a seedwing-policy-client.
And yes, the policy library could contain a policy that says "signatures from<EMAIL_ADDRESS>must exist in rekor"
The input to the policy engine would be (incomplete)

crate name
crate version
sha256 of the crate
origin URL (crates.io, other)

Policy engine then scrambles that up, queries sigstore, queries $whereever-other-data-is-kept, and can decide if the requested artifact is allowed or rejected.

Is the in-toto work following one of the two models described? Or does it modify cargo (I see some cargo r commands)? Or is this work completely separate from the seedwing proxy and so it doesn't matter

This is completely separate and was pursued to figure out how a source distributed Rust project could potentially be signed with in-toto and sigstore, and then how it might be verified using a command line tool or cargo extension. This was done because I was talking/thinking about how things might work but it was more like guessing. Having something that actually works helped iron out things and allowed us to fix some issues around this.

How does cargo-verify.rs relate to a policy evaluation? Are these doing any overlapping or complementary things?

They are currently unrelated, though perhaps if cargo-verify (or some other name) does become something it could utilize the policy work to verify more than just signatures/layouts.

Why are the policies wasm modules?

Sorry about that, I did have a motivation note in a different repo but never copied it over. I've added a note about this now. Another motivation was at the time I was not able to find a Rust implementation of OPA and using kubewarden/policy-evaluator made sense to save time until we know if/what will be used eventually.

Would it make sense to stick this section "Motivation for using tools/projects" in one of the repositories?

Would it make sense to stick this section "Motivation for using tools/projects" in one of the repositories?

Yes, I think this would be great. We should have such a write-up for all of the repos.

Blocking issues:

[ ] #5
[ ] #6
[ ] #7
[ ] #9


The loggingLevel setup in Transformers-CFG will polute the user program

The probelmatic line is here
https://github.com/epfl-dlab/transformers-CFG/blob/651dca0265d159b6207838da5d0012e53fdb2f0d/transformers_cfg/logging_config.py#L18
reproduce
import torch
import logging

if __name__ == "__main__":

    from transformers import AutoModelForCausalLM, AutoTokenizer
    from transformers_cfg.grammar_utils import IncrementalGrammarConstraint
    from transformers_cfg.generation.logits_process import GrammarConstrainedLogitsProcessor

    # logging.basicConfig has already been called in the transformers_cfg library, so this will not work
    # the above function can only be called once in a python session
    # so we should NEVER call logging.basicConfig in a library!
    logging.basicConfig(level=logging.INFO)
    logger = logging.getLogger(__name__)

    # you will not see this message in the console because the logging level is set to WARNING inside the transformers_cfg library
    logger.info("Loading model and tokenizer")

Something which works is below:
import torch
import logging

if __name__ == "__main__":

    logging.basicConfig(level=logging.INFO)

    from transformers import AutoModelForCausalLM, AutoTokenizer
    # the function call inside the transformers_cfg will not work because we have already called logging.basicConfig above
    from transformers_cfg.grammar_utils import IncrementalGrammarConstraint
    from transformers_cfg.generation.logits_process import GrammarConstrainedLogitsProcessor

    logger = logging.getLogger(__name__)

    # you will SEE this log message because the logging level is set to INFO
    logger.info("Loading model and tokenizer")

Reason
import os
import logging

def setup_logging():
    log_level_name = os.getenv(
        "TCFG_LOG_LEVEL", "WARNING"
    ).upper()  # Default to WARNING if not set
    log_levels = {
        "DEBUG": logging.DEBUG,
        "INFO": logging.INFO,
        "WARNING": logging.WARNING,
        "ERROR": logging.ERROR,
        "CRITICAL": logging.CRITICAL,
    }
    log_level = log_levels.get(log_level_name, logging.WARNING)
   # this is BAD, this function configures the root logger of the entire program, so it will overwrite the user's logging level defined in their script when they import the library
    logging.basicConfig(level=log_level)

Solution
import logging

# Create a logger for the library
logger = logging.getLogger('transformers_cfg')
# the level will propagate to loggers with submodule scope
logger.setLevel(logging.WARNING)

solved in #51


climate: Add support for Mitsubishi Electric MLZ-KP series ACs

Mitsubishi's MLZ-KP series are a set of Ductless Minisplit ACs.  The units are capable for cooling, heating and humidity control.
This PR adds initial support for these units by just supporting cooling mode.
Note: It's not clear to be if climate.py works in units of Farenheit or Celcius.  I've assumed Farenheit and it appears to play nice with Home Assistant.

@rdeva31 Out of curiosity, did you use a tool to automate the creation of the JSON or did you manually record each one using the listen remote.learn_command?
I really wanted to use the web tool, but it seems as though it uses an old service that no longer exists


Render client type in details

Changes Unknown when pulling 7ecfd0af03a5aca05ef181ad23b57d6e2ea40397 on render-client-type-in-details into ** on master**.


Cache issue count

Caching the issue count is good to reduce how much we hit the GitHub API, and it also allows us to refactor the code related to caching the GitHub API and reduce the convoluted merge logic.

This preview is missing community tabs, as is the live site. I was hoping it would make things better and reduce cache misses, but apparently if it does, it will be a slow improvement. Still I think it's safe to merge as it should be an overall improvement to how much we hit the GitHub API.


[DataMovement] [Blobs] Move sub StorageResourceOptions to be more condensed.

Library name and version
Azure.Storage.DataMovement.Blobs
Query/Question
https://github.com/Azure/azure-sdk-for-net/pull/32483/files#r1026759999
There's some repeat in having the copy options, upload options and download options, since they all contain the same RequestConditions. There's opportunity here to condense things down.
We might have to ignore some headers from certain options, like for destination download, it doesn't take IfAppendPositionEqual or IfMaxSizeLessThanOrEqual on download.
Same for page blobs and block blobs.
Environment
No response

Also during this work we should ensure that the option bags get applied to all methods which call the respective option bags to make it's requests. (e.g. destination request conditions apply to create, write, etc)


2 Temporary objects for every entity per system!

Have a look at engine/src/ecs/system.h
this function is used per frame for every system that is implemented:
template
FUSE_INLINE auto view() {
std::vector entities;
for(auto& e : _registry->view()) {
entities.push_back(entity(e, _registry));
}
return entities;
}
Just put FUSE_INFO("object created"); next to push_back and you'll discover that there is allocation/ deallocation of every entity just to return it.
It also happens inside _registry->view allocating a list.
This is not a good thing because it defeat the purpose of ECS for cache friendliness and it's really a terrible things to try and scale your project with it.
I don't know how much of an impact this would have. But, it is certainly huge.
Breaking cache flow is a hundred time slower on it's own. We're allocating two object per objects per
There got to be a solution to this.

Well, I made my own ECS.
If it wasn't for your tutorial it would have been much more difficult. :)

Great am happy to be part of your journey!! keep going you have what it takes!


[SPARK-40534][CONNECT][FOLLOWUP] support all join types in python client

What changes were proposed in this pull request?

Following up https://github.com/apache/spark/pull/38157, add all join types support for python. Please note that in the PR we decided to not support CROSS Join now.
Why are the changes needed?

Finish the join type support in Connect.
Does this PR introduce any user-facing change?

No.
How was this patch tested?

UT

R: @zhengruifeng @HyukjinKwon

Can one of the admins verify this patch?

@HyukjinKwon This PR should be ready to merge.

Merged into master


Use local neon in sample project

This is a totally optional change, please discard if that doesn't fit how you work:

Reference local Neon package in the sample to make it editable;
this also enables using the package's tests in Xcode for ⌘U!
Adding these to a test plan, and thus a scheme

Huh, I'm surprised I hadn't already done this! Very into this way of working, it's just convenient.


New translation and minor en fix

Adds initial support for dutch

Minor spelling error in the english translation

Great, thank you :)


ENYO-5874: Bump up clientSize prop to Scrollable

Checklist

[x] I have read and understand the contribution guide

[ ] A CHANGELOG entry is included

[ ] At least one test case is included for this feature or bug fix

[x] Documentation was added or is not needed

[ ] This is an API breaking change

Issue Resolved / Feature Added
ScrollBar accesses the container DOM for calculating thumb size.
Resolution
VirtualList has clientSize to gain performance by reducing DOM access and is the same size as the size which ScrollBar needs for the calculation and it's also used in Scrollable. We can bump up the prop to Scrollable and reduce layout for ScrollBar.
Additional Considerations
From a local perf test (MBP 15", CPU 6x slowdown) done with https://github.com/enactjs/performance-tests/pull/25, I was able to see ~10ms improvement on average.
Enact-DCO-1.0-Signed-off-by: Stephen Choi<EMAIL_ADDRESS>

@viodragon2, @seunghoh - How frequently is the clientSize prop used by applications? Curious how much impact this change will have in the wild.

Only in one panel in one app. I believe this prop was not promoted well enough for app developers to explore.

Okay. I can see the perf benefit of avoiding layout calculations but I'm questioning the value as compared to the DX. Seems like specifying a static value (even when using ri to scale it) is prone to maintenance problems when layouts change (e.g. when we have UX updates or global changes like line-height that adjusts layout) and is contrast to typical flexible web layouts.
More concretely, it this the sort of API we want to promote or do we need to find a way to minimize the impact of style recalc and layout by the scrollbar?

It depends. Main use cases for TV apps normally don't require a flexible layout. So if there's a perf benefit and maybe an extra work(?), would developers choose to opt-in for this option?
Also, other virtualized libraries normally require explicit dimensions set. In the case of react-virtualized, they provide a HOC for flexible layout (i.e. AutoSizer). I don't think one is better than the other API-wise IMO.


Update Set-AzureADUserThumbnailPhoto.md

Typo correction, "witht eh PObjectId" should be "with the ObjectID"

Docs Build status updates of commit 26385ce:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

azureadps-2.0/AzureAD/Set-AzureADUserThumbnailPhoto.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Hi @NoahMillerEXO
Per the read me file:
Please be aware that if you have any updates to automatically generated reference content, you should create an issue and not a PR.  The issue will then be created into a bug and triaged accordingly.  We do this because the reference content must mirror the *dll-help.xml file and subsequent updates to the reference content may overwrite any changes made through the repo.  Capturing it in the source code ensures that this does not occur.  Any PR with changes to automatically generated reference content will be closed.
Automatically generated reference content is any of the content under this Reference node, such as Get-AzureADUser
This only applies to reference content and not conceptual content.  Pull requests for changes to conceptual content are accepted and encouraged.  An example of the conceptual content is the Overview or a scenario such as importing data.
Thank you!
Bill


Add bazel/cc_proto_descriptor_library

In preparation for supporting lite protos, add cc_proto_descriptor_library which can be used to provide
proto descriptor capabilities even with lite protos. Based on previously closed-source library.
Risk Level: Low - Unused
Testing: New unit test
Docs Changes: N/A
Release Notes: N/A
Platform Specific Features: N/A

/assign @abeyad
Ok, looks like this is basically good to to!

Just skimmed but this seems very cool and magical!

Thanks, Matt! The only wrinkle in this seems to be that clang-tidy is complaining. In particular, it's unable to find some files that are being #include'd. The code all builds fine, so clearly that's working. But clang-tidy can't find them. We've seen this a few times in other places in the codebase, I think, like with the logger. I suspect I'll need you to force submit this, unless you have any ideas about how to cajole clang-tidy into being happy?

Sorry no idea. We can force merge.

@RyanTheOptimist this failed clang-tidy before and after landing

https://dev.azure.com/cncf/envoy/_build/results?buildId=143676&view=logs&j=b7634614-24f3-5416-e791-4f3affaaed6c&t=d565ee52-b888-5d80-7fea-dfaed104c390&l=203
https://dev.azure.com/cncf/envoy/_build/results?buildId=143675&view=logs&j=b7634614-24f3-5416-e791-4f3affaaed6c&t=d565ee52-b888-5d80-7fea-dfaed104c390&l=205

the clang-tidy ci is not working optimally, not sure why, but it didnt create the diff just the fail yaml
either way would be good to clean up
cc @wbpcode

@RyanTheOptimist this failed clang-tidy before and after landing

https://dev.azure.com/cncf/envoy/_build/results?buildId=143676&view=logs&j=b7634614-24f3-5416-e791-4f3affaaed6c&t=d565ee52-b888-5d80-7fea-dfaed104c390&l=203
https://dev.azure.com/cncf/envoy/_build/results?buildId=143675&view=logs&j=b7634614-24f3-5416-e791-4f3affaaed6c&t=d565ee52-b888-5d80-7fea-dfaed104c390&l=205

the clang-tidy ci is not working optimally, not sure why, but it didnt create the diff just the fail yaml
either way would be good to clean up
cc @wbpcode

Thanks for noticing this. yeah, clang-tidy was really unhappy with this PR. Confusingly, the "formatting/style" was all fine. But the problem was that clang-tidy was unable to find various files which are #included. We've seen this in a couple of other places in Envoy. I really don't understand how clang is able to find the files when building but clang-tidy can't when tidying. Do you have any insight?
I also wondered if the was some -DENVOY_CLANG_TIDY we could pass in when tidy is running in order to #ifndef out code which tidy has irreconcilable problems with.
Of course actually fixing the issue would be way better.


New Roundtrip Integration

This PR adds the following:

New Roundtrip code in the vis/external sub directory (to eventually be replaced entirely with a pypi package install when sufficiently tested)
A new interface for calling the Hatchet calling context tree: %cct <graphframe or list>
A means to call the Roundtrip singleton object from the hatchet path using from hatchet.vis.external import Roundtrip
A web-pack file which builds out Roundtrip visualization code
Tests for the new CCT interface and Roundtrip (imported from the Roundtrip repo)

This PR changes:

Existing example notebooks using the old RT interface
The content in the vis sub-directory

This PR removes:

Now out-of-date Roundtrip code
Empty files exemplifying the proposed vis directory structure in PR #419

The new roundtrip vis code will be moved to its own repository.


Subtitles show a background black

Have you read the FAQ and checked for duplicate open issues?
Yes
What version of Shaka Player are you using?
Latest
Can you reproduce the issue with our latest release version?
Yes
Can you reproduce the issue with the latest code from main?
Yes
Are you using the demo app or your own custom app?
Demo
If custom app, can you reproduce the issue using our demo app?
What browser and OS are you using?
Brave and Chrome
For embedded devices (smart TVs, etc.), what model and firmware version are you using?
What are the manifest and license server URIs?

Sended to the email
What configuration are you using?  What is the output of player.getConfiguration()?

Default
What did you do?

Start playback
Choose spanish subtitles

What did you expect to happen?
Subtitles should be shown with a tight background black color.
What actually happened?

Subtitles show a big background black color

@adgllorente can you share here the TTML that produces this error? I only need the ttml (if you prefer in raw format here (copy-paste)).


node: neo-cli has a memory leak

I recenty upgraded from version 2.10.0 to 2.12.1. I noticed that this new version of neo-cli slowly fills up my memory until it crashes.

Could you provide the error log?

Sure, I just have to wait for it to happen before I can post it,

Hi @jens-j , plz use v12.2.2 https://github.com/neo-project/neo-node/releases/tag/v2.12.2, it's a stable version.

Hi, could you resolved the problem?

No I never did. Try the newest version. If the problem still exists, only the devs can solve it.

Old, if remains, please re-open


Misconfigured -- Unsupported OS when doing setName(Browser.Safari)

        SauceOptions options = new SauceOptions();
        options.setName(name.getMethodName());
        options.setBrowserName(com.saucelabs.saucebindings.Browser.SAFARI);

That code used in a solution throws the following error:
Misconfigured -- Unsupported OS/browser/version/device combo: OS: 'Windows 10', Browser: 'safari', Version: 'latest', Device: 'unspecified' (WARNING: The server did not provide any stacktrace information)

@nadvolod
What would be the expected outcome here?
I guess there are other unsupported combinations of configuration properties. Should they also be validated?

This issue is mostly solved with #141 but #39 also applies. Both of those apply to all languages.
I'm closing this one and we can track progress in those other two.


added more prefix support, last ditch preview

Instead of checking if the prefix of the url is "https://www.reddit.com/r/", which can lead to some bugs (using www.reddit.com) will still say it's invalid, now we do check if there is a protocol, either http or https, and we replace www. with nothing and reddit.com with old.reddit.com
Also implemented a Preview struct (basically, a last ditch effort to grab the gif / video - as if you tried the url from #1, it would've errored out (unsupported provider)
As for unsupported providers, instead of the default case returning nothing, it now prints an error, and tries the fallback options
Final changes are in GetMediaUrl, as I replace the amp; in the urls with nothing, and instead of using HasSuffix on the .gif, I replaced it with Contains (as the GIF Variant of the fallback url also contains an s query.)

nstead of checking if the prefix of the url is "https://www.reddit.com/r/", which can lead to some bugs (using www.reddit.com) will still say it's invalid, now we do check if there is a protocol, either http or https, and we replace www. with nothing and reddit.com with old.reddit.com

ahh i see, thanks!!
i didn't want to consider other cases cos i just assumed(my mistake) that anyone that's using this tool would copy/share the url directly from reddit

Also implemented a Preview struct (basically, a last ditch effort to grab the gif / video - as if you tried the url from #1, it would've errored out (unsupported provider)

OMG, this is brilliant!
i never would have considered this. gahhh! you're so good. Thanks for making this to be much better <3

Final changes are in GetMediaUrl, as I replace the amp; in the urls with nothing, and instead of using HasSuffix on the .gif, I replaced it with Contains (as the GIF Variant of the fallback url also contains an s query.)

hmm, you made the right call


Creating multiple MQTT clients gives TLS error

Describe the bug
I'm trying to have another MQTT client to the same thing but I got TLS error.
I duplicated the _establishMqttConnection function call with another mqttConnection2  handler,
the second call always fails with TLS error
ERROR: Handshake failed with error code -16

status = _establishMqttConnection( awsIotMqttMode,
NULL,
pNetworkServerInfo,
pNetworkCredentialInfo,
pNetworkInterface,
&mqttConnection );
if( status == EXIT_SUCCESS )
{
IotLogInfo("Sucess 1 \r\n");
status = _establishMqttConnection( awsIotMqttMode,
NULL,
pNetworkServerInfo,
pNetworkCredentialInfo,
pNetworkInterface,
&mqttConnection2 );
if( status == EXIT_SUCCESS )
{
IotLogInfo("Sucess 2 \r\n");
}
else
{
IotLogInfo("Fail 2 \r\n");
}
}
else
{
IotLogInfo("Fail 1 \r\n");
}

Thank you!

Which hardware platform are you running on? TLS handshake requires a significant amount of RAM and there is high chance that you are running out of RAM (the assumption here is that you are running on a platform which does TLS in software).
You can setup the Malloc Failed Hook function to determine if a call to pvPortMalloc is failing: https://www.freertos.org/a00016.html
I want to understand why do you want to create a separate MQTT client and not use the same MQTT client created previously?
Thanks.

Hi,
Thanks for your reply.
I'm working on ESP32.
I'm trying to have a client connected to greengrass core and the second client will be used for the OTA agent through aws IOT core.

Can you check if you are getting malloc failures?
Can you try to make sure to start the second handshake after the first connection is established so that two TLS handshakes are not done in parallel.

Thanks.

Hello,
Thsi in addition to comments from my colleague @aggarg .
There is indeed not enough heap space in your application to support two MQTT connections. -16 is 0x0010 and a search of this reveals the error code MBEDTLS_ERR_MPI_ALLOC_FAILED in mbedTLS. The heap in ESP32 is the space leftover in the dram after all static memory (.bss). You can increase this looking for places where you can reduce static memory in your application and temporarily allocate on the heap.
I saw you had a different issue where you were able to merge get OTA information through your greengrass core: https://github.com/aws/amazon-freertos/issues/1316. So is this issue still a problem for you?

We can close this issue for now.


Clicking outside of the editor does not position the cursor when there is an attribute

Clicking outside of a plain text works fine:

But, when we have an adornment, it does not:


Add: LKE to PAT Scopes

Description
Adds Kube to PAT Scopes
Type of Change

Non breaking change ('update', 'change')

Agree with @johnwcallahan, LKE is entirely invisible unless you're in the beta. Might as well not confuse anyone who sees the scope and thinks that our Kubernetes engine is hiding in a tab somewhere

@johnwcallahan @Jskobos - just flagged the thing behind the thing

@johnwcallahan ready - obviously no good way to sort the list since the scope is lke but the display name is Kubernetes but it works


DOC - Report Zoom audit findings on JupyterLab

Summary

@steff456  has carried out a rather thorough audit on JupyterLab zoom
And a corresponding summary: https://github.com/Quansight-Labs/jupyter-a11y-mgmt/issues/152
Tasks to complete

These needs to be added to the jupyter/accessibility repo under an Audit section

Once PR https://github.com/jupyter/accessibility/pull/111 is merged this issue can be closed


Pipeline UI doesn't open for new environments

Rancher versions: v1.6.10
Steps to Reproduce:

Create a new environment
Add a host
Add the CICD catalog and deploy CICD
Once it's all setup go to Pipelines
Click on Launch Pipeline UI

Results:  Getting a build error page

Can you specify which version of catalog you are using?

Well at the time, I swear there was only 1.  Today there are three versions in
https://github.com/gitlawr/rancher-catalog-1.git.  So I'm going to say 0.0.1-dev

Now, we have updated the deploy guide(https://github.com/rancher/pipeline/blob/docs/docs/Deploy_guide_1.6.md) to the latest one, please follow it to test it again.


http: Cookie Expires in GMT format

Codecov Report

Merging #279 into develop will increase coverage by 0.07%.
The diff coverage is 68.42%.

@@             Coverage Diff             @@
##           develop     #279      +/-   ##
===========================================
+ Coverage    52.69%   52.77%   +0.07%
===========================================
  Files          235      235
  Lines        22480    22490      +10
===========================================
+ Hits         11845    11868      +23
+ Misses        9286     9272      -14
- Partials      1349     1350       +1

Impacted Files
Coverage Δ

bfe_http/cookie.go
73.82% <68.42%> (+3.5%)
:arrow_up:

bfe_spdy/server_write_sched.go
78.46% <0%> (-1.54%)
:arrow_down:

bfe_websocket/server_conn.go
76.51% <0%> (-1.52%)
:arrow_down:

bfe_spdy/server_conn.go
78.53% <0%> (ø)
:arrow_up:

bfe_http2/server.go
71.83% <0%> (+0.32%)
:arrow_up:

bfe_spdy/frame_write.go
50.5% <0%> (+1.01%)
:arrow_up:

bfe_http2/writesched.go
80.91% <0%> (+1.52%)
:arrow_up:

...e_modules/mod_trust_clientip/mod_trust_clientip.go
46.15% <0%> (+3.29%)
:arrow_up:

Continue to review full report at Codecov.

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


[synapse] Convert samples to markdown and first pass of documentation

Converted all synapse samples (both per-existing and those that I wrote) to markdown + cs snippet format
First pass at documenting the 4-5 that are champion scenarios
Found and deleting some duplicate snippet + scenarios I found along the way.
I am not sure about 6 hello worlds in Artifacts, but they are all intro to CRUD on each API. Suggestions welcome here.

I think I got all of the review comments (except on the waiting sample code that I'm going to :crossed_fingers: and hope disappears soon.

Now I think I got them all. Re-running tests on Windows, likely have to upload new json recordings as well.

Ok, I hate to do this, but I'm going to rebase on master and re-PR. The merge was mostly clean, but makes we worried anyway, specially with no one here this week.


Use of verkey

I'm trying to wrap my head around the did:indy security properties.
As I understand it, on initial write, the namespace component needs to
be derived from the verkey, so for instance, we might have:
verkey = 12345...ab
did = did:indy:sovrin:12345...
On write, I am required to sign the transaction. The text is somewhat
unclear about what this means, but I assume that the transaction is an
Indy concept and so the signature doesn't get carried around.  And the
ledger is required to verify the signature, so it should be
consistent.
However, if I update the entry, as in 10.2, I can update the verkey,
which requires a signature by both the old and new verkeys.
The NYM transaction requires that the transaction to be written is
signed by the DID controller using the existing verkey and, if a
new verkey is being provided, the new verkey. The ledger MUST
verify the signature(s). If the signature(s) cannot be validated,
the transaction MUST be rejected and an error returned to the
client.
But at this point, the id will no longer match the verkey unless
I get fantastically lucky (or unlucky, I guess). Am I right so far?
This seems consistent with the fact that that on reading you don't
seem to be required to verify a signature or check that the verkey
matches the namespace component. I see that step 5 requires verifying
the state proof but if I understand correctly, that just checks the
ledger itself, not a signature chain from the original verkey.
Is this correct?

The purpose of the DID is to have a stable identifier with a related public key that can be rotated.
The idea that we are trying to get across, but seems not to be clear is this:

When I create a DID, it's identifier is derived from the initial verkey (as you indicate). So if verkey is VK, then DID=F(VK), and anyone can confirm that.
When you want to rotate the key (change the verkey), the transaction is signed by the old and new private keys, and those signatures are verified. This creates a new ledger entry with the same DID as the initial entry, but a new verkey.

When you come across a key where the DID <> F(VK), then you can look at previous NYM ledger entries for that DID to trace back such that at some point the DID = F(VK) (the initial DID), and based on the ledger rules, know that all updates to that NYM were signed by a party that had access to the old and new private keys.
If the current private key is compromised by a malicious actor, control of the DID can be taken over by that entity. Responsibility for that is on the controller of the DID.
Hopefully that answers your question.
Going a bit further:
We realize that this is not as secure an approach as KERI uses, where an identifier always has both a current and next VerKey stored with the identifier, and a rotation can ONLY be done to the "next verkey", via a signed transaction with the related private key.   The benefit of that approach is that if the current private key of the controller is compromised, control over the identifier can be retrieved by submitting a transaction signed by the private key for the "next" verkey. The practice behind this is the idea that the controller keeps the "current" private key accessible so it can be used, and keeps the "next" private key offline so that the two can't be compromised together.  Of course, if they both are compromised at the same time, you are, as they say, hooped.

When you come across a key where the DID <> F(VK), then you can look at previous NYM ledger entries for that DID to trace back such that at some point the DID = F(VK) (the initial DID), and based on the ledger rules, know that all updates to that NYM were signed by a party that had access to the old and new private keys.

But this is not directly verifiable, correct? I.e., I am just trusting the ledger to enforce those rules. And in fact, I don't know that the creator of the did ever had the private key because only the ledger verified it.
As I read VerKey and KERI, the relying party can actually verify the key rotation but not here. Is that correct?

That should be possible.  I was looking at indyscan.io as I was writing the previous note and expecting to be able to see the signatures, but didn't, so AFAIK today, it is not verifiable. You are right, the sequence of DIDs should be verifiable and I'll add a note to the spec. to see if the implementation can support that.

OK -- did some more checking.  The signature is available from the ledger and so can be verified -- see this: https://indyscan.io/tx/SOVRIN_MAINNET/domain/78559, scrolling down to the "Original Ledger Data" section.

Great. Should the spec require that you check it and describe how to do so?
On Sat, Dec 11, 2021 at 10:57 AM Stephen Curran @.***>
wrote:

OK -- did some more checking. The signature is available from the ledger
and so can be verified -- see this:
https://indyscan.io/tx/SOVRIN_MAINNET/domain/78559, scrolling down to the
"Original Ledger Data" section.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hyperledger/indy-did-method/issues/23#issuecomment-991748813,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAIPLIONPFZAX7B5EJQOVHLUQONI7ANCNFSM5JZ5IKYQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

It should definitely describe how to do it, and the ledger should have functionality to make it easy.
A MUST (in the context of the specification) for a client doing the verification is probably not viable -- I don't think the spec can force someone to do something that they may not feel is needed.  But we definitely want to make it easy.

Well, the spec can't force someone to do something (there are no protocol police), but it's pretty common for security protocol specifications to require behavior that is necessary for security. For instance, here are some MUSTs from QUIC:
  A receiver MUST close the connection with an error of type
   FLOW_CONTROL_ERROR if the sender violates the advertised connection
   or stream data limits; see Section 11 for details on error handling.

   The values provided by a peer for these transport parameters MUST
   match the values that an endpoint used in the Destination and Source
   Connection ID fields of Initial packets that it sent (and received,
   for servers).  Endpoints MUST validate that received transport
   parameters match received connection ID values.

At the bare minimum the Security Considerations should make clear what the implications of failure to do so are.

Agreed.  I'm not saying we shouldn't tell people to do it. Just questioning if a MUST is permitted for an operation done by a client.  But if there is a spec. convention on that -- happy to do it.  Definitely want it in the security considerations.
I think the most important thing at this point is in the updates to Indy Node to do this, we had a way to make it easy to collect all the signatures to enable the verification. For example, we could add to the transaction recorded on the ledger the sequence number of the previous NYM, so that the client can easily "walk the chain".

I think whether it's permitted is probably dependent on the SDO. It would
be permitted (and common) at IETF and W3C.
On Sat, Dec 11, 2021 at 11:52 AM Stephen Curran @.***>
wrote:

Agreed. I'm not saying we shouldn't tell people to do it. Just questioning
if a MUST is permitted for an operation done by a client. But if there is a
spec. convention on that -- happy to do it. Definitely want it in the
security considerations.
I think the most important thing at this point is in the updates to Indy
Node to do this, we had a way to make it easy to collect all the signatures
to enable the verification. For example, we could add to the transaction
recorded on the ledger the sequence number of the previous NYM, so that the
client can easily "walk the chain".
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hyperledger/indy-did-method/issues/23#issuecomment-991765100,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAIPLIJ44GKWJEFXDAT2PYLUQOTYJANCNFSM5JZ5IKYQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

We need to sort out the question of "do we need the transaction signed by the old and new key?". Should we remove that?  If so, we need a PR - nudge, nudge.
AFAIK with KERI, there an identifier is created with two public keys, the current one and the "pre-rotated" one such that the DID controller can restore control of their DID should their current private key be compromised. The assumes that the "pre-rotated" private key cannot be compromised (or at least, it is very, very unlikely because of how it is managed).
In the "Future Considerations" section, we talk about multi-sig NYMs, but that's not a now thing -- nor is the KERI extra "pre-rotated" verkey.

My argument is: we don't gain anything by requiring an additional signature with the new key, so we shouldn't change the current implementation

Sounds good.  I'll do a PR for that.

We need to address that the client SHOULD walk the trail of NYMs to verify self-certification. That goes back to the question of whether there is a way to query the sequence of NYM update transaction via a series of ledger calls.  AFAIK, there is not today and it's not clear it could be easily added.  Of course, it could be checked via a download of the transactions, such as with indyscan.io.


Cannot automatically grey out unused variables, functions and imports

Environment data

VS Code version: 1.46.1
Extension version (available under the Extensions sidebar): 2020.6.90262
OS and version: Ubuntu 18.04.3 LTS
Python version (& distribution if applicable, e.g. Anaconda): 3.6.9
Type of virtual environment used (N/A | venv | virtualenv | conda | ...): N/A
Relevant/affected Python packages and their versions: N/A
Relevant/affected Python-related VS Code extensions and their versions: docker(1.3.1), docker-compose(0.3.5), Remote-Containers(0.122.1)
Value of the python.languageServer setting: XXX

Expected behaviour
Automatically grey out unused variables, functions, and imports
Actual behaviour
Cannot grey out unused variables, functions, and imports
Steps to reproduce:
[NOTE: Self-contained, minimal reproducing code samples are extremely helpful and will expedite addressing your issue]
import os, sys
print('cannot grey out the unused imports')

Logs

Output for Python in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Python)

XXX

Output from Console under the Developer Tools panel (toggle Developer Tools on under Help; turn on source maps to make any tracebacks be useful by running Enable source map support for extension debugging)

XXXX

Please try out the new language server pylance: https://devblogs.microsoft.com/python/announcing-pylance-fast-feature-rich-language-support-for-python-in-visual-studio-code/
See if that helps with the issue.

problem solved using pylance


Update vulnerable deps

Signed-off-by: Miroslav Kovar<EMAIL_ADDRESS>

Codecov Report

Merging #260 (80c1402) into master (e72d3d0) will decrease coverage by 5.76%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #260      +/-   ##
==========================================
- Coverage   57.65%   51.88%   -5.77%
==========================================
  Files         149      148       -1
  Lines       19800    18871     -929
  Branches     4451     4314     -137
==========================================
- Hits        11415     9791    -1624
- Misses       5053     6033     +980
+ Partials     3332     3047     -285

Flag
Coverage Δ

integration
?

unittests
51.88% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

libvcx/src/libindy/utils/anoncreds.rs
21.49% <0.00%> (-59.16%)
:arrow_down:

libvcx/src/libindy/utils/pool.rs
17.39% <0.00%> (-58.66%)
:arrow_down:

libvcx/src/utils/plugins.rs
0.00% <0.00%> (-42.86%)
:arrow_down:

libvcx/src/libindy/utils/ledger.rs
11.74% <0.00%> (-39.24%)
:arrow_down:

libvcx/src/aries/mod.rs
1.04% <0.00%> (-30.77%)
:arrow_down:

libvcx/src/utils/random.rs
75.00% <0.00%> (-25.00%)
:arrow_down:

libvcx/src/utils/devsetup.rs
26.70% <0.00%> (-21.53%)
:arrow_down:

libvcx/src/libindy/utils/payments.rs
42.98% <0.00%> (-21.15%)
:arrow_down:

libvcx/src/libindy/proofs/verifier/verifier.rs
70.37% <0.00%> (-18.06%)
:arrow_down:

...aries/handlers/proof_presentation/prover/prover.rs
60.63% <0.00%> (-16.99%)
:arrow_down:

... and 27 more

Continue to review full report at Codecov.

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

Codecov Report

Merging #260 (80c1402) into master (e72d3d0) will decrease coverage by 5.76%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #260      +/-   ##
==========================================
- Coverage   57.65%   51.88%   -5.77%
==========================================
  Files         149      148       -1
  Lines       19800    18871     -929
  Branches     4451     4314     -137
==========================================
- Hits        11415     9791    -1624
- Misses       5053     6033     +980
+ Partials     3332     3047     -285

Flag
Coverage Δ

integration
?

unittests
51.88% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

libvcx/src/libindy/utils/anoncreds.rs
21.49% <0.00%> (-59.16%)
:arrow_down:

libvcx/src/libindy/utils/pool.rs
17.39% <0.00%> (-58.66%)
:arrow_down:

libvcx/src/utils/plugins.rs
0.00% <0.00%> (-42.86%)
:arrow_down:

libvcx/src/libindy/utils/ledger.rs
11.74% <0.00%> (-39.24%)
:arrow_down:

libvcx/src/aries/mod.rs
1.04% <0.00%> (-30.77%)
:arrow_down:

libvcx/src/utils/random.rs
75.00% <0.00%> (-25.00%)
:arrow_down:

libvcx/src/utils/devsetup.rs
26.70% <0.00%> (-21.53%)
:arrow_down:

libvcx/src/libindy/utils/payments.rs
42.98% <0.00%> (-21.15%)
:arrow_down:

libvcx/src/libindy/proofs/verifier/verifier.rs
70.37% <0.00%> (-18.06%)
:arrow_down:

...aries/handlers/proof_presentation/prover/prover.rs
60.63% <0.00%> (-16.99%)
:arrow_down:

... and 27 more

Continue to review full report at Codecov.

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

Codecov Report

Merging #260 (80c1402) into master (de337d0) will increase coverage by 7.75%.
The diff coverage is n/a.

:exclamation: Current head 80c1402 differs from pull request most recent head 87d5259. Consider uploading reports for the commit 87d5259 to get more accurate results

@@            Coverage Diff             @@
##           master     #260      +/-   ##
==========================================
+ Coverage   49.89%   57.65%   +7.75%
==========================================
  Files         149      149
  Lines       19993    19800     -193
  Branches     6302     4451    -1851
==========================================
+ Hits         9975    11415    +1440
+ Misses       5117     5053      -64
+ Partials     4901     3332    -1569

Flag
Coverage Δ

integration
26.42% <ø> (+3.76%)
:arrow_up:

unittests
51.88% <ø> (+6.20%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

.../aries/handlers/issuance/holder/states/finished.rs
51.85% <0.00%> (-2.54%)
:arrow_down:

...es/handlers/issuance/holder/states/request_sent.rs
73.68% <0.00%> (-1.32%)
:arrow_down:

libvcx/src/lib.rs
0.00% <0.00%> (ø)

...dlers/proof_presentation/prover/states/finished.rs
63.63% <0.00%> (ø)

libvcx/src/error/mod.rs
34.56% <0.00%> (+0.26%)
:arrow_up:

agency_client/src/error.rs
18.18% <0.00%> (+0.36%)
:arrow_up:

libvcx/build.rs
12.87% <0.00%> (+0.99%)
:arrow_up:

libvcx/src/aries/handlers/connection/connection.rs
53.72% <0.00%> (+1.17%)
:arrow_up:

libvcx/src/libindy/utils/callback_u32.rs
59.03% <0.00%> (+1.20%)
:arrow_up:

libvcx/src/libindy/utils/error_codes.rs
59.42% <0.00%> (+1.44%)
:arrow_up:

... and 84 more

Continue to review full report at Codecov.

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


Import fixes for wink and heatmiser

@andylockran, @w1ll1am23
Please check if the platforms still work. Had to fix this as it caused issues.


How to set more  gRPC-JSON transcoder in envoy.yaml

In my project,We want to one port proxy two gRPC services. So I create two grpc_json_transcoder in http_filter. But when I call
the "https://<IP_ADDRESS>:8843/book.BookStore/GetBooksByAuthor?author=zzl",it responsed 404. Here is my envoy.yaml file.
admin:
  access_log_path: /tmp/admin_access_9902.log
  address:
    socket_address: { address: <IP_ADDRESS>, port_value: 9902 }

static_resources:
  listeners:
  - name: listener1
    address:
      socket_address: { address: <IP_ADDRESS>, port_value: 5856 }
    filter_chains:
    - filters:
      - name: envoy.http_connection_manager
        config:
          codec_type: auto
          stat_prefix: ingress_http
          route_config:
            virtual_hosts:
            - name: local_service
              domains:
              - ["*"]
              routes:
              - match: { prefix: "/" }
                route: { cluster: mvc, timeout: { seconds: 60 } }
          http_filters:
          - name: envoy.router
            config: {}

  - name: listener2
    address:
      socket_address: { address: <IP_ADDRESS>, port_value: 8843 }
    filter_chains:
    - filters:
      - name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          stat_prefix: grpc_json
          codec_type: AUTO
          route_config:
            name: local_route
            virtual_hosts:
            - name: local_service
              domains: ["*"]
              routes:
              - match: { prefix: "/greet.Greeter" }
                route: { cluster: grpc, timeout: { seconds: 60 } }
              - match: { prefix: "/" }
                route: { cluster: mvc_https, timeout: { seconds: 60 } }
              - match: { prefix: "/book.BookStore" }
                route: { cluster: grpc_book, timeout: { seconds: 60 } }
          http_filters:
          - name: envoy.filters.http.grpc_json_transcoder
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.grpc_json_transcoder.v3.GrpcJsonTranscoder
              proto_descriptor: "/etc/envoy/greet.pb"
              services: ["greet.Greeter"]
              print_options:
                add_whitespace: true
                always_print_primitive_fields: true
                always_print_enums_as_ints: false
                preserve_proto_field_names: false
              auto_mapping: true

          - name: envoy.filters.http.grpc_json_transcoder
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.grpc_json_transcoder.v3.GrpcJsonTranscoder
              proto_descriptor: "/etc/envoy/book.pb"
              services: ["book.BookStore"]
              print_options:
                add_whitespace: true
                always_print_primitive_fields: true
                always_print_enums_as_ints: false
                preserve_proto_field_names: false
              auto_mapping: true
          - name: envoy.filters.http.router
      tls_context:
        common_tls_context:
          tls_certificates:
            - certificate_chain:
                filename: "/etc/envoy/certs/server_103.crt"
              private_key:
                filename: "/etc/envoy/certs/server_103.key"

  clusters:
  - name: grpc
    connect_timeout: 1.25s
    type: logical_dns
    lb_policy: round_robin
    dns_lookup_family: V4_ONLY
    typed_extension_protocol_options:
      envoy.extensions.upstreams.http.v3.HttpProtocolOptions:
        "@type": type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions
        explicit_http_config:
          http2_protocol_options: {}
    upstream_connection_options:
      tcp_keepalive:
        keepalive_time: 300
    load_assignment:
      cluster_name: grpc
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: <IP_ADDRESS>
                port_value: 50053

  - name: mvc
    connect_timeout: 1.25s
    type: logical_dns
    lb_policy: round_robin
    dns_lookup_family: V4_ONLY
    upstream_connection_options:
      tcp_keepalive:
        keepalive_time: 300
    load_assignment:
      cluster_name: mvc
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: <IP_ADDRESS>
                port_value: 50054

  - name: mvc_https
    connect_timeout: 1.25s
    type: logical_dns
    lb_policy: round_robin
    dns_lookup_family: V4_ONLY
    hosts:
    - socket_address:
       address: <IP_ADDRESS>
       port_value: 50055
    transport_socket:
      name: envoy.transport_sockets.tls
      typed_config:
        "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext

  - name: grpc_book
    connect_timeout: 1.25s
    type: logical_dns
    lb_policy: round_robin
    dns_lookup_family: V4_ONLY
    typed_extension_protocol_options:
      envoy.extensions.upstreams.http.v3.HttpProtocolOptions:
        "@type": type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions
        explicit_http_config:
          http2_protocol_options: {}
    upstream_connection_options:
      tcp_keepalive:
        keepalive_time: 300
    load_assignment:
      cluster_name: grpc_book
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: <IP_ADDRESS>
                port_value: 50057

Here is my book.BookStore proto file:
syntax = "proto3";

option csharp_namespace = "GrpcApp";

package book;

// The greeting service definition.
service BookStore {
  // Sends a greeting
  rpc GetBooksByAuthor (BookInputDto) returns (BooksOutputDto);
  rpc GetList (EmptyRequest) returns (BooksOutputDto);
  rpc AddBook (BookInfoDto) returns (OperResult);
}

// The request message containing the user's name.
message BookInputDto {
  string author = 1;
}

message EmptyRequest{

}

message OperResult{
	string message=1;
	int32 code=2;
}

// The response message containing the greetings.
message BookInfoDto {
  string name = 1;
  string author = 2;
  double price = 3;
  bool enabled = 4;
  string ISBN= 5;
}

message BooksOutputDto{
	string message=1;
	repeated BookInfoDto bookList=2;
}

Is anyone can help me? Thank you very much!!!

Did you use POST in your HTTP call?
Instead of using two grpc_trasncoder filter,  if you can combine your two services into one descriptor file and services is a repeated field what you can specify both services.  In this way, you only need to use one filter.

Did you use POST in your HTTP call?
Instead of using two grpc_trasncoder filter,  if you can combine your two services into one descriptor file and services is a repeated field what you can specify both services.  In this way, you only need to use one filter.

Did you use POST in your HTTP call?
Instead of using two grpc_trasncoder filters, if you can combine your two services into one descriptor file and specify them in services field, you can just use one filter.

how to combine multiple protos into one descriptor file?

@hamza-maqsood with protoc you can do something similar to:
protoc --descriptor_set_out=combined.pb *.proto

Or, using buf build https://docs.buf.build/tour/configure-and-build#build-the-api (after configuring your project) with .bin as the output:
buf build . -o combined.pb

Note: combined.pb is an arbitrary name.


Fix boost-build for VS2019 (vc142)

This will fix multiple boost issues, like #5807, #5302, #6021 .

@ncihnegn @ras0219-msft If you experienced the same as me (or is it I) [see below], I'll describe a work-around (just to be able to continue programming).
I've got VS17 and VS19 installed, side-by-side. Trying to [do a vcpkg] update (glew in this case, but that's irrelevant), vcpkg wacks the current glew install out of existence and then carries on its merry way [why not rename and delete after a successful build and then delete [the old stuff] or rename it back to how it was, depending on the result of the build, is beyond me ( @ras0219-msft )]. But there's a snag, even though I have cmake 3.14.1 installed vcpkg [why not prefer the installed version of cmake iff it's newer than the VS included ones] insists on using cmake 3.12.4 in combination with VS19. This doesn't work, because VS19 is not supported [by that version of cmake], so now your f'ed.
A work-around (just to be able to get a compiled library, so you can keep on building/programming) is to just rename (temporarily)  C:\Program Files (x86)\Microsoft Visual Studio\2019 to let's say C:\Program Files (x86)\Microsoft Visual Studio\2019_ and do the build of said libraries (now it will work again). Then obviously just rename it [that folder] back to its original name.

Thanks, @degski, but I uninstalled VS 2017.
My workaround is fixing boost-build by merging some upstream patches.

Thanks, @degski, but I uninstalled VS 2017.
My workaround is fixing boost-build by merging some upstream patches.

Boost-1.70 will be out soon, I'll probably uninstall VS17 as well, but for the moment the whole thing simply has bugs and incomplete support for Clang/MKL/TBB etc ...  I'll wait for those to catch-up...

I think boost 1.70 is out

https://github.com/boostorg/boost/releases/tag/boost-1.70.0

As a temporary fix modify boost-build package to use 1.70. That should allow building all other boost 1.69 packages using msvc 2019, at least it allows to build all packages i use.
VCPKG_ROOT\ports\boost-build\portfile.cmake:
vcpkg_from_github(
    OUT_SOURCE_PATH SOURCE_PATH
    REPO boostorg/build
    REF boost-1.70.0
    SHA512 be4e410a9656313519e089977a24da8f633db2182985f5d60e07e489f9eac8c887e8cab7e3cbd13f2b747bc3d9dab2899f174be1eaac73cfd7895015fb6b9b58
    HEAD_REF master
)

...
vcpkg_download_distfile(BOOSTCPP_ARCHIVE
    URLS "https://raw.githubusercontent.com/boostorg/boost/boost-1.70.0/boostcpp.jam"
    FILENAME "boost-1.70.0-boostcpp.jam"
    SHA512 7fac16c1f082821dd52cae39601f60bbdbd5ce043fbd19699da54c74fc5df1ed2ad6d3cefd3ae9a0a7697a2c34737f0c9e2b4bd3590c1f45364254875289cd17
)

Will be closed by #6141 .

Additionally, if you want to pin a triplet to a specific compiler version, you can use the VCPKG_PLATFORM_TOOLSET[1] triplet option.
[1] https://github.com/Microsoft/vcpkg/blob/745a0aea597771a580d0b0f4886ea1e3a94dbca6/docs/users/triplets.md#vcpkg_platform_toolset

Hi everyone here, thanks for posting this issue and focusing on this issue.
Boost has been updated to 1.71.0 and it can support for VS2019 now.
Please update vcpkg and try to use them.
Thanks.


Jsdoc Not Marking Properties with Dash in Symbol Name

TS and JS Grammar Extension version:  0.0.18 / latest
From https://github.com/Microsoft/vscode/issues/21592
Code
/**
 * @typedef Product
 * @property {string} title
 * @property {boolean} high-top
 */

/**
 * @type {Product}
 */
const product = null

Bug
high-top is not properly marked. It is scoped as:

other.description.jsdoc
other.meta.jsdoc
comment.block.documentation.js
source.js

while title is scoped as

variable.other.jsdoc
other.meta.jsdoc
comment.block.documentation.js
source.js

Please open the bug in atom/language-javascript as we use their code to colorize jsdoc. We will pick it once it is available
Thanks


Scenery event improvements

It would be nice to combine the event types (input or otherwise) into the same pattern for listening.
Right now, input events require the pattern:
node.addInputListener( { up: ..., down: ... } );

and other events use:
node.on( 'bounds', ... );

Why not allow node.on( 'up, ... ), etc.? How do we combine event listening into one single interface?

Related question: how/why did we settle on bounds rather than boundsChanged for that listener?

9/8/15 dev meeting, consensus design:
//—————————————————————————
// Rename current on/off API to addListener/removeListener,
// creates fewer objects, important for scenery internals

var callback =  function(…) { … } ;
node.addListener( ‘bounds’, callback );
node.addStaticListener( ‘bounds’, callback );
node.removeListener( ‘bounds’, callback );
node.removeStaticListener( ‘bounds’, callback );

//—————————————————————————
// Unify Node.addInputListener and Node.addEventListener
// with overloaded forms of addListener/removeListener.

// object literal, map fields to callbacks
var listener =  {
   bounds: function(...) {...},
   up: function(...) {...},
   down: function(...) {...}
};

node.addListener(  {
   bounds: ...,
   up: …,
   down: …
} );
node.addListener( new SimpleDragHandler( {
  …
} );
node.addStaticListener( {
  …
} );

// Remove listener
node.removeListener( listener );
node.removeStaticListener( listener );

Today we discussed one kind of axon events, the ones emitted from trigger functions in Events.js.  However, there is a (currently orthogonal) pattern for sending events from axon--events that come from property changes.  There is a completely different interface/implementation for listening for Property instance changes.
At today's meeting when @jonathanolson was enumerating the different kind of Node events, he mentioned some like bounds and visible.  In a normal simulation application, these would not be trigger('bounds',...) and trigger('visible',...) but rather messages sent from boundsProperty and visibleProperty instances.
Can these be unified?  Should some scenery events come from property change notifications?  Etc.

9/10/15 dev meeting notes:
• Proposal to change behavior of 'on' and 'onStatic'. Have 'on' operate on actual listener list (not a copy), and 'onVolatile' operate on a copy.  Set a flag in during notification that indicates that functions that modify the list (e.g. addListener, removeListener) will become unsafe, and throw and Error if one of those functions is called.  Tracking this in https://github.com/phetsims/axon/issues/69.
• To help identify an ideal API... Experiment in scenery using axon.Property to see how it would work, what the performance costs are, what changes to axon would be required, etc. Tracking in https://github.com/phetsims/scenery/issues/463
• This issue started with how to add accessibility, but has expanded. It will require breaking changes to scenery (may be able to maintain backward compatibility). It may speed up parts of axon. It's a good longterm thing that will lower future scenery development costs. What is the priority of this issue? @ariel-phet: Let's reevaluate this issue after we're well into S2015R milestone.

See https://github.com/phetsims/axon/issues/80 for performance testing for emitter.


Note: Works great on Linux with PS4 controller over bluetooth (Steam drivers)

Hi,
Just a note saying that using the PS4 controller drivers from steam, this works great on Linux with PS4 controllers over bluetooth too :) Perhaps the README could be updated to note this?

Hey dude, could you give an explanation for how you do this? I googled "download linux steam ds4 drivers" and get nothing.

I think it just means install Steam and support will be added automatically. You don't download drivers separately, it comes packaged with Steam.


pull request for e2e test at 12/16/2016 08:56:17

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


vNext task: add logging to the ActiveProfile property

Overview
As part of the discussion of #3143, the redundancy of multiple methods logging in response to a null ActiveProfile was noted. This change will move the log message into the property getter and save on developer typing :)
Requirements

Add log message to the ActiveProfile getter
Remove custom log messages related to a null ActiveProfile from all methods.

Acceptance Criteria

[ ] Log messages are received as appropriate
[ ] Reduction in code

Why not just address this in the PR?
Those lines were added there, doesn't make sense to push it off until later when it can be addressed now.

This is more for tracking the change and the rationale. It is being worked on as I type :)

This is looking less viable (in that we would be unable to filter these messages using the logging level) as the logging level is on the active profile - adding a filterable log message causes a stack overflow

I think logging it as critical in this case makes sense.

The main service locator needs to have an active profile to run.
Or just log it as an error.

I think logging it as critical in this case makes sense.

The issue is that it takes that message out of the control of the developer...  However, it would be desirable to ultimately solve the stack overflow issue.


Error installing package.

I am trying to install apt-vim to install https://github.com/ctrlpvim/ctrlp.vim plugin.
I executed:
apt-vim install -y https://github.com/ctrlpvim/ctrlp.vim and I get the following error:
Skipping installed package To re-install run:
apt-vim update https://github.com/ctrlpvim/ctrlp.vim
Each package must have a non-blank name.
And when I try to run:
apt-vim update https://github.com/ctrlpvim/ctrlp.vim
I get the following error:
Package not installed: https://github.com/ctrlpvim/ctrlp.vim
Would you like to install it? [y|N]:  y
Skipping installed package To re-install run:
apt-vim update https://github.com/ctrlpvim/ctrlp.vim
Do you wish to continue anyways? [y|N]:  y
Enter a name for package https://github.com/ctrlpvim/ctrlp.vim ( for automatic naming):
I pressed enter for automatic naming. And I again get the following error:
Each package must have a non-blank name.
I am using ubuntu 16.04 32 bit. Shell is zsh with oh-my-zsh.
apt-vim was acting normal few days ago when I installed nerdtree before.

Thanks for reporting this bug.  Can you confirm for me whether or not a ctrlp directory exists at ~/.vimpkg/bundle/ctrlp?
I want to see if you're possibly seeing the same bug that I did.  I'm working on a fix for a bug that I encountered myself, wherein my internet cut out while cloning a dependency.  The net result was that the installation recipe was not saved, but the directory existed, causing confusion about the real state of the plugin.

The more concerning part really is the non-blank name error. I'll dig into that

@egalpin I can see the ctrlp.vim directory and amazing its working now :) I didn't even knew when it was installed.

If you would like to reconcile the state of ctrlp within apt-vim, you can
delete (or move) that ctrlp directory and attempt to reinstall it via
apt-vim.
On Wed, Sep 28, 2016, 12:07 PM Bishisht Bhatta<EMAIL_ADDRESS>wrote:

@egalpin https://github.com/egalpin I can see the ctrlp.vim directory
and amazing its working now :) I didn't even knew when it was installed.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/egalpin/apt-vim/issues/44#issuecomment-250214648, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AHO0HHZ0MeTm66bDRY1CVuAB_gvXM2S_ks5qupDTgaJpZM4KI1eN
.

i try to initialize runnning the apt-vim but got this error:
./apt-vim init
File "./apt-vim", line 97
return {k.replace('_', '-'): v for k,v in list(self.dict.items())}
^
SyntaxError: invalid syntax

@quirinobytes please be sure to update/checkout the latest version of apt-vim.  After trying that, let me know if you have any problems, ideally by opening a new issue :-)


Revert "Revert "Skip tester owned nodes when considering best moves""

Reverts vespa-engine/vespa#11353
@hmusum please merge once I remove the extraneous ).

@bratseth merge og close.

Goddamnit so many conflicts :-(


Documentation about the content of sequencestart and sequencestop tags

Anyone can tell me what i should put in the tags sequencestart and sequencestop? I can not find the relevent pointer of information about it in this solution.
Thanks in advanced

I have been searching for the same information. I would like to setup the proper order in which VMs shutdown and start-up but can't find any information. right not I'm having to create multiple schedules to make this work as I want. However, it seems the logic is there but can't figure out how to may the sequence work.