Copy skillmap headers over for cloud users

fixes https://github.com/microsoft/pxt-arcade/issues/3898
The issue was multilayered 🗻 --
🌸 First, this was only happening for completely new users who have had not visited skillmap before, which is why I could repro it by deleting the account, but not Eric by resetting progress in the skillmap.
🌸 Second, there was an issue where in cloudSyncCheckAsync, when we were figuring out what project headers we wanted to upload, it was always an empty array.
https://github.com/microsoft/pxt/blob/290c02b2143b3dc9cd3f27762d37e61a6654be09/skillmap/src/App.tsx#L224-L231
This was an empty array because there was a race(?) condition where we were writing the local user to the cloud user in onStoreChange
https://github.com/microsoft/pxt/blob/290c02b2143b3dc9cd3f27762d37e61a6654be09/skillmap/src/App.tsx#L391-L399
So we weren't uploading a duplicated copy of the header because there was no duplicate.
🌸 Third, when the user hadn't visited skillmaps before, their user preferences just...didn't have an entry for their skillmap progress. But we were patching their progress with local progress when fetching the user state. We don't want to do the patching here, we'll do the patching in cloudSyncCheckAsync
https://github.com/microsoft/pxt/blob/290c02b2143b3dc9cd3f27762d37e61a6654be09/skillmap/src/lib/workspaceProvider.ts#L41-L57
🌸 Fourth, the way we were keying into what skillmaps to upload were by what the cloud user had visited
...I'll add inline comments to put what fixes what. I don't know if this is readable sorry 😓

I pulled this branch to try it out, and I think it has a regression: my local progress isn't being imported when I sign in. Repro steps:

Delete profile
Reset progress
Start an activity
Sign in
Notice progress wasn't imported

Working as expected in /stable.

Here is an uploadtrg to try out https://arcade.makecode.com/app/02497ed2bc68eb3139615162d0ba255fb5746b3d-fefeaf11fe

Here is an uploadtrg to try out https://arcade.makecode.com/app/02497ed2bc68eb3139615162d0ba255fb5746b3d-fefeaf11fe

Import is working reliably there! I can't repro the delete profile bug either. Nice.

cool cool cool that's the dreeeeaaaam

Great job @livcheerful

Agreed, nice sleuthing.


Wait for migrator service

Hi,
I have pipeline with three steps:

run maintenance mode
migrate db - Started once service
run production mode back

I am facing to problem with waiting for migrator in step 2.
Following command:
upgrade --environment Staging --stack $STACK_NAME --service migrator --new-image myImage:$APP_VERSION --finish-upgrade
run migrations which usually running 1-2 minutes but pipeline dont wait for migrations done and start step 3 (run production mode).
It is possible wait for migrator and then continue to next step?

I suppose you are talking about it, see  --wait-for-upgrade-to-finish / --no-wait-for-upgrade-to-finish

make sure that you have proper health checks in rancher


[SPARK-35348][SQL] Support the utils for escapse the regex for ANSI SQL: SIMILAR TO … ESCAPE syntax

What changes were proposed in this pull request?
ANSI SQL: SIMILAR TO ... ESCAPE is very useful.
There are some mainstream database support the syntax.
PostgreSQL:
https://www.postgresql.org/docs/current/functions-matching.html#FUNCTIONS-SIMILARTO-REGEXP
Redshift:
https://docs.aws.amazon.com/redshift/latest/dg/pattern-matching-conditions-similar-to.html
Sybase:
http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.help.sqlanywhere.12.0.0/dbreference/like-regexp-similarto.html
Firebird:
http://firebirdsql.org/file/documentation/html/en/refdocs/fblangref25/firebird-25-language-reference.html#fblangref25-commons-predsiimilarto
This util supports the following pattern-matching metacharacters:

Operator
Description

%
Matches any sequence of zero or more characters.

_
Matches any single character.

|
Denotes alternation (either of two alternatives).

*
Repeat the previous item zero or more times.

+
Repeat the previous item one or more times.

?
Repeat the previous item zero or one time.

{m}
Repeat the previous item exactly m times.

{m,}
Repeat the previous item m or more times.

{m,n}
Repeat the previous item at least m and not more than n times.

()
Parentheses group items into a single logical item.

[...]
A bracket expression specifies a character class, just as in POSIX regular expressions.

Note
SIMILAR TO is similar to RLIKE, but with the following differences:
1. The SIMILAR TO operator returns true only if its pattern matches the entire string,
unlike RLIKE behavior, where the pattern can match any portion of the string.
2. The regex string allow use _ and % as wildcard characters denoting any single character
and any string, respectively (these are comparable to . and .* in POSIX regular
expressions).
3. The regex string allow use escape character like LIKE behavior.
4. '.', '^' and '$' is not a meta character for SIMILAR TO.
Why are the changes needed?
ANSI SQL: SIMILAR TO ... ESCAPE is very useful.
Does this PR introduce any user-facing change?
Yes, a new feature.
How was this patch tested?
New tests

Test build #139463 has started for PR 32477 at commit 71f6d95.

Test build #139463 has finished for PR 32477 at commit 71f6d95.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/139463/

Test build #139465 has started for PR 32477 at commit 788dfe0.

Test build #139468 has started for PR 32477 at commit 29e5822.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/43986/

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/43988/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/43986/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/43986/

Test build #139465 has finished for PR 32477 at commit 788dfe0.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

retest this please

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/43988/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/43988/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/139465/

Test build #139477 has started for PR 32477 at commit 29e5822.

Kubernetes integration test status success
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/44000/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/44000/

Test build #139468 has finished for PR 32477 at commit 29e5822.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/139468/

Test build #139477 has finished for PR 32477 at commit 29e5822.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/139477/

ping @cloud-fan

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/47348/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/47348/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/47348/

@cloud-fan Please help me to remove stale label.

Test build #146183 has started for PR 32477 at commit 29e5822.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/50656/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/50656/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/50656/

Test build #146183 has finished for PR 32477 at commit 29e5822.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/146183/

Test build #146188 has started for PR 32477 at commit 29e5822.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/50663/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/50663/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/50663/

Test build #146188 has finished for PR 32477 at commit 29e5822.

This patch fails PySpark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/146188/

retest this please

Test build #146206 has started for PR 32477 at commit 29e5822.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/50680/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/50680/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/50680/

Test build #146206 has finished for PR 32477 at commit 29e5822.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/146206/

ping @MaxGekk cc @cloud-fan

@cloud-fan Please help me to remove stale label.


ENH: Where https works, replace http using http_to_https.bash

Automated reformatting with https://github.com/InsightSoftwareConsortium/ITK/blob/master/Utilities/Maintenance/ApplyScriptToRemotes.sh

@dzenanz Seeing CircleCI failures in this repo that do not seem to appear in other external modules using Github Actions runners. Maybe something to do with CircleCI?
Upload file: /ITKIOOpenSlide-build/Testing/20220531-1528/Build.xml to https://open.cdash.org/submit.php?project=Insight&FileName=CircleCI___External-ITKIOOpenSlide-http_to_https-64-66a86fd___20220531-1528-Experimental___XML___Build.xml&MD5=72a2b1b19f2cbb849b3c15ad9c211b78 Size: 1067
   Error when uploading file: /ITKIOOpenSlide-build/Testing/20220531-1528/Build.xml
   Error message was: SSL certificate problem: certificate has expired
   Problems when submitting via HTTP

Warning: Failed to create the file doxygen-1.8.11.linux.bin.tar.gz: Permission

The CI seems to be broken. Let's leave the PR up, until someone can look into CI here.


Compilation error on find_vcpkg_root.

Running on Linux (nixos), installed opencv4 from the distribution package.
Rustc is 1.47.0, OpenCV4.
When doing cargo build, I get:
error[E0603]: function `find_vcpkg_root` is private
   --> /home/alois/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.46.2/build.rs:431:40
    |
431 |         let vcpkg_root = canonicalize(vcpkg::find_vcpkg_root(&config)?)?;
    |                                              ^^^^^^^^^^^^^^^ private function
    |
note: the function `find_vcpkg_root` is defined here
   --> /home/alois/.cargo/registry/src/github.com-1ecc6299db9ec823/vcpkg-0.2.6/src/lib.rs:223:1
    |
223 | fn find_vcpkg_root() -> Result<PathBuf, Error> {
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0061]: this function takes 0 arguments but 1 argument was supplied
   --> /home/alois/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.46.2/build.rs:431:33
    |
431 |         let vcpkg_root = canonicalize(vcpkg::find_vcpkg_root(&config)?)?;
    |                                       ^^^^^^^^^^^^^^^^^^^^^^ ------- supplied 1 argument
    |                                       |
    |                                       expected 0 arguments

error: aborting due to 2 previous errors

I see on crates.io that vcpkg wasn't updated in the last 5 months, so I'm not sure where to look?
Thanks for your help

Should be fixed in v0.46.3, the reason is that the crate is using a vcpkg function that appeared in v0.2.9 and your cached one is probably older. The new crate version should fix that.

I can confirm https://github.com/twistedfall/opencv-rust/commit/21a68d02ea9a53d017b83149d7bf751714485cd4 did fix the issue, I just put 0.46.3 explicitly in my Cargo.toml and now it works fine (fetching latest 0.2.10 of vcpkg).
Thank you so much for your quick support @twistedfall and for this useful binding!


First class port (command redirection) values

Currently ports are only exposed to the user via command redirections. It would be nice if they are also available as first-class values.
Preliminary ideas about the syntax:

Add a new builtin special form open which outputs a port value that would result from applying the redirections it is supplied with. For instance:

var $f = (open >/dev/null)

is roughly equivalent to the following in Python:
f = open('/dev/null', 'w')

Using the value is the same as command redirection:

var $f = (open >/dev/null)
ls >$f

Open questions:

How should open behave when supplied with multiple redirections?

In the previous example the direction of the port (>) appears twice. Should we try to eliminate this reduplication?

What about channel ports?

Allowing f=(open >/dev/null) breaks the lifecycle of redirections.


