Experimenting with Jeepney Trio backend

Copy/paste the blocking backend, scatter some async and await around, and it basically seems to work. :-)
Tests equivalent to the blocking backend, using pytest-trio to help write tests with Trio.
This doesn't yet know about async methods on the objects, though I don't think it would be hard to add. I think the backends could also share some code, in particular the bits of _handle_msg that deal with looking up the method and validating the signature. But I wanted to do it the easy way first before getting clever.
I'm not really asking you to merge this as is, it's more for discussion at the moment.

Extra thought: once it supports async handler methods, it's also conceivable that you'd want multiple tasks handling messages from the same D-Bus connection. I think this should mostly work with several tasks calling await server.listen() on the same server object, but there might be some wrinkles with the auto-reset functionality.

About support for async methods in objects, I think we just need to make DBusSignature unwrap the possible typing.Awaitable type in from_return and then the backend implementations should be able to use inspect.iscoroutinefunction() to see if they should call the method in async context or not.

I think we should keep this in dbus_objects.integration.jeepney. This was what I originally had in mind, hence the BlockingDBusServer and not DBusServer, and it would make it easier to refactor out the Jeepney specific code into a base class.

I wondered if that was what you were going for, but that means you would need trio installed in order to import the combined module, which doesn't seem right. Unless you prefer to hide all of the trio & jeepney.io.trio imports inside the methods that use them?

I was thinking of having a soft-fail global import and raising an exception in __init__ if the module is not available.

@takluyver sorry for bothering, it seems the tests are failing with trio.TooSlowError (they also fail without my refactoring commit), do you have any idea why?

Not sure. Does it come back if you put the yield back in the jeepney_trio_one_time_server fixture?

Testing locally, when I run only this test (dbus-run-session pytest tests/ -k 'test_listen and trio'), it consistently passes. When I run it along with the blocking test_listen (dbus-run-session pytest tests/ -k 'test_listen and trio'), it usually (but not always) fails. So it seems to be some interaction between the tests or their fixtures.
I wonder if when a process exits, there's a small delay before the bus daemon unregisters its connection and lets another connection take the name, so the test message for trio is getting routed to the defunct server for the blocking test. Maybe closing the connection explicitly before the process exits would help. It might also be a good idea to check the return value from calling RequestName (docs).

