Error after closing modal

Hey there
I use the no-captcha in my modal dialog, that I open up via angular-bootstrap $modal. After the modal is closed and removed from the DOM, clicking anywhere on the web page throws an error
Error: Permission denied to access property "I4_1430420130990" (property name varies) in script cb=gapi.loaded.
The error will only happen if I actually click on the recaptcha (attempt to obtain a response). Multiple reproductions of this error result in adding, e.g. attempting to validate 2 times will cause 2 errors on every click, 3 times equal 3 errors per click etc.
The captcha itself works properly.
Has anyone encountered something like this?
Thanks

Check out my angular bootstrap test https://vepasto.github.io/angular-no-captcha-test/
If you have different setup, please make a pull request to gh-pages branch

The test has the same issue.
Javascript error is more insightful in Chrome, it says:
Uncaught SecurityError: Blocked a frame with origin "https://www.google.com" from accessing a frame with origin "https://vepasto.github.io". Protocols, domains, and ports must match.
It seems to be a general problem with NoCaptcha API, here is a discussion about it:
https://groups.google.com/forum/#!topic/recaptcha/miaW9qdVIgA
Would it make sense to include some of the proposed workarounds in the lib?

Does version 0.4.3 resolve your issue?

Yes, the new version works flawlessy!
Thank you for promt resolve :)


qbe: patch /tmp to ${TMPDIR:-/tmp} on tests and enable parallel building

Description of changes

Fix the tests on darwin because of /tmp being hardcode.
Enable parallel building

Things done

Built on platform(s)

[X] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[X] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[X] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[X] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[X] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 292660 run on x86_64-linux 1

1 package marked as broken and skipped:

himitsu-firefox

16 packages built:

bonsai
hare
hare.man
hareThirdParty.hare-compress
hareThirdParty.hare-ev
hareThirdParty.hare-json
hareThirdParty.hare-png
hareThirdParty.hare-ssh
hareThirdParty.hare-toml
harec
haredo
haredo.man
himitsu
qbe
treecat
treecat.man

Result of nixpkgs-review pr 292660 run on aarch64-linux 1

1 package marked as broken and skipped:

himitsu-firefox

16 packages built:

bonsai
hare
hare.man
hareThirdParty.hare-compress
hareThirdParty.hare-ev
hareThirdParty.hare-json
hareThirdParty.hare-png
hareThirdParty.hare-ssh
hareThirdParty.hare-toml
harec
haredo
haredo.man
himitsu
qbe
treecat
treecat.man

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/3554


Ghidra global variable not exported

I'm using Ghidra and pwndbg and I don't get my ghidra global variables in .bss in gdb
But I do have the .data global variables in gdb

Interesting, would you happen to have a binary I can test this on?

Still the same problem, and with the newer version event the variables in .data aren't exported

Hey @Dvorhack thanks for the patience. I believe I have fixed this in #72. I tested it on the binary your provided in the discord, attached here. I checked to see if it worked with DAT_001050e8, which is in the .bss.
Binary is
vm.zip
attached for reference.


unchecked block count increasing much more

Description of bug:

Updated my node to v10 https://github.com/nanocurrency/raiblocks/releases/download/V10.0/rai-10.0.0-Linux.tar.xz
Unchecked block count has much increased, in 12 hours it's more than 3000, blocks are always synced +/- 5blocks
Additional information you deem important (e.g. issue happens only occasionally):
Environment:
Linode server ubuntu 16.04
1GB Ram
Single core Intel Xeon E5-2680 v3 (-MCP-) cache: 16384 KB bmips: 5001 speed: 2499 MHz (max)

logs
http://<IP_ADDRESS>/log1.txt
EDIT: added log

Same problem here. 1GB DO droplet with v10 docker nanocurrency/nano. Block count: "count": "6218941", "unchecked": "1309" and increasing (up 7hrs).

Same here, lagging behind 4000 blocks and climbing. Using new v10 node from nanocurrency/nano

Added a log.

Being in sync while still having a display of multiple unchecked blocks seems a common bug. It may have to do with an inconsistency in node.store.unchecked (especially unchecked_count)

same issue here, are u using rai-10.0.0-Linux.tar.xz ?

Same issue here, using v10.0.1 compiled from commit a73ad375a8ac76b94aac735f06d4e6f7b402f91e and rebootstrapped the database.
Had 120k unchecked blocks. Restarting the node seems to reduce the count again.

I am observing the same issue. Compared to v9, the absolute number of unchecked blocks is comparable after a couple of hours, but the v10 node seems to lag behind significantly. After 24h my v10 node was approx. 8000 blocks behind  in terms of block height ( RPC current block) than other nodes on the web (nanode, nanowatch, etc. ). RPC „clear_unchecked“ or restarting the node fixes that issue immediately. When the node is lagging behind I am also seeing constant 280 MBytes/s. disk I/O.

Could it be that it depends on network situation? At the moment in half a day my unchecked count is 14 only.

Maybe, but I did not see a similar pattern with v9. At the time of this post, the block height reported by nanode.co and nanowat.ch differs by approx. 3000 blocks as well ...

Overnight 2000 unchecked blocks and ~5000 behind, nanowat.ch and nanode.co differ ~6000 at time of writing. Sunday evening evening was even worse, I saw ~10'000 differences with nanowat.ch at the low side, restarted mine it climbed slowly up (as it does now after  a restart). But testing a fresh block on nanowat.ch it showed the right info.
I'll use cron for restart every 6 hours I think for the moment.
.

I'm seeing this as well. 7k unchecked blocks.

Made an edit, it's a week now that I don't see it anymore.


fix power automate opensearch integration

Description
Corrects an Opensearch integration mistake with the new Microst Power Automate alerter.
Checklist

[x] I have reviewed the contributing guidelines.
[x] I have included unit tests for my changes or additions.
[x] I have successfully run make test-docker with my changes.
[ ] I have manually tested all relevant modes of the change in this PR.
[N/A] I have updated the documentation.
[x] I have updated the changelog.

Questions or Comments

Hello @jertel
Thanks for the adjustment. All that was missing was the documentation.
`
ms_power_automate_opensearch_discover_color: By default, the alert will be published with the default type blue if not specified. If set to positive, action is displayed with a positive style (typically the button becomes accent color), If set to destructive, Action is displayed with a destructive style (typically the button becomes red)
`


Can't we just reset the localStorage instead of making multiple API calls

Hi, I've used the createSlider method to create the Typeform manually (Like after some action), Here's the sample code:

// For Creating a TypeForm Embed
export const createTypeFormSlider = (typeFormID) => {
  if (typeof window !== 'undefined') {
    const sliderRight = window.tf.createSlider(typeFormID);
    sliderRight.toggle();
    if (document.querySelector('.tf-v1-iframe-wrapper')) {
      document.querySelector('.tf-v1-iframe-wrapper').style.height =
        'calc(100vh - 4.125rem)';
      document.querySelector('.tf-v1-iframe-wrapper').style.marginTop =
        '4.125rem';
    }
  }
};

- The issue is -> it is performing a set of API calls on each action and recreating the localstorage again and again (Instead of just resetting the fields)
Sometimes it is taking a lot of time to boot up the main TypeForm UI

can't we cached these Scripts and reuse them on every action??
Thanks

Hello @Abhishek765Flyfin those JS scripts are required for by your typeform to work. It should be cached by your browser (when you open dev tools in your browser caching might be disabled) and will be loaded from cache on subsequent visits.
Is your embedded typeform performing poorly? Do you have a link where I can have a look?


Improved topic policy validation

Adds a new TopicPolicy interface to allow more fine grained control over topic change events.
This PR only enables support for topic creation policy validation.

Sorry @tomncooper , could you share the KIP link again? I can't find it anywhere. I'll take a look later. Thanks.

So this is a rework of KIP-201 which has a generic policy interface for all topic changes and a lightweight cluster state object for use by the policies.

It's a fair point @showuon, and +1 from me if @tomncooper wants to publish his KIP. But resolving this one will be one of the first question I ask on the [DISCUSS] thread.


Fixed waveform generation always throwing error

The error callback for the waveform generation was not working as a proper callback, but would always throw an error. By coincidence, this was hardly noticable on shorter videos, but very noticable on longer ones.
This fixes the callback. "Generating waveform" should now be displayed up until the waveform shows up, even on longer videos. In case of an error (e.g. when the video has no audio), "Waveform could not be generated" will still show.

Seems to work → merging


Docker Compose for Node not properly finishing the spinup

I tried to spin up my Testsetup in my globalSetup file (JEST) with the following docker-compose.yml:
version: '3.7'

services:
  rabbitmq:
    image: rabbitmq:3-management
    container_name: rabbitmq
    environment:
      RABBITMQ_DEFAULT_USER: test
      RABBITMQ_DEFAULT_PASS: test
    volumes:
      - './rabbitmq/etc/:/etc/rabbitmq/'
      - './rabbitmq/etc/definitions.json:/etc/rabbitmq/definitions.json:ro'
    ports:
      - 5672
      - 15672
      - 25672
  api:
    image: gcr.io/gke-utility/mocks
    container_name: api
    ports:
      - 5000
    command: api/v1.yaml

This is just to ensure my dependencies for the service i want to Test.
Global Setup file
import { Duration, TemporalUnit } from 'node-duration'
import { DockerComposeEnvironment, StartedTestContainer } from 'testcontainers'
import path = require('path')

export default async (): Promise<void> => {
  const composeFilePath: string = path.basename('../.docker')
  const composeFile = 'docker-compose.yml'
  const environment = await new DockerComposeEnvironment(composeFilePath, composeFile)
    .withStartupTimeout(new Duration(200, TemporalUnit.SECONDS))
    .up()

  const rabbitmq: StartedTestContainer = environment.getContainer('rabbitmq')
  const bully: StartedTestContainer = environment.getContainer('bully')

  // THE REST OF THE SETUP

}

The following problem occurs after the timeout:
$ NODE_ENV=test jest --config=__integration-tests__/jest.config.js --testRunner='jest-circus/runner' --ci --verbose --maxWorkers=7 Error: Port 5671 not bound after 200000ms     at /PATH_TO_PROJECT/node_modules/testcontainers/dist/wait-strategy.js:61:23     at IntervalRetryStrategy.<anonymous> /PATH_TO_PROJECT/node_modules/testcontainers/dist/retry-strategy.js:37:28)     at Generator.next (<anonymous>)     at fulfilled (/PATH_TO_PROJECT/testcontainers/dist/retry-strategy.js:5:58)     at processTicksAndRejections (internal/process/task_queues.js:85:5) error Command failed with exit code 1. info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
The problem occurs on binding the service Ports, for RabbitMQ, additionally
Project structure of the IT:

The two containers are started properly (see container Overview here)

What can i do to get to get this running properly, i would love to use this for the service dependency configuration, especially because the rabbitMQ Preconfiguration over definitions.json would be awesome.

