Extension issue: remoteHub/pullRequest` is not a valid menu identifier

Issue Type: Bug
Extension Name: vscode-pull-request-github
Extension Version: 0.44.0
OS Version: Windows_NT x64 10.0.19044
VS Code version: 1.68.1

{
	"messages": [
		{
			"type": 1,
			"message": "`remoteHub/pullRequest` is not a valid menu identifier",
			"extensionId": {
				"value": "GitHub.vscode-pull-request-github",
				"_lower": "github.vscode-pull-request-github"
			},
			"extensionPointId": "menus"
		}
	],
	"activationTimes": {
		"codeLoadingTime": 20,
		"activateCallTime": 1,
		"activateResolvedTime": 3115,
		"activationReason": {
			"startup": true,
			"extensionId": {
				"value": "GitHub.vscode-pull-request-github",
				"_lower": "github.vscode-pull-request-github"
			},
			"activationEvent": "*"
		}
	},
	"runtimeErrors": [],
	"runningLocation": {
		"affinity": 0,
		"kind": 1
	}
}

Extension host profile

That log is just an info log, and doesn't affect the workings of the extension. 🤞that this will be removed soon: https://github.com/microsoft/vscode-pull-request-github/issues/3656#issuecomment-1169074404


BUG: Does not correctly parse sampler index

when I enter a sampler in the param, it does not map correctly to sampler index. Always defaults to 1 (1 == Euler)
Looking at code for the parse param there is a elseif check that is incorrect
elif value == 'Sampler':             m_sampler_index = map_sampler_to_idx[value]
You are checking if the value is Sampler, when it should be 'key'
Correction should be:
elif key == 'Sampler':             m_sampler_index = map_sampler_to_idx[value]

Thanks @chrisesler. Fixed.


Fota update for following targets 1. DISCO_L475VG_IOT01A 2. K64F 3. K66F 4. NUCLEO_F411RE 5. NUCLEO_F429ZI

Summary of changes

[] I confirm this contribution is my own and I agree to license it with Apache 2.0.
[] I confirm the moderators may change the PR before merging it in.
For new board enablements only:
[] I confirm the board is Mbed Enabled and passes the Mbed Enabled test set.
[] I confirm the contribution has been tested properly and the tests results for TESTS are attached.
[] I confirm mbed-os.lib and mbed-cloud-client.lib hashes or the content in folders mbed-os and mbed-cloud-client were not modified in order to pass the tests.

Maintainers of this repository update the Mbed OS and Client hashes.
Please report any issues through issues in relevant repositories.

run-ci

Test run: ABORTED
posted-by-tag: https://jenkins-client.isgtesting.com/job/mbed-os-example-pelion/

run-ci

Test run: FAILED

Test summary:
Executed: 24
Failed: 4
Skipped: 0
Errors: 0
Failed test cases:
K64F-GCC_ARM-TCP: K64F-GCC_ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c2c213989000000000001001002e1 - failed_connector_channel_update]
K64F-ARM-TCP: K64F-ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c2c212b28000000000001001002e0 - failed_connector_channel_update]
K66F-GCC_ARM-TCP: K66F-GCC_ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c2c226664000000000001001002e2 - failed_connector_channel_update]
K66F-ARM-TCP: K66F-ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c2c2272b2000000000001001002e3 - failed_connector_channel_update]
Build artifacts
posted-by-tag: https://jenkins-client.isgtesting.com/job/mbed-os-example-pelion/

Test run: ABORTED
posted-by-tag: https://jenkins-client.isgtesting.com/job/mbed-os-example-pelion/

Test run: SUCCESS

Test summary:
Executed: 0
Failed: 0
Skipped: 0
Errors: 0
Build artifacts
posted-by-tag: https://jenkins-client.isgtesting.com/job/mbed-os-example-pelion/

Test run: FAILED

Test summary:
Executed: 24
Failed: 4
Skipped: 0
Errors: 0
Failed test cases:
K64F-GCC_ARM-TCP: K64F-GCC_ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c308b141200000000000100100043 - failed_connector_channel_update]
K64F-ARM-TCP: K64F-ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c308b01cb00000000000100100042 - failed_connector_channel_update]
K66F-GCC_ARM-TCP: K66F-GCC_ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c308c14f700000000000100100045 - failed_connector_channel_update]
K66F-ARM-TCP: K66F-ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c308cbfbc00000000000100100046 - failed_connector_channel_update]
Build artifacts
posted-by-tag: https://jenkins-client.isgtesting.com/job/mbed-os-example-pelion/

run-ci

Test run: FAILED

Test summary:
Executed: 24
Failed: 4
Skipped: 0
Errors: 0
Failed test cases:
K64F-GCC_ARM-TCP: K64F-GCC_ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c358748e2000000000001001001ea - failed_connector_channel_update]
K64F-ARM-TCP: K64F-ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c35874c5f000000000001001001eb - failed_connector_channel_update]
K66F-GCC_ARM-TCP: K66F-GCC_ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c35885db0000000000001001001ec - failed_connector_channel_update]
K66F-ARM-TCP: K66F-ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c3588657a000000000001001001ed - failed_connector_channel_update]
Build artifacts
posted-by-tag: https://jenkins-client.isgtesting.com/job/mbed-os-example-pelion/

Test run: FAILED

Test summary:
Executed: 24
Failed: 4
Skipped: 0
Errors: 0
Failed test cases:
K64F-GCC_ARM-TCP: K64F-GCC_ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c3588c5d3000000000001001001ef - failed_connector_channel_update]
K64F-ARM-TCP: K64F-ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c3588f87f000000000001001001f1 - failed_connector_channel_update]
K66F-GCC_ARM-TCP: K66F-GCC_ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c358a0c75000000000001001001f2 - failed_connector_channel_update]
K66F-ARM-TCP: K66F-ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c358a1a8e000000000001001001f3 - failed_connector_channel_update]
Build artifacts
posted-by-tag: https://jenkins-client.isgtesting.com/job/noida-dm-client-mbed-os-example/

run-ci

Test run: FAILED

Test summary:
Executed: 24
Failed: 4
Skipped: 0
Errors: 0
Failed test cases:
K64F-GCC_ARM-TCP: K64F-GCC_ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c3b573d2e000000000001001003e0 - failed_connector_channel_update]
K64F-ARM-TCP: K64F-ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c3b57215c000000000001001003df - failed_connector_channel_update]
K66F-GCC_ARM-TCP: K66F-GCC_ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c3b57ea83000000000001001003e2 - failed_connector_channel_update]
K66F-ARM-TCP: K66F-ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c3b584e4b000000000001001003e4 - failed_connector_channel_update]
Build artifacts
posted-by-tag: https://jenkins-client.isgtesting.com/job/mbed-os-example-pelion/

Test run: FAILED

Test summary:
Executed: 24
Failed: 4
Skipped: 0
Errors: 0
Failed test cases:
K64F-GCC_ARM-TCP: K64F-GCC_ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c3b61b7f2000000000001001003e9 - failed_connector_channel_update]
K64F-ARM-TCP: K64F-ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c3b61ad13000000000001001003e8 - failed_connector_channel_update]
K66F-GCC_ARM-TCP: K66F-GCC_ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c3b626c7e000000000001001003ea - failed_connector_channel_update]
K66F-ARM-TCP: K66F-ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c3b652e31000000000001001003eb - failed_connector_channel_update]
Build artifacts
posted-by-tag: https://jenkins-client.isgtesting.com/job/noida-dm-client-mbed-os-example/

Test run: FAILED

Test summary:
Executed: 24
Failed: 4
Skipped: 0
Errors: 0
Failed test cases:
K64F-GCC_ARM-TCP: K64F-GCC_ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c4972e8ba000000000001001003d9 - failed_connector_channel_update]
K64F-ARM-TCP: K64F-ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c4972d8bb000000000001001003d8 - failed_connector_channel_update]
K66F-GCC_ARM-TCP: K66F-GCC_ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c4973e19b000000000001001003db - failed_connector_channel_update]
K66F-ARM-TCP: K66F-ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c4973dc54000000000001001003da - failed_connector_channel_update]
Build artifacts
posted-by-tag: https://jenkins-client.isgtesting.com/job/noida-dm-client-mbed-os-example/

Test run: FAILED

Test summary:
Executed: 24
Failed: 4
Skipped: 0
Errors: 0
Failed test cases:
K64F-GCC_ARM-TCP: K64F-GCC_ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c49da89ab000000000001001003f8 - failed_connector_channel_update]
K64F-ARM-TCP: K64F-ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c49da8202000000000001001003f7 - failed_connector_channel_update]
K66F-GCC_ARM-TCP: K66F-GCC_ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c49db9126000000000001001003fa - failed_connector_channel_update]
K66F-ARM-TCP: K66F-ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c49db6bd7000000000001001003f9 - failed_connector_channel_update]
Build artifacts
posted-by-tag: https://jenkins-client.isgtesting.com/job/noida-dm-client-mbed-os-example/

Test run: FAILED

Test summary:
Executed: 24
Failed: 4
Skipped: 0
Errors: 0
Failed test cases:
K64F-GCC_ARM-TCP: K64F-GCC_ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c4a78c3c500000000000100100043 - failed_connector_channel_update]
K64F-ARM-TCP: K64F-ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c4a78b20900000000000100100042 - failed_connector_channel_update]
K66F-GCC_ARM-TCP: K66F-GCC_ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c4a79862100000000000100100046 - failed_connector_channel_update]
K66F-ARM-TCP: K66F-ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c4a797d7800000000000100100045 - failed_connector_channel_update]
Build artifacts
posted-by-tag: https://jenkins-client.isgtesting.com/job/noida-dm-client-mbed-os-example/

Test run: FAILED

Test summary:
Executed: 24
Failed: 4
Skipped: 0
Errors: 0
Failed test cases:
K64F-GCC_ARM-TCP: K64F-GCC_ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c4aa33a5d00000000000100100054 - failed_connector_channel_update]
K64F-ARM-TCP: K64F-ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c4aa3276600000000000100100053 - failed_connector_channel_update]
K66F-GCC_ARM-TCP: K66F-GCC_ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c4aa474bd00000000000100100056 - failed_connector_channel_update]
K66F-ARM-TCP: K66F-ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c4aa46e7800000000000100100055 - failed_connector_channel_update]
Build artifacts
posted-by-tag: https://jenkins-client.isgtesting.com/job/noida-dm-client-mbed-os-example/

Test run: SUCCESS

Test summary:
Executed: 24
Failed: 0
Skipped: 0
Errors: 0
Build artifacts
posted-by-tag: https://jenkins-client.isgtesting.com/job/noida-dm-client-mbed-os-example/

Test run: FAILED

Test summary:
Executed: 24
Failed: 4
Skipped: 0
Errors: 0
Failed test cases:
K64F-GCC_ARM-TCP: K64F-GCC_ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c4ad7f1320000000000010010006c - failed_connector_channel_update]
K64F-ARM-TCP: K64F-ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c4ad7e0850000000000010010006b - failed_connector_channel_update]
K66F-GCC_ARM-TCP: K66F-GCC_ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c4ad8ca8e0000000000010010006d - failed_connector_channel_update]
K66F-ARM-TCP: K66F-ARM-TCP.dev-client-tests - [AssertionError: Timeout while waiting update campaign device state to reach deployed. Campaign: 017c4ad8cd6e0000000000010010006e - failed_connector_channel_update]
Build artifacts
posted-by-tag: https://jenkins-client.isgtesting.com/job/noida-dm-client-mbed-os-example/

Test run: ABORTED
posted-by-tag: https://jenkins-client.isgtesting.com/job/noida-dm-client-mbed-os-example/

Test run: FAILED

Test summary:
Executed: 0
Failed: 0
Skipped: 0
Errors: 0
Build artifacts
posted-by-tag: https://jenkins-client.isgtesting.com/job/noida-dm-client-mbed-os-example/

Test run: SUCCESS

Test summary:
Executed: 24
Failed: 0
Skipped: 0
Errors: 0
Build artifacts
posted-by-tag: https://jenkins-client.isgtesting.com/job/noida-dm-client-mbed-os-example/

Test run: SUCCESS

Test summary:
Executed: 24
Failed: 0
Skipped: 0
Errors: 0
Build artifacts
posted-by-tag: https://jenkins-client.isgtesting.com/job/noida-dm-client-mbed-os-example/

Test run: SUCCESS

Test summary:
Executed: 24
Failed: 0
Skipped: 0
Errors: 0
Build artifacts
posted-by-tag: https://jenkins-client.isgtesting.com/job/noida-dm-client-mbed-os-example/

Test run: SUCCESS

Test summary:
Executed: 24
Failed: 0
Skipped: 0
Errors: 0
Build artifacts
posted-by-tag: https://jenkins-client.isgtesting.com/job/noida-dm-client-mbed-os-example/

Test run: SUCCESS

Test summary:
Executed: 24
Failed: 0
Skipped: 0
Errors: 0
Build artifacts
posted-by-tag: https://jenkins-client.isgtesting.com/job/noida-dm-client-mbed-os-example-legacy/

Test run: FAILED

Test summary:
Executed: 0
Failed: 0
Skipped: 0
Errors: 0
Failed to build following targets:
NUMAKER_PFM_NUC472-ARM-TCP
NUMAKER_PFM_NUC472-GCC_ARM-TCP
NUMAKER_IOT_M263A-ARM-TCP
EP_AGORA-GCC_ARM-TCP
NUCLEO_L4R5ZI-ARM-TCP
NUMAKER_IOT_M487-GCC_ARM-TCP
NUMAKER_IOT_M487-ARM-TCP
NUMAKER_PFM_M487-GCC_ARM-TCP
DISCO_F746NG-GCC_ARM-TCP
NUMAKER_PFM_M487-ARM-TCP
NUMAKER_IOT_M263A-GCC_ARM-TCP
DISCO_F746NG-ARM-TCP
DISCO_L496AG-GCC_ARM-TCP
EP_AGORA-ARM-TCP
NUCLEO_H743ZI2-GCC_ARM-TCP
DISCO_L496AG-ARM-TCP
NUCLEO_L4R5ZI-GCC_ARM-TCP
NUCLEO_H743ZI2-ARM-TCP
GR_LYCHEE-ARM-TCP
ARCH_MAX-ARM-TCP
GR_LYCHEE-GCC_ARM-TCP
ARCH_MAX-GCC_ARM-TCP
WIO_3G-GCC_ARM-TCP
RZ_A1H-GCC_ARM-TCP
RZ_A1H-ARM-TCP
WIO_BG96-ARM-TCP
WIO_3G-ARM-TCP
NUCLEO_F767ZI-ARM-TCP
CY8CPROTO_062_4343W-GCC_ARM-TCP
CY8CPROTO_062_4343W-ARM-TCP
WIO_BG96-GCC_ARM-TCP
UHURU_RAVEN-GCC_ARM-TCP
NUCLEO_F767ZI-GCC_ARM-TCP
UHURU_RAVEN-ARM-TCP
Build artifacts
posted-by-tag: https://jenkins-client.isgtesting.com/job/noida-dm-client-mbed-os-example-legacy/

run-ci

Test run: FAILED

Test summary:
Executed: 0
Failed: 0
Skipped: 0
Errors: 0
Failed to build following targets:
WIO_3G-ARM-TCP
NUMAKER_IOT_M487-ARM-TCP
NUMAKER_IOT_M263A-GCC_ARM-TCP
NUMAKER_PFM_NUC472-GCC_ARM-TCP
NUMAKER_PFM_NUC472-ARM-TCP
NUMAKER_PFM_M487-GCC_ARM-TCP
NUMAKER_PFM_M487-ARM-TCP
NUMAKER_IOT_M487-GCC_ARM-TCP
NUMAKER_IOT_M263A-ARM-TCP
DISCO_F746NG-ARM-TCP
DISCO_F746NG-GCC_ARM-TCP
DISCO_L496AG-GCC_ARM-TCP
DISCO_L496AG-ARM-TCP
EP_AGORA-ARM-TCP
EP_AGORA-GCC_ARM-TCP
NUCLEO_H743ZI2-GCC_ARM-TCP
NUCLEO_L4R5ZI-ARM-TCP
NUCLEO_L4R5ZI-GCC_ARM-TCP
NUCLEO_H743ZI2-ARM-TCP
ARCH_MAX-GCC_ARM-TCP
ARCH_MAX-ARM-TCP
RZ_A1H-GCC_ARM-TCP
RZ_A1H-ARM-TCP
GR_LYCHEE-GCC_ARM-TCP
WIO_BG96-GCC_ARM-TCP
GR_LYCHEE-ARM-TCP
WIO_3G-GCC_ARM-TCP
WIO_BG96-ARM-TCP
NUCLEO_F767ZI-GCC_ARM-TCP
NUCLEO_F767ZI-ARM-TCP
CY8CPROTO_062_4343W-ARM-TCP
UHURU_RAVEN-GCC_ARM-TCP
UHURU_RAVEN-ARM-TCP
CY8CPROTO_062_4343W-GCC_ARM-TCP
Build artifacts
posted-by-tag: https://jenkins-client.isgtesting.com/job/noida-dm-client-mbed-os-example-legacy/

Test run: FAILED

Test summary:
Executed: 0
Failed: 0
Skipped: 0
Errors: 0
Failed to build following targets:
NUMAKER_PFM_NUC472-GCC_ARM-TCP
NUMAKER_PFM_NUC472-ARM-TCP
NUMAKER_PFM_M487-ARM-TCP
NUMAKER_PFM_M487-GCC_ARM-TCP
NUMAKER_IOT_M487-GCC_ARM-TCP
NUMAKER_IOT_M487-ARM-TCP
DISCO_F746NG-GCC_ARM-TCP
NUMAKER_IOT_M263A-GCC_ARM-TCP
NUMAKER_IOT_M263A-ARM-TCP
DISCO_L496AG-GCC_ARM-TCP
DISCO_F746NG-ARM-TCP
DISCO_L496AG-ARM-TCP
EP_AGORA-ARM-TCP
EP_AGORA-GCC_ARM-TCP
NUCLEO_L4R5ZI-GCC_ARM-TCP
NUCLEO_H743ZI2-GCC_ARM-TCP
NUCLEO_H743ZI2-ARM-TCP
ARCH_MAX-GCC_ARM-TCP
NUCLEO_L4R5ZI-ARM-TCP
ARCH_MAX-ARM-TCP
RZ_A1H-ARM-TCP
RZ_A1H-GCC_ARM-TCP
GR_LYCHEE-ARM-TCP
GR_LYCHEE-GCC_ARM-TCP
WIO_3G-ARM-TCP
WIO_3G-GCC_ARM-TCP
WIO_BG96-GCC_ARM-TCP
UHURU_RAVEN-GCC_ARM-TCP
WIO_BG96-ARM-TCP
UHURU_RAVEN-ARM-TCP
NUCLEO_F767ZI-GCC_ARM-TCP
NUCLEO_F767ZI-ARM-TCP
CY8CPROTO_062_4343W-ARM-TCP
CY8CPROTO_062_4343W-GCC_ARM-TCP
Build artifacts
posted-by-tag: https://jenkins-client.isgtesting.com/job/noida-dm-client-mbed-os-example-legacy/

Test run: SUCCESS

Test summary:
Executed: 24
Failed: 0
Skipped: 0
Errors: 0
Build artifacts
posted-by-tag: https://jenkins-client.isgtesting.com/job/mbed-os-example-pelion/

Test run: FAILED

Test summary:
Executed: 0
Failed: 0
Skipped: 0
Errors: 0
Failed to build following targets:
NUMAKER_PFM_NUC472-GCC_ARM-TCP
NUMAKER_PFM_NUC472-ARM-TCP
NUMAKER_PFM_M487-GCC_ARM-TCP
NUMAKER_IOT_M487-GCC_ARM-TCP
NUMAKER_PFM_M487-ARM-TCP
NUMAKER_IOT_M263A-GCC_ARM-TCP
NUMAKER_IOT_M487-ARM-TCP
NUMAKER_IOT_M263A-ARM-TCP
DISCO_F746NG-GCC_ARM-TCP
DISCO_L496AG-GCC_ARM-TCP
DISCO_F746NG-ARM-TCP
WIO_3G-ARM-TCP
UHURU_RAVEN-ARM-TCP
EP_AGORA-GCC_ARM-TCP
DISCO_L496AG-ARM-TCP
ARCH_MAX-GCC_ARM-TCP
GR_LYCHEE-GCC_ARM-TCP
NUCLEO_L4R5ZI-GCC_ARM-TCP
RZ_A1H-GCC_ARM-TCP
GR_LYCHEE-ARM-TCP
NUCLEO_L4R5ZI-ARM-TCP
EP_AGORA-ARM-TCP
CY8CPROTO_062_4343W-GCC_ARM-TCP
NUCLEO_H743ZI2-GCC_ARM-TCP
NUCLEO_H743ZI2-ARM-TCP
RZ_A1H-ARM-TCP
ARCH_MAX-ARM-TCP
WIO_3G-GCC_ARM-TCP
WIO_BG96-ARM-TCP
WIO_BG96-GCC_ARM-TCP
UHURU_RAVEN-GCC_ARM-TCP
CY8CPROTO_062_4343W-ARM-TCP
NUCLEO_F767ZI-ARM-TCP
NUCLEO_F767ZI-GCC_ARM-TCP
Build artifacts
posted-by-tag: https://jenkins-client.isgtesting.com/job/noida-dm-client-mbed-os-example-legacy/

Test run: FAILED

Test summary:
Executed: 0
Failed: 0
Skipped: 0
Errors: 0
Failed to build following targets:
K66F-ARM-TCP
K64F-ARM-TCP
NUCLEO_F429ZI-ARM-TCP
NUCLEO_F429ZI-GCC_ARM-TCP
K66F-GCC_ARM-TCP
K64F-GCC_ARM-TCP
NUCLEO_F411RE-GCC_ARM-TCP
NUCLEO_F411RE-ARM-TCP
DISCO_L475VG_IOT01A-ARM-TCP
DISCO_L475VG_IOT01A-GCC_ARM-TCP
Build artifacts
posted-by-tag: https://jenkins-client.isgtesting.com/job/noida-dm-client-mbed-os-example/

run-ci

Test run: SUCCESS

Test summary:
Executed: 24
Failed: 0
Skipped: 0
Errors: 0
Build artifacts
posted-by-tag: https://jenkins-client.isgtesting.com/job/mbed-os-example-pelion/

run-ci

Test run: FAILED

Test summary:
Executed: 0
Failed: 0
Skipped: 0
Errors: 0
Failed to build following targets:
NUCLEO_F411RE-ARM-TCP
K64F-GCC_ARM-TCP
K64F-ARM-TCP
K66F-GCC_ARM-TCP
K66F-ARM-TCP
NUCLEO_F429ZI-GCC_ARM-TCP
NUCLEO_F429ZI-ARM-TCP
DISCO_L475VG_IOT01A-GCC_ARM-TCP
DISCO_L475VG_IOT01A-ARM-TCP
NUCLEO_F411RE-GCC_ARM-TCP
Build artifacts
posted-by-tag: https://jenkins-client.isgtesting.com/job/noida-dm-client-mbed-os-example/

Test run: SUCCESS

Test summary:
Executed: 24
Failed: 0
Skipped: 0
Errors: 0
Build artifacts
posted-by-tag: https://jenkins-client.isgtesting.com/job/mbed-os-example-pelion/

Test run: FAILED

Test summary:
Executed: 0
Failed: 0
Skipped: 0
Errors: 0
Build artifacts
posted-by-tag: https://jenkins-client.isgtesting.com/job/noida-dm-client-mbed-os-example-legacy/

Test run: ABORTED
posted-by-tag: https://jenkins-client.isgtesting.com/job/noida-dm-client-mbed-os-example-legacy/

run-ci

run-ci

Test run: FAILED

Test summary:
Executed: 0
Failed: 0
Skipped: 0
Errors: 0
Build artifacts
posted-by-tag: https://jenkins-client.isgtesting.com/job/noida-dm-client-mbed-os-example/

Test run: FAILED

Test summary:
Executed: 0
Failed: 0
Skipped: 0
Errors: 0
Build artifacts
posted-by-tag: https://jenkins-client.isgtesting.com/job/noida-dm-client-mbed-os-example-legacy/

Test run: SUCCESS

Test summary:
Executed: 24
Failed: 0
Skipped: 0
Errors: 0
Build artifacts
posted-by-tag: https://jenkins-client.isgtesting.com/job/mbed-os-example-pelion/

run-ci

run-ci

run-ci

Test run: ABORTED
posted-by-tag: https://jenkins-client.isgtesting.com/job/mbed-os-example-pelion/

Test run: SUCCESS

Test summary:
Executed: 24
Failed: 0
Skipped: 0
Errors: 0
Build artifacts
posted-by-tag: https://jenkins-client.isgtesting.com/job/noida-dm-client-mbed-os-example-legacy/

Test run: FAILED

Test summary:
Executed: 0
Failed: 0
Skipped: 0
Errors: 0
Build artifacts
posted-by-tag: https://jenkins-client.isgtesting.com/job/noida-dm-client-mbed-os-example/

Test run: SUCCESS

Test summary:
Executed: 24
Failed: 0
Skipped: 0
Errors: 0
Build artifacts
posted-by-tag: https://jenkins-client.isgtesting.com/job/mbed-os-example-pelion/

Test run: SUCCESS

Test summary:
Executed: 24
Failed: 0
Skipped: 0
Errors: 0
Build artifacts
posted-by-tag: https://jenkins-client.isgtesting.com/job/mbed-os-example-pelion/

Test run: SUCCESS

Test summary:
Executed: 24
Failed: 0
Skipped: 0
Errors: 0
Build artifacts
posted-by-tag: https://jenkins-client.isgtesting.com/job/mbed-os-example-pelion/

Test run: ABORTED
posted-by-tag: https://jenkins-client.isgtesting.com/job/mbed-os-example-pelion/

Test run: SUCCESS

Build artifacts
posted-by-tag: https://jenkins-client.isgtesting.com/job/mbed-os-example-pelion-valgrind/


Try to fix CI nbd issues

Run the set timeout in another thread while we poll as it seems that
when the nbd device is open it triggers a partition scan.
Set the NBD size to 0 before disconnecting as it was observed that when
we disconnect sometimes the device gets rescanned and the kernel thinks
it should partition scan again... setting the size to 0 before the
disconnect seems to alleviate this.

bors try

bors retry

bors try

bors try

bors try

bors try

bors try

bors try

bors merge

bors merge


Add Microsoft ToDo support into PowerToys Run

Description of the new feature / enhancement
I would like PowerToys Run be able for creating a new task on ToDo app just by  typing "todo: Description of the task" or similar.

Scenario when this would be used?
While you are doing something and remember to a pending task and want to write it down fast and don't distract.
Supporting information
No response

actually may be able to do via #4233


convoy-gluster fs catalog not working

Version - master 3/15
Steps to Reproduce:

Create and wait for Glusterfs catalog to fully setup
Create Convoy-glusterfs catalog

Results: The convoy-gluster service never activates.  I get an error in logs:
"Error": "Failed to execute: mount [-t glusterfs glusterfs:/my_vol /var/lib/rancher/convoy/convoy-gluster-42b0ba81-3870-4f08-837a-e966d54bebab/glusterfs/mounts/my_vol], output Mount failed. Please check the log file for more details.\n, error exit status 1"
3/15/2016 10:47:15 PM}
Expected: Should setup properly

convoy-gluster is not in GA right @will-chan

I was wrong. This needs fixed for GA.

we just need to be able to deploy it and access/use it.  We don't need to deal with corner case scenarios or HA for now until post GA.

Tested with latest build from master - mar 20:
convoy-gluster instances keeps restarting with the following errors seen in the container:
: dial unix /host/var/run/convoy-convoy-gluster.sock: no such file or directory"
3/20/2016 10:20:27 AMtime="2016-03-20T17:20:27Z" level=error msg="Get http:///host/var/run/convoy-convoy-gluster.sock/v1/volumes/list: dial unix /host/var/run/convoy-convoy-gluster.sock: no such file or directory"
3/20/2016 10:20:28 AMtime="2016-03-20T17:20:28Z" level=error msg="Get http:///host/var/run/convoy-convoy-gluster.sock/v1/volumes/list: dial unix /host/var/run/convoy-convoy-gluster.sock: no such file or directory"
3/20/2016 10:20:29 AMtime="2016-03-20T17:20:29Z" level=error msg="Get http:///host/var/run/convoy-convoy-gluster.sock/v1/volumes/list: dial unix /host/var/run/convoy-convoy-gluster.sock: no such file or directory"
3/20/2016 10:20:30 AMtime="2016-03-20T17:20:30Z" level=error msg="Get http:///host/var/run/convoy-convoy-gluster.sock/v1/volumes/list: dial unix /host/var/run/convoy-convoy-gluster.sock: no such file or directory"
3/20/2016 10:20:31 AMtime="2016-03-20T17:20:31Z" level=debug msg="Cleaning up environment..." pkg=daemon
3/20/2016 10:20:31 AMtime="2016-03-20T17:20:31Z" level=error msg="Timeout executing: mount [-t glusterfs glusterfs:/my_vol /var/lib/rancher/convoy/convoy-gluster-6a5f2c9d-b78d-42d9-899a-3bfc2a65ecda/glusterfs/mounts/my_vol], output , error <nil>"
3/20/2016 10:20:31 AM{
3/20/2016 10:20:31 AM	"Error": "Timeout executing: mount [-t glusterfs glusterfs:/my_vol /var/lib/rancher/convoy/convoy-gluster-6a5f2c9d-b78d-42d9-899a-3bfc2a65ecda/glusterfs/mounts/my_vol], output , error \u003cnil\u003e"
3/20/2016 10:20:31 AM}
3/20/2016 10:20:31 AMtime="2016-03-20T17:20:31Z" level=info msg="convoy exited with error: exit status 1"
3/20/2016 10:20:31 AMtime="2016-03-20T17:20:31Z" level=info msg=Exiting.

mysql> select id,name,state,health_state,created,removed,start_count from instance where name like "%convoy-gluster%";
+------+---------------------------------------------+----------+-------------------------+---------------------+---------+-------------+
| id   | name                                        | state    | health_state            | created             | removed | start_count |
+------+---------------------------------------------+----------+-------------------------+---------------------+---------+-------------+
| 3145 | convoy-gluster_convoy-gluster-storagepool_1 | running  | healthy                 | 2016-03-20 17:11:10 | NULL    |           1 |
| 3146 | convoy-gluster_convoy-gluster_1             | running  | healthy                 | 2016-03-20 17:11:10 | NULL    |          18 |
| 3147 | convoy-gluster_convoy-gluster_2             | starting | updating-reinitializing | 2016-03-20 17:11:10 | NULL    |          18 |
| 3148 | convoy-gluster_convoy-gluster_3             | running  | healthy                 | 2016-03-20 17:11:11 | NULL    |          17 |
+------+---------------------------------------------+----------+-------------------------+---------------------+---------+-------------+
4 rows in set (0.03 sec)

Tested against the new GlusterFS template v3.7.9-rancher1 and existing Convoy GlusterFS template v0.2
The stacks launch, health checks all return ok and convoy-cluster appears as Active on the Storage Pools UI tab.

Tested specifying a port integer tcpsocket probe for mysqld, stack deploys successfully. Specified an invalid port integer probe and observed expected container termination/restart.
https://github.com/LLParse/community-catalog/blob/issue-3981-test/kubernetes-templates/wordpress/0/mysql.yaml#L38

Version - master 3/24
Verified fixed


Doesn't run on centos

Hey mate,
Thanks for this - works a treat when i run on my macbook however when trying to run it as part of an automated script on a centos machine; it doesn't:
wget: unrecognized option '--show-progress'
Usage: wget [OPTION]... [URL]...

Try `wget --help' for more options.

