EPH load balances across partitions

Description
Brief description of the changes made in the PR. This helps in making better changelog

It does consumer partition assignment and rebalancing correctly

Reference to any github issues

Fixes https://github.com/Azure/azure-event-hubs-node/issues/93

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

client/.npmignore
:white_check_mark:Succeeded

client/README.md
:white_check_mark:Succeeded

client/examples/batchReceive.ts
:white_check_mark:Succeeded

client/examples/batchSendReceive.ts
:white_check_mark:Succeeded

client/examples/simpleSendReceive.ts
:white_check_mark:Succeeded

client/examples/simpleSender.ts
:white_check_mark:Succeeded

client/lib/connectionContext.ts
:white_check_mark:Succeeded

client/lib/eventHubClient.ts
:white_check_mark:Succeeded

client/lib/eventHubReceiver.ts
:white_check_mark:Succeeded

client/lib/eventPosition.ts
:white_check_mark:Succeeded

client/lib/rhea-promise/connection.ts
:white_check_mark:Succeeded

client/lib/rhea-promise/receiver.ts
:white_check_mark:Succeeded

client/lib/rhea-promise/sender.ts
:white_check_mark:Succeeded

client/lib/rhea-promise/session.ts
:white_check_mark:Succeeded

client/lib/rhea-promise/util/constants.ts
:white_check_mark:Succeeded

client/lib/streamingReceiver.ts
:white_check_mark:Succeeded

processor/.npmignore
:white_check_mark:Succeeded

processor/README.md
:white_check_mark:Succeeded

processor/changelog.md
:white_check_mark:Succeeded

processor/examples/eph.ts
:white_check_mark:Succeeded

processor/examples/js/examples/eph.js
:white_check_mark:Succeeded

processor/examples/multiEph.ts
:white_check_mark:Succeeded

processor/examples/package.json
:white_check_mark:Succeeded

processor/examples/singleEph.ts
:white_check_mark:Succeeded

processor/examples/tsconfig.json
:white_check_mark:Succeeded

processor/lib/azureBlob.ts
:white_check_mark:Succeeded

processor/lib/azureBlobLease.ts
:white_check_mark:Succeeded

processor/lib/azureStorageCheckpointLeaseManager.ts
:white_check_mark:Succeeded

processor/lib/blobLease.ts
:white_check_mark:Succeeded

processor/lib/blobLeaseManager.ts
:white_check_mark:Succeeded

processor/lib/blobService.ts
:white_check_mark:Succeeded

processor/lib/checkpointInfo.ts
:white_check_mark:Succeeded

processor/lib/checkpointManager.ts
:white_check_mark:Succeeded

processor/lib/eventProcessorHost.ts
:white_check_mark:Succeeded

processor/lib/index.ts
:white_check_mark:Succeeded

processor/lib/lease.ts
:white_check_mark:Succeeded

processor/lib/leaseManager.ts
:white_check_mark:Succeeded

processor/lib/log.ts
:white_check_mark:Succeeded

processor/lib/partitionContext.ts
:white_check_mark:Succeeded

processor/lib/partitionManager.ts
:white_check_mark:Succeeded

processor/lib/processorContext.ts
:white_check_mark:Succeeded

processor/lib/util/constants.ts
:white_check_mark:Succeeded

processor/lib/util/utils.ts
:white_check_mark:Succeeded

processor/package-lock.json
:white_check_mark:Succeeded

processor/package.json
:white_check_mark:Succeeded

processor/tests/eph.spec.ts
:white_check_mark:Succeeded

processor/tests/lease.spec.ts
:white_check_mark:Succeeded

processor/tests/leaseManager.spec.ts
:white_check_mark:Succeeded

processor/tests/partitionContext.spec.ts
:white_check_mark:Succeeded

processor/tsconfig.json
:white_check_mark:Succeeded

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

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

client/.npmignore
:white_check_mark:Succeeded

client/README.md
:white_check_mark:Succeeded

client/examples/batchReceive.ts
:white_check_mark:Succeeded

client/examples/batchSendReceive.ts
:white_check_mark:Succeeded

client/examples/simpleSendReceive.ts
:white_check_mark:Succeeded

client/examples/simpleSender.ts
:white_check_mark:Succeeded

client/lib/connectionContext.ts
:white_check_mark:Succeeded

client/lib/eventHubClient.ts
:white_check_mark:Succeeded

client/lib/eventHubReceiver.ts
:white_check_mark:Succeeded

client/lib/eventPosition.ts
:white_check_mark:Succeeded

client/lib/rhea-promise/connection.ts
:white_check_mark:Succeeded

client/lib/rhea-promise/receiver.ts
:white_check_mark:Succeeded

client/lib/rhea-promise/sender.ts
:white_check_mark:Succeeded

client/lib/rhea-promise/session.ts
:white_check_mark:Succeeded

client/lib/rhea-promise/util/constants.ts
:white_check_mark:Succeeded

client/lib/streamingReceiver.ts
:white_check_mark:Succeeded

processor/.npmignore
:white_check_mark:Succeeded

processor/README.md
:white_check_mark:Succeeded

processor/changelog.md
:white_check_mark:Succeeded

processor/examples/eph.ts
:white_check_mark:Succeeded

processor/examples/js/examples/eph.js
:white_check_mark:Succeeded

processor/examples/multiEph.ts
:white_check_mark:Succeeded

processor/examples/package.json
:white_check_mark:Succeeded

processor/examples/singleEph.ts
:white_check_mark:Succeeded

processor/examples/tsconfig.json
:white_check_mark:Succeeded

processor/lib/azureBlob.ts
:white_check_mark:Succeeded

processor/lib/azureBlobLease.ts
:white_check_mark:Succeeded

processor/lib/azureStorageCheckpointLeaseManager.ts
:white_check_mark:Succeeded

processor/lib/blobLease.ts
:white_check_mark:Succeeded

processor/lib/blobLeaseManager.ts
:white_check_mark:Succeeded

processor/lib/blobService.ts
:white_check_mark:Succeeded

processor/lib/checkpointInfo.ts
:white_check_mark:Succeeded

processor/lib/checkpointManager.ts
:white_check_mark:Succeeded

processor/lib/eventProcessorHost.ts
:white_check_mark:Succeeded

processor/lib/index.ts
:white_check_mark:Succeeded

processor/lib/lease.ts
:white_check_mark:Succeeded

processor/lib/leaseManager.ts
:white_check_mark:Succeeded

processor/lib/log.ts
:white_check_mark:Succeeded

processor/lib/partitionContext.ts
:white_check_mark:Succeeded

processor/lib/partitionManager.ts
:white_check_mark:Succeeded

processor/lib/processorContext.ts
:white_check_mark:Succeeded

processor/lib/util/constants.ts
:white_check_mark:Succeeded

processor/lib/util/utils.ts
:white_check_mark:Succeeded

processor/package-lock.json
:white_check_mark:Succeeded

processor/package.json
:white_check_mark:Succeeded

processor/tests/eph.spec.ts
:white_check_mark:Succeeded

processor/tests/lease.spec.ts
:white_check_mark:Succeeded

processor/tests/leaseManager.spec.ts
:white_check_mark:Succeeded

processor/tests/partitionContext.spec.ts
:white_check_mark:Succeeded

processor/tsconfig.json
:white_check_mark:Succeeded

This comment lists only the first 50 files in the pull request.
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

client/.npmignore
:white_check_mark:Succeeded

client/README.md
:white_check_mark:Succeeded

client/examples/batchReceive.ts
:white_check_mark:Succeeded

client/examples/batchSendReceive.ts
:white_check_mark:Succeeded

client/examples/simpleSendReceive.ts
:white_check_mark:Succeeded

client/examples/simpleSender.ts
:white_check_mark:Succeeded

client/lib/connectionContext.ts
:white_check_mark:Succeeded

client/lib/eventData.ts
:white_check_mark:Succeeded

client/lib/eventHubClient.ts
:white_check_mark:Succeeded

client/lib/eventHubReceiver.ts
:white_check_mark:Succeeded

client/lib/eventPosition.ts
:white_check_mark:Succeeded

client/lib/index.ts
:white_check_mark:Succeeded

client/lib/rhea-promise/connection.ts
:white_check_mark:Succeeded

client/lib/rhea-promise/receiver.ts
:white_check_mark:Succeeded

client/lib/rhea-promise/sender.ts
:white_check_mark:Succeeded

client/lib/rhea-promise/session.ts
:white_check_mark:Succeeded

client/lib/rhea-promise/util/constants.ts
:white_check_mark:Succeeded

client/lib/streamingReceiver.ts
:white_check_mark:Succeeded

client/tests/eventdata.spec.ts
:white_check_mark:Succeeded

processor/.npmignore
:white_check_mark:Succeeded

processor/README.md
:white_check_mark:Succeeded

processor/changelog.md
:white_check_mark:Succeeded

processor/examples/eph.ts
:white_check_mark:Succeeded

processor/examples/js/examples/eph.js
:white_check_mark:Succeeded

processor/examples/multiEph.ts
:white_check_mark:Succeeded

processor/examples/package.json
:white_check_mark:Succeeded

processor/examples/singleEph.ts
:white_check_mark:Succeeded

processor/examples/tsconfig.json
:white_check_mark:Succeeded

processor/lib/azureBlob.ts
:white_check_mark:Succeeded

processor/lib/azureBlobLease.ts
:white_check_mark:Succeeded

processor/lib/azureStorageCheckpointLeaseManager.ts
:white_check_mark:Succeeded

processor/lib/blobLease.ts
:white_check_mark:Succeeded

processor/lib/blobLeaseManager.ts
:white_check_mark:Succeeded

processor/lib/blobService.ts
:white_check_mark:Succeeded

processor/lib/checkpointInfo.ts
:white_check_mark:Succeeded

processor/lib/checkpointManager.ts
:white_check_mark:Succeeded

processor/lib/eventProcessorHost.ts
:white_check_mark:Succeeded

processor/lib/index.ts
:white_check_mark:Succeeded

processor/lib/lease.ts
:white_check_mark:Succeeded

processor/lib/leaseManager.ts
:white_check_mark:Succeeded

processor/lib/log.ts
:white_check_mark:Succeeded

processor/lib/partitionContext.ts
:white_check_mark:Succeeded

processor/lib/partitionManager.ts
:white_check_mark:Succeeded

processor/lib/processorContext.ts
:white_check_mark:Succeeded

processor/lib/util/constants.ts
:white_check_mark:Succeeded

processor/lib/util/utils.ts
:white_check_mark:Succeeded

processor/package-lock.json
:white_check_mark:Succeeded

processor/package.json
:white_check_mark:Succeeded

processor/tests/eph.spec.ts
:white_check_mark:Succeeded

processor/tests/lease.spec.ts
:white_check_mark:Succeeded

This comment lists only the first 50 files in the pull request.
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

client/.npmignore
:white_check_mark:Succeeded

client/README.md
:white_check_mark:Succeeded