Added an option to always show the HUD while in Controller Mode, matching the legacy behaviour of LambdaControls. Also changed some default settings to be "safe" in the sense that the features that can be considered "cheating" in multiplayer servers are now disabled by default.

Added an option to always show the HUD while in Controller Mode, matching the legacy behaviour of LambdaControls. This option is enabled by default so that users migrating from LambdaControls will have a consistent experience.
Also added untranslated strings to the localisation files.
I've also changed some default settings to be "safe" in the sense that the features that can be considered "cheating" in multiplayer servers are now disabled by default, which is something that has bothered me about MidnightControls for a while.
Feel free to discuss with me on Discord regarding these changes, I joined your server ;P

I just noticed that the 'Auto Switch' option already hides the HUD when no controller is active.
I'm going to enable that by default and remove the HUD hiding stuff that I implemented.

Ah… yeah, I noticed that too, but I thought you had some other reason for implementing the feature that you did.
Feel free to hud_always_show, then!

I think it's nice to have it activated by default, as it also automatically switches to the controller on connection, so you don't have to grab a mouse first if you want to use it when gaming on the couch for example.


The keyboard lights for this applet have stopped working

I suspect there is an error when fetching the ticker symbol data from IEX. When I go to add a new stock quote and click save, the save dialog does not complete and move on to the next screen.

This issue is related to https://github.com/daskeyboard/daskeyboard-applet--stock-quote-usa/issues/5
We are currently looking into another API.
Any help would be highly appreciate.


Rephrase model component documentation for full display in API manual

Currently, the documentation for the type property of a model component is not displayed in full in the summary:

(screenshot from 2020-03-12 (ISO8601 date))
The source code from which the text seen in the image is generated, as far as I understand, resides in src/framework/components/model/component.js:
     * @property {string} type The type of the model, which can be one of the following values:
     *
     * * "asset": The component will render a model asset
     * * "box": The component will render a box (1 unit in each dimension)
     * * "capsule": The component will render a capsule (radius 0.5, height 2)
     * * "cone": The component will render a cone (radius 0.5, height 1)
     * * "cylinder": The component will render a cylinder (radius 0.5, height 1)
     * * "plane": The component will render a plane (1 unit in each dimension)
     * * "sphere": The component will render a sphere (radius 0.5)
     *

Note how the summary text in the image stops just after the first period character in the source code. I believe the problem can be avoided by not using that character, and this PR does that.
Perhaps a more global solution to this problem would be that the logic that determines where to stop the summary text is changed to not stop at a single period but rather a period followed by a whitespace character or the end of the string.
I confirm I have signed the Contributor License Agreement.

At the top of each API reference page, there is a short description of each property/function which is taken up to the first full stop. The full description is further down the page. I've edited your PR to be a bit more in line with other descriptions. Thanks! 😄


Add new emergency Graham-Cassidy banner

TEXT
Congress is closer than ever to passing Trumpcare, with devastating effects for tens of millions of Americans. Call your Senators and Representative NOW and tell them to oppose this bill:<PHONE_NUMBER>

One idea:

I like it. But could we make the font somewhat bigger, and the phone number even bigger?

This looks solid. I take it the bottom is mobile?
Only change I'd ask is punctuation at the end of "this bill." With the separated phone number it feels like the sentence is over and the number isn't connected.


Missing milliseconds

DateTime values missing milliseconds which are very useful in tracing events

Which field are you referring to?  I see milliseconds included in the Timestamp and EventTimeStamp fields.


fix(home): Updated per review with Catherine

Catherine asked that the logo be centered vertically and to remove some text.

@dlabrecq snapshot fabric8-ui is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-823-fabric8-ui.int.rdu2c.fabric8.io


Add map for additional data e.g data of request

I want to save more data that is not stored in User model e.g request data.
For example:

Store map with IP address to easily detect what changes was made from particular IP.
Store user agent for statistics.

This can be achieved pretty easy already with the whodoneit-map install option. For example, in the example in the readme file, you can modify the defp whodoneit(conn) do function to create your own map, including with what ever data you want.
I don't think an additional map is required.

Can I keep relation belongs_to to User and store map of additional data at same time?

Is there a good reason to do so? Can you give an example that warrants having both a module model reference and a separate map of additional data. I'm a little hesitant since it adds additional complication and I want to make sure there is a good use case for it.

For example:
I know Mike. He is good editor and my friend from real world, but his account was hacked (e.g "Social engineering").

I want to retrieve list all changes made by Mike to sum his job and send payment.
I want to retrieve list all changes made by hacker IP (stored in request map) to detect unwanted system changes and revert them.

So, what wrong with using the whodoneit-map option and store the following map?
%{user_id: user.id, request_ip: header.ip, username: user.username, ...}

See: Add dependent opts #723. I want to use dependent for versions (see example in point 3 of my comment above).


[Embedded Content Consumer] Terra-dev-site examples blank

Bug Report
Description
The examples of terra-embedded-content-consumer on terra-dev-site don't load in Firefox.
Link

Steps to Reproduce

Open up Firefox
Head to this link

Additional Context / Screenshots

Expected Behavior

Examples should appear as so:

Environment

Component Name and Version: Embedded Content Consumer
Browser Name and Version: Firefox 61
Operating System and version (desktop or mobile): MacOS High Sierra

This is a weird issue because we are need the provider examples to feed to the embedded-content-consumer examples for both doc and test pages. My proposal would be this:

Add a hidden providers navigation link to nav.config.js
Move packages/terra-embedded-content-consumer/src/terra-dev-site/test/embedded-content-consumer/providers examples to packages/terra-embedded-content-consumer/src/terra-dev-site/providers
Rename each example to from example.test.jsx to example.provider.jsx
Update both the doc and test urls to be the raw provider routes

Then, in the terra-ui repo, we can add the hidden providers navigation link to the nav.config.js and then these examples should be visible on terra-ui.com.


Is everything in one container?

May I just check...are MySQL, PHP, Redis etc in one single container?

Yes. this container has all services in a single container. It is meant for development only and not production. If you are looking for a configuration that separates it services into different containers, you can check https://github.com/laradock/laradock


Passing Passcode and Room Name via url

Is there a way to pass both a passcode and room name via url?
When I follow the instructions here: https://www.twilio.com/blog/set-default-room-name-twilio-video-react-app I get the response "Not found".
Alternatively, if there is a way to automatically populate the room name and manually enter the passcode (room first, name and passcode on next screen) that would also fit my use case.

@mcacnl ,
Thanks for writing in. While your local deployment works if you add /room/test to the URL, when you deploy using npm run deploy:twilio-cli, I think the server that is serving the app is different from the local server. So, one way you can achieve what you want is change the app source to accept room name as a URL parameter along with passcode. Does this work for you?