--show-progress feels like vanity anyway, so maybe it can just be removed?

Hey @Stono
I'm glad you like it. I've added a new flag --slient it's available in v0.0.10.
Can you try that and see if it fixes your issue?

I've now added detection of if the command exists so with v0.0.11 you won't need to provide the --silent flag. It will automatically be silent if wget does not have a --show-progress command

Cool, just on a train but will give it a go later
On Wed, 2 Jan 2019, 4:36 pm Simon Mo<EMAIL_ADDRESS>wrote:

I've now added detection of if the command exists so with v0.0.11 you
won't need to provide the --silent flag. It will automatically be silent if
wget does not have a --show-progress command
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Fried-Chicken/ghost-static-site-generator/issues/2#issuecomment-450913131,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABaviS_cnvEtTwbRfylQdZRc6_7KQcMmks5u_OAEgaJpZM4Zm1uj
.

OK it runs now but seems extremely slow and I'm unsure why because I'm not getting much output.
You can see it plows through a bunch of them quite quick:
app_1  | INFO [2019-01-02 18:40:26] "GET /" 200 615ms
app_1  | INFO [2019-01-02 18:40:26] "GET /assets/built/infinitescroll.js?v=d321caa573" 200 9ms
app_1  | INFO [2019-01-02 18:40:26] "GET /assets/built/screen.css?v=d321caa573" 200 24ms
app_1  | INFO [2019-01-02 18:40:26] "GET /assets/built/jquery.fitvids.js?v=d321caa573" 200 19ms
app_1  | INFO [2019-01-02 18:40:26] "GET /public/ghost-sdk.js?v=d321caa573" 200 28ms
app_1  | INFO [2019-01-02 18:40:28] "GET /" 304 155ms
app_1  | INFO [2019-01-02 18:40:28] "GET /assets/built/jquery.fitvids.js?v=d321caa573" 304 6ms
app_1  | INFO [2019-01-02 18:40:28] "GET /assets/built/infinitescroll.js?v=d321caa573" 304 8ms
app_1  | INFO [2019-01-02 18:40:28] "GET /assets/built/screen.css?v=d321caa573" 304 10ms
app_1  | INFO [2019-01-02 18:40:28] "GET /favicon.ico" 200 8ms
app_1  | INFO [2019-01-02 18:40:29] "GET /managing-your-costs-on-kubernetes/" 200 127ms
app_1  | INFO [2019-01-02 18:40:29] "GET /assets/built/screen.css?v=d321caa573" 304 2ms
app_1  | INFO [2019-01-02 18:40:29] "GET /assets/built/jquery.fitvids.js?v=d321caa573" 304 3ms
app_1  | INFO [2019-01-02 18:40:54] "GET /" 200 200ms
app_1  | INFO [2019-01-02 18:40:54] "GET /robots.txt" 200 3ms
app_1  | INFO [2019-01-02 18:40:54] "GET /assets/built/screen.css?v=d321caa573" 200 3ms
app_1  | INFO [2019-01-02 18:40:54] "GET /favicon.ico" 200 3ms
app_1  | INFO [2019-01-02 18:40:54] "GET /public/ghost-sdk.js?v=d321caa573" 200 1ms
app_1  | INFO [2019-01-02 18:40:54] "GET /managing-your-costs-on-kubernetes/" 200 63ms
app_1  | INFO [2019-01-02 18:40:54] "GET /content/images/size/w600/2018/07/cost_cluster-min.png" 200 9ms
app_1  | INFO [2019-01-02 18:40:55] "GET /author/karl/" 200 175ms
app_1  | INFO [2019-01-02 18:40:55] "GET /nginx-ingress-modsecurity-and-secchatops/" 200 67ms
app_1  | INFO [2019-01-02 18:40:55] "GET /securing-microservices-in-the-enterprise/" 200 134ms
app_1  | INFO [2019-01-02 18:40:55] "GET /serverless-vs-kubernetes/" 200 68ms
app_1  | INFO [2019-01-02 18:40:55] "GET /secure-your-site-with-nginx/" 200 64ms
app_1  | INFO [2019-01-02 18:40:55] "GET /nginx-lua-scripting-to-reload-config/" 200 72ms
app_1  | INFO [2019-01-02 18:40:55] "GET /docker-containers-as-systemd-services/" 200 66ms
app_1  | INFO [2019-01-02 18:40:55] "GET /fuse-mount-in-kubernetes/" 200 76ms
app_1  | INFO [2019-01-02 18:40:55] "GET /facetimehd-camera-on-linux/" 200 77ms
app_1  | INFO [2019-01-02 18:40:55] "GET /really-bigdata-really-small-cloud/" 200 58ms
app_1  | INFO [2019-01-02 18:40:55] "GET /are-the-googles-watching/" 200 59ms
app_1  | INFO [2019-01-02 18:40:55] "GET /free-ssl-certificates-with-letsencrypt-and-docker/" 200 58ms
app_1  | INFO [2019-01-02 18:40:55] "GET /ghost-contact-form/" 200 57ms
app_1  | INFO [2019-01-02 18:40:55] "GET /aws-lambda-logs-into-sumologic/" 200 60ms
app_1  | INFO [2019-01-02 18:40:56] "GET /broken-grub/" 200 68ms
app_1  | INFO [2019-01-02 18:40:56] "GET /ikedc-vpn-in-a-container/" 200 68ms
app_1  | INFO [2019-01-02 18:40:56] "GET /using-json-in-chef-cookbook-attributes/" 200 66ms
app_1  | INFO [2019-01-02 18:40:56] "GET /jenkins-pipeline-step-outdated-npm-modules/" 200 64ms
app_1  | INFO [2019-01-02 18:40:56] "GET /redis-sentinel-behind-haproxy/" 200 57ms
app_1  | INFO [2019-01-02 18:40:56] "GET /jenkins-pipeline-node-security-project/" 200 65ms
app_1  | INFO [2019-01-02 18:40:56] "GET /immutable-objects-and-bluebird/" 200 57ms
app_1  | INFO [2019-01-02 18:40:56] "GET /migsql-sql-migration/" 200 58ms
app_1  | INFO [2019-01-02 18:40:56] "GET /internal-npm-registry/" 200 89ms
app_1  | INFO [2019-01-02 18:40:56] "GET /mongodb-elasticsearch-setup/" 200 62ms