client/examples/batchReceive.ts
:white_check_mark:Succeeded

client/examples/batchSendReceive.ts
:white_check_mark:Succeeded

client/examples/simpleSendReceive.ts
:white_check_mark:Succeeded

client/examples/simpleSender.ts
:white_check_mark:Succeeded

client/lib/connectionContext.ts
:white_check_mark:Succeeded

client/lib/eventData.ts
:white_check_mark:Succeeded

client/lib/eventHubClient.ts
:white_check_mark:Succeeded

client/lib/eventHubReceiver.ts
:white_check_mark:Succeeded

client/lib/eventPosition.ts
:white_check_mark:Succeeded

client/lib/index.ts
:white_check_mark:Succeeded

client/lib/rhea-promise/connection.ts
:white_check_mark:Succeeded

client/lib/rhea-promise/receiver.ts
:white_check_mark:Succeeded

client/lib/rhea-promise/sender.ts
:white_check_mark:Succeeded

client/lib/rhea-promise/session.ts
:white_check_mark:Succeeded

client/lib/rhea-promise/util/constants.ts
:white_check_mark:Succeeded

client/lib/streamingReceiver.ts
:white_check_mark:Succeeded

client/tests/eventdata.spec.ts
:white_check_mark:Succeeded

processor/.npmignore
:white_check_mark:Succeeded

processor/README.md
:white_check_mark:Succeeded

processor/changelog.md
:white_check_mark:Succeeded

processor/examples/eph.ts
:white_check_mark:Succeeded

processor/examples/js/examples/eph.js
:white_check_mark:Succeeded

processor/examples/multiEph.ts
:white_check_mark:Succeeded

processor/examples/package.json
:white_check_mark:Succeeded

processor/examples/singleEph.ts
:white_check_mark:Succeeded

processor/examples/tsconfig.json
:white_check_mark:Succeeded

processor/lib/azureBlob.ts
:white_check_mark:Succeeded

processor/lib/azureBlobLease.ts
:white_check_mark:Succeeded

processor/lib/azureStorageCheckpointLeaseManager.ts
:white_check_mark:Succeeded

processor/lib/blobLease.ts
:white_check_mark:Succeeded

processor/lib/blobLeaseManager.ts
:white_check_mark:Succeeded

processor/lib/blobService.ts
:white_check_mark:Succeeded

processor/lib/checkpointInfo.ts
:white_check_mark:Succeeded

processor/lib/checkpointManager.ts
:white_check_mark:Succeeded

processor/lib/eventProcessorHost.ts
:white_check_mark:Succeeded

processor/lib/index.ts
:white_check_mark:Succeeded

processor/lib/lease.ts
:white_check_mark:Succeeded

processor/lib/leaseManager.ts
:white_check_mark:Succeeded

processor/lib/log.ts
:white_check_mark:Succeeded

processor/lib/partitionContext.ts
:white_check_mark:Succeeded

processor/lib/partitionManager.ts
:white_check_mark:Succeeded

processor/lib/processorContext.ts
:white_check_mark:Succeeded

processor/lib/util/constants.ts
:white_check_mark:Succeeded

processor/lib/util/utils.ts
:white_check_mark:Succeeded

processor/package-lock.json
:white_check_mark:Succeeded

processor/package.json
:white_check_mark:Succeeded

processor/tests/eph.spec.ts
:white_check_mark:Succeeded

processor/tests/lease.spec.ts
:white_check_mark:Succeeded

This comment lists only the first 50 files in the pull request.
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

client/.npmignore
:white_check_mark:Succeeded

client/README.md
:white_check_mark:Succeeded

client/examples/batchReceive.ts
:white_check_mark:Succeeded

client/examples/batchSendReceive.ts
:white_check_mark:Succeeded

client/examples/simpleSendReceive.ts
:white_check_mark:Succeeded

client/examples/simpleSender.ts
:white_check_mark:Succeeded

client/lib/connectionContext.ts
:white_check_mark:Succeeded

client/lib/eventData.ts
:white_check_mark:Succeeded

client/lib/eventHubClient.ts
:white_check_mark:Succeeded

client/lib/eventHubReceiver.ts
:white_check_mark:Succeeded

client/lib/eventPosition.ts
:white_check_mark:Succeeded

client/lib/index.ts
:white_check_mark:Succeeded

client/lib/rhea-promise/connection.ts
:white_check_mark:Succeeded

client/lib/rhea-promise/receiver.ts
:white_check_mark:Succeeded

client/lib/rhea-promise/sender.ts
:white_check_mark:Succeeded

client/lib/rhea-promise/session.ts
:white_check_mark:Succeeded

client/lib/rhea-promise/util/constants.ts
:white_check_mark:Succeeded

client/lib/streamingReceiver.ts
:white_check_mark:Succeeded

client/tests/eventdata.spec.ts
:white_check_mark:Succeeded

processor/.npmignore
:white_check_mark:Succeeded

processor/README.md
:white_check_mark:Succeeded

processor/changelog.md
:white_check_mark:Succeeded

processor/examples/eph.ts
:white_check_mark:Succeeded

processor/examples/js/examples/eph.js
:white_check_mark:Succeeded

processor/examples/multiEph.ts
:white_check_mark:Succeeded

processor/examples/package.json
:white_check_mark:Succeeded

processor/examples/singleEph.ts
:white_check_mark:Succeeded

processor/examples/tsconfig.json
:white_check_mark:Succeeded

processor/lib/azureBlob.ts
:white_check_mark:Succeeded

processor/lib/azureBlobLease.ts
:white_check_mark:Succeeded

processor/lib/azureStorageCheckpointLeaseManager.ts
:white_check_mark:Succeeded

processor/lib/blobLease.ts
:white_check_mark:Succeeded

processor/lib/blobLeaseManager.ts
:white_check_mark:Succeeded

processor/lib/blobService.ts
:white_check_mark:Succeeded

processor/lib/checkpointInfo.ts
:white_check_mark:Succeeded

processor/lib/checkpointManager.ts
:white_check_mark:Succeeded

processor/lib/eventProcessorHost.ts
:white_check_mark:Succeeded

processor/lib/index.ts
:white_check_mark:Succeeded

processor/lib/lease.ts
:white_check_mark:Succeeded

processor/lib/leaseManager.ts
:white_check_mark:Succeeded

processor/lib/log.ts
:white_check_mark:Succeeded

processor/lib/partitionContext.ts
:white_check_mark:Succeeded

processor/lib/partitionManager.ts
:white_check_mark:Succeeded

processor/lib/processorContext.ts
:white_check_mark:Succeeded

processor/lib/util/constants.ts
:white_check_mark:Succeeded

processor/lib/util/utils.ts
:white_check_mark:Succeeded

processor/package-lock.json
:white_check_mark:Succeeded

processor/package.json
:white_check_mark:Succeeded

processor/tests/eph.spec.ts
:white_check_mark:Succeeded

processor/tests/lease.spec.ts
:white_check_mark:Succeeded

This comment lists only the first 50 files in the pull request.
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

client/.npmignore
:white_check_mark:Succeeded

client/README.md
:white_check_mark:Succeeded

client/examples/batchReceive.ts
:white_check_mark:Succeeded

client/examples/batchSendReceive.ts
:white_check_mark:Succeeded

client/examples/simpleSendReceive.ts
:white_check_mark:Succeeded

client/examples/simpleSender.ts
:white_check_mark:Succeeded

client/lib/connectionContext.ts
:white_check_mark:Succeeded

client/lib/eventData.ts
:white_check_mark:Succeeded

client/lib/eventHubClient.ts
:white_check_mark:Succeeded

client/lib/eventHubReceiver.ts
:white_check_mark:Succeeded

client/lib/eventPosition.ts
:white_check_mark:Succeeded

client/lib/index.ts
:white_check_mark:Succeeded

client/lib/rhea-promise/connection.ts
:white_check_mark:Succeeded

client/lib/rhea-promise/receiver.ts
:white_check_mark:Succeeded

client/lib/rhea-promise/sender.ts
:white_check_mark:Succeeded

client/lib/rhea-promise/session.ts
:white_check_mark:Succeeded

client/lib/rhea-promise/util/constants.ts
:white_check_mark:Succeeded

client/lib/streamingReceiver.ts
:white_check_mark:Succeeded

client/tests/eventdata.spec.ts
:white_check_mark:Succeeded

processor/.npmignore
:white_check_mark:Succeeded

processor/README.md
:white_check_mark:Succeeded

processor/changelog.md
:white_check_mark:Succeeded

processor/examples/eph.ts
:white_check_mark:Succeeded

processor/examples/js/examples/eph.js
:white_check_mark:Succeeded

processor/examples/multiEph.ts
:white_check_mark:Succeeded

processor/examples/package.json
:white_check_mark:Succeeded

processor/examples/singleEph.ts
:white_check_mark:Succeeded

processor/examples/tsconfig.json
:white_check_mark:Succeeded

processor/lib/azureBlob.ts
:white_check_mark:Succeeded

processor/lib/azureBlobLease.ts
:white_check_mark:Succeeded

processor/lib/azureStorageCheckpointLeaseManager.ts
:white_check_mark:Succeeded

processor/lib/blobLease.ts
:white_check_mark:Succeeded

processor/lib/blobLeaseManager.ts
:white_check_mark:Succeeded

processor/lib/blobService.ts
:white_check_mark:Succeeded

processor/lib/checkpointInfo.ts
:white_check_mark:Succeeded

processor/lib/checkpointManager.ts
:white_check_mark:Succeeded

processor/lib/eventProcessorHost.ts
:white_check_mark:Succeeded

processor/lib/index.ts
:white_check_mark:Succeeded

processor/lib/lease.ts
:white_check_mark:Succeeded

processor/lib/leaseManager.ts
:white_check_mark:Succeeded

processor/lib/log.ts
:white_check_mark:Succeeded

processor/lib/partitionContext.ts
:white_check_mark:Succeeded

processor/lib/partitionManager.ts
:white_check_mark:Succeeded

processor/lib/processorContext.ts
:white_check_mark:Succeeded

processor/lib/util/constants.ts
:white_check_mark:Succeeded

processor/lib/util/utils.ts
:white_check_mark:Succeeded

processor/package-lock.json
:white_check_mark:Succeeded

processor/package.json
:white_check_mark:Succeeded

processor/tests/eph.spec.ts
:white_check_mark:Succeeded

processor/tests/lease.spec.ts
:white_check_mark:Succeeded

This comment lists only the first 50 files in the pull request.
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

client/.npmignore
:white_check_mark:Succeeded

client/README.md
:white_check_mark:Succeeded

client/examples/batchReceive.ts
:white_check_mark:Succeeded

client/examples/batchSendReceive.ts
:white_check_mark:Succeeded

client/examples/simpleSendReceive.ts
:white_check_mark:Succeeded

client/examples/simpleSender.ts
:white_check_mark:Succeeded

