Add configuration option for terraform plugin dir

Fixes #565.
I posed a question on the issue itself about testing but its probably better to have the conversation here:
I'm having a hard time figuring out the best way to implement a test that would be easy to maintain long term. Testing that the -plugin-dir option is actually working requires having pre-downloaded providers. I wrote a test that uses a fixture with a pre-downloaded provider locally but i don't think committing the actual provider binary to the repo is a viable solution.
Do you have any suggestions on how to implement an actual test for this?
Thanks!

Implementation LGTM, but would be nice to have an integration test. I think you can test this by doing the following:

Take one of the terraform examples we have
Create a temporary folder as the plugin dir
Run terraform init without configuring plugin dir
Move the plugin folder from the created .terraform folder to the temporary path
Remove the .terraform folder
Run terraform init with the plugin dir configured to the temporary path

That sounds reasonable, let me give that a shot! thanks!

Thanks for adding the test! It mostly looks good. Had one minor nit around cleanup, and also have a suggestion for the concern around verifiability:
Perhaps we can run InitE with the PluginDir configured but before copying the plugins, and verify that it errors? That way we know the -plugin-dir is being passed given that it errors when the folder is empty, and passes when it is not. What do you think?

That's a great idea, definitely gives me more confidence that things are working as expected.
Here is what the test looks like now:
 $ go test --timeout 30m -run "TestInitPluginDir"
TestInitPluginDir 2021-02-18T15:21:56-05:00 retry.go:91: terraform [init -upgrade=false]
TestInitPluginDir 2021-02-18T15:21:56-05:00 logger.go:66: Running command terraform with args [init -upgrade=false]
TestInitPluginDir 2021-02-18T15:21:56-05:00 logger.go:66:
TestInitPluginDir 2021-02-18T15:21:56-05:00 logger.go:66: Initializing the backend...
TestInitPluginDir 2021-02-18T15:21:56-05:00 logger.go:66:
TestInitPluginDir 2021-02-18T15:21:56-05:00 logger.go:66: Initializing provider plugins...
TestInitPluginDir 2021-02-18T15:21:56-05:00 logger.go:66: - Finding latest version of hashicorp/null...
TestInitPluginDir 2021-02-18T15:21:56-05:00 logger.go:66: - Installing hashicorp/null v3.0.0...
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66: - Installed hashicorp/null v3.0.0 (signed by HashiCorp)
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66:
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66: The following providers do not have any version constraints in configuration,
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66: so the latest version was installed.
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66:
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66: To prevent automatic upgrades to new major versions that may contain breaking
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66: changes, we recommend adding version constraints in a required_providers block
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66: in your configuration, with the constraint strings suggested below.
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66:
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66: * hashicorp/null: version = "~> 3.0.0"
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66:
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66: Terraform has been successfully initialized!
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66:
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66: You may now begin working with Terraform. Try running "terraform plan" to see
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66: any changes that are required for your infrastructure. All Terraform commands
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66: should now work.
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66:
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66: If you ever set or change modules or backend configuration for Terraform,
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66: rerun this command to reinitialize your working directory. If you forget, other
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66: commands will detect it and remind you to do so if necessary.
TestInitPluginDir 2021-02-18T15:21:57-05:00 retry.go:91: terraform [init -upgrade=false -plugin-dir=/var/folders/h8/hcvd85715cn2s2wr9zwp13k80000gn/T/TestInitPluginDir994093440]
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66: Running command terraform with args [init -upgrade=false -plugin-dir=/var/folders/h8/hcvd85715cn2s2wr9zwp13k80000gn/T/TestInitPluginDir994093440]
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66:
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66: Error: Failed to query available provider packages
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66:
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66: Could not retrieve the list of available versions for provider hashicorp/null:
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66:
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66: Initializing the backend...
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66:
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66: Initializing provider plugins...
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66: provider registry.terraform.io/hashicorp/null was not found in any of the
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66: search locations
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66:
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66: - /var/folders/h8/hcvd85715cn2s2wr9zwp13k80000gn/T/TestInitPluginDir994093440
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66:
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66: - Finding latest version of hashicorp/null...
TestInitPluginDir 2021-02-18T15:21:57-05:00 retry.go:99: Returning due to fatal error: FatalError{Underlying: error while running command: exit status 1;
Error: Failed to query available provider packages

Could not retrieve the list of available versions for provider hashicorp/null:
provider registry.terraform.io/hashicorp/null was not found in any of the
search locations

- /var/folders/h8/hcvd85715cn2s2wr9zwp13k80000gn/T/TestInitPluginDir994093440
}
TestInitPluginDir 2021-02-18T15:21:57-05:00 retry.go:91: terraform [init -upgrade=false -plugin-dir=/var/folders/h8/hcvd85715cn2s2wr9zwp13k80000gn/T/TestInitPluginDir994093440]
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66: Running command terraform with args [init -upgrade=false -plugin-dir=/var/folders/h8/hcvd85715cn2s2wr9zwp13k80000gn/T/TestInitPluginDir994093440]
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66:
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66: Initializing the backend...
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66:
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66: Initializing provider plugins...
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66: - Finding latest version of hashicorp/null...
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66: - Installing hashicorp/null v3.0.0...
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66: - Installed hashicorp/null v3.0.0 (unauthenticated)
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66:
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66: The following providers do not have any version constraints in configuration,
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66: so the latest version was installed.
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66:
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66: To prevent automatic upgrades to new major versions that may contain breaking
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66: changes, we recommend adding version constraints in a required_providers block
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66: in your configuration, with the constraint strings suggested below.
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66:
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66: * hashicorp/null: version = "~> 3.0.0"
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66:
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66: Terraform has been successfully initialized!
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66:
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66: You may now begin working with Terraform. Try running "terraform plan" to see
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66: any changes that are required for your infrastructure. All Terraform commands
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66: should now work.
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66:
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66: If you ever set or change modules or backend configuration for Terraform,
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66: rerun this command to reinitialize your working directory. If you forget, other
TestInitPluginDir 2021-02-18T15:21:57-05:00 logger.go:66: commands will detect it and remind you to do so if necessary.
PASS
ok      github.com/gruntwork-io/terratest/modules/terraform     2.896s

Sorry for the delay in getting back to this. It looks like the tests are failing consistently, and only when run all together. I will have to investigate this to see what might be causing the concurrency issues, and will report back findings.

Sorry for the delay in getting back to this. It looks like the tests are failing consistently, and only when run all together. I will have to investigate this to see what might be causing the concurrency issues, and will report back findings.

Alrightly no problem, let me know if there's something I can help investigate!

@cbuto apologies for the delay in getting back to this. I got busy with other work initiatives and took a long time for me to come back.
I finally got to the bottom of the test failures. In our CI environment we use terraform 0.14, and the plugin folder changed (from plugins to providers) with that version. I can reliably reproduce the test failure on tf14.
Can you update the test to attempt to copy over both plugins and providers?

@cbuto apologies for the delay in getting back to this. I got busy with other work initiatives and took a long time for me to come back.
I finally got to the bottom of the test failures. In our CI environment we use terraform 0.14, and the plugin folder changed (from plugins to providers) with that version. I can reliably reproduce the test failure on tf14.
Can you update the test to attempt to copy over both .terraform/plugins and .terraform/providers?