<freezes here for a good 5 minutes before carrying on>

The slowdown was caused by some ipv6 issues in my container which i've now resolved!

Closing issue as it was related to and issue with ipv6


User installer fails with AppLocker publisher rules

VSCode Version: VSCodeUserSetup-x64-1.27.1.exe
OS Version: Windows 10 1803

Steps to Reproduce:

Create an AppLocker executable publisher rule in enforcement mode with the following allow permissions.
Publisher: O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US
Product name: VISUAL STUDIO CODE
File name: *
File version: *

Launch VSCodeUserSetup-x64-1.27.1.exe

Does this issue occur when all extensions are disabled?: N/A
The following error message is produced by the installer when run:

Unable to execute file in the temporary directory. Setup aborted.
Error 1260: This program is blocked by group policy.

The issue is due to the installer extracting an executable into a temp directory which isn't signed with the product name.  The fqbn for the two files are:
VSCODEUSERSETUP-X64-1.27.1.EXE:
O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US\VISUAL STUDIO  CODE\<IP_ADDRESS>
VSCODEUSERSETUP-X64-1.27.1.TMP
O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US\\51.1052.0.00
The insiders build has the same issue with the product name missing from the signed image extracted into the temp folder.

Please use the ZIP archive in situations like this.


[8.x] Add explain() to Query\Builder and Eloquent\Builder