client/lib/connectionContext.ts
:white_check_mark:Succeeded

client/lib/eventData.ts
:white_check_mark:Succeeded

client/lib/eventHubClient.ts
:white_check_mark:Succeeded

client/lib/eventHubReceiver.ts
:white_check_mark:Succeeded

client/lib/eventPosition.ts
:white_check_mark:Succeeded

client/lib/rhea-promise/connection.ts
:white_check_mark:Succeeded

client/lib/rhea-promise/receiver.ts
:white_check_mark:Succeeded

client/lib/rhea-promise/sender.ts
:white_check_mark:Succeeded

client/lib/rhea-promise/session.ts
:white_check_mark:Succeeded

client/lib/rhea-promise/util/constants.ts
:white_check_mark:Succeeded

client/lib/streamingReceiver.ts
:white_check_mark:Succeeded

client/tests/eventdata.spec.ts
:white_check_mark:Succeeded

processor/.npmignore
:white_check_mark:Succeeded

processor/README.md
:white_check_mark:Succeeded

processor/changelog.md
:white_check_mark:Succeeded

processor/examples/eph.ts
:white_check_mark:Succeeded

processor/examples/js/examples/eph.js
:white_check_mark:Succeeded

processor/examples/multiEph.ts
:white_check_mark:Succeeded

processor/examples/package.json
:white_check_mark:Succeeded

processor/examples/singleEph.ts
:white_check_mark:Succeeded

processor/examples/tsconfig.json
:white_check_mark:Succeeded

processor/lib/azureBlob.ts
:white_check_mark:Succeeded

processor/lib/azureBlobLease.ts
:white_check_mark:Succeeded

processor/lib/azureStorageCheckpointLeaseManager.ts
:white_check_mark:Succeeded

processor/lib/blobLease.ts
:white_check_mark:Succeeded

processor/lib/blobLeaseManager.ts
:white_check_mark:Succeeded

processor/lib/blobService.ts
:white_check_mark:Succeeded

processor/lib/checkpointInfo.ts
:white_check_mark:Succeeded

processor/lib/checkpointManager.ts
:white_check_mark:Succeeded

processor/lib/eventProcessorHost.ts
:white_check_mark:Succeeded

processor/lib/index.ts
:white_check_mark:Succeeded

processor/lib/lease.ts
:white_check_mark:Succeeded

processor/lib/leaseManager.ts
:white_check_mark:Succeeded

processor/lib/log.ts
:white_check_mark:Succeeded

processor/lib/partitionContext.ts
:white_check_mark:Succeeded

processor/lib/partitionManager.ts
:white_check_mark:Succeeded

processor/lib/processorContext.ts
:white_check_mark:Succeeded

processor/lib/util/constants.ts
:white_check_mark:Succeeded

processor/lib/util/utils.ts
:white_check_mark:Succeeded

processor/package-lock.json
:white_check_mark:Succeeded

processor/package.json
:white_check_mark:Succeeded

processor/tests/eph.spec.ts
:white_check_mark:Succeeded

processor/tests/lease.spec.ts
:white_check_mark:Succeeded

processor/tests/leaseManager.spec.ts
:white_check_mark:Succeeded

This comment lists only the first 50 files in the pull request.
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Error deleting services when running Kong with Cassandra database

Summary
When using Kong with Cassandra database and without enabling oauth2 plugin, the service deletion is throwing error. The Cassandra service deletion is trying to cascade delete the service from oauth2_tokens and oauth2_authorization_codes tables here, since the oauth2 plugin is not enabled those tables are missing and executing a DELETE statement with missing tables is causing an error.
Steps To Reproduce

Run Kong with Cassandra database and don't include oauth2 plugin in KONG_PLUGINS

# Start Cassandra docker instance
docker run -d --name kong-database -p 9042:9042 cassandra:3

# Run Kong migrations without oauth2 plugin
docker run --rm \
    --link kong-database:kong-database \
    -e "KONG_DATABASE=cassandra" \
    -e "KONG_CASSANDRA_CONTACT_POINTS=kong-database" \
    -e "KONG_PLUGINS=prometheus" \
    -e "KONG_DB_UPDATE_PROPAGATION=3" \
    kong:0.14.1-centos kong migrations up

# Run Kong without oauth2 plugin
docker run -d --name kong \
    --link kong-database:kong-database \
    -e "KONG_DATABASE=cassandra" \
    -e "KONG_CASSANDRA_CONTACT_POINTS=kong-database" \
    -e "KONG_DB_UPDATE_PROPAGATION=3" \
    -e "KONG_ADMIN_LISTEN=<IP_ADDRESS>:8001" \
    -e "KONG_PROXY_ACCESS_LOG=/dev/stdout" \
    -e "KONG_ADMIN_ACCESS_LOG=/dev/stdout" \
    -e "KONG_PROXY_ERROR_LOG=/dev/stderr" \
    -e "KONG_ADMIN_ERROR_LOG=/dev/stderr" \
    -e "KONG_PLUGINS=prometheus" \
    -p 8000:8000 \
    -p 8443:8443 \
    -p 8001:8001 \
    -p 8444:8444 \
    kong:0.14.1-centos

Create a service using the admin api

curl -X POST http://localhost:8001/services \
  -H 'Content-Type: application/json' \
  -d '{
    "host": "localhost",
    "connect_timeout": 600000,
    "protocol": "http",
    "name": "test",
    "read_timeout": 600000,
    "port": 9000,
    "path": null,
    "retries": 0,
    "write_timeout": 60000
}'

Delete the above service using the admin API

curl -X DELETE http://localhost:8001/services/test

The service gets deleted but responds with 500 Internal Server Error

{"message":"An unexpected error occurred"}

Additional Details & Logs

Kong version (0.14.1)
Kong error logs

2018/10/25 18:45:04 [error] 41#0: *2062 lua coroutine: runtime error: .../share/lua/5.1/kong/db/strategies/cassandra/services.lua:35: attempt to get length of local 'entities' (a nil value)
stack traceback:
coroutine 0:
	.../share/lua/5.1/kong/db/strategies/cassandra/services.lua: in function 'delete_cascade'
	.../share/lua/5.1/kong/db/strategies/cassandra/services.lua:64: in function 'delete_by_field'
	/usr/local/share/lua/5.1/kong/db/dao/init.lua:198: in function 'delete_entity'
	/usr/local/share/lua/5.1/kong/api/endpoints.lua:340: in function </usr/local/share/lua/5.1/kong/api/endpoints.lua:339>
coroutine 1:
	[C]: in function 'resume'
	/usr/local/share/lua/5.1/lapis/application.lua:393: in function 'handler'
	/usr/local/share/lua/5.1/lapis/application.lua:130: in function 'resolve'
	/usr/local/share/lua/5.1/lapis/application.lua:161: in function </usr/local/share/lua/5.1/lapis/application.lua:159>
	[C]: in function 'xpcall'
	/usr/local/share/lua/5.1/lapis/application.lua:159: in function 'dispatch'
	/usr/local/share/lua/5.1/lapis/nginx.lua:215: in function 'serve_admin_api'
	content_by_lua(nginx-kong.conf:167):2: in function <content_by_lua(nginx-kong.conf:167):1>, client: <IP_ADDRESS>, server: kong_admin, request: "DELETE /services/test HTTP/1.1", host: "localhost:8001"
2018/10/25 18:45:04 [error] 41#0: *2062 [lua] init.lua:133: handle_error(): /usr/local/share/lua/5.1/lapis/application.lua:397: .../share/lua/5.1/kong/db/strategies/cassandra/services.lua:35: attempt to get length of local 'entities' (a nil value)
stack traceback:
	.../share/lua/5.1/kong/db/strategies/cassandra/services.lua: in function 'delete_cascade'
	.../share/lua/5.1/kong/db/strategies/cassandra/services.lua:64: in function 'delete_by_field'
	/usr/local/share/lua/5.1/kong/db/dao/init.lua:198: in function 'delete_entity'
	/usr/local/share/lua/5.1/kong/api/endpoints.lua:340: in function </usr/local/share/lua/5.1/kong/api/endpoints.lua:339>

stack traceback:
	[C]: in function 'error'
	/usr/local/share/lua/5.1/lapis/application.lua:397: in function 'handler'
	/usr/local/share/lua/5.1/lapis/application.lua:130: in function 'resolve'
	/usr/local/share/lua/5.1/lapis/application.lua:161: in function </usr/local/share/lua/5.1/lapis/application.lua:159>
	[C]: in function 'xpcall'
	/usr/local/share/lua/5.1/lapis/application.lua:159: in function 'dispatch'
	/usr/local/share/lua/5.1/lapis/nginx.lua:215: in function 'serve_admin_api'
	content_by_lua(nginx-kong.conf:167):2: in function <content_by_lua(nginx-kong.conf:167):1>, client: <IP_ADDRESS>, server: kong_admin, request: "DELETE /services/test HTTP/1.1", host: "localhost:8001"
<IP_ADDRESS> - - [25/Oct/2018:18:45:04 +0000] "DELETE /services/test HTTP/1.1" 500 43 "-" "curl/7.54.0"

Operating system(centos:7)

This was resolved in 1.0/1.1, right?

@kikito @bungle ping

Yes, it was fixed here:
https://github.com/Kong/kong/pull/4409
So closing this.


RuntimeError: Please define environment variable $HOME

Hello, AS I am packaging a software which use spyder, I get this error message
/«BUILDDIR»/taurus-3.7.0+dfsg/doc/source/devel/api/taurus/qt/qtgui/editor.rst:8: WARNING: autodoc: failed to import module u'taurus.qt.qtgui.editor'; the following exception was raised:
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/sphinx/ext/autodoc.py", line 386, in import_object
import(self.modname)
File "/«BUILDDIR»/taurus-3.7.0+dfsg/lib/taurus/qt/qtgui/editor/init.py", line 30, in
from .tauruseditor import *
File "/«BUILDDIR»/taurus-3.7.0+dfsg/lib/taurus/qt/qtgui/editor/tauruseditor.py", line 46, in
from spyderlib.utils.qthelpers import create_toolbutton
File "/usr/lib/python2.7/dist-packages/spyderlib/utils/qthelpers.py", line 24, in
from spyderlib.guiconfig import get_shortcut
File "/usr/lib/python2.7/dist-packages/spyderlib/guiconfig.py", line 22, in
from spyderlib.config import CONF
File "/usr/lib/python2.7/dist-packages/spyderlib/config.py", line 736, in
subfolder=SUBFOLDER, backup=True, raw_mode=True)
File "/usr/lib/python2.7/dist-packages/spyderlib/userconfig.py", line 207, in init
fname = self.filename()
File "/usr/lib/python2.7/dist-packages/spyderlib/userconfig.py", line 143, in filename
folder = get_home_dir()
File "/usr/lib/python2.7/dist-packages/spyderlib/baseconfig.py", line 98, in get_home_dir
raise RuntimeError('Please define environment variable $HOME')
RuntimeError: Please define environment variable $HOME
this is spyder 2.3.8
It seems to me that spyder should work even if the HOME env was not set.
Indeed this is during a chroot build, so it is a little bit weard :)
Cheers
Fred