We are also seeing this issue. Yes, the localhost is a different configuration and allows the '/room/test' but the deployed configuration does not. Any hints on where to config the App-source for this? So to be sure. Currently this feature ONLY WORKS IN THE LOCAL ENVIRONMENT and NOT in the deployed environment. Reference: (https://www.twilio.com/blog/set-default-room-name-twilio-video-react-app). When deployed users will either see the /login page, or the roomName with an empty textfield, and userName with an empty textfield. Attempting to use '/room/myUniqueRoomName' results in a blank page stating "not found".
We are also using a custom token. Maybe another potential option would be to bypass the preVideo forms and retrieve the required data from the Token. Or pass them in a JsonObject in the body of the request. Has anyone already done this? thanks.


error: could not upload, status code (504 Gateway Time-out)

Thank you very much for developing this nice software and providing us binaries! It really helps.
I can upload small binary files without errors.  But when I try to upload a larger file (550MB), I got this error.  Here is the last part --verbose message.

setting content-length to 586121216
RESPONSE: &{504 Gateway Time-out 504 HTTP/1.1 1 1 map[Content-Type:[text/html] Content-Length:[176] X-Github-Request-Id:[A96B:9647:6704B7:6C263B:5AFDB043] Server:[GitHub.com] Date:[Thu, 17 May 2018 16:41:23 GMT]] 0xc0420e6b80 176 [] false false map[] 0xc042240100 0xc0422722c0}
error: could not upload, status code (504 Gateway Time-out)

My upload speed is about 100 Mbps. I am using "windows-amd64-github-release.zip" on Windows 10 64bit.
Strangely, though I see the above error on my command prompt window, the file seems to be uploaded without problem. I could download the file and the file was OK.
Any possible solutions?
Thank you.

My guess is the Github API just had a hiccup. I would suggest trying the request again if this happens or building in retry logic.


User does not receive appropriate feedback when invoking an invalid public share link

Steps to reproduce
Steps to reproduce the behavior:

URL of a deleted share link (e.g. https://xxx.de) is accessed.

Expected behavior
Since the link is invalid, a message should come relatively quickly (after 60s at the latest) that the link may no longer be valid.
Actual behavior
the window visible in the screenshot stays for minutes (I stopped looking at some point) and the small loading icon in this window rotates.
Additional context
Context to understand the problem
Note
I just increased the priority a bit, because I'm not sure if this window is only running in the client or if some background process could also affect the server with it, because then a simultaneous call of this URL (e.g. all members of the instance family click on a link because it leads to the current issue of the instance newspaper) could become a problem.

TODO after fixing change -> do a good checking e2e  test https://github.com/owncloud/web/blob/master/tests/e2e/cucumber/steps/ui/public.ts#L133-L137


docs: fix links

SUMMARY
Fix link to docker_build_push.sh in docs/docs/installation/installing-superset-from-scratch.mdx
Fix syntax of link to setup.py file in docs/docs/installation/installing-superset-from-scratch.mdx
Fix links in multiple doc pages so that they take us to the locally hosted URL when we run the docs using the below commands
cd docs
npm run start

TESTING INSTRUCTIONS
Start local version of docs using the below commands
cd docs
npm run start

Visit http://localhost:3000/docs/installation/installing-superset-from-scratch
Before the fix - setup.py was shown as plain text

After the fix - setup.py is highlighted as a link

Clicking on this file link on the same page should take us to a valid file on the GitHub.

Clicking on Configuring Superset should take us to http://localhost:3001/docs/installation/configuring-superset instead of https://superset.apache.org/docs/installation/configuring-superset/ . We can test other pages in the same way.

Thanks @fenilgmehta for a great clean contribution!  The way you shared screenshots and examples in the PR was very helpful 🙏


Long Running Workloads

I've been browsing through the source code, so apologizes if this is supported and I just missed it.
Does keda scaling support long running workloads from queues?
If keda scales up a deployment to 1 pod because there is a queue with an item (assuming that's your scale config), and that pod pulls down the job to work on it and it's long running (say hours), will keda scale the deployment back down causing k8 to kill the pod once the cool down period is reached? From code browsing, looks like it would?
If it's not supported now, any plans on the roadmap? Or just not a use case keda is designed for?

will keda scale the deployment back down causing k8 to kill the pod once the cool down period is reached? From code browsing, looks like it would?

Yes today that will happen based on the cooldownPeriod which defaults to 5 minutes. It's however a static value per ScaledObject. So if the long running workload is not consistent in how long it takes, you'd have to set the largest possible value.
Ideally the scaledown logic should measure the cooldownPeriod from the last function execution or function in progress heartbeat, not the last check of the event source. This would require keda to have access to the metrics emitted by the container.
I think enabling keda to incorporate Prometheus queries into its scaling logic would allow for that logic, but we didn't want to have a hard dependency on Prometheus.  #156 is tracking Prometheus integration.

I guess one gross hack today is to have pod workers continue to update the ScaledObject update stamp while processing a long job.
That should prevent the cool down from triggering? Assuming you update faster then the cool down time.

Currently no plans to address this, but I don't think the use case isn't valid.
Like @ahmelsayed, if you know your processing time takes X, you can set the cooldownPeriod to X.
Having the pods report ongoing work to Keda or have Keda probe pods for ongoing work is a path one does not take lightly..

@whilke The best solution is to remote the item from the queue after you finish processing your job, and not before.

Circling back on this one as it's an area we've discussed some and wanted to get thought down.  I think there are 2 scenarios here:

Preventing KEDA from scaling a deployment to zero if there is work being executed
Preventing the HPA from scaling down a deployment that may have active work happening on it

In the case of #1 I think the recommendations for now would be to:

Don't remove the event item / checkpoint / complete until processing is completed.  Ideally KEDA still sees at least 1 item still alive on the queue.  This isn't always possible, but where it is, it's the best way to handle.
You may need to make your cooldown period as long as the potential execution time.
Potentially something else like whatever is the result of #2 below

For the case of #2, that can happen when the rate of events may decrease and the Kubernetes HPA decides to scale down the deployment.  If you have 5 replicas and replica A is 20 minutes into a 40 minute execution, it's possible that HPA will scale down replica A and terminate it.  In this case we've discussed a few options.  I'm not sure what the best one would be, but I plan to bring this up with the autoscaling SIG and see if any thoughts around what could be done to "postpone" or delay scaling down an instance if it signals somehow that it is the middle of some work.  @yaron2 also brought up that maybe the right Kubernetes paradigm for these types of long running jobs may be a Kubernetes Job - reated this issue to help track that potential approach as well.

Related: https://github.com/kubernetes/kubernetes/issues/45509

@jeffhollan, Jobs as they are implemented today would have a lot of problems handling queue based long running work loads.
They work well for processing through a queue of items, and can scale the jobs based on your own parallel logic, but once the queue goes cold and all the jobs finish you'd need some middleware watching the queue to spin up a new job when new items come back in.
Sounds ripe for race conditions, or over spinning jobs.

@yaron2 That doesn't solve the problem, and in fact wouldn't that result in spinning up to max pods? If you have a scale metric set for 1 queue item, and you start processing the only item but keep it in the queue, keda & hpa is going to see you still have items in your queue and will keep scaling up to try and handle it.
I also don't know of any queue implementations that will keep the item visible in the queue while you're processing it, otherwise it can get picked up by another listener. That goes for at most once, and at least once implementations.

and in fact wouldn't that result in spinning up to max pods?

No, that's not the case. the HPA will scale to meet the threshold, it (for good or for bad) has no knowledge of whether or not you actually finished processing the work. It will bring up the number of pods that meet the threshold metrics.

I also don't know of any queue implementations that will keep the item visible in the queue while you're processing it

Basically every queue system I know has a Peek-Lock functionality or means of achieving it. (noAck for Rabbit).
A consumer can lock and get the message, and the message gets deleted from the queue when the job is done.
If the consumer crashes, there's usually a timeout that releases the lock after a certain period of time.
Queues (normally) support a single consumer per messageID per queue, meaning multiple consumers can't get the same message on a given queue.

@lee0c is working on a proposal for the "job dispatch" pattern.  Any questions, comments, upvotes, etc. should be focused on #199 to see if that's one viable option to solve this that KEDA could provide.  I provided some background and questions [on that issue] as well.  Thanks @lee0c

I have a slightly alternative proposal for long running jobs that would also work for functions and other "listener" style applications rather than job style application.
Similar to this proposal, we would have a scaleType:  with current behavior being hpa, and options are simple, hpa. In simple scale mode, there is no HPA. Keda handles the scaling. This will mean that you'll loose HPA scaling metrics like CPU and memory, but you should still be able to get Keda metric scaling.
Not having HPA allows us to implement a simple "I'm busy" protocol with the application.
Possible options:

Keda-injected endpoint the application reaches out to:
File modified time in the container filesystem.

For #1: Keda could inject a KEDA_STATE_URI=https://<keda-service>:<port>/api/.... KEDA_STATE_TIMEOUT=5m. The app is expected to curl the url every 5 minutes if trigger is not active but busy. This will reset the last-active timer in Keda for the deployment
For #2: The app is expected to touch a file KEDA_STATE_FILE=/run/application/is_busy every timeout period if trigger is not active, but the app is busy. keda will exec stat  the file and reset last active timer if needed. This requires stat in the container.
This should allow most applications (from functions to bash scripts) to easily signal out to Keda that they are busy.

For #1: Keda could inject a KEDA_STATE_URI=https://<keda-service>:<port>/api/.... KEDA_STATE_TIMEOUT=5m. The app is expected to curl the url every 5 minutes if trigger is not active but busy. This will reset the last-active timer in Keda for the deployment

Does the app have to initiate it or does KEDA initiate it? Personally I'd prefer not to change my app because we choose to use KEDA. Having a "busy" endpoint next to (or even same as) my health endpoint would be a better fit which can be consumed.

For #1: Keda could inject a KEDA_STATE_URI=https://<keda-service>:<port>/api/.... KEDA_STATE_TIMEOUT=5m. The app is expected to curl the url every 5 minutes if trigger is not active but busy. This will reset the last-active timer in Keda for the deployment

Does the app have to initiate it or does KEDA initiate it? Personally I'd prefer not to change my app because we choose to use KEDA. Having a "busy" endpoint next to (or even same as) my health endpoint would be a better fit which can be consumed.

This is the approach we went (having the scaler check an instance if it's busy). It follows the normal health/ready check pattern. Also reduces race type conditions as it's a live check when the scaler is looking to scale down a set.

We could do that too. My only reservation is on expecting the pod to have an HTTP endpoint. Since all KEDA applications are meant to process polling-based events. I'm not sure most pods would need to expose an http endpoint, which depending on the framework you're using, it might not be as simple to add to a simple queue or topic consumer app.
Since KEDA doesn't require deployments to expose a service, we will need KEDA to port-forward from each pod to query the http endpoint inside.
To me option #1 above is if you want to push your state into KEDA and option #2 is if you want KEDA to poll your state, but a file is simpler than exposing an http endpoint.

option #1 and option #2 smell, a lot.
#1 makes your data very stale and introduces easy race conditions from when keda last got status and when it's terminating pods (where the pod might have picked up a new job by then).
#2 requires workers to implement the status file correctly or it's worse then #1 (same race condition issue plus all the overhead of requiring a exec stat. Still doesn't stop race conditions completely since it's a disconnected status system.
KEDA could create a headless service for the deployment. Which would give a CNAME DNS entry for every pod so it can connect directly to an endpoint vs port-forward.
I still think it's the best option, for an optional feature, even though it requires the worker to listen on a socket

I'm not sure how exposing an endpoint resolves the race condition though. KEDA could query the endpoint and get "not busy", then start terminating the pod while the pod has picked up a new work item in the mean time. To eliminate that race condition we'll have to re-implement the SIGTERM, SIGKILL approach of kubernetes where we inform a pod that we want to shut it down, and the pod says "yes or no", and if it says "yes, I'm ready to be terminated", then it's on your application to not accept any new tasks until it's terminated. This is quite a bit more involved than just an "is busy" end point.
What are the benefits of creating a service per-pod vs port-forward a pod while checking its status? Also what are the benefits of requiring every queue consumer to implement an HTTP interface to signal busy state as opposed to touch $KEDA_STATE_FILE or curl $KEDA_STATE_URI on a timer while processing a queue message that you expect to take a long time given that both mechanisms are susceptible to the same type of race condition?
If the problem we're trying to solve is KEDA terminating a 3 hour job that's 2 hours into processing, then those race conditions are not applicable.
If the problem is KEDA terminating a pod that has received a workitem between the time of KEDA checking the "busy" status and terminating the pod, then we need the pod to cooperate in the shutdown process, which is more involved.

@ahmelsayed sorry for resurrecting an old thread. Isn't this exactly what liveness probes does? Are you suggesting using it or implementing it as brand new? I am playing with the pod disruption budgets to see if HPA respects it. If thats the case, we can have the pod clear the label when it is not "busy" and let HPA scale it down

Is this still open? I see https://github.com/kedacore/keda/pull/322 merged which gives external checkpoint functionality, was wondering if these 2 issues are different.

Yes the only gap now is documentation.  I think the two recommendations are:

Leverage the pre-hook for termination to delay scaling down of a pod until your application returns the correct SIGTERM to let Kubernetes know it’s ok to scale down.  The upside of this approach is you can still use standard deployments / concurrent containers.  The downside is if a job is delaying scale down for a long time (say hours) the Kubernetes API will set the status as “terminating...” which may be confusing to operators.
Use the new jobs functionality to consume long running tasks as a job.  The upside to this is there’s a single atomic job per long running operation, and status will just be “running”.  Downside is it requires you architect your app in a way so the container only pulls a single message and then terminates.


Bug at login as user on OSM through  TM3

Tried to open a task through the HOT OSM route.
after opening TM3  I need to login to Hotosm.  I have an account. So normally that works fine.
Now, when clicking on a project.  I selected project 3 After clicking on the mapping field I am asked first to log in,
Selected the shortcut gives the next result
https://tasks-assistedv2.hotosm.org/api/v1/auth/oauth-callback?redirect_to=/project/3&oauth_token=C42GNuLKLZkp5jKvRSTQeCjs4viOdMVuwM4hByl7&oauth_verifier=Lungs1mBfB1D4xPJKupr
and ended up in an emty screen with the text  'nul'
That's it.  No I D editor

This has been resolved on the tasking manager side.


Ember 4.0: Unrecoverable Error

It appears that trying to upgrade an application consuming this addon to Ember 4.0 causes an unrecoverable error due to its usage of @ember/render-modifiers.

This error occurred when upgrading an application utilizing empress-blog to Ember 4.0. Per the stack trace in the image above, the error is occurring in the did-insert modifier. A quick yarn why confirmed that ember-responsive-image is the only package requiring @ember/render-modifiers:
=> Found "<EMAIL_ADDRESS>info Reasons this module exists
   - "empress-blog-casper-template#ember-responsive-image" depends on it
   - Hoisted from "empress-blog-casper-template#ember-responsive-image#@ember#render-modifiers"

It would be ideal in the long term if this dependency could be removed altogether, as did-insert (and the other modifiers in that package) were only intended as a bridge to Ember Octane, and they should generally not be used in modern Ember code. More information on that can be found here: https://github.com/emberjs/ember-render-modifiers#when-to-use-these-modifiers-and-when-not-to-use-them
However, if it's easier in the short-term to fix this error instead of removing the dependency, that would be a reasonable fix.

Here's a PR that repros the issue: https://github.com/elwayman02/hella-drunk/pull/283

Related: https://github.com/ember-modifier/ember-modifier/issues/136

Update: This issue may be Windows-specific, as I'm not seeing it occur in my CI builds.

Actually, after a rebase today I can't repro this at all, so... shrug
Gonna close this unless/until it reoccurs where I can repro.


Build Fails on 1H20 Insider Preview with VS2017 or VS2019

This bug-tracker is monitored by Windows Console development team and other technical types.  We like detail!
If you have a feature request, please post to the UserVoice.

Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues. Instead, send dumps/traces to<EMAIL_ADDRESS>referencing this GitHub issue.

Please use this form and describe your issue, concisely but precisely, with as much detail as possible

Your Windows build number:  (Type ver at a Windows Command Prompt)

Microsoft Windows [Version 10.0.18894.1000]

What you're doing and what's happening: (Copy & paste specific commands and their output, or include screen shots)

Build will not succeed in VS2017 or VS2019 Preview. I followed @DarqueWarrior tutorial from here: http://www.donovanbrown.com/post/Building-the-new-Windows-Terminal-with-Visual-Studio-2019

I have tried building the TerminalSettings project separately before trying to build the solution but that didn't succeed either.

What's wrong / what should be happening instead:

I expected it to spit out a complete build then be able to deploy the application and install it.

This should be covered in #489.

Will test, directions appear similar to Donovans guide.


Support YPub and ZPub

Please add support to generate both xpub, ypub and zpub.

Yes please add support and until you do put a note not to used the xpub key as they are broken on the live app

Indeed would be useful

vote

As of 2024, LL still shows xpub for Segwit and Native Segwit accounts incorrectly.
Can someone explain in which format LL shows Segwit accounts' xpub string?
For Segwit ypub, and for Native Segwit zpub required in advanced logs. But LL developers haven't implemented it yet!
Hope someone pays attention to this crucial absence in Bitcoin app.

This was maybe a good idea in 2018, but now that bitcoin moved towards wallets based on output descriptors, ypub/zpub formats should be considered obsolete.
Software wallets should rather backup the entire descriptor, and descriptors only support xpubs.

Thanks for the reply Salvatore. And thanks for the information about descriptors.
Assuming you're also referring to other "software" wallets like Electrum as you used the term "software wallet" in your reply, and we know LL is just a frontend app of Ledger hardware wallet. Just verifying my understanding of terminology.
However, many posts (including on Reddit) are still stating difficulty on viewing Segwit/Native Segwit transactions and correct balance (shows either blank or incomplete on LL interface when you reinstall/reset the OS and the app) and the people are still recommended to use that tool written by Jameson Lopp to see entire transaction history and balance manually, here:
https://jlopp.github.io/xpub-converter/
Apart from displaying xpub entry in a Segwit account, so, at least the integrity of that tool might be integrated on LL (along with details sections of Segwit Bitcoin accounts, of course with the courtesy of author) in which my point of view, it would be very handy and useful. As either on Bitcointalk.org, Reddit and even Github has such quite recent posts mentioning about this problem.
Implementing this feature in LL interface could have cleared the confusion of seeing xpub for Segwit/Native Segwit account details instead of ypub/zpub values.
Best Regards.


Change PR template to include changelog comment and type

Please describe the feature you'd like to see
Currently, we are spending too much time on preparing Changelogs, we can ease out the process by adding section to the changelog comments and type/category(feature, bugs, etc..) in PR templates.
We can even improve it further by automating the changelog generation.
Are there any alternatives to this feature?
Open to suggestions
Additional context
Got this suggestion in the retro call.
Acceptance Criteria

[ ] All checks and tests in the CI should pass
[ ] Unit tests (90% code coverage or more, once available)
[ ] Integration tests (if the feature relates to a new database or external service)
[ ] Example DAG
[ ] Docstrings in reStructuredText for each of the methods, classes, functions, and module-level attributes (including Example DAG on how it should be used)
[ ] Exception handling in case of errors
[ ] Logging (are we exposing useful information to the user? e.g. source and destination)
[ ] Improve the documentation (README, Sphinx, and any other relevant)
[ ] How to use Guide for the feature (example)

You might want to take a look at Towncrier - https://github.com/twisted/towncrier
Check how and why we adopted it for Airflow
https://lists.apache.org/thread/1bch0s4tr4w3vvxwt12z3vx0cyh0qp4o


License

The original author didn't add a license into the repo of FrogCraft.
However, he said that he might choose GPL. [Reference] (http://forum.industrial-craft.net/index.php?page=Thread&postID=153416#post153416)
On the other hand, M3gaFr3ak did port FrogCraft to 1.6.4 and it accepted by the original author. However there was no license either.

Solution 1:

All MPL or apache suggested.
MPL is stricter than MIT.
GPL is never desirable. Btw you can take a look at eclipse public license.

Wait... the api will be divide into two parts...

What two parts?

One for mod itself. One for chemistry

Thus I need to consider about it carefully. The api stuff is still under heavy constructing...

How do you construct it? So you mean the mod is not open source?

I suggest that don't worry about that. Seems that everything has been mixed together.

@liach Seriously, if you understand that what the purpose this repository actually has, you will realize that this issue is very hard to solve... question: have you ever played modded minecraft in 1.5.2?

Nope but vanilla beta. It would be good to choose license later when there's some code

Then it's better for us to be quiet. The more talk the more possibilities to be discovered.

298a0141c931d6e70b40183f6b91c8a85c433c4d

MIT, that's it. Texture will be redone later.

Actually no one see that the license need to change date.

You can use some sort of license gradle plugin to automatically apply licenses.

Lazy...


Create documentation for testing

Your Question
Can the documentation extended with examples how to test and mock this library?
The document you expected this should be explained
A documentation with examples how this library can be tested and mocked.
Expected answer

Hi,
I would suggest to real database for testing, but if you want to mock, you could use sqlmock with GORM like this https://gorm.io/docs/connecting_to_the_database.html#Existing-database-connection
Also you could use the new DryRun mode to check generated SQL.


Refactor Go codebase for better maintainability season

Duck season

Flaky Test
Failure Summary
Logs

[chromium] should return list of users correctly.
The API call to get the list of users failed with a 404 Not Found error.
Logs ↗

[chromium] should display error message for invalid login correctly.
The expected HTTP status code 401 was not received, instead a function was returned.
Logs ↗

[chromium] should login with credentials correctly correctly.
The login request to the server failed with a 404 Not Found error.
Logs ↗

Test$1UnsupportedMediaType
failure$1message: Failedfailure$1text: === RUN   Test$1UnsupportedMediaType    api$1test.go:74: Unsupported media type provided--- FAIL: Test$...
Logs ↗

... and 1 more

View Full Report ↗ ⋅ Docs


[reactivesocket-cpp] add fire-and-forget frame

Add support for Fire-and-Forget frames.

This is looking really good.

LGTM, I'll merge it after you consider the two nits.


Navigation Links Not Redirecting to Sections

Describe the bug
Clicking on the navigation links in the website header does not result in the expected redirection to the respective sections. The href attributes for the navigation links are currently set to "#", preventing proper navigation.
Expected behavior
Clicking on each navigation link should smoothly scroll to the corresponding section on the page.
**Screenshots **

here even after clicking on 'Destination,' the page still does not redirect to the 'Destination' section.
**Additional Context **
I can resolve the navigation issue by updating the href attributes of the navigation links to match the IDs of the target sections. This adjustment will ensure proper redirection when users click on the links.
Are you contributing under any open-source program ?
I'm contributing under JWOC'24

I am working on it under JWOC and in combination to issue #25

@yusra05 Welcome to the repo.
You can work raise any issue of your interest after looking into the already existing issues.


Use specialized traits to generalize lane comparisons

This fixes the issue where lane comparisons are determined by PartialEq and PartialOrd, which isn't correct.  It also allows min, max, clamp, and horizontal_{min,max} to be generic over element type.  This means that this PR also adds min, max, and clamp to integers.
The new traits SimdEq and SimdOrd probably should be part of the public interface, to allow calling the functions generically, but the functions in those traits should never be stabilized (and should probably be hidden, once that bug is worked out).  Both of these traits are sealed by SimdElement.
We can use the results of this PR to inform the conversion of other functions to generic over element type.

If they should be public so people can use them generically then why should the methods never be stabilized?

The traits are used in the bounds of the member fns of Simd, so you may want to check T: SimdOrd in order to be able to call Simd::<T, _>::min, but you shouldn't call <T as SimdOrd>::min directly.

what is the harm if someone did?

There's no harm, it just complicates the API.  There's no good reason to expose it because then we have the liberty to change it in the future.  I suggested hiding them to simplify the docs as well.
The trait is effectively a marker to map type to intrinsic.  A similar trait is std::convert::FloatToInt, which has a hidden intrinsic method as well.

It's worth noting that Simd::min and SimdOrd::min are completely identical, so I don't see any good reason to provide the latter, in any situation where you have SimdOrd you can just call Simd::min.

I just (1) am fundamentally against perma-unstable anything (2) the kind of person that frequently implements traits for newtypes via macro, and i would usually like the possibility to implement all of a base type's traits on the newtype as well, should it be appropriate.

In this case, these traits are literally just mapping of intrinsics to types.  They're sealed so users can't implement them on newtypes.

so, kinda like:
pub trait SimdOrd: ... {}

impl SimdOrd for f32 {}

impl<T: SimdOrd, const LANES: usize> Simd<T, LANES> {
    pub fn max(self, rhs: Self) -> Self {
        unsafe { max_intrinsic(self, rhs) }
    }
}

That isn't possible in some cases, since the implementations for different types aren't the same (for example, min and max are different for integers and floats).  I expect some other functions will work this way, too.  This also makes it much easier in the future to add new element types that may have very different implementations (like the NonZero integers, which would probably convert to the underlying type and defer to their implementation).

I expect we will definitely want fp min/max intrinsics (llvm may have issues recognizing the patterns)...so, while we're at it, just have int min/max too.
for this pr, yeah, we can just leave it with the calling SimdOrd methods, for future extension and for min/max right now.

NonZero types that interact with their "base" type using ops that return a type other than bool have ops that return the NonZero type, not the underlying type.

All I'm saying is that Simd::<NonZeroU8, _>::horizontal_max can't call the intrinsic directly, it'll call something like NonZeroU8::new_unchecked(self.get().horizontal_max()), and therefore the trait fn is necessary.

There's no harm, it just complicates the API. There's no good reason to expose it because then we have the liberty to change it in the future. I suggested hiding them to simplify the docs as well.

If there's no harm in having them exposed, then we should simply have them exposed, unless we actually intend to remove them later. And if this proposal is serious, then we do not. I disagree that it simplifies the docs: #[doc(hidden)] is not actually a promise that no one can see or use the function, and hiding the methods needlessly obfuscates the code to Rust programmers. I am aware that people on crates.io use that as a convention, but it isn't how Rust's stability promises work regarding the traits std implements.
This is true even if the trait is also sealed, and there is no reason to leave these traits as permanently unstable. People should be able to depend on the trait after stabilization for the types for which it is implemented for.

I understand your sentiment but I disagree with what these traits mean.  SimdEq exists purely for the purpose of gating Simd::lanes_eq to types that actually implement equality, and for allowing us to define that implementation per type.  The interface that users call should always be Simd::lanes_eq.  SimdEq::lanes_eq exists as an implementation detail.  We should be free to remove it, change it, etc, without worrying if any users are using it.  Identically, something that's already in std: when you convert an f32 to an int you use f32::to_int_unchecked, not <f32 as FloatToInt<{integer}>>::to_int_unchecked, because the latter is an implementation detail, a trait wrapper around an intrinsic.  Making that part of the public rust API by stabilizing it (and removing the #[doc(hidden)]) is unnecessary and bloats the API with no benefit to the user (and adds some confusion because now there are two duplicate functions!).

There is a tracking issue for that trait's stabilization.
https://github.com/rust-lang/rust/issues/67057
So no, I do not believe that reasoning applies.

I would argue the other way: Simd::lanes_eq exists because we don't want to fill the prelude with more stuff and we don't yet have intrinsic trait impls.

I guess whether or not it's part of the API is somewhat immaterial to this PR--I wish it weren't but it doesn't make a huge difference either way.  Like FloatToInt, I'd prefer if we make the functions hidden purely from the documentation perspective (isn't documentation the whole reason we went down this road of traits in the first place?) but if we must stabilize them I won't argue against it and I still think this PR is the right way to go.

Regarding SimdAbs:
I suggested traits because I felt we should have {Simd?}Float and {Simd?}{S,U,}Int, not SimdAbs, and that the traits should define that the vectors they are implemented for implement a natural subset of the behaviors of floats or integers, with very well-defined variations. That would keep the number of traits down to a sane and simple scope. I did offer a SimdAbs impl variation, briefly, but I no longer am inclined to such. Even so, I am not perturbed by the possible asymmetry.

This is not a good direction to go in, IMO.
As far as I can tell, the only reason to have SimdEq and SimdOrd is to support user types in Simd, which we should just not support. If you recall, we were careful to require that vectorized comparison (and essentially all other operations) was semantically the same as the scalar comparison in a loop — which isn't something we get for free (portable NaN handling has a cost on e.g. x86).
Keep in mind: even having SimdElement at all is already a step beyond most similar features in the stdlib (compare with core::sync::atomic, scalar integers/floats, ...), so we're already much more flexible and generic than we need to be.
People who want Simd<UserType, N> can write a transparent wrapper around Simd<Scalar, N> (where UserType is a transparent wrapper around Scalar), and convert/transmute on use. Again, precedent here is core::sync::atomic which we're already way more flexible and generic than.
Similarly, Simd<NonZeroInt, _> sounds like a headache for everybody. People who want to have niches in their vectors are more than capable of using [NonZeroInt; N] and convert to a vector on use. People who want to semantically forbid zeros can just wrap Simd<Int, _>.
TBH, given the bikeshedding and discussion about hypothetical future use cases we won't be able to add compatibly... I can see why the stdlib usually opts not to make traits for these things (or opts not to make them public). Designing a trait like this without excluding some hypothetical future use cases is both impossible, and seen as the Worst Possible Thing.

Okay, I'm going to roll the discussions from the comment thread and the main thread into this comment, to go through all the critiques in one place.
Are these traits required at all?
SimdEq is roughly equivalent to PartialEq, but there is no way to provide min, max, and clamp for floats, because PartialOrd does not provide those functions!  They are part of Ord, but we can't use that either, since it is not implemented for f32 or f64.  Even if we did use PartialOrd for the comparisons, we would still need a separate trait for these functions.  Not to mention all of the other functions (saturating math, abs, sqrt, etc) that don't correspond to an existing trait in std will need their own std::simd trait, anyway.  In the future I imagine having something like SimdSaturating (saturating arithmetic), SimdSigned (for abs, checking signs, etc), and then perhaps SimdInt, SimdFloat, for more specific operations (conversions, sqrt, trig, etc).
User types
This PR has nothing to do with user types.  These traits are sealed by SimdElement and I (personally) have no desire to ever support user types.
Library newtypes types
NonZero integers is just one good example, I think another good example is std::num::Saturating.  Considering how common saturating arithmetic is in SIMD, I could see that being very commonly used.  NonNull is also a good candidate, considering it has some useful semantic meaning beyond providing niches.  It's not a type yet, but I've seen some people advocate for NonNan float types, which would also help std::simd significantly.  I'm not suggesting we rush to support every single primitive newtype that exists, but I don't think a design that expressly prohibits them is a good idea, either.
Implementing newtypes by extending intrinsics
In the thread above, @workingjubilee suggested that instead of individually implementing each function as done in this PR, you could instead extend the intrinsics to support newtypes.  While this is theoretically possible, I don't think this is the way to go.  Consider the following example:
Imagine you want to add support for an arbitrary newtype (let's use all of the NonZero integers, and assume #[repr(simd)] has been appropriately updated to support newtypes as well).  Now you must modify all of the following:

the LLVM backend intrinsics
the cranelift backend intrinsics
the hypothetical scalar polyfill library

My concerns with this approach:

newtypes are promoted to something "special" in the compiler, somewhere near the level of primitives
newtype logic that can be easily represented in plain rust in std::simd (like simd_abs(x.get())) must now instead be duplicated in each backend
implementing a new backend would require an inordinate amount of knowledge about each individual newtype

While this approach could theoretically work, I think it makes more sense for the intrinsics to only use primitive types, and handle logic around newtypes within std::simd.  Using traits like in this PR allows you to customize how the various functions work for each newtype and maintain a clear distinction between newtypes at the library level and primitives at the compiler level.

In the thread above, @workingjubilee suggested that instead of individually implementing each function as done in this PR, you could instead extend the intrinsics to support newtypes.

I do not desire this, I stated that it is what limits the current interface, and that we originally designed SimdElement to mean "A machine scalar type", exactly matching the bounds in typeck as we found them. I do not desire this proposed extension, and I do not desire this infinite increase to the scope of our work. I do not want you to say I "suggested" something when I enumerate alternate paths, as it would have to mean I desire it, or even think it is a good idea, for it to actually be a suggestion. I have stated this boundary multiple times. Please do not transgress it again.
I agree with Thom. We should not go down this path.
NonZeroInt is just another user type: it merely happens that the user is std.
And there is no clear reason to support Simd<Saturating<i32>, N> instead of Saturating<Simd<i32, N>>.

Sorry, when I said suggest I didn't mean "advocate", I meant "propose to be considered".
You're right that newtypes could potentially be handled by wrapping Simd, but that complicates passing through the more complicated APIs like scatter/gather.  The nice thing about Simd is that it's a container.  Again, what I am getting at is that I'm not ready to make the decision today to prohibit using newtypes within a vector.
Maybe it was my mistake picking the comparison functions first, but I wanted to target the most complicated ones first.  If we don't go down this path, can I ask how we should implement min, max, and clamp?

Sorry, when I said suggest I didn't mean "advocate", I meant "propose to be considered".

Thank you.
I prefer "enumerate", as it is appropriately tediously dry and void of implication beyond the monotonic iteration of a thinking machine over multiple variations.

After a discussion with @workingjubilee, I've made some changes that I believe clarify the purpose and reasoning behind these changes.
There are two traits:

SimdPartialEq, which indicates that a type can be used to compute vector PartialEq operations
SimdPartialOrd, which indicates that a type can be used to compute vector PartialOrd operations

These traits indicate vector semantics, marking which vector operations can be done.  The implementations of these functions are handled by sealed traits.
The reasoning behind these changes is simply that different types need different implementations, and relying on PartialEq and PartialOrd does not convey enough information to implement everything.  Type wrappers such as the NonZero integers are one example, but even primitive integers and floats are significantly different and require different implementations.  clamp, for example, stands out as it's not possible to write a generic implementation for both integers and floats.


Protobuf version problem

Hello.
I try to install paddlepaddle_gpu on Jetson Xaiver Nx. When i try to follow guide pip3 installation on this link https://qengineering.eu/install-paddle-on-jetson-nano.html everthing looks fine. But protobuf version getting error like ##  protobuf requires Python '>=3.7' but the running Python is 3.6.9. I install protobuf 3.19.4 which compatible with python 3.6.9 everything looks like OK. But when i execute  "sudo -H pip3 install paddlepaddle_gpu-2.0.0-cp36-cp36m-linux_aarch64.whl" command, i am getting error about protobuf version. Probably it occurs cause in requirements.txt file has just protobuf not protobuf==3.19.4. Is there any other PADDLE_GPU version compatible with python 3.7 or newer version or could you update requirements file with python 3.6 supported versions.

I'm sorry, at the moment there is no other version available.
The Jetson Nano has ships with Python 3.6. If you upgrade with the Ubuntu 20.04 version, you get Python 3.7.
With the new protobuf is force users to install the Ubuntu 20.04. However, I can't install all requirements under 20.04.
It will take time to solve this issue. Being very busy, it will take a while.

I figured out my problem. I installed paddlepaddle_gpu on my Jetson Xavier Nx with Python 3.7. I download cp37 version from this link:
https://paddleinference.paddlepaddle.org.cn/master/user_guides/download_lib.html#python
Then i applied pip3 steps from this link:
https://qengineering.eu/install-paddle-on-jetson-nano.html
hints:
use virtualenv,
after "pip3 install paddleocr" step versions should be like
numpy==1.23.5
protobuf==3.22.0
onnx=1.11.0

Glad you could solve it!
Thanks for the info.


CC75032: Updating link CONTRIBUTING.md

Hello, @ghogen, @corob-msft,
This proposed file change comes from https://github.com/MicrosoftDocs/cpp-docs.pt-br/pull/2 .
Could you review this contribution and help to merge if agreed?
Many thanks in advance.
This proposed file change comes from xxx .
Could you review this contribution and help to merge if agreed?
Many thanks in advance.

@v-makoud : Thanks for your contribution! The author, @, has been notified to review your proposed change.

@v-makoud This change is not appropriate. The original reference is to the local CONTRIBUTING.md file in root of the repo, not the Microsoft Docs contributor guide, which is referenced in the previous sentence. These are two different documents, with different content. This change to MicrosoftDocs/cpp-docs.pt-br#2 should not be made in the pt-br content, either.


Fix e2e login error

Summary
The error:
When we add the server, sometimes the login form does not appear.
The assumption:
The detox build, for some reason ends up calling the "componentDidAppear" navigation event before the effect to register the listener is executed.
The solution:
Use an effect that sets the value of translateX to 0 after the first render, effectively starting the animation.
The caveat:
What is done should be the same as doing it on componentDidAppear, but not sure whether there is some material difference there, so I kept the componentDidAppear event. If we consider the effect is going to be the same, we could remove the componentDidAppear event.
Ticket Link
None
Release Note
NONE

Successfully triggered e2e mobile testing!
https://git.internal.mattermost.com/qa/mobile-e2e-testing/-/pipelines/289562


spooky-commit was not added

spooky-commit was not added, the commit was made on 10/31/2024, but for some reason, the badge was not added.
commit: https://github.com/andrewjswan/svitlobot/commit/1cccefbf36463a6cde1c730fe5107bf2011adf02.patch
action: https://github.com/andrewjswan/andrewjswan/actions/runs/11622110394/job/32367041283#step:2:118
my badges commit: https://github.com/andrewjswan/andrewjswan/commit/1dbdf3ba610f7001e7187f32fa60735cce67befb

https://api.github.com/repos/andrewjswan/svitlobot/commits
"commit": {
      "author": {
        "name": "Andrew J.Swan",
        "email"<EMAIL_ADDRESS>        "date": "2024-10-31T12:42:48Z"
      },
      "committer": {
        "name": "Andrew J.Swan",
        "email"<EMAIL_ADDRESS>        "date": "2024-10-31T12:42:48Z"
      },
      "message": "Fix for ESPHome 2024.10",
      "tree": {
        "sha": "d9dfa98f8978860993a38604978b0e055bdc7e11",
        "url": "https://api.github.com/repos/andrewjswan/svitlobot/git/trees/d9dfa98f8978860993a38604978b0e055bdc7e11"
      },
      "url": "https://api.github.com/repos/andrewjswan/svitlobot/git/commits/1cccefbf36463a6cde1c730fe5107bf2011adf02",
      "comment_count": 0,
      "verification": {
        "verified": false,
        "reason": "unsigned",
        "signature": null,
        "payload": null
      }

I see. Let's fix it!

+1 ..

I support it, but I don’t know ts, and I still don’t understand how it works now, and why this badge isn’t added.

We are looking forward... :)

Hi!
Any news? :)

@antonmedv I looked through the entire code several times, went through the chain, and still didn't understand why it doesn't work. Maybe you can give me a hint as to why, maybe I'll understand and make a PR?

Ufff! I had to put a lot of efforts to fix it)))
https://github.com/my-badges/my-badges/commit/88a1fde91123cd38a31b5d7562306395d3d45d39

Please check it. Should be fixed now!

I might be wrong here but doesn't typeset work with 0 index counting and not 1?
so or 31st oct, it should be: if (data.getMonth() === 9 && data.getDate() === 31) {...}
instead of if (data.getMonth() === 10 && data.getDate() === 31) {...}
regarding: https://github.com/my-badges/my-badges/blob/master/badges/spooky-commit/spooky-commit.ts

True! getMonth is 0-based: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/getMonth
Could you do a fix?

yes. on it.. :)

testing was longer than editing.. but there you go: #73

Thanks! Worked! :)


Task/list updates

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 68.61%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
306

Relevant Lines:
446

💛  - Coveralls


validate length when inline editing

When using the inline editor, error when assembling content that is too large and pad when changing to a shorter length

We now pad out the instruction with nops if the new instruction is smaller than the old one. For instruction that are larger, we pad out to the closest instruction boundary.

To clarify, this is fixed in dev -- should be coming out to beta soon.

fixed in 1.0.273 beta


Patterns: CTA Section isn't not rendering properly

Detailed description

Describe in detail the issue you're having.

During the building of NextJS Services Page, I need to use CTASection, but when one of CTA’s text is increased, a buggy CTA appears in background.

Is this a feature request (new component, new icon), a bug, or a general
issue?

Bug

Is this issue related to a specific component?

CTASection

What browser are you working in?

Google Chrome

What version of the IBM.com Library are you using?

v1.8.0
Steps to reproduce the issue

Step one

Access here

Step two

Scroll Down to see CTASection
Additional information

PR related: carbon-design-system/ibm-dotcom-library-nextjs-test/pull/33

I am closing this issue, because there is an open PR to handle multiple CTA on CTASection.

I am closing this issue, because there is an open PR to handle multiple ctas on CTASection


Feat/prometheus server update

Updated prometheus_server role, in order to only install snmp_exporter and ipmi_exporter if necessary.
Also added inventory variables for alertmanager.yml (should be added into defaults.yml ?) , and added restart of prometheus service each time the role is executed, in order to take into account the changes to prometheus.yml. The variables start_services and enable_services for prometheus_server and prometheus_client which are required should also be placed into default.yml?

Hi @sobrase ,

Updated prometheus_server role, in order to only install snmp_exporter and ipmi_exporter if necessary.

Can we install those packages with the role prometheus_client? Or is it mandatory to collocate these 2 exporters with the prometheus service?

Dear @sobrase
I will have a deep look into this end of next week.

Can you use this PR to fix the indentation in prometheus doc at https://github.com/bluebanquise/bluebanquise/blame/eea7e83a42fd7f25fc73dee6a1ef774500db2c09/resources/documentation/monitoring/prometheus.rst#L36-L41

We need to review the snmp and ipmi architecture for 1.4 version. This PR is to be left open until investigated.

Closing for now.


Close and Fullscreen buttons are in the center of the scene

Discord username
farmaazon
What type of issue is this?
Permanent – Ocurring repeatably
Is this issue blocking you from using Enso?

[ ] Yes, I can't use Enso because of this issue.

Is this a regression?

[ ] Yes, previous version of Enso did not have this issue.

What issue are you facing?
When I open a project in browser, the close and fullscreen icons are in the middle of the scene:

They move to their proper place after resizing scene.
Expected behaviour
Those icons should be in their right place right away.
How we can reproduce it?
No response
Screenshots or screencasts
No response
Enso Version
build on commit 58c7ca54011bba1208de298d7b2e6877570d5b47
Browser or standalone distribution
Chrome
Browser Version or standalone distribution
Google Chrome 110.0.5481.100
Operating System
Linux
Operating System Version
No response
Hardware you are using
No response

@sylwiabr Is it still required for the Design Partners?

This is fixed.


Update index.md

Learn Build status updates of commit 8871536:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

microsoft-365/whiteboard/index.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 the learn.microsoft.com contributor guidesPost your question in the Learn support channel

Learn Build status updates of commit cb2cb79:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

microsoft-365/whiteboard/index.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 the learn.microsoft.com contributor guidesPost your question in the Learn support channel

Learn Build status updates of commit a945697:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

microsoft-365/whiteboard/index.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 the learn.microsoft.com contributor guidesPost your question in the Learn support channel


Provide better default buffer size to FlatBufferBuilder.init()

Currently the size is 1 and is doubled each time needed thus requiring a handful of unnecessary malloc/frees for any reasonable normal object - would be nice if the default could be the "sum of the sizes of all scalars, padding, known vtable size, some reasonable guess of N bytes per string" such that normally zero, or just a single reallocation would be needed.
Each generated class could provide different defaults in the generated code "let builder = FlatBufferBuilder(xxxx)".

This one should be addressed by #6
I think estimating the size would be a tough thing to do, however if you can provide a serialisation config this would make everybody happy

That would probably be good enough for the most interesting use cases. Perhaps changing the current default from 1 to a reasonable three-digit number (if such a config is not provided) would give better default behavior though (removing 5-10 of the malloc/frees by default).
One could always use the serialization config to tune it down if desired.

just added 1024*40 as default .. don't ask me why :) but than again the real solution will come later with the config object

Btw, the generated code still uses 1 as the default...


Replaces unfilled template of the license

Fixes an unfilled template part of the license

@bkase IANAL, but I think you need to put a year or list of years, or range of years for the copyright claim.

@bkase IANAL, but I think you need to put a year or list of years, or range of years for the copyright claim.

I was advised to use this specific string 🤷♂ , we can adjust later I suppose


Fix setting connect timeout

fixed the bug of timeout set
add more options(persistent)

hope it's useful.

Thanks!


Add selectable attribute to edges

Please describe the feature that you want to propose
I'd like to be have access to a selectable attribute on individual edges.
My use case is related to collapsible nodes, in which I'd like to "freeze" all edges between two nodes when both nodes are collapsed.
https://github.com/wbkd/react-flow/assets/4822129/3eb26baa-df02-4854-9978-a68abe54b985
The closest I can get is to set edge.deletable = true for each edge. Maybe I could set pointerEvents = 'none' on those specific edges, but it would be nice if the library could handle this.
(My workaround plan is to hide those edges and render a dummy edge between the collapsed nodes. This will provide a better user experience anyways, but I still think this would be a nice improvement to the library.)

This will be possible in v12.

Thanks @moklick !

I'm currently using selectable inside edges and it is still possible to select them.
reactflow: 11.10.3
The following code is enough to reproduce it (https://codesandbox.io/p/sandbox/withered-bush-8kgf2v?file=%2FApp.js)
import React from "react";
import ReactFlow, { useNodesState, useEdgesState } from "reactflow";

import "reactflow/dist/style.css";

const INITIAL_NODES = [
  {
    id: "1",
    data: {
      label: "Default Node",
    },
    position: { x: 100, y: 100 },
  },
  {
    id: "2",
    data: {
      label: "Default Node",
    },
    position: { x: 100, y: 500 },
  },
];

const INITIAL_EDGES = [
  {
    id: "e1-2",
    source: "1",
    target: "2",
    selectable: false,
    label: "selectable: false",
  },
];

const Flow = () => {
  const [nodes, setNodes, onNodesChange] = useNodesState(INITIAL_NODES);
  const [edges, setEdges, onEdgesChange] = useEdgesState(INITIAL_EDGES);

  return (
    <ReactFlow
      nodes={nodes}
      edges={edges}
      onNodesChange={onNodesChange}
      onEdgesChange={onEdgesChange}
    />
  );
};

export default Flow;

This is supported since React Flow 12!
If you are using 11, you can find the migration guide here: https://reactflow.dev/learn/troubleshooting/migrate-to-v12


Document caveat of bean-spec compliant endpoints

If endpoints are written in a way that comply with bean-spec property and have validation annotations on them, they will be additionally executed as part of the validation logic.
I dug into the code and there is very little we can do in this regard. I tried coding a way to exclude certain properties that are annotated with javax.ws.rs annotations, but I had no luck -- we'd have to write our own Validator, so I thought the best solution would be to just document this small downside.
Only 1.0.0 and 1.1.0 users should be affected.
CC @scottaj
Closes #2008

Coverage remained the same at 84.495% when pulling efec6377eade4dbb88afd6257fca53d4d9ac757f on nickbabcock:return-validation-caveat into e6fba4c563604cc155ca9095bd781a0a1111d16b on dropwizard:master.


Preprocessing takes too much time

Hi, thank you for sharing code. It is a nice work.
I want to evaluate Light-ASD on in-the-wild YouTube video.
While Light-ASD is fast and accurate, for me, preprocessing (extracting video frame, face detection, face crop) is too slow.
Is there a good way to reduce the time?
Thank you

Hello, thank you for your interest in our work.
As the AVA dataset consists of facial sequences and the corresponding audio, Light-ASD did not specifically optimize the data preprocessing component. We adopted the preprocessing approach used by TalkNet to extract face tracking of speakers from the raw videos using S3FD, and validated it on the Columbia dataset. You can place the raw video (name.mp4 and name.avi are both fine) in a folder named folder and run the following code for detection.
python Columbia_test.py --videoName name --videoFolder folder
Perhaps you can achieve faster processing by replacing S3FD with a more efficient method in the Columbia_test.py file.

Although replacing S3FD is one of the possible solutions, replacing ffmpeg preprocessing seems to be tough.
Thank you for the reply.

Although replacing S3FD is one of the possible solutions, replacing ffmpeg preprocessing seems to be tough.
Thank you for the reply.

Concerning speeding up the extraction of video frames, I wonder if extracting and working on every n frames instead of all of them would make the performance much worse

@andrea-gatto I don't think that there would be a performance degradation
using ffmpeg less can be a detour
I'm trying to hardware accel
https://docs.nvidia.com/video-technologies/video-codec-sdk/12.0/ffmpeg-with-nvidia-gpu/index.html

@jun297 I tried running ffmpeg on frames extraction on one A10G GPU, I don't really see a speed-up unfortunately

@andrea-gatto Is there no difference despite the hardware accel?
I'm sorry but I haven't tried yet. I am considering extract frames with denseflow or opencv
you can refer:
https://github.com/open-mmlab/mmaction/blob/master/DATASET.md#extract-frames
https://github.com/open-mmlab/denseflow

Yeah no difference at all, the GPU is running at 1% and I get the same time as on CPU, I cannot exclude that switching to a different GPU would give the same result
Agreed probably the way to go is to move to something else like the stuff you linked


CardField giving null in all keys of error and paymentIntent is also undefined

Describe the bug
I am getting {"code": "Failed", "declineCode": null, "localizedMessage": null, "message": null, "stripeErrorCode": null, "type": null} error from confirmPayment function while using CardField.
I am passing this data to CardField:
CardNumber: 4242 4242 4242 4242, expiryDate: 12/23, cvc: 123, postalCode: 123456,
Smartphone (please complete the following information):

Device: Vivo v9
OS: Funtouch OS

Versions

"react": "17.0.2"
"react-native": "0.65.0"
"@stripe/stripe-react-native": "^0.16.0"

Please provide a reproducible demo, not able to reproduce this myself so far

At app.js
import { StripeProvider } from '@stripe/stripe-react-native';
//in main function
<StripeProvider publishableKey='[PUBLISHABLE_TEST_KEY]' > //Other Code </StripeProvider>
Confirming Payment
import { CardField, useConfirmPayment } from '@stripe/stripe-react-native';
const {confirmPayment, loading} = useConfirmPayment();
`
const handlePayPress = async () => {
if (!card) {
return;
}
// Fetching the intent client secret from the backend.
const clientSecret = await fetchPaymentIntentClientSecret();

const { error, paymentIntent } = await confirmPayment(clientSecret, {
paymentMethodType: 'Card',
paymentMethodData: {
billingDetails: {
name: 'Blah Blah',
email: '[EMAIL]',
phone: '[MOBILE_NUMBER]',
address: {[ADDRESS_OBJECT]}
},
},
});
if(error) {
console.error(
'Payment confirmation error',
error,
);
} else if (paymentIntent) {
console.log('Success from promise', paymentIntent);
}
};

<CardField
postalCodeEnabled={true}
placeholders={{
number: '4242 4242 4242 4242',
}}
cardStyle={{
backgroundColor: '#FFFFFF',
textColor: '#000000',
}}
style={{
height: 50,
marginVertical: 30,
}}
onCardChange={(cardDetails) => {
console.log('cardDetails', cardDetails);
}}
onFocus={(focusedField) => {
console.log('focusField', focusedField);
}}
autofocus
/>

`

This works in the example screen here, you might want to try and model your code off of that to figure out what's going on.

Closing since no repro was provided, but can re-open if there is one


[ci] rebalanced Linux tests

Now we have the following setting for Linux:

VSTS: regular (with examples), sdist, bdist, if-else, mpi-source, gpu-source with gcc (6 jobs, were 8)

Travis: regular (with examples), sdist, bdist, pylint, check-docs, mpi-source, mpi-pip, gpu-source, gpu-pip with Clang (9 jobs, were 11)

Travis can easy run 15 concurrent jobs, so there is no need in reduction of job numbers. In contrast, at Azure Pipelines we should try to stick to 10 tasks.
Use the same name BUILD_SOURCESDIRECTORY across build scripts: https://github.com/MicrosoftDocs/vsts-docs/issues/665

@StrikerRUS actually, I think we may need to add a tmp oxs test with gcc in vsts side (for 2.1.3 release), since we don't have the artifacts from travis.

@guolinke Sure! I'm planning to rebalance macOS part tomorrow. Will switch the COMPILER variable to gcc for 2.1.3.

Oh, forgot to mention that I believe we should run check-docs only at Travis due to it fails rather frequently and everyone should be able easy re-run it. Seems it's possible only at Travis.


Update of the usage reports references

In Step 2 in the note box, last paragraph: the reference should be to the PSTN and SMS (preview) usage report
In Step 2, paragraphs below the Note box the reference to the pstn usage report should be via Teams admin center -> Analytics & reports -> Usage reports -> PSTN and SMS (preview) usage
In Step 2 last paragraph the link to the doc page for pstn usage report should point to https://docs.microsoft.com/en-us/microsoftteams/teams-analytics-and-reports/pstn-usage-report

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

ID: 277cf140-5c6c-82c7-cc56-490ef2188754
Version Independent ID: 72e7de29-fd71-23bf-15a7-172634c2a5fd
Content: Set up Communications Credits for your organization - Microsoft Teams
Content Source: Teams/set-up-communications-credits-for-your-organization.md
Service: msteams
GitHub Login: @CarolynRowe
Microsoft Alias: crowe

Thank you for submitting feedback and contributing to the docs. We are currently investigating this.


makes it so that the main menu screen doesnt appear

just showing the main menu pictures without any of the text

was an issue with mod settings, not this


Updated CONTRIBUTING.md with images

Issue that this pull request solves
New images that load for CONTRIBUTING.md file
Closes: #330
Proposed changes
Add images for the CONTRIBUTING.md file to guide beginners
Brief description of what is fixed or changed
Added 7 images including:

PR template
New branch remote directory
How to create branches
How to compare files
Where to find the PR
How to find the issues
Where to fork project

Types of changes
Put an x in the boxes that apply

[x] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[x] Documentation update (Documentation content changed)
[ ] Other (please describe):

Checklist
Put an x in the boxes that apply

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] My changes does not break the current system and it passes all the current test cases.

Screenshots

Please attach the screenshots of the changes made in case of change in user interface
Other information
Any other information that is important to this pull request
All the images can be found at assets/cont-img

I am under DWOC. Happy to complete this issue. Please review my PR and provide feedbacks Thanks!!

Thank you for approving👍


Added thunk middleware breaks server-side render

Hi. First of all, thanks for this repo. Great job!
This issue is about thunk middleware I'm trying to add to applyMiddleware. The problem is that it breaks server-side render, it doesn't wait for fetchData's result. Here is the thunk taken from redux-thunk.
function thunk({ dispatch, getState }) {
  return (next) => (action) => {
    let isFunc = typeof action === 'function';
    typeof action === 'function' ?
      action(dispatch, getState) :
      next(action);
  };
}

and in redux/create.js
export default function(client, data) {
  const middleware = createMiddleware(client);
  let finalCreateStore;
  if (__DEVELOPMENT__ && __CLIENT__ && __DEVTOOLS__) {
    const { devTools, persistState } = require('redux-devtools');
    finalCreateStore = compose(
      applyMiddleware(thunk, middleware), // <--- add thunk
      devTools(),
      // ...
    );
  } else {
    finalCreateStore = applyMiddleware(thunk, middleware)(createStore); // <--- add thunk
  }
  return finalCreateStore(reducer, data);
}

Obviously I'm missing something. Any idea?

What is you swap the order? i.e. applyMiddleware(middleware, thunk)

@jepezi Double check if you're importing the middleware correctly (for example, import thunk from 'redux-thunk' vs. import { thunk } form 'redux-thunk'?

@jepezi Is this still a problem?

I'm sorry. Late to this. Turns out error was in my code trying to debug the dispatching sequence and messed it up. So this middleware code...
function thunk({ dispatch, getState }) {
  return (next) => (action) => { // <----------------------------- notice the '{'
    // let isFunc = typeof action === 'function';
    typeof action === 'function' ?
      action(dispatch, getState) :
      next(action);
  };
}

should return like this
function thunk({ dispatch, getState }) {
  return (next) => (action) =>  // <----------------------------- no '{'
    typeof action === 'function' ?
      action(dispatch, getState) :
      next(action);
}

From this commit, I notice we should return from the thunk as well, or just add redux-thunk before it.


SqlAG/SqlAGDatabase/SqlAGReplica - Updating examples to include enable HADR option

Pull Request (PR) description
Updating examples to include enabling the HADR option for SQL Server.
This Pull Request (PR) fixes the following issues
Fixes #1182
Task list

[x] Added an entry under the Unreleased section in the CHANGELOG.md? Entry
should say what was changed, and how that affects users (if applicable).
[ ] Resource documentation added/updated in README.md?
[ ] Resource parameter descriptions added/updated in README.md, schema.mof
and comment-based help?
[ ] Comment-based help added/updated?
[ ] Localization strings added/updated in all localization files as appropriate?
[x] Examples appropriately added/updated?
[ ] Unit tests added/updated?
See DSC Resource Testing Guidelines.
[ ] Integration tests added/updated (where possible)?
See DSC Resource Testing Guidelines.
[ ] New/changed code adheres to
DSC Resource Style Guidelines
and Best Practices?

This change is

@wsmelton Thank you for fixing this! 😃  Just minor comments.

Codecov Report

:exclamation: No coverage uploaded for pull request base (dev@f72dd2c). Click here to learn what that means.
The diff coverage is n/a.

@@          Coverage Diff          @@
##             dev   #1208   +/-   ##
=====================================
  Coverage       ?     97%
=====================================
  Files          ?      33
  Lines          ?    4016
  Branches       ?       0
=====================================
  Hits           ?    3929
  Misses         ?      87
  Partials       ?       0

Curious to know why the built in review features on GitHub are not used instead of a 3rd party tool? I have not submitted PRs to other major projects within MS so unsure if this is common tool or not. It is interesting.
The fact yall also validate a line is only 80 characters wide for markdown is just ridiculous to me as well. This is not coded language and has built in ability to wrap the line for viewing. But is what it is.
Anyway, InstanceName is the correct property name:

a discussion (no related file):
Previously, johlju (Johan Ljunggren) wrote…
There are merge conflicts since your PR was not based on the latest changes. Could you please rebase against branch dev using git rebase (not by using git pull or git merge, to keep the commit history). If you don't know how to rebase your local dev and working branch, please look at how to Resolve merge conflicts.
Let me know if you need any assistance.

Ha, that documentation is backwards to how Git is documented on remotes (e.g. origin should be my fork and not the upstream remote, this goes against every example in the documentation). I'll have to read through that a few times to make sure I don't break my branch.

The comment from review got strange, commenting here instead.
These are the commands I would have run.
git checkout dev
git fetch upstream dev
git rebase upstream/dev
git push origin dev --force
git checkout createag-example-updates
git rebase origin/dev
# fix any merge conflicts, run `git rebase --continue` as necessary
# When there are no more conflicts. continue with the next row.
git push origin createag-example-updates --force

At any time during rebase, while there is a conflict, you can abort by using git rebase --abort. Also, if for some reason there are nothing to commit when you fix a merge conflict, it can happen if the files are changed to exactly what are already being tracked (is committed), you can use git rebase --skip. But only do that if there are nothing to stage for commit.
The last could happen if there was a problem with a rebase prior, and commits was added manually.

You will have to just close this PR as the branch is messed up now and I can't get it to revert cleanly. I'll come back around and do a new PR at some point.

@wsmelton I rebeased it for you, hope you don't mind. Love to get this PR through. 🙂

@wsmelton Missed the question you asked in https://github.com/PowerShell/SqlServerDsc/pull/1208#issuecomment-416920555.
I personally think Reviewable is far superior to GitHub review, and gives you so much more control over the conversations. DSC Resource Kit is using Reviewable, not sure other repositories does. Just last week GitHub added that you can resolve review comments, so they slowly getting better.
The 80 char limit in markdown makes it easier to read the markdown when reviewing the raw files.

How did you get it to reset?

I just ran the commands I posted above, except not pushing dev to your fork since I don't have permission. The rebase replayed your commits over the updated dev branch.

Although. Some commit did not want to stage any changes, so I skipped those commits (the changes was already correct by a previous commit).

Just waiting for the tests to pass, then I merge this.

@wsmelton do you have time to resolve the tests that failed? https://ci.appveyor.com/project/PowerShell/sqlserverdsc/build/9.0.448.0?fullLog=true#L1832

@wsmelton I resolved the problem in the examples files, hopefully the tests passes this time.

Closing and reopening to kick off the tests again, some error unrelated to this change occurred.

@wsmelton this is merged now! Thanks for you help fixing this! 😃


Migrate json rpc middleware stream repo

Explanation

We would like to migrate most MetaMask libraries into core monorepo to make them easier to maintain.
In this PR, we are migrating json-rpc-middleware-stream into core monorepo. In the process of migration, we don't want to remove / loose the original GIT history, but to preserve the history of the library as though the entire project had been located in a merged-packages/json-rpc-middleware-stream directory all along.
We chose to place json-rpc-middleware-stream initially in the merged-packages and not packages so we can hide it from Yarn, ESLint, Prettier, and TypeScript. This allows us to clean it up and conform it to how we've configured this repo before we properly incorporate it.
References

Fixes https://app.zenhub.com/workspaces/shared-libraries-621e46b4d7103800171d1b02/issues/gh/metamask/core/1680
Changelog

@metamask/json-rpc-middleware-stream

Migration: migrating to core monorepo

Checklist

[ ] I've updated the test suite for new or updated code as appropriate
[ ] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
[ ] I've highlighted breaking changes using the "BREAKING" category above as appropriate

Could you update this to include the v5.0.1 commit as well? This looks good aside from that!

Could you update this to include the v5.0.1 commit as well? This looks good aside from that!

Thanks for pointing it out Mark(@Gudahtt ). Done now.


Publishing every packet for Ikea ICTC-G-1

This fixes https://github.com/Koenkk/zigbee2mqtt/issues/1447

Thanks!

Thanks!


Form Foundation

Add common form fields and buttons that are integrated with material-ui and final form

@CarsonF is this one ready for merging? it was in Draft mode and I accidentally marked it as "Ready for Review"

Well I wanted to do a bit more due diligence before merging, but I wanted to at least expose that it's coming.