explain() method allows you to receive the explanation from the builder (both Query and Eloquent).
Before you would typically call toSql(), copy the result, open TablePlus, prepend the query with EXPLAIN , replace all ?, and check the result.
Now you can just call explain() to return the explanation or explain()->dd() to die & dump the explanation.
>>> Webhook::where('event', 'users.registered')->explain()
=> Illuminate\Support\Collection {#15414
     all: [
       {#15407
         +"id": 1,
         +"select_type": "SIMPLE",
         +"table": "webhooks",
         +"partitions": null,
         +"type": "ref",
         +"possible_keys": "webhooks_event_index",
         +"key": "webhooks_event_index",
         +"key_len": "1022",
         +"ref": "const",
         +"rows": 1,
         +"filtered": 10.0,
         +"Extra": "Using where",
       },
     ],
   }
>>> DB::table('webhooks')->where('event', 'users.registered')->explain()
=> Illuminate\Support\Collection {#5350
     all: [
       {#5448
         +"id": 1,
         +"select_type": "SIMPLE",
         +"table": "webhooks",
         +"partitions": null,
         +"type": "ref",
         +"possible_keys": "webhooks_event_index",
         +"key": "webhooks_event_index",
         +"key_len": "1022",
         +"ref": "const",
         +"rows": 1,
         +"filtered": 100.0,
         +"Extra": null,
       },
     ],
   }
>>> User::where('name', 'Illia Sakovich')->explain()
=> Illuminate\Support\Collection {#5344
     all: [
       {#15407
         +"id": 1,
         +"select_type": "SIMPLE",
         +"table": "users",
         +"partitions": null,
         +"type": "ALL",
         +"possible_keys": null,
         +"key": null,
         +"key_len": null,
         +"ref": null,
         +"rows": 9,
         +"filtered": 11.11111164093,
         +"Extra": "Using where",
       },
     ],
   }
>>> DB::table('users')->where('name', 'Illia Sakovich')->explain()
=> Illuminate\Support\Collection {#5348
     all: [
       {#5342
         +"id": 1,
         +"select_type": "SIMPLE",
         +"table": "users",
         +"partitions": null,
         +"type": "ALL",
         +"possible_keys": null,
         +"key": null,
         +"key_len": null,
         +"ref": null,
         +"rows": 9,
         +"filtered": 11.11111164093,
         +"Extra": "Using where",
       },
     ],
   }

Woah, this is another level awesomeness. I hated replacing all those ? for large queries


Seed-genes configuration file

Can we enhance the seed-genes config file to support case insensitive gene ids?
It would have been helpful to have a comment in the example file or some clear blocking error message warning, or, upper case command in the code... It is not natural that ID copy pasted direct from EMBL do not work.

@KeywanHP we could, but that doesn't make much sense: accessions are almost always case sensitive and making them ambiguous just to avoid a Unix one-liner is error-prone and not very worthwhile in my opinion.

Well the original gene accessions used in the input data (gff3, fasta etc) are often lower case but they are made upper case by ondex / tabular parser without telling the user/developer. So they will most likely use the source id to configure the seed-genes which won't work in that case. We have added a comment to our seed-genes.tsv configs as a reminder for now:
No lower case letters allowed in seed genes tsv

I've just realised old code in the old version of the tab parser (which I had to reuse) indeed converts accessions to upper case :disappointed:
In my opinion that's grossly wrong, as a minimum, it should be an optional conversion. Because this issue is popping up over and over again, let's file a ticket to fix it (if we want to remove the upper case conversion, it's trivial to do, if we want it optional, it's some more code to write).
Regarding the specific problem, changing the case-sensivity isn't so simple, since the accessions in the file are used to search Gene concepts in the graph based on Set.contains() (here), and that's obviously case-sensitive, practically impossible to be changed in an efficient way (eg, would need a loop-based, O(n^2) search over all the concepts). The only efficient solution would be searching via Lucene, which would require passing the Lucene manager class to the traverse class and changing the code to use it.
All of this to fix what I think are errors with the data (accessions are case-sensitive and turning them to upper/lower case can cause ambiguities), caused, among other things, by errors in the parsers. We should fix the latter instead of introducing even more errors.
Incidentally, something similar happens where you wouldn't expect it even less.

OK. I will close this ticket and create another one in due course to review all parsers used in our KG build workflows and ensure they don't change concept accession strings to upper case.


Fix function send problem and add group chat option

I have used code from pull request #32 to fix the JSON bug on client.getUsers("friend's name")

@Charliiee Would you please solve the conflict for this PR? I merged the previous pull request which contains the same fix in your PR so I can't merge this.

Problems solved by pr #42.
Closing pull request.


NotADirectoryError when importing exoplanet

I ran the tutorial as written here:
http://exoplanet.dfm.io/en/latest/tutorials/stellar-variability/
and get the following error. I'm using a git clone of the master branch
NotADirectoryError                        Traceback (most recent call last)
<ipython-input-2-19985ffa6e50> in <module>()
----> 1 import exoplanet as xo
      2
      3 results = xo.estimators.lomb_scargle_estimator(
      4     x, y, max_peaks=1, min_period=5.0, max_period=100.0,
      5     samples_per_peak=50)

~/anaconda3/lib/python3.6/importlib/_bootstrap.py in _find_and_load(name, import_)

~/anaconda3/lib/python3.6/importlib/_bootstrap.py in _find_and_load_unlocked(name, import_)

~/anaconda3/lib/python3.6/importlib/_bootstrap.py in _load_unlocked(spec)

~/anaconda3/lib/python3.6/importlib/_bootstrap.py in _load_backward_compatible(spec)

~/anaconda3/lib/python3.6/site-packages/exoplanet-0.1.2.dev0-py3.6.egg/exoplanet/__init__.py in <module>()
     14     from .sampling import *  # NOQA
     15     from .estimators import *  # NOQA
---> 16     from .light_curves import *  # NOQA
     17
     18     from . import distributions, gp, orbits

~/anaconda3/lib/python3.6/importlib/_bootstrap.py in _find_and_load(name, import_)

~/anaconda3/lib/python3.6/importlib/_bootstrap.py in _find_and_load_unlocked(name, import_)

~/anaconda3/lib/python3.6/importlib/_bootstrap.py in _load_unlocked(spec)

~/anaconda3/lib/python3.6/importlib/_bootstrap.py in _load_backward_compatible(spec)

~/anaconda3/lib/python3.6/site-packages/exoplanet-0.1.2.dev0-py3.6.egg/exoplanet/light_curves.py in <module>()
     13 from .theano_ops.starry.limbdark import LimbDarkOp
     14
---> 15 get_cl = GetClOp()
     16 limbdark = LimbDarkOp()
     17

~/anaconda3/lib/python3.6/site-packages/exoplanet-0.1.2.dev0-py3.6.egg/exoplanet/theano_ops/starry/get_cl.py in __init__(self)
     20
     21     def __init__(self):
---> 22         self.grad_op = GetClRevOp()
     23         super(GetClOp, self).__init__()
     24

~/anaconda3/lib/python3.6/site-packages/exoplanet-0.1.2.dev0-py3.6.egg/exoplanet/theano_ops/starry/base_op.py in __init__(self)
     19
     20     def __init__(self):
---> 21         super(StarryBaseOp, self).__init__(self.func_file, self.func_name)
     22
     23     # def c_code_cache_version(self):

~/anaconda3/lib/python3.6/site-packages/theano/gof/op.py in __init__(self, func_files, func_name)
   1306         # find the new path and new version of the file in Theano.
   1307         self.func_files = func_files
-> 1308         self.load_c_code(func_files)
   1309
   1310         if len(self.code_sections) == 0:

~/anaconda3/lib/python3.6/site-packages/theano/gof/op.py in load_c_code(self, func_files)
   1329         for func_file in func_files:
   1330             # U (universal) will convert all new lines format to \n.
-> 1331             with _open_u(func_file) as f:
   1332                 self.func_codes.append(f.read())
   1333

