OCI output from filter

Hi all,
Terraform offer Data Sources Filtering to geting some specific date from OCI .tfstate file. For example I have following data function which receives information about subnets created in the environment:
data "oci_core_subnets" "test_subnets" {
    #Required
    compartment_id = "${var.compartment_ocid}"
    vcn_id = "${var.vcn_ocid}"
    filter {
        name = "cidr_block"
        values = ["${var.cidr_block}"]
    }
}

In my environment I have many subnets (suppose 20). And using " filter"  option I want to receive subnet_ocid of specific subnet (for example subnet_ocid of subnet <IP_ADDRESS>/25).
How in this case should look "output" script ?
I tried to use the following output functions:
Attempt 1:
output "subnet_Х_ocid" {
      value = "${data.oci_core_subnets.test_subnets.subnets.*.id}"
    }

Attempt 2:
output "subnet_Х_ocid" {
      value = "${data.oci_core_subnets.test_subnets.subnets.id}"
    }

But they all give an error and do not display the required subnet_ocid.
* module.subnets.output.subnet_Х_ocid: Resource 'data.oci_core_subnets.test_subnets' does not have attribute 'subnets.id' for variable 'data.oci_core_subnets.test_subnets.subnets.id'
The valid result is displayed only when I using following function:
Attempt 3:
output "subnet_Х_ocid" {
      value = "${data.oci_core_subnets.test_subnets.subnets.0.id}"
    }