@picca, Spyder needs $HOME to save its configuration settings. I don't know how to help you because I don't understand how Spyder is used as a library by the project you're packaging.
However, you're welcome to send us a pull request that improves the situation for you.

Closing because of lack of response.


fix: add missing image to main branch

Problem
There is an image that is referenced for one of the blueprints but isn't available in prod
Solution
Bring that image over from the develop branch

Thanks for adding this - not sure how it got deleted but I definitely added this before. Weird.


@flex

@flex-container
Creates a flex container
params
@flex-container;

Doesn't save much by implementing this, since there are so many variables to a flex setup


Update How-to-roll-out-teams.md

Hi, I created suggested changes to the article as discussed with Tina.

Closing pull request


Fix networkstate update behavior (DEV)

The network callback for onUnavailable() is not reliable.
Solution: Just force a refresh on any state change.
Also see:
https://issuetracker.google.com/issues/144891976
According to that ticket, it's fixed in a "future release", but on my Pixel 3a@Android11, it's not :shrug:.
@BMItr noticed this during debugging.

@d4rken its much better than before.
Unfortunally its not as reliable..
e.g. Wifi OFF->ON is detected
Wifi ON->OFF is not detected.
Maybe you have an idea..

e.g. Wifi OFF->ON is detected

This was also working for me before.

Wifi ON->OFF is not detected.

This should be fixed by this PR, on which devices does it happen, and how did you test it?

e.g. Wifi OFF->ON is detected

This was also working for me before.

Wifi ON->OFF is not detected.

This should be fixed by this PR, on which devices does it happen, and how did you test it?

Tested on Pixel 3xl.
There might be no 100%reliable solution...


Fix issues in alpha 2 blog post

Fixes typos
Adds link to PSR-6
Fixes grammar
Links to the live RSS feed (instead of the .test one 😉)

Oh boy, so many mistakes 😅 Thanks!


Compute execution_time only if there is a finished timestamp

Done under the expert guidance of @enykeev

lol :+1: There's likely to be another problem related to the time not getting properly recalculated on execution completion, but that's minor and I'm hoping @emedvedev can take care of that Monday.

Like a pro :P


Makefile:244: recipe for target 'nheqminer' failed

Trying to Build on Google Cloud. I got this error. Any help?
_traits, std::allocator >&, std::locale const&)'
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
Makefile:244: recipe for target 'nheqminer' failed
make: *** [nheqminer] Error 1

Im getting the same issues

Please try Linux branch and reopen if it isn't fixed.


Show information about the workflow run

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
0

Relevant Lines:
3

💛  - Coveralls


Deployment

Description
Stablishing Prettier Config for the Project
Changes

List of specific changes made in this pull request:

Adding Prettier Config
Installing Locally Prettier and fixing package json

Branch Details

Branch: Deployment
Type of Change: feature , fix

Accepted :)


[BUGFIX] Fix return type for getInfo to work with current discord-player changes

Updates discord-player-downloader to reflect the ExtractorModel changes made in https://github.com/Androz2091/discord-player/commit/62bf57ac7482843d4c2694aab7794b881aa6b406#diff-2a0195201cb04efb11714b2999b4db85896c20f7acb91b5037466c86129ffedfL32-R43
Previously would successfully scrape data but wouldn't return it in the format expected by discord-player, resulting in discord-player interpreting it as null data (same as if it was given an invalid link).

Made a slight mistake, typings should be good now.


Make CypherWhereExpressionVisitor class overridable

Hello,
Can you make CypherWhereExpressionVisitor object to be injected in BoltGraphClient ?
I need to modify existing behavior when using StartsWith, Contains and EndsWith and to add Contains functionality for arrays.
Thanks

Hello!
No, that's not something I have the time, or think is right for the client. If you want to do a pull request with the changes in as you see it, I'll see if it fits and whether it would make sense to put it in, but if you're adding functionality which can be used by others (such as 'contains for an array') it would be better for everyone to have it - so a pull request for that would also be welcome!
All the best
Chris


feat(push): restore syntax sugar for repository attribute

It's just handled in the macro, the underlying rule still expects a file of repotags

closing, will just revert #169 instead to restore the user interface with oci_push#repository


How to declare multiple variables?