NotADirectoryError: [Errno 20] Not a directory: '/Users/tom/anaconda3/lib/python3.6/site-packages/exoplanet-0.1.2.dev0-py3.6.egg/exoplanet/theano_ops/starry/get_cl_rev.cc'

I can install fine from pip install exoplanet

How did you install from the github clone?

good question. I'm not sure. If I was following your instructions then python setup.py install. But I may have done pip install -e .

OK. Well if you do:
git clone --recursive https://github.com/dfm/exoplanet.git
cd exoplanet
python setup.py install

Everything should work.

Ok, I did a fresh install and i got the same error.

NotADirectoryError: [Errno 20] Not a directory: '/Users/tom/anaconda3/lib/python3.6/site-packages/exoplanet-0.1.2.dev0-py3.6.egg/exoplanet/theano_ops/starry/get_cl_rev.cc'

And you included --recursive and you first did pip uninstall exoplanet?

yes to both.

In that case, try:
python setup.py develop

instead!

python setup.py develop

imports and works correctly

OK. Great! I see what's happening and I'm not sure why, but I'll try to work it out. Thanks for letting me know!

I figured it out. setup.py install should work for master now.


NonMaxSuppression not implemented yet

Hi,
I'm trying to convert YoloV7-tiny.onnx to keras by using cli command below
python converter.py --weights "yolov7-tiny.onnx" --formats "keras"
but raise exception:
Traceback (most recent call last):
  File "converter.py", line 73, in <module>
    run()
  File "converter.py", line 57, in run
    onnx_converter(
  File "converter.py", line 19, in onnx_converter
    keras_model = keras_builder(model_proto, input_node_names, output_node_names, native_groupconv)
  File "/outerDisk1/onnx2tflite/utils/builder.py", line 101, in keras_builder
    raise KeyError(f"{op_name} not implemented yet")
KeyError: 'NonMaxSuppression not implemented yet'

anyone know how to fix it?

NonMaxSuppression is a dynamic operator, and maybe not suitable for tflite.
You should not add "--include-nms" in export yolov7 onnx, remove it and try again.

I export onnx by this command:
python export.py --weights weights/yolov7-tiny.pt --grid --end2end --simplify --topk-all 100 --iou-thres 0.65 --conf-thres 0.35 --img-size 320 320 --max-wh 320
but still not work. any suggestion?

I'm run this command, and successed.
python export.py --weights ./yolov7-tiny.pt --grid --simplify

My yolov7 version is latest, maybe you should check cafefully.

I found that NMS operator would added when parameter --end2end was set, remove it will be ok, thanks!


Error Message for incompletely parsed queries is bad

When a query cannot be parsed completely the given error message is very confusing. The message also does not indicate where exactly the problem is and thus does not help in finding the error. It probably shouldn't be an assertion error but just a normal error.
The error message should indicate that the query could not be parsed completely and which part could not be parsed.
I can fix this problem. This issue is just a reminder for me to not forget it. Feel free to assign me Johannes.
Try e.g. this query with a trailing )
PREFIX wd: <http://www.wikidata.org/entity/>
PREFIX wdt: <http://www.wikidata.org/prop/direct/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
SELECT DISTINCT ?name ?population WHERE {
  ?city wdt:P31/wdt:P279* wd:Q515 .
  ?city wdt:P17 wd:Q183 .
  ?city wdt:P1082 ?population .
  ?city rdfs:label ?name .
  FILTER (LANG(?name) = "de")
}
ORDER BY DESC(?population) )

Ok. The problem was missing brackets in the grammar for the rule queryOrUpdate. Because of this queries triggered the assertion instead of a proper error. Solution: change queryOrUpdate: query | update EOF to queryOrUpdate: (query | update) EOF. See #1419


getCurrentListView() method does not get ListView from current page

From<EMAIL_ADDRESS>on October 14, 2011 02:18:16
What steps will reproduce the problem? 1. Page A has one ListView, and TextView textV is in this ListView's first ItemView.
Page B is Page A's next page, there is no textV in Page B.
2. The current page is Page B, then run these code.
ArrayList viewlist = solo.getCurrentListView();
View first = viewlist.get(0).getChildAt(1);
TextView textV = (TextView)first.findViewById(R.id.textV);
solo.clickOnView(textV);
What is the expected output?
It should have error, like cannot find the view.
Because textV is not in Page B, but we run the code when current page is Page B.
What do you see instead?
No any error. What version of the product are you using? On what operating system? Robotium 2.5, Android OS 2.2 Please provide any additional information below.
Original issue: http://code.google.com/p/robotium/issues/detail?id=173

From<EMAIL_ADDRESS>on October 14, 2011 17:18:21
The list view still exists. It is probably set to invincible when going to page 5. The list however still exists and that is why it is returned to you.
Status: Invalid


Fixed minor formatting issues preventing the full build

What is this PR for?
Fixed minor issues in Java files formatting to make maven-checkstyle-plugin happy
What type of PR is it?
Improvement
Todos
What is the Jira issue?
How should this be tested?

Regular regressions tests

Screenshots (if appropriate)
Questions:

Does the license files need to update?
Is there breaking changes for older versions?
Does this needs documentation?

No license updates, no breaking changes, no need for extra docs.

I think it would be good if with this fix the checkstyle plugin is enabled.

I think it would be good if with this fix the checkstyle plugin is enabled.

It seems to be enabled, at least it was complaining without the fixes when I followed the general build instructions from the docs

I see. Which Maven command did you run?

I see. Which Maven command did you run?

mvn clean package -DskipTests

I am surprised that there are no errors in the CI.
Do you see errors in the CI system? Maybe we should adjust the default build.

Thank you, I can reproduce the issue.
Can you change the Goal package to verify in the following line? Then the CI system should run checkstyle. Unfortunately the phase package is not enough.
https://github.com/apache/zeppelin/blob/1e9c7fd0496f13b73c26dc3eef254c90c4a70ee7/.github/workflows/core.yml#L486


Rename the "/BSOminigame" commands to "/CustomMinigames"

🐛 Bug Report
Ever since /bs became a command, it also brings up the /bsominigames due to sharing 2 letters. This makes it nearly impossible to see the /bs command. Changing the name to customminigames will solve this issue and make /bs much more user-friendly.
While an alternative solution exists in changing /bs > /banksearch, the convenience of typing 2 letters for the command is incredible. Full name would ruin that.
Image of what /bs currently brings up:

I think this needs to be polled.


Room detail

To display the talk list in a better way, could be copied as is in a mail or other.

Coverage remained the same at 78.82% when pulling 722444aaa79903eeaaa03c157f0cf12f2d2aa94d on room_detail into 933d468dcbaa3a2235a1b78e1d1fbd76c67de721 on master.

Coverage remained the same at 78.82% when pulling 337ef2ea294f4316687c024da4e27b9b19fb7c70 on room_detail into 933d468dcbaa3a2235a1b78e1d1fbd76c67de721 on master.

Coverage remained the same at 78.82% when pulling 337ef2ea294f4316687c024da4e27b9b19fb7c70 on room_detail into 933d468dcbaa3a2235a1b78e1d1fbd76c67de721 on master.


Feature: Check for cast error

API
Python
Description
I'd like to see a feature in Cypher in which I can test a CAST to a target type and return TRUE if the cast was successful else FALSE.
That would make it possible to select nodes that don't have the right field types.

Hi @ubmarco, we can provide a tryCast() function that never throw exception instead return NULL if cast fails. Return true/false might conflict with the case when tryCast(input, BOOL).

Sounds good! In terms of performance, do you consider casting and try-casting expensive?


ipfs: update everything to latest master

Note: already have this running on nihal.
Putting the cowboy hat on, since the canaries lack 38 commits from master:
https://github.com/ipfs/go-ipfs/compare/9eba0e4ffbbf5230a54788e546ea822b357eea6f...8d6ac7a83f91089d536790f3db07ed653a8a1c04
The storage hosts have been on 0.4.3-rc3 and 0.4.4 respectively.
They haven't been updated as often because it sometimes requires
coordination with community members who use them for archives work.
Adding the CCC archive to nihal showed a few interesting things which
probably have been fixed on master -- such as the amount of effort
put into synchronizing provider records.
License: MIT
Signed-off-by: Lars Gierth<EMAIL_ADDRESS>

I am reluctant about merging by 3rd person in this repo, I think the creator and merger should deploy changes as they create merge commit.


'NO VALID DATA' message not written with plot command

Reported by joe mclean on 26 Oct 2004 16:51 UTC
There is a difference in behavior for Ferret plot(1d) and shade(2d) commands
when all of the data is missing.
def axis/x=80W:20W:1 xax
def axis/y=20N:20N:1 yax
def axis/t="1-sep-2004":"25-oct-2004":1/unit=hours tax
let var1 = 0*x[var/bad=-22 var1
stat var1
shade var1
pause Now do the same with one dimension
let var2 = 0*t[gt=tax](gx=xax]*y[gy=yax]*t[gt=tax]-22
set)-22
set var/bad=-22 var2
stat var2
plot var2
pause There is no NO VALID DATA message
Migrated-From: http://dunkel.pmel.noaa.gov/trac/ferret/ticket/1038

Comment by<EMAIL_ADDRESS>on 26 Oct 2004 16:54 UTC
What is the desired behavior when using the /OVERLAY qualifier?  The 'NO VALID
DATA' message shouldn't appear on the plot when missing data is plotted over
good data.  Would it be better to attach the message to the label of the overlay
(by default positioned left and below the plot)?

Comment by<EMAIL_ADDRESS>on 5 Aug 2008 00:44 UTC
Fixed in xeq/xeq_plot.F and plt/plot_set_up.F
If a line plot has no valid data put NO VALID DATA across it, as is done with 2D
plots
If a line plot overlay is requested, but the line has no valid data, this is
noted in the key information at the bottom of the plot  i.e var2 No Valid Data.
This is also consistent with what is done with line plots
If several lines are requested at once,
yes? plot v1, v2, v3, v4
and if any of these have all-missing data, then that is noted after the
individual variable in the key at the bottom of the plot.
(Note that now that this is the case, 1D plots should be fixed as well as 2D, in
bug 1586)


Add EDE (RFC8914) caching

Thanks @wcawijngaards for the review!
I believe the easiest way (because of all the changes here) to now include the feature for cachedb and ecs is to bring @TCY16's relevant commits here from #790.


Changed instance type to m5.large.

I added my GPG key to github.

It's a local git client config.


Add lsb-release dependency to agent and mgmt server on Debian/Ubuntu.

The cloudstack-setup-management script needs the lsb_release command. This command is provided by the lsb-release package on Debian and Ubuntu, and this is not always installed by default. So, it should be added as a dependency to cloudstack-management.

LGTM, simple change

Apparently the build of this pull request sucked Jenkins into a black hole. The build returns 404.

I've updated this pull request @bhaisaab. The dependency needs to be added to cloudstack-agent as well due to a similar problem with the cloudstack-setup-agent script (they both depend on the same Python libraries).

What do we do about this since it is against the 4.6 branch?  Do you want to close this and open it against the 4.7 branch?

Since it's a bug fix, according to the current CS workflow it should be put on the oldest supported release branch and then forward merged. I can resubmit it against 4.7 if need be though.

@ProjectMoon Can you open a new PR against 4.7 with this?  We're really only supporting 4.7.x onward.
Trivial packing change. LTGM

@ProjectMoon please close this and open against 4.7+, thanks
tag:closeme

Closing to open new PR.