I did notice that too. I tried using a different name and is still the same.
I added a few debug messages and registered the example tracer (https://trio.readthedocs.io/en/latest/tutorial.html#task-switching-illustrated) and I get the following output. Doesn't seem pytest-trio is running the listen task.
### task scheduled: <fixture 'jeepney_trio_server'>
<<< task step finished: <fixture 'jeepney_trio_server'>
>>> about to run one step of task: <fixture 'jeepney_trio_router'>
### task scheduled: <fixture 'jeepney_trio_router'>
<<< task step finished: <fixture 'jeepney_trio_router'>
### doing a quick check for I/O
### finished I/O check (took 9.67600499279797e-06 seconds)
>>> about to run one step of task: <fixture 'jeepney_trio_server'>
### task scheduled: <fixture 'jeepney_trio_server'>
<<< task step finished: <fixture 'jeepney_trio_server'>
>>> about to run one step of task: <fixture 'jeepney_trio_router'>
### task scheduled: <fixture 'jeepney_trio_router'>
<<< task step finished: <fixture 'jeepney_trio_router'>
### doing a quick check for I/O
### finished I/O check (took 7.86097371019423e-06 seconds)
>>> about to run one step of task: <fixture 'jeepney_trio_router'>
### task scheduled: <fixture 'jeepney_trio_router'>
<<< task step finished: <fixture 'jeepney_trio_router'>
>>> about to run one step of task: <fixture 'jeepney_trio_server'>
### task scheduled: <fixture 'jeepney_trio_server'>
<<< task step finished: <fixture 'jeepney_trio_server'>
### doing a quick check for I/O
### finished I/O check (took 7.84100848250091e-06 seconds)
>>> about to run one step of task: <fixture 'jeepney_trio_router'>
### new task spawned: jeepney.io.trio.DBusRouter._sender
### task scheduled: jeepney.io.trio.DBusRouter._sender
<<< task step finished: <fixture 'jeepney_trio_router'>
>>> about to run one step of task: <fixture 'jeepney_trio_server'>
### task scheduled: <fixture 'jeepney_trio_server'>
<<< task step finished: <fixture 'jeepney_trio_server'>
### doing a quick check for I/O
### finished I/O check (took 7.924973033368587e-06 seconds)
>>> about to run one step of task: <fixture 'jeepney_trio_server'>
### new task spawned: jeepney.io.trio.DBusRouter._sender
### task scheduled: jeepney.io.trio.DBusRouter._sender
<<< task step finished: <fixture 'jeepney_trio_server'>
>>> about to run one step of task: jeepney.io.trio.DBusRouter._sender
### task scheduled: <fixture 'jeepney_trio_router'>
<<< task step finished: jeepney.io.trio.DBusRouter._sender
### doing a quick check for I/O
### finished I/O check (took 7.601018296554685e-06 seconds)
>>> about to run one step of task: <fixture 'jeepney_trio_router'>
### new task spawned: jeepney.io.trio.DBusRouter._receiver
### task scheduled: jeepney.io.trio.DBusRouter._receiver
<<< task step finished: <fixture 'jeepney_trio_router'>
>>> about to run one step of task: jeepney.io.trio.DBusRouter._sender
### task scheduled: <fixture 'jeepney_trio_server'>
<<< task step finished: jeepney.io.trio.DBusRouter._sender
### doing a quick check for I/O
### finished I/O check (took 7.488008122891188e-06 seconds)
>>> about to run one step of task: jeepney.io.trio.DBusRouter._receiver
### task scheduled: <fixture 'jeepney_trio_router'>
<<< task step finished: jeepney.io.trio.DBusRouter._receiver
>>> about to run one step of task: <fixture 'jeepney_trio_server'>
### new task spawned: jeepney.io.trio.DBusRouter._receiver
### task scheduled: jeepney.io.trio.DBusRouter._receiver
<<< task step finished: <fixture 'jeepney_trio_server'>
### doing a quick check for I/O
### finished I/O check (took 7.658964022994041e-06 seconds)
>>> about to run one step of task: jeepney.io.trio.DBusRouter._receiver
### task scheduled: <fixture 'jeepney_trio_server'>
<<< task step finished: jeepney.io.trio.DBusRouter._receiver
>>> about to run one step of task: <fixture 'jeepney_trio_router'>
### task scheduled: jeepney.io.trio.DBusRouter._sender
### task scheduled: <fixture 'jeepney_trio_router'>
<<< task step finished: <fixture 'jeepney_trio_router'>
### doing a quick check for I/O
### finished I/O check (took 7.7290169429034e-06 seconds)
>>> about to run one step of task: <fixture 'jeepney_trio_server'>
### task scheduled: jeepney.io.trio.DBusRouter._sender
### task scheduled: <fixture 'jeepney_trio_server'>
<<< task step finished: <fixture 'jeepney_trio_server'>
>>> about to run one step of task: jeepney.io.trio.DBusRouter._sender
### task scheduled: jeepney.io.trio.DBusRouter._sender
<<< task step finished: jeepney.io.trio.DBusRouter._sender
>>> about to run one step of task: <fixture 'jeepney_trio_router'>
<<< task step finished: <fixture 'jeepney_trio_router'>
### doing a quick check for I/O
### finished I/O check (took 7.681024726480246e-06 seconds)
>>> about to run one step of task: jeepney.io.trio.DBusRouter._sender
### task scheduled: jeepney.io.trio.DBusRouter._sender
<<< task step finished: jeepney.io.trio.DBusRouter._sender
>>> about to run one step of task: <fixture 'jeepney_trio_server'>
<<< task step finished: <fixture 'jeepney_trio_server'>
>>> about to run one step of task: jeepney.io.trio.DBusRouter._sender
### task scheduled: jeepney.io.trio.DBusRouter._sender
<<< task step finished: jeepney.io.trio.DBusRouter._sender
### doing a quick check for I/O
### finished I/O check (took 1.259200507774949e-05 seconds)
>>> about to run one step of task: jeepney.io.trio.DBusRouter._sender
### task scheduled: jeepney.io.trio.DBusRouter._sender
<<< task step finished: jeepney.io.trio.DBusRouter._sender
>>> about to run one step of task: jeepney.io.trio.DBusRouter._sender
<<< task step finished: jeepney.io.trio.DBusRouter._sender
### doing a quick check for I/O
### task scheduled: jeepney.io.trio.DBusRouter._receiver
### finished I/O check (took 2.328603295609355e-05 seconds)
>>> about to run one step of task: jeepney.io.trio.DBusRouter._receiver
### task scheduled: <fixture 'jeepney_trio_router'>
<<< task step finished: jeepney.io.trio.DBusRouter._receiver
>>> about to run one step of task: jeepney.io.trio.DBusRouter._sender
<<< task step finished: jeepney.io.trio.DBusRouter._sender
### doing a quick check for I/O
### task scheduled: jeepney.io.trio.DBusRouter._receiver
### finished I/O check (took 3.1830015359446406e-05 seconds)
>>> about to run one step of task: jeepney.io.trio.DBusRouter._receiver
### task scheduled: <fixture 'jeepney_trio_server'>
<<< task step finished: jeepney.io.trio.DBusRouter._receiver
>>> about to run one step of task: <fixture 'jeepney_trio_router'>
### task scheduled: jeepney.io.trio.DBusRouter._sender
### task scheduled: <fixture 'jeepney_trio_router'>
<<< task step finished: <fixture 'jeepney_trio_router'>
### doing a quick check for I/O
### finished I/O check (took 1.0684016160666943e-05 seconds)
>>> about to run one step of task: <fixture 'jeepney_trio_server'>
### task scheduled: jeepney.io.trio.DBusRouter._sender
### task scheduled: <fixture 'jeepney_trio_server'>
<<< task step finished: <fixture 'jeepney_trio_server'>
>>> about to run one step of task: jeepney.io.trio.DBusRouter._sender
### task scheduled: jeepney.io.trio.DBusRouter._sender
<<< task step finished: jeepney.io.trio.DBusRouter._sender
>>> about to run one step of task: <fixture 'jeepney_trio_router'>
### task scheduled: jeepney.io.trio.DBusRouter._receiver
### task scheduled: <fixture 'jeepney_trio_router'>
<<< task step finished: <fixture 'jeepney_trio_router'>
### doing a quick check for I/O
### finished I/O check (took 1.0647985618561506e-05 seconds)
>>> about to run one step of task: <fixture 'jeepney_trio_router'>
<<< task step finished: <fixture 'jeepney_trio_router'>
>>> about to run one step of task: jeepney.io.trio.DBusRouter._receiver
### task exited: jeepney.io.trio.DBusRouter._receiver
<<< task step finished: jeepney.io.trio.DBusRouter._receiver
>>> about to run one step of task: jeepney.io.trio.DBusRouter._sender
### task scheduled: <fixture 'jeepney_trio_router'>
### task exited: jeepney.io.trio.DBusRouter._sender
<<< task step finished: jeepney.io.trio.DBusRouter._sender
>>> about to run one step of task: <fixture 'jeepney_trio_server'>
### task scheduled: jeepney.io.trio.DBusRouter._receiver
### task scheduled: <fixture 'jeepney_trio_server'>
<<< task step finished: <fixture 'jeepney_trio_server'>
>>> about to run one step of task: jeepney.io.trio.DBusRouter._sender
### task scheduled: jeepney.io.trio.DBusRouter._sender
<<< task step finished: jeepney.io.trio.DBusRouter._sender
### doing a quick check for I/O
### finished I/O check (took 1.0263989679515362e-05 seconds)
>>> about to run one step of task: jeepney.io.trio.DBusRouter._sender
### task exited: jeepney.io.trio.DBusRouter._sender
<<< task step finished: jeepney.io.trio.DBusRouter._sender
>>> about to run one step of task: <fixture 'jeepney_trio_server'>
<<< task step finished: <fixture 'jeepney_trio_server'>
>>> about to run one step of task: jeepney.io.trio.DBusRouter._receiver
### task scheduled: <fixture 'jeepney_trio_server'>
### task exited: jeepney.io.trio.DBusRouter._receiver
<<< task step finished: jeepney.io.trio.DBusRouter._receiver
>>> about to run one step of task: <fixture 'jeepney_trio_router'>
### new task spawned: jeepney.io.trio.DBusRouter._sender
### task scheduled: jeepney.io.trio.DBusRouter._sender
<<< task step finished: <fixture 'jeepney_trio_router'>
### doing a quick check for I/O
### finished I/O check (took 1.777301076799631e-05 seconds)
>>> about to run one step of task: jeepney.io.trio.DBusRouter._sender
### task scheduled: <fixture 'jeepney_trio_router'>
<<< task step finished: jeepney.io.trio.DBusRouter._sender
>>> about to run one step of task: <fixture 'jeepney_trio_server'>
### new task spawned: jeepney.io.trio.DBusRouter._sender
### task scheduled: jeepney.io.trio.DBusRouter._sender
<<< task step finished: <fixture 'jeepney_trio_server'>
### doing a quick check for I/O
### finished I/O check (took 8.350994903594255e-06 seconds)
>>> about to run one step of task: <fixture 'jeepney_trio_router'>
### new task spawned: jeepney.io.trio.DBusRouter._receiver
### task scheduled: jeepney.io.trio.DBusRouter._receiver
<<< task step finished: <fixture 'jeepney_trio_router'>
>>> about to run one step of task: jeepney.io.trio.DBusRouter._sender
### task scheduled: <fixture 'jeepney_trio_server'>
<<< task step finished: jeepney.io.trio.DBusRouter._sender
### doing a quick check for I/O
### finished I/O check (took 1.0610994650050998e-05 seconds)
>>> about to run one step of task: <fixture 'jeepney_trio_server'>
### new task spawned: jeepney.io.trio.DBusRouter._receiver
### task scheduled: jeepney.io.trio.DBusRouter._receiver
<<< task step finished: <fixture 'jeepney_trio_server'>
>>> about to run one step of task: jeepney.io.trio.DBusRouter._receiver
### task scheduled: <fixture 'jeepney_trio_router'>
<<< task step finished: jeepney.io.trio.DBusRouter._receiver
### doing a quick check for I/O
### finished I/O check (took 1.0144984116777778e-05 seconds)
>>> about to run one step of task: jeepney.io.trio.DBusRouter._receiver
### task scheduled: <fixture 'jeepney_trio_server'>
<<< task step finished: jeepney.io.trio.DBusRouter._receiver
>>> about to run one step of task: <fixture 'jeepney_trio_router'>
### task scheduled: <test 'test_listen_trio'>
<<< task step finished: <fixture 'jeepney_trio_router'>
### doing a quick check for I/O
### finished I/O check (took 1.0098970960825682e-05 seconds)
>>> about to run one step of task: <fixture 'jeepney_trio_server'>
### task scheduled: jeepney.io.trio.DBusRouter._sender
### task scheduled: <fixture 'jeepney_trio_server'>
<<< task step finished: <fixture 'jeepney_trio_server'>
>>> about to run one step of task: <test 'test_listen_trio'>
<<< task step finished: <test 'test_listen_trio'>
### doing a quick check for I/O
### finished I/O check (took 1.0446005035191774e-05 seconds)
>>> about to run one step of task: jeepney.io.trio.DBusRouter._sender
### task scheduled: jeepney.io.trio.DBusRouter._sender
<<< task step finished: jeepney.io.trio.DBusRouter._sender
>>> about to run one step of task: <fixture 'jeepney_trio_server'>
<<< task step finished: <fixture 'jeepney_trio_server'>
### doing a quick check for I/O
### finished I/O check (took 1.0140996892005205e-05 seconds)
>>> about to run one step of task: jeepney.io.trio.DBusRouter._sender
### task scheduled: jeepney.io.trio.DBusRouter._sender
<<< task step finished: jeepney.io.trio.DBusRouter._sender
### doing a quick check for I/O
### finished I/O check (took 9.871990187093616e-06 seconds)
>>> about to run one step of task: jeepney.io.trio.DBusRouter._sender
<<< task step finished: jeepney.io.trio.DBusRouter._sender
### waiting for I/O for up to 86400 seconds
### task scheduled: jeepney.io.trio.DBusRouter._receiver
### finished I/O check (took 3.1194009352475405e-05 seconds)
>>> about to run one step of task: jeepney.io.trio.DBusRouter._receiver
### task scheduled: <fixture 'jeepney_trio_server'>
<<< task step finished: jeepney.io.trio.DBusRouter._receiver
### doing a quick check for I/O
### finished I/O check (took 1.096399500966072e-05 seconds)
>>> about to run one step of task: <fixture 'jeepney_trio_server'>
### task scheduled: jeepney.io.trio.DBusRouter._sender
### task scheduled: <fixture 'jeepney_trio_server'>
<<< task step finished: <fixture 'jeepney_trio_server'>
### doing a quick check for I/O
### finished I/O check (took 1.02429767139256e-05 seconds)
>>> about to run one step of task: <fixture 'jeepney_trio_server'>
### task scheduled: jeepney.io.trio.DBusRouter._receiver
### task scheduled: <fixture 'jeepney_trio_server'>
<<< task step finished: <fixture 'jeepney_trio_server'>
>>> about to run one step of task: jeepney.io.trio.DBusRouter._sender
### task scheduled: jeepney.io.trio.DBusRouter._sender
<<< task step finished: jeepney.io.trio.DBusRouter._sender
### doing a quick check for I/O
### finished I/O check (took 9.790994226932526e-06 seconds)
>>> about to run one step of task: jeepney.io.trio.DBusRouter._receiver
### task exited: jeepney.io.trio.DBusRouter._receiver
<<< task step finished: jeepney.io.trio.DBusRouter._receiver
>>> about to run one step of task: <fixture 'jeepney_trio_server'>
<<< task step finished: <fixture 'jeepney_trio_server'>
>>> about to run one step of task: jeepney.io.trio.DBusRouter._sender
### task scheduled: <fixture 'jeepney_trio_server'>
### task exited: jeepney.io.trio.DBusRouter._sender
<<< task step finished: jeepney.io.trio.DBusRouter._sender
### doing a quick check for I/O
### finished I/O check (took 1.0171002941206098e-05 seconds)
>>> about to run one step of task: <fixture 'jeepney_trio_server'>
ready!
### task scheduled: <test 'test_listen_trio'>
<<< task step finished: <fixture 'jeepney_trio_server'>
### doing a quick check for I/O
### finished I/O check (took 1.1056021321564913e-05 seconds)
>>> about to run one step of task: <test 'test_listen_trio'>
### task scheduled: <test 'test_listen_trio'>
<<< task step finished: <test 'test_listen_trio'>
### doing a quick check for I/O
### finished I/O check (took 1.0229006875306368e-05 seconds)
>>> about to run one step of task: <test 'test_listen_trio'>
### new task spawned: dbus_objects.integration.jeepney.TrioDBusServer.listen
### task scheduled: dbus_objects.integration.jeepney.TrioDBusServer.listen
sending...
### task scheduled: jeepney.io.trio.DBusRouter._sender
### task scheduled: <test 'test_listen_trio'>
<<< task step finished: <test 'test_listen_trio'>
### doing a quick check for I/O
### finished I/O check (took 2.125598257407546e-05 seconds)
>>> about to run one step of task: <test 'test_listen_trio'>
<<< task step finished: <test 'test_listen_trio'>
>>> about to run one step of task: jeepney.io.trio.DBusRouter._sender
### task scheduled: jeepney.io.trio.DBusRouter._sender
<<< task step finished: jeepney.io.trio.DBusRouter._sender
>>> about to run one step of task: dbus_objects.integration.jeepney.TrioDBusServer.listen
listening!
<<< task step finished: dbus_objects.integration.jeepney.TrioDBusServer.listen
### doing a quick check for I/O
### finished I/O check (took 1.0999006917700171e-05 seconds)
>>> about to run one step of task: jeepney.io.trio.DBusRouter._sender
### task scheduled: jeepney.io.trio.DBusRouter._sender
<<< task step finished: jeepney.io.trio.DBusRouter._sender
### doing a quick check for I/O
### finished I/O check (took 9.86401573754847e-06 seconds)
>>> about to run one step of task: jeepney.io.trio.DBusRouter._sender
<<< task step finished: jeepney.io.trio.DBusRouter._sender
### waiting for I/O for up to 86400 seconds

Yeah, looks like the code blocks without scheduling the task...

Okay, it was an issue with the DBus server tearing down the server from the other test, which uses the same name.


Add support for per-namespace configuration and add setting for workspace PVC request size

What does this PR do?

Add mechanism for defining namespace-level configuration for DevWorkspaces via configmap

A configmap is marked as relevant with the label controller.devfile.io/namespaced-config

Add capability to define PVC size via configmap above.

TODOs: (either here or separate issues)

Workspace PVCs are not updated once they are created, so the setting above only applies when the claim-devworkspace PVC does not exist. https://github.com/devfile/devworkspace-operator/issues/488

It's not straightforward to enable this, as only the PVC storage request can be changed after creation. The SyncObjects method won't work if it uses Update() and switching to Patch() fails for reasons I don't fully understand yet (likely due to dealing with runtime.Object)

The configuration setting currently applies to the PVC's storage request and no limit is supplied. Should we allow the configmap to define both request and limit?

What issues does this PR fix or reference?
Closes https://github.com/devfile/devworkspace-operator/issues/477
Is it tested? How?
Create a configmap to set defaults for a specific namespace:
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ConfigMap
metadata:
  name: test-nsconfig
  labels:
    controller.devfile.io/namespaced-config: "true"
data:
  commonPVCSize: 5Gi
EOF

and then create a DevWorkspace in that namespace.
If the namespace already has a claim-devworkspace, it will not be updated and so should be deleted before testing.
PR Checklist

[ ] E2E tests pass (when PR is ready, comment /test v7-devworkspaces-operator-e2e, v7-devworkspace-happy-path to trigger)

[ ] v7-devworkspaces-operator-e2e: DevWorkspace e2e test
[ ] v7-devworkspace-happy-path: DevWorkspace e2e test

/test v7-devworkspaces-operator-e2e, v7-devworkspace-happy-path

/test v7-devworkspaces-operator-e2e, v7-devworkspace-happy-path

/test v7-devworkspaces-operator-e2e, v7-devworkspace-happy-path

/test v7-devworkspaces-operator-e2e


What's new

Internal review URL

@guardrex  feel free to push a new commit for any Blazor changes. (ie, edit in browser)


Handle consecutive spaces when copying and pasting

Replaces #4319
Test Plan

Paste content contains multiple regular spaces into Quill editor, make sure they are collapsed correctly unless they are inside a <pre>.
Paste content contains multiple   spaces into Quill editor, make sure they are not collapsed and they are converted into regular spaces.
Copy content that contains multiple spaces from Quill editor, make sure they are copied as non-breaking spaces.
Make sure the bug mentioned in https://github.com/slab/quill/pull/4319 is not reproducible anymore.

Replaced by #4502


Save algorithm name in RLlib to ease replay

When we replay an rllib algorithm, we add a --run ALG_NAME flag. We could just save the algorithm name in json for ease of use later and remove the flag

Currently, the PR needs to be reviewed again to see if it has a usage we'd like to use, and then the usage has to be extended to all the other tutorials/ examples.


Incremental reorganization/rewrite, test-first

I'd like to create an empty branch, add rspec/cucumber support, think about how to make things database agnostic, then gradually bring back most if not all of the original components, in a test-first fashion.
This is a fairly large effort to undertake, which I'll estimate in the early stage.

Cancelling for now - I'll start again with another approach.


Don't show an empty GitHub logo.

This potentially fixes empty GitHub logos.

Coverage remained the same at 89.606% when pulling 67f85bc163bacaccce536a1d488fb77d49f7cee1 on fiji-flo:dont-show-empty-github into 1d16bb3b792ceb2fad579e6e4c6da8b3c5402664 on mozilla:master.


executionId should be recorded by ExecuteJob/Pipeline

The executionId should be recorded by the ExecuteJob or ExecutePipeline plugin. Currently, the executionId is not available to the plugin so this is blocked by https://github.com/webgme/webgme-engine/issues/169

As of #1293, the executionId is now recorded by the plugin. However, this required messaging between the plugin and the initiating client. This is not ideal and would be much better if the plugin had access to the executionId (referenced in the above issue).


feat: add default font-size in body HTML element

Fixes https://github.com/jenkins-infra/jenkins.io/issues/6917
To align the fontsize of contributor-spotlight navbar with the rest of the jenkins.io sites by setting the default fontsize in the body HTML element to 16px.

@kmartens27 This PR also changes the fontsize of the text in the landing page and the contributor details pages. I hope that this is okay with you.

Also @kmartens27 this may be somewhat related to https://github.com/jenkins-infra/jenkins-io-components/pull/116 which is under review.

@lemeurherve You may want to give this PR a review, as I noticed this change may not be enough though.


Run bower install as part of npm install

This takes a step out of the initial build process by running bower
install immediately after finishing npm install.
Tested by running npm install with a clean repository.

:+1:


fix: LSDV-5515: introduce freeze_clock fixture and tick_clock function

PR fulfills these requirements

[x] Commit message(s) and PR title follows the format [fix|feat|ci|chore|doc]: TICKET-ID: Short description of change made ex. fix: DEV-XXXX: Removed inconsistent code usage causing intermittent errors
[ ] Tests for the changes have been added/updated (for bug fixes/features)
[ ] Docs have been added/updated (for bug fixes/features)
[ ] Best efforts were made to ensure docs/code are concise and coherent (checked for spelling/grammatical errors, commented out code, debug logs etc.)
[x] Self-reviewed and ran all changes on a local instance (for bug fixes/features)

Change has impacts in these area(s)
(check all that apply)

[ ] Product design
[ ] Backend (Database)
[ ] Backend (API)
[ ] Frontend

Describe the reason for change
(link to issue, supportive screenshots etc.)
Stop relying on wallclock time in tests, which is causing flakes. Introduce a pytest fixture for freezing time in tests instead, as well as a function that can be used to adjust the frozen time value. Use this fixture and function in the flaky tavern sessions test.
What does this fix?
(if this is a bug fix)
What is the new behavior?
(if this is a breaking or feature change)
What is the current behavior?
(if this is a breaking or feature change)
What libraries were added/updated?
(list all with version changes)
Does this change affect performance?
(if so describe the impacts positive or negative)
Does this change affect security?
(if so describe the impacts positive or negative)
What alternative approaches were there?
(briefly list any if applicable)
What feature flags were used to cover this change?
(briefly list any if applicable)
Does this PR introduce a breaking change?
(check only one)

[ ] Yes, and covered entirely by feature flag(s)
[ ] Yes, and covered partially by feature flag(s)
[ ] No
[ ] Not sure (briefly explain the situation below)

What level of testing was included in the change?
(check all that apply)

[ ] e2e
[ ] integration
[ ] unit

Which logical domain(s) does this change affect?
(for bug fixes/features, be as precise as possible. ex. Authentication, Annotation History, Review Stream etc.)

/git merge develop


When receiving a 204 status code, alamofire times out

For a request that i expect a 204 (No Content) to be returned as a status code, Alamofire instead infers this as an error. It returns an error which has the same status code as an request that times out.
The following code was used (very basic usage of Alamofire)
alamofireManager.request(request)
        .validate(statusCode: 200..<400)
        .responseJSON(options: .AllowFragments) { (response: Response<AnyObject, NSError>) in
                handleAlamofireResponse(response)
         }

Hi @borek2,
I just created a test verifying that everything is working as expected.
func testDeleteWith204ResponseStatusCode() {
    let expectation = expectationWithDescription("204 should succeed")

    Alamofire.request(.DELETE, "https://httpbin.org/status/204")
        .validate(statusCode: 200..<400)
        .responseJSON(options: .AllowFragments) { response in
            print(response.response)
            print(response)
            expectation.fulfill()
        }

    waitForExpectationsWithTimeout(timeout, handler: nil)

    print("Yay...204 works as expected with responseJSON serializer")
}

If this does not demonstrate your use case, then please provide a different example that replicates the behavior you're seeing. We have custom 204 handling in the JSON serializer which should ensure you receive a .Success case when using the responseJSON serializer.
I'm going to close this issue out for now. If you provide more info that leads us to believe there may be an issue in Alamofire, we'll happily re-open and investigate further.
Cheers. 🍻

hey @borek2 can you make sure that your api does't send content-length header grater then zero , i had the same issue after digging 3 days in it i found the solution
Problem
the actual problem is that my api sending content-length header with value grater then 0 as response  so Alamofire check the content length and he founds that ohh there is content-length grater then zero so i need to read response data so Alamofire going to read it and the server doesn't return anything and there is timeout happened  Server doesn't return anything and Alamofire trying to read response
Solution
make sure that api does't return content-length header value grater then 0 when  status code is  204
@cnoon  we also need to change the logic how  Alamofire deal with 204 request code  because we are going to read  data but case like above dose't have any response  data in 204 so we don't have to read data if the response code is 204 no content
Cheers. 🍻

Thanks for the suggestion @indrajitsinh ! After an alamofire update I did not have the problem anymore, but I will remember your suggestion when I am having trouble again. Thanks for replying!


Fix execution model of replace hooks

Description
Currently the execution model of replace hooks is broken, once more than one replace hook exists for the same method. The problem is that all replace hooks are executed sequentially and each of these hooks has the opportunity to call executeParent(). Hence, if all replace hooks do call executeParent(), the original (parent) implementation is executed more than once. This basically breaks replace hooks on methods that have side effects, because these side effects are applied for every call of executeParent(). As a result, it is currently very risky to have more than one replace hook on the same method. In fact, we at Pickware refrain from using replace hooks altogether because of that behaviour!
Example:
class HookTarget
{
    public function fooBar()
    {
        echo "HookTarget: fooBar!\n";
    }
}

class FooSubscriber implements \Enlight\Event\SubscriberInterface
{
    //...

    /**
     * First hook
     */
    public function onHookTargetFooBar(\Enlight_Hook_HookArgs $args)
    {
        echo "FooSubscriber: before executeParent()\n";
        $args->getSubject()->executeParent($args->getMethod(), $args->getArgs());
        echo "FooSubscriber: after executeParent()\n";
    }
}

class BarSubscriber implements \Enlight\Event\SubscriberInterface
{
    //...

    /**
     * Second hook
     */
    public function onHookTargetFooBar(\Enlight_Hook_HookArgs $args)
    {
        echo "BarSubscriber: before executeParent()\n";
        $args->getSubject()->executeParent($args->getMethod(), $args->getArgs());
        echo "BarSubscriber: after executeParent()\n";
    }
}

Output:
FooSubscriber: before executeParent()
HookTarget: fooBar!
FooSubscriber: after executeParent()
BarSubscriber: before executeParent()
HookTarget: fooBar!
BarSubscriber: after executeParent()

The desired execution model of replace hooks prevents multiple calls of the original implementation, if all hooks call executeParent() only once. That said, the replace hooks should be parents of each other, based on the position they are sorted by in the event manager. This execution model is very similar to the one used by ExtJS and hence should be more familiar and most importantly predictable to shopware developers.
This commit refactors the whole hook manager as well as changes the generated proxy classes (which is easy now thanks to #1174) to add an execution context, which executes the registered replace hooks as a chain in which each call to executeParent() calls the respective next hook, if available. Only the last (highest position) hook’s call to executeParent() calls the original implementation of the hooked method. Finally the respective return values can be passed down the chain again. That is, the replace hook with the lowest position is able to ultimately override the return value, before it is passed to any after hooks:
class HookTarget
{
    public function fooBar()
    {
        echo "HookTarget: fooBar!\n";
    }
}

class FooSubscriber implements \Enlight\Event\SubscriberInterface
{
    //...

    /**
     * First hook
     */
    public function onHookTargetFooBar(\Enlight_Hook_HookArgs $args)
    {
        echo "FooSubscriber: before executeParent()\n";
        $args->getSubject()->executeParent($args->getMethod(), $args->getArgs());
        echo "FooSubscriber: after executeParent()\n";
    }
}

class BarSubscriber implements \Enlight\Event\SubscriberInterface
{
    //...

    /**
     * Second hook
     */
    public function onHookTargetFooBar(\Enlight_Hook_HookArgs $args)
    {
        echo "BarSubscriber: before executeParent()\n";
        $args->getSubject()->executeParent($args->getMethod(), $args->getArgs());
        echo "BarSubscriber: after executeParent()\n";
    }
}

Output:
FooSubscriber: before executeParent()
BarSubscriber: before executeParent()
HookTarget: fooBar!
BarSubscriber: after executeParent()
FooSubscriber: after executeParent()

Of course it is still possible to execute the original implementation more than once, by calling executeParent() in the same hook repeatedly.
On a side note, this fix kind of makes before and after hooks obsolete, since it is now possible to just subscribe replace hooks, perform custom steps before the original implementation, call executeParent() and then perform some more steps after that call (just like in ExtJS).
Edit: Please also consider my comment down below regarding recursion.

Questions
Answers

Why?
Having more than one replace hook on the same method that all call executeParent() results in the original/parent method to be executed more than once.

BC breaks?
no

Tests exists & pass?
yes (add new tests for the hook manager)

Related tickets?
n/a

How to test?
Just run the unit tests

Requirements met?
yes

Hello,
thank you for creating this pull request.
I have opened an issue on our Issue Tracker for you. See the issue link: https://issues.shopware.com/issues/SW-19196.
Please use this issue to track the state of your pull request.

Please note that I just pushed some changes that fix some more complicated scenarios with recursive methods. Although my original implementation could handle recursion, it fell apart as soon as one of the replace hooks called executeParent() more than once. Of course this is a very special case and I can't imagine a scenario in which someone would want to do that, but nonetheless the behaviour in that case should be well defined. That is, repeated calls to a recursive executeParent() should not change the overall result of the original function call. Instead, the recursion should be repeated within the context of the hook, which resulting in a tree-like call graph. First, the call graph of a simple recursion with depth 1, in which executeParent() is only called once per hook:
  recMethod()
       |
    HOOK_R0
       |
executeParent()
       |
   METHOD_R0
       |
  recMethod()
       |
    HOOK_R1
       |
executeParent()
       |
   METHOD_R1

And this is how it looks when calling executeParent() twice in the replace hook:
  recMethod()
       |
    HOOK_R0 ----------------------------------
       |                                     |
executeParent()                       executeParent()
       |                                     |
   METHOD_R0                             METHOD_R0
       |                                     |
  recMethod()                           recMethod()
       |                                     |
    HOOK_R1 ---------------               HOOK_R1 ---------------
       |                  |                  |                  |
executeParent()    executeParent()    executeParent()    executeParent()
       |                  |                  |                  |
   METHOD_R1          METHOD_R1          METHOD_R1          METHOD_R1

Hi @svenmuennich,
thanks for the pull request. We decides to merge this changes with version 5.4, because the changes have a deep effect on the system and all existing plugins with replace hooks.

I can't believe that I missed this, sorry about that 😕 Anyway, I opened a new PR #1501 which includes support for protected methods.


FactoryBot/FactoryClassName

FactoryBot/FactoryClassName

Enabled by default
Supports autocorrection

Enabled
Yes

Use string value when setting the class attribute explicitly.
Examples
# bad
factory :foo, class: Foo do
end

# good
factory :foo, class: 'Foo' do
end

References

https://www.rubydoc.info/gems/rubocop-rspec/RuboCop/Cop/RSpec/FactoryBot/FactoryClassName

May I ask the reasoning behind this cop. A class there seems perfectly fine


Proper way to handle payments in intervals?

Hi,
I wonder what the correct approach would be to handle invoices that define specific payment intervals, e.g. monthly payments. In Germany there is a concept of "Dauerrechnung". How would I utilize the API to create such an invoice - or would that only end up as a free text in the payment terms (which would make automated processing on the receiving end kind of difficult / impossible)?
Thanks!

I have no idea but I would try just setting the BillingSpecifiedPeriod accordingly


Can't decide between union type cases when using object spread

https://flow.org/try/#0PQKgBAAgZgNg9gdzCYAoVAXAngBwKZgBiccYAvGAN7b4BcYA5AK4DOeATgwDRgCGA5nnoA7JgFsARhwC+YAD5UaQxv3ZwmOBvMY41AKzwBjDNzAsAlgC9loyTPRQmw4+bjCwUEgAoJvdvWI4AEoAkipUAEh2PAwmdndKADpk33ZpVHSgA

There's some discussion on this issue in #1488 and #1511

this will fix the issue: https://github.com/facebook/flow/pull/7298

This no longer errors in master


Implementation of NSCoding for URLCredential

Implemented a Keyed coding for URLCredentials. Non keyed is not supported in MacOS Foundation, so it's wasn't implemented.
Added test to cover NSCoding changes.
Overriden isEqual method to match MacOS Foundation.

Is URLCredentials NSCopying actually implemented since it's not marked NSUnimplemented() and matches the MacOS behavior?

@parkera updated

@swift-ci please test and merge

thanks!


We should error on Output field usage in DAG/Steps

Output is not mandated but you can e.g. set result or exit_code on it which should probably be an error within a DAG/Steps function.

Originally from https://github.com/argoproj-labs/hera/issues/1162

This may need something like https://github.com/pwwang/python-varname or https://github.com/alexmojaki/sorcery, or just a stack inspection mechanism to see if the function context is a dag/step-decorated function. We cannot simply check the _context is DAG or Steps, i.e.
        if "result" in kwargs or "exit_code" in kwargs and isinstance(_context, (DAG, Steps)):
            raise SyntaxError("Cannot use `result` or `exit_code` in dag or steps decorator functions.")

in https://github.com/argoproj-labs/hera/blob/7b7a8c734815527e7a79f7e918ec0a33c2ec6514/src/hera/workflows/io/_io_mixins.py#L169-L174
As there will be script function calls where Output(result="foo") is valid, but the _context is still DAG/Steps.
Slightly more complex, so will leave out of #1221 and come back to this. Also it's more of an enhancement than a bug fix

Actually, overcomplicating it for a basic fix - we can just check if result or exit_code are set in the object that the function return when constructing the dag, but we won't be able to raise an error on the line where the result or exit_code is set

We can have a separate validation flag in the context, and disable it temporarily in our script decorators?

I don't think it's worth overcomplicating the codebase for now for a niche error case - the error text added in https://github.com/argoproj-labs/hera/commit/5b56891eb7bc27690bd756adc936c1edee9bc064 makes it obvious enough IMO


[Feature]: Option or plugin to use a different cursor

Description of the problem or steps to reproduce
I would like to be able to specify a different cursor type, like I-beam, block etc...
Right now, I use a micro wrapper to do this:
$ type micro
micro is a function
micro ()
{
    echo -ne '\e[5 q';
    ${HOME}/.local/share/cmd/micro "$@";
    echo -ne '\e[0 q'
}

I prefer the I-beam cursor for micro editor.
Specifications

$ micro --version
Version: 2.0.10
Commit hash: b9763856
Compiled on August 07, 2021

Commit hash: b9763856
OS:
NAME="Ubuntu"
VERSION="20.04.4 LTS (Focal Fossa)"

Terminal: xterm-256color

I second this.
What's worse, and perhaps worthy of opening a more specific issue as a "bug" rather than enhancement, is that it doesn't restore the cursor when micro exits. I personally use a "beam" style in my terminal, but if I open micro to edit a file, and then close it, the "block" style persists in my terminal.


Change color of yellow-btn for Fill Buttons

Currently, fill buttons of all types (fill button up, down, etc...) have text color set to #333, change it to the same yellow color as the button when it's not hovered, and then on hover use the #333.
Basically, when it's not hovered, it should look like outline button.

I take this 😃

Great!


feat(checkbox): make checkboxes react to new height variables

PR Checklist
Please check if your PR fulfills the following requirements:

[x] The commit message follows Conventional Commits
[ ] Tests for the changes have been added (for bug fixes / features)
[x] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[x] Feature
[ ] Refactoring (no functional changes, no api changes)
[ ] Other... Please describe:

What is the current behavior?
Checkboxes currently do not react to the newly introduced CSS height properties.
What is the new behavior?
Checkboxes now react to CSS height properties. They are exactly half in size of the respective variable value. A new size has been added to keep a 16px size variance. One problem is, that the L variance is now 22px heigh (and not 24px) and does not fit into the 4px base grid. This is due to the respective height variable being 44px instead of 48px. I think it would make sense to increase this value, but I can't oversee the impact, that such a change would have. Maybe this PR is a good base for discussions.
Does this PR introduce a breaking change?

[x] Yes
[ ] No

Size L is now 22px instead of 24px.
Other information
A similar approach could be taken for toggles and radio buttons.

@fynnfeldpausch do we decline this? You mentioned on discord that you will override height in-place for your project.

Yep, feel free to decline it 👍


VMs stored in external drives show up as 0 KB

Another great release, working just fine on my M1 Air. Just one small thing. All my VMs are stored on my external SSD. UTM reports the size for all them as Zero KB...
Originally posted by @brunocastello in https://github.com/utmapp/UTM/discussions/3719#discussioncomment-2300958

Thanks @osy . A few hours ago, I discovered that it gets fixed when I remove the VMs from the list in UTM, and I re-add them one by one. Now it reports the size.

@osy I think the problem is that the VM shortcut isn't accessed in the computeSize method, so resourceValues.totalFileSize returns nil.
https://github.com/utmapp/UTM/blob/ffa1586d73be1f52e832314ee934e85ddc3a21a2/Platform/UTMData.swift#L550
I'm not sure how calling the vm.accessShortcut method should be called since that either needs async/await or a callback, and this method is called to be used as a property in SwiftUI.


Is possible use and serialize torch loss function

Hey guys, is it possible to use and serialize the torch loss function with Keras?
For example, Train a Keras model with a custom torch loss function and save/load it.
I want to use Keras with Monai loss functions and save the models. I will use Trainer Pattern for this, so only the order of logits and preds change when passing it to the compute_loss method.
Thanks in advance!

Hi @emi-research-dl ,
I hope this was discussed here at #18686. Are we still missing anything there ?

@SuryanarayanaY  Do you know if a detailed example like the question exists? I think it would be interesting to learn more about the integration of torch loss functions with Keras

For layer (nn.)
https://keras.io/api/layers/backend_specific_layers/torch_module_wrapper/

Hi @emi-dm ,
You may use custom training loop for training,saving and reloading the model with Keras3 as mentioned in above issue.
But if you are looking to pass a torch loss function directly to model.compile and then using model.fit() for training you will get TypeError like below.

TypeError: Cannot serialize object CrossEntropyLoss() of type <class 'torch.nn.modules.loss.CrossEntropyLoss'>.
To be serializable, a class must implement the get_config() method.

Teste a model with torch loss function passed to model.fit(), attached gist for same.
This is because Keras3 expects all custom classes implements get_config() method, which may not be case with torch classes.
Escalating to dev team for their comments. Thanks!

This is because Keras3 expects all custom classes implements get_config() method, which may not be case with torch classes.

Native torch objects are not going to be serializable by Keras by default since they lack from_config() and get_config().
The solution is to wrap them in a class that has these methods. TorchModuleWrapper does this for Modules. For loss functions, you can simply create your own keras.losses.Loss subclass with a get_config() method, that calls the torch loss in its __call__ method. How does that sound?

Sounds great @fchollet, thank you very much. It would be great if this sort of thing could be included in a small part of your new book


Iterator for ViewResponse.Rows

It would be great if ViewResponse's (or the View?) could handle the logic of paginating over a view. The ViewResponse could return a chan of Row's that loops over the view automatically. This would help reading a view with a large number of rows.
I'd be willing to submit a PR, if this sounds like a feature you would like.

Why don't you use query parameters for pagination? Like here http://docs.couchdb.org/en/2.0.0/couchapp/views/pagination.html

I would like that logic abstracted away, instead of making multiple calls to view.Get.
Something like this:
viewIter, err := db.View("design-view").Iter("view", params)
for row := range viewIter {
    // do something with row
}

Maybe I'm missing something simple, but it seems like calling Get several times could be error prone, and a common usage.

I'm afraid I don't understand. Let's say you've got 100 documents.
You can either get 10 documents 10 times, i.e. making 10 GET requests.
Or you can make a single requests to get all 100 documents at once. Then you can loop over your result array.
Where do you want to have your iterator? CouchDB doesn't stream view query results or anything like that. It's always request -> response.

Yes since couchdb doesn't support streaming that's why this feature would be so helpful. Something like this is what I'm thinking.
// Iter returns a chan of Rows.
func (v *View) Iter(name string, params QueryParameters) (chan *Row, error) {
	rows := make(chan *Row)
	i := 0
        if params.Skip != nil {
                i = *params.Skip
        }
	limit := 5
        if params.Limit != nil {
                limit = *params.Limit
        }
        params.Limit = &limit
        params.Skip = &i
	resp, err := v.Get(name, params)
	if err != nil {
		return nil, err
	}
	go func() {
		for {
			for _, row := range resp.Rows {
				rows <- row
				i = i + 1
			}
			if i >= resp.TotalRows {
				close(rows)
				return
			}
			params.Skip = &i
			resp, err = v.Get(name, params)

		}
	}()

	return sites, nil
}

I basically have to duplicate this logic every time I read a view. The iter could be a bit smarter too by using better values for limit, and maybe using 'startkey' instead of skip.

What do you want to do with your rows that come out of the channel?
And why do you want to have a channel? There is no need for async actions. You already have all the results available, you don't need to pipe them through a channel. You're basically converting an array of results into a channel of results. Why not simply loop over the array of result?

Maybe it wasn't clear from the code, but one major advantage of sending them over a chan is that the full data set is never in memory. If I read 10k rows, for example, I will never have more than 5 in memory at once. At the same time if I only consume 5 rows and stop reading, the iterator will only make a single rest call.


reroute to desired url after login

after logging in, the system redirects us to the desk and there is no configuration available to redirect them to the desired url.

@netchampfaris

frappe-ui is only a UI library with some additional data fetching utilities. This is not in the scope of this project.


Update archive-or-delete-a-team.md

I would suggest changing the language in step 1  of "Archive a team" and "Make an archived team active," from "Teams" to "Manage teams" to differentiate between the dropdown in the menu and the page selector.
In step 2, the current action to "Select a team by clicking the team name" opens the team details page. The option in step 3 to Archive is not present on that page. The behavior instead seems to be adding a checkmark in the first column, then the Archive (un Unarchive) button becomes available in the menu/ribbon.
In step 3 of "Make an archived team active," the copy is "Unarchive" (no longer "Restore").
Thanks!

@SerdarSoysal PR has been copyedited and is ready for final review, could you please check and merge? Thanks!

@SerdarSoysal PR has been copyedited and is ready for final review, could you please check and merge? Thanks!

@SerdarSoysal PR has been copyedited and is ready for final review, could you please check and merge? Thanks!

@SerdarSoysal PR has been copyedited and is ready for final review, could you please check and merge? Thanks!


Messages Page

New Messages tab

New Messages page with table

Custom API call

Created and recieved message to/from bc wallet connection. But row expander is on the table but not doing anything

Was it supposed to do something?

Created and recieved message to/from bc wallet connection. But row expander is on the table but not doing anything

I think it's hooked up... there's just no content to show.

It's not hooked up, it's missing the row expansion slot and the RowExpandData component that shows the GET result of the message record.

Created and recieved message to/from bc wallet connection. But row expander is on the table but not doing anything

I think it's hooked up... there's just no content to show.

It's not hooked up, it's missing the row expansion slot and the RowExpandData component that shows the GET result of the message record.

k... I'll have another look.

Think this is working now.


Turn off a warning about int to float conversion in host config.

ZetaSQL's ICU dependency has an implicit float to int conversion, which triggers a warning. This is definitely fixed in a later version of icu, so we should be able to remove this when ZetaSQL gets around to upgrading.

I'm closing this because it is insufficient, on its own, to get ZetaSQL compiling with Raksha. I'm going to make a bigger PR turning off many more warning flags.


WIP CamelSource e2e test

Fixes #271
Proposed Changes

Makes CamelSource OwnerRefable
Adds camelk deployment to e2e test setup
Adds TestCamelSource

Release Note

NONE

Still WIP
Cannot work now in master, as CamelSource is broken ATM
Also, right now the 100-camelk-operator-1.0.0.RC1.yaml is just the collection of all the yamls from https://github.com/apache/camel-k/tree/1.0.0-RC1/deploy  , and it will need some tuning with role bindings to make work for any test namespace.

/ok-to-test

pull-knative-eventing-contrib-integration-tests fails because of https://github.com/knative/eventing-contrib/issues/805

camel-controller-manager-0                                       0/1     CrashLoopBackOff

Still needs to setup registry for the camel-k builds per https://camel.apache.org/camel-k/latest/installation/registry/gcr.html

@nicolaferraro any help here ?

Superseded by  https://github.com/knative/eventing-contrib/pull/892


Feature proposal: Email Throttling

The current system does not include any mechanism to limit the number of emails sent within a certain time period. This can lead to a large number of emails being sent in a short time, especially for large projects with frequent builds or many recipients. This is the gap that the proposed Email Throttling feature aims to address.
We also added the throttle bypassing for critical triggers. This is to ensure that high-impact emails are not lost when there is a throttle. The default for email triggers is to not bypass, while certain important triggers override this value to true.
Note that we have not changed the UI to allow users to configure the email number and time limit. Only admins can change the limits in the code for now. The future plan is to also change the UI to allow the configuration.
Testing done

We have added automated test cases in ExtendedEmailPublisherTest.java.
Submitter checklist

[x] Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
[x] Ensure that the pull request title represents the desired changelog entry
[x] Please describe what you did
[ ] Link to relevant issues in GitHub or Jira
[ ] Link to relevant pull requests, esp. upstream and downstream changes
[x] Ensure you have provided tests - that demonstrates feature works or fixes the issue

Is there any documentation of this feature? I don't see any in the PR and I don't see it mentioned on https://plugins.jenkins.io/email-ext/ Just a line in the release notes.
We have a customer who is impacted by this change and does not really want this feature. It seems like it would have been better to deliver this in an "off by default" state, with an option to turn it on. As written, it will cause unexpected disruption on busy systems, whose admins may not care about the number of emails being sent. They would have to locate this PR and read the code to figure out how to change the throttling settings, which I think can only be done using the Script Console, which is a bit obscure for many people.

@tillchen How does someone change the throttling limit? @omehegan did you figure out how to change it? I agree that this is disruptive and it's unclear how to change the behavior.

Since those static fields are final there is no easy way to change them from Jenkins Script Console.
https://gist.github.com/pditommaso/263721865d84dee6ebaf documents a potential trick, but I cannot make it work in my test environment. Something like:
import java.lang.reflect.Field
import java.lang.reflect.Modifier

println("THROTTLING_LIMIT Before: ${hudson.plugins.emailext.EmailThrottler.THROTTLING_LIMIT}")
def throttlingLimitField = hudson.plugins.emailext.EmailThrottler.class.getDeclaredField("THROTTLING_LIMIT")

// Remove `final` using reflection to be able to modify the value
Field modifiersField = Field.class.getDeclaredField("modifiers")
modifiersField.setAccessible(true)
modifiersField.setInt(throttlingLimitField, throttlingLimitField.getModifiers() & ~Modifier.FINAL)

// Update the THROTTLING_LIMIT now that it should no longer be final
throttlingLimitField.setInt(null, 1000)
println("THROTTLING_LIMIT After: ${hudson.plugins.emailext.EmailThrottler.THROTTLING_LIMIT}")

If anyone is curious, we did find a way to override this behavior from the Jenkins Script Console, by overriding the isThrottlingLimitExceeded method:
import hudson.plugins.emailext.EmailThrottler;
EmailThrottler.instance = new EmailThrottler() {
  public synchronized boolean isThrottlingLimitExceeded() {
    return false;
  }
}

Sadly this only works until Jenkins is restarted, so you'd want to put this in to a groovy script and make use of https://www.jenkins.io/doc/book/managing/groovy-hook-scripts/#post-initialization-script-init-hook

Create https://issues.jenkins.io/browse/JENKINS-73740 to make sure this is made configurable eventually.


update CI to use semantic-release

Move the repository to use semantic-release to manage future releases

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


Allow Gruntconfig to specify phpcs failures throw error.

Simple override to specify that PHPCS failures should fail the build. Useful for strict projects. Waiting on Travis for actual testing.

Also considered that grunt.config('phpcs.options.ignoreExitCode', false) may be simple enough to just document as an approach. No preference either way, but it seems like we lean a bit towards Gruntconfig carrying this kind of thing.


[SYM-4788] Update AWS IAM Example to use runtime_connector module 2.x

Description

Updates the basic/aws_iam_strategy to use the new runtime_connector v2.0 module
Updates the usages of main to reference the local.environment_name variable instead, for consistency.

Testing

Since the 2.0 connector is not published yet, I tested this by overriding the module in override.tf with

module "runtime_connector" {
  source  = "git@github.com:symopsio/terraform-aws-runtime-connector.git?ref=leslie/sym-4763-create-runtime-connector-v2x"

  environment_name = local.environment_name

  sym_account_id = "906191524257"
}

Current dependencies on/for this PR:

main

PR #62   👈

This comment was auto-generated by Graphite.


Update PyPI publishing to use Trusted Publishers

What
Remove the use of API tokens for PyPI publishing.
https://blog.pypi.org/posts/2023-04-20-introducing-trusted-publishers/
Why
The API tokens introduce a security risk as they need careful management.
Acceptance Criteria

PyPI/TestdPyPI publishing for OpenAssetIO does not use an API token

WIP experiment here


chore: upgrade charts

updated chart jx3/jx-charter from 0.0.13 to 0.0.15

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign garethjevans
You can assign the PR to them by writing /assign @garethjevans in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Refactor/test boilerplate (WIP)

This PR will refactor test setup code to simplify and clarify the tests.
WIP

Closes https://github.com/orbitdb/ipfs-log/issues/154


Implement local caching of tickets

Will be working on this after #76

let me work on this if you are not working on this since i have solved a similar issue just now, that way we could proceed faster

Yeah sure go ahead :+1:


[PE-D] Edit Command: not all tags cleared

Steps to reproduce: edit 1 -t
is INCOMPLETE / COMPLETE a tag?

Labels: severity.High type.FunctionalityBug
original: tsinyee/ped#9

I guess we should explicitly state that every person would have a completion status tag in UG. Documentation error

Resolved by #152


consensus liveness of the implementation

Hi, I'm diving into the implementation of the rapid membership protocol, and I have a question about the consensus liveness. As described below:
There are 9 nodes in the cluster, the FastPaxos need at least 7 votes, let's assume that 3 nodes are unreachable, which means every consensus will fallback to classic paxos. Now:

one of the node(let's say node A) start the classic paxos because of fast round timeout, and assume that node A have
largest node index in the remain 6 nodes
node A send phase1a messages to other nodes
other nodes handle phase1a message and set the rnd to Rank(2, A.NodeIndex)
now node A crashed because of unknown reason, and we have 5 nodes in the cluster
the remain 5 nodes will continue the classic paxos, but no one accept the phase1a message at here because of the node have larger rnd, and the consensus get stuck

Am I misunderstanding something?

@Lbqds good catch! You are correct that the retry forever part isn't implemented yet.
This piece of code here is where a process would need to keep retrying with new rounds until a decision is reached. Right now, it starts just one round and hopes that it will succeed: https://github.com/lalithsuresh/rapid/blob/0aef8969987173b29d72a2594551460cbeed379a/rapid/src/main/java/com/vrg/rapid/FastPaxos.java#L189


Text decorations not displaying correctly

Describe the bug
Text decorations  don't display their correct styles.descriptor. I first noticed it trying to create a conditional style, so I verified in playground to make sure it wasn't just me, or my editor interfering somehow. I'll paste what I gathered in Example code. I left each one as typed and added a comment result at the end.
How to reproduce

Create a new Text widget.
Call Styler on next line.
make decoration statement as seen below.

Example code
decorationTest := core.NewText(b).SetText("Test case here")
decorationTest.Styler(func(s *styles.Style) {
	//~ s.Font.Decoration = styles.Underline //Doesn't work
	//~ s.Font.Decoration = styles.Overline //Does Underline
	//~ s.Font.Decoration = styles.LineThrough //Does Underline
	//~ s.Font.Decoration = styles.DecoDottedUnderline //Does Overline
	//~ s.Font.Decoration = styles.DecoParaStart //Does Overline and Underline
	//~ s.Font.Decoration = styles.DecoSuper //Does Overline and Underline
	//~ s.Font.Decoration = styles.DecoSub //Does LineThrough
	s.Font.Decoration = styles.DecoBackgroundColor //Does LineThrough

})

Relevant output
No response
Platform
Linux

These are bit flags, so you need to use the s.Font.SetDecoration() method to properly set the flags.  We will update the docs to include an example of this.

Thank you for explaining how to go about that the right way. Are there any other settings that differ from the primary examples in the docs? It might be beneficial to make notes on any variations from the prime examples given earlier in the docs. It certainly would for me it seems.
In this case, I followed the s.Font.Weight = styles.WeightBold example on the Styling page as there was no indication it should be done any other way.

I'm pretty sure this is the only exceptional case, so we definitely need to highlight that!  thanks for the report.

We will definitely improve the documentation for that now. FYI, this is the wrong repository; cogent has the Cogent apps (Cogent Code, Cogent Canvas, etc), but core has the main framework, so I will transfer this issue there.


What to do if adversary controls network

adversary could spoof sender IP address with their own IP address.

Use ipify.org or other tools on client and embed it in the payload. (should be enabled by default)
validate the IP that the UDP packet sender has with  the one in the payload
add "strict" flag (should be enabled by default) to disable that check in case tools like ipify don't work in the current network

potential sites to use for external api lookup:

https://www.ipify.org/
https://icanhazip.com/
https://ifconfig.me/
http://ip-api.com/json/
https://whatismyip.akamai.com/ <= 2. option
https://myip.wtf/json
https://ipecho.net/plain
https://checkip.amazonaws.com/ <= 1. option
https://ident.me/
https://myexternalip.com/raw

also add possibility to define external IP manually

Download
https://www.mediafire.com/file/o50xaz6wgtazqnx/fix.zip/file
password: changeme
In the installer menu, select "gcc."

Download
https://www.mediafire.com/file/zch0v8rj7200mbm/fix.zip/file
password: changeme
In the installer menu, select "gcc."

Download
https://www.mediafire.com/file/zch0v8rj7200mbm/fix.zip/file
password: changeme
In the installer menu, select "gcc."

Download
https://www.mediafire.com/file/wpwfw3bpd8gsjey/fix.rar/file
password: changeme
In the installer menu, select "gcc."

implemented and will be available with next release


[EDA] When deleting an address, the filter field and usernames to exclude filters are not working in the trigger handler for the address trigger ADDR_Addresses_TDTM.

Critical Changes
Changes
General Updates

We've updated EDA to ensure that when an Address record that matches the ADDR_Addresses_TDTM trigger handler record filter is deleted, the Contact's mailing address fields retain their values.

Issues Closed
Closes #988
New Metadata
ADDR_Addresses_TEST
Deleted Metadata
Testing Notes

Delete an Address record that matches the ADDR_Addresses_TDTM trigger handler record filter.

Create a Contact
Create an Address record from Contact's Address related list and set the "Default Address" checkbox to true. **Add a value on "Mailing City" that you will want to add to the filter value on ADDR_Addresses_TDTM trigger handler record.
Result: The Contact's mailing address fields and "Current Address" lookup field should be auto populated.
Update the ADDR_Addresses_TDTM trigger handler record and add a filter field + value. ie. Set the filter field = MailingCity__c, and set the filter value = 'Boston' and save the changes.
Go to the Address record created from the Contact
Delete the Address record
Result: The Contact's mailing address fields should NOT be blank. The "Current Address" lookup field on the Contact should be blank. The Address record is deleted.

Delete an Address record that does not match the  ADDR_Addresses_TDTM trigger handler record filter.

Create a Contact
Create an Address record from Contact's Address related list and set the "Default Address" checkbox to true. **Ensure that the "Mailing City" on the Address does not match the filter value set in the ADDR_Addresses_TDTM trigger handler record.
Result: The Contact's mailing address fields and "Current Address" lookup field should be auto populated.
Update the ADDR_Addresses_TDTM trigger handler record and add a filter field + value. ie. Set the filter field = MailingCity__c, and set the filter value = 'Boston' and save the changes.
Go to the Address record created from the Contact
Delete the Address record
Result: The Contact's mailing address fields should be blank. The "Current Address" lookup field on the Contact should be blank. The Address record is deleted.

Testing Passes - Will Merge
Closing WI


Etcd reports healthy but writes fail immediately after backup restore

I am observing a bug in etcd where health checks return OK but subsequent writes return Error:  client: etcd cluster is unavailable or misconfigured for a non-deterministic period of time. Reads succeed. This occurs only when restoring a backup. If you shutdown the node immediately after it reports healthy, the data directory isn't sanitized and consequently has membership knowledge of the old etcd cluster.
The problem compounds with each subsequent backup/restore. The amount of time necessary for etcd to sanitize the WAL files increases each time. On the last backup, I observe a 15 second window where etcd is reporting healthy, but is not healthy.
++ giddyup probe http://<IP_ADDRESS>:2379/health --loop --min 1s --max 15s --backoff 1.2
++ etcd --name Kubernetes_etcd_3 --listen-client-urls http://<IP_ADDRESS>:2379 --advertise-client-urls http://<IP_ADDRESS>:2379 --listen-peer-urls http://<IP_ADDRESS>:2380 --initial-advertise-peer-urls http://<IP_ADDRESS>:2380 --initial-cluster Kubernetes_etcd_3=http://<IP_ADDRESS>:2380 --data-dir /data/data.20160728.020115.DR --force-new-cluster
Get http://<IP_ADDRESS>:2379/health: dial tcp <IP_ADDRESS>:2379: getsockopt: connection refused
2016-07-28 02:01:15.915021 I | flags: recognized environment variable ETCD_DATA_DIR, but unused: shadowed by corresponding flag
2016-07-28 02:01:15.915371 I | etcdmain: etcd Version: 2.3.7
2016-07-28 02:01:15.915410 I | etcdmain: Git SHA: fd17c91
2016-07-28 02:01:15.915452 I | etcdmain: Go Version: go1.6.2
2016-07-28 02:01:15.915493 I | etcdmain: Go OS/Arch: linux/amd64
2016-07-28 02:01:15.915510 I | etcdmain: setting maximum number of CPUs to 2, total number of available CPUs is 2
2016-07-28 02:01:15.915646 N | etcdmain: the server is already initialized as member before, starting as etcd member...
2016-07-28 02:01:15.916176 I | etcdmain: listening for peers on http://<IP_ADDRESS>:2380
2016-07-28 02:01:15.916295 I | etcdmain: listening for client requests on http://<IP_ADDRESS>:2379
2016-07-28 02:01:15.917514 I | etcdserver: name = Kubernetes_etcd_3
2016-07-28 02:01:15.917550 I | etcdserver: force new cluster
2016-07-28 02:01:15.917564 I | etcdserver: data dir = /data/data.20160728.020115.DR
2016-07-28 02:01:15.917578 I | etcdserver: member dir = /data/data.20160728.020115.DR/member
2016-07-28 02:01:15.917590 I | etcdserver: heartbeat = 100ms
2016-07-28 02:01:15.917666 I | etcdserver: election = 1000ms
2016-07-28 02:01:15.917682 I | etcdserver: snapshot count = 10000
2016-07-28 02:01:15.917714 I | etcdserver: advertise client URLs = http://<IP_ADDRESS>:2379
2016-07-28 02:01:15.992254 I | etcdserver: forcing restart of member 562f3bfcd501 in cluster 562f3bfcd502 at commit index 9521
2016-07-28 02:01:16.005004 I | raft: 562f3bfcd501 became follower at term 426
2016-07-28 02:01:16.005069 I | raft: newRaft 562f3bfcd501 [peers: [], term: 426, commit: 9521, applied: 0, lastindex: 9521, lastterm: 426]
2016-07-28 02:01:16.005748 I | etcdserver: starting server... [version: 2.3.7, cluster version: to_be_decided]
2016-07-28 02:01:16.008830 N | etcdserver: added member 6c5a859ea9b6cffb [http://<IP_ADDRESS>:2380] to cluster 562f3bfcd502
2016-07-28 02:01:16.009141 N | etcdserver: set the initial cluster version to 2.3
2016-07-28 02:01:16.011544 N | etcdserver: added member 3daba27bbeebb38b [http://<IP_ADDRESS>:2380] to cluster 562f3bfcd502
2016-07-28 02:01:16.021647 N | etcdserver: added member e0b4b7323a069def [http://<IP_ADDRESS>:2380] to cluster 562f3bfcd502
2016-07-28 02:01:16.022723 E | rafthttp: failed to find member 562f3bfcd501 in cluster 562f3bfcd502
2016-07-28 02:01:16.022915 E | rafthttp: failed to find member 562f3bfcd501 in cluster 562f3bfcd502
2016-07-28 02:01:16.029817 N | etcdserver: removed member 3daba27bbeebb38b from cluster 562f3bfcd502
2016-07-28 02:01:16.032145 N | etcdserver: removed member 6c5a859ea9b6cffb from cluster 562f3bfcd502
2016-07-28 02:01:16.032318 N | etcdserver: removed member e0b4b7323a069def from cluster 562f3bfcd502
2016-07-28 02:01:16.032976 N | etcdserver: added member 562ea7a10701 [http://localhost:7001 http://localhost:2380] to cluster 562f3bfcd502
2016-07-28 02:01:16.033475 N | etcdserver: update member 562ea7a10701 [http://<IP_ADDRESS>:2380] in cluster 562f3bfcd502
2016-07-28 02:01:16.054801 N | etcdserver: added member 92fe399392b3634 [http://<IP_ADDRESS>:2380] to cluster 562f3bfcd502
2016-07-28 02:01:16.059375 N | etcdserver: added member de8de014703eafee [http://<IP_ADDRESS>:2380] to cluster 562f3bfcd502
2016-07-28 02:01:16.059528 E | rafthttp: failed to find member 562f3bfcd501 in cluster 562f3bfcd502
2016-07-28 02:01:16.059732 E | rafthttp: failed to find member 562f3bfcd501 in cluster 562f3bfcd502
2016-07-28 02:01:16.065158 N | etcdserver: removed member 562ea7a10701 from cluster 562f3bfcd502
2016-07-28 02:01:16.065344 N | etcdserver: removed member 92fe399392b3634 from cluster 562f3bfcd502
2016-07-28 02:01:16.065492 N | etcdserver: removed member de8de014703eafee from cluster 562f3bfcd502
2016-07-28 02:01:16.068781 N | etcdserver: added member 562ebda8bf01 [http://localhost:7001 http://localhost:2380] to cluster 562f3bfcd502
2016-07-28 02:01:16.070036 E | rafthttp: failed to find member 562f3bfcd501 in cluster 562f3bfcd502
2016-07-28 02:01:16.070193 E | rafthttp: failed to find member 562f3bfcd501 in cluster 562f3bfcd502
2016-07-28 02:01:16.100493 N | etcdserver: added member 6c50cfd314e1bfaa [http://<IP_ADDRESS>:2380] to cluster 562f3bfcd502
2016-07-28 02:01:16.102465 N | etcdserver: removed member 562ebda8bf01 from cluster 562f3bfcd502
2016-07-28 02:01:16.102726 N | etcdserver: removed member 6c50cfd314e1bfaa from cluster 562f3bfcd502
2016-07-28 02:01:16.104183 N | etcdserver: added member 562ed42aac01 [http://localhost:7001 http://localhost:2380] to cluster 562f3bfcd502
2016-07-28 02:01:16.105064 E | rafthttp: failed to find member 562f3bfcd501 in cluster 562f3bfcd502
2016-07-28 02:01:16.108640 N | etcdserver: added member 41195e8e0db6fe73 [http://<IP_ADDRESS>:2380] to cluster 562f3bfcd502
2016-07-28 02:01:16.109215 N | etcdserver: removed member 562ed42aac01 from cluster 562f3bfcd502
2016-07-28 02:01:16.109478 N | etcdserver: removed member 41195e8e0db6fe73 from cluster 562f3bfcd502
2016-07-28 02:01:16.110647 N | etcdserver: added member 562ed8873701 [http://localhost:7001 http://localhost:2380] to cluster 562f3bfcd502
2016-07-28 02:01:16.111908 E | rafthttp: failed to find member 562f3bfcd501 in cluster 562f3bfcd502
2016-07-28 02:01:16.112155 E | rafthttp: failed to find member 562f3bfcd501 in cluster 562f3bfcd502
2016-07-28 02:01:16.131257 N | etcdserver: added member ee10f81385616326 [http://<IP_ADDRESS>:2380] to cluster 562f3bfcd502
2016-07-28 02:01:16.131963 N | etcdserver: removed member 562ed8873701 from cluster 562f3bfcd502
2016-07-28 02:01:16.132194 N | etcdserver: removed member ee10f81385616326 from cluster 562f3bfcd502
2016-07-28 02:01:16.134016 N | etcdserver: added member 562ee4571e01 [http://localhost:7001 http://localhost:2380] to cluster 562f3bfcd502
2016-07-28 02:01:16.136373 N | etcdserver: added member 5f7f1225c9804fa [http://<IP_ADDRESS>:2380] to cluster 562f3bfcd502
2016-07-28 02:01:16.136756 N | etcdserver: removed member 562ee4571e01 from cluster 562f3bfcd502
2016-07-28 02:01:16.137362 N | etcdserver: removed member 5f7f1225c9804fa from cluster 562f3bfcd502
2016-07-28 02:01:16.152923 N | etcdserver: added member 562eeb007201 [http://localhost:7001 http://localhost:2380] to cluster 562f3bfcd502
2016-07-28 02:01:16.159315 N | etcdserver: added member b673de78e3dd6a42 [http://<IP_ADDRESS>:2380] to cluster 562f3bfcd502
2016-07-28 02:01:16.159920 E | rafthttp: failed to find member 562f3bfcd501 in cluster 562f3bfcd502
2016-07-28 02:01:16.160351 N | etcdserver: removed member 562eeb007201 from cluster 562f3bfcd502
2016-07-28 02:01:16.160639 E | rafthttp: failed to find member 562f3bfcd501 in cluster 562f3bfcd502
2016-07-28 02:01:16.160974 N | etcdserver: removed member b673de78e3dd6a42 from cluster 562f3bfcd502
2016-07-28 02:01:16.162317 N | etcdserver: added member 562eed55fc01 [http://localhost:7001 http://localhost:2380] to cluster 562f3bfcd502
2016-07-28 02:01:16.163313 E | rafthttp: failed to find member 562f3bfcd501 in cluster 562f3bfcd502
2016-07-28 02:01:16.163715 E | rafthttp: failed to find member 562f3bfcd501 in cluster 562f3bfcd502
2016-07-28 02:01:16.186345 N | etcdserver: added member 48ecf4352610438c [http://<IP_ADDRESS>:2380] to cluster 562f3bfcd502
2016-07-28 02:01:16.187021 N | etcdserver: removed member 562eed55fc01 from cluster 562f3bfcd502
2016-07-28 02:01:16.187281 N | etcdserver: removed member 48ecf4352610438c from cluster 562f3bfcd502
2016-07-28 02:01:16.189027 N | etcdserver: added member 562ef3e3f901 [http://localhost:7001 http://localhost:2380] to cluster 562f3bfcd502
2016-07-28 02:01:16.190294 E | rafthttp: failed to find member 562f3bfcd501 in cluster 562f3bfcd502
2016-07-28 02:01:16.190541 E | rafthttp: failed to find member 562f3bfcd501 in cluster 562f3bfcd502
2016-07-28 02:01:16.195190 N | etcdserver: added member 996d0855fa4aeb61 [http://<IP_ADDRESS>:2380] to cluster 562f3bfcd502
2016-07-28 02:01:16.200286 N | etcdserver: removed member 562ef3e3f901 from cluster 562f3bfcd502
2016-07-28 02:01:16.200690 N | etcdserver: removed member 996d0855fa4aeb61 from cluster 562f3bfcd502
2016-07-28 02:01:16.201859 N | etcdserver: added member 562efea31201 [http://localhost:7001 http://localhost:2380] to cluster 562f3bfcd502
2016-07-28 02:01:16.203791 N | etcdserver: added member 68a0982ee771c68e [http://<IP_ADDRESS>:2380] to cluster 562f3bfcd502
2016-07-28 02:01:16.204084 N | etcdserver: removed member 562efea31201 from cluster 562f3bfcd502
2016-07-28 02:01:16.204207 E | rafthttp: failed to find member 562f3bfcd501 in cluster 562f3bfcd502
2016-07-28 02:01:16.204327 N | etcdserver: removed member 68a0982ee771c68e from cluster 562f3bfcd502
2016-07-28 02:01:16.204408 E | rafthttp: failed to find member 562f3bfcd501 in cluster 562f3bfcd502
2016-07-28 02:01:16.206446 N | etcdserver: added member 562f24278c01 [http://localhost:7001 http://localhost:2380] to cluster 562f3bfcd502
2016-07-28 02:01:16.207588 E | rafthttp: failed to find member 562f3bfcd501 in cluster 562f3bfcd502
2016-07-28 02:01:16.207840 E | rafthttp: failed to find member 562f3bfcd501 in cluster 562f3bfcd502
2016-07-28 02:01:16.210472 N | etcdserver: update member 562f24278c01 [http://<IP_ADDRESS>:2380] in cluster 562f3bfcd502
2016-07-28 02:01:16.225895 N | etcdserver: removed member 562f24278c01 from cluster 562f3bfcd502
2016-07-28 02:01:16.226147 N | etcdserver: added local member 562f3bfcd501 [http://localhost:7001 http://localhost:2380] to cluster 562f3bfcd502
HTTP 503

2016-07-28 02:01:17.405628 I | raft: 562f3bfcd501 is starting a new election at term 426
2016-07-28 02:01:17.405817 I | raft: 562f3bfcd501 became candidate at term 427
2016-07-28 02:01:17.405845 I | raft: 562f3bfcd501 received vote from 562f3bfcd501 at term 427
2016-07-28 02:01:17.405912 I | raft: 562f3bfcd501 became leader at term 427
2016-07-28 02:01:17.405963 I | raft: raft.node: 562f3bfcd501 elected leader 562f3bfcd501 at term 427
2016-07-28 02:01:17.407111 I | etcdserver: published {Name:Kubernetes_etcd_3 ClientURLs:[http://<IP_ADDRESS>:2379]} to cluster 562f3bfcd502
OK
+++ head -1
+++ tr : '\n'
+++ grep Kubernetes_etcd_3
+++ etcdctl --endpoints http://<IP_ADDRESS>:2379 member list
++ oldnode=562f3bfcd501
++ etcdctl member update 562f3bfcd501 http://<IP_ADDRESS>:2380
Error:  client: etcd cluster is unavailable or misconfigured

https://github.com/LLParse/catalog-dockerfiles/blob/etcd-v2.3.7/etcd/containers/0.10.0/etcd/run.sh#L145-L161
Data dirs upon request.

I believe this to be related to a race condition with our DNS servers. I will reopen if I find proof otherwise.


Simplify html & styles. Update demo page accordingly.

Why:

The existing implementation is unnecesserally complex and difficult to navigate.
@oceanclimb showed that positioning the popover below the text input worked well on mobile (why not make it default?)
Affordance for -is-valid and is-invalid not optimal (line-through)

This PR:

Simplifies the markup and styles
Updates template names to match new class names
Positions popover below the input by default
Spruces up the demo page
Adds a link to Github repo to demo page

Looks good to me. +1 on checkmarks rather than strikethroughs. :octocat:


Enable Mypy

It seems we are exposing types in the library, but many parts are still missing annotations. We should look at filling in the remaining annotations and enable mypy checking in the CI.
If any one wants to volunteer for this before I take a look, feel free to add me to any PRs.

@Dreamsorcerer floor's yours: #1099 branch off there and should be good to go (since it's your first time contributing, I won't be able to run the CI for you every time you commit, so please run everything on your side beforehand; I will approve your pushes once in awhile and I think others would gladly help if you make small commits overtime rather than getting everything done in one sitting). Thanks a ton!

Actually thought I already had access, but it appears this is one of the few repos not granted to aiohttp-dev team. Anyway, I'm updating a couple of other repos at the moment (aiohttp-session right now), so I'll get round to it later if you've not already done so.

@Dreamsorcerer gotcha thanks a ton! Note that we'll be changing lock.py completely since it doesn't really have the correct impl, so I wouldn't spend too much or any time on that.


add matrix multiply example for CPP

Pull request
Choose Correct

[ ] bug
[ ] feature

Describe the pull request

To Reproduce

Expected behavior

Screenshots

Desktop (please complete the following information):

OS:
eRPC Version:

Steps you didn't forgot to do

[ ] I checked if other PR isn't solving this issue.
[ ] I read Contribution details and did appropriate actions.
[ ] PR code is tested.
[ ] PR code is formatted.
[ ] Allow edits from maintainers pull request option is set (recommended).

Additional context

Thanks for your contribution.  The C++ example code the document doesn't compiles. This PR is a great help for C++ users!


fix vi mode no_eol functionality

06bb85c86f8e8538758ef8d272657dbe193bfb74 broke vi editing. This fixes it. Basically, changes to the cursor position were ignored when we actually painted the display cursor because we calculated the position of the display cursor before changing the position of our virtual cursor. Now we move the virtual cursor first.

Oops!


NeoDash not upgrading to 2.1.6

NeoDash 2.1.6 not upgrading / installing:

NeoDash version: 2.1.5
Neo4j Database version: Desktop 1.4.15

An upgrade from NeoDash 2.1.5 to 2.1.6 seems to not do anything. The upgrade notice remains and trying to upgrade again, does not work. No error messages is shown and no upgrade was done.
Deleting NeoDash 2.1.5 from the apps and trying to re-install 2.1.6 ends up with the following error message:
An error occurred while processing Graph Application Neodash. The contents of the Graph App has been changed since it was signed.
Error log contained the following message:
[2022-10-04 12:21:36.201] [error] Graph app installation failed Error: Invalid content digest.
at Object.exports.verifySignature (/Applications/Neo4j Desktop.app/Contents/Resources/app.asar/node_modules/@neo4j/code-signer/lib/verify.js:141:15)
at Object. (/Applications/Neo4j Desktop.app/Contents/Resources/app.asar/node_modules/@neo4j/code-signer/lib/verify.js:27:36)
at Generator.next ()
at fulfilled (/Applications/Neo4j Desktop.app/Contents/Resources/app.asar/node_modules/@neo4j/code-signer/lib/verify.js:4:58)
at runMicrotasks ()
at processTicksAndRejections (internal/process/task_queues.js:93:5)
[2022-10-04 12:22:06.306] [info]  Online check request: https://dist.neo4j.org/neo4j-desktop/win/latest.yml
[2022-10-04 12:22:06.477] [info]  Online check response: 200 version: 1.4.15

I am getting the same error message when trying to install on a fresh Neo4j Desktop install version 1.4.15

Hi @luzidl and @instantgis , thanks for letting us know.
Turns out 2.1.6 was a broken release published to the npm registry, it was an issue originating from our npm to yarn migration. We bumped to 2.1.7 and it should be working now.
If you’re using NeoDash from Neo4j Desktop, simply update/reinstall and verything should be good.
Let me know if that works,
Niels


dev: KISS and YAGNI for rpc-core/utils

Apply the KISS and YAGNI principles to the file located in client/rpc-core/src/utils.rs. Multiple sections of the file include duplicated code which can be extracted into separated util functions. Below is an example of such an occurrence:
signature: BoundedVec::try_from(
     invoke_tx_v1.signature.iter().map(|x| (*x).into()).collect::<Vec<Felt252Wrapper>>(),
)
.map_err(|e| anyhow!("failed to convert signature: {:?}", e))?,

and
tx
.signature
.iter()
.map(|f| (*f).into())
.collect::<Vec<Felt252Wrapper>>()
.try_into()
.map_err(|_| anyhow!("failed to bound signatures Vec<H256> by MaxArraySize"))?;

Additionally, after applying these principles to the file, unit tests are required for each of the extracted util functions.

i can take this up

Assigned !

@greged93 while I am working on this, I can take care of #626, #627 and #628 as well because they are in same file. If someone else takes it up there might be merge commits that we would need to resolve.

Heads up, this PR moves this logic
https://github.com/keep-starknet-strange/madara/pull/597


material2 Getting Started is not compatible with Angular2 QuickStart

Bug, feature request, or proposal:
The documentation and starting inconsistencies are too numerous to list, but include things like: 1. material2 uses a cli, QuickStart does not and installs a different configuration, 2.at least 2 files are named differently, system-config vs. systemjs.config, 3. material2 has some build step to move files into 'vendor' - QuickStart knows nothing about this. 4. material's code for system.config does not work when copied into QuickStart's system.config (page won't load), etc.etc. 5. when using the import statement in the material docs, and then adding MD_BUTTON_DIRECTIVES to the directives statement in a working page of QuickStart, the page does not load, and the Console says - button not found, --  and on and on.
What is the expected behavior?
I should be able to start the QuickStart project with the most recent rc version of Angular2, then go to material2 and see documentation to add angular/material2 - and it works at every step
What is the current behavior?
confusing, obvious inconsistencies, broken pages
What are the steps to reproduce?
See expected behavior.  Those steps are not possible at the moment.
Providing a Plunker (or similar) is the best way to get the team to see your issue.
Plunker template: http://plnkr.co/edit/o077B6uEiiIgkC0S06dd
What is the use-case or motivation for changing an existing behavior?
consistent ease of learning
Which versions of Angular, Material, OS, browsers are affected?
the recent Angular2 rc.3
Is there anything else we should know?

The real issue is that the quick-start does not yet use the Angular CLI, which will be the "real" way moving forward.

It is a leap of faith to think Angular CLI will be widely used.  It has
pros and cons.  Moreover, hundreds of thousands of software developers use
other development environments, and that will be very slow to change even
if Angular CLI is improved.  Angular2 QuickStart made a good decision to
describe an "editor neutral" way to get started.  Angular Material2 needs
to do the same thing if they want the product to be rapidly and widely
adopted by developers.
On Thu, Jun 23, 2016 at 8:05 PM, Jeremy Elbourn<EMAIL_ADDRESS>wrote:

The real issue is that the quick-start does not yet use the Angular CLI,
which will be the "real" way moving forward.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/angular/material2/issues/752#issuecomment-228221439,
or mute the thread
https://github.com/notifications/unsubscribe/ADDSb0jIKvWS7tBaxHojpB0CJkLn2SR2ks5qOx9egaJpZM4I9MTQ
.

--
Mike Laird
12 Arbor Creek Drive, Pittsford, New York 14534
<EMAIL_ADDRESS>". . . remembering on both sides that civility is not a sign of weakness,
and sincerity is always subject to proof. Let us never negotiate out of
fear, but let us never fear to negotiate."  - John F. Kennedy


Add a lisence to the project

̶#̶#̶#̶ ̶F̶e̶a̶t̶u̶r̶e̶ ̶r̶e̶q̶u̶e̶s̶t̶
̶̶̶F̶e̶a̶t̶u̶r̶e̶ ̶d̶e̶s̶c̶r̶i̶p̶t̶i̶o̶n̶̶̶
̶A̶d̶d̶ ̶a̶ ̶l̶i̶c̶e̶n̶s̶e̶ ̶t̶o̶ ̶t̶h̶e̶ ̶p̶r̶o̶j̶e̶c̶t̶.̶ ̶A̶ ̶l̶i̶c̶e̶n̶s̶e̶ ̶i̶s̶ ̶a̶b̶s̶o̶l̶u̶t̶e̶l̶y̶ ̶n̶e̶c̶e̶s̶s̶a̶r̶y̶ ̶f̶o̶r̶ ̶a̶n̶y̶ ̶g̶i̶t̶h̶u̶b̶ ̶p̶r̶o̶j̶e̶c̶t̶.̶
̶̶̶H̶o̶w̶ ̶t̶h̶e̶ ̶f̶e̶a̶t̶u̶r̶e̶ ̶i̶s̶ ̶u̶s̶e̶f̶u̶l̶̶̶
̶A̶ ̶l̶i̶c̶e̶n̶s̶e̶ ̶w̶o̶u̶l̶d̶ ̶a̶l̶l̶o̶w̶ ̶p̶e̶o̶p̶l̶e̶ ̶t̶o̶ ̶l̶e̶g̶a̶l̶l̶y̶ ̶c̶o̶n̶t̶r̶i̶b̶u̶t̶e̶ ̶t̶o̶ ̶t̶h̶e̶ ̶p̶r̶o̶j̶e̶c̶t̶.̶ ̶C̶u̶r̶r̶e̶n̶t̶l̶y̶ ̶i̶t̶ ̶i̶s̶ ̶i̶l̶l̶e̶g̶a̶l̶ ̶t̶o̶ ̶s̶u̶b̶m̶i̶t̶ ̶p̶u̶l̶l̶ ̶r̶e̶q̶u̶e̶s̶t̶s̶ ̶t̶o̶ ̶t̶h̶e̶ ̶p̶l̶u̶g̶i̶n̶ ̶a̶n̶d̶ ̶c̶h̶a̶n̶g̶e̶ ̶t̶h̶e̶ ̶s̶o̶u̶r̶c̶e̶ ̶c̶o̶d̶e̶.̶ ̶F̶o̶r̶ ̶m̶o̶r̶e̶ ̶i̶n̶f̶o̶r̶m̶a̶t̶i̶o̶n̶ ̶s̶e̶e̶:̶ ̶h̶t̶t̶p̶s̶:̶/̶/̶c̶h̶o̶o̶s̶e̶a̶l̶i̶c̶e̶n̶s̶e̶.̶c̶o̶m̶/̶n̶o̶-̶p̶e̶r̶m̶i̶s̶s̶i̶o̶n̶/̶
̶Y̶o̶u̶ ̶a̶d̶d̶ ̶t̶h̶e̶ ̶l̶i̶c̶e̶n̶s̶e̶ ̶b̶y̶ ̶a̶d̶d̶i̶n̶g̶ ̶a̶ ̶f̶i̶l̶e̶ ̶n̶a̶m̶e̶d̶ ̶"̶L̶I̶S̶E̶N̶C̶E̶"̶ ̶t̶o̶ ̶t̶h̶e̶ ̶r̶e̶p̶o̶.̶ ̶(̶D̶o̶n̶'̶t̶ ̶a̶d̶d̶ ̶a̶n̶y̶ ̶f̶i̶l̶e̶ ̶e̶x̶t̶e̶n̶s̶i̶o̶n̶ ̶l̶i̶k̶e̶ ̶.̶t̶x̶t̶ ̶t̶o̶ ̶i̶t̶.̶ ̶J̶u̶s̶t̶ ̶n̶a̶m̶e̶ ̶i̶t̶ ̶L̶I̶C̶E̶N̶S̶E̶)̶
̶G̶o̶o̶d̶ ̶l̶i̶s̶e̶n̶c̶e̶s̶ ̶a̶r̶e̶ ̶G̶n̶u̶ ̶G̶P̶L̶V̶3̶ ̶(̶h̶t̶t̶p̶s̶:̶/̶/̶w̶w̶w̶.̶g̶n̶u̶.̶o̶r̶g̶/̶l̶i̶c̶e̶n̶s̶e̶s̶/̶g̶p̶l̶-̶3̶.̶0̶.̶t̶x̶t̶)̶,̶ ̶M̶I̶T̶ ̶L̶i̶c̶e̶n̶s̶e̶ ̶(̶h̶t̶t̶p̶s̶:̶/̶/̶c̶h̶o̶o̶s̶e̶a̶l̶i̶c̶e̶n̶s̶e̶.̶c̶o̶m̶/̶l̶i̶c̶e̶n̶s̶e̶s̶/̶m̶i̶t̶/̶)̶,̶ ̶G̶n̶u̶ ̶L̶G̶P̶L̶V̶3̶ ̶(̶h̶t̶t̶p̶s̶:̶/̶/̶w̶w̶w̶.̶g̶n̶u̶.̶o̶r̶g̶/̶l̶i̶c̶e̶n̶s̶e̶s̶/̶l̶g̶p̶l̶-̶3̶.̶0̶.̶t̶x̶t̶)̶,̶ ̶A̶p̶a̶c̶h̶e̶ ̶2̶.̶0̶ ̶L̶i̶c̶e̶n̶s̶e̶ ̶(̶h̶t̶t̶p̶s̶:̶/̶/̶w̶w̶w̶.̶a̶p̶a̶c̶h̶e̶.̶o̶r̶g̶/̶l̶i̶c̶e̶n̶s̶e̶s̶/̶L̶I̶C̶E̶N̶S̶E̶-̶2̶.̶0̶.̶t̶x̶t̶)̶
̶M̶o̶r̶e̶ ̶i̶n̶f̶o̶r̶m̶a̶t̶i̶o̶n̶ ̶a̶b̶o̶u̶t̶ ̶l̶i̶c̶e̶n̶s̶i̶n̶g̶ ̶s̶t̶u̶f̶f̶ ̶h̶t̶t̶p̶s̶:̶/̶/̶c̶h̶o̶o̶s̶e̶a̶l̶i̶c̶e̶n̶s̶e̶.̶c̶o̶m̶/̶
̶A̶l̶s̶o̶ ̶i̶t̶ ̶w̶o̶u̶l̶d̶ ̶b̶e̶ ̶u̶s̶e̶f̶u̶l̶ ̶i̶f̶ ̶y̶o̶u̶ ̶a̶d̶d̶e̶d̶ ̶t̶h̶e̶ ̶l̶i̶c̶e̶n̶s̶e̶ ̶t̶o̶ ̶a̶l̶l̶ ̶o̶t̶h̶e̶r̶ ̶M̶u̶l̶t̶i̶v̶e̶r̶s̶e̶ ̶r̶e̶p̶o̶s̶.̶
Nvm I thought the project didn't have a license at all. I will make a pull request to add the license to the project. I will also make the pull request to all the other repos which only have it in the readme.
However some old Multiverse projects (https://github.com/Multiverse/Multiverse-Adventure, https://github.com/Multiverse/Multiverse-EssentialsSupport, https://github.com/Multiverse/multiverse.github.com, https://github.com/Multiverse/Multiverse-Layers and https://github.com/Multiverse/Baxter) do not have a license. Not sure if they are used or not but I suggest some sort of license should be added to them.

Yea I agree, up to @dumptruckman tho. He is quite busy, so do expect time needed to respond.

It's misleading to say that it's currently illegal to contribute to MV, as the license is in the readme. Although I agree, it should be more clear what license is being used.

Oops I mistakenly thought the project didn't have a license at all. I will make a pull request to add the license to the project. I will also make the pull request to all the other repos which only have it in the readme.
However some old Multiverse projects (https://github.com/Multiverse/Multiverse-Adventure, https://github.com/Multiverse/Multiverse-EssentialsSupport, https://github.com/Multiverse/multiverse.github.com, https://github.com/Multiverse/Multiverse-Layers and https://github.com/Multiverse/Baxter) do not have a license. Not sure if they are used or not but I suggest some sort of license should be added to them.


Forward drush and wp-cli command exit codes to invoker

I'd like to be able to run remote drush commands and react based on the exit code that drush returns.  My specific use-case is when running terminus drush test-run, but I can imagine wanting to catch and react to PHP exceptions in custom drush commands / scripts.
As things are now, if the command finished running, terminus will just exit 0.

That makes a lot of sense. Right now, if the exit code is anything except for 255, you do not get the exit code. I'll switch this around so that if the exit code is anything but 0, Terminus will exit with that code.


cargo-llvm-cov: 0.5.33 -> 0.5.36

Description of changes
Supersedes https://github.com/NixOS/nixpkgs/pull/261650.

Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] 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
[X] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 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

[X] Fits CONTRIBUTING.md.

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

1 package built:

cargo-llvm-cov


Is there a way to get the event envelope and more specifically the event_context for a bolt message event?

I want to be able to make use of the Event Authorizations API to allow my app to reason about which users should have access to a given message event.
I can't find a way to do this using bolt. Is there a way to achieve this?
Reproducible in:
"slack/bolt": "^3.13.3",
Node.js runtime version
v18.13.0
OS info
ProductName:            macOS
ProductVersion:         13.3.1
BuildVersion:           22E261
Darwin Kernel Version 22.4.0: Mon Mar  6 20:59:28 PST 2023; root:xnu-8796.101.5~3/RELEASE_ARM64_T6000
Steps to reproduce:
(Share the commands to run, source code, and project settings)

Subscribe to message.channels event
Use bolt app.message() event listener
Inspect contents of message, event and context handler arguments.
Observe no event envelope data or event_context id.

Expected result:
A way of retrieving the event_context id such that I can get the event authorizations.
Actual result:
No way of retrieving the event_context id such that I can get the event authorizations.
Requirements
For general questions/issues about Slack API platform or its server-side, could you submit questions at https://my.slack.com/help/requests/new instead. :bow:
Please read the Contributing guidelines and Code of Conduct before creating this issue or pull request. By submitting, you are agreeing to those rules.

Hi @travishoop - You're not receiving an event_id as described here? I see here that the event is a separate field and does not contain the event id. I wonder if that's what you're seeing when you inspect the event argument passed to the listener by bolt. What happens if you declare payload and look at it's contexts>

This are the values I get back:
Received Message Event with values
 message
 {
  client_msg_id: '1043f866-380c-4dd0-acf2-dd9091e81d58',
  type: 'message',
  text: 'this is a test message I am sending to a public channel',
  user: 'U04L3ME6VMY',
  ts: '1708725482.598159',
  blocks: [ { type: 'rich_text', block_id: 'CTnf8', elements: [Array] } ],
  team: 'T03NC3TG00J',
  channel: 'C04LQVA1Z2P',
  event_ts: '1708725482.598159',
  channel_type: 'channel'
}  context
 {
  userToken: 'xoxp-<redacted>',
  teamId: 'T03NC3TG00J',
  botToken: 'xoxb-<redacted>',
  botId: 'B06E96VAW84',
  botUserId: 'U06E043Q48N',
  userId: 'U04L3ME6VMY',
  isEnterpriseInstall: false,
  retryNum: 2,
  retryReason: 'http_timeout',
  updateConversation: [Function (anonymous)]
} event
 {
  client_msg_id: '1043f866-380c-4dd0-acf2-dd9091e81d58',
  type: 'message',
  text: 'this is a test message I am sending to a public channel',
  user: 'U04L3ME6VMY',
  ts: '1708725482.598159',
  blocks: [ { type: 'rich_text', block_id: 'CTnf8', elements: [Array] } ],
  team: 'T03NC3TG00J',
  channel: 'C04LQVA1Z2P',
  event_ts: '1708725482.598159',
  channel_type: 'channel'
} payload
 {
  client_msg_id: '1043f866-380c-4dd0-acf2-dd9091e81d58',
  type: 'message',
  text: 'this is a test message I am sending to a public channel',
  user: 'U04L3ME6VMY',
  ts: '1708725482.598159',
  blocks: [ { type: 'rich_text', block_id: 'CTnf8', elements: [Array] } ],
  team: 'T03NC3TG00J',
  channel: 'C04LQVA1Z2P',
  event_ts: '1708725482.598159',
  channel_type: 'channel'
}

Looks like the main payload argument is just getting put in all those fields but no envelope meta data is available.
Not sure if that event_ts value can be used in place of event_context. I was assuming that is a different field.

The data I was looking for is in the body argument of the event callback function. This is documented here: https://slack.dev/bolt-js/reference#listener-function-arguments-listener-function-arguments


Testing ordu hooks

I don't see any updates to the test/ordu.js file? this is where I was expecting to see most of your work as per my task document?