@yorinasub17 No problem, I completely understand! Thanks for digging into this. I was always confused why terraform 0.13 called the directory plugins 😆 .
I updated the test to copy over both directories. I wonder if I should attempt to check the terraform version before doing the copy?
Anyway, the test passes now with both 0.13 and 0.14, let me know what you think:
➜  terraform git:(plugin-dir) ✗ go test --timeout 30m -run "TestInitPluginDir"
TestInitPluginDir 2021-03-17T09:08:37-04:00 retry.go:91: terraform [init -upgrade=false]
TestInitPluginDir 2021-03-17T09:08:37-04:00 logger.go:66: Running command terraform with args [init -upgrade=false]
TestInitPluginDir 2021-03-17T09:08:38-04:00 logger.go:66:
TestInitPluginDir 2021-03-17T09:08:38-04:00 logger.go:66: Initializing the backend...
TestInitPluginDir 2021-03-17T09:08:38-04:00 logger.go:66:
TestInitPluginDir 2021-03-17T09:08:38-04:00 logger.go:66: Initializing provider plugins...
TestInitPluginDir 2021-03-17T09:08:38-04:00 logger.go:66: - Finding latest version of hashicorp/null...
TestInitPluginDir 2021-03-17T09:08:39-04:00 logger.go:66: - Installing hashicorp/null v3.1.0...
TestInitPluginDir 2021-03-17T09:08:40-04:00 logger.go:66: - Installed hashicorp/null v3.1.0 (signed by HashiCorp)
TestInitPluginDir 2021-03-17T09:08:40-04:00 logger.go:66:
TestInitPluginDir 2021-03-17T09:08:40-04:00 logger.go:66: Terraform has created a lock file .terraform.lock.hcl to record the provider
TestInitPluginDir 2021-03-17T09:08:40-04:00 logger.go:66: selections it made above. Include this file in your version control repository
TestInitPluginDir 2021-03-17T09:08:40-04:00 logger.go:66: so that Terraform can guarantee to make the same selections by default when
TestInitPluginDir 2021-03-17T09:08:40-04:00 logger.go:66: you run "terraform init" in the future.
TestInitPluginDir 2021-03-17T09:08:40-04:00 logger.go:66:
TestInitPluginDir 2021-03-17T09:08:40-04:00 logger.go:66: Terraform has been successfully initialized!
TestInitPluginDir 2021-03-17T09:08:40-04:00 logger.go:66:
TestInitPluginDir 2021-03-17T09:08:40-04:00 logger.go:66: You may now begin working with Terraform. Try running "terraform plan" to see
TestInitPluginDir 2021-03-17T09:08:40-04:00 logger.go:66: any changes that are required for your infrastructure. All Terraform commands
TestInitPluginDir 2021-03-17T09:08:40-04:00 logger.go:66: should now work.
TestInitPluginDir 2021-03-17T09:08:40-04:00 logger.go:66:
TestInitPluginDir 2021-03-17T09:08:40-04:00 logger.go:66: If you ever set or change modules or backend configuration for Terraform,
TestInitPluginDir 2021-03-17T09:08:40-04:00 logger.go:66: rerun this command to reinitialize your working directory. If you forget, other
TestInitPluginDir 2021-03-17T09:08:40-04:00 logger.go:66: commands will detect it and remind you to do so if necessary.
TestInitPluginDir 2021-03-17T09:08:40-04:00 retry.go:91: terraform [init -upgrade=false -plugin-dir=/var/folders/h8/hcvd85715cn2s2wr9zwp13k80000gn/T/TestInitPluginDir211329488]
TestInitPluginDir 2021-03-17T09:08:40-04:00 logger.go:66: Running command terraform with args [init -upgrade=false -plugin-dir=/var/folders/h8/hcvd85715cn2s2wr9zwp13k80000gn/T/TestInitPluginDir211329488]
TestInitPluginDir 2021-03-17T09:08:41-04:00 logger.go:66:
TestInitPluginDir 2021-03-17T09:08:41-04:00 logger.go:66: Initializing the backend...
TestInitPluginDir 2021-03-17T09:08:41-04:00 logger.go:66:
TestInitPluginDir 2021-03-17T09:08:41-04:00 logger.go:66: Initializing provider plugins...
TestInitPluginDir 2021-03-17T09:08:41-04:00 logger.go:66: - Finding latest version of hashicorp/null...
TestInitPluginDir 2021-03-17T09:08:41-04:00 logger.go:66:
TestInitPluginDir 2021-03-17T09:08:41-04:00 logger.go:66: Error: Failed to query available provider packages
TestInitPluginDir 2021-03-17T09:08:41-04:00 logger.go:66:
TestInitPluginDir 2021-03-17T09:08:41-04:00 logger.go:66: Could not retrieve the list of available versions for provider hashicorp/null:
TestInitPluginDir 2021-03-17T09:08:41-04:00 logger.go:66: provider registry.terraform.io/hashicorp/null was not found in any of the
TestInitPluginDir 2021-03-17T09:08:41-04:00 logger.go:66: search locations
TestInitPluginDir 2021-03-17T09:08:41-04:00 logger.go:66:
TestInitPluginDir 2021-03-17T09:08:41-04:00 logger.go:66:   - /var/folders/h8/hcvd85715cn2s2wr9zwp13k80000gn/T/TestInitPluginDir211329488
TestInitPluginDir 2021-03-17T09:08:41-04:00 logger.go:66:
TestInitPluginDir 2021-03-17T09:08:41-04:00 retry.go:99: Returning due to fatal error: FatalError{Underlying: error while running command: exit status 1;
Error: Failed to query available provider packages

Could not retrieve the list of available versions for provider hashicorp/null:
provider registry.terraform.io/hashicorp/null was not found in any of the
search locations

  - /var/folders/h8/hcvd85715cn2s2wr9zwp13k80000gn/T/TestInitPluginDir211329488
}
TestInitPluginDir 2021-03-17T09:08:41-04:00 retry.go:91: terraform [init -upgrade=false -plugin-dir=/var/folders/h8/hcvd85715cn2s2wr9zwp13k80000gn/T/TestInitPluginDir211329488]
TestInitPluginDir 2021-03-17T09:08:41-04:00 logger.go:66: Running command terraform with args [init -upgrade=false -plugin-dir=/var/folders/h8/hcvd85715cn2s2wr9zwp13k80000gn/T/TestInitPluginDir211329488]
TestInitPluginDir 2021-03-17T09:08:42-04:00 logger.go:66:
TestInitPluginDir 2021-03-17T09:08:42-04:00 logger.go:66: Initializing the backend...
TestInitPluginDir 2021-03-17T09:08:42-04:00 logger.go:66:
TestInitPluginDir 2021-03-17T09:08:42-04:00 logger.go:66: Initializing provider plugins...
TestInitPluginDir 2021-03-17T09:08:42-04:00 logger.go:66: - Finding latest version of hashicorp/null...
TestInitPluginDir 2021-03-17T09:08:42-04:00 logger.go:66: - Installing hashicorp/null v3.1.0...
TestInitPluginDir 2021-03-17T09:08:42-04:00 logger.go:66: - Installed hashicorp/null v3.1.0 (unauthenticated)
TestInitPluginDir 2021-03-17T09:08:42-04:00 logger.go:66:
TestInitPluginDir 2021-03-17T09:08:42-04:00 logger.go:66: Terraform has created a lock file .terraform.lock.hcl to record the provider
TestInitPluginDir 2021-03-17T09:08:42-04:00 logger.go:66: selections it made above. Include this file in your version control repository
TestInitPluginDir 2021-03-17T09:08:42-04:00 logger.go:66: so that Terraform can guarantee to make the same selections by default when
TestInitPluginDir 2021-03-17T09:08:42-04:00 logger.go:66: you run "terraform init" in the future.
TestInitPluginDir 2021-03-17T09:08:42-04:00 logger.go:66:
TestInitPluginDir 2021-03-17T09:08:42-04:00 logger.go:66: Terraform has been successfully initialized!
TestInitPluginDir 2021-03-17T09:08:42-04:00 logger.go:66:
TestInitPluginDir 2021-03-17T09:08:42-04:00 logger.go:66: You may now begin working with Terraform. Try running "terraform plan" to see
TestInitPluginDir 2021-03-17T09:08:42-04:00 logger.go:66: any changes that are required for your infrastructure. All Terraform commands
TestInitPluginDir 2021-03-17T09:08:42-04:00 logger.go:66: should now work.
TestInitPluginDir 2021-03-17T09:08:42-04:00 logger.go:66:
TestInitPluginDir 2021-03-17T09:08:42-04:00 logger.go:66: If you ever set or change modules or backend configuration for Terraform,
TestInitPluginDir 2021-03-17T09:08:42-04:00 logger.go:66: rerun this command to reinitialize your working directory. If you forget, other
TestInitPluginDir 2021-03-17T09:08:42-04:00 logger.go:66: commands will detect it and remind you to do so if necessary.
PASS
ok      github.com/gruntwork-io/terratest/modules/terraform     6.124s
➜  terraform git:(plugin-dir) ✗ tfenv use 0.13.2
Switching default version to v0.13.2
Switching completed
➜  terraform git:(plugin-dir) ✗ go test --timeout 30m -run "TestInitPluginDir"
TestInitPluginDir 2021-03-17T09:09:37-04:00 retry.go:91: terraform [init -upgrade=false]
TestInitPluginDir 2021-03-17T09:09:37-04:00 logger.go:66: Running command terraform with args [init -upgrade=false]
TestInitPluginDir 2021-03-17T09:09:38-04:00 logger.go:66:
TestInitPluginDir 2021-03-17T09:09:38-04:00 logger.go:66: Initializing the backend...
TestInitPluginDir 2021-03-17T09:09:38-04:00 logger.go:66:
TestInitPluginDir 2021-03-17T09:09:38-04:00 logger.go:66: Initializing provider plugins...
TestInitPluginDir 2021-03-17T09:09:38-04:00 logger.go:66: - Finding latest version of hashicorp/null...
TestInitPluginDir 2021-03-17T09:09:39-04:00 logger.go:66: - Installing hashicorp/null v3.1.0...
TestInitPluginDir 2021-03-17T09:09:40-04:00 logger.go:66: - Installed hashicorp/null v3.1.0 (signed by HashiCorp)
TestInitPluginDir 2021-03-17T09:09:40-04:00 logger.go:66:
TestInitPluginDir 2021-03-17T09:09:40-04:00 logger.go:66: The following providers do not have any version constraints in configuration,
TestInitPluginDir 2021-03-17T09:09:40-04:00 logger.go:66: so the latest version was installed.
TestInitPluginDir 2021-03-17T09:09:40-04:00 logger.go:66:
TestInitPluginDir 2021-03-17T09:09:40-04:00 logger.go:66: To prevent automatic upgrades to new major versions that may contain breaking
TestInitPluginDir 2021-03-17T09:09:40-04:00 logger.go:66: changes, we recommend adding version constraints in a required_providers block
TestInitPluginDir 2021-03-17T09:09:40-04:00 logger.go:66: in your configuration, with the constraint strings suggested below.
TestInitPluginDir 2021-03-17T09:09:40-04:00 logger.go:66:
TestInitPluginDir 2021-03-17T09:09:40-04:00 logger.go:66: * hashicorp/null: version = "~> 3.1.0"
TestInitPluginDir 2021-03-17T09:09:40-04:00 logger.go:66:
TestInitPluginDir 2021-03-17T09:09:40-04:00 logger.go:66: Terraform has been successfully initialized!
TestInitPluginDir 2021-03-17T09:09:40-04:00 logger.go:66:
TestInitPluginDir 2021-03-17T09:09:40-04:00 logger.go:66: You may now begin working with Terraform. Try running "terraform plan" to see
TestInitPluginDir 2021-03-17T09:09:40-04:00 logger.go:66: any changes that are required for your infrastructure. All Terraform commands
TestInitPluginDir 2021-03-17T09:09:40-04:00 logger.go:66: should now work.
TestInitPluginDir 2021-03-17T09:09:40-04:00 logger.go:66:
TestInitPluginDir 2021-03-17T09:09:40-04:00 logger.go:66: If you ever set or change modules or backend configuration for Terraform,
TestInitPluginDir 2021-03-17T09:09:40-04:00 logger.go:66: rerun this command to reinitialize your working directory. If you forget, other
TestInitPluginDir 2021-03-17T09:09:40-04:00 logger.go:66: commands will detect it and remind you to do so if necessary.
TestInitPluginDir 2021-03-17T09:09:40-04:00 retry.go:91: terraform [init -upgrade=false -plugin-dir=/var/folders/h8/hcvd85715cn2s2wr9zwp13k80000gn/T/TestInitPluginDir865044869]
TestInitPluginDir 2021-03-17T09:09:40-04:00 logger.go:66: Running command terraform with args [init -upgrade=false -plugin-dir=/var/folders/h8/hcvd85715cn2s2wr9zwp13k80000gn/T/TestInitPluginDir865044869]
TestInitPluginDir 2021-03-17T09:09:41-04:00 logger.go:66:
TestInitPluginDir 2021-03-17T09:09:41-04:00 logger.go:66: Initializing the backend...
TestInitPluginDir 2021-03-17T09:09:41-04:00 logger.go:66:
TestInitPluginDir 2021-03-17T09:09:41-04:00 logger.go:66: Initializing provider plugins...
TestInitPluginDir 2021-03-17T09:09:41-04:00 logger.go:66: - Finding latest version of hashicorp/null...
TestInitPluginDir 2021-03-17T09:09:41-04:00 logger.go:66:
TestInitPluginDir 2021-03-17T09:09:41-04:00 logger.go:66: Error: Failed to query available provider packages
TestInitPluginDir 2021-03-17T09:09:41-04:00 logger.go:66:
TestInitPluginDir 2021-03-17T09:09:41-04:00 logger.go:66: Could not retrieve the list of available versions for provider hashicorp/null:
TestInitPluginDir 2021-03-17T09:09:41-04:00 logger.go:66: provider registry.terraform.io/hashicorp/null was not found in any of the
TestInitPluginDir 2021-03-17T09:09:41-04:00 logger.go:66: search locations
TestInitPluginDir 2021-03-17T09:09:41-04:00 logger.go:66:
TestInitPluginDir 2021-03-17T09:09:41-04:00 logger.go:66: - /var/folders/h8/hcvd85715cn2s2wr9zwp13k80000gn/T/TestInitPluginDir865044869
TestInitPluginDir 2021-03-17T09:09:41-04:00 logger.go:66:
TestInitPluginDir 2021-03-17T09:09:41-04:00 retry.go:99: Returning due to fatal error: FatalError{Underlying: error while running command: exit status 1;
Error: Failed to query available provider packages

Could not retrieve the list of available versions for provider hashicorp/null:
provider registry.terraform.io/hashicorp/null was not found in any of the
search locations

- /var/folders/h8/hcvd85715cn2s2wr9zwp13k80000gn/T/TestInitPluginDir865044869
}
TestInitPluginDir 2021-03-17T09:09:41-04:00 retry.go:91: terraform [init -upgrade=false -plugin-dir=/var/folders/h8/hcvd85715cn2s2wr9zwp13k80000gn/T/TestInitPluginDir865044869]
TestInitPluginDir 2021-03-17T09:09:41-04:00 logger.go:66: Running command terraform with args [init -upgrade=false -plugin-dir=/var/folders/h8/hcvd85715cn2s2wr9zwp13k80000gn/T/TestInitPluginDir865044869]
TestInitPluginDir 2021-03-17T09:09:42-04:00 logger.go:66:
TestInitPluginDir 2021-03-17T09:09:42-04:00 logger.go:66: Initializing the backend...
TestInitPluginDir 2021-03-17T09:09:42-04:00 logger.go:66:
TestInitPluginDir 2021-03-17T09:09:42-04:00 logger.go:66: Initializing provider plugins...
TestInitPluginDir 2021-03-17T09:09:42-04:00 logger.go:66: - Finding latest version of hashicorp/null...
TestInitPluginDir 2021-03-17T09:09:42-04:00 logger.go:66: - Installing hashicorp/null v3.1.0...
TestInitPluginDir 2021-03-17T09:09:42-04:00 logger.go:66: - Installed hashicorp/null v3.1.0 (unauthenticated)
TestInitPluginDir 2021-03-17T09:09:42-04:00 logger.go:66:
TestInitPluginDir 2021-03-17T09:09:42-04:00 logger.go:66: The following providers do not have any version constraints in configuration,
TestInitPluginDir 2021-03-17T09:09:42-04:00 logger.go:66: so the latest version was installed.
TestInitPluginDir 2021-03-17T09:09:42-04:00 logger.go:66:
TestInitPluginDir 2021-03-17T09:09:42-04:00 logger.go:66: To prevent automatic upgrades to new major versions that may contain breaking
TestInitPluginDir 2021-03-17T09:09:42-04:00 logger.go:66: changes, we recommend adding version constraints in a required_providers block
TestInitPluginDir 2021-03-17T09:09:42-04:00 logger.go:66: in your configuration, with the constraint strings suggested below.
TestInitPluginDir 2021-03-17T09:09:42-04:00 logger.go:66:
TestInitPluginDir 2021-03-17T09:09:42-04:00 logger.go:66: * hashicorp/null: version = "~> 3.1.0"
TestInitPluginDir 2021-03-17T09:09:42-04:00 logger.go:66:
TestInitPluginDir 2021-03-17T09:09:42-04:00 logger.go:66: Terraform has been successfully initialized!
TestInitPluginDir 2021-03-17T09:09:42-04:00 logger.go:66:
TestInitPluginDir 2021-03-17T09:09:42-04:00 logger.go:66: You may now begin working with Terraform. Try running "terraform plan" to see
TestInitPluginDir 2021-03-17T09:09:42-04:00 logger.go:66: any changes that are required for your infrastructure. All Terraform commands
TestInitPluginDir 2021-03-17T09:09:42-04:00 logger.go:66: should now work.
TestInitPluginDir 2021-03-17T09:09:42-04:00 logger.go:66:
TestInitPluginDir 2021-03-17T09:09:42-04:00 logger.go:66: If you ever set or change modules or backend configuration for Terraform,
TestInitPluginDir 2021-03-17T09:09:42-04:00 logger.go:66: rerun this command to reinitialize your working directory. If you forget, other
TestInitPluginDir 2021-03-17T09:09:42-04:00 logger.go:66: commands will detect it and remind you to do so if necessary.
PASS
ok      github.com/gruntwork-io/terratest/modules/terraform     6.066s