chore: guide for upgrading k8s version support in cdk8s & cdk8s+ (#1232)

Backport
This will backport the following commits from k8s-25/main to k8s-23/main:

chore: guide for upgrading k8s version support in cdk8s & cdk8s+ (#1232)

Questions ?
Please refer to the Backport tool documentation

⚪ Backport skipped
The pull request was not backported as there were no branches to backport to. If this is a mistake, please apply the desired version labels or run the backport tool manually.
Manual backport
To create the backport manually run:
backport --pr 1738

Questions ?
Please refer to the Backport tool documentation


Thanks, and maybe a bug?

Hi! This code is GOLD. Thanks so much for putting it together!
Wanted to report a couple of maybe-bugs.
In Gaussian Blur, sigma is calculated automatically as if (sigma < 0) sigma = sigma = size / 4;. For one thing sigma is set twice, but the main issue is that I had thought that sigma was normally calculated as radius/3; which would mean /6 here? I guess it's more a preference anyway.
In the same function, int ys is calculated but unused - xs is used for x and y. Is that an oversight?
Ta!

Fixed in commit 73f1cb1


feat: relocate js sdk to merge

feat: separate adapter and collector, add demangling
feat: add datadog adapter, re-export from sdk
feat: implement support for allocation tracking
chore: centralize util id functions
fix: update import paths
chore: remove span collector id
fix: add modsurfer-demangle to the repo
fix: correct trace endpoint, address pr feedback
fix: duration correction
chore: remove name truncation
fix: use put for datadog request
feat: Produce bundles for Deno & Node
feat: add web build
feat: create separate npm packages for datadog and stdout adapters
feat: create separate npm packages for datadog and stdout adapters
fix: support allocation tracing attached to functions (#4)

fix: support allocation tracing attached to functions

chore: include additional wasm module for testing

test: update tests to use other wasm

fix: update package.json to use new tests

chore: gen build files
chore: commit build files
fix: node test
chore: create packages directory
chore: use package name as directory name
feat: parse custom name section without wasm-parser, create universal distributables
chore: package cleanup
chore: remove dist
chore: relocate js sdk to merge

We should add some CI actions to run the example scripts for at least the stdout adapter


[android] implement support for qModuleInfo packet

Purpose
Properly respond to the GDB qModuleInfo packet, defined here, in the DS2 platform session.
Overview

Implement basic support to parse the build ID out of an ELF executable file
Define a new GetExecutableFileBuildID method in the Host::Platform interface and implement a Linux and FreeBSD version based on the new ELF support to fetch build ID
Define a new fileSize method in the Host::File interface and implement a POSIX version based on stat
Define a new onQueryModuleInfo method in the Session interface and implement it in the platform session using the new file size and executable file build ID implementations

If deemed important, we can eventually implement jModulesInfo using the bulk of this implementation.
Problem Details
Though qModuleInfo is documented as optional for lldb support, I have found it must be implemented on Android in order to properly resolve symbols of on-device executable files.
Validation
On an aarch64 Android device and x86_64 Android emulator, attach lldb to a ds2 instance running in the app sandbox. Verify that images are loaded with (lldb) image list.
Verify Swift symbols from an Android test app can be looked-up in lldb:
(lldb) image lookup --name getSwiftGreeting
2 matches found in C:\Users\user\.lldb\module_cache\remote-android\.cache\2749C9AB-7810-6105\libSwiftMainActivity.so:
        Address: libSwiftMainActivity.so[0x0000000000006f40] (libSwiftMainActivity.so.PT_LOAD[1]..text + 864)
        Summary: libSwiftMainActivity.so`Java_com_thebrowsercompany_SwiftSupportTestApp_MainActivity_getSwiftGreeting at <compiler-generated>
        Address: libSwiftMainActivity.so[0x0000000000006f50] (libSwiftMainActivity.so.PT_LOAD[1]..text + 880)
        Summary: libSwiftMainActivity.so`SwiftMainActivity.getSwiftGreeting(Swift.UnsafeMutablePointer<Swift.Optional<Swift.UnsafePointer<__C.JNINativeInterface>>>, Swift.UnsafeMutableRawPointer) -> Swift.Optional<Swift.UnsafeMutableRawPointer> at MainActivity.swift:8
(lldb)

Build and execute on an AMD64 FreeBSD 14.0 host to verify the build is not broken.

@compnerd please have a look when you get a chance

@compnerd feedback addressed, ready for re-review


docs: minimal prisma example

Thanks! Please also add a typescript example including codegen.

@timsuchanek : Added the TS example with codegen and documented it. Merging this one. Please let me know if any further changes are needed.


Application not working after reinstall

The application does a device registration process during startup. However, when the app is uninstalled and installed again it does no longer work, as i believe it tries to register the device again when it is already registered

Thanks - we'll look into it. Could you please provide your phone's make, model, and Android version number?

Sure. It’s a motog Falcón using android 7, but my understanding is that it’s a problem in the back end and not related to the device

I uninstalled and reinstalled on Galaxy S6 Android 7.0 and did not experience an issue.

I uninstalled and reinstalled on a Galaxy S9+ Android 10.0 and also did not experience an issue

I'm pasting this message in every active GitHub issue, so you may receive duplicate notifications.
Today, I'm happy to announce that NHSX has released the full git commit history for the Isle of Wight Beta apps.

Android - https://github.com/nhsx/COVID-19-app-Android-BETA
iOS - https://github.com/nhsx/COVID-19-app-iOS-BETA

As discussed, we have redacted API keys, sensitive domain names, and some of the developers' personal details. I am still waiting on final approval to publish the server-side code.
I would like to personally thank the community for your comments, bug reports, and vulnerability disclosures. They all went into helping the development process.
The beta trial of this app has now ended and we've moved to the next phase of app development. It is our intention to publish the source code of future apps as the binaries are released to the public.
Once again, thank you for being part of this.
Terence Eden
Head of Open Technology - NHSX


Clean up build setup

@neurolabusc reached out to me due to working with npm run demo being really slow and a non-pleasant setup in general, as restarting it was required on changes.
This PR replaces npm run dev with a structurally similar setup that uses Vite to serve the demos.
A few questions and points:

Was npm run dev still used for something? It served src/index.html, which wasn't changed substantially in a long time. If yes, I'll integrate it into the new npm run dev.
As this change will certainly need some discussion, I only adapted features/basic.multiplanar.html so far.
This PR will require changes to how the demos are hosted on GitHub Pages. This is not a complicated change (use actions/deploy-pages on push to main) and I can take care of it within this PR once no other discussion points are open.

Changes:

prepare some HTML files to be actually valid HTML (i.e. no non-tags in text like <lp_sigma>)
remove unused vite.config_inject.ts
add new vite.config.demos.ts
adapt NiiVue import in demo HTMLs to point to source code
npm run dev: runs the demos in dev mode with HMR and all other bells and whistles, startup and iterations should be near instantaneous
npm run demo: runs a built version of the demos, similar to how it worked before
npm run build:demo: invoked by npm run demo (and by the deploy step later) to build the demos

@jens-ox thanks for your quick response.

npm run dev is crucial for development of new features, it allows hot loading of the code base, allowing us to experiment with new features. The src/index.html has not been changed, as it is a basic starting point. In reality, I modify this file to develop new features, but I do not change this in the master branch. So in general, I create new features using npm run dev, and then use npm run demo to ensure that there are no unintended consequences and also to create a /demos/features/*.html to illustrate the new features.

@jens-ox , This does look like a great improvement to the dev experience.

I think it's best to keep src/index.html. I regularly use npm run dev while editing the niivue code base. Just as @neurolabusc, I do not often commit changes to src/index.html. It's very useful to have as a playground.
Perhaps src/index.html could have a link to the updated demos with HMR. something like click here for HMR demos. This way, everything that we would want to experiment with would have HMR features.
With the new npm run demo, it looks like each demo will get its own javascript file to accompany the html. Is that right? Seems fine to me.
The hosted demo pages will just need to be built first (as you started to do with the new config file and example html input path). We will need to add the base property to the vite.config.demos.ts file to accomodate our pages repo setup. Or just set base to base: './' (which has worked well for me in the past).

@neurolabusc @hanayik
I've split up dev and demo properly, see the updated PR description. npm run dev works like before and npm run demo runs the demos in Vite's dev mode (note that only basic.multiplanar is migrated so far).

@jens-ox, This draft looks good to me (with the exception of the comment below). It will be nice to have the demos update in real-time during development. Are you happy to finish updating the remaining demo *.html files as part of this PR, or would you like someone else to take over now that you've provided the proof of concept?
small exception
I noticed that vite.config_inject.js is actually still used. This is purely to allow the AFNI developers to build the UMD version since they were relying on it. While not strictly necessary (their code could be ported to not use the UMD version), it would be good to keep this in for them for now. The UMD is not an "exposed" entry point for niivue in any other context, so other projects should not be affected (hopefully).

Hey @jens-ox !

This PR will require changes to how the demos are hosted on GitHub Pages. This is not a complicated change (use actions/deploy-pages on push to main) and I can take care of it within this PR once no other discussion points are open.

If you want to host your vite app on GitHub pages, you can use this workflow:
https://github.com/kolibril13/niivue-vite-vanillajs-app/blob/main/.github/workflows/deployvite.yml
I've hosted my own vite app with niivue
https://github.com/kolibril13/niivue-vite-vanillajs-app/blob/main/.github/workflows/deployvite.yml
(make sure you also add this line to the config file)

@jens-ox, is this draft PR still something that you are looking into? At the least, it would be good to get the dev mode for demos merged in (and then expanded to all demo pages). The code and some config files have progressed since this PR was started, so we may need to resolve some conflicts.

Hi @hanayik! Sorry, I forgot about this PR. I'll look into it this weekend.


s3secret multi-path and cleanup

Summary: a relatively small change, general cleanup of the code, extending the paths to multiple paths inside a s3 bucket

adding licence headers to the files
added a makefile to make build easier
added some intellij ignores - do forgive
cleaned up elements of the code
a small feature, instead of single BUCKET/PATH we can now get multiple paths within a bucket and write out if require event specific files.
removed the verbose flag and using the standard glog lib instead
added a dryrun to print to screen for test purposes
by default if not path is set, we take the root, we do NOT allow the root to propagate though, i.e. it will not go recursive
updated the README.md to reflect the changes

Nice one! LGTM
Just not sure we need a Makefile.


instance size preference - why it chooses the biggest ec2 when only 1 pod is requested

Version

Karpenter Version: v0.18.1

Kubernetes Version: v1.0.0
Expected Behavior
I would expect that when 1 pod is requested a "big enough" EC2 will be launched, but not the biggest one. What I see in the logs that every time a small spark job starts (executor.instances=1) karpenter launches a 48CPU machine. Isnt that an overkill?
Actual Behavior
Karpenter decideds to run r6id.12xlarge all the time.
INFO controller.provisioning Found 1 provisionable pod(s) {"commit": "51becf8-dirty"}
--
Wed, Nov 30 2022 2:19:32 pm | 2022-11-30T13:19:32.399Z INFO controller.provisioning Computed 1 new node(s) will fit 1 pod(s) {"commit": "51becf8-dirty"}
Wed, Nov 30 2022 2:19:32 pm | 2022-11-30T13:19:32.399Z INFO controller.provisioning Launching node with 1 pods requesting {"cpu":"2125m","memory":"2Gi","pods":"4"} from types r6id.2xlarge, m6id.2xlarge, r6id.4xlarge, m6id.4xlarge, m6id.8xlarge and 5 other(s) {"commit": "51becf8-dirty", "provisioner": "spark-prov"}
Wed, Nov 30 2022 2:19:34 pm | 2022-11-30T13:19:34.767Z INFO controller.provisioning.cloudprovider Launched instance: i-045a4cefaaac678be, hostname: ip-11-5-150-196.eu-west-1.compute.internal, type: r6id.12xlarge, zone: eu-west-1b, capacityType: spot {"commit": "51becf8-dirty", "provisioner": "spark-prov"}
Wed, Nov 30 2022 2:21:26 pm | 2022-11-30T13:21:26.932Z INFO controller.node Added TTL to empty node {"commit": "51becf8-dirty", "node": "ip-11-5-150-196.eu-west-1.compute.internal"}
Wed, Nov 30 2022 2:21:26 pm | 2022-11-30T13:21:26.955Z INFO controller.node Added TTL to empty node {"commit": "51becf8-dirty", "node": "ip-11-5-150-196.eu-west-1.compute.internal"}

Steps to Reproduce the Problem
The provisioner we use in this case:
apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
  name: spark-prov
spec:
  providerRef:
    name: spark-template-nvme
  # Application requirements
  requirements:
    - key: karpenter.sh/capacity-type
      operator: In
      values:
        - spot
    - key: kubernetes.io/arch
      operator: In
      values:
        - amd64
    - key: "node.kubernetes.io/instance-type"
      operator: In
      values: ["m6id.large", "m6id.2xlarge", "m6id.4xlarge", "m6id.8xlarge", "m6id.12xlarge", "m6id.16xlarge","r6id.2xlarge", "r6id.4xlarge", "r6id.8xlarge", "r6id.12xlarge", "r6id.16xlarge"]
  limits:
    resources:
      cpu: '600'
  taints:
    - key: spark
      effect: NoSchedule
  labels:
    node-group: spark-prod
  ttlSecondsAfterEmpty: 60

Resource Specs and Logs
See the log output in actual behaviour
Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

spot market can be weird.
but even at spot prices, seems overkill, indeed.

Beyond the prices, it's possible that the capacity simply wasn't available.

In karpenter 1.19, we use a new fleet strategy that optimizes more heavily for price, rather than spot pool depth. Read more here: https://github.com/aws/karpenter/pull/2835


Preview documents via JS.

scribd-dl version: pip
Python version: 3.6.4
Operating System: Archlinux

Description
I wanted to download a pdf. Perhaps it ought to be integrated with this or this to get all files...
What I Did
scribd-dl https://www.scribd.com/presentation/41048167/AOA-ppt
[41048167]  Visiting requested url
[41048167]  Error: this document is only a preview and not fully availabe for reading

That's a pretty good idea. I will definitely take the time to experiment with that soon.
In the meantime, feel free to create a pull request, if you have the time.

Well I'm not well versed with chromedriver at all... But I can try to take a look in a few days..


Redis single for AWS ElastiCache

Hi,
Is Redis single compatible with Amazon ElastiCache or only GCP and Azure ?

Redis single mode allows to specify only one node. You can specify a master node of Amazon ElastiCache, but failover won't work. Use replicated or cluster mode instead.


Tube model wrong output

I was reading the paper: Wave Digital Simulation of a Vacuum-Tube Amplifier recreated in the TubeModel.m and something is wrong or missing, the model it is not behaving like a tube. Since Vg = 20 is constant the tube is always saturated, and  is not posible to recreate Fig. 5 in the paper where saturation is a directly related to the amplitude. Also the implementation is weird, since the signal is feeded from a constant voltage source.

Yes, I remember the response not being correct and behaving weird. Feel free to update it and make a pull request.

@Bk8 did you ever solve this? I'm trying to reimplement this in python and have the same issue.

@kevin-nel No, I was not able to fix it. There are a couple of errors, not even the Newton-Raphson solver is correctly implemented. Maybe if you have a public repo of the Python implementation I could take a look again at it.


Use CSS Custom properties for colour values in all components

Most components use css custom properties, but some have been overlooked:

Typography
Popover
Search
Radio

Not relevant anymore with the new tokens model. Closing issue.


compile to wasm？

I'm curious is it possible or any plan compile sharp to wasm? Building sharp in docker is complicated and too heave, if we can compile to wasm then we got cross platform binaries.

Previously asked here: https://github.com/lovell/sharp/issues/1476


Hi, you can download it here: https://drive.google.com/file/d/1D6-sDPEkOJX32h0-EclxpiEmiMkNGybo/view?usp=sharing

Hi, you can download it here: https://drive.google.com/file/d/1D6-sDPEkOJX32h0-EclxpiEmiMkNGybo/view?usp=sharing
Originally posted by @JaywongWang in https://github.com/JaywongWang/DenseVideoCaptioning/issues/1#issuecomment-427807540
I am unable to download this feature file from above link and can u please tell me how this feature file is different from feature file used for  training i.e. activitynet_c3d_fc7_stride_64_frame.hdf5

You may try https://drive.google.com/open?id=1UquwlUXibq-RERE8UO4_vSTf5IX67JhW .
The official C3D is in http://activity-net.org/challenges/2016/download.html#c3d . The features are with stride of 8 frames. In my paper, I directly downsample the features to stride of 64 frames (8-times) by mean pooling (a mean pooling layer with kernel=8 and stride=8). Please download the codes for generating h5 file in my updated repo.

why you are using sub_activitynet_v1-3_stride_64frame.c3d.hdf5 file to generate anchors and get their weights while you are using  activitynet_c3d_fc7_stride_64_frame.hdf5 for training. Are both the files same.

They are the same. I accidentally renamed the file.

Hi
GauravKrRoy,
I am trying to execute test.py but getting the following error.
Restoring model from
ValueError Traceback (most recent call last)
in
3 tf.reset_default_graph()
4 options = default_options()
----> 5 test(options)
in test(options)
20 print('Restoring model from %s'%options['init_from'])
21 saver = tf.train.Saver()
---> 22 saver.restore(sess, options['init_from'])
23
24 word2ix = options['vocab']
/usr/local/lib/python3.6/dist-packages/tensorflow_core/python/training/saver.py in restore(self, sess, save_path)
1280 if not checkpoint_management.checkpoint_exists_internal(checkpoint_prefix):
1281 raise ValueError("The passed save_path is not a valid checkpoint: " +
-> 1282 checkpoint_prefix)
1283
1284 logging.info("Restoring parameters from %s", checkpoint_prefix)
ValueError: The passed save_path is not a valid checkpoint:
Could you please help me on these issues?
Thanks for your time and great work!


PaymentDetailsService: Call method on 'null'

The PaymentDetailsService throws an error "Call method on null' when calling it.
In the Shopware 6 OrderTransactionEntity the order is null, so no SalesChannelId of the OrderEntity is retrieved.

Versions
Shopware version: <IP_ADDRESS>
Plugin version: 3.0.0
PHP version: ^8.0 | ^7.4
To Reproduce
Steps to reproduce the behavior:

Initialize PaymentDetailsService in a controller or an EventListener.
Pass the OrderTransactionEntity for the order.
Complete an order and check the PaymentDetails

Expected behavior
Return PaymentDetails from PaymentDetailsService
Code Example
`
........
class OrderEventListener implements EventSubscriberInterface
{
public function __construct(private LoggerInterface $logger, private OrderService $orderService)
{
}
/*
 * @return array<string, mixed>
 */
public static function getSubscribedEvents()
{
    return [
        'state_enter.order_transaction.state.paid' => 'onOrderStatePaidEvent',
    ];
}

public function onOrderStatePaidEvent(OrderStateMachineStateChangeEvent $event): void
{
    try {
        $this->logger->info('Paid order....');
        $order = $event->getOrder();
        if ($order instanceof OrderEntity) {
            $this->getPaymentDetails($order);
        }
    } catch (RuntimeException $exception) {
        $this->logger->critical($exception->getTraceAsString())
        );
    }
}

private function getPaymentDetails(OrderEntity $order): void {
    $transaction = ($order->getTransactions())->filterByState(OrderTransactionStates::STATE_PAID)->first();
    $paymentDetails = $this->paymentDetails->getPaymentDetails([], $transaction);
}

.......
}
`

Hello Adyen,
do you have any feedback for me?
Kind regards

Hi @miguelseuster,
Thanks for reporting this, we will investigate this in internal ticket and we hope to work on a fix soon.
If you already have a working modification, please consider making a PR, then it can be even faster.

HI @miguelseuster, thanks for your feedback!
If you wish to access the order (->getOrder()) on an OrderTransactionEntity you have to make sure that the order association is fetched along with it.
I see that you are first getting the order transactions from the OrderEntity itself ($order->getTransactions()), doing it this way the returned OrderTransactionEntity objects will NOT contain the order association (i.e. getOrder() will be null), because $order->getTransactions()->first()->getOrder() does not really make sense.
I would recommend that you first fetch your order transactions directly from the database with the order association. You can see our OrderRepository implementation for an example of fetching entities with an association. Feel free to add a method to our OrderTransactionRepository and make a PR

Hi @miguelseuster since there are no more updates on this, I will assume that the comment above has resolved this issue and close this ticket.
Feel free to reopen this issue of the same problem persists or create a new issue for a different problem.
Thanks for contributing to adyen-shopware6


Boring SSL JAR conflict when using the same JAR in two different classpaths

Expected behavior
I have two isolated subprojects (with two different classpaths) which I can run each of them separately or at the same time. Both of these sub-projects contains the same netty-tcnative-boringssl-static-2.0.46.Final.jar. According to the Netty library loading logic here, when there is more than one resource, it gives an error.
It is better if the implementation could check at least the JAR is the same or not. If JARs are different, it is okay to give an error. But when urlsList has the same JAR twice, it is problematic to give an error.
Actual behavior
Gives an error without checking the JAR replications.
Steps to reproduce

Run netty SSL example with two classpaths

Netty version
netty-tcnative-boringssl-static-2.0.46.Final.jar
JVM version (e.g. java -version)

Java 11

OS version (e.g. uname -a)

macOS

@BuddhiWathsala PRs welcome

Maybe it would be even better to check if filename is the same and also compare the sha256 for the file. And if the filename is the same and the sha256 not fail. WDYT @BuddhiWathsala  ?

@normanmaurer, yes exactly. Checking the file names will solve my issue.

@BuddhiWathsala  see https://github.com/netty/netty/pull/11927


Inconsistent usage of attributes to mark a field as not null/required?

There might be a good reason for this if that is the case just close the issue!
But when marking a argument as required in some parts of this library use the RequiredAttribute and some parts use the GraphQLNotNullAttribute attribute.
I was confused why applying the RequiredAttribute to a field on my Entity had no effect, after looking at the source i found the GraphQLNotNullAttribute applying that attribute ensured that the field was marked as required.

You are right. I stupidly didn't know about/forgot about the default dotnet RequiredAttribute. We should deprecate GraphQLNotNullAttribute and use RequiredAttribute in its place.

Fixed in upcoming 1.1


Submission of comment results in 404 page when also using Kirby's re-routing of URL function

This is unfortunately a breaking change that will result in my needing to switch to use Disqus instead, if a solution cannot be determined. :(
I am using the approach described by Kirby here to re-route my blog's home page URL from https://[mysite.com]/blog to just https://[mysite.com] (without the "/blog") needed in the URL:
Routing | Omitting the blog folder in URLs
However, when I do that, every time I try to submit a comment (now testing live, not on localhost); it gives me a 404 page. The commenting works perfectly when I am not rerouting to remove the "/blog" from my URL.
I have been reading on Kirby and I found some guidance that may help; however I am not at all a master of PHP and have not figured out how to adapt it to my situation in a way that works:
Routing | Actions
...I think the issue is with the submit button and its action attribute, possibly...that is why I am wondering if this documentation could help to solve this issue?
If you have any way to solve that, that would be amazing! I am certain many Kirby users are re-routing their URLs in this way, so a solution to this problem would be helpful to us all!
Or if I need to ask this in the Kirby forum instead, please let me know. Thanks for all your work on this plugin; I really hope to be able to use it!!!

There are different approaches for routing in Kirby. Could you please share the code you are using for the routing process?

Sure thing. In my site/config/config.php file I have added:
c::set('home','blog');
c::set('routes', array(
array(
'pattern' => '(:any)',
'action'  => function($uid) {
  $page = page($uid);

  if(!$page) $page = page('blog/' . $uid);
  if(!$page) $page = site()->errorPage();

  return site()->visit($page);

}

),
array(
'pattern' => 'blog/(:any)',
'action'  => function($uid) {
go($uid);
}
)
));

UPDATE: I have asked my question in the Kirby Forum and got a response that fixed my issue!

Great, thank you for sharing the fix! May I close this issue?

Yes, definitely!


Convert to NuGet numbering to correct use of semver and remove pre-release tag

WARNING: NuGet package MightyORM 1.0.0-prealpha3 will shortly be unlisted, then relisted as MightyORM 0.1.0 (with 0.1.x and/or 0.2.y to follow).
This won't break anything except that, if you have already installed version 1.0.0-prealpha3, you will have the one-time task of manually forcing NuGet to (apparently) downgrade to Mighty 0.1.0 (or to 0.2.0 when it comes, if you were still on 1.0.0-prealpha3 then). After this, I'll make sure upgrades are upgrades (i.e. the number goes up!) and NuGet will automatically notify you about them as it should.
Note that below version 1.0.0, semver officially allows breaking changes on any version number change. I mention this because I am still playing around, somewhat, with the API naming of a few of the new features only - but at this stage this would involve only minor name changes at most (e.g. is ExecuteProcedure preferable to ExecuteAsProecedure); and I am definitely not - now or in any near future (if at all) - planning to break anything (other than the edge cases already documented in the project's README) for any existing Massive users who want to try Mighty.

Mighty 3.0.3-beta is now up on NuGet. I am working on finishing a documentation website.


TER-71 add test for inc load with null

Jira: TER-71
Before asking for review make sure that:

[x] In the case of modified import queries, I checked that the CustomQuery component is updated.

Testy uplne neprosly, napr. Snowflake, Teradata:

Tests\Keboola\Db\ImportExportFunctional\Teradata\ToFinal\IncrementalImportTest::testIncrementalImport with data set "multi pk" ...
Failed asserting that 5 matches expected 3.

jo, zrovna to resim

jeste jsem to rebasnul, ale posledni build prosel (krome mrtveho EXA)


[Research] Admin needs

Description:
[Description of the task]
Acceptance Criteria:
[Note: Use 'Given/When/Then' format if it makes sense to. Otherwise, a simple checklist that can be tested.]
Development Checklist:

[ ] ...
[ ] ...
[ ] ...

Dependencies

Blocked by
Blocking

Relevant documentation as reference
Definition of Ready

[ ] Acceptance criteria are included
[ ] Wireframes are included (if applicable)
[ ] Design / Solution is accepted by Product Owner (if applicable)
[ ] Dependencies are identified (technical, business, regulatory/policy)
[ ] Story has been estimated (under 13 pts)

Definition of Done

In progress:

[ ] Acceptance criteria are tested (Functionality meets the acceptance criteria defined in the ticket)
[ ] UI meets accessibility requirements
[ ] Unit tests are written
[ ] Work is traceable in GitHub
[ ] PR linked to ticket number
[ ] If needed/required - Dev adds flag/label to highlight any migration steps necessary prior to PROD deployment

Code review:

[ ] Code is peer reviewed and has passed CI/CD tests

QA:

[ ] Acceptance criteria are tested (Functionality meets the acceptance criteria defined in the ticket)
[ ] Code is potentially shippable to the production environment
[ ] Functional features have been tested and passed by QA
[ ] UI components tested by designer
[ ] Code is deployed to PROD when moved to 'done' column (unless requested otherwise by PO)

PO Review:

[ ] Acceptance criteria are tested (Functionality meets the acceptance criteria defined in the ticket)
[ ] Reviewed and approved by Product Owner

Notes:

This will be directly influenced by data modelling.
Majority of admin will be a mirror of what we offer on our api. - CRUD operations - create/update/delete

will have this on all of our objects - eg: protected area layer, facility, etc, whatever we are calling them.
In the past in the api side we ignored making crud operations (eg: A&R) - but now it bites us in the butt

Regardless, we need to make crud operations for it. Todo make ticket - for future work.
side note - right now - data model shows what's relevant now. Once confident, they will make api endpoints to facilitate creating/updating/deleting on those layers (sub area area). So currently, solidifying data model --- todo create tickets.

Refinement notes:

Cam - idea to include in this ticket - look into data types and build front-ends to support their CRUD endpoints.
todo: discuss timing and prioritization of this work (possibly seeing this as complementary of the user story session for admin side of things).
... and also expand to Park Operators as a next step to this first step.


Improved efficiency wrf_remove_urban

The function that removes urban areas and replace it with the dominant surrounding land use has been modified to improve efficiency. For each urban grid point, the function searches for most frequent land use category from the closest NPIX_NLC points that are not water or urban. To decide which grids are the closest, the function computes the distance over the entire domain. This slows down the process considerably. Now it looks over a tile of 2xNPIX_NLC by 2xNPIX_NLC grid points. The computation time is reduced considerably. This wasn't an issue over small domains, but in @matthiasdemuzere's example over Ireland, it was (partly due to missing values that shouldn't be there). Using that input files example, the time is reduced to a 10% of the original required time. Other minor changes are also introduced, mostly to define auxiliary variables in a cleaner way.

Hi @dargueso,
Thanks for this.
I have just tried this development on the d02 data from Ireland. The wrf_remove_urban routine is indeed much more efficient now, it was completed in 638.75 seconds. So that's good!
Yet the application was killed in a following step:
--> Create LCZ-based geo_em file
> Processing LP_URB2D ...
> Processing MH_URB2D ...
> Processing STDH_URB2D ...
> Processing HGT_URB2D ...
> Processing LB_URB2D ...
> Processing LF_URB2D ...
> Processing HI_URB2D ...
Killed

I am not sure what is causing this. I'll try to have a look later on.
I also noticed your optimisation did not pass our tests? So this is also something we need to look into ...

Hi @matthiasdemuzere,
thanks for letting me know. It run well in my computer, but I will check what may kill it.
I saw this morning that it didn't pass the tests, so I will check that too.
I'll let you know how it goes.

I checked in two other machines using python 3.9 and 3.8. It all went fine.
As for the tests, all three tests failed belong to test_wrf_remove_urban, which makes sense and it's a good sign. Some of those tests were probably based on how the code was implemented before. I will look into that.

Good morning,
I have fixed the issues that made the test fail. I have tested and it now pass all the tests.
@matthiasdemuzere, the error you got is likely due to a memory issue. I tried in an older machine and also got killed due to memory. In any case, this error has nothing to do with the changes implemented now in wrf_remove_urban. It is raised later on and probably due to the domain size. The issue didn't come up before because the code  was slow and you didn't run it until completion. I would say the error would raise in the previous version too if run with the same domain.

since the remove urban routine can take a while, and as a user, you are left in the dark, I thought it would be a good idea to have a sense of where the routine is at?
So I added a progress bar that monitors the outer loop, and the general progress of that routine?

Almost there ...
Except that test test_check_hi_values_fails_sample_size_too_small fails, in python 3.7 only?
Will have to check what is going on there?

this was run on python3.9 in a ubuntu VM with 6 cores and this processor (Intel(R) Core(TM) i7-10750H CPU @ 2.60GHz)

@theendlessriver13, I get the same thing on my new laptop too. I tested the optimisation over large domains, not small/standard ones. It looks like the modifications I introduced slow down the whole process. I need to check this.

maybe this also helps a little: currently 77.84% is spent in wrf_remove_urban (prior to the patch) after it's 88.44%. These are SVGs so you can click on them and zoom in and out

before the patch (entire program):

after the patch (only wrf_remove_urban)

I think we somehow have to avoid looping over each coordinate; I am no expert at all in xarray, but maybe apply_ufunc might be what you need? https://docs.xarray.dev/en/stable/examples/apply_ufunc_vectorize_1d.html. but maybe to be able to use this, the parts need to be split into separate functions which are then applied...

@theendlessriver13 thanks for the insight, very helpful!
I'm working on this to try to remove the loops, which I think I'm close to.

Good morning,
Looking into the code in detail, the _calc_distance_coord had some issues with precision. The algorithm is know to have large rounding errors when using low floating precision on small distances. Thus, the selection of the nearest K points was not accurate enough. It wasn't a big deal when looking for a large number of K nearest neighbours, but it can be an issue when K is small. Furthermore, the new green fraction was not exactly as expected, although the error was again small when using large K.
This part of the code has been revamped. We no longer use brute force to calculate distances, but KD trees, which makes the calculation much faster for both large and small domains. We were calculating distances from a given grid points to all points in the domain, and this is clearly an overkill that slows down the process. According to my test, the sample data is now processed in ~12 seconds and the Ireland domain is processed in ~370s. This is faster than the original version even for small domains.
I wasn't able to remove the loops, but it is more efficient now.
I need to make some tests and clear up the code before committing. I removed a test on the function that calculate distance with the previous method, so I guess we need to add a test for the new function.

Hi,
I have made some significant changes to the wrf_remove_urban function. It combines optimisation for both small and large domains:
Sample data -> best of 5: 10.821772583
Ireland data (large domain) -> best of 5:<PHONE_NUMBER>17
I couldn't avoid loops, but it know loops over a much smaller number of items. Also it only iterates over one dimension not two nested loops.
Results are not exactly the same as before, because distances are calculated slightly differently (see  comment above). There is also a change in how the urban fraction of landusef is transferred to the new landuse. Before, it was searching again for nearest grid points with a slightly different condition (landusef for urban must be zero) and calculates the mode again. It is now much simpler, because it just grabs the urban fraction and adds it to the new dominant landuse category.
It has passed tests, except pre-commit.ci (@theendlessriver13, can you help with this?)
It also passes the tests in my local machine using pytests.
I think we should consider to label this with a new version number, because the output values are not the same.
Cheers,

I think we could even speed this up more:
diff --git a/w2w/w2w.py b/w2w/w2w.py
index 18d9b43..76c47e7 100644
--- a/w2w/w2w.py
+++ b/w2w/w2w.py
@@ -12,6 +12,7 @@ import scipy.spatial as spatial
 import os, sys
 import argparse
 from argparse import RawTextHelpFormatter
+from multiprocessing import cpu_count
 import traceback
 from typing import Dict, Any
 from typing import List
@@ -405,7 +406,11 @@ def using_kdtree(
     data['y'] = R * np.cos(phi) * np.sin(theta)
     data['z'] = R * np.sin(phi)
     tree = spatial.KDTree(data[['x', 'y', 'z']])
-    distance, index = tree.query(data[['x', 'y', 'z']], k=kpoints)
+    distance, index = tree.query(
+        data[['x', 'y', 'z']],
+        k=kpoints,
+        workers=cpu_count() - 1
+    )

     return distance, index

This only takes 7 seconds for me with the sample data. However maybe this should also become an argument then, if you want to avoid using too many cores on a powerful machine. I was not able to test this on the ireland data, but this should also reduce this significantly.

Interesting.
@theendlessriver13: in case you want to test out with the Ireland files: geo_em.d02.nc and LCZ file.

I checked on my machine, for the large Ireland domain:

with the multiprocessing, time to solution:

real	5m48.359s
user	7m12.460s
sys	0m37.772s

without mp:

real	6m47.402s
user	6m12.215s
sys	0m31.903s

So not too much time gained.
On the good side: I am now able to process the large domain on my laptop, which was not possible before. So it seems much of the memory usage came from the old verrsion of remove_urb ?

I checked on my machine, for the large Ireland domain:

with the multiprocessing, time to solution:

real	5m48.359s
user	7m12.460s
sys	0m37.772s

without mp:

real	6m47.402s
user	6m12.215s
sys	0m31.903s

So not too much time gained.
On the good side: I am now able to process the large domain on my laptop, which was not possible before. So it seems much of the memory usage came from the old verrsion of remove_urb ?

Yep, similar here. I think we should keep it simple considering the limited impact, otherwise we would need to add new options and document them.

Yep, similar here. I think we should keep it simple considering the limited impact, otherwise we would need to add new options and document them.

Yes, @theendlessriver13 and myself agree not to have this multiprocessor function.

This all looks good to me. Perhaps @theendlessriver13 can have a last look, and then we can merge into main (and update version and pypi?)

Maybe I should also update the JOSS paper already? To add the info that is now added in README? I'll do this now ...