I am trying to do basic query.
My query is this as a preparedStatement:
'SELECT id, username, email, password FROM users WHERE username=$username AND password=$password'
I am trying to declare double variables. (https://docs.oracle.com/en/database/other-databases/nosql-database/19.5/sqlreferencefornosql/variable-declarations.html)
I am getting error when i declare like that:
DECLARE $username STRING;
DECLARE $password STRING;
in SELECT statement.
I also tried DECLARE $username,$password STRING;
"message": "[ILLEGAL_ARGUMENT] PREPARE: Illegal Argument: Error: at (1, 26) no viable alternative at input 'DECLARE$usernameSTRING;DECLARE', at line 1:26\nrule stack: [parse, statement]"

same as pl/sql done.

Can you send us the error message?  I have working code that does the following:
"DECLARE $param1 STRING; $param2 STRING;\n" +
"SELECT …"

On May 10, 2020, at 9:32 AM, tweenietomatoes<EMAIL_ADDRESS>wrote:
I am trying to do basic query.
My query is this as a preparedStatement:
'SELECT id, username, email, password FROM users WHERE username=$username AND password=$password'
I am trying to declare double variables. (https://docs.oracle.com/en/database/other-databases/nosql-database/19.5/sqlreferencefornosql/variable-declarations.html https://docs.oracle.com/en/database/other-databases/nosql-database/19.5/sqlreferencefornosql/variable-declarations.html)
I am getting error when i declare like that:
DECLARE $username STRING;
DECLARE $password STRING;
in SELECT statement.
I also tried DECLARE $username,$password STRING;
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://urldefense.com/v3/__https://github.com/oracle/nosql-examples/issues/22__;!!GqivPVa7Brio!LMDDQpkmr66WhKcd6GIx64w9SKov15ABy69yirrosbi0P6cK2-Ca_bxIIFMZt0b-$, or unsubscribe https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ABW5UFY7YQOMCOOB2SZPB3LRQ3JLNANCNFSM4M5J5DWA__;!!GqivPVa7Brio!LMDDQpkmr66WhKcd6GIx64w9SKov15ABy69yirrosbi0P6cK2-Ca_bxIIOPIKucA$.

@tweenietomatoes the DECLARE syntax is as following :
variable_declaration ::= DECLARE (variable_name type_definition ";")+
You need to DECLARE only once and you need to separate variables via semicolon
So, the correct syntax would be
DECLARE $username STRING; $password STRING;
select ...
Give it try and let me know

It was my mistake. I solved it by following pl/sql guide of yours.
Thanks for replies.

Glad it worked for you. It would be useful to know what exactly is your use case for NoSQL DB. If possible, please drop me an email - anand dot chandak @oracle dot com (replace dot and spaces)


Escaping quotes causes a parsing error (regression at 9be1403)

(This issue was found via a re-run of the Rug tests.)
At zq commit db76d01 that came right before the changes in #2072 (cc: @mccanne), this was working:
$ zq -version
Version: v0.29.0

$ echo '{"foo": "\"bar\""}' | zq -f zson '\"bar\"' -
{
    foo: "\"bar\""
} (=0)

However, ever since the changes in #2072, this has been a parse error. Here it is failing with current zq at commit 8ea1b4c.
$ zq -version
Version: v0.29.0-75-g8ea1b4c6

$ echo '{"foo": "\"bar\""}' | zq -f zson '\"bar\"' -
zq: parse error: error parsing Z at column 8:
\"bar\"
   === ^ ===

In my attempt to verify the fix, I can see we've made progress, but an example like the one that spawned this issue is not working yet.
Using the test data in the first linked PR and testing with zq commit 3cc324e, we can see that a search term containing a single quote works where it wouldn't have before the fix.
$ zq -version
Version: v0.29.0-80-g3cc324e6

$ cat input.tzng
#0:record[s:string]
0:[foo"bar;]
0:[foobar;]
0:["foobar";]

$ zq -f tzng '"foo\"bar"' input.tzng
#0:record[s:string]
0:[foo"bar;]

However, the one with two quoted strings in it is still a failure.
$ zq -f tzng '\"foobar\"' input.tzng
zq: parse error: error parsing Z at column 11:
\"foobar\"
      === ^ ===

It used to work back before #2072 though.
$ zq -version
Version: v0.29.0

$ zq -f tzng '\"foobar\"' input.tzng
#0:record[s:string]
0:["foobar";]

Well, I'm not sure this is something that we should.   You're putting an escaped quote into an identifier then wanting the search rules to treat the identifier as a string.  The way you get around similar such confusion is to put quotes around the string you want to search for.

In general, we don't have an escape syntax for identifiers...

Maybe I;n thinking about this the wrong way.  We can certainly put escapes in search keywords.

I'm with @mccanne here. It's a bit of a surprise to me that
echo '{"foo": "\"bar\""}' | zq -f zson '\"bar\"' -

produced the same output as
echo '{"foo": "\"bar\""}' | go run ./cmd/zq -f zson '"\"bar\""' -

rather than a parse error prior to #2072.

But whichever direction we decide to go, let's codify as a test before closing this.

Verified in zq commit 99477b6.
Now this works, whereas it was a parse error last time I tried:
$ zq -version
Version: v0.29.0-235-g99477b61

$ cat input.tzng
#0:record[s:string]
0:[foo"bar;]
0:[foobar;]
0:["foobar";]

$ zq -f tzng '\"foobar\"' input.tzng
#0:record[s:string]
0:["foobar";]

Thanks @nwt!


Change requirements.txt to Pipfile

Motivation

Closes #2252

Changes

Test Plan

TODO

[ ] Explain motivation or link existing issue(s)
[ ] Test changes and document test plan
[ ] Update documentation as needed

bors try

bors try

bors try

bors try

bors try

bors try

bors try

bors try

bors try-

bors try-

bors try

bors try

bors try

bors try

try
Build failed:

ci-stage2

Strange, it looks like the tests passed, I wonder why bors reported a failure here - it might be lagging in the data it receives from GH or something.

try
Build failed:

ci-stage2

Strange, it looks like the tests passed, I wonder why bors reported a failure here - it might be lagging in the data it receives from GH or something.

Also when you get a chance please finish filling in the PR description above.

Also when you get a chance please finish filling in the PR description above.

bors try

bors try

bors try

bors try

bors try-

bors try-

bors try

bors try

bors merge

bors merge

bors merge

bors merge

bors merge

bors merge

bors merge

bors merge


[1577] Use deferral date for withdraw date if deferred

Context

https://trello.com/c/5UK9osuw/1577-s-dev-use-deferral-date-as-withdrawal-date-where-a-deferred-trainee-is-withdrawing

Changes proposed in this pull request

Use the deferral date as the withdrawal date when withdrawing a trainee that's been deferred.

Guidance to review

Load a deferred trainee and withdraw them
Assert the date is set to the deferral date

Can we suppress the change link on the summary card for the date?

 [S] Dev: use deferral date as withdrawal date where a deferred trainee is withdrawing


Cannot reproduce SAR-RL results in the MyoLeg Hilly Locomotion task

This is the performance I am getting when trying the ICAPCA approach with phi = 1 and phi = 0.66.
It is clearly worse compared to the results published in the paper. To be sure that the worse results are not due to something I did wrong in the play phase,  I took the precomputed SAR values that are provided in this repository.
Below I provide the results given in the paper. As you can see my results are falling significantly short of the ones provided in the paper.

Hi @dhruv-sarkar, a few suggestions for troubleshooting this:

Have you tried rendering the policies and seeing if the agent/environment behavior looks reasonable? This could help us determine where the problem is. I personally recall getting results quite similar to this when there was an issue with the contacts in the environment (the agent was stepping 'through' the ground).
There will be seed-to-seed variation, consider running them again if 1. doesn't reveal an obvious issue.
Try running the precomputed SAR on a different related environment and see if it still isn't working.

I can try to help again once you've given 1-3 a try if the issue is still not resolved at that point. Miscellaneous note: the environments may have changed slightly since the paper—consider getting SAR from scratch if this is indeed the case. Hope this helps.

Thanks @camberg23 for taking care to write such a detailed reply.

Have you tried rendering the policies and seeing if the agent/environment behavior looks reasonable? This could help us determine where the problem is. I personally recall getting results quite similar to this when there was an issue with the contacts in the environment (the agent was stepping 'through' the ground).

I have tried 1 and yes the agent seems to have a contact problem. What's the next step?

@cameronberg -- If we suspect code regression, can you also point out the commit hash where the results worked at your end. @dhruv-sarkar -- it might be a good idea to check that hash at your end before we go ahead about fixing the latest version.

Hi @dhruv-sarkar ! this might have been due to issues with the height field in MuJoCo. We pushed fixes to this to the GitHub repo. See https://github.com/MyoHub/myosuite/commit/bdb973ac655e0596a7040e5d9758e525109117e6.
Try installing myosuite by cloning from GitHub and please test if the performance improves!
We would be glad to hear back from you.

Sure. I tried running the experiments on the various terrains with precomputed SAR and these are the various results I got.

I think that is reasonable. I am also attaching the videos in case someone is curious.
https://github.com/MyoHub/myosuite/assets/121563009/d2e84739-f498-429e-8150-5b28d8c5427b
https://github.com/MyoHub/myosuite/assets/121563009/b95e04c8-4d0d-4521-ba7a-b0d4698e4f8b
https://github.com/MyoHub/myosuite/assets/121563009/32e11100-5475-43ee-920b-22e7ae9dbba8
So are we good to close this issue?

Looks close enough to the original score for me. @Vittorio-Caggiano  can be closed right? I'm not the SAR expert.

@dhruv-sarkar thanks for the update and for following up on this issue. Were those results obtained with the standard tutorial/seed or did you need to make any change?

@Vittorio-Caggiano I did not need to make any change. In fact I even used the precomputed SAR given in the repo to generate these results. This perhaps shows that even the precomputed SAR that has been provided is still relevant.

sg... we can then close the issue.
thanks again @dhruv-sarkar for following through on this issue!

@dhruv-sarkar  Hello, have u ever tried to reproduce SAR-RL results in the Myohand reorient task?

@dhruv-sarkar Hello, have u ever tried to reproduce SAR-RL results in the Myohand reorient task?

@Baliencasia No. Unfortunately, I haven't tried reproducing on Myohand reorient task.


Add some concrete examples of possible TAML usage

Demonstrate a hypothetical use of TAML by converting the following to TAML documents with appropriate documentation accompanying:

[ ] package.json
[ ] appsettings.json
[ ] Kubernetes YML doc?
[ ] GitHub workflow YML?

I've just tried to do something with a GitHub Workflow YAML file and came across an issue that I have written up in https://github.com/csharpfritz/TAML/issues/26#issuecomment-695839056

I have a simple appsettings.taml here:
Logging
	LogLevel
		Default				Information
		Microsoft			Warning
		Microsoft.Hosting.Lifetime	Information

AllowedHosts	*

The JSON original would be:
{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information"
    }
  },
  "AllowedHosts": "*"
}

Where would it be best for these files to be located and in the instances where a 1:1 mapping is undesirable/not yet possible would it be worth us still having an example and just noting that you would need a specific converter to make it work (until we get schemas done at least)

As can be seen above, I proposed a spot for those files to live and started a PR on a separate branch for the files. Cfritz was broadcasting and pushing to the repo at the time so its out of sync with master, I'll wait until the end of the stream to fix.

Added Kubernetes and GitHub actions sample docs in the concrete_samples folder


fix(resolver): Treat unset MSRV as compatible

What does this PR try to resolve?
Have the resolver treat no-MSRV as rust-version = "*", like cargo add does for version-requirement selection
How should we test and review this PR?
We last tweaked this logic in #13066.
However, we noticed this was inconsistent with cargo add in automatically selecting version requirements.
It looks like this is a revert of #13066, taking us back to the behavior in #12950.
In #12950 there was a concern about the proliferation of no-MSRV and whether we should de-prioritize those to make the chance of success more likely.
There are no right answes here, only which wrong answer is ok enough.

Do we treat lack of rust version as rust-version = "*" as some people expect or do we try to be smart?
If a user adds or removes rust-version, how should that affect the priority?

One piece of new information is that the RFC for this has us trying to fill the no-MSRV gap with
rust-version = some-value-representing-the-current-toolchain>.
See also https://github.com/rust-lang/cargo/issues/9930#issuecomment-1977471059
r? @Eh2406
Additional information

I wish we had taken better notes about what problems #13066 fixed. I remember feeling strongly about it at the time.
Let me try and reconstructed through brute force. There are three categories of compatibility Incompatible (I), None (N) and, Compatible (C). Which leads to six possible release orders.

If C is the most recent then we should obviously pick that one. The highest version release has a compatible MSRV, there is no reason to look at an older one. (Oldest to newest INC and NIC).
If I is the most recent then we should look an the next older. The most recent release has told us it won't work, so we should try something else. This is also a normal situation, the package has an MSRV policy which has updated past our needs. (Oldest to newest NCI and CNI).
If N is the most recent then the library has removed its MSRV policy. Do we try it because the library has made no statement, or do we go back to an older version where the library promised to work? If we grab an old version, then removing a MSRV policy is a decision that cargo (the tool) will actively fight you on. (Oldest to newest ICN and CIN).

The think about it differently:

Older
Newer
main
PR

N
C
C
C

I
C
C
C

C
I
C
C

N
I
N
N

C
N
C
C

I
N
N
N

main tested with https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=da9fa93b2cb04c29d85f3384f42ad147
pr tested with https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=2435818bb3868c54b6edda33ebffa26d
So clearly I've done something wrong because they both always agree. Feel free to correct my table (and my testing examples) when you spot the problem.

I wish we had taken better notes about what problems https://github.com/rust-lang/cargo/pull/13066 fixed. I remember feeling strongly about it at the time.

One change from when we had that conversation is that we had a lot less clear of a picture of how to deal with not enough data to make good choices.  Since then, the RFC evolved to include rust-version = "<current-toolchain>" which helped close some of that gap (on top of any second order effects from making it easier to deal with MSRVs).

So clearly I've done something wrong because they both always agree. Feel free to correct my table (and my testing examples) when you spot the problem.

I'll have to come back later to dig into this.  I think the core of the problem is when there are at least 3 versions involved, rather than just 2.

After dinner the problem became obvious, and a better design for the script also seems worth doing. The table has been updated.

To summarize, when upgrading from an MSRV compatible to an unset MSRV, we are changing the behavior from "prefer MSRV compatible" to "prefer unset".  The nuance comes in when dealing with what dependents can rely on working for version with an unset MSRV.
Initially

if unset MSRV has an effective MSRV that matches the old versions, then users may prefer that
if unset MSRV has an effective MSRV that is still below the user's, then user may prefer that
if the unset MSRV has an effective MSRV that is above the user's, then the user would prefer the compatible version

However, over time, the user will upgrade their rust version far enough that they won't want a years-old version but one of those mysterious versions.  It could be latest, who knows.

Picking the latest might work
Picking the latest will work but won't make the user happy

However, we may not want to optimize for the case of "moving away from an MSRV"
However, this could send a signal to the user that there is a mismatch in expectations.  The question is how much we want to be policing this.  I lean towards "we shouldn't".

Another angle to this is if the dependency adds back in an MSRV.

If the new MSRV is like the old MSRV and we pick "unset" then you were likely never supported in the first place and I don't care as much
If the new MSRV higher than the old MSRV, this is somewhat like when the MSRV was removed.  It depends on circumstances but will eventually not matter.

From this analysis, I'm finding that I don't care enough about the differences between the two cases which leads me to preferring consistency with cargo add (and i prefer that behavior because it would be a lot messier in that circumstance to support the resolver's current behavior)

Seams convincing.
@bors r+

:pushpin: Commit 89ead6f60eaf733d232eb18db0e31da04ba8b88d has been approved by Eh2406
It is now in the queue for this repository.

:hourglass: Testing commit 89ead6f60eaf733d232eb18db0e31da04ba8b88d with merge 82dca28700173a784fcf1240849075023cf22aba...

:sunny: Test successful - checks-actions
Approved by: Eh2406
Pushing 82dca28700173a784fcf1240849075023cf22aba to master...

I'm glad for the conclusion, but if you view this from the perspective of the crate author I think this wouldn't have been very hard to figure out:
If a crate author publishes a new semver compatible version with an unset MSRV, do they want their users to switch to it? Or do they want people to keep using the older release forever?


sdk/state: may need to add locking to account balances when updating

probably balances will need locking when they're getting updated. Probably should be addressed when we start demoing with high TPS with networking done

I'm not convinced yet that this should be part of state.Channel. I think it is okay for us to say the state.Channel object is not thread safe, and then to provide another type, syncstate.Channel (or some other name), that wraps a state.Channel and makes it thread safe. This keeps the main channel code simpler, and isolates code that will be concerned with concurrency.
Thoughts?


chore: sync upstream

Related Issue(required)

Description(required)

Review Procedure(required)

Related PR(optional)

Pre-Review Checklist for the PR Author
PR Author should check the checkboxes below when creating the PR.

[ ] Read commit-guidelines
[ ] Assign PR to reviewer

If you are adding new package following items are required:

[ ] Documentation with description of the package is available
[ ] A sample launch file and parameter file are available if the package contains executable nodes

Checklist for the PR Reviewer
Reviewers should check the checkboxes below before approval.

[ ] Commits are properly organized and messages are according to the guideline
[ ] PR title describes the changes

Post-Review Checklist for the PR Author
PR Author should check the checkboxes below before merging.

[ ] All open points are addressed and tracked via issues or tickets

CI Checks

Build and test for PR / build-and-test-pr: Required to pass before the merge.
Build and test for PR / clang-tidy-pr: NOT required to pass before the merge. It is up to the reviewer(s). Found false positives? See the [guidelines][clang-tidy-guidelines].
Check spelling: NOT required to pass before the merge. It is up to the reviewer(s). See here if you want to add some words to the spell check dictionary.

git cliff --config ../../autowarefoundation/autoware-github-actions/cliff.toml 3e27b12~..10bd1c0

Changelog
All notable changes to this project will be documented in this file.
[unreleased]
Bug Fixes

[behavior_path] Add minus and comments (#246)
Use transient_local qos for route (#149)
Ring outlier filter bug (#253)
[behavior velocity planner] Occlusion spot slice (#237)
[behavior_path_planner] Add transformation to polygon, obj frame to map frame (#251)
[ndt_scan_matcher] Fix compiler flags and Eigen aligned allocator to support general SIMD architecture (#154)
[lanelet2_extension] Add guard for inner product (#256)
[system_monitor] Fix build error on aarch64 (#263)
[lanelet2_extension] Fix getAngleDifference (#264)
[vehicle_cmd_gate] Fix topic name (#274)
[behavior_velocity_planner] Fix inversion of object orientation in intersection planner (#280)
Typo in localization util.launch.py (#277)
Particle distribution of initial pose estimatation (#278)

Features

[diagnostics_aggregator] Remove map_version diagnostic from configuration (#267)
Port pure_pursuit (#271)
Add covariance param (#281)
Add pose_initializer params (#279)
[route_handler] Better avoidance drivable areas extension in behavior path planning (#285)

Tests

[behavior velocity] Fix unstable gtest (#273)


Create provenance resources in MELD sandbox

When we populate new data in the sandboxes, it will display a Source.
Start with the regular Care Planning sandbox.

The data is in the sandbox but it's not displaying. Not sure if this is the case because of the CQL or because of how the data is set up.
Sean to ask @drdavec

@swmuir, which MELD sandbox are you using to test this?  I looked at "Care Planning" to review the Provenance resources, but there are no Provenance resources in this sandbox.

@drdavec
https://gw.interop.community/MCCDevelopment/data
Provenance?target=Condition/mcc-cond-pnoelle-hypertension
This also pulls it in
Condition?patient=mcc-pat-pnoelle&_revinclude=Provenance:target
I am getting the fhir blob but the CQL does not seem to find it when processing

@swmuir is adding @drdavec to Develop sandbox to review.

The Provenance resource display is now working in MELD CarePlanning sandbox and can be tested there.  Provenance source is displayed for Hypertension and Dyslipidemia conditions.  I found these issues:

The example Provenance in MCC Development sandbox used a target reference = "Condition/mcc-cond-pnoelle-hypertension/_history/1".  Remove the version-specific "/history/1" suffix.  The CQL logic cannot resolve this history version reference, and I've never seen any EHR system FHIR API that supports history queries, so we won't see this from Epic.

I added two new Provenance resources for hypertension and dyslipidemia using a Provenance resource template that is exactly what we will see from Epic production systems. I recommend using this template for additional samples because it is based on US Core requirements for two agents: author and transmitter.  And CQL is designed to support this agent style.  See attached sample (also in MCC Development and Care Planning sandboxes).

The provenance source still was not displayed.  I found and fixed a bug where MyCarePlanner used a query format of "&_revInclude" (with a capital I) instead of "&_revinclude" (with lower-case i).  The upper-case I works for Epic, but is ignored by MELD.  I committed this change to develop branch.

I added patient/Provenance.read to the MELD scope.  I committed this change to develop branch, and updated the MyCarePlanner scope in CarePlanning sandbox.

Provenance source is now displayed correctly in CarePlanning sandbox.  Pull and rebuild the app using changed I committed to develop branch to update MCC Development sandbox.
mcc-provenance-pnoelle-hypertension.json.txt

@swmuir to rebuild and redeploy. It's on the develop branch.

@kbertodatti to test in Develop sandbox. Hypertension and Dyslipidemia.


Rebase BeaconBlockBodyMerge on top of BeaconBlockBodyAltair

PR Description

Extract BeaconBlockBody* and BeaconBlockBodySchema* interfaces to make possible Phase0 -> Altair -> Merge -> ... structures inheritance
Rebase BeaconBlockBodyMerge on top of BeaconBlockBodyAltair

Part of implementation for #4351

Hm... Now I'm not so sure if that inheritance actually makes sense. Some field might be removed at some fork and inheritance couldn't be applied.
I also see that other structures don't inherit from phase0 to altair.

From the other side making BeaconStateMerge without inheriting BeaconStateAltair would require a lot of Altair logic to be copy-and-pasted from altair to merge version. So I'm currently sticking to inherit where possible. Not an ideal solution but for now seems to be better than copy-pasting.

Merging this into the merge-interop branch via: https://github.com/ConsenSys/teku/pull/4352

Closing this to continue on branch https://github.com/ConsenSys/teku/tree/merge-interop


feat(fluent-ui-release): Address High Contrast Mode A11y Bugs

Details
This PR addresses High Contrast Mode bugs identified in our recent accessibility pass:

[x] Assessment does not correctly apply contrast colors:

[x]  side nav buttons

[x] target page link

[x]save/load button borders Fluent's colors are fine
[x] failure instance edit/delete buttons

[x] Tab stops undo/add instance buttons Fluent's colors are fine
[x] Launch pad buttons to fastpass/assessment/ad-hoc tools

[x] Adhoc tools back to launch pad link

Motivation
Feature Work
Context
FluentUI treats some controls differently than Fabric used to when in OS-level high contrast mode. We've made the decision to defer to Fluent's treatment of specific colors (e.g. button borders, undo button color are different between this PR and production) but needed to explicitly override forced-color-adjust: none in several places to allow colors to be changed for high contrast mode. For this, I created a mixin that can be included in components where overriding is necessary.
This is a similar challenge as is described in discussion about Fluent UI's approach to high contrast in components here.
Pull request checklist

[x] Ran yarn fastpass
[x] PR title AND final merge commit title both start with a semantic tag (fix:, chore:, feat(feature-name):, refactor:). See CONTRIBUTING.md.
[x] (UI changes only) Added screenshots/GIFs to description above

Codecov Report

:exclamation: No coverage uploaded for pull request base (fluentuiV8-migration@5df4576). Click here to learn what that means.
The diff coverage is n/a.

:exclamation: Current head 7edd3cc differs from pull request most recent head a172340. Consider uploading reports for the commit a172340 to get more accurate results

@@                   Coverage Diff                   @@
##             fluentuiV8-migration     #196   +/-   ##
=======================================================
  Coverage                        ?   94.41%
=======================================================
  Files                           ?     1266
  Lines                           ?    19126
  Branches                        ?     1438
=======================================================
  Hits                            ?    18058
  Misses                          ?      969
  Partials                        ?       99

Continue to review full report at Codecov.

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


⚠ Samsung has degraded performance

In 847a02d, Samsung (https://samsung.com) experienced degraded performance:

HTTP code: 200
Response time: 2844 ms

Resolved: Samsung performance has improved in 8022158.


Potential Vulnerability in one of the dependencies

Working with the nodejs Console Echobot sample. I committed package-locked.json file into one of my own repos and then GitHub notified me of a potential vulnerability. Adding the screenshots here, as a heads-up and in case anything needs to be updated.
Package - https://github.com/Microsoft/BotBuilder-Samples/blob/v4/javascript_nodejs/01.console-echobot/package-lock.json#L279

the above PR addresses the issue.


Origin/feat/#200 Room loading error fix

Purpose of this PR:
Error : Cannot load scene: Invalid scene name (empty string) and invalid build index -1
most of the time there is no error but sometimes this error occurs.
How to test:
now when the scene changes there's no error.
links:
https://github.com/SillyBusinessInc/Moldbreaker/issues/200

@tessakang plzz be carfull what you safe when safing a scene.
You removed the UI from the base scene, but that should stay ofcourse. I added it back again since it was not that difficult, but jutst keep that in mind


Decouple the usage of model_path in model train

Presently, the usage of the model_path parameter in ilab train is split between different responsibilities:

Used as a HuggingFace model reference, e.g. <namespace>/<repo-name>
Used to reference where the local model will be saved and read from

These should be different parameters to decouple responsibility.

Related to #1871


Please add Arbitrum Sepolia chainId to assets list

Please add chainId= 421614 to the assets list

@bertux @develCuy @liliya-soroka @katspaugh please check

Hey @IvanKodak , you can deploy it by following the instructions in https://github.com/safe-global/safe-smart-account
The team is currently not deploying contracts to other networks as the demand is magnitudes larger than the capacity.

@mmv08 contract already deployed, the issue is about adding arbitrum sepolia chainId to assets list

@mmv08 contract already deployed, the issue is about adding arbitrum sepolia chainId to assets list

you can create a pr in this case


bring back dev scripts for ballista

Which issue does this PR close?
bring back dev scripts for ballista
Closes #.
Rationale for this change

What changes are included in this PR?
i did a run in dev/ using
rg --files-with-matches ballista

to identify any dev files mentioning ballista
Are there any user-facing changes?

fyi @yjshen


nuxt3.7  nitro,devProxy not available

Environment
nuxt3.7
Reproduction
nuxt3.7
Describe the bug
nitro: {
devProxy: {
"/dev": {
target: "https://xxxxx.com",
changeOrigin: true,
prependPath: true,
},
},
},
The proxy is unavailable, has the proxy method been updated?
Additional context
No response
Logs
No response

This was a bug with the underlying httpxy package used for proxying. It's been fixed in version 0.1.4, and updating to that version solved the issue for me 🙂

这是用于代理的底层 httpxy 包的错误。它已在 0.1.4 版中修复，更新到该版本为我🙂解决了问题

This was a bug with the underlying httpxy package used for proxying. It's been fixed in version 0.1.4, and updating to that version solved the issue for me 🙂

Thank you very much, it can be used normally after the upgrade, I am very happy


Right click fires other events

This is copy of this issue: https://github.com/SAP/openui5/issues/3936 and https://github.com/SAP/openui5/issues/3973 as I didn't get any response there. Might be helpful to read it initially.
OpenUI5 version: latest (1.129.0)
Browser/version (+device/version): Chrome, Firefox, Safari (all on MacOS)
URL (minimal example if possible):
https://harelyshau.dev/#/games/minesweeper (most priority for me)
https://openui5.hana.ondemand.com/entity/sap.m.IconTabBar/sample/sap.m.sample.IconTabBar
https://openui5.hana.ondemand.com/entity/sap.tnt.ToolHeader/sample/sap.tnt.sample.ToolHeaderIconTabHeader
Steps to reproduce the problem:
For custom button:

Go to this link: https://harelyshau.dev/#/minesweeper
Left click to any cell

Right click to any closed cell

Again right to cell which is clicked on step 3

a result left click (press event) is also fired. But I think shouldn't be

For IconTab:
Click right button to one of the following controls:
IconTabFilter (1st link)
IconTabHeader (2nd link)
I'm using right click and left click with pressed ctrl button (should be the same result, but might be different)
Left Click to empty space
And you will see that time to time events like select or liveChange are triggered by this scenario
Video link:
https://1drv.ms/v/s!AhK9R225yn15a94Enfuo3KDccoI?e=VvVR2Q
What is the expected result?
Just open context menu without triggering extra events
What happens instead?
Context menu is opened but with extra triggering of events
Any other information? (attach screenshot if possible)
I've found that when I implemented custom button this way (just add one more event for handling right click). And I found that right click also triggers simple press event in button. I didn't expect that and tried with default button and there I wasn't be able to reproduce it and found other controls which have similar issue. Seems it's not all controls which have this behaviour but it's what I found quickly
image
Video link: https://1drv.ms/v/s!AhK9R225yn15a94Enfuo3KDccoI?e=VvVR2Q

Hey @harelyshau,
ontouchend had two sections where it could fire a press event, the first check was fixed but the second check would also fire. It should be fixed now with the commit above, and will be available in version 1.131.
Best,

Diana

Thanks all very much. Now it really works well. Great work!


handle controller disconnects and reconnects

if a controller is not connected on page load, we should detect when a controller is reconnected and proceed as normal
(reproduced on Windows MR with Dell Visor)

this works now for me. thanks, @caseyyee!


Ephemeral nodes should not get any stateful services

fixes #2487

eh, there's slight  problem if there's a service which already has instances scheduled for ephemeral nodes:
$ k service deploy redis
 [done] Deploying service redis
⊛ Deployed instance e2e/null/redis-1 to node moby

$ k node label add moby ephemeral=true

$ k service deploy redis
 [fail] Deploying service redis
 [error] 500 : Cannot find applicable node for service instance e2e/null/redis-1: Did not find any non-ephemeral nodes for stateful service:

Hmm right, I was only testing with strategy: daemon and then making sure that new services do not get deployed to ephemeral nodes.
Hmm... odd error though, how many nodes do you have in your grid? If it's just one node, then that error looks sensible? Otherwise for the case of a stateful service instance deployed to a node that gets labled as ephemeral, I would expect it to behave like #2277 for an offline node: Strategy Scheduler::Strategy::HighAvailability did not find any node:
Labeling a node as ephemeral after the fact is a bit of an odd use-case, that label should come from the Docker labels when the agent first connects.

Otherwise for the case of a stateful service instance deployed to a node that gets labled as ephemeral, I would expect it to behave like #2277 for an offline node: Strategy Scheduler::Strategy::HighAvailability did not find any node:

And the workaround should be the same: kontena service rm --instance the affected stateful instance on the ephemeral node.

Hmm... odd error though, how many nodes do you have in your grid? If it's just one node, then that error looks sensible?

Kinda yes, but still some part of my brain would expect that an existing instance could be re-deployed to the same node where the data already is.

Labeling a node as ephemeral after the fact is a bit of an odd use-case, that label should come from the Docker labels when the agent first connects.

I agree that this is bit of odd case, but I think there's a real possibility of this happening since < 1.4 releases have not had any deployment controls over ephemeral nodes. The worst part is that the only workaround involves manual removal of instance(s) which could very well lead to data loss.

Indeed:
kontena service show stateful-1/foo
Stateful service is deployed to core-02:
development/stateful-1/foo:
  created: 2017-07-03T14:09:12.247Z
  updated: 2017-07-03T14:09:12.247Z
  stack: development/stateful-1
  desired_state: running
  image: redis:latest
  revision: 1
  stack_revision: 1
  stateful: yes
  scaling: 1
  strategy: ha
  stop_grace_period: 10s
  deploy_opts:
  dns: foo.stateful-1.development.kontena.local
  instances:
    stateful-1/foo/1:
      scheduled_to: core-02
      deploy_rev: 2017-07-03 14:09:12 UTC
      rev: 2017-07-03 14:09:12 UTC
      state: running
      containers:
        stateful-1.foo-1 (on core-02):
          dns: foo-1.stateful-1.development.kontena.local
          ip: <IP_ADDRESS>
          public ip: <IP_ADDRESS>
          status: running

kontena node label add core-02 ephemeral=true
Label core-02 as ephemeral
kontena stack deploy stateful-1
Scheduling fails per #2277
 [done] Triggering deployment of stack stateful-1
 [fail] Waiting for deployment to start
        Cannot find applicable node for service instance development/stateful-1/foo-1: Strategy Scheduler::Strategy::HighAvailability did not find any node
 [error] RuntimeError : deploy failed
         See /home/kontena/.kontena/kontena.log or run the command again with environment DEBUG=true set to see the full exception

kontena service rm --instance=1 stateful-1/foo
Force stateful service instance to get re-scheduled:
Destructive command. To proceed, type "stateful-1/foo/1" or re-run this command with --force option.
> Enter 'stateful-1/foo/1' to confirm:  stateful-1/foo/1
 [done] Removing service instance stateful-1/foo/1

kontena stack deploy stateful-1
Able to schedule instance to new node:
 [done] Triggering deployment of stack stateful-1
 [done] Waiting for deployment to start
 [done] Deploying service foo

kontena service show stateful-1/foo
development/stateful-1/foo:
  created: 2017-07-03T14:09:12.247Z
  updated: 2017-07-03T14:09:12.247Z
  stack: development/stateful-1
  desired_state: running
  image: redis:latest
  revision: 1
  stack_revision: 1
  stateful: yes
  scaling: 1
  strategy: ha
  stop_grace_period: 10s
  deploy_opts:
  dns: foo.stateful-1.development.kontena.local
  instances:
    stateful-1/foo/1:
      scheduled_to: core-01
      deploy_rev: 2017-07-03 14:09:53 UTC
      rev: 2017-07-03 14:09:53 UTC
      state: running
      containers:
        stateful-1.foo-1 (on core-02):
          dns: foo-1.stateful-1.development.kontena.local
          ip: <IP_ADDRESS>
          public ip: <IP_ADDRESS>
          status: running
        stateful-1.foo-1 (on core-01):
          dns: foo-1.stateful-1.development.kontena.local
          ip: <IP_ADDRESS>
          public ip: <IP_ADDRESS>
          status: running

The dup container disappers once the agent notices that it should be terminated.

I think  the Ephemeral filter should consider an ephemeral node being valid deployment target for stateful service IF there's already existing instance on that node.

I think the Ephemeral filter should consider an ephemeral node being valid deployment target for stateful service IF there's already existing instance on that node.

Then that sounds vaugely like the offline node grace period stickyness, and should be implemented at the strategy level.... although that offline grace period thing is implemented in the GridScheduler and does not apply to the actual deploy, which is the exactly the missing thing that makes the resulting error in #2277 so nasty.

Then that sounds vaugely like the offline node grace period stickyness, and should be implemented at the strategy level....

The problem is that filters are run first and thus ephemeral nodes will not get to strategy level at all for stateless services. I don't see a problem if the filter would return ephemeral node if it already has an stateful instance, the strategy should then pick that up.

With the latest commit that allows ephemeral node for scheduling only if it already has an instance:
k service create --stateful redis redis
 [done] Creating redis service

$ k service deploy redis
 [done] Deploying service redis
⊛ Deployed instance e2e/null/redis-1 to node moby

$ k node label add moby ephemeral=true

$ k service deploy redis
 [done] Deploying service redis
⊛ Deployed instance e2e/null/redis-1 to node moby

$ k service create --stateful another redis
 [done] Creating another service

$ k service deploy another
 [fail] Deploying service another
 [error] 500 : Cannot find applicable node for service instance e2e/null/another-1: Did not find any non-ephemeral nodes for stateful service:

With the latest commit that allows ephemeral node for scheduling only if it already has an instance:

BTW I think offline nodes should also behave similarly re #2277: existing stateful instances should just keep being scheduled to offline nodes, then the deploy will fail on them being offline with an informative error message.


Code updated to work with TensorFlow 2.0+

Hello,
I have updated this library to work with TensorFlow 2.1, there was no major changes needed, just something to match the new API. Since it is advised in Keras documentation to use tf.keras instead of keras for TF 2+, I have refactored the code accordingly. I took the liberty of adding a requirements.txt file to make it easier for the user to install all the needed packages with pip.
I have added a Travis badge in the README file with the build status, but I advise you to change the link since it currently points to my fork of the library.
I hope that this contribution is useful and I really appreciate the work you did with this library.
Have a nice day,
Aurelio Amerio

Thanks a lot for your PR, @aurelio-amerio! Much appreciated!


Storage: bucket.labels surprisingly returns a deepcopy

I expected this to work:
    bucket = storage_client.get_bucket(bucket_name)
    bucket.labels['example'] = 'label'
    bucket.patch()

Turns out bucket.labels returns a deepcopy, so I have to do this instead:
    bucket = storage_client.get_bucket(bucket_name)
    labels = bucket.labels
    labels['example'] = 'label'
    bucket.labels = labels
    bucket.patch()

I'm not sure what the right move is. There are definitely pros and cons here, i.e. I can imagine a user surprised they mutated the Bucket when they didn't intend to.

Yeah I agree. Could we at least document it better? The docstring for labels is actually totally wrong: https://google-cloud-python.readthedocs.io/en/latest/storage/buckets.html#google.cloud.storage.bucket.Bucket.labels

Copy-pasta strikes again!

The other properties which contain non-scalar values (cors, lifecycle_rules) also return copies.  I'm working on a PR which adds the following note (modified to use values appropriate to each one):
        .. note::

           The getter for this property returns a list which contains
           *copies* of the bucket's CORS policy mappings.  Mutating the list
           or one of its dicts has no effect unless you then re-assign the
           dict via the setter.  E.g.:

           >>> cors = bucket.cors
           >>> cors.append({'origin': '/foo', ...})
           >>> del policies[0]
           >>> bucket.cors = cors


optimize parsing the cost argument to softfork

We know it may not exceed u64::MAX, so no need to allocate a BigInt.
I also added a dev-dependency on rstest for parameterizing the test for the new function, uint_atom().

updated with more test cases

Wait, I realize now uint_atom has a size parameter. Maybe you just add u64_atom that calls uint_atom::<8>. But I will approve for now.


onnx model import issue

Hi, I am trying to import a .onnx model exported using YOLOv8. However, I am getting this following error.
OnnxImportException: Unexpected error while parsing layer /model.2/Split_output_0 of type Split.
Unsupported default attribute split for node /model.2/Split_output_0 of type Split. Value is required.
Are you using any specific version of Barracuda?

Hey!
This project uses Barracuda 3.0.0.
You can try this notebook to fix the onnx model.


Add reference to training and partners

Top page needs mention of training, and partners.

added training and pm


Creating a DataTemplate in code

How would I create a DataTemplate in code?
Poking around I see that I'd have to use TemplateContent which isn't exactly code-friendly.

Scratch that.
http://avaloniaui.net/docs/templates/datatemplates-in-code


fix: you are contraction to possesive

Sorry. This is definitely my least proud pull request.

woops. closing in favor of #378


Tellstick Core Not Working - Hassbian

Hassbian Stretch on RPI 3
On release 59.2 tellstick core (for tellstick duo) broke. Reading @pvizeli - #10859 seems related.
Service reports: “error, could not connect to the Telldus Service",.

This is only hass.io relevant while the core service run outside home-assistant container. Don't use this network config.

@pvizeli , thank you. I followed one of the “stretch” installation tutorials and only added tellstick to conf.yaml file. It worked on 59.1. After moving to 59.2 it stopped with the mentioned error.

Still a problem with 0.60.0?

Thank you for reaching out. I’ve abandoned the Tellstick.


Considering Update to Android U?

com.github.tiann:FreeReflection:3.2.0
It is compatible with Android U.
https://github.com/tiann/FreeReflection/pull/57


Add support for Flask-Admin Panel

Goal
Create classes and functions in a dynamic way so that the generated api can create flask admin panels for the connected database.
Description
Flask-Admin lets you build an admin interface on top of your existing data model. It helps in creating an easy way to view, add, edit, and delete data entries in the database and pythonrest would benefit a lot by incorporating an admin panel creation on execution

The commit 03274a0 solved the issue


Accessing some resolve data of a child state in a parent state, when it is resolved?

I have a root state that handles a map for the whole app. A descendant state is linked to a specific url like /user/:userid and the user is a resolve data of this child state. When loading the user, the map must select the corresponding marker for this user and be centered on it.
Of course, I could have a common service that stores a current user (by the substate controller) and the parent controller would watch it. But I'm wondering if there is a ui-router specific solution for that. I tried to register a hook in the parent controller to know when the child state is started and get the resolve, but it seems it is too late and it is never triggered. Another way to do that?
Thanks

There is not any ui router construct to accomplish this.  In ui router, all data flows downwards.  If you need to communicate back up, you can do that (like you currently are)  using a service.  Another option is to expose an API as part of a resolve on the parent state.  The child can inject that resolve an call a method on it which updates the parent data.
A third option, more uirouter centric, would be to define a dynamic parameter on the root state which does not appear in the URL.  After the child state is loaded, it can update that state parameter by calling $state.go.   Because the parameter is marked as dynamic: true, the states do not reload. You would have to respond to the parameter changes in your root states template using something like uiOnParamsChanged

Closing this issue because I believe I've answer the question. If you have follow-ups feel free to respond.

Thank you.
Option 2: could you elaborate a bit more abotu defining an api as a resolve and injecting it?
Option 3: do you mean that the child state would call go with its own state name, but different params?

Option 2:
An api as a resolve.  Basically "a service", but locally scoped (not a global singleton).
function mapApi() {
   var api = {
    coords: { x: 1, y: 2 }, // some default, perhaps
    listeners: [],
    setCoords: function(coords) {
      api.coords = coords;
      listeners.forEach(callback => callback(api.coords));
    },
    onCoordsChanged: function($scope, callback) {
      api.listeners.push(callback);
      const deregister = () => {
        let idx = api.listeners.indexOf(callback);
        if (idx !== -1) api.splice(idx, 1);
      }
      $scope.$on('$destroy', deregister);
    }
  };

  return api;
}

... resolve: {
    mapApi: makeApi
  }

The parent's component injects mapApi and adds a listener which updates the map
mapApi.onCoordsChanged($scope, componentCallbackFunction);

while the child injects the resolve and triggers the setCoords api
resolve: {
  user: ($transition$, userApi, mapApi) =>
    userApi.get($transition$.params.userId).then(user => mapApi.setCoords(user.coords));
}

Option 2:
The parent has a dynamic parameter. The child, when entered, redirects the transition with the proper coords params.
.state('parent', {
  params: {
    coords: { dynamic: true, value: { x: 1, y: 2 } }
  }
})
.state('child', {
  url: '/user/:userId',
  resolve: {
    user: (userApi, $transition$) => userApi.get($transition$.params.userId)
  },
  onEnter: (user, $transition$) {
    if ($transition$.params().coords !== user.coords) {
      // redirect the transition with proper coordinates
      $transition$.router.stateService.target(".", { coords: user.coords });
    }
    // or this could work in a different way by starting a new transition just to update the  coords
    // $transition$.promise.then(() => $state.go(".", { coords: user.coords });
  }
}

This is fantastic Chris. Thank you.
Two short questions though:

What does "." mean in target or go? Does it mean "same state"?
What is the difference between go and target? In the docs I see for target a mere "Factory method for creating a TargetState".

Thanks

@cadilhac

What does "." mean in target or go? Does it mean "same state"?

It means "current state" in the same sense as "." means "current working directory" when working with paths.
(note however, it is relative to options.base.  When using relative paths with ui-sref, it is always relative to the state that the ui-sref was created in. That means ui-sref="." created in home always links back to home, even if the current state is home.foo)

What is the difference between go and target? In the docs I see for target a mere "Factory method for creating a TargetState".

Click TargetState to get a better description: https://ui-router.github.io/docs/latest/classes/state.targetstate.html  . In the public API, a target state is primarily used as a return value from a transition hook
The difference between .go() and .target() is that the former abruptly clobbers the existing transition ("Transition Superseded"), while the latter returns a value which the transition inspects, and then redirects nicely.  $state.go() creates and runs a transition IMMEDIATELY while returning a TargetState allows the old transition to clean itself up and run the new transition.  There are other benefits to redirecting via TargetState, like redirect loop detection and not re-fetching resolves on the second transition that were already fetched on the first one.

Many thanks Chris. This makes a nice thread to learn a lot!

Jsut one thing, I tried to call target() in onEnter() and I get this message:

No reference point given for path '.'

@cadilhac interesting!
Yes, it makes sense to me now.  The "." is actually ambiguous in an onEnter.  Does it mean relative to the current state, to the destination state, or to the state being entered.  I think in this case I would do
var $state = $transition$.router.stateService;
return $state.target($transition$.to(), { coords: user.coords });

Great. Thanks.

@christopherthielen I'm going with the solution 3, I'm using in UI-Router for Angular 2+.
I'm stuck on detecting the parameter change.
The function is fired only when I navigate from another state. It is fired after the .target() but the new parameter value is not set (it's undefined). This is what I have:
parent state:
{
    name: 'root.settings.profile',
    url: "/profile",
    params: {
      operativeHeadquarter$: {
        dynamic: true
      }
    },
    views: {
      '': {
        component: ProfileSettingsComponent
      },
      'extra@root': {
        component: ProfileSettingsPanelsComponent
      },
    }, resolve: [
      {
         ... // omitted for clearness
      }
    ]
}

child state:
 {
    name: 'root.settings.profile.operative-headquarters.edit',
    url: "/{idx:int}",
    resolve: [{
      token: 'operativeHeadquarter$',
      ... // omitted for clearness
    }],
    onEnter: (transition: Transition, state: StateDeclaration) => {
      const operativeHeadquarter$ = transition.injector().get('operativeHeadquarter$');
      if (transition.params().operativeHeadquarter$ !== operativeHeadquarter$) {
        transition.router.stateService.target(transition.to(), { operativeHeadquarter$: operativeHeadquarter$ });
      }
    }
  },

handler in ProfileSettingsPanelsComponent (extra@root view component in parent state)
  uiOnParamsChanged(newParams, trans: Transition) {
    if (trans.to().name === 'root.settings.profile.operative-headquarters.edit') {
      this.operativeHeadquarter$ = trans.params().operativeHeadquarter$;
    }
  }

trans.params().operativeHeadquarter$ is undefined (the default value), newParams has no operativeHeadquarter$ field

Damn... I forgot to return the transition created with target(). I also had to merge the current parameters.
Now if I go land directly to the leaf routing (root.settings.profile.operative-headquarters.edit), the uiOnParamsChanged doesn't trigger (the first time)
    onEnter: (transition: Transition, state: StateDeclaration) => {
      const operativeHeadquarter$ = transition.injector().get('operativeHeadquarter$');
      if (transition.params().operativeHeadquarter$ !== operativeHeadquarter$) {
        const params = {
          ...transition.params(),
          operativeHeadquarter$: operativeHeadquarter$
        };
        return transition.router.stateService.target(transition.to(), params);
      }
    }


Mislabeling as AMPBIAS

Hi,
VarDict is mislabeling a SNV as being AMPBIAS for 2 of my three samples. As you can see in the picture, there are multiple overlapping amplicons that contain the SNV.

Any idea what could be causing this issue?
Thanks,
Tim

Hi Tim,
Sorry about the issue you're seeing. Ampbias is triggered when running VarDict in amplicon-aware mode when, out of multiple overlapping different amplicons, only one supports the variant.
What does your bed file look like in this exact region? How many amplicons are there?

Hi Mika,
There are 5 amplicons overlapping this particular variant, 4 of which pick it up (it is in the middle of the fifth, so not sequenced).

Sorry this dropped off my radar. If I remember correctly there is a rule in VarDict that says all amplicons must support a variant for it to be called. I'd ask @zhongwulai but not sure if he's monitoring this ticket.

Hi Tim!
Sorry for the very late reply!
I want to confirm the last comment from Miika, that flag will not be triggered only if all amplicons support the variant. Because one amplicon doesn't support it, AMPBIAS flag was set in this case.
I will close this issue. Let me know if there are any other questions.


Avoid implicit coercions of dangling hashes to empty nodes

The existing implementation of Tree contains several operations that consider "dangling" hashes (internal tree hashes that are Not_found in the underlying store) to be equivalent to empty nodes. For instance:

Tree.find at a path that contains a dangling hash will return None (and similarly Tree.mem returns false).

Tree.update at a path that contains a dangling hash will observe a false empty node at the end of the path (... with similar results for add / remove etc.)

This behaviour can be triggered by the user using Tree.shallow, but also arises when the underlying store is corrupt (and certain internal objects can't be found). In each case, silently coercing to an empty node is surprising, and so this commit changes these operations to raise a Dangling_hash exception when this happens instead.
This is a fix for https://github.com/mirage/irmin/issues/1475 that opts for not breaking the API over exposing a richer result type in each of the Tree operations where this case can occur. I tried the latter, and it produed a lot of churn in consumer code without adding much value. I think for the vast majority of use-cases it makes sense to interpret dangling hashes as unintentional (user error or store corruption) and raise an exception. I still think any future use of trees as proofs would be better served by a dedicated "blind" internal representation vs. overloading the existing "shallow" concept.

LGTM