In it I use the subnet sequence number "0", which was automatically assigned to the subnet during the call to the "data" function described above.
It is clearly visible if you look in the .tfstate file
"resources": {
                "data.oci_core_subnets.test_subnets": {
                    "type": "oci_core_subnets",
                    "depends_on": [],
                    "primary": {
                        "id": "2019-04-24 12:58:49.209260087 +0000 UTC",
                        "attributes": {
                            "compartment_id": "ocid1.compartment.oc1..aaaaaaaaz77ckem7hfsshpligt2nq624i6fva7xw5owlf5rbotqgdh3uooga",
                            "id": "2019-04-24 12:58:49.209260087 +0000 UTC",
                            "subnets.#": "2",
                            "subnets.0.availability_domain": "",
                            "subnets.0.cidr_block": "<IP_ADDRESS>/25",
                            "subnets.0.compartment_id": "ocid1.compartment.oc1..aaaaaaaaz77ckem7hfsshpligt2nq624i6fva7xw5owlf5rbotqgdh3uooga",
                            "subnets.0.defined_tags.%": "1",
                            "subnets.0.defined_tags.netcloud01.GP": "IaC_Test",
                            "subnets.0.dhcp_options_id": "ocid1.dhcpoptions.oc1.iad.aaaaaaaarnlgjlsfkislh3b2dbshs2e5hlkdzijdkb3mo6ngbs3vs472gh2q",
                            "subnets.0.display_name": "subnet-oracle-TEST-<IP_ADDRESS>/25",
                            "subnets.0.dns_label": "subnet1",
                            "subnets.0.freeform_tags.%": "0",
                            "subnets.0.id": "ocid1.subnet.oc1.iad.aaaaaaaahvqw5tdooqrjpioba3bzaxakuiba3jcch6pjgze7scvgreca7syq",
                            "subnets.0.prohibit_public_ip_on_vnic": "true",
                            "subnets.0.route_table_id": "ocid1.routetable.oc1.iad.aaaaaaaamhqu7skcusmw3dwrbeztfi4wh6rhlkizd4umxpjq5lo3idl76rna",
                            "subnets.0.security_list_ids.#": "1",
                            "subnets.0.security_list_ids.0": "ocid1.securitylist.oc1.iad.aaaaaaaazufeadqsyz6d6gtlhecc6hrctfcdtkthqbll7lrhsizkh3f4m4ra",
                            "subnets.0.state": "AVAILABLE",
                            "subnets.0.subnet_domain_name": "subnet1.vcn.oraclevcn.com",
                            "subnets.0.time_created": "2019-04-16 14:16:00.868 +0000 UTC",
                            "subnets.0.vcn_id": "ocid1.vcn.oc1.iad.aaaaaaaanwgk3efm5gtryvsfclvbo6zbzqtv2r35aq3mnzzbrt7fskgez5fq",
                            "subnets.0.virtual_router_ip": "<IP_ADDRESS>",
                            "subnets.0.virtual_router_mac": "00:00:17:68:82:DD",
                            "subnets.1.availability_domain": "",
                            "subnets.1.cidr_block": "<IP_ADDRESS>/26",
                            "subnets.1.compartment_id": "ocid1.compartment.oc1..aaaaaaaaz77ckem7hfsshpligt2nq624i6fva7xw5owlf5rbotqgdh3uooga",
                            "subnets.1.defined_tags.%": "1",
                            "subnets.1.defined_tags.netcloud01.GP": "IaC_Test",
                            "subnets.1.dhcp_options_id": "ocid1.dhcpoptions.oc1.iad.aaaaaaaarnlgjlsfkislh3b2dbshs2e5hlkdzijdkb3mo6ngbs3vs472gh2q",
                            "subnets.1.display_name": "subnet-oracle-TEST-<IP_ADDRESS>/26",
                            "subnets.1.dns_label": "subnet2",
                            "subnets.1.freeform_tags.%": "0",
                            "subnets.1.id": "ocid1.subnet.oc1.iad.aaaaaaaaxgrxefifmij3aavk5azis4twd7rtlroti65qmfigljzst6uxcira",
                            "subnets.1.prohibit_public_ip_on_vnic": "true",
                            "subnets.1.route_table_id": "ocid1.routetable.oc1.iad.aaaaaaaamhqu7skcusmw3dwrbeztfi4wh6rhlkizd4umxpjq5lo3idl76rna",
                            "subnets.1.security_list_ids.#": "1",
                            "subnets.1.security_list_ids.0": "ocid1.securitylist.oc1.iad.aaaaaaaazufeadqsyz6d6gtlhecc6hrctfcdtkthqbll7lrhsizkh3f4m4ra",
                            "subnets.1.state": "AVAILABLE",
                            "subnets.1.subnet_domain_name": "subnet2.vcn.oraclevcn.com",
                            "subnets.1.time_created": "2019-04-16 14:16:00.514 +0000 UTC",
                            "subnets.1.vcn_id": "ocid1.vcn.oc1.iad.aaaaaaaanwgk3efm5gtryvsfclvbo6zbzqtv2r35aq3mnzzbrt7fskgez5fq",
                            "subnets.1.virtual_router_ip": "<IP_ADDRESS>",
                            "subnets.1.virtual_router_mac": "00:00:17:68:82:DD",
                            "vcn_id": "ocid1.vcn.oc1.iad.aaaaaaaanwgk3efm5gtryvsfclvbo6zbzqtv2r35aq3mnzzbrt7fskgez5fq"
                        },
                        "meta": {},
                        "tainted": false
                    },
                    "deposed": [],
                    "provider": "provider.oci"
                },

But in this case (Attempt 3), it makes no sense to use Data Sources Filtering
, because Data Sources Filtering is designed to display the necessary data by key.
Please, specify how to properly refer to "data"  by key using Data Sources Filtering to get the subnet_ocid of a specific subnet specified in the key of Data Sources Filtering?

I managed to find a solution. This construction is working, it may be useful to someone.
data "oci_core_subnets" "test_subnets" {
    #Required
    compartment_id = "${data.terraform_remote_state.vcn.compartment_ocid}"
    vcn_id = "${data.terraform_remote_state.vcn.vcn_ocid}"

    #Optional
	filter {
        name = "cidr_block"
        values = ["${var.cidr_block}"]
    }
}

subnet_id = "${lookup(data.oci_core_subnets.test_subnets.subnets[0], "id")}"

variable "cidr_block" { default = "<IP_ADDRESS>/27" }


New features: Sensitivity analysis

This PR adds new features related to local sensitivity analysis of bioscrape models:

Compute the Jacobian matrix at any point in the system trajectory (i.e. at a given state value).
Compute the sensitivity of the model to any parameter at any given point in trajectory.
Building on the two above, compute the sensitivity coefficient matrix that gives the sensitivity of the model with respect to each parameter at all time points for all states.

New tests are added as well as a jupyter notebook demonstrating a simple use case.
The PR will fix #10

This looks good! I'd still love to know if we can pass it the jacobian into ODE int....

I looked into that a bit and it definitely seems possible from the code point of view but

We would need a proper example to demonstrate how Jacobian helps with odeint
Maybe need some Cythonizing before we implement this because in that case odeint will evaluate the Jacobian function at every time point.

We can merge this and release the new version now..this is all I have from my end.

merged!


Error in Menu's docs

From @jabas06 on April 20, 2016 17:5
There is an error in the Menu's documentation of Ionic2. The docs say that there are two display modes but three are mentioned.

Copied from original issue: driftyco/ionic#6247

@jabas06 Ahh good catch! Since this is an issue with the docs site and not the framework i will be moving this issue over there. Thanks!

This was fixed in source, just need to deploy the site again to get it updated 👍


Update packages/backend/src/accounting/service.ts commit and rollback functions to make use of an enum instead of a boolean for the commit/rollback operations

https://github.com/interledger/rafiki/blob/dc909a6e73aec9064fd144b0a79fa74aceb07c88/packages/backend/src/accounting/transfers.ts#L32-L48

I think it'd be ok to keep things as is


Nanopub get published but are not available in the SPARQL endpoint

Some nanopubs are successfully published but cannot be queried through the SPARQL endpoint
Here are 2 nanopubs published but that can't be found in the SPARQL endpoint https://virtuoso.nps.petapico.org/sparql

http://purl.org/np/RAFi4vsVj-Xuh6tay2rt29ztwJ-7rDPDCLMIeDqJDMw-A
http://purl.org/np/RA36RQQ9gJnvC4-m2jEOop5g3X9bAp0jMXRfD_QM3EeLE

Tried with this query:
SELECT * WHERE {
 GRAPH ?g {
  <http://purl.org/np/RAFi4vsVj-Xuh6tay2rt29ztwJ-7rDPDCLMIeDqJDMw-A> ?p ?o .
 }
} LIMIT 10

It is due to the use of the integer data type for dct:created in the pubinfo, it should be xsd:dateTime
dct:created "2022-06-24T09:36:41+00:00"^^xsd:integer

cf. related issue https://github.com/peta-pico/nanopub-services/issues/2
Ideally nanopub-java should fail and show an error message when someone tries to publish a nanopub that does not meet all the requirements to be available through the SPARQL endpoint, otherwise we might end up with a hidden network of semi-valid nanopubs

Related to: https://github.com/tkuhn/nanopub-server/issues/14


Add uniqueConstraintExists precondition

Overview
There are indexExists and foreignKeyExists preconditions, but no uniqueConstraintExists.
Some databases use the same name for backing indexes for unique constraints so indexExists happens to work, but we need something more robust.

@nvoxland In the PR I can see failed stability checks for Liquibase PRO. Is any action required from me in this regard?

Looks like it got added but we didnt close this issue (https://docs.liquibase.com/concepts/changelogs/preconditions.html)


Use Erubis instead of ERB for outcome templates

The ERB trim mode chosen in this commit was intended to replicate how
Rails handles whitespace trimming. However, in fact Rails uses Erubis
in its default trim mode.
This commit uses Erubis in its default trim mode instead of ERB to render
outcome templates.
This change means there is no longer any need to use -%> tags on lines which
(other than the ERB tag) only contain whitespace. This is because the
suppression of leading & trailing whitespace and the trailing newline is the
default behaviour in Erubis.
I had to add an explicit newline to one of the outcome templates in order to
generate the appropriate paragraph HTML tag to match the regression test
outcome HTML.
This change will make it easier to switch to Rails templating in the future
which is part of our plan.

LGTM


BUG: Github Action Failing on Turborepo v 1.12.0

🐛 Bug Description / How to Reproduce
Currenty running the action like this:
    - name: App changed in last commit?
      id: changedAction
      uses: Trampoline-CX/action-turbo-changed@v1
      with:
        workspace: ${{ inputs.app-name }}
        from: HEAD^1

Error from GH Actions: SyntaxError: Unexpected token A in JSON at position 1
Issue likely lies in the turborepo output that now contains the following text followed by the json
Attention:
Turborepo now collects completely anonymous telemetry regarding usage.
This information is used to shape the Turborepo roadmap and prioritize features.
You can learn more, including how to opt-out if you'd not like to participate in this anonymous program, by visiting the following URL:
https://turbo.build/repo/docs/telemetry

{... start of json}

Probably requires a change in main.ts

debug(Output from Turborepo: ${json})
const parsedOutput = JSON.parse(json)
const changed = parsedOutput.packages.includes(workspace)

✅ Expected behavior
Gh action to run successfully

fixed by setting
env:
  TURBO_TELEMETRY_MESSAGE_DISABLED: 1

In the gh action env

This is now fixed on version 1.1 of the action 🚀 Thanks for the insights on the environment variable to use!

The fix has been backported to the v1 version, so your Github Action Workflows should now just work without having to upgrade this action nor having to manually set the environment variable.


the intersection operator modifies the first argument

The first argument of api.intersection is set to the intersection after it is called.

This has now been fixed by @qahtanaa


metacontrol ontologies reorganized

tomasys.owl and other ontology files now in folder owl/
mros-robmosys examples moved to this repo and names adjusted, use lowercase and underscores

Using this version requires adjustments  mc_mros_reasoner changes in branch ontologies_separate_repo

I've tested this branch with the latest version of the mc_mros_reasoner https://github.com/tud-cor/mc_mros_reasoner/commit/c3c24d5ee322a7be4cc12f1b3784b12ef403998f and works fine so LGTM!


Docs: Fluid dropdown

Closes https://github.com/carbon-design-system/carbon-website/issues/3174
Closes https://github.com/carbon-design-system/carbon-website/issues/3173
Closes https://github.com/carbon-design-system/carbon-website/issues/3172

Docs for fluid dropdown, combobox, multiselect
"Fluid input" branch updates from "main" (or have I missed something up? lol)

Changelog
Usage

Add a "Styling" section under Formatting to give an overview of Fixed and Fluid styles

This is different than how I did it in Text Input, where this section was under each variant, if we like this way better can change text input to match later.

Add tab component with Fluid image example to select images (not all have one)
Mover "disabled" and "invalid" sections previously under "Modifiers" to a "States" section under "Universal Behaviors"
Removed light prop section under modifiers.

Style

Add tab component and fluid images to color section
Add a Fluid dropdown structure section

I didn't add a new fluid section to Combobox or MultiSelect as the page would get very long. My thinking is that the structure for those can be inferred from their fixed version and the fluid default dropdown. Do you agree? Or should I go ahead and add those sections too?

Move "Size" section to the bottom
Added a fluid size section

Testing/Reviewing

Go to the "Dropdown" page and proof read add fluid sections and images on usage and style tabs.

@aagonzales I'm going to push up a PR that updates the fluid-input branch with the latest from main so this PR is cleaner

@tw15egan it's not showing any conflict anymore, can we just merge this one? Or should I still open a new clean one?

As long as everything looks good on your end, I'm good with merging it 👍🏻


Silent failure in the preprocessor

Current behavior
When there is an error in the preprocessor to interpret the .feature, the user is not notified in any way and "an old version of the project" is executed.
Desired behavior
missing error message and stop execution
Test code to reproduce
Given any project, feature:
Feature: duckduckgo.com
  Scenario: visiting the front page
    When I visit duckduckgo.com
    Then I should see a search bar

cypress run
runs successfully
I change the language to Spanish and the feature with some mistaken keyword (for example "Scenario" in English instead of Spanish)
# language: es
Característica: google.com
  Scenario: visiting the frontpage
    Cuando I visit google.com
    Entonces I should see a search bar

This results in a successful execution but the first feature is executed again and not the changes I made
It doesn't only happen because of the languages, it also happened to me for defining a rule wrong, any error that doesn't allow interpreting the feature
debug:
✘ [ERROR] (49:4): expected: #EOF, #TableRow, #TagLine, #ExamplesLine, #ScenarioLine, #RuleLine, #Comment, #Empty, got 'Scenario: visiting the frontpage' [plugin feature]
Versions
Cypress version: 12.17.1
Preprocessor version: 18.0.1
Node version: v18.16.0

Checklist

[x] I've read the FAQ.

[x] I've read instructions for logging issues.

[x] I'm not using<EMAIL_ADDRESS>(package name has changed and it is no longer the most recent version, see #689).

Hey, and thanks for reporting this issue. You need to provide a minimal, reproducible example issues that illustrates the issue.

Furthermore, it's not clear whether you're talking about open- or run-mode here.

Aha, I see what you mean. I can also observe the same behavior when using @bahmutov/cypress-esbuild-preprocessor without @badeball/cypress-cucumber-preprocessor (as seen below), which tells me that the problem lies therein.
// "Vanilla" Cypress (IE. without cypress-cucumber-preprocessor), with above-mentioned behavior.
const { defineConfig } = require("cypress");
const createBundler = require("@bahmutov/cypress-esbuild-preprocessor");

module.exports = defineConfig({
  e2e: {
    video: false,
    setupNodeEvents(on, config) {
      on("file:preprocessor", createBundler());
    },
  },
});

Closing as duplicate of https://github.com/badeball/cypress-cucumber-preprocessor/issues/786 and https://github.com/bahmutov/cypress-esbuild-preprocessor/issues/195.
Sadly, the issue mentioned hasn't gotten a lot of attention. I recommend users suffering from this, to try and contribute in the form of maybe a PR.


[test-only] apiTest. delete users with their personal spaces after each test

after #4195 we have easy way to clean users/personal space after each test

:boom: Acceptance test localApiTests-apiSpaces-ocis failed. Further test are cancelled...

I think this should get green after rebasing on latest master (to get #4532)

I deleted deleteAllPersonalSpaces. It is't necessary step because after deleting user-> personal spaces will be deleted automatically


Modal

📑 Description
Modal component re-written.

New API
Only one file: Modal.svelte
Docs rewritten to be in sync with Flowbite.com

✅ Checks

[x] My pull request adheres to the code style of this project
[x] My code requires changes to the documentation
[x] I have updated the documentation as required
[x] All the tests have passed
[x] My pull request is based on the latest commit (not the npm version).

ℹ Additional Information
Modal sizes are not consistent in the Flowbite.com
In the example section Sizes it defines:

small modal - max-w-md
default modal - max-w-lg
large modal - max-w-4xl
extra large modal - max-w-7xl

However in the very first example Default modal they use the value of max-w-2xl.
I have implemented my approach to sizing. Please verify.

Thank you for your work. Merged.

In a small screen, bottom-left etc, placement are not working.
Bottom-left

@jjagielka  It would be fine when a focus trap is implemented in modal

@maku @jjagielka updated the modal, https://github.com/themesberg/flowbite-svelte/pull/191, please check it and let us know.

@shinokada @jjagielka yeah I would say it works perferct. Thank you 👍

For components that uses human interaction, such as modal, alert, etc. can benefit using the dialog element for the future version.
It has the open attribute as well.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog#result
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog


Support for JUnit 5

Context
We're going to provide JUnit 5 support.
What's new test framework's name?
Currently, it's named as useJUnitPlatform() in contrast to exsited useJUnit()/useTestNG(), but that's not decided yet, see discussion here.
Goal
As a first step, we want to provide equivalent support as current test features for the following basic JUnit 5 features:

Allow user to specify useJUnitPlatform() and run pure JUnit 5 tests.
All our test features (e.g. includePattern/excludePattern) should work for JUnit 5 basic tests:

Standard Tests
Assertions
Assumptions
Disabling Tests

Existed Gradle test infrastructure
Previously, we have two TestFramework implementations: JUnitTestFramework and TestNGTestFramework. The most important responsibility of theirs is to provide TestClassProcessor for test worker JVM process, and TestClassProcessor is the main entry of Gradle test message dispatch layer. For example, JUnitTestClassProcessor is an concrete implementation which registers a JUnit RunListener to JUnit 3/4 engine, receives notification, converts and dispatches these notifications to Gradle test infrastructure.
------------------------------------------------------------
                 Test progress/report
------------------------------------------------------------
            Gradle test message dispatch/collection
-------------↑--------------  --------------↑--------------
  JUnitTestClassProcessor      TestNGTestClassProcessor
     JUnit 3/4 Engine                 TestNG Engine

First-step implementation
The simplest approach is to create an adapter layer and plug it into the current infrastructure. This PR slightly refactors JUnitTestEventAdapter and extends it as JUnitPlatformTestExecutionListener. JUnitPlatformTestExecutionListener.java implements JUnit5 TestExecutionListener and adapts the received message to Gradle test infrastructure. Likewise, JUnitPlatformTestClassProcessor extends JUnitTestClassProcessor to avoid lots of rework.
----------------------------------------------------------------------
                      Test progress/report
----------------------------------------------------------------------
                    Gradle test message dispatch/collection
---------------↑-------------------  --------------↑--------------
  JUnitTestClassProcessor               TestNGTestClassProcessor
  JUnit 3/4 Engine   ↑                  TestNG Engine
---------------------↑-----------
  JUnitPlatformTestClassProcessor
  JUnit 5 Engine

Java 8 subprojects
All JUnit 5 jar are Java 8 format. This PR creates a new subprojects and set its sourceCompatibility to 1.8. We have to instantiate JUnitPlatformTestClassProcessor via reflection: https://github.com/gradle/gradle/blob/33a00cae60e114ff53cb3e9cf1eeeb8356b996f4/subprojects/testing-jvm/src/main/java/org/gradle/api/internal/tasks/testing/junitplatform/JUnitPlatformTestFramework.java#L80 because its class format is also Java 8, which can't be used by other subprojects at compile time.
Test integration of Gradle&JUnit 5
To avoid rewriting hundreds of JUnit 5 test cases, this PR can convert existed JUnit 4 test cases to JUnit 5 test cases:

org.junit.Test -> org.junit.jupiter.api.Test
org.junit.Before -> org.junit.jupiter.api.BeforeEach
...

And then run tests with JUnitBasicMultiVersionIntegrationSpec.
All basic JUnit 4 tests (without Runner/Categories) in testing-jvm subprojects have been annotated and tested.

I really appreciate your review!
Previously what I planned is not including tagging feature in this PR. Soon I realized I'd better do. Tagging/filtering features only take a few extra files and I'll be freed from:

Find out which tests contains filtering, mark them as "Only work with JUnit 4" for now, then reopen them in next PR.
Write "Tagging is not supported now" in release notes and documentations then remove them in next PR.

So I take tagging/filtering feature in this PR.
There's a big change in recent commits, which is we send all test classes to JUnit Platform in one pass instead of process them one by one. This can leverage JUnit 5's scan functionality and improve performance.
As for the test, now I've changed almost all existing JUnit tests to multi-version tests:

Run tests with old version, e.g. JUnit 3/4.
Replace junit:junit with junit-vintage-engine, useCategories with useTags, then rerun them with useJUnitPlatform().
Replace junit:junit with junit-jupiter-engine, org.junit annotation with org.junit.jupiter.api, then rerun them with useJUnitPlatform.

The result is satisfying.

This is very awesome, @blindpirate!
Did I get you correctly, that you're executing "almost all existing JUnit tests" thrice?

pass 1: as designed with JUnit 3/4 API + runner
pass 2:  as designed with JUnit 3/4 API + JUnitPlatform
pass 3: "auto converted JUnit 3/4 API to Jupiter" + JUnitPlatform

How many tests are processed liked this?

just to throw some honest dimes in: Why'o'why should "we" (i.e. you adorable, enthusiastic, committed people) take any effort in making things "backward compatible" (i.e. things like https://github.com/gradle/gradle/pull/4116/files#diff-a5945fda2451f7bab0e91c578e8e7f2eR54 or https://github.com/gradle/gradle/pull/4116/files#diff-a5945fda2451f7bab0e91c578e8e7f2eR24 or https://github.com/gradle/gradle/pull/4116/files#diff-a5945fda2451f7bab0e91c578e8e7f2eR78 …) if "explicit changes in a build definition" (i.e. you have to set useJunitPlatform or whatever) are needed to enable Junit5 platform (i.e. it's not just a version bump but a decision made to switch).
I see "this would make some things easier to migrate" but I don't see this as a valid and valuable solution.
Because?
Please: Just encourage to split out old tests in a subproject or subconfiguration (that still might be compiled and tested with junit 4 or vintage-engine) but not letting (because it works) stuff mixed in with old and new test APIs!!
If you want to allow a "migration helper" to "rewrite old buildfiles" or event class files ... please give some tooling to do this explicit and at exactly once.
This won't either help to get clean code neither to get the junit5 stuff on board (i.e. regarding the developers who don't have any clue of the junit5 changes yet)
Even I don't see (without testing it) that case 3 (i.e. Replace junit:junit with junit-jupiter-engine, org.junit annotation with org.junit.jupiter.api, then rerun them with useJUnitPlatform) would work well with any IDE if only gradle will do "some magic"?!?!
Did I missed a point in this rant? if yes, please complaint now ;)

Did I missed a point in this rant? if yes, please complaint now ;)

No offense, but I think you're indeed missing the point.
JUnitPlatformTestRewriter is a class only used for testing the Gradle support for the JUnit Platform, as @blindpirate wrote in its Javadoc:

To avoid rework when testing JUnit Platform (a.k.a JUnit 5), we'd like to reuse previous test cases in following aspects [...]

This is only done to recycle existing JUnit 4 based test classes (that already exist in the Gradle codebase!) by converting them into JUnit Jupiter tests to verify that they can be executed using the test task on the JUnit platform. AFAIK there are no plans to apply this transformation to any user-provided code.

@sormuras Your understanding is correct. We have about 200 integration tests here and I've converted as many as possible old JUnit tests with JUnitMultiVersionIntegrationSpec.
If a test class is annotated with something like @TargetCoverage({ JUNIT_4_LATEST + JUNIT_VINTAGE_JUPITER }), it will be executed thrice as you understand. I can't give you an exact number of how many test cases here, but I estimate the number is (120~140)*3.

@childnode Thanks for pointing out this, but what @marcphilipp said is right.JUnitPlatformTestRewriter is never a solution for users, that's just used for test by ourselves. Previously we have 100~200 integration tests to test the integration of JUnit 4 and Gradle, we don't want to write 100 more tests for JUnit 5 so we "convert" this tests to JUnit Jupiter API so that we can avoid reworking.

@marcphilipp Unfortunately seems there's a regression in 5.1.0-RC1 so I have to use 5.1.0-M2 somewhere in tests: https://github.com/junit-team/junit5/issues/1285

Great work @blindpirate! Let's get this merged so people can start playing with it. We can open issues for the few remaining questions we had.


CLOUDSTACK-9851 travis CI build failure after merge of PR#1953 & CLOUDSTACK-9850

Fixed travis CI failures happening after merge of PR#1953.
Also fixed root volume detach that was broken after merge of PR#1953.
I found following logs with root volume attach.
2017-03-24 23:19:48,380 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] (API-Job-Executor-27:ctx-7c53d1bc job-44) (logid:f3b54257) Executing AsyncJobVO {id:44, userId: 2, accountId: 2, instanceType: Volume, instanceId: 3, cmd: org.apache.cloudstack.api.command.admin.volume.AttachVolumeCmdByAdmin, cmdInfo: {"apiKey":"PYHMg5HhOkmTQvlmZSe1dIDfTxl8uwreeFoqfj0a4zPCC-1XTuwH7H5I8Ac9fyvPbtNO1eN9THi72q8ATfs8hg","signature":"DD+ljbVWpWQw6FCl1tCDSYe5Ui0\u003d","httpmethod":"GET","deviceid":"0","ctxAccountId":"2","uuid":"2db57cd8-c96c-48f9-83c5-b9a79c852cc5","cmdEventType":"VOLUME.ATTACH","virtualmachineid":"9cb6a944-8775-4e11-961b-0e8dbdebf5a7","response":"json","ctxUserId":"2","ctxStartEventId":"117","id":"2db57cd8-c96c-48f9-83c5-b9a79c852cc5","ctxDetails":"{\"interface com.cloud.vm.VirtualMachine\":\"9cb6a944-8775-4e11-961b-0e8dbdebf5a7\",\"interface com.cloud.storage.Volume\":\"2db57cd8-c96c-48f9-83c5-b9a79c852cc5\"}"}, cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: null, initMsid:<PHONE_NUMBER>, completeMsid: null, lastUpdated: null, lastPolled: null, created: null } 2017-03-24 23:19:50,160 ERROR [c.c.v.VmWorkJobHandlerProxy] (Work-Job-Executor-15:ctx-489eb1dd job-44/job-45 ctx-cce17070) (logid:f3b54257) Invocation exception, caused by: java.lang.RuntimeException: deviceId should be 1,2,4-5