Hi @aixellent, could you confirm what version of testcontainers you're using?

Hi @cristianrgreco , sorry I missed you lift this up, I am using 3.4.4.

I think the problem is that rabbitmq doesn't bind to all the ports it exposes. The default wait strategy of testcontainers is to wait until all of the container's exports are bound. Could you try the log wait strategy instead and let me know if it fixes this issue?
const environment = await new DockerComposeEnvironment(composeFilePath, composeFile)
  .withWaitStrategy("rabbitmq", Wait.forLogMessage("Server startup complete"))
  .withStartupTimeout(new Duration(200, TemporalUnit.SECONDS))
  .up()

I will try this asap and update you here, but the interesting part is that all 3 ports are available for use if I call them manually over my tools.

@aixellent Sure let me know 🙂
Running rabbit locally I see it exposes 5 ports, I'd need to double check but I assume by default it doesn't bind all of them

@cristianrgreco
Thanks a lot, I tried your approach and it worked for my dependency Tools (API / rabbitMQ) right now, but wouldn´t it good if we can have a similar behaviour like when we use it for DEV reasons on the local machine? My problem now is that the Service container does not work with this WaitMechanism.
I know that since version 3 of compose it is not that easy to use a manually defined startup order: https://docs.docker.com/compose/startup-order/ so that containers really wait for other containers.
I tried the Wait for Log strategy for our service container too, but this does not work as it starts the container parallel to the rabbit what causes a error in the service startup.
yarn run v1.22.5 $ NODE_ENV=test jest --config=__integration-tests__/jest.config.js --testRunner='jest-circus/runner' --ci --verbose --maxWorkers=7 Error: (HTTP code 409) unexpected - Container 8169527d30c69904fbfc5c93db08cd122eac27b878890a333bdbbfe3e0a279f7 is not running     at /THE_SERVICE/node_modules/docker-modem/lib/modem.js:301:17     at getCause (/THE_SERVICE/node_modules/docker-modem/lib/modem.js:331:7)     at Modem.buildPayload (/THE_SERVICE/node_modules/docker-modem/lib/modem.js:300:5)     at IncomingMessage.<anonymous> (/THE_SERVICE/node_modules/docker-modem/lib/modem.js:275:14)     at IncomingMessage.emit (events.js:208:15)     at endReadableNT (_stream_readable.js:1168:12)     at processTicksAndRejections (internal/process/task_queues.js:77:11) error Command failed with exit code 1.
What means that the container breaks the UP of the testcontainers flow. Is there anything i can do here? The container just includes a small node application which on startup connects to the RMQ.
If this is not possible to pipe it properly i can live with it and create the service container from dockerfile or manually by generic container structure.

Hi @aixellent, I think there are a couple options here:

Change the service so that if the connection fails it retries (recommended by Docker https://docs.docker.com/compose/startup-order/):

The problem of waiting for a database (for example) to be ready is really just a subset of a much larger problem of distributed systems. In production, your database could become unavailable or move hosts at any time. Your application needs to be resilient to these types of failures.
To handle this, design your application to attempt to re-establish a connection to the database after a failure. If the application retries the connection, it can eventually connect to the database.
The best solution is to perform this check in your application code, both at startup and whenever a connection is lost for any reason.

For a GenericContainer, we're able to use a HealthCheck wait strategy as follows:

.withHealthCheck({
  test: "curl -f http://localhost || exit 1",
  interval: new Duration(1, TemporalUnit.SECONDS),
  timeout: new Duration(3, TemporalUnit.SECONDS),
  retries: 5,
  startPeriod: new Duration(1, TemporalUnit.SECONDS)
})
.withWaitStrategy(Wait.forHealthCheck())
.start();

This isn't supported yet for docker-compose but would something like this solve the problem if you were able to use it as the wait strategy for the service container? I'm thinking the health check would be the service trying to connect to rabbit and it could try a number of times over a time period

@cristianrgreco
Thanks for this advice, i tried the first option, but if it fails once, it breaks the cycle, the only difference is the follwoing
yarn run v1.22.5
$ NODE_ENV=test jest --config=__integration-tests__/jest.config.js --testRunner='jest-circus/runner' --ci --verbose --maxWorkers=7
Error: (HTTP code 409) unexpected - Container 8169527d30c69904fbfc5c93db08cd122eac27b878890a333bdbbfe3e0a279f7 **is restarting**
    at /THE_SERVICE/node_modules/docker-modem/lib/modem.js:301:17
    at getCause (/THE_SERVICE/node_modules/docker-modem/lib/modem.js:331:7)
    at Modem.buildPayload (/THE_SERVICE/node_modules/docker-modem/lib/modem.js:300:5)
    at IncomingMessage.<anonymous> (/THE_SERVICE/node_modules/docker-modem/lib/modem.js:275:14)
    at IncomingMessage.emit (events.js:208:15)
    at endReadableNT (_stream_readable.js:1168:12)
    at processTicksAndRejections (internal/process/task_queues.js:77:11)
error Command failed with exit code 1.

But no problem with that, i got it working with 2 COMPOSE Files, one for the dependencies and one for the service, they are bound over a network together so they can interact without problems.
But NOW i have the following problem on TEARDOWN
 PASS  __integration-tests__/__tests__/health.test.ts
  Integration tests
    ✓ TC 0: Health Endpoint check (35ms)

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        0.978s, estimated 2s
Ran all test suites.
jest-html-reporter >> Report generated (/Users/schmitz/Development/Projects/shop-apotheken-offer-adapter/test-report.html)

All tests passed

__tests__/health.test.ts
  Integration tests
    ✓ TC 0: Health Endpoint check

{"level":"warn","message":"🧨 Tear down Integration Test Environment 🧨","module_name":"the-service","module_version":"0.0.1","timestamp":"2020-09-21T10:07:11.688Z"}
Stopping rabbitmq ... done
Stopping api    ... done
Found orphan containers (the-service) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up.
Removing rabbitmq ... done
Removing api    ... done
Removing network __mocks___default
error while removing network: network __mocks___default id c378a1b6d8ef386a99beb2f6e439b246299c92504b1596f680170df50e704f34 has active endpoints
    at StartedDockerComposeEnvironment.<anonymous> (/path/Development/Projects/the-service/node_modules/testcontainers/dist/docker-compose-environment.js:158:23)
    at Generator.throw (<anonymous>)
    at rejected (/path/Development/Projects/the-service/node_modules/testcontainers/dist/docker-compose-environment.js:25:65)
    at processTicksAndRejections (internal/process/task_queues.js:85:5)
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Is there a possibility to kill the network o.e. a container which dows not stop properly (as this is just for a testcycle)

@aixellent Apologies just a few questions so I'm sure I understand correctly:

i tried the first option, but if it fails once, it breaks the cycle

What's meant by it breaks the cycle? My understanding is:

We have a rabbit container which takes a while to start up
We have a service container that tries to connect to rabbit immediately. Rabbit isn't ready at this point which causes this container to fail to start.

If this is the case, then I was suggesting that the service container continually retries to connect to rabbit until it is ready. If it does this then as long as rabbit comes up successfully, both containers will eventually start successfully.
If this change isn't possible then do you think the health check wait strategy I proposed in the previous comment would solve the problem?

@cristianrgreco
Sorry for the confusion, my bad.
I tried the approach here: https://github.com/testcontainers/testcontainers-node/issues/133#issuecomment-695332527 which is working fine for the dependencies (rabbit & API) now.
Then i thought about how to fix the problem with the SERVICE Container which needs to either wait for the rabbit to be ready OR to reconstruct the startup mechanism of it for facing this problem.
Waiting is not possible easily with docker compose as you said, so this option has gone. The second approach is not feasible either, why? Because our K8s Strategy says that we should BREAK the service on errors so it can be restarted by the orchestrator, so the service design could not be adapted here only for testreasons (maybe it could by ENVs but we internally agreed on that this is quite bad smell stuff). So i configured the service in the compose file with restart:always what did the restart part you described, BUT initially it fails and breaks the spinup and delivers the following message:
yarn run v1.22.5
$ NODE_ENV=test jest --config=__integration-tests__/jest.config.js --testRunner='jest-circus/runner' --ci --verbose --maxWorkers=7
Error: (HTTP code 409) unexpected - Container 8169527d30c69904fbfc5c93db08cd122eac27b878890a333bdbbfe3e0a279f7 **is restarting**

So i came to the point that i outsourced the SERVICE to a second compose file which is started sequentially after RABBIT and API have been spinned up successfully (with the help of your WaitForLog proposal)

That is working quite fine, as the services are bound over a network i only have one problem left, on globalTeardown the service container / service container compose environment cannot be stopped / downed because of the network which is automatically created with the name __mocks___default refuses this as it says that there are active connections left.
Error:
 PASS  __integration-tests__/__tests__/health.test.ts
  Integration tests
    ✓ TC 0: Health Endpoint check (35ms)

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        0.978s, estimated 2s
Ran all test suites.
jest-html-reporter >> Report generated (/pathProjects/the-service/test-report.html)

All tests passed

__tests__/health.test.ts
  Integration tests
    ✓ TC 0: Health Endpoint check

{"level":"warn","message":"🧨 Tear down Integration Test Environment 🧨","module_name":"the-service","module_version":"0.0.1","timestamp":"2020-09-21T10:07:11.688Z"}
Stopping rabbitmq ... done
Stopping api    ... done
Found orphan containers (the-service) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up.
Removing rabbitmq ... done
Removing api    ... done
Removing network __mocks___default
error while removing network: network __mocks___default id c378a1b6d8ef386a99beb2f6e439b246299c92504b1596f680170df50e704f34 has active endpoints
    at StartedDockerComposeEnvironment.<anonymous> (/path/Development/Projects/the-service/node_modules/testcontainers/dist/docker-compose-environment.js:158:23)
    at Generator.throw (<anonymous>)
    at rejected (/path/Development/Projects/the-service/node_modules/testcontainers/dist/docker-compose-environment.js:25:65)
    at processTicksAndRejections (internal/process/task_queues.js:85:5)
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

So the question from my side would be, will there be an option to pass params like --remove-orphans or --rmi type in the future? I know this looks dirty too, but in some cases this would be a great feature.

I ran a test locally with --remove-orphans but it still fails to stop docker-compose because the network is in use.
According to the docs:

docker-compose stop: The docker-compose stop command will stop your containers, but it won’t remove them.
docker-compose down: The docker-compose down command will stop your containers, but it also removes the stopped containers as well as any networks that were created.

This means that if you have two running docker-composes sharing a network, and you down one of them, docker will try to kill the network, which is in use, and will fail.
Based on this, I think what we might want to do is:

docker-compose up the dependencies
docker-compose up the service
docker-compose stop the service
docker-compose down the dependencies.

What do you think?

@cristianrgreco
That idea will fit the needs more properly, but therefore the DockerEnvironment should get the stop option or the down option runs stop at first for all services in the environment.
As said i actually found a solution by manually chain the TearDown in Promises so that it does not throw exceptions, but this would be really nice to have.

Hey @aixellent, take a look at the referenced PR - unless you see any issues with it I'll release 🙂

Hi @cristianrgreco ,
Approved your PR, thanks for the support and the fast implementation.
🎉 Everything running properly now

@aixellent Thanks for raising the issue, this has been released in 4.1.0 🙂


Minor LMP reference manual cleanups

Docs for 57d5b9e4e135360f6fdf15d126fb277990abb1ba are browesable at: https://ci.foundries.io/projects/fio-docs/builds/715/docs/artifacts/html/index.html


Add check for no rde before getting the RDE entity type version

Signed-off-by: Aniruddha Shamasundar<EMAIL_ADDRESS>Description
Please provide a brief description of the changes proposed in this Pull Request

Get the entity type version of the RDE only if it doesn't have NO_RDE prefix

Checklist

[x] tested locally
[x] updated any relevant dependencies
[ ] updated any relevant documentation or examples - N/A

API Changes
Are there API changes?

[ ] Yes
[x] No

If yes, please fill in the below

Updated conversions?

[ ] Yes
[ ] No
[ ] N/A

Updated CRDs?

[ ] Yes
[ ] No
[ ] N/A

Updated infrastructure-components.yaml?

[ ] Yes
[ ] No
[ ] N/A

Updated ./examples/capi-quickstart.yaml?

[ ] Yes
[ ] No
[ ] N/A

Updated necessary files under ./infrastructure-vcd/v1.0.0/?

[ ] Yes
[ ] No
[ ] N/A

Issue
If applicable, please reference the relevant issue
Fixes #

This change is

controllers/vcdcluster_controller.go line 540 at r1 (raw file):
Previously, arunmk (Arun M. Krishnakumar) wrote…
Yes, I believe that is the intent. We don't need to get the version of the RDE if it is a NO_RDE kind.
@anirudh9794 in the case of NO_RDE, can we set vcdCluster.Status.RdeVersionInUse to NO_RDE? Will it break anything else? This is mainly for completeness and not to have missing fields or empty fields.

I think it should be alright to set RdeVersionInUse to "NO_RDE". I will run a few tests and update the PR.


Feature: add links to GitHub and NPM

Git adds the link to the GitHUb repo when a push has completed.
$ git push -u origin master
Enumerating objects: 112, done.
Counting objects: 100% (112/112), done.
Delta compression using up to 4 threads.
Compressing objects: 100% (95/95), done.
Writing objects: 100% (112/112), 555.16 KiB | 4.37 MiB/s, done.
Total 112 (delta 23), reused 0 (delta 0)
remote: Resolving deltas: 100% (23/23), done.
To https://github.com/nidkil/vue-test-plugin.git
 * [new branch]      master -> master
Branch 'master' set up to track remote branch 'master' from 'origin'.

In Webstorm and some consoles this link is clickable, which makes it very easy to go to the repo and do a quick check. It would be cool if release-it could add links to GitHub and NPM when the release process completes succsfully. Can I put in a pull request?

I was thinking about exactly the same thing, so your PR is very welcome! Thanks in advance.

Okay I will have a look at it.

I have submitted 3 pull requests for this issue.

In v9.2.0.


Feature Request for avatars-avataaars-sprites

Would it be possible to add a gender parameter for this specific library?
Thanks,
Mark

There has been such a request before. Have a look at #21.


Behavior for tci_type differs between Stash Measurement calls and Invoke DPE calls for Derive Context

We have 3 ways of handling incoming measurements that eventually become a Derive Context call to DPE.

Stash measurement called during ROM
Stash measurement called during RT
RT call to invoke DPE for derive context

In cases 1 and 2 (both stash measurement cases) the tci_type endianness is maintained. The LSB of the type dword is the LSB when it's sent back in the cert.
In case 3, the endianness is seen as flipped in the cert.
In the following test output, each of those scenarios is tried in order. Then, a certify key command is issued and the responding cert is dumped.
ROM Stash (raw cmd payload):
[4, 253, 255, 255, 101, 102, 103, 104, 1, 2, 3, 4, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2, 3, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
RT stash (raw cmd payload):
[220, 252, 255, 255, 101, 102, 103, 104, 1, 2, 3, 4, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 1, 2, 3, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
RT invoke DPE - Derive Context (raw cmd payload):
[46, 251, 255, 255, 88, 0, 0, 0, 67, 69, 80, 68, 8, 0, 0, 0, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 2, 3, 4, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 1, 2, 3, 4, 0, 0, 0, 18, 101, 102, 103, 104, 0, 0, 0, 0]
Certify key response cert (tci_type is highlighted, it's just a little hard to see)
[48, 130, 5, 177, 6, 9, 42, 134, 72, 134, 247, 13, 1, 7, 2, 160, 130, 5, 162, 48, 130, 5, 158, 2, 1, 3, 49, 13, 48, 11, 6, 9, 96, 134, 72, 1, 101, 3, 4, 2, 2, 48, 130, 4, 228, 6, 9, 42, 134, 72, 134, 247, 13, 1, 7, 1, 160, 130, 4, 213, 4, 130, 4, 209, 48, 130, 4, 205, 48, 130, 4, 83, 2, 1, 0, 48, 94, 49, 17, 48, 15, 6, 3, 85, 4, 3, 19, 8, 68, 80, 69, 32, 76, 101, 97, 102, 49, 73, 48, 71, 6, 3, 85, 4, 5, 19, 64, 56, 56, 55, 70, 70, 65, 53, 56, 48, 69, 70, 57, 54, 66, 68, 65, 68, 48, 55, 57, 49, 69, 69, 57, 55, 53, 68, 54, 55, 66, 54, 50, 54, 53, 57, 53, 48, 70, 54, 68, 48, 57, 54, 53, 48, 57, 68, 49, 69, 70, 52, 56, 51, 57, 56, 67, 51, 65, 52, 56, 55, 65, 52, 69, 48, 118, 48, 16, 6, 7, 42, 134, 72, 206, 61, 2, 1, 6, 5, 43, 129, 4, 0, 34, 3, 98, 0, 4, 84, 129, 214, 60, 195, 45, 111, 32, 114, 254, 254, 59, 46, 179, 118, 135, 245, 45, 180, 104, 54, 238, 146, 148, 45, 141, 225, 208, 213, 239, 73, 62, 200, 62, 179, 161, 176, 223, 80, 126, 84, 205, 14, 47, 91, 36, 5, 164, 68, 85, 226, 91, 179, 198, 246, 54, 88, 50, 119, 16, 82, 100, 20, 50, 38, 52, 27, 166, 101, 32, 191, 55, 14, 109, 122, 184, 38, 204, 225, 70, 94, 137, 217, 145, 147, 96, 199, 164, 102, 136, 101, 163, 144, 147, 197, 35, 160, 130, 3, 116, 48, 130, 3, 112, 6, 9, 42, 134, 72, 134, 247, 13, 1, 9, 14, 49, 130, 3, 97, 48, 130, 3, 93, 48, 130, 2, 222, 6, 6, 103, 129, 5, 5, 4, 5, 1, 1, 255, 4, 130, 2, 207, 48, 130, 2, 203, 48, 129, 140, 166, 126, 48, 61, 6, 9, 96, 134, 72, 1, 101, 3, 4, 2, 2, 4, 48, 238, 7, 164, 186, 211, 194, 3, 233, 60, 238, 228, 144, 35, 99, 199, 152, 236, 17, 133, 44, 158, 121, 179, 31, 255, 139, 179, 9, 99, 252, 28, 248, 57, 75, 195, 137, 94, 47, 169, 160, 20, 214, 175, 253, 221, 108, 212, 62, 48, 61, 6, 9, 96, 134, 72, 1, 101, 3, 4, 2, 2, 4, 48, 229, 136, 236, 172, 122, 100, 72, 171, 227, 9, 211, 19, 169, 124, 50, 15, 239, 91, 22, 161, 80, 192, 8, 104, 15, 5, 18, 69, 82, 246, 155, 76, 184, 200, 251, 219, 194, 101, 142, 152, 26, 116, 34, 3, 241, 179, 203, 127, 136, 4, 255, 255, 255, 255, 137, 4, 82, 84, 74, 77, 48, 129, 140, 166, 126, 48, 61, 6, 9, 96, 134, 72, 1, 101, 3, 4, 2, 2, 4, 48, 25, 175, 16, 114, 168, 194, 94, 20, 254, 167, 80, 226, 172, 238, 158, 142, 36, 229, 1, 19, 54, 130, 171, 218, 97, 190, 54, 108, 2, 84, 195, 77, 30, 16, 137, 162, 28, 214, 202, 72, 47, 127, 51, 69, 220, 79, 193, 50, 48, 61, 6, 9, 96, 134, 72, 1, 101, 3, 4, 2, 2, 4, 48, 131, 204, 62, 211, 226, 39, 74, 82, 156, 22, 231, 64, 8, 43, 47, 79, 252, 96, 41, 55, 238, 116, 171, 105, 106, 179, 194, 180, 124, 131, 190, 15, 172, 120, 131, 44, 186, 201, 146, 26, 236, 231, 158, 94, 189, 219, 133, 88, 136, 4, 0, 0, 0, 1, 137, 4, 77, 66, 86, 80, 48, 129, 140, 166, 126, 48, 61, 6, 9, 96, 134, 72, 1, 101, 3, 4, 2, 2, 4, 48, 1, 2, 3, 4, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2, 3, 4, 48, 61, 6, 9, 96, 134, 72, 1, 101, 3, 4, 2, 2, 4, 48, 243, 152, 188, 139, 115, 26, 39, 9, 147, 210, 112, 34, 25, 174, 216, 127, 224, 193, 96, 180, 76, 219, 167, 28, 89, 100, 64, 72, 118, 242, 5, 41, 169, 45, 144, 158, 194, 121, 35, 194, 189, 107, 206, 116, 232, 6, 239, 193, 136, 4, 0, 0, 0, 1, 137, 4, 101, 102, 103, 104, 48, 129, 140, 166, 126, 48, 61, 6, 9, 96, 134, 72, 1, 101, 3, 4, 2, 2, 4, 48, 1, 2, 3, 4, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 1, 2, 3, 4, 48, 61, 6, 9, 96, 134, 72, 1, 101, 3, 4, 2, 2, 4, 48, 158, 79, 43, 49, 218, 195, 162, 29, 80, 194, 239, 202, 177, 82, 25, 144, 182, 79, 252, 127, 188, 129, 12, 10, 23, 170, 108, 144, 162, 30, 244, 145, 164, 203, 115, 133, 208, 149, 183, 202, 222, 115, 15, 154, 119, 83, 242, 55, 136, 4, 0, 0, 0, 1, 137, 4, 101, 102, 103, 104, 48, 129, 140, 166, 126, 48, 61, 6, 9, 96, 134, 72, 1, 101, 3, 4, 2, 2, 4, 48, 1, 2, 3, 4, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 1, 2, 3, 4, 48, 61, 6, 9, 96, 134, 72, 1, 101, 3, 4, 2, 2, 4, 48, 85, 18, 56, 119, 246, 230, 111, 223, 154, 129, 241, 131, 165, 244, 54, 192, 96, 249, 61, 48, 171, 230, 85, 230, 219, 161, 29, 14, 139, 129, 20, 161, 19, 14, 212, 79, 160, 202, 38, 205, 208, 59, 20, 240, 107, 75, 107, 199, 136, 4, 0, 0, 0, 1, 137, 4, 104, 103, 102, 101, 48, 65, 6, 6, 103, 129, 5, 5, 4, 4, 1, 1, 255, 4, 52, 48, 50, 4, 48, 48, 47, 46, 45, 44, 43, 42, 41, 40, 39, 38, 37, 36, 35, 34, 33, 32, 31, 30, 29, 28, 27, 26, 25, 24, 23, 22, 21, 20, 19, 18, 17, 16, 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 48, 15, 6, 3, 85, 29, 19, 1, 1, 255, 4, 5, 48, 3, 1, 1, 0, 48, 14, 6, 3, 85, 29, 15, 1, 1, 255, 4, 4, 3, 2, 7, 128, 48, 21, 6, 3, 85, 29, 37, 1, 1, 255, 4, 11, 48, 9, 6, 7, 103, 129, 5, 5, 4, 100, 9, 48, 10, 6, 8, 42, 134, 72, 206, 61, 4, 3, 3, 3, 104, 0, 48, 101, 2, 49, 0, 197, 24, 216, 155, 83, 96, 81, 165, 248, 160, 165, 119, 112, 206, 74, 206, 3, 50, 37, 8, 76, 139, 105, 87, 241, 153, 197, 193, 206, 13, 197, 80, 178, 6, 182, 170, 111, 238, 202, 30, 118, 124, 89, 65, 38, 87, 20, 183, 2, 48, 5, 224, 154, 194, 231, 26, 45, 60, 42, 250, 18, 99, 196, 78, 213, 203, 75, 200, 12, 205, 12, 214, 21, 190, 48, 229, 140, 137, 67, 17, 241, 202, 240, 220, 182, 9, 86, 75, 46, 168, 108, 192, 80, 126, 229, 200, 189, 102, 49, 129, 161, 48, 129, 158, 2, 1, 3, 128, 22, 4, 20, 240, 18, 244, 89, 32, 97, 219, 246, 221, 200, 2, 176, 108, 35, 112, 68, 228, 190, 20, 113, 48, 11, 6, 9, 96, 134, 72, 1, 101, 3, 4, 2, 2, 48, 10, 6, 8, 42, 134, 72, 206, 61, 4, 3, 3, 4, 104, 48, 102, 2, 49, 0, 189, 146, 119, 71, 225, 149, 54, 229, 197, 60, 9, 124, 142, 83, 111, 244, 250, 82, 7, 138, 96, 124, 162, 83, 153, 23, 121, 160, 64, 101, 159, 31, 114, 239, 39, 35, 108, 124, 231, 75, 26, 229, 133, 129, 191, 32, 152, 7, 2, 49, 0, 139, 45, 134, 117, 153, 65, 6, 107, 3, 34, 181, 143, 235, 251, 26, 173, 77, 214, 244, 95, 34, 20, 134, 103, 203, 215, 155, 47, 126, 85, 17, 136, 253, 253, 132, 249, 159, 70, 133, 242, 202, 210, 218, 86, 59, 252, 250, 175, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

This endianness is flipped in 3 places (when being treated as big endian while being copied)

When handling stashed info from ROM. ONLY affects ROM stash measurement. https://github.com/chipsalliance/caliptra-sw/blob/593c9bd2e672421b9ad5f30e8872b57152a5d9d8/runtime/src/drivers.rs#L459
When handling a stash measurement call during runtime. ONLY affects runtime stash measurement. https://github.com/chipsalliance/caliptra-sw/blob/593c9bd2e672421b9ad5f30e8872b57152a5d9d8/runtime/src/stash_measurement.rs#L81
In DPE when copying to the cert. Affects ALL 3 cases. https://github.com/chipsalliance/caliptra-dpe/blob/f06e88caa2e9d1407160d2fc677293b013fe6a0f/dpe/src/x509.rs#L1249

The result is the endianness is flipped twice for stash measurement calls and thus maintained. In the invoke DPE with derive context call, the endianness is flipped when comparing sending the data vs receiving it.
I would argue all three of these cases where flipping occurs should be removed so the endianness is maintained and no assumptions are being made for the use of this 4 byte field.

Thanks @nquarton! I agree with removing all of these cases and just maintaining endianness passed from the caller.

Talked with Nick, we should also add a test to ensure that the resulting cert measurement is the same from all 3 ways of making a measurement:

DeriveContext via INVOKE_DPE command
STASH_MEASUREMENT called during ROM
STASH_MEASUREMENT called during RT


feat(netlify-cms-core): expose loadEntry action to Widgets

Summary
As commented on #1928 this is an attempt to break down the work needed to implement that feature on the "userland", this lifts the backwards-compatible requirement for implementing it.
As there are not many tests on that feature is hard to implement it right now as it changes the underlying implementation besides adding the new feature.
I intend to provide a third-party module for achieving what is described on the PR, including the custom UI, it's also a better way to test the API before committing to it on the core (:
PS: the contents of this PR are rebased and linted changes made originally on 974fc3d
A picture of a cute animal (not mandatory but encouraged)

Let's give it a go 👍


Allow RequestHandler type to return undefined

Fixes sveltejs/kit#1018
Very simple change, not sure how to write a test for a typescript type change only...
Feel free to delete this if more involved then it looks.
Before submitting the PR, please make sure you do the following

[ ] It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
[ ] This message body should clearly illustrate what problems it solves.
[ ] Ideally, include a test that fails without this PR but passes with it.

Tests

[ ] Run the tests with pnpm test and lint the project with pnpm lint

Changesets

[ ] If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpx changeset and following the prompts

thank you!


Significant performance regression since 1.1.0

I've observed very nasty performance regression between v1.0.1 and v1.1.0, causing on average x2 CPU usage in one application, and with localised impact even greater in various situations.
I'll post some benchmarks when I get the chance, but posting this in the meantime to give an early heads up.

v1.1 added some new checks, which invariably take more time to perform. Specifically, robust cross-realm date and regex checks (via is-date-object and is-regex) are likely the culprit.
v2 will have even more robust cross-realm checks, so it matches node core.
I'm very interested in improving performance, but only where it won't sacrifice correctness. Benchmarks would be helpful.

Here's a simple benchmark that tests deep equal checks on an object 4 levels deep with 3 keys at each level:
#!/usr/bin/env node

const equal110 = require('deep-equal-110');
const equal101 = require('deep-equal-101');
const ldIsEqual = require('lodash/isEqual');

const Benchmark = require('benchmark');

const suite = new Benchmark.Suite();

function makeDeepObj(width, depth, value) {
    if (depth < 1) {
        return val;
    }

    const d = {};
    for (let m = 0; m < width; m += 1) {
        d[m] = makeDeepObj(width, depth - 1, value);
    }
    return d;
}
const data = makeDeepObj(3, 4, 'cat');
const data2 = makeDeepObj(3, 4, 'cat');

suite
    // Add tests.
    .add('node-deep-equal 1.0.1', function() {
        equal101(data, data2);
    })
    .add('node-deep-equal 1.1.0', function() {
        equal110(data, data2);
    })
    .add('lodash-is-equal', function() {
        ldIsEqual(data, data2);
    })
   // Add listeners.
    .on('cycle', function(event) {
        console.log(String(event.target));
    })
    .on('complete', function() {
        console.log('Fastest is ' + this.filter('fastest').map('name'));
    })
    // Run async.
    .run({ 'async': true });

Results:
node-deep-equal 1.0.1 x 24,842 ops/sec ±1.42% (85 runs sampled)
node-deep-equal 1.1.0 x 1,609 ops/sec ±0.78% (74 runs sampled)
lodash-is-equal x 16,015 ops/sec ±0.52% (89 runs sampled)
Fastest is node-deep-equal 1.0.1

Changing the second 'cat' to 'catfish' for unequal object check gives:
node-deep-equal 1.0.1 x 278,097 ops/sec ±1.56% (86 runs sampled)
node-deep-equal 1.1.0 x 17,237 ops/sec ±0.92% (55 runs sampled)
lodash-is-equal x 162,234 ops/sec ±0.67% (84 runs sampled)
Fastest is node-deep-equal 1.0.1

Twiddling the width and depth parameters gives different results for node-deep-equal vs lodash isEqual, however in terms of node-deep-equal v1.0.1 vs 1.1.0, 1.1.0 is always significantly slower in my tests.

What would be most helpful is using git bisect to figure out which commit(s) specifically impact performance.
Again, correctness is paramount - always much more important than performance - so I'll want to ensure we maintain v1.1's correctness fixes while improving performance.

Hi! I met the same issue. For me it comes from is-date-object library. Where is it calling tryDateObject on each object what is going through deep-equal. I'm losing there xx seconds so I had to downgrade to version 1.0.1.

@sionzeecz I don't think it makes sense to add a bunch of options for each type of thing that's checked; there's a similar check for every builtin object type (with more coming in v2). Correctness, not performance, is most important.
I'm very happy to review PRs that improve performance without sacrificing correctness.

I'm going to close this - I will continue to support both the v1.0 and v1.1 minor lines for the foreseeable future; v2.0 will be out shortly. It's highly likely that v1.1 and v2+ will be slower than v1.0, because as node's assert.deepEqual and assert.deepStrictEqual have added features, so must we.
I will accept "performance improvements that do not sacrifice correctness" and backport them to any minor lines that I can; I will accept bugfixes to any minor line as well (but many fixes couldn't go into v1.0 without causing the same perf issues).

I was using this package because it was performing great speed. At my application i'm comparing thousands things at same time.
I will stay at 1.x. Thank you for keeping alive old versions.

Totally reasonable choice :-) this package's primary goal is to match node's assert in a portable way, however.


Auto-import curation

Discovery script run on 15/3/2023
curate projects:

[x] Single-Cell RNA Sequencing Reveals the Effects of Chemotherapy on Human Pancreatic Adenocarcinoma and its Tumor Microenvironment
[x] Lineage tracing reveals fate bias and transcriptional memory in human B cells

Discovery script run on 19/4/2023

[x] Single-cell sequencing of human white adipose tissue identifies new cell states in health and obesity
[x] Mapping hormone-regulated cell-cell interaction networks in the human breast at single-cell resolution
[x] Single-cell Transcriptomic Analysis of Systemic Autoinflammatory Diseases with Anti-TNFα Therapy
[x] Integration of single-cell multiomic measurements across disease states with genetics identifies mechanisms of beta cell dysfunction in type 2 diabetes
[x] Astrocytic cell adhesion genes linked to schizophrenia correlate with synaptic programs in neurons
[x] Ex vivotissue perturbations coupled to single cell RNA-seq reveal multi-lineage cell circuit dynamics in human lung fibrogenesis
[x] Adenomyosis: single-cell transcriptomic analysis reveals a paracrine mesenchymal–epithelial interaction involving the WNT/SFRP pathway
[x] An integrated single cell and spatial transcriptomic map of human white adipose tissue

Completed this. Made notes for any in doubt areas


WebView does not scale correctly when monitors have different scaling

Describe the bug
The WebView / Browser / Viewer part of the editor does not scale correctly on one of the monitors and is zoomed in.
To Reproduce
Steps to reproduce the behavior:

Setup requires 2 monitors. On my setup I have one at 100% scaling and the other at 150%.
Open Visual Studio 2022 and open a markdown file.
Observe one monitor display the correct zoom level (as well as correct size for the split between editor and viewer which is 50/50 by default) on 150% scale monitor.
Move Visual Studio to the other monitor and observe that viewer is zoomed in and now occupies more than half of the editor screen.

Expected behavior
The zoom level and the split size to be the same regardless of monitor and scaling settings.
Screenshots

Additional context
I realize this issue is not top priority and probably not the easiest fix in the world, since the base scaling settings are probably inside visual studio itself (which also doesn't scale some dialogs properly at times).
There are 2 properties within WebView2 that could potentially be used to fight/fix this issue
corewebview2controller.rasterizationscale
corewebview2controller.zoomfactor
If I have time in the near future will look at potentially fixing this myself, but if someone know exactly where the problem is and how to fix it, please do!

Is the using the latest version from the CI build? That version now has WebView2 instead of IE and that might have solved the issue

Ok so it no longer zooms in with WebView2! Awesome.
It still changes the split screen from 50/50 to about 30/70, which would be nice to solve, however not critical.


4.0.0 Release

The next major release 4.0.0 of tailor must have these below listed features. These features were used at Zalando and its much more performant than the open source version. So its time to upstream those changes

[x] drop node 6 support
[ ] Should use Keep alive agents (https://github.com/node-modules/agentkeepalive)
[ ] Caching of fragments either by using the Id and URL or through cache-control headers
[ ] Logging and Metrics(Fragment TTFB, TTLB) that are based on tailor event system
[ ] System level metrics like IO/CPU which can be made available via child process
[ ] Template caching on bootup ( Super easy for File system, Probably for now we can skip if its a remote endpoint and have to take care of update mechanism to be generic)
[ ] Circuit breakers pool for each fragment
[ ] Agent pooling (https://github.com/vigneshshanmugam/agent-pool/)
[ ] Reporting Browser metrics that are captured via Tailor performance hooks (https://github.com/zalando/tailor/blob/master/docs/hooks.md)

If anyone wants to pick it up specific taks, Let me know.. I can give more context...

@franz-josef-kaiser Sure, Please provide ideas on the issue on what you want the behaviour to be when the obligatory ones fail and whether its applicable only for primary or all the fragments.

any progress on this?

Was bit busy with other things, I will come back to working on this in few days.

Hello @vigneshshanmugam, I've talked to you on Twitter a few days back, we've agreed that I'll create an issue and we'll discuss details here. However, I don't want to duplicate existing issues, and pretty much all of issues or lack of features we've experienced are listed here. So I'm commenting here, let me know if you still prefer separate thread for our support.
Features we are craving for in Tailor:

keep-alive connection for fragments
caching of fragments
circuit breaker for fragments

All of those are mentioned here. Is it still the plan? Are they going to be implemented? Do you need any help with that? If yes, how can we help? :-)
Additionally, there is this point on your list here, "Logging and Metrics(Fragment TTFB, TTLB) that are based on tailor event system". Is it somehow related to hooking system? Does it mean that you are aware of the fact that events described in documentation of hooks (https://github.com/zalando/tailor/blob/master/docs/hooks.md) are never triggered? At least that's what we've experienced. If this is not the same thing, I'll open separate issue with detailed description for this particular bug.
Thanks a lot! :-)

Hi @soofka , I stated a separate client for tailor https://github.com/vigneshshanmugam/tailor-http-client which should resemble close to what we had internally at Zalando and would include the features you mentioned with configurable parameters. Once i push the code changes, I will put here so that everyone can review and contribute more features 😃

Logging and Metrics(Fragment TTFB, TTLB)

This is purely server side events and not related to hooks which is associated to front end metrics. Its based on the tailor events https://github.com/zalando/tailor/blob/master/docs/Events.md.

I'll open separate issue with detailed description for this particular bug.

Yes please do, happy to help.

Any updates? Could we help somehow?

Its been a bit of a delay, But I started prototyping some of the ideas as a separate package here. https://github.com/vigneshshanmugam/tailor-libs
PR's are welcome and also please open issues on whatever features that would beneficiary for the tailor core.

Can we have some bigger picture and what has to be done? tailor-libs seems to be quite empty


There is no loop above comment

Challenge http://freecodecamp.com/challenges/waypoint-iterate-with-javascript-for-loops has an issue. Please describe how to reproduce it, and include links to screenshots if possible.
var myArray = [];
//Push the numbers zero through four to myArray using a “for loop" like above.
As per bug title

Isn't the point of the bonfire to create the loop yourself?


Scala Common Enrich: remove field length checks and truncation from EnrichmentManager

Suggest splitting in two: 1) remove JSON length checks, 2) move truncation code to shredder

r72 will move some shredder logic into common enrich to get the event name, vendor, etc from unstructured event JSONs. As a side effect this will check whether unstructured events are valid JSONs. Should we continue to check whether contexts are valid JSONs in common enrich, or should that be the responsibility of later parts of the pipeline (currently hadoop shred and kinesis es sink)?

One benefit of doing this check is that we could make common enrich's output slightly smaller by removing unnecessary whitespace from JSONs.

Validating contexts in Common Enrich is important - it's part of our move
to fully validating our raw event early/eagerly. It's not storage target
related. Remember that our enriched event in S3 is becoming our canonical
format, so needs to be fully validated.
On 9 Sep 2015 9:59 am, "Fred Blundun"<EMAIL_ADDRESS>wrote:

r72 will move some shredder logic into common enrich to get the event
name, vendor, etc from unstructured event JSONs. As a side effect this will
check whether unstructured events are valid JSONs. Should we continue to
check whether contexts are valid JSONs in common enrich, or should that be
the responsibility of later parts of the pipeline (currently hadoop shred
and kinesis es sink)?
—
Reply to this email directly or view it on GitHub
https://github.com/snowplow/snowplow/issues/2041#issuecomment-138840200.


Connect Setting page

Is your feature request related to a problem? Please describe.
Currently no api has been connected to the change banner, edit bio of the setting page. Its also missing a connect button.

Describe the solution you'd like
connect the require api to the corresponding features and create a logout button
Describe alternatives you've considered
N/A
Additional context
N/A

LGTM


Libreoffice-fresh: 7.3. 3.2 -> <IP_ADDRESS>, libreoffice-still: <IP_ADDRESS> -> <IP_ADDRESS>

Description of changes
Based of PR #187468
Release notes
Security patch
    https://www.libreoffice.org/about-us/security/advisories/CVE-2022-3140

Originally posted by @mweinelt in https://github.com/NixOS/nixpkgs/issues/187468#issuecomment-1279616184
included.
Also did a bit of cleanup for some unused code.
Todo:

[x] Test kdeIntegration

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

This is a semi-automatic executed nixpkgs-review with nixpkgs-review-checks extension. It is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
Result of nixpkgs-review pr 196535 run on x86_64-linux 1

12 packages built:

jpsxdec
libreoffice (libreoffice-still)
libreoffice-fresh
libreoffice-fresh-unwrapped
libreoffice-qt
libreoffice-unwrapped (libreoffice-still-unwrapped)
paperwork
python310Packages.paperwork-backend
python310Packages.paperwork-shell
python39Packages.paperwork-backend
python39Packages.paperwork-shell
unoconv

The following issues got detected with the above build packages.
Please fix at least the ones listed with your changed packages:

libreoffice-fresh:

got build log for '/nix/store/gzk7v5xysx1f9dysdbdkkg6r3s4d0p6x-libreoffice-<IP_ADDRESS>' from 'daemon'
When evaluating attribute ‘libreoffice-fresh’:
warning: unused-argument
Unused argument: commonsLogging.
Near pkgs/applications/office/libreoffice/default.nix:89:3:
   |
89 | , commonsLogging
   |   ^

libreoffice-fresh-unwrapped:

got build log for '/nix/store/nx8kdvbchfislqn8djsliqazc3dd7xcr-libreoffice-<IP_ADDRESS>' from 'daemon'
When evaluating attribute ‘libreoffice-fresh-unwrapped’:
warning: unused-argument
Unused argument: commonsLogging.
Near pkgs/applications/office/libreoffice/default.nix:89:3:
   |
89 | , commonsLogging
   |   ^

libreoffice:

got build log for '/nix/store/dw1i44d5cwzdx0jvkd99pmv27q4h22my-libreoffice-<IP_ADDRESS>' from 'daemon'
When evaluating attribute ‘libreoffice’:
warning: unused-argument
Unused argument: commonsLogging.
Near pkgs/applications/office/libreoffice/default.nix:89:3:
   |
89 | , commonsLogging
   |   ^

libreoffice-qt:

got build log for '/nix/store/fiqbgwr4b961k8g5vvxn1rfkij72zjg2-libreoffice-<IP_ADDRESS>' from 'daemon'
When evaluating attribute ‘libreoffice-qt’:
warning: unused-argument
Unused argument: commonsLogging.
Near pkgs/applications/office/libreoffice/default.nix:89:3:
   |
89 | , commonsLogging
   |   ^

libreoffice-unwrapped:

got build log for '/nix/store/nnjcr3ybgglr3c7x2nrvf359vyid0b6i-libreoffice-<IP_ADDRESS>' from 'daemon'
When evaluating attribute ‘libreoffice-unwrapped’:
warning: unused-argument
Unused argument: commonsLogging.
Near pkgs/applications/office/libreoffice/default.nix:89:3:
   |
89 | , commonsLogging
   |   ^

commonsLogging can be ignored. It is needed.

Can we get a backport into 22.05?

I'm not sure whether we should. This is a major version bump for both packages..
On the other hand, this is also a security fix.
I don't have enough experience with backports to deicde


SFPF	Form Object: Form

class CL_FP_WB_FORM

Issue #99 is solved, but #98 still problem.

added in https://github.com/larshp/abapGit/issues/644


Check and fix dequantize_affine is idempotent

Resolves https://github.com/pytorch/ao/issues/289
Follow up includes adding this check for quantize as well.
Follow up includes making tests run on 2.3+ instead of 2.4+ by porting reference into torchao.

This may result in a performance regression due to the extra copy (even though I'd expect the compiler to handle this). However, the existing implementation can also yield silent correctness issues in case the input is being fed into multiple modules that use this dtype or when using skip connections, etc.


feat(TDF-477): Utilities for generating random Avro rows.

Please check if the PR fulfills these requirements

[X] The commit message follows Talend standard
[X] Tests for the changes have been added (for bug fixes / features)

What is the current behavior? (You can also link to an open issue here)
What is the new behavior?
The RowGeneratorIO can be used to generate random Avro records.
Does this PR introduce a breaking change?

[ ] Yes
[X] No

If this PR contains a breaking change, please describe the impact and migration path for existing applications: ...
Other information:

Pull request test result: failure :x:

Pull request test result: success :star:

Pull request test result: success :star:

I really would have liked this row generator to be used for test any kind of runtime and not only beam once. Could this be also used for any kind of components ?

Pull request test result: success :star:

Pull request test result: success :star:


Typo in permissions that are required to move Management Groups and Subscriptions "child Subscription"

Permission is wrong. Should be "Microsoft.Authorization/roleAssignments/write", currently is "Microsoft.Authorization/roleassignment/write"

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

ID: 7d78cf71-d050-1d54-6048-7e92ea98084d
Version Independent ID: 16675bf7-077e-0394-c578-8bcc0226ec0b
Content: How to work with your management groups - Azure Governance - Azure governance
Content Source: articles/governance/management-groups/manage.md
Service: governance
GitHub Login: @rthorn17
Microsoft Alias: rithorn

@scratch85 Thanks for the question! We are investigating and will update you shortly.

We have verified and updated the document as appropriate. Thanks again!


build: Transform most CI scripts to bash

We only use those scripts in CI where bash is always the default shell.
Bash provide modern features and more convenient scripting experience
(i.e. may reduced error rate) with almost no penalty other than portability
and unnoticeable run time. But that's acceptable for our CI.

I'm prepared to entertain merging this (being explicit about bash is good in my books) but I'd like to solve the spurious failures first if we can.

:umbrella: The latest upstream changes (presumably #1923) made this pull request unmergeable. Please resolve the merge conflicts.

:umbrella: The latest upstream changes (presumably #1955) made this pull request unmergeable. Please resolve the merge conflicts.

I'd like to solve the spurious failures first if we can

It looks like we cannot fix it anytime soon.
We could just merge this PR because it doesn't conflict with that goal.

I do not want clippy on stable -- I value strongly the indication that beta isn't regressing (and right now it is) and I can deal with deciding if the failure is relevant.

In that case: Do you want to keep clippy on beta or move it to nightly?

Definitely keep it on beta -- it gives us an excellent canary for whether or not there might be issues in the next stable.

I dropped the clippy commit.


trying to add native library and fail to compile

Hello. I tried to build the app with one native library (react-native-calendars) and it throw an error :
Failed to compile.

./node_modules/react-native-calendars/src/calendar-list/index.js
Module parse failed: Unexpected token (17:19)
You may need an appropriate loader to handle this file type.
|
| class CalendarList extends Component {
|   static propTypes = {
|     ...Calendar.propTypes,
|

I guess it's a webpack thing. Any idea what can I do or where to config my webpack?
Thank you!

https://github.com/wix/react-native-calendars/issues/2 might help?

wix/react-native-calendars#2 might help?

Not really. I need to manually config webpack to make it work. But I can't see any option to eject the web part of the project. Am I right or am I missing something and I am able to config webpack somehow?


Get custom terms return an empty array

Issue description:
I was trying to get woocommerce terms for the select type but return an empty array.
Is working fine if want to get normal wp terms (category and tags).
Version used:
2.3.1
Using theme_mods or options?
both
Code to reproduce the issue (config + field(s))
Custom terms always return an empty array
Kirki::add_config( 'my_settings', array(
	'capability'  => 'edit_theme_options',
	'option_type' => 'theme_mods',
) );

Kirki::add_field( 'my_settings', array(
	'type'        => 'select',
	'settings'    => 'my_setting',
	'label'       => __( 'This is the label', 'my_textdomain' ),
	'section'     => 'title_tagline',
	'default'     => '',
	'priority'    => 10,
	'choices'     => Kirki_Helper::get_terms( 'product_cat' ),
) );

Use normal customizer without kirki is working fine.
$wp_customize->add_setting( 'my_setting',
	array(
		'default'        => '',
		'type'           => 'theme_mod',
		'capability'     => 'edit_theme_options',
	)
);
$wp_customize->add_control( 'my_setting',
	array(
		'label' 		=> esc_html__('Display Layout', 'my_textdomain'),
		'section' 		=> 'title_tagline',
		'description'   => '',
		'type'          => 'select',
		'choices'       => Kirki_Helper::get_terms( 'product_cat' )
	)
);

The first select field is using normal wp customizer
The second select field is using kirki

I just tested this on normal categories and it seems to be working fine there...
Can you please check if the issue is with that particular taxonomy?

Yes is working fine if want to get WP built-in taxonomy such as category and post_tag.
It seem almost all custom taxonomy. I have try woocommerce, easy-digital-downloads, custom-content-portfolio and also register some custom taxonomy just for testing purpose. But still return an empty array.
I wrote some helper function with the new get_terms arguments and still not working too.
function prefix_get_terms( $taxonomy ){

	$term_item = array();

	$terms = get_terms( array(
		'taxonomy'		=> $taxonomy,
		'hide_empty' 	=> false
	) );
	foreach ( $terms as $term ) :
		$term_item[$term->term_id] = $term->name;
	endforeach;

	return $term_item;

}

The issue is that custom taxonomies arregistered from WooCommerce on init, so when you're trying to call the Kirki_Helper::get_terms( 'product_cat' ) method directly the taxonomies have not been registerd yet, so there's nothing to retrieve.
When using the WordPress Customizer API you're adding your controls in the customize_register action which is later than init so by that time the taxonomies are properly found.
A solution would be to add your field on init like this:
add_action( 'init', function() {
	Kirki::add_field( 'my_settings', array(
	    'type'        => 'select',
	    'settings'    => 'my_setting',
	    'label'       => __( 'This is the label', 'my_textdomain' ),
	    'section'     => 'title_tagline',
	    'default'     => '',
	    'priority'    => 10,
	    'choices'     => Kirki_Helper::get_terms( 'product_cat' ),
	) );
});

Ahhh, didn't notice that part.
Thanks a lot for your awesome work.


Fix scaling issue on linux with high DPI monitor

You may want to change names of variables or functions here. Fixes the issue, for all demos except multiscene, on Linux and works on MacOS M1 (not tested on Windows).  Fixes issue #20

great, thanks for looking into it. I will have to test a bit and i'll merge it when im done. feel free to ping if i forget about it

Looks like I merged this prematurely, I found some breakage in celtest.

moved to https://github.com/bmchtech/rengfx/tree/feat/fix-dpi

Sorry, looking at it more, I think the PR was totally broken to begin with. I rushed into merging it

Ah, actually I see a difference on my M1 for celtest now...perhaps I didn't recompile that one to test. Seems like the view is too close.
Pong is the same, but can be fixed with this patch and changing the actual ball/paddles/scores placements manually in the example code.
So, not totally sure how you wanted to fix this...but it seems like anything that is setting a view/scene offset by resolution will have some issues with this fix, as it is.


fix(navbar): flip page hero to the top of the tabs

Summary

summary_here

Change List (commits, features, bugs, etc)

items_here

Related Issues

Closes IBM/carbon-addons-iot-react#NUMBER

Acceptance Test (how to verify the PR)

Verify that the hero is now on top of the Navigation bar

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 2.0.0-beta.9 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.71.8 :tada:
The release is available on npm package (@release-1.x dist-tag)
Your semantic-release bot :package::rocket:


Replace 'inline extern' with 'fixed function block'

The term 'inline extern' is a misleading choice of words for this functionality in PNA, and fixed function block has a longer history of being used for such things.
Remove a left-over mention of the pre control that was missed before.
Correct the name of the extern function set_entry_expire_time_if in some examples in comments.
Use INCLUDE directive in a few more places of PNA.mdk that will help keep the code snippets from the pna.p4 include file consistent between that file and the spec more easily in the future.

@mariobaldi These are mostly minor fixes, that I think would be reasonable to merge if you approve, without going through meeting discussions on.


TypeError when importing modin

System information

Amazon linux (Centos):
Modin installed from binary:
Modin version: 0.2.2:
Python version: 3.7.0:
Ray version: 0.5.3
import modin.pandas:

Describe the problem
I am getting an import error because of an unexpected argument use_raylet
Source code / logs
In [1]: import modin.pandas
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-1-d42df328a6c7> in <module>()
----> 1 import modin.pandas

~/anaconda3/lib/python3.7/site-packages/modin/pandas/__init__.py in <module>()
     78             include_webui=False,
     79             redirect_worker_output=True,
---> 80             use_raylet=True,
     81         )
     82 except AssertionError:

TypeError: init() got an unexpected keyword argument 'use_raylet'

What is your Ray version?
import ray
ray.__version__

Hi @ek-nath, I did a bit more digging. It looks like you may have recently built Ray from source. We depend on the pypi release of Ray, and the ray.init API changed slightly since the last Ray release. If you want to resolve this issue, you will have to install Ray using pip (pip install ray).
cc @robertnishihara

I have updated the original issue report with the version. It is 0.5.3

installing ray via pip doesn't seem to resolve the issue either. I will try to check with an older version of ray and report back

You may need to pip uninstall ray; pip install ray.

This is weird. I am unable to install ray at all using pip.
dev-machine % pip install ray
Collecting ray
  Could not find a version that satisfies the requirement ray (from versions: )
No matching distribution found for ray

(18-10-31 20:11:08) <1> [~]
dev-machine % pip install ray==0.5.3
Collecting ray==0.5.3
  Could not find a version that satisfies the requirement ray==0.5.3 (from versions: )
No matching distribution found for ray==0.5.3

(18-10-31 20:11:10) <1> [~]

Was able to install using pip install -U https://s3-us-west-2.amazonaws.com/ray-wheels/latest/ray-0.5.3-cp37-cp37m-manylinux1_x86_64.whl based on instructions here
But the problem of the use_raylet persists and like it says in the URL, it installs version 0.5.3

Oh, it is a Python 3.7 issue. Ray 0.5.3 on pypi did not ship with Python 3.7 support.
There is a PR that will resolve this use_raylet issue: https://github.com/ray-project/ray/pull/3176, and once it gets merged the nightly wheels (where you installed from) will reflect that change.
In the meantime, it is possible to install this way:
pip install git+https://github.com/devin-petersohn/modin/@no_raylet

I pushed a branch that removes the use_raylet option to my fork of Modin. Everything else is identical to current master.

Success @devin-petersohn
python -c "import modin.pandas"
Process STDOUT and STDERR is being redirected to /tmp/ray/session_2018-10-31_20-41-01_29838/logs.
Waiting for redis server at <IP_ADDRESS>:12739 to respond...
Waiting for redis server at <IP_ADDRESS>:17503 to respond...
Starting the Plasma object store with 6.4900694009999995 GB memory using /dev/shm.


Fixes bug when envelopeKey is changed and WSSecurityCert is set

Heyo,
I’ve fixed a bug in my fork. There is a hard coded envelopeKey for the Header, and it throws when the envelopeKey for the envelope is not 'soap'.
Thanks!

Coverage remained the same at 94.848% when pulling 3bb2433a8085fdf28dcd32efc0362b4bae900a75 on jmkomala:1105 into c484871ad9a7a0ea61e31fc15191fac2b9124b91 on vpulim:master.


SqliteError: expose code?

Currently, SqliteError stores the raw result code from sqlite, but only exposes it as a string through the DatabaseError trait.
While I guess the interface makes sense assuming it originates in Postgres, this is not really convenient when trying to get precise data out of it (e.g. try to know whether a query failed due to a constraint and if so which), especially since sqlite documents the return code as a struct of sort composed of an 8-bit error category ("primary result code") as the LSB, and 24 bits of extended information ("extended result code") for the most significant bytes. It might even be useful to provide a direct accessor to the primary result code (whether as an u8 or an i32), and integer constants for the known codes (primary and extended).

PS: I'd be fine working on that, just not sure if the project would be interested, or how to approach it (especially in terms of magic values / constants)

PS: I'd be fine working on that, just not sure if the project would be interested, or how to approach it (especially in terms of magic values / constants)


Configs generated for LB with ssl enabled listeners does not have any information about certs.

Server version - Build from master - Aug 26
Create LB service with ssl enabled listeners and few certificates.
YML Configs generated for LB service with ssl enabled listeners does not have any information about certs.

Tested with server build from master - Sep 4
ssl ports are indicated using labels:
io.rancher.loadbalancer.ssl.ports: '400'
Certs are present in rancher-compose.yml in LB service section:
LB-test721471:
  scale: 2
  certs:
  - test-919305
  - test-388082
  default_cert: test-639611


The potassium explosion can also be done with blood, blue blood, slime, and sap.

About the PR

Added four more reactions, potassium with blood, potassium with blue blood, potassium with slime, and potassium with sap. They all produce an explosion, which is identical in strength to that of potassium with water.
Why / Balance

Adds more realism, but also now scientists cant just have the arti room filled with blood from the poor monkeys. They actually have to call a janitor to get that cleaned(or do it themselves), else the artifact may just generate potassium and blow up the lab.

[x]  This PR does not require an ingame showcase

Changelog

:cl:

add: Potassium now explodes on contact with blood, blue blood, slime blood, and sap.

What happens if you inject someone with potassium?

Not a huge fan of this, it’s going to make doing artifacts much, much more difficult for what seems like no real reason. I get not wanting to have the artifact chamber filled with blood, but there’s also the just as likely outcome of it being filled with potassium (which is much more difficult to just have someone clean up).

With artifacts spawning few thousands units of chems PER ACTIVATION, thats not something we would even call janitor for, we would need ERT janis from centcom.

This just makes hypo darts and hypos in general 10x better, injecting an instant unavoidable explosive into your blood stream is absurd

This just makes hypo darts and hypos in general 10x better, injecting an instant unavoidable explosive into your blood stream is absurd

it's already been tested with cryo syringes and the explosions are pathetically weak

Bloodstream does not at all react with the chemstream fyi. Injections will NOT do anything currently. Blood reagent is separate from where chemicals are metabolized, they'd only react if you started bleeding, at which point part of the chemstream is mixed with the bloodstream to create the blood puddles

when the nukies murder half the station, our hero tider comes in to save the day at the last second by throwing a potassium bomb into the sea of crew blood....

im not a fan of these types of solutions and would prefer this just didn't get done until theres some reaction system that doesnt require duplicating everything like this


Recipes should have item tags as ingredient

Description
Playing with nuclearcraft and thorium reactor on same lets play i have find that thorium crafting table dont allow other graphite ingots so why not change as #forge:ingots/graphite to add compatibility ?

Links
No response

Hey! That's already planned for a pretty long time now. I made a mistake in Not adding Tag Support to all of my recipes, also machines. That rework will take a bit of time to complete and currently I dont see when I could finish it. Maybe next month.

Its me again, took some of my time to remake almost all recipes to support external items and blocks. This will be fixed in 0.1.6b! But still no ETA, maybe next week :)

Hey! Just uploaded 0.1.6b where I changed all this! Thanks for this Issue and if you still have problems or ideas regarding the crafting system just let me know!


fix: minor ext bugs

About
This pr does two things relating to .ext:

fixes the IndentationError in base.pyi, which makes it unable to be formatted by black
Changes the MD5Hash typehint to point towards an existing class in hashlib

Checklist

[x] I've ran pre-commit to format and lint the change(s) made.
[x] I've checked to make sure the change(s) work on 3.8.6 and higher.
[ ] This fixes/solves an Issue.

(If existent):

[x] I've made this pull request for/as: (check all that apply)

[ ] Documentation
[ ] Breaking change
[ ] New feature/enhancement
[x] Bugfix

I think something may be broken with pre-commit

I think something may be broken with pre-commit

why?

It passed on my machine, but the automated checks here failed

It passed on my machine, but the automated checks here failed

Thats not your fault:


Step 1: Assign yourself

Step 1: Assign yourself
Unassigned issues don't have owners to look after them. When you’re assigned to an issue or pull request, it tells repository visitors and contributors that you'll be facilitating the conversation or task :muscle:.
:keyboard: Activity

On the right side of the screen, under the "Assignees" section, click the gear icon and select yourself

For a printable version of the steps in this course, check out the Quick Reference Guide.

I'll respond when I detect you've assigned yourself to this issue.

Sometimes I respond too fast for the page to update! If you perform an expected action and don't see a response from me, wait a few seconds and refresh the page for your next steps.

Originally posted by @github-learning-lab[bot] in https://github.com/MastereredSelf/github-slideshow/issues/1#issuecomment-781058999

Hello world . Eye am Masterereds


Find Element should not throw exception when element not found.

somthing like this
driver.FindElementById("yourelementid")
should return null if there isn't any element with that id, so that
                    var waitHandler = new WebDriverWait(driver, TimeSpan.FromSeconds(10));
                    waitHandler.Until((d) => { return d.FindElement(By.Id("yourelementid")); });

could work correctly.

I'm using C# and have been annoying to see the NoSuchElementException keeping bubbling up again and again. The intuitive meaning of the wait.Until method should imply that it will keep waiting until the expected condition is met. This includes the situation when the element has not been rendered yet. Otherwise, why would I wait?

I have to make an extension method called 'SafeUntil' to the default wait class to handle the NoSuchElementException. psst!


Support Python 3.12 wheels

Fix #156

When will this be released?

Yes, it will be included in the next 3.4.0 release

I see there is https://github.com/apache/pulsar-client-python/releases/tag/v3.4.0-candidate-1, I suppose we can expect 3.4.0 release this week?

I didn't see a vote for this candidate here. Generally, we need a vote that must be open for at least 72 hours until 3 binding +1s and then promote the candidate to a formal release.
@RobertIndie Is there anything that blocks the release or did you just forget the vote?

@BewareMyPower It's blocked by the release CI: https://github.com/apache/pulsar-client-python/actions/runs/7269467100/job/19807133709. I'm currently fixing it.


Fix class name in import_file_uploader_component

before:

after:

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Option to not append results to Python Interactive

As part of my data science workflow I use the Python Interactive window as a REPL. That is, I run lines and then can interact with the Jupyter terminal to check data and figures. However, as the number of Jupyter cells grows the processing speed of each line declines. In some cases, when the number of cells exceeds 200 it takes a while to even process 1+1. To overcome this I restart the ipython kernel and remove all cells. However, I lose my variables and have to rerun all the variables I was working with.
After some searching, it appears there was an option to disable appending results to the window, but it is not available now.
"python.jupyter.appendResults": false,
It would be great to have this option available so the Python Interactive window acts more like a REPL than a notebook, at least until this issue is resolved #727. These features are necessary for efficient data science workflows -- akine to Spyder and RStudio.

Do you really want to not append, or actually to just have it be performant with 200 cells in it? We've been discussing virtualizing the scrollable area in order to allow any number of cells in the window.
Not appending seems more like a notebook than a REPL then.

@rchiodo Performant with 200 cells would solve this issue, but seems unnecessary -- how many notebooks are greater than 200 cells. Ideally, a terminal with syntax highlighting and plotting is, in my opinion, exactly what a data scientist needs to work efficiently -- RStudio implements this workflow, although not perfect. As you mention, virtualizing the scrollable area would work or just allow for a single pane that runs each line/block of code while also allow the ability to view the history. I know this is an issue being discussed, but a Hydrogen like implementation in VS Code is what is needed.
This issue is the biggest constraint in my current workflow with VS Code. I do appreciate the team focusing on these issues in the future and all the work so far.

When will this feature be updated?

Sorry but not any time soon. It's not currently on our backlog.

We're re-purposing this issue to really just be about not appending. There's interest in having the interactive window behave slightly more like a notebook in that a cell stays in the location it's written to. This would essentially be do not append unless a new cell is run mode.
The perf related to that change should not be necessary once we fix some of our virtualization issues (and we'll be doing separately).

We're re-purposing this issue to really just be about not appending. There's interest in having the interactive window behave slightly more like a notebook in that a cell stays in the location it's written to. This would essentially be - do not append unless a new cell is run - mode.
The perf related to that change should not be necessary once we fix some of our virtualization issues (and we'll be doing separately).

All right. But I hope vscode notebook will support Vim soon, as jupyter lab has Vim support.


follow PEP 257 docstrings & quote consistency

Follow PEP 257 docstring guidelines
Follow PEP 8 guideline of consistency with quotes across the project

Contributor checklist

[ ] Provided the tests for the changes
[ ] Added the changes to CHANGELOG.md
[x] Requested (or received) a review from another contributor

Going to merge this by EOD since, as the contributing doc states, it's just documentation updates but I would love feedback if anyone has some.

I would wait, since this touches a large number of files. It's erring on the side of more than trivial.
Either way, I'm generally -1 on these kinds of changes unless there's style enforcement in the build. Without enforcement, the changes are kind of meaningless since nothing prevents future PR's from breaking the style guidelines. For consideration:

There is a pep257 plugin for flake8.
I'd gather more feedback from other people, but I'm 👎  on changing string quotes in code since it  negatively affects git-blame. That said, it would be more acceptable if there was enforcement of quote consistency. Maybe this plugin?

I don't see the value this PR adds. Adding a automatic checker would bring value for future contributions, but aesthetic changes like these are counter productive, and produce unnecessary conflicts for every pending PR.

@rpkilby a style checker is a great idea. However, even if that were added these changes would be required.
@davidovich the value is consistency which is the entire point of PEP standards. Maybe give this page a read. :D

the value is consistency which is the entire point of PEP standards. Maybe give this page a read. :D

I'm sure @davidovich understands the benefits of style consistency 😉. The implication is that the PR does not have a net positive value on the codebase. ie, even though style consistency is a plus, is it worth mucking up git-blame and creating conflicts for existing PRs?
@davidovich - would simplifying this to just doc strings/pep 257 make sense? It would be a lot less disruptive.


macos: activateApp not implemented error

Hi!
We would like to use the Application Under Test Concept for automating some native tests on Mac using Appium and mac2-driver.
We started the driver without bundleId and then tried to use activateApp but in vain. The error say it's not yet implemented:
[debug] [W3C (1eed6dce)] Calling AppiumDriver.activateApp() with args: ["com.apple.calculator",null,null,null,"1eed6dce-93bb-4a53-a9fd-68d0468dc1bf"]
[debug] [W3C (1eed6dce)] Encountered internal error running command: NotYetImplementedError: Method has not yet been implemented
[debug] [W3C (1eed6dce)]     at Mac2Driver.executeCommand (/Users/gberta/.nvm/versions/node/v14.15.0/lib/node_modules/appium/node_modules/appium-base-driver/lib/basedriver/driver.js:328:13)
[debug] [W3C (1eed6dce)]     at AppiumDriver.executeCommand (/Users/gberta/.nvm/versions/node/v14.15.0/lib/node_modules/appium/lib/appium.js:563:36)
[debug] [W3C (1eed6dce)]     at runMicrotasks (<anonymous>)
[debug] [W3C (1eed6dce)]     at processTicksAndRejections (internal/process/task_queues.js:93:5)
[debug] [W3C (1eed6dce)]     at asyncHandler (/Users/gberta/.nvm/versions/node/v14.15.0/lib/node_modules/appium/node_modules/appium-base-driver/lib/protocol/protocol.js:297:21)
Are you aware of this problem?

Can we just implement this instead? so it s similar to use other platforms?
Should be as easy as map AppiumDriver.activateApp()  to driver.execute_script("macos: activateApp", {"bundleId": "com.apple.calculator"})
Or is this something to be done in other repo?


Feature - Streaming of OpenAI API requests

The current API request can be augmented by adding "stream": true to the json input. This will prompt the OpenAI API to stream chunks of data to the caller rather than the full message. This feature will make the experience more smooth for the user, as text will appear as it is generated like on ChatGPT, but we will need to build a server side event handler for this, which builds a response string by appending chunks as they appear and handles the termination message data: [DONE], such that the parsing can begin and the player input can be reactivated.

use regex or something of the like to determine which parts are shown to the user, as the entire response contains a lot of context updates which should not be shown directly.


213 Differentiate broker services and standardize

Handling of the term "metadata broker":

if "broker" only refer to metadata brokers, name it like that
if "broker" means multiple types of brokers (app, service, metadata
see 3.1.1. Roles in the IDS), name it "any broker", "broker service providers" or similar
if "data broker", name it "metadata broker"

Note: Caps have been ignored (metadata broker, Metadata Broker)

Proposal to solve https://github.com/International-Data-Spaces-Association/IDS-RAM_4_0/issues/213

We need to agree on a uniform spelling. "Metadata Broker" vs. "metadata broker" eliminates already a huge number of previous variations :-) Proposed updates are fine with me.

That's a good point I was thinking about, too. Sometimes the text refers to components as names - therefore they were written with starting capitals (such as "Metadata Broker", "Participant Information System"). Sometimes they weren't. I just sticked to the respective chapter (well, they're written by different persons).
As a consequence, I would align on calling it Metadata Broker in uppercase.
In an additional issue, it could make sense to introduce a naming convention, couldn't it? Something like refering to names,  concepts and entities of the IDS RAM as upper case (like Contract Offer, Usage Policy) and add something like a preamble to explain it. Maybe this proposal also is overengineering because it's a cosmetical issue.

Editorial changes are to be released immediately. Changelog needs to be updated.


drop test.yaml: operator image nudging is configured

SSIA

/override ci/prow/e2e-aws-operator
/override ci/prow/images
/override ci/prow/security
/override ci/prow/unit
/override ci/prow/verify


Set default pool size for HiLo to 1 and allow pool size to be configured

As per design meeting decision and Issue #778. Also some renaming in core metadata to better match the new naming in the fluent API.

@smitpatel Will do

@smitpatel Are you planning to finish review of this? If not, I'll find somebody else to look at it.

:shipit:

Merged


How i get my cropped image from canvas

Please give the js code for save the cropped image to particular url.

Read the doc or reference the official demo.


Documenting static argument & return types of numba-JIT-compiled functions?

I am heavily using sphinx, autodoc and sphinx-autodoc-typehints to document code. I am also using numba to JIT-compile (some) functions. I typically statically type my JIT-compiled functions via numba’s jit and njit decorators instead of using Python type annotations (because numba does not understand them). I was wondering if there was a tool or plugin for sphinx similar to sphinx-autodoc-typehints that would be able to pick up the types specified via numba. Or sphinx-autodoc-typehints perhaps supports it and I overlooked it?

Regular Python annotation:
def foo(bar: float) -> float:
    return bar ** 2

Statically typed, numba-JIT-compiled function:
@numba.njit('f8(f8)')
def foo(bar):
    return bar ** 2

AFAIK this has not been created yet and we don't support it yet. I'm personally not sure it belongs to this project though 🤔

Closing as there doesn't seem to be a wide interest for it just yet.


If and else clause have same code PyscesSED.py

Hi Bret,
just looked over the PyscesSED.py file and the following does not make sense.
The best M
    def addModel(self, id, model):
        try:
            if not self.models.has_key(id):
                self.models[id] = model.clone()
            else:
                self.models[id] = model.clone()

Thanks will look into it, I mostly work with a single model so missed this one.

Not really using it, just read over the code and caught my attention.
M
On Feb 24, 2016 2:39 PM, "Brett Olivier"<EMAIL_ADDRESS>wrote:

Thanks will look into it, I mostly work with a single model so missed this
one.
—
Reply to this email directly or view it on GitHub
https://github.com/PySCeS/pysces/issues/18#issuecomment-188258452.

fixed.


Fix build issue when re-running the build in an existing setup

In an existing Submariner (with globalnet) deployment, when we re-run
the command "make build package e2e status=keep", the following error
is seen and this patch fixes it.
kubectl --context=cluster2 -n submariner create serviceaccount submariner-globalnet
Error from server (AlreadyExists): serviceaccounts "submariner-globalnet" already exists
[submariner]$ ./scripts/e2e keep 1.14.2 false false helm false
FATA[0224] exit status 1
make: *** [Makefile:18: e2e] Error 1
Signed-off-by: Sridhar Gaddam<EMAIL_ADDRESS>

This change is


JodaTime Domain properties are not listed as Persistent Properties

Grails 3.3.2
JDK 8
For example we have a domain User.groovy
package demoapp

import org.joda.time.LocalDate
import org.jadira.usertype.dateandtime.joda.PersistentDateTime

class User {

    LocalDate dateOfBirth

    static constraints = {
	dateOfBirth type: PersistentDateTime
    }
}

Now, when we run the following test it should pass:
    void "test joda time property on persistentEntity"() {
		when:
		assert domain.properties != null
        PersistentEntity persistentEntity = User.gormPersistentEntity
        List<PersistentProperty> properties = persistentEntity.persistentProperties

        then: "Joda property found on persistent entity"
        properties.any {it.type == LocalDate}
    }

For unit testing, you need to register the CustomTypeMarshaller for the SimpleMap by adding this to your application.groovy:
grails.gorm.custom.types = [
    new SimpleMapJodaTimeMarshaller(LocalDate),
    new SimpleMapJodaTimeMarshaller(LocalDateTime),
]

The plugin should probably add this configuration automatically. This used to be done inside the initialize method on the SimpleMapJodaTimeMarshaller, however in GORM 6 and later, the registerCustomType method is no longer static so it must be done via the configuration.


An option to adjust the playfield's offset/alignment

With my intention for sentakki to be a viable option for DIY maimai machines, it is important that there are options to ease the use of sentakki on those machines.
Currently the playfield is hard locked to the center of the screen, either forcing DIY-ers to accommodate that in fullscreen, or to resort to using windowed mode.
Having an option to finetune the playfield position would allow for greater accessibility and leniency for DIY machines.

I completely forgot that lazer already has the option to do just what we need via the "Screen scaling" option. By how well made it already is, it's safe to say that it is more than enough to cover a variety of use cases.

I completely forgot that lazer already has the option to do just what we need via the "Screen scaling" option. By how well made it already is, it's safe to say that it is more than enough to cover a variety of use cases.


Allow junctions with name and exclude

Fixes #36: can now pass junctions to name or exclude options, expanded test coverage to exercise this.

@doomvox Thank you, it looks good to me. Perhaps it can be released after a bit of local testing.

@2colours: you can release community modules, can you not?  If not, would you like to be able to?

@lizmat thanks, yes I can, and I eventually did. :)


[BUG] makes get_utc_timestamp work with datetime.datetime objs.

Python datetimes were throwing an error in get_utc_timestamp,
this fixes that issue for me locally. I used pd.to_datetime to
ensure that pd.Timestamps are used. The method works for arrays
as well as individual datetimes.
The example NBs run without error for me locally with this change.

:+1:


Killzone 2 motion control sequences

If you play the first 5-10 minutes of Killzone 2, you'll reach a motion control valve turning segment.
Presumably the valve is attached to the player so animations can be synced up. Normally no camera input is accepted during these sequences.
The valve.

The prompt.

Applying mouse input.

Not really relevant to any fix, but i'm not meant to be out here.

Separate issue but you can't progress further once the game asks the player to turn the valve unless he uses a controller with sixaxis support :P

Did you played for 5-10 minutes without crashing? If so, How? And I'm just sorry but if you don't have a PS3/PS4 controller I'm afraid that you can't play that part, or just find a Savefile.

I used the settings from the RPCS3 wiki article and I didn't experienced any crash at all.


make Controller.Open return status code

Controller.Open needs to return status code to indicate whether there are
schema changes or not. Schema manager stops early if there are no schema
changes.

Another fix might be skip schema change if Controller.Read returns empty. This is much simpler and I am thinking maybe it is not worth to introduce the status struct at this time.