Tests failed, but for an unrelated transient issue, so we can merge this in!


Create Streams wrapper...

...and move List.zipWithIndex etc. to the Streams wrapper.

The wrapper implements the delegate/decorator pattern. The original stream is augmented with additional/missing functionality.
Perhaps move it to javaslang.collection.
All collection.stream()/.parallelStream() methods should return this wrapper.

Out of focus. Replaced with javaslang.collection.Stream


Quantity update

Updated Quantity schema to use ndarray, along with additional unit tests and other relatively minor changes. This addresses issue #263.

Coverage increased (+0.03%) to 94.162% when pulling bc704fb07856fff4425c7c5380ab65ee4eea4462 on drdavella:quantity-update into 7c91d1333dc6b9bb43a7c7d089f47d005e837f30 on spacetelescope:master.


Delete message a certain BOT?

Your application is great!
It works like a charm.
I have a special case
I use some different BOT in a channel. How can I delete messages of certain BOT?
Again, thank you very much

Currently there is no argument to specify this. But if you try to delete all messages on a channel with certain BOT's API key, it'll just delete messages of that BOT (since the API key does not have any privilege on others messages. Of course any PR for this feature will be appreciated! :)
Thank you!

This doesn't work for App BOTs (such as the jenkins integration) as they don't have permissions to delete any messages.
https://api.slack.com/bot-users

Supporting deleting messages from a bot that match a certain pattern in the body of the message would be powerful too. Basically a conditional delete. I guess we could always query first and delete iteratively too.
This is some great python tooling though digging into slack to clean things up. Great work.

Supporting deleting messages from a bot that match a certain pattern in the body of the message would be powerful too. Basically a conditional delete. I guess we could always query first and delete iteratively too.
This is some great python tooling though digging into slack to clean things up. Great work.


Umbrel seed

Implements #978 for 0.3.x

Let's do not merge into 0.3.5 but once approved create 0.3.6 and take the commit. That way we preserve version 0.3.5 as a branch

@rishflab I noticed that release 0.3.6 is alrady out. Should we point this against master now to get it into the current version as well or is there a different plan?

@rishflab I noticed that release 0.3.6 is alrady out. Should we point this against master now to get it into the current version as well or is there a different plan?

yep, ill rebase  and merge it onto master today. I was not sure how to deal with this PR with this new backporting workflow.

It seems you are pointing all backported commits against master now. You'll have to remove the ones that are not relevant for your changes :)

As part of this, can we also rip out the reinit feature for the wallet please? It is not needed anymore!

As part of this, can we also rip out the reinit feature for the wallet please? It is not needed anymore!

I am not sure we should remove it. I think it is still a nice feature to have and we will probably want it in the medium to longterm.
I think we should have a quick discussion on how we deal with the backup problem longterm.

bors r+

I am not sure we should remove it. I think it is still a nice feature to have and we will probably want it in the medium to longterm.

I would like to have it removed because it is dead code at the moment and annoying to maintain!
If we want such a feature again in the future, we can add it on top of whatever the code is then!

Is this rebased on latest master? If so we should record the test failure.

bors r+

bors r+


Map Style settings can't be applied

Hi! Just found out about this project's web counterpart through weeklyOSM and I love to know this exist.
I've tried to play around with the Map Styles settings expecting the same behavior as the app but sadly it does not work. I tried several map styles and different rendering settings but none of the changes to the latter seem to be applied to the map.
Thanks and good work! :+1:

The app and the web seem to be organised differently:
The app has the profile that has all sorts of things attached to it including map source and style, render settings, routing profile, etc. You can add your own profiles on to the standard set too.
The web has map styles and the render settings are associated with them (which don't work at present).
I would like both to have the same data hierarchy so that they are consistent and you can share profiles across the OsmAnd cloud.
I'm happy to work on some of the above - is someone coordinating work on this project?

Web is developed for development purposes we won't be able to support custom rendering styles with all option cause basically we won't have any cache. So at max we will be able to support 5-10 concurrent users on web, so this approach won't scale unless we do vector tile rendering on device


PowerToys Run Do not run as expected

Microsoft PowerToys version
0.51.1
Running as admin

[X] Yes

Area(s) with issue?
PowerToys Run
Steps to reproduce
I use the default shortcut and customs ones
✔ Expected Behavior
To see the Search Bar
❌ Actual Behavior
I do not see anything, I changed everything and still not seeing anything. Somethimes it works, somethimes it doesn't
Other Software
No response

/bugreport

also we did fix a bunch of bugs in PT Run with the new 0.53 release.  That may have a fix for your issue

@crutkas
This is a bug I saw multiple times the last day. Can we track it centralized?

Mmmm.. Not sure what's the issue here. Need a bug report.
The test build was for the program plugin crash.

@htcfreek, we need data. otherwise we are chasing ghosts and not able to repro.

Sorry for the delay, I already opened another Issue, but with the updated version of PT. Anyways , here is the BugReport Zip File.
PowerToysReport_2022-01-12-06-13-34.zip

@davidegiacometti going to dup this against his new issue.
/dup https://github.com/microsoft/PowerToys/issues/15341


Fix up tracers so they can be enabled/disabled completely.

Tracers can add unnecessary code that was running pre-main. The comments in the source file
implied that you could disable them, but that was not possible. Now by defining GRPC_USE_TRACERS
to 0, you can disable tracers.
They are enabled by default in opensource builds.

****************************************************************

libgrpc.so

     VM SIZE                                                                                FILE SIZE
 ++++++++++++++ GROWING                                                                              ++++++++++++++
  +0.3% +2.41Ki [None]                                                                               +25.2Ki  +0.3%
      +0.3% +2.03Ki [Unmapped]                                                                           +25.2Ki  +0.3%
      +3.8%     +39 [None]                                                                                0  [ = ]
     +23e2%     +23 grpc_combiner_trace                                                                        0  [ = ]
     +23e2%     +23 grpc_polling_api_trace                                                                     0  [ = ]
     +23e2%     +23 grpc_trace_auth_context_refcount                                                           0  [ = ]
     +23e2%     +23 grpc_trace_chttp2_refcount                                                                 0  [ = ]
     +23e2%     +23 grpc_trace_closure                                                                         0  [ = ]
     +23e2%     +23 grpc_trace_cq_refcount                                                                     0  [ = ]
     +23e2%     +23 grpc_trace_error_refcount                                                                  0  [ = ]
     +23e2%     +23 grpc_trace_fd_refcount                                                                     0  [ = ]
     +23e2%     +23 grpc_trace_lb_policy_refcount                                                              0  [ = ]
     +23e2%     +23 grpc_trace_metadata                                                                        0  [ = ]
     +23e2%     +23 grpc_trace_pending_tags                                                                    0  [ = ]
     +23e2%     +23 grpc_trace_pollable_refcount                                                               0  [ = ]
     +23e2%     +23 grpc_trace_resolver_refcount                                                               0  [ = ]
     +23e2%     +23 grpc_trace_security_connector_refcount                                                     0  [ = ]
     +23e2%     +23 grpc_trace_stream_refcount                                                                 0  [ = ]
   +43%    +786 src/core/lib/iomgr/combiner.cc                                                          +786   +43%
       +53%    +358 grpc_combiner_continue_exec_ctx                                                         +358   +53%
       +46%    +103 combiner_finally_exec                                                                   +103   +46%
      +143%     +70 grpc_combiner_unref                                                                      +70  +143%
       +27%     +64 combiner_exec                                                                            +64   +27%
       +79%     +59 really_destroy                                                                           +59   +79%
      [NEW]     +48 _GLOBAL__sub_I_combiner.cc                                                               +48  [NEW]
       +36%     +47 grpc_combiner_create                                                                     +47   +36%
       +28%     +30 queue_offload                                                                            +30   +28%
      +4.5%      +5 [Unmapped]                                                                                +5  +4.5%
      [NEW]      +2 grpc_core::DebugOnlyTraceFlag::~DebugOnlyTraceFlag                                        +2  [NEW]
  +1.5%    +103 src/core/lib/iomgr/error.cc                                                             +103  +1.5%
      [NEW]    +103 _GLOBAL__sub_I_error.cc                                                                 +103  [NEW]
  +1.5%     +96 src/core/ext/filters/client_channel/subchannel.cc                                        +96  +1.5%
       +28%     +85 on_connected_subchannel_connectivity_changed                                             +85   +28%
      +4.1%     +11 [Unmapped]                                                                               +11  +4.1%
  +5.1%     +91 src/core/lib/iomgr/ev_posix.cc                                                           +91  +5.1%
       +88%     +91 _GLOBAL__sub_I_ev_posix.cc                                                               +91   +88%
  +1.1%     +87 src/core/lib/surface/completion_queue.cc                                                 +87  +1.1%
       +84%     +87 _GLOBAL__sub_I_completion_queue.cc                                                       +87   +84%
  +3.5%     +48 src/core/ext/filters/client_channel/lb_policy.cc                                         +48  +3.5%
      [NEW]     +48 _GLOBAL__sub_I_lb_policy.cc                                                              +48  [NEW]
   +13%     +48 src/core/ext/filters/client_channel/resolver.cc                                          +48   +13%
      [NEW]     +48 _GLOBAL__sub_I_resolver.cc                                                               +48  [NEW]
  +0.4%     +48 src/core/lib/iomgr/ev_epollex_linux.cc                                                   +48  +0.4%
      [NEW]    +137 pollset_kick_all(grpc_pollset*) [clone .isra.5]                                         +137  [NEW]
      [NEW]     +48 _GLOBAL__sub_I_ev_epollex_linux.cc                                                       +48  [NEW]
  +1.5%     +48 src/core/lib/security/context/security_context.cc                                        +48  +1.5%
      [NEW]     +48 _GLOBAL__sub_I_security_context.cc                                                       +48  [NEW]
  +0.5%     +48 src/core/lib/security/security_connector/security_connector.cc                           +48  +0.5%
      [NEW]    +537 fake_check_peer(grpc_security_connector*, tsi_peer, grpc_auth_context**, grpc_closur    +537  [NEW]
      [NEW]    +404 ssl_check_peer(grpc_security_connector*, char const*, tsi_peer const*, grpc_auth_con    +404  [NEW]
      [NEW]     +48 _GLOBAL__sub_I_security_connector.cc                                                     +48  [NEW]
  +1.4%     +48 src/core/lib/transport/metadata.cc                                                       +48  +1.4%
      [NEW]     +48 _GLOBAL__sub_I_metadata.cc                                                               +48  [NEW]
  +2.3%     +48 src/core/lib/transport/transport.cc                                                      +48  +2.3%
      [NEW]     +48 _GLOBAL__sub_I_transport.cc                                                              +48  [NEW]
  +0.1%     +46 src/core/ext/transport/chttp2/transport/chttp2_transport.cc                              +46  +0.1%
       +96%     +46 _GLOBAL__sub_I_chttp2_transport.cc                                                       +46   +96%

  +0.3% +3.91Ki TOTAL                                                                                +26.7Ki  +0.3%

****************************************************************

libgrpc++.so

     VM SIZE              FILE SIZE
 ++++++++++++++ GROWIN ++++++++++++++

 -------------- SHRINK --------------
  [ = ]       0 [None]    -160  -0.0%

  [ = ]       0 TOTAL     -160  -0.0%

[trickle] No significant performance differences

Objective-C binary sizes
*****************STATIC******************
  New size                      Old size
 1,976,682      Total (>)      1,976,654

 No significant differences in binary sizes

***************FRAMEWORKS****************
  New size                      Old size
10,775,732      Total (>)     10,775,730

 No significant differences in binary sizes

[microbenchmarks] No significant performance differences


ERROR: --nouse_workers_with_dexbuilder :: Unrecognized option: --nouse_workers_with_dexbuilder with Bazel@HEAD

https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/3341#_
Platform : MacOs, Windows, Ubuntu
Logs:
ERROR: --nouse_workers_with_dexbuilder :: Unrecognized option: --nouse_workers_with_dexbuilder

Culprit : https://github.com/bazelbuild/bazel/commit/f2c11f7f2225e0a881585bf866ce5117f3c51735
CC Greenteam @Wyverald

Fixed at 5b7d428


Add mapping entities

1. Why is this change necessary?

PHPStan is annoyed, that you have to pass an entity collection but you have none, because searching is not a thing
Searching should be a thing to get multiple many to many associations at once
Did you have a look at the docs? It is super annoying to read and write. Just let us to read and write like other entities
You already do that for mail_template_media which should be super weird because mapping definitions with more than two FKs as \Shopware\Core\Framework\DataAbstractionLayer\Write\WriteCommandExtractor::extract will decide to go for a REPLACE INTO approach and therefore writing this entity is already a weird case. Just make it a normal entity like product_media and product_visibility

I am happy to rewrite docs but maybe this needs to mature in a discussion.
2. What does this change do, exactly?
It adds a unique identifier calculation so one can use collections. This should be enough to work with as the collection can now hold all of them as expected
3. Describe each step to reproduce the issue or behaviour.

Add StoreAPI to link two entities
Add EntityRepository of the mapping to create or delete
Have phpstan set up

Read the docs how to write associations
See code, that I need to have the product repository to add an association to a tag
See code, that I need the mapping repository to delete the association to a tag
See code, that I need the product repository, to query for associations to a tag

5. Checklist

[x] I have rebased my changes to remove merge conflicts
[ ] I have written tests and verified that they fail without my change
[x] I have created a changelog file with all necessary information about my changes
[ ] I have written or adjusted the documentation according to my changes
[ ] This change has comments for package types, values, functions, and non-obvious lines of code
[x] I have read the contribution requirements and fulfill them.

Hey @JoshuaBehrens
first of all thx for the contribution! 🎉
we quickly discussed this and actually agree with you that the current handling for the mapping "entities" is a bit weird and could be simplified.
But we definitely should add some integration testcases for mapping entities then to the EntityRepositoryTestCase
I'm also wondering if this is really everything there is to it, I quickly checked for instanceof checks for MappingEntities and guess that some (or even most of them) can and should get removed as well to really treat mapping entities as closely as possible to real entities (if you read them over the repo directly)
Because the thing we definitely wanna keep is that when you read them over e.g. the product repo directly you get product.tags directly and there the "mapping" info we need on the DB layer will be "flattened" -> to double check the changes you want to do only should have an affect when you use the "mappingRepository" directly right?

@keulinho indeed. I do not try to reinvent mappings. ManyToMany associations should still be able to directly fetch the data, you can still just do REPLACE INTO to create entries. It should IMHO be forbidden to have more than two associations therefore. Maybe one wants to approach this. Then the mail_template_media thingy would not exist. I just want phpstan to be less annoying and the documentation not contain a code snippet with the hint in the prosa saying "the following should not work". This does not feel polished at that point.
Any test cases I should especially look into? Something that is important to you regarding that, that might not yet be covered by a test?

@JoshuaBehrens i would check reading & hydrating as well as writing  mapping entities work as expected


Toolbar refactor and styling

Would fix #125 and fix #49

Turn toolbar buttons into JupyterLab commands
Move commands logic in its own file
Improve the UI and UX of the toolbar (no dropdown, new icons, less clicks)

Remaining TODO:

[ ] Rebase and fix conflicts 😄
[ ] Refactor user toolbar
[ ] Spacers in the toolbar

I probably need to update the integration tests and screenshots, but the rest is ready to review.

please update snapshots

Thanks @martinRenou


"Error: Could not determine field type PARAM NAME in DTO" when field type is number

Heya, when defining a field with type number as followed:
export class RemoveDto {
  @Param({
    name: 'position',
    description: 'Position of song to remove from Queue',
    required: true,
  })
  position: number;
}

I receive this error:
Error: Could not determine field type position in class RemoveDto
    at OptionResolver.getApplicationOptionTypeByArg (/home/NAME/workspace/APP/node_modules/@discord-nestjs/core/src/resolvers/option/option.resolver.ts:117:15)
    at /home/NAME/workspace/APP/node_modules/@discord-nestjs/core/src/resolvers/option/option.resolver.ts:34:16
    at Array.map (<anonymous>)
    at OptionResolver.resolve (/home/NAME/workspace/APP/node_modules/@discord-nestjs/core/src/resolvers/option/option.resolver.ts:25:30)
    at BuildApplicationCommandService.resolveCommandOptions (/home/NAME/workspace/APP/node_modules/@discord-nestjs/core/src/services/build-application-command.service.ts:59:50)
    at CommandResolver.resolve (/home/NAME/workspace/APP/node_modules/@discord-nestjs/core/src/resolvers/command/command.resolver.ts:43:7)
    at /home/NAME/workspace/APP/node_modules/@discord-nestjs/core/src/services/discord-resolver.service.ts:71:9
    at async Promise.all (index 2)
    at DiscordResolverService.resolveDecorators (/home/NAME/workspace/APP/node_modules/@discord-nestjs/core/src/services/discord-resolver.service.ts:68:30)
    at DiscordResolverService.onModuleInit (/home/NAME/workspace/APP/node_modules/@discord-nestjs/core/src/services/discord-resolver.service.ts:55:5)

If i change it to string it works just fine.
I assume this is a bug but let me know if I'm doing something wrong.
Cheers!

Sorry, there is an mistake in the documentation. Only string and boolean are resolved automatically. In all other cases, you need to specify the type.


config: exclude [vendor] site_templates

w/o this, I get:
             ERROR: YOUR SITE COULD NOT BE BUILT:
                    ------------------------------------
                    Invalid date '<%= Time.now.strftime('%Y-%m-%d %H:%M:%S %z') %>': Document 'vendor/bundle/ruby/2.1.0/gems/jekyll-3.3.1/lib/site_template/_posts/0000-00-00-welcome-to-jekyll.markdown.erb' does not have a valid date in the YAML front matter.

on a new install.
see: https://github.com/jekyll/jekyll/issues/2938

Yup, been hit by this in other sites.


Tuple notation in the where clause

Is that possible to create a query like below with the qb? It seems like there is no filtering comparator  for the tuple notation.
SELECT * FROM posts
 WHERE userid = 'john doe'
   AND (blog_title, posted_at) > ('John''s Blog', '2012-01-01')

Never mind. It's can be done with qb.Func without function name
var titlePostedTuple = qb.Func{ParamNames: []string{"blog_title", "posted_at"}}
qb.GtFunc("(blog_title, posted_at)", &titlePostedTuple)


Proper exception handling

Currently we just throw errors if we get an unexpected result. These should use the new SessionException type instead

Closed in bd6901688e6c9d8332fea161260d32666885f9ed


Kepler not handling multiple cgroupIDs of a process.

What happened?
A user space process can be associated with multiple cgroups.
e.g. a VM started with qemu, can have different cgroup for each vcpu
sub processes of VM process
vimal vimal $ ps -T -p 12152
    PID    SPID TTY          TIME CMD
  12152   12152 ?        16:21:42 qemu-system-x86
  12152   12164 ?        00:00:00 qemu-system-x86
  12152   12167 ?        00:00:01 IO mon_iothread
  12152   12168 ?        03:48:57 CPU 0/KVM
  12152   12169 ?        04:00:23 CPU 1/KVM
  12152   12170 ?        04:31:59 CPU 2/KVM
  12152   12171 ?        03:54:04 CPU 3/KVM
  12152   12173 ?        00:00:00 vnc_worker
  12152 1488968 ?        00:00:00 worker
  12152 1489155 ?        00:00:00 worker
  12152 1489156 ?        00:00:00 worker
  12152 1489157 ?        00:00:00 worker
  12152 1489158 ?        00:00:00 worker
  12152 1489159 ?        00:00:00 worker
  12152 1489160 ?        00:00:00 worker
  12152 1489161 ?        00:00:00 worker
  12152 1489162 ?        00:00:00 worker
  12152 1489163 ?        00:00:00 worker
  12152 1489164 ?        00:00:00 worker
  12152 1489165 ?        00:00:00 worker
  12152 1489166 ?        00:00:00 worker
  12152 1489167 ?        00:00:00 worker
  12152 1489168 ?        00:00:00 worker
  12152 1489169 ?        00:00:00 worker
  12152 1489170 ?        00:00:00 worker
  12152 1489171 ?        00:00:00 worker

associated cgroups
vimal vimal $ for task in /proc/12152/task/* ; do echo "task: $task"; cat $task/cgroup || true; done
task: /proc/12152/task/12152
0::/machine.slice/machine-qemu\x2d2\x2dbeaker\x2dvm.scope/libvirt/emulator
task: /proc/12152/task/12164
0::/machine.slice/machine-qemu\x2d2\x2dbeaker\x2dvm.scope/libvirt/emulator
task: /proc/12152/task/12167
0::/machine.slice/machine-qemu\x2d2\x2dbeaker\x2dvm.scope/libvirt/emulator
task: /proc/12152/task/12168
0::/machine.slice/machine-qemu\x2d2\x2dbeaker\x2dvm.scope/libvirt/vcpu0
task: /proc/12152/task/12169
0::/machine.slice/machine-qemu\x2d2\x2dbeaker\x2dvm.scope/libvirt/vcpu1
task: /proc/12152/task/12170
0::/machine.slice/machine-qemu\x2d2\x2dbeaker\x2dvm.scope/libvirt/vcpu2
task: /proc/12152/task/12171
0::/machine.slice/machine-qemu\x2d2\x2dbeaker\x2dvm.scope/libvirt/vcpu3
task: /proc/12152/task/12173
0::/machine.slice/machine-qemu\x2d2\x2dbeaker\x2dvm.scope/libvirt/emulator
task: /proc/12152/task/1488968
0::/machine.slice/machine-qemu\x2d2\x2dbeaker\x2dvm.scope/libvirt/emulator

What did you expect to happen?
low priority bug
kepler only captures cgroup of the sub-process which creates entry in the ProcessStats. It may not be a problem, because most cases CgroupID is being compared to 1, to know if the process belongs to kernel.
If the function func NewProcessStats(pid, cGroupID uint64, containerID, vmID, command string, bpfSupportedMetrics bpf.SupportedMetrics) creates entry for a process as in user space, the pid, cGroupID, command etc should be of the parent pid (tgid), or should we replace the field cGroupID with isKernelProcess?
How can we reproduce it (as minimally and precisely as possible)?
run kepler with VM, or any process which can have multiple cgroups
Anything else we need to know?
No response
Kepler image tag

Kubernetes version

$ kubectl version
# paste output here

Cloud provider or bare metal

OS version

# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here

Install tools

Kepler deployment config

For on kubernetes:
$ KEPLER_NAMESPACE=kepler

# provide kepler configmap
$ kubectl get configmap kepler-cfm -n ${KEPLER_NAMESPACE}
# paste output here

# provide kepler deployment description
$ kubectl describe deployment kepler-exporter -n ${KEPLER_NAMESPACE}

For standalone:
put your Kepler command argument here

Container runtime (CRI) and version (if applicable)

Related plugins (CNI, CSI, ...) and versions (if applicable)

Cc: @rootfs


Patch 7

Preparing for release 0.5.4

:tada: This PR is included in version 1.0.0-beta.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Clear 'no style' option from Firefox before loading a pdf

Go to a page that links to a pdf. In Firefox chose view > style > no style then follow the pdf link. The pdf is displayed with no style. Which makes pdf.js impossible to use.

Open a page with with a pdf http://surlybikes.com/bikes/cross_check
View > style > no style
Click "Cross-Check Complete Instructions"
the 'no style' breaks pdf.js

The breakage looks like http://people.mozilla.org/~kbrosnan/tmp/pdf.js-issue-1175.png

That's because pdf.js uses CSS for styling. I wouldn't call this a bug, nor really an issue - It's almost impossible to use the web without CSS these days.


node: verify genesis doc hash against the file contents rather than remarshalled JSON

Closes #1287

PR checklist

[x] Tests written/updated
[ ] Changelog entry added in .changelog (we use unclog to manage our changelog)
[x] Updated relevant documentation (docs/ or spec/) and code comments

I don't think this needs a changelog entry, as this is a follow-up to #1017 and we haven't released the functional changes yet.

@mzabaluev PR #1295 is likely to affect this PR. Sorry for the inconveniences...

@mzabaluev PR #1295 is likely to affect this PR. Sorry for the inconveniences...

No worries, I will wait (and review) and rebase once that one is merged.

Merging the PR now so you are free to rebase! Thanks Mikhail !


Failure when /etc/cdi dirs not present on the system but /var/run/cdi is

The default spec dirs are set set as follows:
cdi_spec_dirs = {
    /etc/cdi,
    /var/run/cdi,
}

If we are on a system that only has a /var/run/cdi directory (and not an /etc/cdi directory), then we fail to parse any of the cdi device files present in the /var/run/cdi directory.
Doing a simple mkdir /etc/cdi allows us to move past the error and find all of the devices in the /var/run/cdi directory.

I thought this was addressed? Which crio version was this?

cc @klihub

Git log shows it addressed in #79. Maybe there is still an issue.

The commit: https://github.com/container-orchestrated-devices/container-device-interface/pull/79/commits/e7cbe91de89de7db8ca3f8534b712d9f40323416 shows that this is in the following tags:

v0.5.4
v0.5.3
v0.5.2
v0.5.1

Ah, OK. We’ve already addressed it. Maybe it’s just still an issue in the the crio version used by minikube. cri-o version 1.24.1
This is the environmental observed it in.

v1.24.1 of cri-o is using v0.3.2 of the CDI package which does not include the fix.

I take it back -- it is using:
$ crio --version
crio version 1.24.4

but this is also on v0.3.2 of the CDI package:
https://github.com/cri-o/cri-o/blob/v1.24.4/go.mod#L9
which would explain the issue....


[General Inquiry]: Should errors be limited by 'sessionEventLimit'?

What is your general inquiry?
I wasn't expecting the behaviour of errors not being recorded when a sessionEventLimit is not, got a bit caught out by it. Is there a reason for blanket preventing all events based on the limit, including errors?
Would be handy if this was configurable. Being able to still collect errors beyond when you may care about other events in the session.

The design was to limit cost to customers, but I agree that it's inconvenient.
Here is what I propose. Do you have any feedback?
const config: AwsRumConfig = {
    ...
    sessionEventLimitOverride: [
       // list of RUM event types
       ['js-error', 0] // where zero removes the limit
       ['other-event', 5] // count against override limit before counting against overall sessionEventLimit
    ]
}

Yeah ok, that makes sense.
Just thinking about it, it would be a huge win for us to be able to limit all of the individual event types, just as you have there. So that looks pretty much perfect to me.

Perfect, I'll see what I can do.
Out of curiosity, which other events were you thinking about using this configuration for?

I would probably do something like this once this configuration is available.
const config: AwsRumConfig = {
    ...
    sessionEventLimitOverride: [
       ['js-error', 0],
       ['fetch', 0], // Assuming this is correct to capture all HTTP
       ['pageview', 20], // Allow viewing some of the user journey
       // Maybe other limits for performance events
    ]
}

There are several requirements for this to be closed out

[ ] Cleanup session sampling tech debt #504
[ ] Add sessionLimitOverride support to always record certain types
[ ] Move session event counts from cookies to local storage
[ ] Add sessionLimitOverride support to set limits on specific types


Initial documentation for tomography

Summary
Details and comments

@mtreinish any thoughts on the Travis CI error? I'm seeing this in another unrelated PR.
ERROR: InvocationError for command '/home/travis/build/Qiskit/qiskit/.tox/lint/bin/pylint -rn --rcfile=/home/travis/build/Qiskit/qiskit/.pylintrc test' (exited with code 4)
___________________________________ summary ____________________________________
ERROR:   lint: commands failed
The command "tox" exited with 1.

@derivation that error is being caused because a new pylint was released today and it (as is typical with every pylint release) changed and/or added new rules which broke us. I'm going to push a patch that adds a pin for the pylint version to the ci jobs. In the meantime I actually have a fix up for this embedded in my larger change here #30

Thank you in advance for making a focused PR to add a pin for the pylint version to the ci jobs.

@gadial do you think users would benefit from any references to published research these tools were based on?

Reference can be helpful (actually, the best reference I can think of is Chris' thesis...) but I'm not sure this document is the correct place; we also have a notebook explaining the theory in more details, and maybe a list of references is more suitable there.


Cannot update hyprpm

Hyprland Version
 System/Version info
Hyprland, built from branch  at commit cba1ade848feac44b2eda677503900639581c3f4  (props: bump version to 0.40.0).
Date: Sat May 4 15:42:32 2024
Tag: v0.40.0, commits: 4606

flags: (if any)

System Information:
System name: Linux
Node name: Laptop
Release: 6.9.1-arch1-2
Version: #1 SMP PREEMPT_DYNAMIC Wed, 22 May 2024 13:47:07 +0000

GPU information:
07:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Rembrandt [Radeon 680M] [1002:1681] (rev c8) (prog-if 00 [VGA controller])

os-release: NAME=ArcoLinux
ID=arcolinux
ID_LIKE=arch
BUILD_ID=rolling
ANSI_COLOR="0;36"
HOME_URL="https://arcolinux.info/"
SUPPORT_URL="https://arcolinuxforum.com/"
BUG_REPORT_URL="https://github.com/arcolinux"
LOGO=arcolinux-hello

plugins:

Bug or Regression?
Bug
Description
whenever i try to update hyprpm, it fails stating that subprojects/wlroots-hyprland/build/include isn't found.
How to reproduce
run
LC_TIME="en_US.UTF-8" hyprpm update -v

(i use a diferent time format than the US one)
Crash reports, logs, images, videos
[v] version returned: Hyprland, built from branch  at commit cba1ade848feac44b2eda677503900639581c3f4  (props: bump version to 0.40.0).
Date: Sat May 4 15:42:32 2024
Tag: v0.40.0, commits: 4606

flags: (if any)

[v] parsed commit cba1ade848feac44b2eda677503900639581c3f4 at branch  on Sat May 4 15:42:32 2024, commits 4606

 ╍━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━  0 / 5  Cloning the hyprland re! Cloning https://github.com/hyprwm/hyprland, this might take a moment.
 ╍━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━  0 / 5  Cloning the hyprland re[v] will shallow since: Sat Apr 27 15:42:32 2024

 ╍━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━  0 / 5  Cloning the hyprland re✔ cloned
 ╍━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━  0 / 5  Cloning the hyprland re ━━━━━━━━━━━━━━━━━━━━╍━━━━━━━━━━━━━━━━━━━━━━━━━━━━━  2 / 5  Checking out sourc[v] git returned (co): Your branch is up to date with 'origin/main'.

 ━━━━━━━━━━━━━━━━━━━━╍━━━━━━━━━━━━━━━━━━━━━━━━━━━━━  2 / 5  Checking out sourc[v] git returned (rs): rm 'subprojects/tracy'
HEAD is now at cba1ade props: bump version to 0.40.0

 ━━━━━━━━━━━━━━━━━━━━╍━━━━━━━━━━━━━━━━━━━━━━━━━━━━━  2 / 5  Checking out sourc✔ checked out to running ver
 ━━━━━━━━━━━━━━━━━━━━╍━━━━━━━━━━━━━━━━━━━━━━━━━━━━━  2 / 5  Checking out sourc! configuring Hyprland
[v] setting PREFIX for cmake to /home/vynns/.local/share/hyprpm/headersRoot
[v] cmake returned: Not searching for unused variables given on the command line.
-- The C compiler identification is GNU 14.1.1
-- The CXX compiler identification is GNU 14.1.1
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Gathering git info
-- Found Python3: /usr/bin/python3.12 (found version "3.12.3") found components: Interpreter
Building itab.c/itab.h...
-- Setting up wlroots
-- Found PkgConfig: /usr/bin/pkg-config (found version "2.1.1")
-- Found WaylandScanner at /usr/bin/wayland-scanner
-- Found wayland-protocols at //usr/share/wayland-protocols
-- Configuring Hyprland in Release with CMake
-- Checking deps...
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- Found OpenGL: /usr/lib/libOpenGL.so  found components: GLES3
-- Checking for modules 'xkbcommon;uuid;wayland-server;wayland-client;wayland-cursor;wayland-protocols;cairo;pango;pangocairo;pixman-1;libdrm;libinput;hwdata;libseat;libdisplay-info;libliftoff;libudev;gbm;hyprwayland-scanner>=0.3.4;hyprlang>=0.3.2;hyprcursor>=0.1.7'
--   Package 'hyprwayland-scanner', required by 'virtual:world', not found
CMake Error at /usr/share/cmake/Modules/FindPkgConfig.cmake:634 (message):
  The following required packages were not found:

   - hyprwayland-scanner>=0.3.4

Call Stack (most recent call first):
  /usr/share/cmake/Modules/FindPkgConfig.cmake:862 (_pkg_check_modules_internal)
  CMakeLists.txt:107 (pkg_check_modules)

-- Configuring incomplete, errors occurred!

[v] meson returned: Traceback (most recent call last):
  File "/usr/bin/meson", line 5, in <module>
    from mesonbuild.mesonmain import main
ModuleNotFoundError: No module named 'mesonbuild'

✔ configured Hyprland
[v] installation will run: sed -i -e "s#PREFIX = /usr/local#PREFIX = /home/vynns/.local/share/hyprpm/headersRoot#" /tmp/hyprpm/hyprland-vynns/Makefile && cd /tmp/hyprpm/hyprland-vynns && make installheaders
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╍━━━━━━━━━  4 / 5  Installing sources[v] installer returned: rm -fr /home/vynns/.local/share/hyprpm/headersRoot/include/hyprland
mkdir -p /home/vynns/.local/share/hyprpm/headersRoot/include/hyprland
mkdir -p /home/vynns/.local/share/hyprpm/headersRoot/include/hyprland/protocols
mkdir -p /home/vynns/.local/share/hyprpm/headersRoot/include/hyprland/wlroots-hyprland
mkdir -p /home/vynns/.local/share/hyprpm/headersRoot/share/pkgconfig
find src -name '*.h*' -print0 | cpio --quiet -0dump /home/vynns/.local/share/hyprpm/headersRoot/include/hyprland
cd subprojects/wlroots-hyprland/include && find . -name '*.h*' -print0 | cpio --quiet -0dump /home/vynns/.local/share/hyprpm/headersRoot/include/hyprland/wlroots-hyprland && cd ../../..
cd subprojects/wlroots-hyprland/build/include && find . -name '*.h*' -print0 | cpio --quiet -0dump /home/vynns/.local/share/hyprpm/headersRoot/include/hyprland/wlroots-hyprland && cd ../../../..
/bin/sh: line 1: cd: subprojects/wlroots-hyprland/build/include: No such file or directory
make: *** [Makefile:100: installheaders] Error 1

✖ failed to install headers with error code 2
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━  5 / 5  Failed

✖ Headers missing. Please run hyprpm update to fix those.

Duplicate of #6232

--   Package 'hyprwayland-scanner', required by 'virtual:world', not found
CMake Error at /usr/share/cmake/Modules/FindPkgConfig.cmake:634 (message):
  The following required packages were not found:

   - hyprwayland-scanner>=0.3.4

--   Package 'hyprwayland-scanner', required by 'virtual:world', not found
CMake Error at /usr/share/cmake/Modules/FindPkgConfig.cmake:634 (message):
  The following required packages were not found:

   - hyprwayland-scanner>=0.3.4

thanks! it fixed my issue! i simply just had to read for once xD


[SliderIOS] Suggestion: add support for double-handled sliders?

Maybe there could be a way for SliderIOS to become a range slider if necessary

:+1:

Hi there! This issue is being closed because it has been inactive for a while.
But don't worry, it will live on with ProductPains! Check out it's new home: https://productpains.com/post/react-native/sliderios-suggestion-add-support-for-double-handled-sliders


adOnLookupTagClick is not available in the latest version of On Premise CRM D365

The documents need to make clear which version numbers for Online and On Premise each item was introduced. This one for example does not yet exist for On premise and it would be nice to make that clarer (even better would e to keep On Premise up to date with features!)

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

ID: 0db6fb00-418e-9599-3895-ec2e9f80536c
Version Independent ID: 5efd1e98-7335-6938-1a20-4b59a62e9d0f
Content: addOnLookupTagClick (Client API reference) in model-driven apps - Power Apps
Content Source: powerapps-docs/developer/model-driven-apps/clientapi/reference/controls/addOnLookupTagClick.md
Service: powerapps
GitHub Login: @Nkrb
Microsoft Alias: nabuthuk

Thanks for contacting us. We are in the process of updating docs that differentiate what methods are supported on on-premises and online version. Will be pushed live sometime end of April or first week of May. Closing the issue.  If you need further help, please reopen the issue or open a new issue.


Support for PreTeXt documents

I am the developer of the pretext-tools extension, which provides tools for working with PreTeXt documents.  These are XML with a particular schema, so your sxml extension is of great interest.  Instead of forking your project and integrating parts directly into pretext-tools, I wonder if it would make more sense to contribute to vscode-sxml directly to provide the flexibility I would need to require it by pretext-tools (I hope I have that language right).
Here are the features that I would love to see implemented (and would be happy to work on myself):

Support for the ptx language (which is really xml, but pretext-tools defines a new "language" recognized on the  file extension .ptx).  So some way to start validation for such files.
The ability to specify the schema used universally, rather than included at the top of each file.  Perhaps on a project level, but of course, respecting the current behavior for xml files that have the schema referenced in the file.
Support for xi:include (your #28 )
Use of snippet-like behavior for completions.  No idea how easy/hard this is, but it would be great if the completion suggestions were for more complex snippets that were provided by pretext-tools (in the case of ptx files; otherwise snippets specified for xml by the user).

Would love to hear your thoughts on these ideas.

There are a few XML/XSLT "scholarly" users related to the PreTeXt/Runestone projects that Zoom weekly on Tuesdays and Fridays. This looks like a cool project @raffazizzi and you'd be very welcome to join us to talk shop and maybe discuss this issue further. https://prose.runestone.academy/#upcoming-events has info - Oscar and I join those regularly, or we can find another time to chat if you're interested.

Hello @oscarlevin and @StevenClontz thanks for reaching out! I would be happy to talk more, I could drop in for the Friday meeting if that helps (I can join at the start around 3pm Eastern but would need to leave by 4pm ET).
Some quick reponses:

Support for the ptx language (which is really xml, but pretext-tools defines a new "language" recognized on the  file extension .ptx).  So some way to start validation for such files.

Do you expect that this would be mostly about loading a default schema for certain file types? If yes, that would be fine, though I may want to start doing this with other extensions too such as .odd (for TEI file documentation), .mei (for MEI files) etc.

The ability to specify the schema used universally, rather than included at the top of each file.  Perhaps on a project level, but of course, respecting the current behavior for xml files that have the schema referenced in the file.

Sounds good. We should looks at XML Catalogs for this.

Support for xi:include (your Support for xinclude #28 )

It's much needed in a lot of my projects and work with students, so yes :)

Use of snippet-like behavior for completions.  No idea how easy/hard this is, but it would be great if the completion suggestions were for more complex snippets that were provided by pretext-tools (in the case of ptx files; otherwise snippets specified for xml by the user).

OK. It would be good for TEI as well. It shouldn't be too hard to provide them as commands from the Command Palette

I'll be at the Zoom drop-in at 3 Eastern this week, but Oscar has his head around this better than I do. When will you be around @oscarlevin?

I'll be there as well.  This is exciting.


Use @each multiple assignment for mq-show-breakpoints

Just a micro optimisation ;-)
See: http://sass-lang.com/documentation/file.SASS_REFERENCE.html#each-multi-assign

Thanks @slavanga! There is a reason this extra step is in there: it's providing useful feedback if the breakpoint wasn't found.
(also, the Travis build did not complete, so there must be a compilation error somewhere)

Ah right. I missed that. Thank you for clarifying.


Can it handle 62 placements?

Hi,
I have a board that has 62 placements… can it handle this?
Mike

Hello Mike,
I don't see a reason why not. So I think that should be possible ;)
PixiePlacer


Feature: Add support for pinning shortcuts to favorites

What feature or improvement do you think would benefit Files?
When a shortcut to a folder location is pinned to the sidebar favorites section. It shows as missing location when clicked it shows access denied.

Step to reproduce

Create a shortcut to a folder
Right click the created shortcut
Select pin to favorites
Open the pinned item
See Access denied

Requirements

Pinning a shortcut should pin the target destination to the sidebar

Files Version
<IP_ADDRESS>
Windows Version
10.19043.1899
Logs
debug.log
debug_fulltrust.log

Do you mean that the folder itself should get pinned? In that case, the context menu of the shortcut should have an option named "Pin the destination folder to favorites".
Pinning a shortcut itself would be useless, or does someone know what a possible usecase of that would be?

Merging with #3223

Should pinning a shortcut just pin the referred folder or not?

Yes, but this issue might actually be resolved with #10800

@Rick-HM this is supported in v2.4.33.


owl-lisp: 0.1.15 -> 0.1.16

Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/owl-lisp/versions.
These checks were done:

built on NixOS
/nix/store/w56xh2wbvj0f9f7cs7px7jrwkw6lcb9q-owl-lisp-0.1.16/bin/ol passed the binary check.
Warning: no invocation of /nix/store/w56xh2wbvj0f9f7cs7px7jrwkw6lcb9q-owl-lisp-0.1.16/bin/ovm had a zero exit code or showed the expected version
1 of 2 passed binary check by having a zero exit code.
1 of 2 passed binary check by having the new version present in output.
found 0.1.16 with grep in /nix/store/w56xh2wbvj0f9f7cs7px7jrwkw6lcb9q-owl-lisp-0.1.16
directory tree listing: https://gist.github.com/b4c2aa74b73f2272f18b1a116c55897a
du listing: https://gist.github.com/c130a766b1c674ed98f2f4e109186fe3

meta.description for owl-lisp is: '"A functional lisp"'.
cc @peterhoeg for testing.
Experimental: this build is cached with Cachix. To use the cache follow these experimental instructions:
One time setup in nixpkgs Git checkout:
cachix use r-ryantm
git remote add r-ryantm https://github.com/r-ryantm/nixpkgs.git

Test this build:
git fetch r-ryantm && git checkout b7edc2b30e13cc30ccea951dec2e4c72e7dc2988 && nix-shell --pure -I nixpkgs=. -p owl-lisp

Failure on x86_64-darwin (full log)
Attempted: owl-lisp
Partial log (click to expand)
c/vm.c:584:41: error: use of undeclared identifier 'CLOCK_THREAD_CPUTIME_ID'
CLOCK_PROCESS_CPUTIME_ID,CLOCK_REALTIME,CLOCK_THREAD_CPUTIME_ID
                                        ^
c/vm.c:586:40: error: invalid application of 'sizeof' to an incomplete type 'const word []'
return onum(sysconst[immval(a)%(sizeof sysconst/W)],0);}
                                       ^~~~~~~~
1 warning and 5 errors generated.
make: *** [Makefile:35: bin/vm] Error 1
builder for '/nix/store/2bi8ljvgn7fdflvkcf4qahf4wl0dsi3z-owl-lisp-0.1.16.drv' failed with exit code 2
error: build of '/nix/store/2bi8ljvgn7fdflvkcf4qahf4wl0dsi3z-owl-lisp-0.1.16.drv' failed

Success on x86_64-linux (full log)
Attempted: owl-lisp
Partial log (click to expand)
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/w56xh2wbvj0f9f7cs7px7jrwkw6lcb9q-owl-lisp-0.1.16
shrinking /nix/store/w56xh2wbvj0f9f7cs7px7jrwkw6lcb9q-owl-lisp-0.1.16/bin/ovm
shrinking /nix/store/w56xh2wbvj0f9f7cs7px7jrwkw6lcb9q-owl-lisp-0.1.16/bin/ol
gzipping man pages under /nix/store/w56xh2wbvj0f9f7cs7px7jrwkw6lcb9q-owl-lisp-0.1.16/share/man/
strip is /nix/store/21ymadblbmsbb2bk4q7gl4kjasp8zmgd-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/w56xh2wbvj0f9f7cs7px7jrwkw6lcb9q-owl-lisp-0.1.16/bin
patching script interpreter paths in /nix/store/w56xh2wbvj0f9f7cs7px7jrwkw6lcb9q-owl-lisp-0.1.16
checking for references to /build in /nix/store/w56xh2wbvj0f9f7cs7px7jrwkw6lcb9q-owl-lisp-0.1.16...
/nix/store/w56xh2wbvj0f9f7cs7px7jrwkw6lcb9q-owl-lisp-0.1.16

Success on aarch64-linux (full log)
Attempted: owl-lisp
Partial log (click to expand)
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/5ypw6zg15a0jgyr35125wcpi2f68dwcx-owl-lisp-0.1.16
shrinking /nix/store/5ypw6zg15a0jgyr35125wcpi2f68dwcx-owl-lisp-0.1.16/bin/ovm
shrinking /nix/store/5ypw6zg15a0jgyr35125wcpi2f68dwcx-owl-lisp-0.1.16/bin/ol
gzipping man pages under /nix/store/5ypw6zg15a0jgyr35125wcpi2f68dwcx-owl-lisp-0.1.16/share/man/
strip is /nix/store/qg2agrqkf240s656d207zqhipl0bc2id-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/5ypw6zg15a0jgyr35125wcpi2f68dwcx-owl-lisp-0.1.16/bin
patching script interpreter paths in /nix/store/5ypw6zg15a0jgyr35125wcpi2f68dwcx-owl-lisp-0.1.16
checking for references to /build in /nix/store/5ypw6zg15a0jgyr35125wcpi2f68dwcx-owl-lisp-0.1.16...
/nix/store/5ypw6zg15a0jgyr35125wcpi2f68dwcx-owl-lisp-0.1.16


fix: Update for IDEA 2021.2ff

Add GitHub action as replacement for Travis
Update properties and junit dependency only.

Fix for #146

For what it's worth: you may download the build plugin from https://github.com/mfriedenhagen/GitLink/actions

Thanks, this has been merged into the 4.0.0 release.


NEP 31: unumpy into numpy

@hameerabbasi would you mind looking into the issue on your numpy fork that means PRs can't be submitted against it?

@peterbell10 I did, I can't find anything in permissions disallowing pull requests.

@peterbell10 I added you to the collaborators, you can push to my fork directly now.

this isn't the first time I've seen such a problem, but I've never seen a good explanation. @hameerabbasi perhaps open a support issue with GitHub?

@hameerabbasi now that I'm a collaborator, I can open pull requests. I suppose it must be a permissions issue then.

@peterbell10 I believe it is, but I can't seem to find any permissions related to it in the project settings.

NEP 31 won't be accepted in its current form, however is still the best way to add support for backends (e.g. fft, linalg).


Update to use new Analyzer and AnalysisContext APIs to-be-released

This is a placeholder for upcoming work to address stuff going away and changing in these APIs:

no more getByKind etc (replaced with generic getFeature query interface).
analyze returns a Document today, but not when this new Analyzer released.

Probably a few more things to address.

Fixed in #478


Adding a new project: Fetal Health Classification

I would like to add a new project under the HealthCheck - Fetal Health Classification. I came across the dataset on Kaggle and it looked really interesting.
https://www.kaggle.com/andrewmvd/fetal-health-classification
I am a GSSOC'21 participant

Hey, @nandinib1999 I found the idea really interesting, I'm assigning this issue to you. Do remember to make a pr when the contribution period for GSSOC'21 starts. Happy Coding :)

Hi, thanks a lot!
I am participating in GSSOC'21 for the first time, so what to confirm - are there any deadlines for the PR submission after the contribution period starts?

You'll be provided with 7 days to work on an issue, If you'll not submit a pr for the same in that period, the next one who comments to work on that issue will be assigned. So don't worry you'll have one week to work on one issue :)

Okay, thanks a lot for clearing up that!


Add font

Added font family support for indicator and tick mark texts

It will support in next version, thank you for your contribution!


Fixed even more Sentry errors

You can find the full list of fixed errors here.

Codecov Report

Merging #1726 into canary will decrease coverage by 0.33%.
The diff coverage is 33.33%.

@@            Coverage Diff             @@
##           canary    #1726      +/-   ##
==========================================
- Coverage   71.21%   70.88%   -0.34%
==========================================
  Files          12       12
  Lines         337      340       +3
==========================================
+ Hits          240      241       +1
- Misses         97       99       +2

Impacted Files
Coverage Δ

src/util/read-metadata.js
80.26% <33.33%> (-1.93%)
:arrow_down:

Continue to review full report at Codecov.

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

@javivelasco Agreed! 👍
Gonna do further investigation on this later. Once the commits land on stable, we can see exactly who caused the error and see if their cert documents are faulty.


UITableView in centerview can't be edited

I have an UITableView in centerview. While the tableview is set editing, I can't drag cells up and down.

I hava a problem in left ViewController ,then I did select the row enter my centerView ,the centerVC is tabbarVC ,then push nextVc from CenterVC,and leftNavItem of  the nextVC  is not system back Item ,i look have the    effect of   DDMenuController


/version should be at root of API

The basepath of the specification is set to /v2, but ideally /version would be better than /v2/version.

Hi @taliaga , I am working on this issue and just wanted to confirm my approach that I have removed basePath from quantumleap.yml file and added /v2 as prefix in other api e.g. for /config I have done /v2/config.
Please confirm my approach so that i can raise PR.

hi @daminichopra i would synch with PR #255
check the discussion there, and let's either combine the PR, or build your PR on top of PR #255.

hi @ddaminichopra PR #255 was merged
I would then proceed as follow:

move /v2/version,  /v2/config,  /v2/health to root in the swagger specs
remove those paths from the api [endpoint] (https://github.com/smartsdk/ngsi-timeseries-api/blob/master/src/reporter/api.py)
change the test for api /v2 so that these paths are not included in the return messages. see here

thx


Sort markets on tournament pages by %, using ContractSearchFirestore

This is super hacky and trades off a much longer initial load time, for a better browsing experience... Not sure if this is the right longterm solution but I think it's better for the CEP contest?

Just realized in ContractSearchFirestore, const contracts = useContracts() actually loads the ENTIRE set of Manifold contracts before doing an in-memory filter over them... quite suboptimal

Why do you need to use ContractSearchFirestore? It seems to me this is just the homepage with a hardcoded group slug and a hardcoded sort so what's the problem with using Algolia?

Why do you need to use ContractSearchFirestore? It seems to me this is just the homepage with a hardcoded group slug and a hardcoded sort so what's the problem with using Algolia?

Algolia didn't know about contract probabilities, so can't sort by them afaict. ContractSearchFirestore has the nice property of allowing us to calculate arbitrary sorts based on any computable/derivable property from the contract itself.

Why do you need to use ContractSearchFirestore? It seems to me this is just the homepage with a hardcoded group slug and a hardcoded sort so what's the problem with using Algolia?

Algolia didn't know about contract probabilities, so can't sort by them afaict. ContractSearchFirestore has the nice property of allowing us to calculate arbitrary sorts based on any computable/derivable property from the contract itself.

It's in the database now (James added it last week) so presumably it should be easy to index.

Here's a market for this: https://manifold.markets/MarketManagerBot/how-many-days-after-september-1st-w-bff738132665

Not needed now that this is supported in Algolia!


Latest Version Not Available on PyPi

Hi, I'm so sorry, but when I ran 'pip install nitrado==1.0.14', I could not get the latest version from PyPi, and only got up to 0.0.11. :) Is it still in the process of being tested?

My mistake, I accidentally used Python3.8 instead of Python3.11 to install it. I apologize!


Math::Divide isn't very precise

1/2=0? Need to use floats or something more precise.

Being fixed with #51 and #52


Slim\App::setBasePath method missing

Slim App v4 doesn't have setBasePath method.
Also
$app->getRouteCollector()->setBasePath($basePath);

doesn't work, but this is Slim issue

Not true. The App class extends extends RouteCollectorProxy.
The RouteCollectorProxy class has a method: setBasePath.

doesn't work, but this is Slim issue

I think it's not a Slim (4) issue, its just a setup issue.

Sorry, you are right.
But still RouteCollectorProxy::getBasePath method is never called after base path is set in my case


Incorrect PlusCal translation maybe due to upstream

I faced a bug in "Translate PlusCal".
Transpiling PlusCal succeeded, but TLC checking failed.
There're a same issue in upstream: https://github.com/tlaplus/tlaplus/issues/370, https://github.com/tlaplus/tlaplus/pull/634.
Source code (PlusCal):
------------------------- MODULE test -------------------------
EXTENDS Integers, Sequences

(*--algorithm test
variables
    x = "",
procedure foo() begin
    Foo:
        x := self;
        return;
end procedure;
process baz = "One"
begin Baz:
    call foo()
end process
end algorithm;*)
=============================================================================

Translated result:
seems something wrong.

Error when TLC checking:
***Parse Error***
Encountered "\/" at line 59, column 38 and token "\\/"

This patch outputs (maybe) correct result although this might be not a fundamental solution..
https://github.com/okue/tlaplus-intellij-plugin/commit/55cbee1b5a09fdcbea080861e86d9246d7b2add0

[FYI]
pcal.trans CLI returns a correct result.
java -cp ~/.../tla2tools-1.8.0.jar pcal.trans src/test/resources/pluscal/translate/test.tla

------------------------- MODULE test -------------------------
EXTENDS Integers, Sequences

(*--algorithm test
...
end algorithm;*)
\* BEGIN TRANSLATION (chksum(pcal) = "83c39aa4" /\ chksum(tla) = "a4310d13")
VARIABLES x, pc, stack

vars == << x, pc, stack >>

ProcSet == {"One"}

Init == (* Global variables *)
        /\ x = ""
        /\ stack = [self \in ProcSet |-> << >>]
        /\ pc = [self \in ProcSet |-> "Baz"]

Foo(self) == /\ pc[self] = "Foo"
             /\ x' = self
             /\ pc' = [pc EXCEPT ![self] = Head(stack[self]).pc]
             /\ stack' = [stack EXCEPT ![self] = Tail(stack[self])]

foo(self) == Foo(self)

Baz == /\ pc["One"] = "Baz"
       /\ stack' = [stack EXCEPT !["One"] = << [ procedure |->  "foo",
                                                 pc        |->  "Done" ] >>
                                             \o stack["One"]]
       /\ pc' = [pc EXCEPT !["One"] = "Foo"]
       /\ x' = x

baz == Baz

(* Allow infinite stuttering to prevent deadlock on termination. *)
Terminating == /\ \A self \in ProcSet: pc[self] = "Done"
               /\ UNCHANGED vars

Next == baz
           \/ (\E self \in ProcSet: foo(self)) // <---- HERE
           \/ Terminating

Spec == Init /\ [][Next]_vars

Termination == <>(\A self \in ProcSet: pc[self] = "Done")

\* END TRANSLATION
=============================================================================

NOTE: PlusCal translation still generates incorrect result for long procedure name as reported in upstream.


General idiom usage

Hi there! I took a quick look through this codebase and have a few friendly pointers to help get the most out of using Rust :) I think at the moment, much of the code I've seen feels as though it's been translated from another language such as C and although they can occupy much the same space, idiomatic Rust and C are quite different.
Please note that these things I spotted come from a sample of the files, so some impressions may be spurious. I also grouped these into one issue to avoid spam, so apologies for the length. Anyway, in no particular order, here's what I found:

There seem to be quite a few places there's _ = fallible_func() is used, unexpectedly preventing error propagation. Whilst this may be okay in tests, it's definitely a code smell in general
The proxy_agent cli argument parser is hand-rolled. Unless case insensitivity is required, I think it would be easier to maintain and more idiomatic to derive a parser with clap
Some fallible functions return booleans instead of a Result. This isn't idiomatic and has the added downside that the user can quietly ignore the error condition! By using a Result instead, the compiler will enforce that the error is considered, thus leading to more robust code. (e.g. here, I'd expect an error detailing what went wrong)
I see very many free functions and although these are sometimes okay, most instances I've seen would be more idiomatically expressed as methods. E.g.fn attach_kprobe_program(bpf: &mut Bpf, ...)

Would feel more idiomatic asimpl Bpf {
    fn attach_kprobe_program(&mut self, ...)
}

It may be necessary to have a wrapper type for Bpf in this case as it is defined in the aya crate, but the newtype pattern, i.e. struct Bpf(aya::Bpf);, could help here
Sometimes values where the type system (correctly) expresses invalid values get converted to valid-looking ones with invalid values. Specifically here, where if proxy_agent_exe is not valid utf8, path_to_string returns 'InvalidPath,' which the OS then attempts to execute.execute_command(&path_to_string(proxy_agent_exe), vec!["--version"], -1)

Assuming this fails, later on, the string 'Unknown' is returned to indicate an error, which isn't very helpful. Checking whether the proxy_agent_exe is valid utf8 before executing would improve this greatly and give enough information for a more appropriate error message. Another approach could be to use camino::Utf8PathBuf rather than std::path::PathBuf to represent proxy_agent_exe, which would express the opinion that incoming paths must be valid utf8. This may be quite a strong opinion though, so I'm not sure (I lack context)
The shared state seems to always be cloned before use as many functions involving it unnecessarily take ownership (e.g. this one). As ownership doesn't need to be moved, a reference would be more idiomatic here.
Whenever SharedState is used, it seems to be behind an Arc<Mutex<_>>, which:

Should probably be hidden by a new type as this leaks implementation details of how it's locked
probably shouldn't lock the entire struct, as SharedState contains a very large number of fields so one thread will exclude all other threads from reading the shared state, which seems like it would cause unnecessary stalls. Instead, it may be better to lock individual fields or group fields together

I see std::io::Result being used as a custom result type (a common rookie error seen for example here), but really crates should define their own error and result types, leading to a nice 'branded' feeling API (e.g. in crate foo, foo::bar() might return a foo::Result which can hold a foo::Error). This is surprisingly straightforward to remedy, the usual way this is done is by using thiserror deriving a custom error type and making a new Result alias as follows (I like to put these next to one another in lib.rs#[derive(Debug, thiserror::Error)]
pub enum Error {
    #[error("cannot foo")]
    Foo,
}

pub type Result<T> = std::result::Result<T, Error>

Doing this also has the added benefit of encouraging better error handling and
There are a couple of places where the use of new enums would be more robust, e.g. ModuleState has associated string constants, which doesn't prevent other arbitrary states from being used where a module state is expected, leading to the rather awkward and very fragile need to use a comment!pub status: String,  // ModuleState, RUNNING|STOPPED

Thanks for your feedback list, I will fix them gradually with priority.

https://github.com/Azure/GuestProxyAgent/pull/119

https://github.com/Azure/GuestProxyAgent/pull/151


refactor(backend): swap connection for methods

Changes proposed in this pull request

updates to latest open-payments openapi spec  (5.2.1)
refactors to remove connection and replace with methods. there is still a reduced concept of connections internally (no longer exposed over API) which basically amount to stream credentials.

Context

We still have a concept of connections internally because we still need to get the stream credentials for the ilp payment method. I elaborate a bit on this here and speculate about a further refactor which I welcome feedback on, but I think that is out of scope for this PR. https://github.com/interledger/rafiki/pull/2042#discussion_r1364007405
This branch is does not build yet, and not all tests pass, which is expected. This is due to other unimplemented changes. I fixed all build errors related to these change and the test failures I see locally appear related to pagination (possibly due to bug in our down migration in our dev branch at the moment?).

fixes https://github.com/interledger/rafiki/issues/1962

Checklist

[ ] Related issues linked using fixes #number
[ ] Tests added/updated
[ ] Documentation added
[ ] Make sure that all checks pass
[ ] Postman collection updated

the ilp payment method is hardcoded a number of places. I'm not against abstracting it a bit to handle multiple methods where it's clear and simple but I wanted to keep the scope to what is necessary to maintain functionality of ilp payment methods. In additional to maximizing the amount of time we have to update testnet, I think the right way to handle multiple methods will probably be more clear when we actually add the next method.

We still have a concept of connections internally because we still need to get the stream credentials for the ilp payment method.
Should we call it streamCredentials then? Or something else that is not as generic as connection? Since I'm assuming we'll have something similar for MJL?

Stream credentials is good

Almost makes me think we can just pass in the streamServer into incomingPaymentService and remove connectionService altogether, thoughts? @sabineschaller @BlairCurrey

@mkurapov @sabineschaller If there's any other feedback you'd like to give in this PR feel free to make comment on pertinent lines as usual, but in the interest of keeping things moving I'd also like for you to create an issue so we can address it in a subsequent PR on the nl-open-payments feature branch.


Not able to match the results of NHHaze dataset in paper

Please let me know how to reproduce the SSIM and PSNR value of NHHaze dataset given in paper. I am getting on .509 as SSIM value

Please let me know how to reproduce the SSIM and PSNR value of NHHaze dataset given in paper. I am getting on .509 as SSIM value

When I run the code，
RuntimeError: Error(s) in loading state_dict for DehazeFormer:
Missing key(s) in state_dict: "layer1.blocks.6.norm1.weight", "layer1.blocks.6.norm1.bias", "layer1.blocks.6.norm1.meta1.weight", "layer1.blocks.6.norm1.meta1.bias", "layer1.blocks.6.norm1.meta2.weight", "layer1.blocks.6.norm1.meta2.bias", "layer1.blocks.6.attn.QK.weight", "layer1.blocks.6.attn.QK.bias", "layer1.blocks.6.attn.attn.relative_positions", "layer1.blocks.6.attn.attn.meta.0.weight", "layer1.blocks.6.attn.attn.meta.0.bias", "layer1.blocks.6.attn.attn.meta.2.weight", "layer1.blocks.6.attn.attn.meta.2.bias", "layer1.blocks.7.norm1.weight", "layer1.blocks.7.norm1.bias", "layer1.blocks.7.norm1.meta1.weight", "layer1.blocks.7.norm1.meta1.bias", "layer1.blocks.7.norm1.meta2.weight", "layer1.blocks.7.norm1.meta2.bias", "layer1.blocks.7.attn.QK.weight", "layer1.blocks.7.attn.QK.bias", "layer1.blocks.7.attn.attn.relative_positions", "layer1.blocks.7.attn.attn.meta.0.weight", "layer1.blocks.7.attn.attn.meta.0.bias", "layer1.blocks.7.attn.attn.meta.2.weight", "layer1.blocks.7.attn.attn.meta.2.bias", "layer2.blocks.4.norm1.weight", "layer2.blocks.4.norm1.bias", "layer2.blocks.4.norm1.meta1.weight", "layer2.blocks.4.norm1.meta1.bias", "layer2.blocks.4.norm1.meta2.weight", "layer2.blocks.4.norm1.meta2.bias", "layer2.blocks.4.attn.QK.weight", "layer2.blocks.4.attn.QK.bias", "layer2.blocks.4.attn.attn.relative_positions", "layer2.blocks.4.attn.attn.meta.0.weight", "layer2.blocks.4.attn.attn.meta.0.bias", "layer2.blocks.4.attn.attn.meta.2.weight", "layer2.blocks.4.attn.attn.meta.2.bias", "layer2.blocks.5.norm1.weight", "layer2.blocks.5.norm1.bias", "layer2.blocks.5.norm1.meta1.weight", "layer2.blocks.5.norm1.meta1.bias", "layer2.blocks.5.norm1.meta2.weight", "layer2.blocks.5.norm1.meta2.bias", "layer2.blocks.5.attn.QK.weight", "layer2.blocks.5.attn.QK.bias", "layer2.blocks.5.attn.attn.relative_positions", "layer2.blocks.5.attn.attn.meta.0.weight", "layer2.blocks.5.attn.attn.meta.0.bias", "layer2.blocks.5.attn.attn.meta.2.weight", "layer2.blocks.5.attn.attn.meta.2.bias", "layer2.blocks.6.norm1.weight", "layer2.blocks.6.norm1.bias", "layer2.blocks.6.norm1.meta1.weight", "layer2.blocks.6.norm1.meta1.bias", "layer2.blocks.6.norm1.meta2.weight", "layer2.blocks.6.norm1.meta2.bias", "layer2.blocks.6.attn.QK.weight", "layer2.blocks.6.attn.QK.bias", "layer2.blocks.6.attn.attn.relative_positions", "layer2.blocks.6.attn.attn.meta.0.weight", "layer2.blocks.6.attn.attn.meta.0.bias", "layer2.blocks.6.attn.attn.meta.2.weight", "layer2.blocks.6.attn.attn.meta.2.bias", "layer2.blocks.7.norm1.weight", "layer2.blocks.7.norm1.bias", "layer2.blocks.7.norm1.meta1.weight", "layer2.blocks.7.norm1.meta1.bias", "layer2.blocks.7.norm1.meta2.weight", "layer2.blocks.7.norm1.meta2.bias", "layer2.blocks.7.attn.QK.weight", "layer2.blocks.7.attn.QK.bias", "layer2.blocks.7.attn.attn.relative_positions", "layer2.blocks.7.attn.attn.meta.0.weight", "layer2.blocks.7.attn.attn.meta.0.bias", "layer2.blocks.7.attn.attn.meta.2.weight", "layer2.blocks.7.attn.attn.meta.2.bias", "layer3.blocks.2.norm1.weight", "layer3.blocks.2.norm1.bias", "layer3.blocks.2.norm1.meta1.weight", "layer3.blocks.2.norm1.meta1.bias", "layer3.blocks.2.norm1.meta2.weight", "layer3.blocks.2.norm1.meta2.bias", "layer3.blocks.2.attn.QK.weight", "layer3.blocks.2.attn.QK.bias", "layer3.blocks.2.attn.attn.relative_positions", "layer3.blocks.2.attn.attn.meta.0.weight", "layer3.blocks.2.attn.attn.meta.0.bias", "layer3.blocks.2.attn.attn.meta.2.weight", "layer3.blocks.2.attn.attn.meta.2.bias", "layer3.blocks.3.norm1.weight", "layer3.blocks.3.norm1.bias", "layer3.blocks.3.norm1.meta1.weight", "layer3.blocks.3.norm1.meta1.bias", "layer3.blocks.3.norm1.meta2.weight", "layer3.blocks.3.norm1.meta2.bias", "layer3.blocks.3.attn.QK.weight", "layer3.blocks.3.attn.QK.bias", "layer3.blocks.3.attn.attn.relative_positions", "layer3.blocks.3.attn.attn.meta.0.weight", "layer3.blocks.3.attn.attn.meta.0.bias", "layer3.blocks.3.attn.attn.meta.2.weight", "layer3.blocks.3.attn.attn.meta.2.bias".


Update to newer versions of Accumulo and Tomcat

[ ] joeferner
[ ] mwizeman joeybrk372 jharwig sfeng88

CHANGELOG
Changed: Updated Accumulo to version 1.7.3 and Tomcat to version 8.5.23

I'm working out an issue with the Travis container that's causing the build to fail.


When are annotations stripped?

I feel like the answer must be obvious, but I've been poking around the docs, and can't find anything about it.
I've used the /* @flow* / annotation, as well as various type annotations in the file itself, and checked it with flow check. But clearly all the type annotations I'm adding to my code won't let it run.
e.g. with typescript, .ts files are compiled into .js files.

This is covered in Running Flow code. Babel is probably the most recommended way right now.

I guess comparing Flow to TypeScript isn't very accurate then -- they're not really in the same class of tooling.
Is handling a transform/compile step something that's on the horizon for Flow?

I just spent 15 minutes trying to see how to compile down too!  (doh)

Thanks @ianobermiller

@brycepj Is this issue resolved?