LGTM for code change. Most of the recent travis CI is failing for this.

LGTM for code changes

LGTM

tag:mergeready

@SudharmaJain Although the PR fixes the tests but it is not correct. I looked at PR #1953 and the changes there are incorrect.
getMaxDataVolumes() returns only the data volume count by excluding the root and cd-rom device. That PR is again subtracting them which results in incorrect limit.

Thanks @koushik-das for reviewing this. So Let me close this and root volume detach should also be fixed as a part of PR #1953.

LGTM

@koushik-das As suggested by you, I have  added changes to correct the maxDataVolume limits.

Code changes LGTM. @SudharmaJain Can you check on the travis failures?

LGTM, travis failure is not related to this PR, it is fixed in #2021

merging now


Add XML documentation for publishing library to .Net API Reference

Lots of hardwork coming in!
Contributors:
@JRahnama @v-kaywon @cheenamalhotra
Changes with this PR:

Adds common XML doc snippets to be extracted for XML documentation
Adds Samples to repository included in documentation
Updated both NetFx and NetCore drivers with documentation includes.
GitIgnore update to exclude nuget.exe
build.proj now defaults to BuildAllConfigurations target. Addresses #197
Added include tags in 'ref' classes for Visual Studio Intellisense support.

Additional Changes in this PR:

Microsoft.Data.SqlTypes.SqlFileStream added in NetFx.
Existing tests run against the newly added SqlFileStream class.

As of now, this PR brings documentation over from System.Data.SqlClient.
Work to be continued to enhance missing docs in future PRs.

NuGet Package from Commits Feed:
Microsoft.Data.SqlClient 1.1.0-build.19274.1-d6f2e29


azure.ai.ml.dsl.pipeline decorate should support identity argument

Is your feature request related to a problem? Please describe.
The PipelineJob python class and YAML schema supports an identity attribute, yet the dsl.pipeline decorator provides no way to pass this in.
Describe the solution you'd like
It is unclear whether pipelines should be usable with UserIdentityConfiguration. We are using a compute cluster where user ACLs are used to authenticate to ADLS gen v2. We can submit single jobs with the identity argument just fine.
Describe alternatives you've considered
We are currently setting the identity attribute on the PipelineJob instance directly. This seems like an anti-pattern.
Additional context
Are pipeline jobs intended to be used with UserIdentityConfiguration? Or this this an anti-pattern?

Thanks for the feedback, we’ll investigate asap.

closing as obsolete


First draft of the general connection pooling info.

 Should we say "... can be higher..."?

I think it is always higher if the number of threads exceeds the number of cores, due to time-slicing. But just in case I changed it to "is typically higher".

Network latency is typically the least important factor in determining the connection pool size.

If this is the case, should we mention network latency at all?

I think we should if only to avoid pedants who will say, "what about network latency?". Maybe something to ask @rafiss  about.

Is this always the case? Should we say "... can be higher..."?

I think it is always higher if the number of threads exceeds the number of cores, due to time-slicing. But just in case I changed it to "is typically higher".

Network latency is typically the least important factor in determining the connection pool size.

If this is the case, should we mention network latency at all?

I think we should if only to avoid pedants who will say, "what about network latency?". Maybe something to ask @rafiss  about.

