fabricbeat 'make update'

I try to start make update but this error comes out.
/opt/gopath/src/github.com/hyperledger-elastic/agent/fabricbeat$ make update
DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python 2.7. More details about Python 2 support in pip, can be found at https://pip.pypa.io/en/latest/development/release-process/#python-2-support
DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python 2.7. More details about Python 2 support in pip, can be found at https://pip.pypa.io/en/latest/development/release-process/#python-2-support
Installing mage v1.8.0 from vendor dir.
can't load package: package /opt/gopath/src/github.com/hyperledger-elastic/agent/fabricbeat/vendor/github.com/magefile/mage: import "/opt/gopath/src/github.com/hyperledger-elastic/agent/fabricbeat/vendor/github.com/magefile/mage": cannot import absolute path
vendor/github.com/elastic/beats/dev-tools/make/mage.mk:9: recipe for target 'mage' failed
make: *** [mage] Error 1

@lotty02cho after the move to hyperledger-labs, the agent paths need to be updated from hyperledger-elastic to blockchain-analyzer. They are being updated in this PR, which will be merged tomorrow. cc @balazsprehoda

@lotty02cho please full the latest changes from master. Hopefully, the make update should work.
Please note that go module vendoring is still a work in progress. Please copy vendor modules from this previous commit to the agent vendor directory:
https://github.com/hyperledger-labs/blockchain-analyzer/tree/14199bfa3e770822a7877652d1a589b425b94894/agent/fabricbeat/vendor/github.com
and then run make .

I try to clone 'blockchain-analyzer' project, but it has still errors.
/opt/gopath/src/github.com/blockchain-analyzer/agent/fabricbeat$ make update
Running virtualenv with interpreter /usr/bin/python2
New python executable in /opt/gopath/src/github.com/blockchain-analyzer/agent/fabricbeat/build/python-env/bin/python2
Also creating executable in /opt/gopath/src/github.com/blockchain-analyzer/agent/fabricbeat/build/python-env/bin/python
Installing setuptools, pkg_resources, pip, wheel...done.
DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python 2.7. More details about Python 2 support in pip, can be found at https://pip.pypa.io/en/latest/development/release-process/#python-2-support
DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python 2.7. More details about Python 2 support in pip, can be found at https://pip.pypa.io/en/latest/development/release-process/#python-2-support
ERROR: docker-compose 1.23.2 has requirement PyYAML<4,>=3.10, but you'll have pyyaml 4.2b1 which is incompatible.
Installing mage v1.8.0 from vendor dir.
can't load package: package /opt/gopath/src/github.com/blockchain-analyzer/agent/fabricbeat/vendor/github.com/magefile/mage: import "/opt/gopath/src/github.com/blockchain-analyzer/agent/fabricbeat/vendor/github.com/magefile/mage": cannot import absolute path
vendor/github.com/elastic/beats/dev-tools/make/mage.mk:9: recipe for target 'mage' failed
make: *** [mage] Error 1

I think that absolute path is important, do I have to change path or absolute path like that?

@lotty02cho I could not reproduce this error, but I suspect that the Makefile in the fabricbeat dir is responsible for this. Try to change the BEAT_PATH assginment to BEAT_PATH=github.com/blockchain-analyzer/agent/fabricbeat and see if the error is gone. Please let me know if this helps, and I fix it in a PR.

As you said, I change BEAT_PATH=github.com/blockchain-analyzer/agent/fabricbeat using vi Makefile. and now I couldn't find error.
/opt/gopath/src/github.com/blockchain-analyzer/agent/fabricbeat$ make update
DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python 2.7. More details about Python 2 support in pip, can be found at https://pip.pypa.io/en/latest/development/release-process/#python-2-support
DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python 2.7. More details about Python 2 support in pip, can be found at https://pip.pypa.io/en/latest/development/release-process/#python-2-support
Installing mage v1.8.0 from vendor dir.
/home/hyper/.magefile cleaned
Generated fields.yml for fabricbeat to /opt/gopath/src/github.com/blockchain-analyzer/agent/fabricbeat/fields.yml
Updating generated files for fabricbeat
## The line below allows beats to add a post-processor script that alters the config in arbitrary ways
mkdir -p include
go run  ./vendor/github.com/elastic/beats/dev-tools/cmd/asset/asset.go -license ASL2 -pkg include -in fields.yml -out include/fields.go fabricbeat
if [ -d /opt/gopath/src/github.com/blockchain-analyzer/agent/fabricbeat/_meta/kibana ]; then \
	cp -pr /opt/gopath/src/github.com/blockchain-analyzer/agent/fabricbeat/_meta/kibana/* /opt/gopath/src/github.com/blockchain-analyzer/agent/fabricbeat/_meta/kibana.generated ; \
fi

but when I start next command, make,  it throws error like below.
...
../../../hyperledger/fabric-sdk-go/pkg/fab/comm/connectionopts.go:16:2: cannot find package "google.golang.org/grpc/keepalive" in any of:
	/opt/go/src/google.golang.org/grpc/keepalive (from $GOROOT)
	/opt/gopath/src/google.golang.org/grpc/keepalive (from $GOPATH)
../../../hyperledger/fabric-sdk-go/pkg/fab/comm/streamconnection.go:20:2: cannot find package "google.golang.org/grpc/peer" in any of:
	/opt/go/src/google.golang.org/grpc/peer (from $GOROOT)
	/opt/gopath/src/google.golang.org/grpc/peer (from $GOPATH)
../../../hyperledger/fabric-sdk-go/pkg/common/errors/status/status.go:22:2: cannot find package "google.golang.org/grpc/status" in any of:
	/opt/go/src/google.golang.org/grpc/status (from $GOROOT)
	/opt/gopath/src/google.golang.org/grpc/status (from $GOPATH)
../../../hyperledger/fabric-sdk-go/internal/github.com/hyperledger/fabric/msp/configbuilder.go:23:2: cannot find package "gopkg.in/yaml.v2" in any of:
	/opt/go/src/gopkg.in/yaml.v2 (from $GOROOT)
	/opt/gopath/src/gopkg.in/yaml.v2 (from $GOPATH)
vendor/github.com/elastic/beats/libbeat/scripts/Makefile:107: recipe for target 'fabricbeat' failed
make: *** [fabricbeat] Error 1

when I access fabric-sdk-go directory, path is correct. Is there any path or value that I have to change in Makefile?

@lotty02cho see instructions here on building the agent on Ubuntu 16.04/18.04 or Mac OS X:
https://github.com/hyperledger-labs/blockchain-analyzer/blob/master/docs/Basic_setup.md#build-fabricbeat-agent

I see an error in the documentation in building the agent. It should be "make go-get" and not "make get-go"

@ashishxooa Thanks for the feedback. The error you get after using make go-get is probably caused by this line. Instead of vv0.8.0, it should be v0.8.0. Please try that, and let us know if it helps.

@balazsprehoda Hi yes, I saw that bug yesterday and corrected that. Even after doing that change issues.
go: finding github.com/go-kit/kit/sd latest
cd ../../../go-kit/kit/; git checkout tags/v0.8.0 -b v0.8.0
bash: line 0: cd: ../../../go-kit/kit/: No such file or directory
fatal: 'tags/v0.8.0' is not a commit and a branch 'v0.8.0' cannot be created from it
make: *** [go-get] Error 128

@balazsprehoda Hi yes, I saw that bug yesterday and corrected that. Even after doing that change issues.
go: finding github.com/go-kit/kit/sd latest
cd ../../../go-kit/kit/; git checkout tags/v0.8.0 -b v0.8.0
bash: line 0: cd: ../../../go-kit/kit/: No such file or directory
fatal: 'tags/v0.8.0' is not a commit and a branch 'v0.8.0' cannot be created from it
make: *** [go-get] Error 128

@ashishxooa @balazsprehoda @salmanbaset  I'm also facing the issue, not able to proceed further to get fabricbeat* in Kibana like said in Readme doc. :(

@ashishxooa @SwapnilEI @salmanbaset I tried to reproduce this error in a new Ubuntu 18.04 VM, but I found a few other issues instead :) I have submitted a PR to fix those. For this error, I would recommend to check if you can manually clone go-kit and check out v0.8.0. Sorry for the late answer.

@ashishxooa @salmanbaset @balazsprehoda Thanks for the reply and fixing that issue. But, now it gave new error as it could not find  protoutil. :(
Here is the error:
go get github.com/hyperledger/fabric/protoutil: module github.com/hyperledger/fabric@upgrade found (v1.4.4), but does not contain package github.com/hyperledger/fabric/protoutil
make: *** [go-get] Error 1
Also, @ashishxooa were you able to proceed further?

@lotty02cho @ashishxooa @SwapnilEI @salmanbaset I uploaded an executable built on Ubuntu 18.04 to my fork. I am going to upload another for Ubuntu 16.04 soon. After that, I am going to submit a PR. Until then, please take a look at this and see if it helps.

@swapnil-kogx I did delete everything and started everything from scratch and this time it worked. I use a mac so it got built on mac. trying now on Ubuntu 18.04 maybe @balazsprehoda fork will help.

@ashish235 @swapnil-kogx @ashishxooa We have released a Docker image of fabricbeat which makes deployment easier (you do not have to build it on your own machine). For details, see #37


Update google-cloud-datacatalog to 1.27.0

About this PR
📦 Updates com.google.cloud:google-cloud-datacatalog from 1.26.0 to 1.27.0
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.google.cloud", artifactId = "google-cloud-datacatalog" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "com.google.cloud", artifactId = "google-cloud-datacatalog" }
}]

labels: library-update, early-semver-minor, semver-spec-minor, commit-count:1

Superseded by #573.


Progress circle not working in node env

Because it uses requestAnimationFrame, it fails in Node (ex: app shell).   We probably need to think about how it's going to work in that context, given that it uses JS in animations now.

@josephperrott next time you're in 1055, we need to brainstorm a solution that will work in IE11 and server-side prerendering (may actually be impossible).

Hello all, i noticed this while running issue-zero. For what I could see in Angular Universal the way that this is usually made is via dependency injection?
It looks like what is being done there is that instead of using the browser API directly, a service gets injected with a given interface. The interface  might be implemented differently across environments. For example the angular universal cookies service -> https://github.com/angular/universal/issues/273
in the browser it uses cookies, on the server it will read from the current HTTP request header.
Or the HTTP service, in the browser it will use XMLHttpRequest, on the server it will trigger an HTTP route directly.  just mentioning this in the hope that it will avoid large refactorings in the future.

Tracking via #308


[Bug] The label of the pie chart will have ghosting when the position is' center '

Version
5.2.1
Link to Minimal Reproduction
https://echarts.apache.org/examples/zh/editor.html?c=pie-doughnut
Steps to Reproduce
Replace the linked option to reproduce it ：
option = {
  tooltip: {
    trigger: 'item'
  },
  legend: {
    top: '5%',
    left: 'center'
  },
  series: [
    {
      name: 'Access From',
      type: 'pie',
      radius: ['40%', '70%'],
      avoidLabelOverlap: true,
      label: {
        show: true,
        position: 'center',
        formatter: '123123213',
      },
      emphasis: {
        label: {
          show: true,
          fontSize: 40,
          fontWeight: 'bold'
        }
      },
      labelLine: {
        show: false
      },
      data: [
        { value: 1048, name: 'Search Engine' },
        { value: 735, name: 'Search Engine' },
        { value: 580, name: 'Search Engine' },
        { value: 484, name: 'Search Engine' },
        { value: 300, name: 'Search Engine' }
      ]
    }
  ]
};

Current Behavior
The label of the pie chart will have ghosting when the position is' center '
Expected Behavior
When the mouse moves into each area of the pie chart, the middle text has no ghosting
Environment
- OS: windows
- Browser: Chrome 96.0.4664.55
- Framework: Vue@3

Any additional comments?
No response

make label and emphasis.label identical except position, Demo


Container won't mount in Gmail due to undefined chrome.runtime

After typing '/giphy' and hitting space, the text disappears and the search prompt that shows up in github, etc doesn't show up.
https://www.dropbox.com/s/rxbyqqu8l0kg8k1/Screenshot 2016-02-22 11.12.35.png?dl=0

This issue magically disappeared.


Modify screenshot links for Iris.iOS

[x] Project URL:https://github.com/Neko3000/Iris.iOS
[x] Update contents.json instead of README
[x] One project per pull request
[x] Screenshot included
[x] Avoid iOS or open-source in description as it is assumed
[x] Use this commit title format if applicable: Add app-name by @github-username
[x] Use approved format for your entry

@Neko3000 thank you!


Disable Images

Hi -- amazing plugin!
I'm wondering if it's possible to simply ignore images in the doc -> markdown process. I'm writing an html (distill.pub) paper with interactive figures, and I have images of the figures in my google docs and real figures in my html paper. It's a bit of a weird use-case, but I'd love if it was possible!
Nick

@ncammarata:
It's kind of an edge case, but since we can't do much directly with images, it might be a good option. Would you want any kind of marker in the converted text, or just ignore the images and drawings completely?

Ignore completely but I don't think it's worth the code surface area of supporting my weird case

Closing this for now. I think @ncammarata forked and fixed it in their own version.Iif it becomes a greater need, we can reopen.


Mobile UX issues

Issue Summary
Google reporting mobiles errors including:

touch elements too close
content wider than the screen

Here is the link Google sent: https://support.google.com/webmasters/answer/9063469
Screenshot showing horizontal scrollbar

More cut off content

Footer menus cut off on my iPhone

iOS menus don't work
The dropdown menus do not dropdown on my iPhone when I touch them:

Ahhh, I didn't realize my "fix" yesterday removed the links from the mobile menu. Yikes

Code snippets are typically horizontally scrolled on mobile devices.


Support Behaviors

In a lambda:
(lambda :behavior type-name (binding..) body...)

in a global function:
(defbehavior func-name type-name (binding...) [docstring] body...)

in a method (only in the deftype)
(method-name (arg-type...) return-type [:behavior type-name] [assert-id])

in a typespec
(type-name (arg...) [:behavior type-name])

In a behavior, the self variable is mapped to the process register and has the type of the behavior.
Also some silly changes to TypeSpec.cpp to make it faster.

Pull Request Test Coverage Report for Build 998834885

217 of 306 (70.92%)  changed or added relevant lines in 14 files are covered.
4 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.0004%) to 68.997%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

goalc/compiler/compilation/Type.cpp
17
18
94.44%

goalc/compiler/compilation/Function.cpp
18
20
90.0%

common/type_system/TypeSpec.h
49
52
94.23%

decompiler/analysis/expression_build.cpp
1
4
25.0%

common/type_system/deftype.cpp
19
23
82.61%

decompiler/analysis/final_output.cpp
6
12
50.0%

common/type_system/TypeSystem.cpp
14
25
56.0%

decompiler/IR2/Env.cpp
4
18
22.22%

common/type_system/TypeSpec.cpp
24
45
53.33%

common/util/SmallVector.h
58
82
70.73%

Files with Coverage Reduction
New Missed Lines
%

common/type_system/TypeSystem.cpp
2
70.96%

decompiler/IR2/Env.cpp
2
60.99%

Totals

Change from base Build 997641364:
-0.0004%

Covered Lines:
37369

Relevant Lines:
54160

💛  - Coveralls


Fix shell scripts to pass shellcheck linter

In scripts/style/shellcheck_skip.txt we have a list of not linted files. The goal of this issue is to get them fixed to pass shellcheck. To run shellcheck use make shell-style. Ideally every PR should fix one file:

[ ] .github/workflows/scripts/patch-changelog.sh
[ ] deploy/common/deploy.sh
[ ] deploy/common/docker-auth.sh
[ ] deploy/common/k8sbased.sh
[ ] deploy/k8s/central.sh
[ ] deploy/k8s/deploy-local.sh
[ ] deploy/k8s/deploy.sh
[ ] deploy/k8s/sensor.sh
[ ] deploy/openshift/central.sh
[ ] deploy/openshift/deploy-local.sh
[ ] deploy/openshift/deploy.sh
[ ] deploy/openshift/sensor.sh
[ ] dev-tools/add-host-alias.sh
[ ] dev-tools/enable-hotreload.sh
[ ] dev-tools/helmdiff.sh
[ ] dev-tools/roxctl.sh
[ ] image/assets/docker-auth.sh
[ ] image/central-entrypoint.sh
[ ] image/postgres/scripts/docker-entrypoint.sh
[ ] image/rhel/create-bundle.sh
[ ] image/static-bin/start-central.sh
[ ] image/templates/common/ca-setup.sh
[ ] image/templates/common/delete-ca.sh
[ ] image/templates/common/port-forward.sh
[ ] image/templates/common/setup-central.sh
[ ] image/templates/common/setup-scanner.sh
[ ] image/templates/common/setup.sh
[ ] image/templates/sensor/kubernetes/delete-sensor.sh
[ ] image/templates/sensor/kubernetes/sensor.sh
[ ] image/templates/sensor/openshift/delete-sensor.sh
[ ] image/templates/sensor/openshift/sensor.sh
[ ] licenses/generate-license-wrapper.sh
[ ] local/expand-db.sh
[ ] operator/hack/common.sh
[ ] operator/hack/olm-operator-install.sh
[ ] operator/hack/olm-operator-upgrade.sh
[ ] operator/scripts/retry.sh
[ ] qa-tests-backend/local-test-example/step1-setup-macos.sh
[ ] qa-tests-backend/local-test-example/step2-install-acs.sh
[ ] qa-tests-backend/local-test-example/step3-run-qa-tests-backend.sh
[ ] qa-tests-backend/scripts/migrate_protos.sh
[ ] qa-tests-backend/test-images/fail-compliance/ssh/run-ssh.sh
[ ] qa-tests-backend/test-images/trigger-policy-violations/most/run-csh.sh
[ ] qa-tests-backend/test-images/trigger-policy-violations/most/trigger-violations.sh
[ ] release/scripts/vuln_check.sh
[ ] scale/chaos/deploy.sh
[ ] scale/dev/cluster.sh
[ ] scale/dev/launch_central.sh
[ ] scale/dev/launch_sensor.sh
[ ] scale/dev/run-many.sh
[ ] scale/launch_workload.sh
[ ] scale/mockcollector/launch_mock_collector.sh
[ ] scale/mocksensor/launch_mock_sensor.sh
[ ] scale/mocksensor/launch_multiple_mock_sensors.sh
[ ] scale/profiler/launch-profiler.sh
[ ] scale/profiler/port-forward.sh
[ ] scale/signatures/deploy.sh
[ ] scripts/certification/run.sh
[ ] scripts/check-debugger.sh
[ ] scripts/ci/bench-and-graph.sh
[ ] scripts/ci/collect-qa-service-logs.sh
[ ] scripts/ci/complianceoperator/create.sh
[ ] scripts/ci/deployment-minder.sh
[ ] scripts/ci/logcheck/check-restart-logs.sh
[ ] scripts/ci/logcheck/check.sh
[ ] scripts/ci/roxctl-publish/prepare.sh
[ ] scripts/ci/sensorbundle-label/list-resources.sh
[ ] scripts/connect-ui.sh
[ ] scripts/ensure_image.sh
[ ] scripts/grab-data-from-central.sh
[ ] scripts/k8s/cleanup.sh
[ ] scripts/k8s/get-lb-ip.sh
[ ] scripts/k8s/kill-pod.sh
[ ] scripts/k8s/local-port-forward.sh
[ ] scripts/mergeswag.sh
[ ] scripts/offline-bundle/image-bundle/import.sh
[ ] scripts/offline-bundle/image-collector-bundle/import.sh
[ ] scripts/port-forward-ui.sh
[ ] scripts/redhat-infra-release/generate-proto-sources.sh
[ ] scripts/redhat-infra-release/remove-non-operator-deps.sh
[ ] scripts/reference/build-quay-operator-bundles.sh
[ ] scripts/release-tools/clusters.sh
[ ] scripts/sync-release-branch.sh
[ ] tests/roxctl/authz-trace.sh
[ ] tests/roxctl/helm-chart-generation.sh
[ ] tests/roxctl/istio-support.sh
[ ] tests/roxctl/slim-collector.sh
[ ] tests/upgrade/postgres_run.sh
[ ] tests/yamls/roxctl_verification.sh
[ ] tools/check-service-protos/run.sh
[ ] tools/detect-large-files.sh
[ ] tools/fix-blanks.sh
[ ] tools/githooks/install-hooks.sh
[ ] ui/apps/platform/scripts/cypress.sh
[ ] ui/apps/platform/scripts/get-auth-token.sh
[ ] ui/apps/platform/scripts/get-demo-auth-token.sh

@janisz created PR to Fix shell check linter for deploy/common/deploy.sh
https://github.com/stackrox/stackrox/pull/3547/files

@janisz created PR to fix below listed files:
dev-tools/helmdiff.sh
scripts/k8s/cleanup.sh
scripts/k8s/get-lb-ip.sh
local/expand-db.sh

Created a PR for this issue -> https://github.com/stackrox/stackrox/pull/3578. Please review
Files updated are deploy/k8s/sensor.sh and deploy/k8s/central.sh.
@janisz Can you please approve the PR checks as well?

Created the PR for this issue -> #3582.
Files updated are deploy/k8s/deploy.sh and deploy/k8s/deploy-local.sh
@janisz, Please verify this and approve the PR checks too.

Created PR for this issue -> https://github.com/stackrox/stackrox/pull/8266
Files updated are deploy/openshift/deploy-local.sh
@janisz Please verify and approve the PR checks


Updating Arduino AVR Boards

I am using IDE 1.6.9....... And after updating Arduino AVR Boards to v. 1.6.12, I can no longer uplload to board.
Going back to v. 1.6.11 and it works again.
Tried this on Arduino Mega2560 and Nano. Same result.
Any idea?
i have just bought Arduino products from this site www.w11stop.com/ard-uino in pakistan...

Also posted at http://forum.arduino.cc/index.php?topic=468968.0

This is completely the wrong place to submit problems related to the Arduino IDE or Arduino AVR Boards.
You should always test using the latest versions before submitting a bug report. There is no point for submitting reports of bugs that were fixed 8 months ago.
We're already trying to help you on the forum. If you would have taken the time to respond instead of cross-posting we would already have your problem solved.


“Undefined” is not valid JSON (after upgrading dash-ag-grid)

Started receiving “Undefined is not valid JSON” after upgrading dash-ag-grid package from 2.0.0a1 to 2.0.0a3.  No code changes were made when upgrading.  AG Grid table no longer displays after the upgrade.

Can you share your code, or even better some pared down version that still shows the issue? There are some breaking changes between each alpha release so your code may not be expected to work without a change, but an error like that isn't very helpful so may point to a bug as well.

Partial Code below
defaultColDef = {
"resizable": True,
#"initialWidth": 200,
"wrapHeaderText": True,
"autoHeaderHeight": True,
}
scorecard_table_overview_new = dbc.Card(
children = [
dag.AgGrid(
id = 'scorecard-table',
className="ag-theme-alpine-dark",
columnSize="sizeToFit",
dashGridOptions={"pagination": True, "paginationPageSize": 15 },
defaultColDef=defaultColDef
)
]
)
@app.callback(
[Output("scorecard-table", "columnDefs"),
Output("scorecard-table", "rowData"),
],
[Input("cto-filter", "value"),
Input("scorecard-filter", "value")],
)
def update_table_content(cto_name, scorecard_filter):
if scorecard_filter == "monthlyscorecard":
if cto_name == "ALL":
scorecard_table = cto_scorecard_df.to_json(orient='records')
else:
scorecard_table = seal_scorecard_df[seal_scorecard_df['CTO'] == cto_name]
scorecard_table.drop(columns=['CTO'], axis=1, inplace=True)
scorecard_table.rename(columns={'App':'CTO'},inplace=True)
scorecard_table = scorecard_table.to_json(orient='records')
    score_card_columns= [
        { "headerName": "Name", "field": "CTO",
            "valueFormatter": {"function": "(params.value).toUpperCase();", "dangerously_allow_html": True},
            },
        { "headerName": "Monthly Potential Savings", "field": "Monthly savings", "filter": "agNumberColumnFilter", "valueFormatter":"Number(value).toFixed(2)", "dangerously_allow_html": True},
        { "headerName": "Current Month", "field": "2023-02", "valueFormatter": {"function": "'$' + (params.value)", "dangerously_allow_html": True},},
        { "headerName": "Previous Month", "field": "2023-01"},
        { "headerName": "Delta", "field": "diff"},
        ]

return [score_card_columns, json.loads(scorecard_table)]

Hello @esdesai,
Typically, you would use scorecard_table.to_dict('records') when sending rowData back to the table, no need to convert to JSON.
Could you please try this? Without data to test out, we cant very easily troubleshoot.

Hi, I also tried to_dict(‘records’) and received the same error.
It seems like the issue is with setting the score_card_columns inside the app.callback.   If i hardcode the columns outside of the callback, I do not get the error with the latest version.     Please advise on how we can pass both Data & Columns within the callback.

Closing, this was an intentional change between a1 and a3, the safe evaluation functionality we added requires you to wrap valueFormatter in {function: ...} rather than just send the string, so that we know to parse it ourselves rather than send the string to AG Grid to parse dangerously.


feat: add default keyboard focus style

Describe the changes you have made in this PR
Currently some elements such as buttons have an explicit keyboard focus style with an orange ring.
Other things like links fallback to the default (blue) styling that the browser gives.
I think we should set a default here that matches with the explicit defined styles and overall brand (using the primary color).
Screenshots of the changes [optional]
Before:

After:

Thanks for the PR!
I now see two different outlines: (orange + white)
![image](https://github.com/getAlby/lightning-browser-extension/assets/100827540/366b8f67-d4c8-4edd-90a7-eda5d247e881
Not sure if that is intentional?


Robotic audio when live stream is displayed on screens

This appears to be a kind of feedback or delay problem due to the audio on the live stream passing through the AV desk and thence to the sound desk, but slightly out of sync with the audio from the microphone.
Elliot Miller wrote today:

It seems that one of the sound desk's output destinations (likely the Livestream PC) is feeding audio back out again via the HDMI cable plugged into the Roland box (on the AV desk).

This audio signal continues on to the AV L and AV R sound desk inputs, somehow.

This morning, setting the Britney mic to +0dB and the AV inputs to -20dB reproduced the delay effect 🤖
(Turning the AV inputs up to +0dB produced the familiar, thundering feedback ⚡ effect.)

Luckily, the Roland V8 menu allows you to Mute any HDMI inputs it receives. We have muted #2 (and turned it down -70dB to make sure) and this has eliminated the delay 🤖 and the feedback ⚡.
After a test, these settings remain in place even after the Roland has been switched off at the wall, and back on again.

The photo below shows the Roland setting:

The schematic diagram below shows how the audio is split off from the Roland vision mixer (a V-8HD has replaced the V-40HD shown) HDMI programme output to be sent to the sound desk, using a Roland VC-1-DL video converter.

Note that a workaround is to temporarily mute the AV L and AV R channels on the sound desk. But hopefully muting input 2 on the Roland V-8HD will be a permanent solution.


Problem creating error document

I’m trying to create a document from a request which returns an empty response when the request succeeds but when there is an error it returns a HTTP 401 with the error in json. The problem is i’m not getting a document when the server returns a 401. It only returns a retrofit HttpException with a response with an error body at that moment.
The network call looks like this:
@POST("authenticate")
fun authenticate(): Single<Document<Void>>

The error body looks like this:
{
  "errors": [
    {
      "id": "",
      "status": "401",
      "code": "invalid_credentials",
      "title": "Authentication Failed",
      "detail": "Invalid credentials"
    }
  ]
}

Is there anything we are doing wrong? We are using retrofit with RxJava

Hi, this has nothing to do with this library in particular since this library is only for serializing and deserializing JSON.
It would be best if you managed this on the retrofit level while making the call. The retrofit will return Response<Document<T>>.
So you need to handle both when this Response (retrofit class) has data (deserialized class) or error (you need to handle).
Example utils functions to do so are below (modify them according to your needs). These are mapping the Retrofit Response to custom sealed class Result that can either be Success or Error.
fun <T> Response<Document<T>>.responseToResult(): Result<T> {
  if (isSuccessful) {
    // If data exists return success
    val data = body()?.data
    if (data != null) {
      return Result.Success(data)
    }

    // Data does not exist, check if this is a business logic error
    // but the successful response
    val errors = body()?.errors
    if (errors != null) {
      return Result.Error(ApiException(errors))
    }

    // If there is no data or error this is an invalid JsonAPI document
    return Result.Error(Exception("Invalid JsonAPI document. No data or errors!"))
  } else {
    // In case of non 2xx response errors can be present in Response.errorBody
    // but it is not parsed for us. Check if there are API errors and return
    // appropriate failure result with ApiException or default
    val errors = errorsOrNull()
    return if (errors != null) {
      Result.Error(ApiException(errors))
    } else {
      Result.Error(toException())
    }
  }
}

/**
 * Parse [List] of [Error] from Response.errorBody.
 * Returns `null` in case of exception.
 */
fun <T> Response<T>.errorsOrNull(): List<Error>? {
  val errorBodyString = this.errorBody()?.string() ?: return null
  try {
    val errors = errorsAdapter.fromJson(errorBodyString) ?: return null
    return errors
  } catch (e: Exception) {
    return null
  }
}

private val errorsAdapter = Moshi.Builder()....


Create a blackboard account (student and instructor)

@smccaffrey do you know if there is a way to create a blackboard account that is used for just this project? It would also be useful for testing (#25).

I created a blackboard and the relevant users have access, solving this issue.


[FEATURE REQUEST] Warn to download the correct addon version

Problem encountered
When downloading the plugin it's easy to download the Godot 3 version and get a little stuck on the problem because it's not clearly marked to go for the godot 4 branch.
A possible solution
Add a simple line in the installation instructions of the wiki to warn the newcomers their choose the correct version.
Alternative solution
Make the godot 4 branch the main one. I don't exactly know how much people are still on Godot 3 and their reason but with the time passing it should logically be replace by godot 4.
Additional context
Downloading godot 3 version on godot 4 give the following error:
Unable to load addon script from path: 'res://addons/http-sse-client/httpsseclient_plugin.gd'. This might be due to a code error in that script. Disabling the addon at 'res://addons/http-sse-client/plugin.cfg' to prevent further errors.

Good idea, will add that! And will comment here when I've done so and close this.

Okay, that was quick and easy. :P Put it right on the main page.


refactor: restore AttributeRemovedError for resp.body

The blocked resp.body property was introduced in #2090, and then removed later in the 4.0( cycle by oversight.
It is useful to have it, since otherwise setting resp.body in legacy code silently does nothing, and it is hard to understand what is going on.
Example when using swagger-ui-py (unfortunately, it needs to be updated):
2024-10-09 13:44:20 [FALCON] [ERROR] GET /api/doc => Traceback (most recent call last):
  File "<venv>/lib/python3.8/site-packages/falcon/app.py", line 440, in __call__
    responder(req, resp, **params)
  File "<venv>/lib/python3.8/site-packages/swagger_ui/handlers/falcon.py", line 19, in on_get
    resp.body = doc.doc_html
  File "<venv>/lib/python3.8/site-packages/falcon/response.py", line 221, in body
    raise AttributeRemovedError(
falcon.util.deprecation.AttributeRemovedError: The body attribute is no longer supported. Please use the text attribute instead.

(With 4.0.0b1, the page is completely blank, and nothing is logged on the server side either.)

The attribute was already deprecated in 3.x, but the AttributeRemovedError has never been part of a stable release.

I am going to disable the Firefox gate for now. I haven't found the reason yet, but I suspect something is not working correctly with geckodriver on Linux and the newest Firefox 131.0. I won't have the bandwidth to dig into this.
Locally, it works for me, but I cannot make the browser headless anymore, it always pops up. In the gate, 1/2 tests fail.


Updating error logging in ExecutableRunner

Coverage remained the same at 41.884% when pulling 96a3d46caa90a13e35718fa0332077a17334aa0d on ExecutableRunnerLogging into 1b375c6c6587a8180a73622fb644f3214b634d12 on master.


Fix css-class on mj-section

Logic for applying css-class has been fixed. Closes #35.
Also adds in a missing tbody in mj-column.

Thank you very much, well spotted.


fix(Haptics): hook up haptic profiles to Linked Alias Collection

The haptic profile lists have now been hooked up to the
LinkedAliasAssociationCollection properties so they can be
accessed as expected.

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

npm package (@latest dist-tag)
v1.1.1
GitHub release

Your semantic-release bot :package::rocket:


Setting hand="left" appears to have no effect on resulting threaded model

right = IsoThread(
    major_diameter=VF_thread_major_diameter,
    pitch=VF_thread_pitch,
    length=VF_inlet_thread_length,
    hand="right",
    external=True,
    end_finishes=("chamfer", "chamfer"),
    align=(
        bd.Align.CENTER,
        bd.Align.CENTER,
        bd.Align.MIN,
    ),
)
right.label = 'right'

left = IsoThread(
    major_diameter=VF_thread_major_diameter,
    pitch=VF_thread_pitch,
    length=VF_inlet_thread_length,
    hand="left",
    external=True,
    end_finishes=("chamfer", "chamfer"),
    align=(
        bd.Align.CENTER,
        bd.Align.CENTER,
        bd.Align.MAX,
    ),
)
left.label = 'left'

show(right,left)

Fixed with 8d9a6b47822e3f278e4a8ca7792e445799ec7651.

This problem was also related with an internal/external thread mix-up which is also fixed.


Refactor getAttendanceNumber to use aggregate queries instead of brute-force calculation

Overview
The function getAttendanceNumber in firebaseUtils.ts currently queries every signed-in user document in an event and counts how many have sign-in or sign-out times by iterating through each one. Not only does this waste computations due to the data not utilizing a firebase index, but reading each document individually is more expensive than simply using an aggregate query.
Aggregate query documentation can be found here

81db1789ec89238e111df7d0475bb2cd1e8183f8


Fix project projection bug

Here I revert the try to have generic CRUD methods. It is impossible to upsert, and require a lot of where clause for insert and update. And just make it slightly more readable.
The truth it that diesel is built in a way that discourages this by design. The current state of the code is how it is supposed to be used. If we want to spare some redundant code, we will have to generate code through macro. Totally doable, and a good use case for somebody who when to experiment with it.
The rest of the PR is a mix of:

renaming every projection repo to the insert, update, upsert naming convention
get rid of unnecessary checks of existence when receiving events that by design require the aggregate to exist
get rid of repositories methods that are never used
get rid of test that tests nothing but the fact that the code actually calls the methods he is calling (testing the entity implementation details rather that the entity logical behavior)

I tested to refresh the project projection locally with the dump DB. It worked. So I guess the bug that was present in staging is solved.

The current state of the code is how it is supposed to be used.

DO you have some links to explain what is the expected way of using diesel ?
because I have seen several ways to do the same thing: where to put the .filter(), diesel::update(table) vs table.update()...

we will have to generate code through macro

That is an excellent idea IMO. If we base our design of DB tables on a standard (like must have an ID, etc) we could generate all boilerplate code to perform simple CRUD operations on all our repositories.
Downside is that we would generate useless code sometimes, but as it is generated, I guess this is worth it


fix(migrations): split redis migrations into up and teardown

Summary
"UP" phase should only contain non-destructive operations. "TEARDOWN" (or "FINISH") phase should be used to change/delete data.

Checklist

[x] The Pull Request has tests
[x] A changelog file has been created under changelog/unreleased/kong or skip-changelog label added on PR if changelog is unnecessary. README.md
[x] N/A There is a user-facing docs PR against https://github.com/Kong/docs.konghq.com - PUT DOCS PR HERE

Issue reference

KAG-4419
https://github.com/Kong/kong/issues/12978

@nowNick @locao @hanshuebner @samugi, I do want to double check if this is re-entrant or not. I feel it is not.

+1 with @bungle . The up part seems ok to be executed multiple times but not after executing tearup. It will lose all the Redis setup. The commands need careful checks before it does the change. Please fix this and then backport it @nowNick.

BTW is it ok for new nodes to see the old fields in the config object? It will happen when the teardown is not done.

Just a quick through the code, this PR follows the official guideline to split update and add operations into up and teardown respectively.
However, it does not resolve the timeout issues reported here https://github.com/Kong/kong/issues/12978. It is quite common, nowadays, customers may have hundreds of rate-limiting instances.
Maybe, we should adopt @bungle 's suggestion on shorthand_fields like this https://github.com/Kong/kong/blob/49aa2332b219826410c46cf207c9bb31ce25785d/kong/plugins/session/schema.lua#L216.

However, it does not resolve the timeout issues reported here #12978. It is quite common, nowadays, customers may have hundreds of rate-limiting instances.

#12761 addresses the timeout issue in the sense that it makes the environment variable KONG_PG_TIMEOUT work in addition to the --db-timeout option.  It may be worthwhile to change the default database timeout for command line operations to a higher value.

Maybe, we should adopt @bungle 's suggestion on shorthand_fields like this
https://github.com/Kong/kong/blob/49aa2332b219826410c46cf207c9bb31ce25785d/kong/plugins/session/schema.lua#L216

Can you elaborate how shorthand_fields can help with the timeout issue?

Can you elaborate how shorthand_fields can help with the timeout issue?

@bungle explained:  We should generally avoid data migrations if possible as they are scary and failure prone.  In this case, the new version can work with the old configration values and shorthand_fields, so a data migration might not even be needed.

BTW is it ok for new nodes to see the old fields in the config object? It will happen when the teardown is not done.

It is perfectly fine. New nodes will remove unknown fields on read.

We should generally avoid data migrations if possible as they are scary and failure prone. In this case, the new version can work with the old configuration values and shorthand_fields, so a data migration might not even be needed.

Yes. This is a bit debatable. As some people feel that leaving old data in db is somekind of cruft that we need to get rid of, or that will cause some other problems. The old values will stay there only as long as entity is not saved, When entity issaved the old fields (and now unknown) are removed from (db). Meanwhile we can migrate them over to new fields (without even checking if new fields are there already, as I explained, they will be gone on save).
I also do agree that we need to get rid of this "cruft", but perhaps it is best done with major version. When we get rid of cruft like here in finish:
            UPDATE plugins
            SET config =
              config
                #- '{storage_config,redis,auth}'
                #- '{storage_config,redis,ssl_server_name}'
                #- '{storage_config,redis,scan_count}'
                #- '{storage_config,redis,namespace}'
            WHERE name = 'acme';

It is a destructive operation. Now only way to get back to older Kong version is to restore db. If we didn't do this at all, it would be just matter of switching version back. And it would work even if new fields already had data copied over, because again, old nodes remove unknown fields on read.

Migrations can go wrong in many unexpected ways. Especially data migrations. We have seen timeouts, processed get killed in a mid, network issues, postgres version issues (migration works on my machine, but not on customer version of pg), we have seen that we needed to rewrite migrations because of bugs and then we needed to somehow support also people who ran the buggy migration if possible etc.


Local storage static provisioner

This provisioner is still in development and not functional yet.  It is pending API and volume plugin changes (PRs kubernetes/kubernetes#44640 and kubernetes/kubernetes#44897).  But the unit tests are passing and I did deploy it on a cluster to make sure it starts up and runs.
This PR includes:

Basic controller
PV cache and informer
Volume discovery at a fixed directory
PV deletion
Deployment files
Project documentation

/assign @jsafrane @wongma7 @ddysher

overall lgtm, ddysher has pointed out stuff (populator) and most everything else is being tracked as TODO already.
Feel free to add build & test invocations to travis (it takes forever at the moment since it builds everything in this repo 1 by 1, but I am working on splitting it up)

I added some more commits to address review comments.

Generally LGTM, we can revisit this when API is finalized.
embarrassing...  how can I join the community?  @msau42 @wongma7

@msau42: GitHub didn't allow me to assign the following users: ddysher.

This is the criteria to be added as a member: https://github.com/kubernetes/community/blob/master/community-membership.md.  I don't know if it automatically does it, or someone needs to add you manually.  If you meet the member criteria, let me know and I can get someone to add you.

Thanks, I'll take a look.

I am not a kubernetes org member, kubernetes-incubator is distinct. I think for kubernetes-incubator we just find somebody with admin privileges and have them add us to the org as external-storage collaborators

Thanks for the heads up; not a priority right now, i'll ping folks if this is necessary.

I am not a kubernetes org member, kubernetes-incubator is distinct. I think for kubernetes-incubator we just find somebody with admin privileges and have them add us to the org as external-storage collaborators

lgtm after a very quck review

Last call for reviews, will merge shortly.

lgtm after a very quck review

Thanks guys!  I'll incorporate all the comments here into the next PR.  I just want to get a base change in so that others can start working on it too.


[BUG?] Interaction Interface and Chests

Depending on distance to chests you see or doesn't see them in Terminal
https://i.gyazo.com/26ab43231f4a73b8499a4de68c8404d0.gif

If you gona say that OK then why Crafting Table and ME Chests work with ANY distance?

That is how Minecraft handles their vanilla containers. The crafting table also as a max distance. It's just longer than chests. I can't really do anything about it sadly. There isn't any way of overriding it.


prefer tomli over toml

Per discussion in:
https://github.com/praiskup/argparse-manpage/commit/c9f0ff6912bb7af888a057f3b61dc3145fffd19f
Closes: https://github.com/praiskup/argparse-manpage/pull/92

Thank you!


Feature/3312 drawer footer api page

Fixes # BLUI-3312

Changes proposed in this Pull Request:

Added Drawer Footer api docs

Screenshots:

To Test:

yarn start:reactdev
Navigate to Drawer->Drawer Footer->API DOCS (tab)

Is it possible to style the table like Material Design's style?
https://brightlayer-ui-dev.github.io/patterns/tables#design-specifications

Should the <components> be styled like they are in the design or are there very specific places where they get highlighted in a code block?
Screenshot from current demo

Partial image from design file

@huayunh @daileytj Yes, we are going to style tables and components names in the markdown style story BLUI-3323


tracker: do not warn about missing takeActionRequest

In some situations, willTakeAction and/or didTakeAction may be published without prior takeActionRequest.
The widget should not warn about this.

Fixed on master (v1.6.0) and release-1.5.x (v1.5.3).


python310Packages.aenum: 3.1.11 -> 3.1.12

Description of changes

Things done

Built on platform(s)

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

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

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

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

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

[ ] Fits CONTRIBUTING.md.

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

10 packages failed to build:

python310Packages.awswrangler
python310Packages.awswrangler.dist
python311Packages.awswrangler
python311Packages.awswrangler.dist
python311Packages.cassandra-driver
python311Packages.cassandra-driver.dist
python311Packages.intellifire4py
python311Packages.intellifire4py.dist
python311Packages.vulcan-api
python311Packages.vulcan-api.dist

44 packages built:

csvkit
csvkit.dist
home-assistant-component-tests.homematicip_cloud
home-assistant-component-tests.intellifire
home-assistant-component-tests.vulcan
home-assistant-component-tests.wallbox
onlykey-agent
onlykey-agent.dist
onlykey-cli
onlykey-cli.dist
python310Packages.aenum
python310Packages.aenum.dist
python310Packages.agate-dbf
python310Packages.agate-dbf.dist
python310Packages.cassandra-driver
python310Packages.cassandra-driver.dist
python310Packages.dbf
python310Packages.dbf.dist
python310Packages.gremlinpython
python310Packages.gremlinpython.dist
python310Packages.homematicip
python310Packages.homematicip.dist
python310Packages.intellifire4py
python310Packages.intellifire4py.dist
python310Packages.okta
python310Packages.okta.dist
python310Packages.vulcan-api
python310Packages.vulcan-api.dist
python310Packages.wallbox
python310Packages.wallbox.dist
python311Packages.aenum
python311Packages.aenum.dist
python311Packages.agate-dbf
python311Packages.agate-dbf.dist
python311Packages.dbf
python311Packages.dbf.dist
python311Packages.gremlinpython
python311Packages.gremlinpython.dist
python311Packages.homematicip
python311Packages.homematicip.dist
python311Packages.okta
python311Packages.okta.dist
python311Packages.wallbox
python311Packages.wallbox.dist

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

2 packages marked as broken and skipped:

python311Packages.intellifire4py
python311Packages.intellifire4py.dist

4 packages failed to build:

python311Packages.cassandra-driver
python311Packages.cassandra-driver.dist
python311Packages.vulcan-api
python311Packages.vulcan-api.dist

48 packages built:

csvkit
csvkit.dist
home-assistant-component-tests.homematicip_cloud
home-assistant-component-tests.intellifire
home-assistant-component-tests.vulcan
home-assistant-component-tests.wallbox
onlykey-agent
onlykey-agent.dist
onlykey-cli
onlykey-cli.dist
python310Packages.aenum
python310Packages.aenum.dist
python310Packages.agate-dbf
python310Packages.agate-dbf.dist
python310Packages.awswrangler
python310Packages.awswrangler.dist
python310Packages.cassandra-driver
python310Packages.cassandra-driver.dist
python310Packages.dbf
python310Packages.dbf.dist
python310Packages.gremlinpython
python310Packages.gremlinpython.dist
python310Packages.homematicip
python310Packages.homematicip.dist
python310Packages.intellifire4py
python310Packages.intellifire4py.dist
python310Packages.okta
python310Packages.okta.dist
python310Packages.vulcan-api
python310Packages.vulcan-api.dist
python310Packages.wallbox
python310Packages.wallbox.dist
python311Packages.aenum
python311Packages.aenum.dist
python311Packages.agate-dbf
python311Packages.agate-dbf.dist
python311Packages.awswrangler
python311Packages.awswrangler.dist
python311Packages.dbf
python311Packages.dbf.dist
python311Packages.gremlinpython
python311Packages.gremlinpython.dist
python311Packages.homematicip
python311Packages.homematicip.dist
python311Packages.okta
python311Packages.okta.dist
python311Packages.wallbox
python311Packages.wallbox.dist

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

2 packages failed to build:

python311Packages.vulcan-api
python311Packages.vulcan-api.dist

50 packages built:

csvkit
csvkit.dist
home-assistant-component-tests.homematicip_cloud
home-assistant-component-tests.intellifire
home-assistant-component-tests.vulcan
home-assistant-component-tests.wallbox
onlykey-agent
onlykey-agent.dist
onlykey-cli
onlykey-cli.dist
python310Packages.aenum
python310Packages.aenum.dist
python310Packages.agate-dbf
python310Packages.agate-dbf.dist
python310Packages.awswrangler
python310Packages.awswrangler.dist
python310Packages.cassandra-driver
python310Packages.cassandra-driver.dist
python310Packages.dbf
python310Packages.dbf.dist
python310Packages.gremlinpython
python310Packages.gremlinpython.dist
python310Packages.homematicip
python310Packages.homematicip.dist
python310Packages.intellifire4py
python310Packages.intellifire4py.dist
python310Packages.okta
python310Packages.okta.dist
python310Packages.vulcan-api
python310Packages.vulcan-api.dist
python310Packages.wallbox
python310Packages.wallbox.dist
python311Packages.aenum
python311Packages.aenum.dist
python311Packages.agate-dbf
python311Packages.agate-dbf.dist
python311Packages.awswrangler
python311Packages.awswrangler.dist
python311Packages.cassandra-driver
python311Packages.cassandra-driver.dist
python311Packages.dbf
python311Packages.dbf.dist
python311Packages.gremlinpython
python311Packages.gremlinpython.dist
python311Packages.homematicip
python311Packages.homematicip.dist
python311Packages.okta
python311Packages.okta.dist
python311Packages.wallbox
python311Packages.wallbox.dist

I will deal with vulcan-api...not sure if it's a glitch.


it stil does not work

i've donewhat you asked.  i've even redownloaded it but it stil does not work.
i get the same error everytime right now

this is the code

btw: i will change my token.

i sometimes get this to

You'll keep getting the keyerror if you don't change your token. Get it again after changing your password, replace the token in the code with the new one and then try.
The latest error you posted seems like a unique one to you. Post the full Traceback (The error info starting from Traceback) to see where the error occurs.

Changed password, changed key, still there same error. On thé official pokecord catcher thé key works.

You have teamspeak? Maybe you can see yourself

TeamViewer*

Sorry, I cannot that level of assistance where I take control of your PC itself.
Also, I have noticed the obvious mistake there which everyone seems to be making.
It should be:
configs["token"] = "Insert token here"

Not:
configs["token"] = os.environ["Insert token here"]

UMG thanks it's working


Add English Translation

Add English translation to the site.
Mentioned in #7 .

We finished proofreading.
Now waiting for @MrWillCom to create pull request after final review.

Sorry to be a bit late, now this pr is ready for review. 🚀

🎉🎉

We are now able to show HN this🐶: https://news.ycombinator.com/newest


Document trait objects with auto traits

Basically, for any trait object Trait, Trait + Send and Trait + Send + Sync and related are also trait objects. Before Rust 1.23.0 this was only for Send and Sync, but now it's for any auto trait (e.g. UnwindSafe) too. But since auto traits are unstable/an implementation detail right now, just get a list of what they are.

Fixed by #184


Suggesting changes flow is not discoverable

Testing https://github.com/Microsoft/vscode/issues/64262
I think current Suggest changes was not the beset in the flow of review and not discoverable. As a reviewer I would

Open a file diff and start reviewing
I see there is a change needed, I would like to start editing the file inline
Do the changes and save it
I might look for an action in the diff editor, or may be in the title, or in the SCM view a primary action (not in context menu) to suggest these changes. I suppose changes I do in this review mode/branch is to always suggest, is not it? If so, this action has to be prominent rather hidden in context menu.

By the way is not this action can be called Suggest Changes instead of Suggest Edit?

+1 to this. I just tried to do it and had to go look at the PR to figure out how 🙈

I can't find how to suggest changes. 😢
What is the "proper" way of doing it?

I can't find how to suggest changes. 😢
What is the "proper" way of doing it?

+1

Closing in favor of supporting https://github.com/microsoft/vscode-pull-request-github/issues/603


[AMBARI-24523] Hive and Oozie JDBC url reset after set manually.

What changes were proposed in this pull request?
Don't allow recommendations to update config values which have been overriden by user. Also don't show them as a part of applied recommendations.
How was this patch tested?
21771 passing (24s)
48 pending

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/3721/
Test FAILed.
Test FAILured.

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/3722/
Test PASSed.


WIP: Add tls cert config (issue/52)

TODO

Create k8s secret to distribute certs. It wasn't clear to me yet whether to make this part of "Istio Manager" or "Istio Manager service".

Update proxy config generation to include certs. Assume that service port assignment is unique within the cluster  and only include listener ssl_context for non-local services. Otherwise, if service ports are reused, proxy listener expects TLS termination from local service.

What's the difference between istio manager and istio manager service ? Do you mean the proxy manager and the service that manages all proxies?
If so, it goes into the local proxy manager imo. And we pull the certificates from the secret store. So users are free to use same certificate across all services. For this to happen, we need to ask users to specify the secret names in the proxy container config. And this seems a bit clunky... any other alternatives?

Ignore my comment about difference between "Istio Manager" and "Istio Manager Service". I missed the spf13/cobra command inheritance and assumed that the rootCmd was a separate command (its not, its common between server and agent).
Agreed that asking user to manually specify secrets is clunky, but we have the same problem with the init-container and proxy injection. Short term I don't see an alternative if we want to distribute certs via k8s secrets. We could pre-process k8s yaml files on the client via some helper script before submitting to API server, but it's arguable whether this provides a better UX via manually updating the spec.
Longer term this problem could hopefully be addressed some combination Pod Injection Policy and Proposal: Extensible Admission Control,

cc @lookuptable

Please rebase your PR.


Wrong OpenSSL CMake targets used

Describe the bug
Hi,
while working on packaging the 1.11 version for Conan (conan-io/conan-center-index#22905) I noticed that compilation cannot find any OpenSSL headers. The Conan package manager fiddles with some CMake default lookup rules which might reveal the error.
This is for version 1.11.273: In your CMakeLists.txt in line 208 you include external_dependencies
https://github.com/aws/aws-sdk-cpp/blob/5929e202e9b1cd84d6234aa01b64f56fd2208350/CMakeLists.txt#L208
which does the OpenSSL crypto lib lookup and as part of that sets CRYPTO_LIBS to the imported target AWS::crypto:
https://github.com/aws/aws-sdk-cpp/blob/5929e202e9b1cd84d6234aa01b64f56fd2208350/cmake/external_dependencies.cmake#L40-L54
This is good because linking the CMake aws-cpp-sdk-all against the imported target later will apply both, the link libraries and the include dirs.
But in your CMakeLists.txt lines 250 you overwrite CRYPTO_LIBS with ${OPENSSL_LIBRARIES}.
https://github.com/aws/aws-sdk-cpp/blob/5929e202e9b1cd84d6234aa01b64f56fd2208350/CMakeLists.txt#L260-L266
The problem is that OPENSSL_LIBRARIES is empty and I also could not find any invocation of find_package(OpenSSL) which could have set it.
The same problem applies to CLIENT_LIBS.
Could you please take a look what's going on and which of the code blocks is the correct and desired one?
Expected Behavior
OpenSSL is properly used.
Current Behavior
[ 18%] Building CXX object src/aws-cpp-sdk-core/CMakeFiles/aws-cpp-sdk-core.dir/source/http/curl/CurlHttpClient.cpp.o
In file included from /Users/jenkins/w/prod-v2/bsr@2/98097/eacca/p/b/aws-s92c917073c641/b/build/Release/src/aws-cpp-sdk-core/ub_core.cpp:50:
In file included from /Users/jenkins/w/prod-v2/bsr@2/98097/eacca/p/b/aws-s92c917073c641/b/src/src/aws-cpp-sdk-core/source/utils/crypto/openssl/CryptoImpl.cpp:9:
/Users/jenkins/w/prod-v2/bsr@2/98097/eacca/p/b/aws-s92c917073c641/b/src/src/aws-cpp-sdk-core/include/aws/core/utils/crypto/openssl/CryptoImpl.h:12:10: fatal error: 'openssl/ossl_typ.h' file not found
#include <openssl/ossl_typ.h>
         ^~~~~~~~~~~~~~~~~~~~

Reproduction Steps
git clone https://github.com/gjasny/conan-center-index.git
git checkout aws-sdk-cpp/1.11.179
git reset --hard 026b203b4f46d6b637899e2b020cd41e914f9667

# install Conan 2
recipes/aws-sdk-cpp/conan create all/conanfile.py --version 1.11.179 --user local --channel local -pr:b=default -pr:h=default --build=missing

Possible Solution
I commented out the block which overwrites the discovered variables:
https://github.com/gjasny/conan-center-index/blob/6d49f275630c48a8f757b2ec0f58fe0ebb607b69/recipes/aws-sdk-cpp/all/patches/1.11.179-0002-fix-openssl-and-curl-lookup.patch#L1-L22
Additional Information/Context
No response
AWS CPP SDK version used
1.11.273
Compiler and Version used
Xcode 15
Operating System and version
macOS 14.3

Thanks for opening this issue. We are currently in the process of reworking our cmake build process.
I'm not sure that your possible solution will fit all use cases, but I wanted to make sure I understand your request. Are you suggested commenting out this entire block?
    #[[
    if (ENABLE_BCRYPT_ENCRYPTION)
        set(CRYPTO_LIBS Bcrypt)
        set(CRYPTO_LIBS_ABSTRACT_NAME Bcrypt)
    elseif (ENABLE_OPENSSL_ENCRYPTION)
        set(CRYPTO_LIBS ${OPENSSL_LIBRARIES} ${ZLIB_LIBRARIES})
        set(CRYPTO_LIBS_ABSTRACT_NAME crypto ssl z)
    endif ()

    if (ENABLE_CURL_CLIENT)
        set(CLIENT_LIBS ${CURL_LIBRARIES})
        set(CLIENT_LIBS_ABSTRACT_NAME curl)
    elseif (ENABLE_WINDOWS_CLIENT)
        if (USE_IXML_HTTP_REQUEST_2)
            set(CLIENT_LIBS msxml6 runtimeobject)
            set(CLIENT_LIBS_ABSTRACT_NAME msxml6 runtimeobject)
            if (BYPASS_DEFAULT_PROXY)
                list(APPEND CLIENT_LIBS winhttp)
                list(APPEND CLIENT_LIBS_ABSTRACT_NAME winhttp)
            endif ()
        else ()
            set(CLIENT_LIBS Wininet winhttp)
            set(CLIENT_LIBS_ABSTRACT_NAME Wininet winhttp)
        endif ()
    endif ()
    ]]

Any update on this issue. I have the same problem

Yes, this should be fixed with this patch. We updated this sdk to not depend on crypto directly, but rather use the common runtime's(aws-c-common) dependency on crypto. Updating this sdk to the latest version should fix any problems that you might be running into with this. If it doesn't fix it for you please open a new issue/discussion.


feat(build): track head and base ref for pr

summary
Adds the VELA_PULL_REQUEST_SOURCE and VELA_PULL_REQUEST_TARGET variables that match the base and head refs from go-github.
Starts the work to complete https://github.com/go-vela/community/issues/28.
value
Allows plugins/users to determine both branches involved in a given pull request.
Note: The failing reviewdog action is unrelated to my changes.

@JordanSussman thanks for your contribution! 🎉


man pages

Write/generate man pages for the helics_* executables and install them on Linux/Mac(/BSD).
It seems like man pages are typically written using GNU troff for typesetting, but there are converters for Markdown and other alternatives. It would be nice to be able to generate HTML pages from the same source as the man pages for including in RTD.

Some discussion in PR #662 on man pages being easier to read for detailed information on program usage than long help messages. Caveat is that not all platforms (Windows) support man pages.


downscope(examples): show credential downscoping with CAB

This push adds some examples showing how to downscope credentials using CredentialAccessBoundaries (documented here).  The added examples use the code stored here.

cc @bojeil-google

@codyoss can you rerun the snippet-bot?

cc @lsirac

Can you please refactor this a little so that it looks like https://github.com/GoogleCloudPlatform/java-docs-samples/pull/5803?
We shouldn't be hardcoding a bucket/object name. Also see how the tests are setup.


An explicit implemented IPackable causes MethodAccessException

I'm targeting Desktop .NET Framework 4.6.1 (4.5.0 also tested with same result), I have a class explicit implements IPackable and IUnpackable, but serialization causes MethodAccessException:
Attempt by method 'MsgPack.Serialization.EmittingSerializers.Generated.Tests_LiveDetailIdsSerializer1.UnpackFromCore(MsgPack.Unpacker)' to access method 'Tests.LiveDetailIds.MsgPack.IUnpackable.UnpackFromMessage(MsgPack.Unpacker)' failed.
I'm not familiar with .NET security, but seems the call to typeof( TObject ).GetInterfaceMap( typeof( IUnpackable ) ).TargetMethods.Single() at [SerializerBuilder`3.Object.cs L232](https://github.com/msgpack/msgpack-cli/blob/master/src/MsgPack/Serialization/AbstractSerializers/SerializerBuilder`3.Object.cs#L232) got a `NonPublic` method that needs to be fully trusted to call by generated assemblies.
I tried to replace that with typeof( IUnpackable ).GetMethod( "UnpackFromMessage" ) which returns a Public MethodInfo and can fix my issue.
Same to IPackable.
Another problem: when a class derived from List<T> implements IPackable and IUnpackable, MsgPack will serialize it as an array but ignore IPackable.

Thank you for reporting.

MethodAccessException should be caused because of lack of casting to the interface. This is a bug, so I'll fix it.
Currently, IPackable and IUnpackable only works types which do not implement IEnumerable. I think design change of this needs more consideration and discussion. Do you really have problem for this?

My class derived from List<T> and implemented IPackable/IUnpackable at the beginning, because the serialized object is a Map with numeric key so I want to convert it to a list. The result is MsgPack keeps throwing exceptions saying the stream doesn't contains an array, and I found that breakpoints inside UnpackFromMessage() are never hit, so I quickly realized the priority of List<T> is higher than IUnpackable and edited my class.
But I think it's unreasonable, IPackable/IUnpackable is a more advanced feature so when users implement them, they must want to override the default behavior, they want a list that is not a list, or an object that is not an object.

You are right. I'll support with compatibility switch as another issue for it.

This issue was fixed in 0.7.0-alpha3, so I've closed it.


IACD Test Fix

[x] This contribution adheres to CONTRIBUTING.md.

What does this Pull Request accomplish?

Refactoring for the committed tests. Fixes the issue with the intermittent failures on the ATS system.

Why should this Pull Request be merged?

Fixes the issue with the intermittent failures on the ATS system.

What testing has been done?

Testing has been done on a VM with the 2020 software stack installed + RT Pharlap Target

The two tests from below were validating that a Periodic Message was triggered after the set time has elapsed. The refactoring does not validate this anymore. As you can notice on both Block Diagrams of these test VIs we trigger "N" messages, but we read "N+1" in the "Expected Messages" array, as we are expecting to have one Periodic Message triggered. Also the content of the Periodic Message is not checked anymore.
From my point of view, we need to address this, as we may add a test gap using the proposed implementation.
* test_Periodic and Multiple Static Single Channel Command-Response Messages using Trigger with Protection.vi

* test_Periodic and Multiple Static Single Channel Command-Response messages using Trigger.vi

It was not obvious in any way, from the original test, that a periodical message is actually expected and checked (even though, indeed, the System Definition is actually configured with one). The way the content was being checked is completely fragile and it was actually leading to the test failures reported before. The idea would be to separate the tests for the triggered messages from the periodical one - which means creating a separate test only for the periodical message.

The two tests from below were validating that a Periodic Message was triggered after the set time has elapsed. The refactoring does not validate this anymore. As you can notice on both Block Diagrams of these test VIs we trigger "N" messages, but we read "N+1" in the "Expected Messages" array, as we are expecting to have one Periodic Message triggered. Also the content of the Periodic Message is not checked anymore.
From my point of view, we need to address this, as we may add a test gap using the proposed implementation.
* test_Periodic and Multiple Static Single Channel Command-Response Messages using Trigger with Protection.vi

* test_Periodic and Multiple Static Single Channel Command-Response messages using Trigger.vi

It was not obvious in any way, from the original test, that a periodical message is actually expected and checked (even though, indeed, the System Definition is actually configured with one). The way the content was being checked is completely fragile and it was actually leading to the test failures reported before. The idea would be to separate the tests for the triggered messages from the periodical one - which means creating a separate test only for the periodical message.

We already have a test for the Periodic Channel and Periodic Message. So that is covered.
As this two test names imply, they check that a Periodic Message is sent even if Multiple Static Single Channels Messages are Triggered without affecting the Periodicity.
We are here to improve the test logic, but also to keep the current code coverage as before, or improving it if we can.
I would like to not discard tests that test this scenario (sending multiple triggered messages with periodic messages in between them). I do not mind if we do this adding new tests, or try to improve the ones in this PR.

The two tests from below were validating that a Periodic Message was triggered after the set time has elapsed. The refactoring does not validate this anymore. As you can notice on both Block Diagrams of these test VIs we trigger "N" messages, but we read "N+1" in the "Expected Messages" array, as we are expecting to have one Periodic Message triggered. Also the content of the Periodic Message is not checked anymore.
From my point of view, we need to address this, as we may add a test gap using the proposed implementation.
* test_Periodic and Multiple Static Single Channel Command-Response Messages using Trigger with Protection.vi

* test_Periodic and Multiple Static Single Channel Command-Response messages using Trigger.vi

It was not obvious in any way, from the original test, that a periodical message is actually expected and checked (even though, indeed, the System Definition is actually configured with one). The way the content was being checked is completely fragile and it was actually leading to the test failures reported before. The idea would be to separate the tests for the triggered messages from the periodical one - which means creating a separate test only for the periodical message.

We already have a test for the Periodic Channel and Periodic Message. So that is covered.
As this two test names imply, they check that a Periodic Message is sent even if Multiple Static Single Channels Messages are Triggered without affecting the Periodicity.
We are here to improve the test logic, but also to keep the current code coverage as before, or improving it if we can.
I would like to not discard tests that test this scenario (sending multiple triggered messages with periodic messages in between them). I do not mind if we do this adding new tests, or try to improve the ones in this PR.

Ok ... than I think that this should have been explained in a comment, in the VI itself. The title of the VI was not very suggestive as to how the test was actually operating.

Ok ... than I think that this should have been explained in a comment, in the VI itself. The title of the VI was not very suggestive as to how the test was actually operating. The test, as it was, did not validate in anyway the periodicity of the message since it was checking if the periodic message was received only once ... and to be fair, the periodicity in this particular case could be checked only approximately. What the original tests were actually checking, was simply if the message was sent once, not in any way if it is periodic.

We should operate changes to code only when we fully understand the implications and ask if otherwise.
As you may know, we currently do not have an official guideline, so is at the developers willingness on how he decides to document the code if not requested explicitly in the task or US. You are free to add any additional info you think may help in the future.
As I explained before, this tests were checking if the periodicity of the message was affected by triggering other messages. The IA CD is made to run in tens of Hz frequency ranges, and we do not expect and also do not guarantee exact timings, as there are a lot of factors that can affect the timing like: the LabVIEW Version, Target Type, VeriStand System latency, VeriStand System size, the no of Instrument Addon Messages we send, the Protocol we use, etc.
So for this setup, the decision was to have 4 messages sent before getting the Periodic one. And that was what we were checking. And it seems was not the best approach for this particular tests.

Ok ... than I think that this should have been explained in a comment, in the VI itself. The title of the VI was not very suggestive as to how the test was actually operating. The test, as it was, did not validate in anyway the periodicity of the message since it was checking if the periodic message was received only once ... and to be fair, the periodicity in this particular case could be checked only approximately. What the original tests were actually checking, was simply if the message was sent once, not in any way if it is periodic.

We should operate changes to code only when we fully understand the implications and ask if otherwise.
As you may know, we currently do not have an official guideline, so is at the developers willingness on how he decides to document the code if not requested explicitly in the task or US. You are free to add any additional info you think may help in the future.
As I explained before, this tests were checking if the periodicity of the message was affected by triggering other messages. The IA CD is made to run in tens of Hz frequency ranges, and we do not expect and also do not guarantee exact timings, as there are a lot of factors that can affect the timing like: the LabVIEW Version, Target Type, VeriStand System latency, VeriStand System size, the no of Instrument Addon Messages we send, the Protocol we use, etc.
So for this setup, the decision was to have 4 messages sent before getting the Periodic one. And that was what we were checking. And it seems was not the best approach for this particular tests.

To your point - I made the changes in the code based on what I saw was done in the original code. The purpose of the PR is exactly to validate this kind of changes and solve questions if they appear, so I think there should be no issue with my understanding. Since the test did not validate in any way the periodicity ("periodicity" meaning in this case that the message is periodic) of the periodic message, again, since it was received only once during the original test, and combined with the lack of documentation, my conclusion was that it was simply not required or that it was a "by-product" of the test.

This test checks that the periodic message is sent, but it does not check if Triggering other messages affect the timing of the Periodic Message. We check the similar scenario in "test_Enable Periodic Message Channel.vi". So this test is redundant if it does not check the additional Triggering of other messages and if this affects the Periodic one.

This test checks that the periodic message is sent, but it does not check if Triggering other messages affect the timing of the Periodic Message. We check the similar scenario in "test_Enable Periodic Message Channel.vi". So this test is redundant if it does not check the additional Triggering of other messages and if this affects the Periodic one.

I was in the process of modifying this test based on your last comments.

This test checks that the periodic message is sent, but it does not check if Triggering other messages affect the timing of the Periodic Message. We check the similar scenario in "test_Enable Periodic Message Channel.vi". So this test is redundant if it does not check the additional Triggering of other messages and if this affects the Periodic one.

I was in the process of modifying this test based on your last comments.

Great! Thanks! Will wait for the diffs.

test_Multiple Periodic Command Message.vi
The 16 second interval is really close to the border, as we do not expect to have exact timing. So I consider we should send like 20 messages (aprox 18-20 seconds IA runtime) to make sure we get also the second message in a specified range.

1st periodic message ~8+ sec
2nd periodic message ~16+ sec
3rd periodic message ~ 24+ sec

So if we stick to a range around 19-21 seconds runtime, we can make sure we have the second periodic message, but the chances to get a third one, are pretty slim. The current setup having 16 seconds runtime may make this test intermittent, as we may not get the second periodic message.
Please add also a check using the "Check Message Occurrences.vi" to confirm that we get also the expected number of triggered messages having the below content.

I would also preferred to have a way of also checking the order in which we get the messages, but for this specific test, I do not think is required.

test_Multiple Periodic Command Message.vi
The 16 second interval is really close to the border, as we do not expect to have exact timing. So I suggest we should send 20 messages (aprox 18-20 seconds IA runtime) to make sure we get also the second message in the specified range.
* 1st periodic message ~8+ sec

* 2nd periodic message ~16+ sec

* 3rd periodic message ~ 24+ sec

So if we stick to a range around 19-21 seconds runtime, we can make sure we have the second periodic message, but know we should not get a third one. The current setup is having a 16 seconds aprox runtime and this may make the test intermittent, as we may not get the second periodic message.
Please add also a check using the "Check Message Occurrences.vi" to confirm that we get the expected number of triggered messages having the below content.

I would also preferred to have a way of checking the order in which we get the messages, but for this specific test, I do not think it makes any sense.

I think that the time is more than enough - each iteration of the "For Loop" takes much more than a second due to the execution time of the trigger-confirm function. Moreover, there are delays between when the deployment is finished and when the triggering execution starts. During the development and test phase for this VI, always, the first periodic message would arrive before the sixth triggered command - this gives an excess of 2 seconds of margin. I agree however with adding 2 more iterations to be on the safe side.
I will not add the extra testing for the triggered messages - this is not the purpose of this test, additionally it would be redundant since we have dedicated tests for this behavior, for these specific channels.

I agree however with adding 2 more iterations to be on the safe side.
👍

I will not add the extra testing for the triggered messages - this is not the purpose of this test, additionally it would be redundant since we have dedicated tests for this behavior, for these specific channels.
I do not think the additional check is redundant, as the purpose of this test is to make sure that this messages work together independent on what trigger is used (trigger channel, periodic). So that's why I think we should check we have the expected number and content for both received message types. Only then we can guarantee they work as expected.

The additional check implementation is trivial, and should not require a lot of extra work, as you already have the VIs needed to do this.
Thanks!

The highlighted comment is not valid anymore, as we now check only a specific message content and no of occurrences.

I agree however with adding 2 more iterations to be on the safe side.

👍

I will not add the extra testing for the triggered messages - this is not the purpose of this test, additionally it would be redundant since we have dedicated tests for this behavior, for these specific channels.

I do not think the additional check is redundant, as the purpose of this test is to make sure that this messages work together independent on what trigger is used (trigger channel, periodic). So that's why I think we should check we have the expected number and content for both received message types. Only then we can guarantee they work as expected.
The additional check implementation is trivial, and should not require a lot of extra work, as you already have the VIs needed to do this.
Thanks!

We have already a test that validates that the triggered command messages are actually being sent. Would it be possible for you to explain why this extra measure of certainty is required for this test ?

We have already a test that validates that the triggered command messages are actually being sent, and implicitly that this functionality works as expected - verified. Why is it not enough ? Would it be possible for you to explain why this extra measure of certainty is required for this test ?

As I explained in previous messages is that this test needs to validate that triggering a message does not affect a periodic one. But that goes both ways. So, if a periodic message was triggered, we want to make sure the triggered one still works fine.
Basically, we want to make sure a triggered and a periodic message work ok together. That's why we need to check both.

We have already a test that validates that the triggered command messages are actually being sent, and implicitly that this functionality works as expected - verified. Why is it not enough ? Would it be possible for you to explain why this extra measure of certainty is required for this test ?

As I explained in a previous message is that this test needs to validate that triggering a message does not affect a periodic one. But that goes both ways. So, if a periodic message was triggered, we want to make sure the triggered one still works fine.
Basically, we want to make sure a triggered and a periodic message work ok together. That's why we need to check both.

The periodic message is enabled default in the system definition - this means that periodic messages are being sent, once the deployment is complete, for all of the tests. This also means that periodic messages are being sent anyways during the execution of the tests for the triggered command messages - so I would imagine that this aspect is also covered by the other dedicated tests. Or you think that this is not the case ?

We have already a test that validates that the triggered command messages are actually being sent, and implicitly that this functionality works as expected - verified. Why is it not enough ? Would it be possible for you to explain why this extra measure of certainty is required for this test ?

As I explained in a previous message is that this test needs to validate that triggering a message does not affect a periodic one. But that goes both ways. So, if a periodic message was triggered, we want to make sure the triggered one still works fine.
Basically, we want to make sure a triggered and a periodic message work ok together. That's why we need to check both.

Thank you for the explanation. I would like to point out that the periodic message is enabled by default in the system definition - this means that periodic messages are being sent, once the deployment is complete, for all of the tests. This also means that periodic messages are being sent anyways during the execution of the tests for the triggered command messages - so I would imagine that this aspect is also covered by the other dedicated tests. Or you think that this is not the case ?

You are right, the fact that the periodic message is generated is covered as a side topic in other tests. But there is no dedicated test that actually checks if the periodicity is correct, or if the number of expected periodic messages are generated in a defined timeframe.

We have already a test that validates that the triggered command messages are actually being sent, and implicitly that this functionality works as expected - verified. Why is it not enough ? Would it be possible for you to explain why this extra measure of certainty is required for this test ?

As I explained in a previous message is that this test needs to validate that triggering a message does not affect a periodic one. But that goes both ways. So, if a periodic message was triggered, we want to make sure the triggered one still works fine.
Basically, we want to make sure a triggered and a periodic message work ok together. That's why we need to check both.

Thank you for the explanation. I would like to point out that the periodic message is enabled by default in the system definition - this means that periodic messages are being sent, once the deployment is complete, for all of the tests. This also means that periodic messages are being sent anyways during the execution of the tests for the triggered command messages - so I would imagine that this aspect is also covered by the other dedicated tests. Or you think that this is not the case ?

You are right, the fact that the periodic message is generated is covered as a side topic in other tests. But there is no dedicated test that actually checks if the periodicity is correct, or if the number of expected periodic messages are generated in a defined timeframe.

I think that it would benefit us to clarify things a little bit. This is a dedicated test (test_Multiple Periodic Command Message.vi) that verifies that a periodic message is being generated, checks it's period (approximately of course) and that it works even if we are triggering additional command messages. I am not sure what do you mean exactly when you are saying " testing the periodicity", but assuming that you mean testing that the target command message is generated periodically - than this test does exactly that.
Additionally, since we have tests that trigger multiple command messages, while the periodic command message is enabled (by default in the system definition), it means that we are testing also that a triggered command message can execute while a periodical command message is also running.  Would it be possible for you to point out what aspect exactly you think is missing ? Thank you.

I think that it would benefit us to clarify things a little bit. This is a dedicated test (test_Multiple Periodic Command Message.vi) that verifies that a periodic message is being generated, checks it's period (approximately of course) and that it works even if we are triggering additional command messages. I am not sure what do you mean exactly when you are saying " testing the periodicity", but assuming that you mean testing that the target command message is generated periodically - than this test does exactly that.

Yes, I agree with you on the above summary regarding the current implementation of the test. And I agree that the current implementation of the test is validating the periodicity of the message in the expected runtime.
Testing the periodicity = testing the tendency of the periodic message to recur at intervals as per the term definition.

Additionally, since we have tests that trigger multiple command messages, while the periodic command message is enabled (by default in the system definition), it means that we are testing also that a triggered command message can execute while a periodical command message is also running. Would it be possible for you to point out what aspect exactly you think is missing ? Thank you.

In previous tests we just check if we get a periodic message, but just as a side effect of the periodic message being enabled by default.
So, long story short, if this test will have also a check that the number and content of the triggered message is as we expect, only then we can say for sure that the Messages work independently with no influence from the trigger type.

I think that it would benefit us to clarify things a little bit. This is a dedicated test (test_Multiple Periodic Command Message.vi) that verifies that a periodic message is being generated, checks it's period (approximately of course) and that it works even if we are triggering additional command messages. I am not sure what do you mean exactly when you are saying " testing the periodicity", but assuming that you mean testing that the target command message is generated periodically - than this test does exactly that.

Yes, I agree with you on the above summary regarding the current implementation of the test. And I agree that the current implementation of the test is validating the periodicity of the message in the expected runtime.
Testing the periodicity = testing the tendency of the periodic message to recur at intervals as per the term definition.

Additionally, since we have tests that trigger multiple command messages, while the periodic command message is enabled (by default in the system definition), it means that we are testing also that a triggered command message can execute while a periodical command message is also running. Would it be possible for you to point out what aspect exactly you think is missing ? Thank you.

In previous tests we just check if we get a periodic message, but just as a side effect of the periodic message being enabled by default.
So, long story short, if this test will have also a check that the number and content of the triggered message that is triggered by the Trigger Channel is as we expect, only then we can say for sure that the Messages work independently with no influence from the trigger type used.
Thanks!

Thank you for the reply. I don't see how this last comment, or paragraph is an argument - it seems to be reiterating the request for change. At the same time, I also believe that it does not make too much sense to continue this discussion. If you deem it necessary, I will apply this modification.

I think that it would benefit us to clarify things a little bit. This is a dedicated test (test_Multiple Periodic Command Message.vi) that verifies that a periodic message is being generated, checks it's period (approximately of course) and that it works even if we are triggering additional command messages. I am not sure what do you mean exactly when you are saying " testing the periodicity", but assuming that you mean testing that the target command message is generated periodically - than this test does exactly that.

Yes, I agree with you on the above summary regarding the current implementation of the test. And I agree that the current implementation of the test is validating the periodicity of the message in the expected runtime.
Testing the periodicity = testing the tendency of the periodic message to recur at intervals as per the term definition.

Additionally, since we have tests that trigger multiple command messages, while the periodic command message is enabled (by default in the system definition), it means that we are testing also that a triggered command message can execute while a periodical command message is also running. Would it be possible for you to point out what aspect exactly you think is missing ? Thank you.

In previous tests we just check if we get a periodic message, but just as a side effect of the periodic message being enabled by default.
So, long story short, if this test will have also a check that the number and content of the triggered message that is triggered by the Trigger Channel is as we expect, only then we can say for sure that the Messages work independently with no influence from the trigger type used.
Thanks!

Thank you for the reply. I don't see how this last comment, or paragraph is an argument - it seems to be reiterating the request for change. At the same time, I also believe that it does not make too much sense to continue this discussion. If you deem it necessary, I will apply this modification.

I think that it would benefit us to clarify things a little bit. This is a dedicated test (test_Multiple Periodic Command Message.vi) that verifies that a periodic message is being generated, checks it's period (approximately of course) and that it works even if we are triggering additional command messages. I am not sure what do you mean exactly when you are saying " testing the periodicity", but assuming that you mean testing that the target command message is generated periodically - than this test does exactly that.

Yes, I agree with you on the above summary regarding the current implementation of the test. And I agree that the current implementation of the test is validating the periodicity of the message in the expected runtime.
Testing the periodicity = testing the tendency of the periodic message to recur at intervals as per the term definition.

Additionally, since we have tests that trigger multiple command messages, while the periodic command message is enabled (by default in the system definition), it means that we are testing also that a triggered command message can execute while a periodical command message is also running. Would it be possible for you to point out what aspect exactly you think is missing ? Thank you.

In previous tests we just check if we get a periodic message, but just as a side effect of the periodic message being enabled by default.
So, long story short, if this test will have also a check that the number and content of the triggered message that is triggered by the Trigger Channel is as we expect, only then we can say for sure that the Messages work independently with no influence from the trigger type used.
Thanks!

Thank you for the reply. I don't see how this last comment, or paragraph is an argument - it seems to be reiterating the request for change. At the same time, I also believe that it does not make too much sense to continue this discussion. If you deem it necessary, I will apply this modification.

Yes, I consider it necessary for validating both message types work together as expected.
Thanks!


python3Packages.notmuch2: fix build

folder name became incorrect with notmuch update

Motivation for this change
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
[ ] macOS
[ ] 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"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Relase notes)

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

[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 132829 at 3346e0af run on aarch64-linux 1

2 packages built successfully:

python38Packages.notmuch2
python39Packages.notmuch2

1 suggestion:

warning: unclear-gpl
gpl3 is a deprecated license, please check if project uses gpl3Plus or gpl3Only and change meta.license accordingly.
Near pkgs/development/python-modules/notmuch/2.nix:24:5:
   |
24 |     license = licenses.gpl3;
   |     ^


Disable eBPF on AWS

Solves #378, sadly amazon linux kernel don't seem to be new enough to use eBPF but the pre-built kernel should work just fine.

The container starts if docker is disabled but it dosen't give me all the data that I want. It's unable to pinpoint the container image that is used to perform the call and thus any of our ignore image rules get's ignored.


Randomly failure to save file.

Type: Bug
Unfortunately it seems completely random. But the file remains unsaved randomly, with the white dot indicator in the file tab indicating it can't be saved. Ctrl + S doesn't work. Right click + save doesn't work. Restarting only sometimes fixes it.

Please follow steps from bot below to see if you can reproduce error in different setups.

Please diagnose the root cause of the issue by running the command F1 > Help: Troubleshoot Issue and following the instructions. Once you have done that, please update the issue with the results.
Happy Coding!

I wonder if this issue is being caused by an installed extension. Can you try to run VS Code without extensions? From the command line (NOT the integrated terminal in Code), execute: code --disable-extensions and try your steps again to see if it reproduces. If you see it is an issue with the extension, please file it against the extension repository itself.

Same on Mac OS, command + s is always not working
Version: 1.89.1 (Universal)
Commit: dc96b837cf6bb4af9cd736aa3af08cf8279f7685
Date: 2024-05-07T05:14:24.611Z
Electron: 28.2.8
ElectronBuildId: 27744544
Chromium: 120.0.6099.291
Node.js: 18.18.2
V8: 12.0.267.19-electron.0
OS: Darwin arm64 23.4.0

https://github.com/microsoft/vscode/issues/212943#issuecomment-2120917304

I haven't yet been able to repro without extensions.
When I launch without extensions, it works. But then when I launch back into my IDE with extensions, it also works.
It is at some random time later my IDE begins to not be able to save new files. I'll continue trying every now and then.

👍

For my use case, I'm pretty sure I narrowed it down to this extension:
https://marketplace.visualstudio.com/items?itemName=isudox.vscode-jetbrains-keybindings
I manually bisected, and I went back and forth with this extension ~5 times and successfully reproed 5 times in a row.

This issue is caused by an extension, please file it with the repository (or contact) the extension has linked in its overview in VS Code or the marketplace for VS Code. See also our issue reporting guidelines. If you don't know which extension is causing the problem, you can run Help: Start extension bisect from the command palette (F1) to help identify the problem extension.
Happy Coding!