I'm not sure how # spindles can be correlated to the connection pool size. I doubt it can be, credibly that is.
Specifically, the formula suggests the faster the storage (# connections is proportional to # spindles; more spindles generally means faster IO), the bigger the pool size can be. This maybe it's incorrect; the opposite is true. The reason overcommitting connections to CPU works is because during query processing CPU has to wait for IO (disk and network ios). Means it can process another query in the meantime. The faster the IO, the better is CPU utilization and consequently less benefit for running 2  queries on 1 core. In a theoretical case when 0 IO is needed, there is no benefit in having more than 1 sql exe thread per core.
I suggest removing the disk and network IO references altogether (adds confusion, not actionable by user, not entirely true technically; there are no "spindles" in many types of storage e.g. cloud storage) and use a simple formula consistent with our sizing guidance - the connection pool size across all apps should not exceed 4 * the total cores (vcpus) in the cluster, presuming connections are uniformly distributed across all nodes (in case nodes are diff size, not recommended, but then - proportionally to vcpus per node)
We don't need to talk about active connections in relation to connection pool size. We know the number of cores in the cluster. That's the input for connection pool sizing. (Fwiw, the active connections stuff is for cluster sizing, which the task of figuring the number of cores and nodes required... a related yet different exercise).

I'm not sure how # spindles can be correlated to the connection pool size. I doubt it can be, credibly that is.
Specifically, the formula suggests the faster the storage (# connections is proportional to # spindles; more spindles generally means faster IO), the bigger the pool size can be. This maybe it's incorrect; the opposite is true. The reason overcommitting connections to CPU works is because during query processing CPU has to wait for IO (disk and network ios). Means it can process another query in the meantime. The faster the IO, the better is CPU utilization and consequently less benefit for running 2  queries on 1 core. In a theoretical case when 0 IO is needed, there is no benefit in having more than 1 sql exe thread per core.
I suggest removing the disk and network IO references altogether (adds confusion, not actionable by user, not entirely true technically; there are no "spindles" in many types of storage e.g. cloud storage) and use a simple formula consistent with our sizing guidance - the connection pool size across all apps should not exceed 4 * the total cores (vcpus) in the cluster, presuming connections are uniformly distributed across all nodes (in case nodes are diff size, not recommended, but then - proportionally to vcpus per node)
We don't need to talk about active connections in relation to connection pool size. We know the number of cores in the cluster. That's the input for connection pool sizing. (Fwiw, the active connections stuff is for cluster sizing, which the task of figuring the number of cores and nodes required... a related yet different exercise).

I'm not sure how # spindles can be correlated to the connection pool size. I doubt it can be, credibly that is.
Specifically, the formula suggests the faster the storage (# connections is proportional to # spindles; more spindles generally means faster IO), the bigger the pool size can be. This maybe it's incorrect; the opposite is true. The reason overcommitting connections to CPU works is because during query processing CPU has to wait for IO (disk and network ios). Means it can process another query in the meantime. The faster the IO, the better is CPU utilization and consequently less benefit for running 2 queries on 1 core. In a theoretical case when 0 IO is needed, there is no benefit in having more than 1 sql exe thread per core.

I think the HikariCP docs explain this in more detail, but it is strongly implied that the increasing the number of spindles increases latency in the storage system.
https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing

I suggest removing the disk and network IO references altogether (adds confusion, not actionable by user, not entirely true technically; there are no "spindles" in many types of storage e.g. cloud storage) and use a simple formula consistent with our sizing guidance - the connection pool size across all apps should not exceed 4 * the total cores (vcpus) in the cluster, presuming connections are uniformly distributed across all nodes (in case nodes are diff size, not recommended, but then - proportionally to vcpus per node)
We don't need to talk about active connections in relation to connection pool size. We know the number of cores in the cluster. That's the input for connection pool sizing. (Fwiw, the active connections stuff is for cluster sizing, which the task of figuring the number of cores and nodes required... a related yet different exercise).

This brings up a problem in talking about connection pool sizing. How do we talk about sizing the connection pool at the application layer with HikariCP when the connection pool size maximum is across all applications that use the cluster? In other words, how do I, an application developer, know how to size my connection pool when I don't know what other applications are hitting the same database? If I were configuring PgBouncer as a proxy in between my application and the database, that would be easy. But that is more an operator configuration since it's a deployment scenario.

I'm not sure how # spindles can be correlated to the connection pool size. I doubt it can be, credibly that is.
Specifically, the formula suggests the faster the storage (# connections is proportional to # spindles; more spindles generally means faster IO), the bigger the pool size can be. This maybe it's incorrect; the opposite is true. The reason overcommitting connections to CPU works is because during query processing CPU has to wait for IO (disk and network ios). Means it can process another query in the meantime. The faster the IO, the better is CPU utilization and consequently less benefit for running 2 queries on 1 core. In a theoretical case when 0 IO is needed, there is no benefit in having more than 1 sql exe thread per core.

I think the HikariCP docs explain this in more detail, but it is strongly implied that the increasing the number of spindles increases latency in the storage system.
https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing

I suggest removing the disk and network IO references altogether (adds confusion, not actionable by user, not entirely true technically; there are no "spindles" in many types of storage e.g. cloud storage) and use a simple formula consistent with our sizing guidance - the connection pool size across all apps should not exceed 4 * the total cores (vcpus) in the cluster, presuming connections are uniformly distributed across all nodes (in case nodes are diff size, not recommended, but then - proportionally to vcpus per node)
We don't need to talk about active connections in relation to connection pool size. We know the number of cores in the cluster. That's the input for connection pool sizing. (Fwiw, the active connections stuff is for cluster sizing, which the task of figuring the number of cores and nodes required... a related yet different exercise).

This brings up a problem in talking about connection pool sizing. How do we talk about sizing the connection pool at the application layer with HikariCP when the connection pool size maximum is across all applications that use the cluster? In other words, how do I, an application developer, know how to size my connection pool when I don't know what other applications are hitting the same database? If I were configuring PgBouncer as a proxy in between my application and the database, that would be easy. But that is more an operator configuration since it's a deployment scenario.

This brings up a problem in talking about connection pool sizing. How do we talk about sizing the connection pool at the application layer with HikariCP when the connection pool size maximum is across all applications that use the cluster? In other words, how do I, an application developer, know how to size my connection pool when I don't know what other applications are hitting the same database?

I believe you would still size for your application needs. If there are multiple applications, which is something we see with users with many microservices, then you might want want to bring in something like PGBouncer to act as the funnel to the database. However, I think we can treat this as a separate use case which might fit better in operator docs.

This brings up a problem in talking about connection pool sizing. How do we talk about sizing the connection pool at the application layer with HikariCP when the connection pool size maximum is across all applications that use the cluster? In other words, how do I, an application developer, know how to size my connection pool when I don't know what other applications are hitting the same database?

I believe you would still size for your application needs. If there are multiple applications, which is something we see with users with many microservices, then you might want want to bring in something like PGBouncer to act as the funnel to the database. However, I think we can treat this as a separate use case which might fit better in operator docs.


Use of 2D GT landmarks

Hi, thank you for your paper and code, very nice work!
I was wondering if you could illuminate me as to where in your code you access (or use) the ground truth 2D landmarks for the projections when performing the registration test.
I am asking this to test your code with my own annotated CT and generated DRR with manual landmark annotations. I notice I can run the code and have some results without ever specifying where those ground truth 2D landmarks should be collected from, which is odd.
Thank you in advance for this.

Hi @pimatysiak, the two datasets we evaluate in this work don't have ground truth 2D landmarks per se. Instead, the authors of these datasets annotated landmarks in each 3D CT and projected these into 2D using the ground truth extrinsic/intrinsic matrices. In the DeepFluoro dataset, ground truth poses were determined with an offline global registration processes. In the Ljubljana dataset, ground truth poses were determined by registering implanted fiducials - unfortunately these 2D/3D landmarks are not available in the dataset.
This was something that confused me too when I started working with these datasets. This issue may help clarify: https://github.com/rg2/DeepFluoroLabeling-IPCAI2020/issues/4

Hi Vivek, thanks for the quick reply!
Specifically for the DeepFluoro dataset I know the landmarks were computed automatically, but the paper specifies that they were manually inspected and verified, which is why I considered them to be "ground truth", and they are included in the dataset.
I guess if you do not use them for the validation and instead project landmarks on the provided fluoro images from the 3D landmarks, it's fine, I guess that was just a misunderstanding on my part.
Would you think it possible to still plug in those 2D ground truth landmarks into the registration framework, so I can rule out bad automated landmarks if the results I get are unsatisfactory? Could you point out which section of the code I should modify for this? I notice you have a get_2d_fiducials method but I don't see it used.. unless I'm blind.

get_2d_fiducials is used for visualization purposes - it's been called whenever you see landmarks in figures in the paper.
The 2D landmarks aren't only used for figures, however. They're also used in the validation function that computes registration error (see, the Evaluator class). I could have unified their implementation to use the same helper function ... something to simplify in future implementation!

Ah I see, that's why I didn't find it in the validation. Thanks!
Forgive me for being annoying, but could you specify where you load the 2D landmarks? I noticed in your Evaluator class that you indeed load what you call fiducials from the specimen, but it looks to me that the ones that are loaded are only the 3D landmarks from the patient, not the individual 2D landmarks from each fluoro image used in the evaluation.. Unless I am once again mistaken?

I don't load the 2D landmarks from the DeepFluoro dataset. Since they're just the perspective projection of the fiducials, I just compute them myself. For sanity, here's a check that the two are equal:
import torch
from diffpose.calibration import perspective_projection
from diffpose.deepfluoro import DeepFluoroDataset, convert_diffdrr_to_deepfluoro

idx = 1  # Specimen ID
jdx = 0  # X-ray ID

specimen = DeepFluoroDataset(idx)

# From DiffPose
_, pose = specimen[jdx]
pose = convert_diffdrr_to_deepfluoro(specimen, pose)
perspective_projection(pose, specimen.intrinsic, specimen.fiducials)

# tensor([[[1599.6984,  639.4305],
#          [  29.8002,  625.9924],
#          [1409.0881, 1118.6995],
#          [ 236.0820, 1138.9253],
#          [1314.6082,  673.6483],
#          [ 386.6854,  685.3052],
#          [1156.6296, 1393.9117],
#          [ 563.0671, 1408.9928],
#          [ 858.9445, 1423.1156],
#          [ 805.6584, 1422.8655],
#          [ 985.3099, 1336.1173],
#          [ 688.2995, 1325.3735],
#          [ 845.8329, 1303.7023],
#          [ 796.3127, 1305.0377]]])

# From DeepFluoro
torch.tensor([x[:] for x in  specimen.projections[f"{jdx:03d}/gt-landmarks"].values()]).squeeze()

# tensor([[1599.6986,  639.4305],
#         [  29.8006,  625.9923],
#         [1409.0884, 1118.6995],
#         [ 236.0822, 1138.9249],
#         [1314.6084,  673.6480],
#         [ 386.6857,  685.3053],
#         [1156.6298, 1393.9119],
#         [ 563.0674, 1408.9928],
#         [ 858.9448, 1423.1151],
#         [ 805.6586, 1422.8654],
#         [ 985.3102, 1336.1173],
#         [ 688.2997, 1325.3733],
#         [ 845.8331, 1303.7023],
#         [ 796.3130, 1305.0375]])

They're equal up to floating point error, which probably contributes ~10^-3 mm of registration error.

no problem at all, happy to answer any questions. hope it's helpful for your work!


[WIP] Add all integer/real runtime variables

Fixes #60.
Use the pg_settings view to retrieve runtime variables:
https://www.postgresql.org/docs/current/static/view-pg-settings.html
This replaces the use of SHOW to retrieve runtime variables.
In PostgreSQL 9.6, this adds 339 metrics, which use the short_desc
field as a description.
Only runtime variables with a vartype of real or integer are
currently supported.
Example metrics:
# HELP pg_settings_archive_timeout Forces a switch to the next xlog file if a new file has not been started within N seconds.
# TYPE pg_settings_archive_timeout gauge
pg_settings_archive_timeout 0
# HELP pg_settings_authentication_timeout Sets the maximum allowed time to complete client authentication.
# TYPE pg_settings_authentication_timeout gauge
pg_settings_authentication_timeout 60
# HELP pg_settings_autovacuum_analyze_scale_factor Number of tuple inserts, updates, or deletes prior to analyze as a fraction of reltuples.
# TYPE pg_settings_autovacuum_analyze_scale_factor gauge
pg_settings_autovacuum_analyze_scale_factor 0.1
# HELP pg_settings_autovacuum_analyze_threshold Minimum number of tuple inserts, updates, or deletes prior to analyze.
# TYPE pg_settings_autovacuum_analyze_threshold gauge
pg_settings_autovacuum_analyze_threshold 50

Tries to use the unit column from the pg_settings view to determine
which unit a metric is using, and normalise the metrics accordingly to
match Prometheus conventions:
https://prometheus.io/docs/practices/naming/
Settings with units of 8kB are not normalised because most of those
metrics are counting pages rather than bytes, e.g.:
# HELP pg_settings_checkpoint_flush_after Number of pages after which previously performed writes are flushed to disk.
# TYPE pg_settings_checkpoint_flush_after gauge
pg_settings_checkpoint_flush_after 0

# select * from pg_settings WHERE name = 'checkpoint_flush_after';
-[ RECORD 1 ]---+-----------------------------------------------------------------------------
name            | checkpoint_flush_after
setting         | 0
unit            | 8kB
category        | Write-Ahead Log / Checkpoints
short_desc      | Number of pages after which previously performed writes are flushed to disk.
extra_desc      |
context         | sighup
vartype         | integer
source          | default
min_val         | 0
max_val         | 256
enumvals        |
boot_val        | 0
reset_val       | 0
sourcefile      |
sourceline      |
pending_restart | f

I'm interested in feedback on this PR - this change adds a lot of metrics (at least 339 on my test setup), which I'm not sure is desired.
I'd also like to look at adding some tests for this PR before it's merged.

/cc @prymitive @bobrik @ferringb

Rebased to fix the integration test.

Test wise we'd want to figure out how to assert the unit inference works version to version I think, which might be a bit of a change to how I run the tests now since the best way would be to do a like to like comparison across postgres versions where one unit matches.
Adding 300+ metrics which don't change much should be okay for Prometheus since unchanging metrics yield a pointer update in the backend and no additional storage use.
At the very least Prometheus should be arbitrating what it wants to accept, not us.

@wrouesnel: Prometheus can compress these kinds of metrics efficiently, however the overhead of indexing and retaining the extra timeseries in-memory is worth considering IMHO.
I think it's probably fine - these are useful metrics to have and we could always put them behind a feature flag in future if users complained.

I miscounted the number of metrics - I've included bool types and the number of metrics is 189 using PostgreSQL 9.6.

Sorry for the delay on this, picking it up again.

Updated to add tests, please take a look.

Coverage increased (+0.4%) to 52.159% when pulling 51aefbb376c82c4545fe49fcc2342919f826719f on mattbostock:pg_settings into 0b003b29014e0c14d290bae2138807c082474a26 on wrouesnel:master.

Hopefully I'll have time in the next few days. Thanks for the great work on this!

Coverage increased (+0.4%) to 51.815% when pulling f9df40d5fb9d81f0f735d3ab01d85842c152b2b3 on mattbostock:pg_settings into 53b9d9cea7de0d4ae4194e0e52ea2ca10911979b on wrouesnel:master.

Coverage increased (+0.4%) to 51.815% when pulling f9df40d5fb9d81f0f735d3ab01d85842c152b2b3 on mattbostock:pg_settings into 53b9d9cea7de0d4ae4194e0e52ea2ca10911979b on wrouesnel:master.

Spent some time augmenting the integration tests so I could inspect the result of this. In future I definitely need to have CI send comments automatically for me - across all versions:
Removed Metrics
pg_runtime_variable_max_connections
pg_runtime_variable_max_files_per_process
pg_runtime_variable_max_function_args
pg_runtime_variable_max_identifier_length
pg_runtime_variable_max_index_keys
pg_runtime_variable_max_locks_per_transaction
pg_runtime_variable_max_pred_locks_per_transaction
pg_runtime_variable_max_prepared_transactions
pg_runtime_variable_max_standby_archive_delay_milliseconds
pg_runtime_variable_max_standby_streaming_delay_milliseconds
pg_runtime_variable_max_wal_senders

Added Metrics
pg_settings_allow_system_table_mods
pg_settings_archive_mode
pg_settings_archive_timeout_seconds
pg_settings_array_nulls
pg_settings_authentication_timeout_seconds
pg_settings_autovacuum
pg_settings_autovacuum_analyze_scale_factor
pg_settings_autovacuum_analyze_threshold
pg_settings_autovacuum_freeze_max_age
pg_settings_autovacuum_max_workers
pg_settings_autovacuum_multixact_freeze_max_age
pg_settings_autovacuum_naptime_seconds
pg_settings_autovacuum_vacuum_cost_delay_seconds
pg_settings_autovacuum_vacuum_cost_limit
pg_settings_autovacuum_vacuum_scale_factor
pg_settings_autovacuum_vacuum_threshold
pg_settings_autovacuum_work_mem_bytes
pg_settings_backend_flush_after_bytes
pg_settings_bgwriter_delay_seconds
pg_settings_bgwriter_flush_after_bytes
pg_settings_bgwriter_lru_maxpages
pg_settings_bgwriter_lru_multiplier
pg_settings_block_size
pg_settings_bonjour
pg_settings_check_function_bodies
pg_settings_checkpoint_completion_target
pg_settings_checkpoint_flush_after_bytes
pg_settings_checkpoint_segments
pg_settings_checkpoint_timeout_seconds
pg_settings_checkpoint_warning_seconds
pg_settings_commit_delay
pg_settings_commit_siblings
pg_settings_cpu_index_tuple_cost
pg_settings_cpu_operator_cost
pg_settings_cpu_tuple_cost
pg_settings_cursor_tuple_fraction
pg_settings_data_checksums
pg_settings_db_user_namespace
pg_settings_deadlock_timeout_seconds
pg_settings_debug_assertions
pg_settings_debug_pretty_print
pg_settings_debug_print_parse
pg_settings_debug_print_plan
pg_settings_debug_print_rewritten
pg_settings_default_statistics_target
pg_settings_default_transaction_deferrable
pg_settings_default_transaction_read_only
pg_settings_default_with_oids
pg_settings_effective_cache_size_bytes
pg_settings_effective_io_concurrency
pg_settings_enable_bitmapscan
pg_settings_enable_hashagg
pg_settings_enable_hashjoin
pg_settings_enable_indexonlyscan
pg_settings_enable_indexscan
pg_settings_enable_material
pg_settings_enable_mergejoin
pg_settings_enable_nestloop
pg_settings_enable_seqscan
pg_settings_enable_sort
pg_settings_enable_tidscan
pg_settings_escape_string_warning
pg_settings_exit_on_error
pg_settings_extra_float_digits
pg_settings_from_collapse_limit
pg_settings_fsync
pg_settings_full_page_writes
pg_settings_geqo
pg_settings_geqo_effort
pg_settings_geqo_generations
pg_settings_geqo_pool_size
pg_settings_geqo_seed
pg_settings_geqo_selection_bias
pg_settings_geqo_threshold
pg_settings_gin_fuzzy_search_limit
pg_settings_gin_pending_list_limit_bytes
pg_settings_hot_standby
pg_settings_hot_standby_feedback
pg_settings_idle_in_transaction_session_timeout_seconds
pg_settings_ignore_checksum_failure
pg_settings_ignore_system_indexes
pg_settings_integer_datetimes
pg_settings_join_collapse_limit
pg_settings_krb_caseins_users
pg_settings_lock_timeout_seconds
pg_settings_lo_compat_privileges
pg_settings_log_autovacuum_min_duration_seconds
pg_settings_log_checkpoints
pg_settings_log_connections
pg_settings_log_disconnections
pg_settings_log_duration
pg_settings_log_executor_stats
pg_settings_log_file_mode
pg_settings_logging_collector
pg_settings_log_hostname
pg_settings_log_lock_waits
pg_settings_log_min_duration_statement_seconds
pg_settings_log_parser_stats
pg_settings_log_planner_stats
pg_settings_log_replication_commands
pg_settings_log_rotation_age_seconds
pg_settings_log_rotation_size_bytes
pg_settings_log_statement_stats
pg_settings_log_temp_files_bytes
pg_settings_log_truncate_on_rotation
pg_settings_maintenance_work_mem_bytes
pg_settings_max_connections
pg_settings_max_files_per_process
pg_settings_max_function_args
pg_settings_max_identifier_length
pg_settings_max_index_keys
pg_settings_max_locks_per_transaction
pg_settings_max_parallel_workers_per_gather
pg_settings_max_pred_locks_per_transaction
pg_settings_max_prepared_transactions
pg_settings_max_replication_slots
pg_settings_max_stack_depth_bytes
pg_settings_max_standby_archive_delay_seconds
pg_settings_max_standby_streaming_delay_seconds
pg_settings_max_wal_senders
pg_settings_max_wal_size_bytes
pg_settings_max_worker_processes
pg_settings_min_parallel_relation_size_bytes
pg_settings_min_wal_size_bytes
pg_settings_old_snapshot_threshold_seconds
pg_settings_operator_precedence_warning
pg_settings_parallel_setup_cost
pg_settings_parallel_tuple_cost
pg_settings_password_encryption
pg_settings_port
pg_settings_post_auth_delay_seconds
pg_settings_pre_auth_delay_seconds
pg_settings_quote_all_identifiers
pg_settings_random_page_cost
pg_settings_replacement_sort_tuples
pg_settings_replication_timeout_seconds
pg_settings_restart_after_crash
pg_settings_row_security
pg_settings_segment_size_bytes
pg_settings_seq_page_cost
pg_settings_server_version_num
pg_settings_shared_buffers_bytes
pg_settings_silent_mode
pg_settings_sql_inheritance
pg_settings_ssl
pg_settings_ssl_prefer_server_ciphers
pg_settings_ssl_renegotiation_limit_bytes
pg_settings_standard_conforming_strings
pg_settings_statement_timeout_seconds
pg_settings_superuser_reserved_connections
pg_settings_synchronize_seqscans
pg_settings_syslog_sequence_numbers
pg_settings_syslog_split_messages
pg_settings_tcp_keepalives_count
pg_settings_tcp_keepalives_idle_seconds
pg_settings_tcp_keepalives_interval_seconds
pg_settings_temp_buffers_bytes
pg_settings_temp_file_limit_bytes
pg_settings_trace_notify
pg_settings_trace_sort
pg_settings_track_activities
pg_settings_track_activity_query_size
pg_settings_track_commit_timestamp
pg_settings_track_counts
pg_settings_track_io_timing
pg_settings_transaction_deferrable
pg_settings_transaction_read_only
pg_settings_transform_null_equals
pg_settings_unix_socket_permissions
pg_settings_update_process_title
pg_settings_vacuum_cost_delay_seconds
pg_settings_vacuum_cost_limit
pg_settings_vacuum_cost_page_dirty
pg_settings_vacuum_cost_page_hit
pg_settings_vacuum_cost_page_miss
pg_settings_vacuum_defer_cleanup_age
pg_settings_vacuum_freeze_min_age
pg_settings_vacuum_freeze_table_age
pg_settings_vacuum_multixact_freeze_min_age
pg_settings_vacuum_multixact_freeze_table_age
pg_settings_wal_block_size
pg_settings_wal_buffers_bytes
pg_settings_wal_compression
pg_settings_wal_keep_segments
pg_settings_wal_log_hints
pg_settings_wal_receiver_status_interval_seconds
pg_settings_wal_receiver_timeout_seconds
pg_settings_wal_retrieve_retry_interval_seconds
pg_settings_wal_segment_size_bytes
pg_settings_wal_sender_delay_seconds
pg_settings_wal_sender_timeout_seconds
pg_settings_wal_writer_delay_seconds
pg_settings_wal_writer_flush_after_bytes
pg_settings_work_mem_bytes
pg_settings_zero_damaged_pages

Two metrics not retained (looking at the short names) between the versions are:
max_standby_archive_delay_milliseconds
max_standby_streaming_delay_milliseconds

Which looks to be because we pick up "seconds" instead.
So nothing's lost and I'll add this data to release notes.

Closed by 98ba5663221a514b0d334780eb3651b9838c42c7
I ended up doing some rebasing and touch-ups on the commit messages, but your authorship is preserved. Great work - I'll think on it for another few days and cut a new release then.

Coverage remained the same at 51.815% when pulling d0f1e378e525d1751d5f0779e57240ed1b0c196e on mattbostock:pg_settings into 98ba5663221a514b0d334780eb3651b9838c42c7 on wrouesnel:master.

Thanks!


Use Copyfile() to back up the log, so as not to continue writing the …

Use Copyfile() to back up the log, so as not to continue writing the log to the old file because the old fd is not closed #1366

@flead CI failed.

Closed due to inactivity.


jsx in index.js causing compiling error

I'm trying to use the library in a project created by create-react-app.  There's a JSX at line 135.
Error in<EMAIL_ADDRESS>Module parse failed<EMAIL_ADDRESS>Unexpected token (135:16)
You may need an appropriate loader to handle this file type.
SyntaxError: Unexpected token (135:16)

Module parse failed<EMAIL_ADDRESS>Unexpected token (135:16)
You may need an appropriate loader to handle this file type.
|   },
|   render() {
|     var input = <input
|       ref='input'
|       className={this.props.inputClass}

Was there any solution to this? With create-react-app the webpack config is hidden and I'd rather not have to eject it - if it's related to webpack

@tmcw can y'all look into addressing this issue? Would be good to have a component supported by mapbox doing the thing that the fork is currently doing.

You'll need to take it up with someone who works at Mapbox, I do not work there.


Colin/portfolio swap

This is based off of waylon/portfolio-swap but is now further ahead.

Getting to merge conflicts now


[Feature request] add support for scenes

Is it possible to add support to use the Govee Scenes and/or DIY scenes available for each device?

Unfortunately the LAN APIs don't support them.


lib3mf: 1.8.1 → 2.0.0

Motivation for this change
Failed in https://r.ryantm.com/log/2020-10-17.log
Result of nixpkgs-review 11

2 packages built:

lib3mf
openscad

Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[x] macOS
[x] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 101105 run on x86_64-darwin 1

2 packages built:

lib3mf
openscad

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

2 packages built:

lib3mf
openscad


Getting "[emerg] no "ssl_certificate" is defined for the "listen ... ssl" directive in webiste.conf

Information

It's related to script and nginx
Help request
Problem

After "SSL Init" step,  and running command for "Comment out SSL related directives in the configuration: ", sudo nginx -t fails with error message [emerg] no "ssl_certificate" is defined for the "listen ... ssl" directive in webiste.conf
What I have tried

I had to comment out the whole server block that contains listen 443 to solve the issue. Only then the nginx config is correct and certbot can be used to generate certificate.
I am thinking ssl off command is not disabling the whole server block ssl.
Screenshots

What does your listen definition look like after running that first sed command?
What OS are you on?

server {
    ssl off;
    listen                  443; # ssl http2;
    listen                  [::]:443; # ssl http2;
    server_name             example-server.example.com;
    set                     $base /var/www/example-server.example.com;
    root                    $base/current/public;

    # SSL
    #;#ssl_certificate         /etc/letsencrypt/live/example-server.example.com/fullchain.pem;
    #;#ssl_certificate_key     /etc/letsencrypt/live/example-server.example.com/privkey.pem;
    #;#ssl_trusted_certificate /etc/letsencrypt/live/example-server.example.com/chain.pem;

    # security
    include                 nginxconfig.io/security.conf;

    # logging
    access_log              /var/log/nginx/access.log combined buffer=512k flush=1m;
    error_log               /var/log/nginx/error.log warn;

    # index.php
    index                   index.php;

    # index.php fallback
    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    # additional config
    include nginxconfig.io/general.conf;

    # handle .php
    location ~ \.php$ {
        fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
        include      nginxconfig.io/php_fastcgi.conf;
    }
}

# subdomains redirect
server {
    ssl off;
    listen                  443; # ssl http2;
    listen                  [::]:443; # ssl http2;
    server_name             *.example-server.example.com;

    # SSL
    #;#ssl_certificate         /etc/letsencrypt/live/example-server.example.com/fullchain.pem;
    #;#ssl_certificate_key     /etc/letsencrypt/live/example-server.example.com/privkey.pem;
    #;#ssl_trusted_certificate /etc/letsencrypt/live/example-server.example.com/chain.pem;
    return                  301 https://example-server.example.com$request_uri;
}

# HTTP redirect
server {
    ssl off;
    listen      80;
    listen      [::]:80;
    server_name .example-server.example.com;
    include     nginxconfig.io/letsencrypt.conf;

    location / {
        return 301 https://example-server.example.com$request_uri;
    }
}

OS:
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.6 LTS
Release:        20.04
Codename:       focal
nginx version: nginx/1.24.0

I created a new config today, and the new config is working fine.

Closing as not reproducible -- the shared config has no active listen ssl in it.


Error: CoreServer needs further setup to launch the browserEmulator.

Error: CoreServer needs further setup to launch the browserEmulator. See server logs.
Got this error immediately after starting my code on new created ubuntu 18.04 or 20.04 server. There is no such error on old server. My assumption is that on old server I updated secret-agent incrementally from secret-agent v1.3.* or maybe even from v1.2.* (if I remember correctly).
Current version secret-agent v1.4.1-alpha.0.

Hi @dmzebrov,
We did two things that might have triggered this message - one was switching to Chrome (from Chromium), and second, we added a "dependency checker" to ubuntu to make sure all the linked libraries that Chrome (and Chromium) need are present on the machine. We did this in a minor version release because the library is still in Alpha. Normally, this would have necessitated a full major version.
Were you able to run the instructions and get running?

I am able to run on macOS Big Sur 11.2.1 and on Ubuntu 18.04 and not able to run on new created 18.04 or 20.04 server.

Oh, ok. Can you share logs from your server? Did you attempt to run the debian installer from the logs there and it didn't work?

Can you please specify what logs you need?

Are there console output logs on the server?

journalctl gives me absolutely nothing connected with secret-agent... In journalctl follow mode there are no new logs when I start my code and get  aforementioned error. I also checked /var/log/syslog, /var/log/dmesg and some others. Nothing...

How did you start SecretAgent on that server? Could you start again as a foreground process and look at the logs? Should just be outputting as normal stdout.

Oh, you mean normal stdout, sorry for my misunderstanding. Here is file with node output:
logs.txt

Are you running full-client all from that server? Ie, no special setup with a core process? If so, it looks like the log that shows you the command to run is being hidden from view. It should be telling you that you have missing dependencies and provides a script to correct it.
Do you have a session database you could share? It might show me more about what exactly is failing here.
Thanks

Sure, here is database:
cd63b450-90a1-11eb-910c-d3d7e1aa8173.db.zip

Thanks! Unfortunately, doesn't have any details about the error. It should be printing out that you have dependencies missing, and link to running this script:
sudo $(npx puppet-install-deps)
Just running this npx puppet-install-deps will tell you the script path, which you should be able to inspect first. If it's there correctly, running it will install all your dependencies.

I ran script from output and it resolves the problem! Thank you!


Add links to open in Remote - Containers

Add the badge and link to open in Remote-Containers. Happy to discuss any wording or location suggestions!

Duplicate of #


Interfacing BeagleBone Black with Temperature sensor

What is a dtb file?
What issues did you or other might face regarding connecting the temperature sensor to an BBB?

ANS: - DT stands for device tree. device tree is a hardware description script. when we add new hardware to beagle-bone it does,t know what hardware it is and what its output. so in device tree we explain all the seensor properties and then we save that file as a DTS or .dts which means device tree source. then we compiler that code and the compiler output is .dtbo file which means device tree binary output. So know when we mention this bianry file in boot file. kernal will know which hardware it is.

Answer 2 : - Yes a lot because we have to explain all the properties of senor to beagle-bone and the put those changes in boot file which cause so many problems if we even miss one "," or any little mistake will corrupt the boot file which is uEnv.txt . If its corrupted we have to do flashing again. which we did like 4-5 times.
then we also got some error with eMMC blocking the u-boot_overlay file which cause no detection of the sensor. To solve that we ask question to Robert C. Neslon who mentaine the beaglebone kernals.
here the link our question or error we ask: - https://github.com/beagleboard/linux/issues/142#issuecomment-660562922
finally we get the correct result.


[stable/prometheus-operator] Upgrading prometheus version to v2.5.0

Upgrading prometheus-operator version to 0.26.0
Upgrading prometheus version to 2.5.0
Upgrading alertmanager version to 0.15.3
Tested on GKE by installing prometheus operator with above versions.
helm lint passed.

Signed-off-by: Harshal Shah<EMAIL_ADDRESS>What this PR does / why we need it:
prometheus operator released a new version. This PR uses the new version of this operator.
Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md

Could you please alter your changes so they won't interfere with https://github.com/helm/charts/pull/9647 and most important do not update prometheus-operator to 0.26.0 because of https://github.com/coreos/prometheus-operator/issues/2182?

I tested quickly with persistent storage and ran into coreos/prometheus-operator#2182
#9647 is doing pretty much the same thing. I will close this and keep test #9647 on GKE whenever it is ready

closing in favor of #9647

@harshal-shah, I think updating prometheus and alertmanager is worth to do before updating prometheus-operator, as well as adding stable/prometheus-operator/CONTRIBUTING.md. Could you please reopen this PR with only these changes? Thank you for your work!

@paskal Added a new commit and reopened the PR.

/ok-to-test
/assign
/lgtm


[Feature Request] Add bru support for jetbrains IDEs

There is syntax support for vsCode: https://marketplace.visualstudio.com/items?itemName=bruno-api-client.bruno
Would something similar be possible for jetbrain IDEs like WebStorm and PhpStorm?
Thx a lot!
Andreas

It's already planned https://docs.usebruno.com/bru-lang-extensions.html

Extensions for IntelliJ and the JetBrains family of IDEs are under development.

I'd also love some level of integration with bruno and PHPStorm 🔥


total number of inference benchmarks allowed

We target maximum 8 benchmarks for datacenter inference, 8 benchmarks for edge inference and 8 for mobile.
All benchmarks should match the training models unless there is a compelling reason not to do so.

updated the roadmap doc accordingly. https://docs.google.com/document/d/15SJJqVBuLLC6k8Tks1TiyPWFwEGCzFmBhgJPU8ph_7s/edit


[dev] Worker updates not seen in terminal until restarting dev

Mentioned initially in https://github.com/cloudflare/wrangler/issues/1078#issuecomment-587695836.
@EverlastingBugstopper
🐛 Bug Report
Environment

operating system: MacOS (Catalina, 10.15.1)
output of rustc -V: n/a
output of node -v: v10.17.0
output of wrangler -V: 1.8.0-rc.1

Steps to reproduce
With dev running, add a console log statement inside the worker. Save. The console log does not show up. Restart dev, the console log is there.
What did you expect to see?
The new console log should show up in the terminal without dev needing to be restarted.
What did you see instead?
The new console log does not show up in the terminal.

@yet-another-dev - the reload itself can take a bit since it needs to re-build and upload the worker to the cloudflare api (wrangler dev is not offline). Does it work if you wait a bit until you see a Built successfully message?

Does it work if you wait a bit until you see a Built successfully message?

No, I'm afraid not.

I'm having the same issue here, also with the console.logs.

Ok - I'm able to reproduce with a Workers Site project, but not with a regular worker. Going to investigate this.

It seems like this has to do with how make_service_fn works - I need to force it to update quicker than it is. Waiting on a response from some Rust experts 😄


⚠ ClamAV has degraded performance

In 72c5119, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 50 ms

Resolved: ClamAV performance has improved in 0e0edb4.


Move GOPATH check to a phony target

Signed-off-by: Mrunal Patel<EMAIL_ADDRESS>

@runcom @jawnsy @nalind PTAL

:+1:

@jawnsy renamed. Will fixup existing .PHONY in a follow on.

LGTM


Incorrect copy-paste check

E.g. I have the code:
function sum(a, b) {
    return a + b;
}

I copy it to the new file - copy-paste is detected. If I add export before the function, copy-paste is not detected anymore

Working on a fix for the next release :) Improving ES6 compatibility all around

Fixed in https://github.com/danielstjules/jsinspect/commit/3d624097ad2dd790bf97e5532c18713cfd6279f2 thanks!


S3 data remains when deleting datasource.

Hi.
I installed using release-4.2.
Hive uses s3Compatible.
apiVersion: metering.openshift.io/v1
kind: MeteringConfig
metadata:
  name: "operator-metering"
spec:
  disableOCPFeatures: true
  reporting-operator:
    spec:
      config:
        prometheus:
          # update this field
          url: "<IP>"
  hive:

  storage:
    type: "hive"
    hive:
      type: "s3Compatible"
      s3Compatible:
        bucket: "metering"
        secretName: "my-aws-secret"
        createBucket: false
        endpoint: "<IP>"

apiVersion: metering.openshift.io/v1
kind: ReportDataSource
metadata:
  name: mlp-test-gpu-datasource
  namespace: metering
spec:
  prometheusMetricsImporter:
    query: |
      metering:mlp_gpu_requests_slots:sum

I created a datasource and confirmed that it is stored in a bucket of s3. And deleted this datasource. It was deleted in the hive table but not in s3.
for obj in client.list_objects_v2(Bucket="metering", Prefix="metering.db/")['Contents']:
    print(obj['Key'])

metering.db/datasource_metering_mlp_test_gpu_datasource/dt=2019-10-14/20191014_120145_00422_hpwrj_fc1d84f3-536e-4a86-9097-2c41b4935e49.snappy
metering.db/datasource_metering_mlp_test_gpu_datasource/dt=2019-10-14/20191014_120157_00424_hpwrj_18644871-9f4d-4781-93a8-374aef4a67a7.snappy

Can I delete the data in s3?
Thank you

We don't use finalizers yet, so if the pods are deleted while the datasource is deleted, data may not be cleaned up, that being said, generally if you delete a datasource you created, it should delete the data when it drops the table which happens when you delete a datasource.

You can manually clean up the data if the datasource was deleted though, that should be fine. You can also drop the table from within Presto or Hive and that will do the same.

@chancez
Thank you for your feedback.
If I delete the datasource, the hive table is deleted. However, the s3 bucket data remained and was manually deleted.
Thank you


[Snyk] Upgrade react-router-dom from 6.17.0 to 6.18.0

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to upgrade react-router-dom from 6.17.0 to 6.18.0.
:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

The recommended version is 3 versions ahead of your current version.
The recommended version was released 21 days ago, on 2023-10-31.

Release notes

Package name: react-router-dom

6.18.0 -<EMAIL_ADDRESS>

6.18.0-pre.1 -<EMAIL_ADDRESS>

6.18.0-pre.0 - 2023-10-26

6.17.0 - 2023-10-16

    from react-router-dom GitHub release notes

Commit messages

Package name: react-router-dom

667f936 chore: Update version for release (#10981)
3c6e27c Exit prerelease mode
67af262 chore: Update version for release (pre) (#10978)
1500288 Updates for v7_fetcherPersist post-processing logic (#10977)
cacc90b chore: Update version for release (pre) (#10966)
77402de Enter prerelease mode
1a8265c Merge branch 'main' into release-next
19af0cf Add future.v7_fetcherPersist flag (#10962)
cb2d911 Add fetcher data layer (#10961)
c0dbcd2 Add useFetcher(key) and <Form navigate={false}> (#10960)
805924d Revert "Ensure Form contains splat portion of pathname when no action is specified (#10933)" (#10965)
677d6c8 Support optional path segments in `matchPath` (#10768)
a23f017 docs: Clarify fetcher load revalidation behavior
908a40a Ensure Form contains splat portion of pathname when no action is specified (#10933)
2041d9c chore: sort contributors list
a71b4e2 Merge branch 'release-next' into dev
779536c Merge branch 'release-next'
e2c0d82 Split up router-test.ts (#10929)
e74b935 Fix lint errors

Compare

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:
🧐 View latest project report
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs

fixed in https://github.com/janus-idp/backstage-showcase/pull/693


Install fails with default values

I wanted to use this cookbook to just install the zookeeper libraries, so just added "recipe[zookeeper::install]".  Attempting to cook a server I get the following error:
NoMethodError
undefined method `map' for false:FalseClass
Cookbook Trace:
/home/me/chef-solo/cookbooks-2/magic/libraries/configuration.rb:70:in `exports_config'
/home/me/chef-solo/cookbooks-2/zookeeper/recipes/install.rb:46:in `block in from_file'
/home/me/chef-solo/cookbooks-2/zookeeper/recipes/install.rb:44:in `from_file'
/home/me/chef-solo/cookbooks-2/zookeeper/recipes/default.rb:18:in `from_file'

Relevant File Content:
/home/me/chef-solo/cookbooks-2/magic/libraries/configuration.rb:
63:    def exports_raw_config obj
64:      obj.map do |k, v|
65:        "export #{k}=#{Shellwords.escape v.to_s}"
66:      end.join("\n")
67:    end
68:
69:    def exports_config obj
70>>     obj.map do |k, v|
71:        "export #{k}=#{Shellwords.escape v.to_s}"
72:      end.join("\n")
73:    end
74:
75:    def ini_config obj
76:      obj.map do |name, config|
77:        "[#{name}]\n" +
78:        config.map do |k, v|
79:          "#{k}=#{v}"
The only place exports_config is used in the zookeeper config is in install.rb:
# Add optional Zookeeper environment vars
file "#{node[:zookeeper][:config_dir]}/zookeeper-env.sh" do
  owner node[:zookeeper][:user]
  content exports_config node[:zookeeper][:env_vars]
  only_if { node[:zookeeper][:env_vars] }
end

And node[:zookeeper][:env_vars] defaults to false.  I am not setting it anywhere else.
Any idea what's going on here?

@ianbamforth damn, that might be my fault. I wrote that feature pretty quickly. I’ll check it out.

Yeah, I neglected to test with the default attributes settings, just tested setting the attributes in .kitchen.yml. I’ll test with the default settings, and rectify what is clearly a bug you’ve found.

Fixed, shipped in v2.11.0

Thanks for the swift response!
On 13 Aug 2015 22:08, Jeff Byrnes<EMAIL_ADDRESS>wrote:Fixed, shipped in v2.11.0
—Reply to this email directly or view it on GitHub.


When will JSON files with semantic segmentation polygons be available?

In the current form of the README, it says "At present time, instance segmentation is provided as semantic segmentation maps and polygons in json will be provided in the future"
Is there any update as to when these polygons in json files will be provided?

I think everyone's needs are consistent, and I hope to provide a label.json file similar to the cityscape dataset, which can generate the segmented label file of the category you need.

@tensorflowt
Hello! Do you have any latest developments? About annotation json file for 10k images for semantic segmentation.


Python 3.12 and Nix

I was adding Nix files (as for the other repos), but in the process I also noticed that the Python version was stuck before py3.12. Thus, I decided to upgrade even that, and abandon py3.8 (which has been dropped since long in Qibolab).

[x] add NumPy dependency

currently it is hidden: it is used, but undeclared

[ ] fix tests
[x] fix workflows

@rodolfocarobene sorry, I opened this mainly to add Nix, but it turned out there was a bunch of maintenance overdue :sweat_smile: