feat: Add event to validate the cart before creating an order

1. Why is this change necessary?
Currently it is not possible to validate the cart using an event before the order is created in the order service. Only the event order.create exists where it is not possible to access the cart. Due to the structure of the current code I decided to add an additional event.
2. What does this change do, exactly?
Add the event Shopware\Core\Checkout\Order\Event\OrderCartValidationEvent
3. Describe each step to reproduce the issue or behaviour.
No issue.
4. Please link to the relevant issues (if any).
-
5. Checklist

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

Hey @aragon999
thank you for your contribution! :tada: :blue_heart:
You are completely right that there currently is no cart validate event available, but this is not by accident, but by design.
For validating the cart we have implemented another ExtensionMechanism, called CartValidators. We don't want to introduce two extension mechanisms for the same use cases, therefore i will close your PR.

Hey @keulinho
thank you for your feedback. We are aware of the validators and use them in most of the cases.
But in this case this was not possible, probably of the same reason why the payments are not implemented as validators.
The usecase is that the customer has the ability to choose the delivery on the confirm page, which are specific to the current cart. We implement this using a custom CartBehavior in our CartProcessor.
That works fine so far, the problem occurs if the cart has somehow changed in the meantime, which invalidates the deliveries, but we cannot recompute the deliveries every time the cart is changed, since the information is loaded via an API request which is not really fast. Thus we only want to recompute the deliveries on checkout. Additionally the customer needs to select the preferred way of shipping (e.g. in one complete delivery or in split deliveries).
So if the customer has one tab open of the confirm page with already calculated deliveries and opens another tab and adds a new product, the deliveries are invalidated. If the customer than submits the confirm page I currently see no way to throw an error that the cart has changed and the deliveries have to be recalculated.
Do you see a way to implement this using the validators?

So to sum it up, the issue in your case is that the validators are called too often (as they are always called when something in the cart changes). You only want to run the validation after the checkout confirm page is submitted.
One way i can think of accomplishing that is that you could inject the original request into your validator over the request_stack service and then check that you only run your validations on the frontend.checkout.finish.order route.
Is that feasible for your use case?

Hey @keulinho
This doesn't fit because the errorStruct has to have set "blockOrder" to have the customer be redirected back to the checkout to show him the message. Otherwise, the order is placed. This blockOrder results in no possibility to finish the order :-) But he just needs to re-confirm the order.

Ok so is the use case something like:
You need to prevent the order creation and tell the customer that creating the order was not possible, and maybe notifying him that some fees have changed because of changes in the card and the customer should confirm the order again with the latest data, but the customer himself does not need to adjust something in the cart?
in that case i would suggest adding a specialized flag to the Error class
Something like:
    abstract public function needsReconfirmation():bool
    {
         return false;
    }

and in the OrderPersister we check for errors with the blockOrder OR the needsReconfirmation flag.
the storefront implementation should work as it does now, only setting the disabled attribute on the checkout button if some error is blockOrder but not if it is needsReconfirmation
Does that work for your use case and is the solution understandable for you?
I would prefer that solution, so cart validation always works with the same pattern and not to introduce a second extension pattern here.

Thank you for the update, you are right, we actually solved something similar in the past like this. Although we did not want to use the cart error messages in general, since when there is an active error (which in this case would only be resolved once the customer was on the confirm page) the messages like that a product was added or the quantity has been changed are not displayed, due to this logic: https://github.com/shopware/platform/blob/b3af64e846867dd504a311ecec9d17b5aec0d11f/src/Storefront/Controller/CartLineItemController.php#L153
But we can work around this using an extension of the cart. An event just would have been easier, but maybe this problem is too specific.

Yep i think that problem is pretty specific and we don't want to add a generic event for that, that kinda contradicts the CartValidator pattern, especially if you've already found a workaround.

Okay. I think this is now the third or fourth time that we need to do such a thing.
The biggest pain point is additionally the handling of the messages, not sure if the current behavior is desired or not.
But this would probably require some refactoring (and rethinking of how messages should be handled). Such that one can add an error and still get the messages that a new product has been added or the quantity has been changed. This is a more generic problem, I'd say. But additionally this is unrelated to this PR :-)


[18.09 backport] Fix stopped containers with restart-policy showing as "restarting"

backport of https://github.com/moby/moby/pull/38737 for 18.09
When manually stopping a container with a restart-policy, the container
would show as "restarting" in docker ps whereas its actual state
is "exited".
Stopping a container with a restart policy shows the container as "restarting"
docker run -d --name test --restart unless-stopped busybox false

docker stop test

docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS                       PORTS               NAMES
7e07409fa1d3        busybox             "false"             5 minutes ago       Restarting (1) 4 minutes ago                     test

However, inspecting the same container shows that it's exited:
docker inspect test --format '{{ json .State }}'
{
  "Status": "exited",
  "Running": false,
  "Paused": false,
  "Restarting": false,
  "OOMKilled": false,
  "Dead": false,
  "Pid": 0,
  "ExitCode": 1,
  "Error": "",
  "StartedAt": "2019-02-14T13:26:27.6091648Z",
  "FinishedAt": "2019-02-14T13:26:27.689427Z"
}

And killing the container confirms this;
docker kill test
Error response from daemon: Cannot kill container: test: Container 7e07409fa1d36dc8d8cb8f25cf12ee1168ad9040183b85fafa73ee2c1fcf9361 is not running

docker run -d --name test --restart unless-stopped busybox false

docker stop test

docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS                PORTS               NAMES
d0595237054a        busybox             "false"             5 minutes ago       Restarting (1)       4 minutes ago                       exit

Signed-off-by: Sebastiaan van Stijn<EMAIL_ADDRESS>(cherry picked from commit 8c0ecb638705e89746a81fa1320aafaa7ff701b2)
Signed-off-by: Sebastiaan van Stijn<EMAIL_ADDRESS>
- What I did
- How I did it
- How to verify it
- Description for the changelog

- A picture of a cute animal (not mandatory but encouraged)

@cpuguy83 @tonistiigi PTAL

Lgtm


Auto duplicate opinions when ballot isn't full

To fill the ballot, randomly duplicate previous opinions.

Closed with latest commit.


Revert "Update sysinfo version to 0.32.1 (#16517)"

This reverts commit 3476a9f3a658fe7c8326ca0e618ad543914ca7f4.
Objective
#16517 makes it impossible to select a libc version, now that the "breaking" libc release was yanked
Solution
Revert the version bump so we can select a version of sysinfo that builds (the previous version)

not needed on the 0.15 release


Update domains.txt

@AgentCosmic @vboctor i added more domains based on https://github.com/disposable-email-domains/disposable-email-domains

Thanks @AidenY69 - these are a lot of domains, what is the source you used to figure out all of these domains?


need some guidance

I'm going to be writing hundreds of unittest for all of the capability that exists in securitycenter, so that i can  test against changes as new releases are made.
using the api functions that you have is a good starting point for me. I just need a little guidance on updating settings.
I'm attempting to turn on or set the classification banner.  should i be using post or put?
self.sc.post('configSection/3', json={"LoginMaxAttempts":100,"PasswordMinLength":3,"ServerClassification":"UNCLASSIFIED//FOR OFFICIAL USE ONLY","SessionLimit":15} )

i just need to figure out the pattern to use so that i can create test to update sections, add scanners and repositories, user, etc.

ill have to test this to know personally.  admittedly, you should be able to see the calls yourself using chrome developer mode in the network tab and then making the changes.

closing this due to lack of updates


KEB status updatedAT is not refreshed properly

Expected result

make updatedAT up to date on rutnimes and cld endpoints

Steps to reproduce
Provision Kyma and see updatedAT value.
Example
8 sec and reconiciler failed after 30 minutes of retries.
  {
    "runtimeId": "179dc682-e0d8-44ef-aad2-c959e9862f95",
    "globalAccountId": "e449f875-b5b2-4485-b7c0-98725c0571bf",
    "subaccountId": "3af623d8-034c-4c00-a649-95446014fcc5",
    "subaccountRegion": "cf-eu10",
    "serviceInstanceId": "ee202cd5-b707-44fe-b556-22ed33097b05",
    "serviceClassId": "47c9dcbf-ff30-448e-ab36-d3bad66ba281",
    "serviceClassName": "kymaruntime",
    "servicePlanId": "5cb3d976-b85c-42ea-a636-79cadda109a9",
    "servicePlanName": "preview",
    "status": {
      "createdAt": "2021-10-11T15:42:52.94139Z",
      "updatedAt": "2021-10-11T15:43:00.292993Z",
      "provisioning": {
        "state": "failed",
        "description": "Operation created : Reconciler failed"
      }
    }
  },

Another example:
{
    “runtimeId”: “26f9ffbd-5989-4918-ba94-d0e1dfa9934d”,
    “globalAccountId”: “2358e708-68f0-4af0-94b6-cf4e8407aff8",
    “subaccountId”: “e97a29c9-18f6-4c75-8ef3-4419c6ddee63",
    “subaccountRegion”: “cf-us10-staging”,
    “serviceInstanceId”: “59AE1111-81CB-407D-BAD4-B93259222E1D”,
    “serviceClassId”: “47c9dcbf-ff30-448e-ab36-d3bad66ba281",
    “serviceClassName”: “kymaruntime”,
    “servicePlanId”: “5cb3d976-b85c-42ea-a636-79cadda109a9",
    “servicePlanName”: “preview”,
    “status”: {
      “createdAt”: “2021-12-06T14:07:17.291216Z”,
      “updatedAt”: “2021-12-06T14:07:18.741203Z”,
      “provisioning”: {
        “state”: “succeeded”,
        “description”: “Operation created”
      }
    }
  },

Kyma installed in 1 sec :)

updatedAt (for info/runtime) and modifiedAt (for /runtimes) values are taken from Instance, which is not updated when process finishes (success/failure) - we only update the corresponding Operation data. The Instance data is only updated when suspending/unsuspending, on instance update (for example autoscaler parameters change), on provisioning after getting runtimeID from provisioner. For details, see all usages of
https://github.com/kyma-project/control-plane/blob/1e307c89ca0d37f1b65ec979de7225a3c2b5a3e1/components/kyma-environment-broker/internal/storage/ext.go#L15
Possible solutions are:

calling Update method on each process failure (when OperationFailed method is called) or success (OperationSucceeded or UpdateOperation when all steps finished) without any data changes - updatedAt timestamp will be overwritten here:
https://github.com/kyma-project/control-plane/blob/1e307c89ca0d37f1b65ec979de7225a3c2b5a3e1/components/kyma-environment-broker/internal/storage/postsql/write.go#L77

change the presentation layer to use updatedAt timestamp from latest operation for given instance

extend operations data in the payload to include also updatedAt timestamp (it already has createdAt on /runtimes endpoint, for info/runtimes there's no such data printed) like this:

        "provisioning": {
          "state": "succeeded",
          "description": "Operation created",
          "createdAt": "2021-10-29T14:42:01.810446Z",
          "updatedAt": "2021-10-29T15:42:01.810446Z",
          "operationID": "e7c12049-2482-4bd4-8041-05b7e4b7dd0f"
        },


[META] OIDC federation roadmap for Warehouse

This is meta-issue, tracking different strands of development/design for Warehouse's use of OIDC.
Goals
There are two high-level goals for Warehouse's OIDC work:

Enable "OIDC macaroon minting" for a handful of CI providers, enabling users to configure trusted repositories via OIDC instead of manually provisioning API tokens
Add support for an OIDC IdP to PyPI, allowing it to become its own identity provider for ecosystems like Sigstore

Task 2 is tracked separately under #12466.
Task 1: OIDC macaroon minting
This task has two subtasks: core OIDC support work, and individual support for each CI provider's OIDC IdP.
Core OIDC support work
The core work required for OIDC JWT consumption is tracked under https://github.com/pypi/warehouse/projects/4, and is almost entirely complete (but currently disabled via a feature flag). Some of the key work included additional models and services for OIDC state management, as well as a general refactor of Warehouse's AuthN/AuthZ layers to use Pyramid 2.0-style APIs.
Core refs:

https://github.com/pypi/warehouse/pull/10628
https://github.com/pypi/warehouse/issues/10620
https://github.com/pypi/warehouse/pull/10753
https://github.com/pypi/warehouse/issues/10792
https://github.com/pypi/warehouse/pull/11122
https://github.com/pypi/warehouse/pull/11239
https://github.com/pypi/warehouse/pull/11218

GitHub OIDC macaroon minting
This is also tracked under https://github.com/pypi/warehouse/projects/4.
Core refs:

https://github.com/pypi/warehouse/pull/11272

Once https://github.com/pypi/warehouse/pull/11272 is merged, this will be functionally complete (but again, disabled via a feature flag).
One sidecar feature is OIDC tokens from reusable workflows. This is tracked in https://github.com/pypi/warehouse/issues/11096.
Macaroon minting via other OIDC providers
We currently have support for two other OIDC providers scoped:

GitLab's OIDC provider: https://docs.gitlab.com/ee/integration/openid_connect_provider.html
CircleCI's OIDC provider: https://circleci.com/docs/openid-connect-tokens/

Both of these are currently in the planning phase:

[ ] Each needs a separate tracking issue
[ ] Each requires coordination with their respective teams to ensure that certain JWT constraints are met (e.g., that we can set the aud claim to "pypi")

Adjacent tasks
Separately from these two tasks, there are also separate issues that track usability/UX changes that the OIDC work would benefit from.
Core refs:

https://github.com/pypi/warehouse/issues/11296
https://github.com/pypi/warehouse/issues/11918
https://github.com/pypi/warehouse/issues/12316

cc @di for visibility.

Some follow-on things we'll need to do once this is merged/enabled:

[ ] Update https://github.com/marketplace/actions/pypi-publish and related docs to support this
[ ] Update https://github.com/pypa/twine and related docs to support this
[ ] Update https://github.com/pypa/packaging.python.org/ with a brief guide on using this

Other refs:

#12965 and #13073 for enabling an initial OIDC beta period
#13060 for admin app/view support for OIDC publishers

Just as a reminder to myself: we probably also want to vary the OIDC audience by PyPI's FQDN, e.g. instead of pypi everywhere it should be pypi.org for the main PyPI instance and test.pypi.org for TestPyPI.
This should be easy to do, since we can grab the expected FQDN from warehouse.domain.

Just as a reminder to myself: we probably also want to vary the OIDC audience by PyPI's FQDN, e.g. instead of pypi everywhere it should be pypi.org for the main PyPI instance and test.pypi.org for TestPyPI.

We chatted about this and decided to stick with pypi/testpypi as audiences for PyPI and TestPyPI respectively because this removes the assumption of "one index per domain", which is currently true but might not be true in the future.

See #13148 for another follow-up bugfix.

For anyone following along, you can sign up for the closed beta for this feature here: https://github.com/pypi/warehouse/issues/12965#issuecomment-1440713858.

Some additional prior art to consider here as we roll this out: pub.dev also supports OIDC-based publishing:

https://medium.com/dartlang/screenshots-and-automated-publishing-for-pub-dev-9bceb19edf79
https://dart.dev/tools/pub/automated-publishing

Hmm, their model is interesting: rather than checking the workflow's filename, they only allow tag patterns and accept any workflow so long as it was triggered by a tag event (under the theory that only sufficiently privileged users can cut tags?).
If I'm right, that's a little weaker than our model (since any repo maintainer can cut tags by default, and anybody with commit access can modify a workflow). But the fact that they support tag patterns is a good sign that we should additionally support them 🙂

Looks like GitLab now supports a customizable aud claim: https://docs.gitlab.com/ee/ci/secrets/id_token_authentication.html

For tracking: https://github.com/pypi/warehouse/issues/13551 tracks support for Google Cloud as an OIDC provider, similar to GitHub.

Opened https://github.com/pypi/warehouse/issues/13575 as well, for GitLab support.

Tag patterns would be a great addition to support. We typically kick off a publishing workflow on releases (which create new tags), so the branch-based environment protections are pretty useless. Using protected tags in those cases instead seems to be a better and more secure way to actually control access to PyPI publishing workflows.

Actually in this case it's not even possible to sufficiently secure the PyPI publishing workflows currently. Any deployment branch rule will block the workflow from running when checked out at a tag, unless the branch rule matches the tag itself (e.g. v* seems to work for a tag like v1.7.0). However, this also allows committers to kick off a workflow from any branch that starts with a v, so that's a problem.

Tag patterns would be a great addition to support.

Agreed! This was identified during the beta period as a useful addition, and it's on my feature backlog.

We typically kick off a publishing workflow on releases (which create new tags), so the branch-based environment protections are pretty useless. Using protected tags in those cases instead seems to be a better and more secure way to actually control access to PyPI publishing workflows.

To be clear: it's useless for your case.
That's fine and valid, but there are multiple ways to secure a workflow on GitHub; we started with environment names (and corresponding environment restrictions, like required reviewers) because they impose fewer idiomatic constraints on PyPI users: not everybody releases from a tag (much less a GitHub release), so tag patterns would have been confusing to users who e.g. run a locked-down release workflow manually from a commit once it's ready for release.
The current plan is to support tag patterns as an additional optional constraint, similar to how we added support for environments.

Actually in this case it's not even possible to sufficiently secure the PyPI publishing workflows currently.

Can you say more about your expectations here?
This is why we encourage users to set up required reviewers in their environment, if their threat model is an "untrusted committer" one: regardless of tag or other event source, a required reviewer setup forces a trusted user to manually approve or reject the publishing workflow below it actually runs.
You can see an example of that in action here: https://github.com/pypa/pip-audit/actions/runs/4884995570

Of course, I meant it's not particularly useful in those cases where GitHub releases are used to trigger publishing. I don't doubt there's plenty of other equally viable approaches!
As far as I understood the idea behind environments was to restrict who is able to publish to PyPI, i.e. it's possible to set up restrictions where users with commit rights are unable to obtain an OIDC token to upload an unapproved package. This is because OIDC tokens can be restricted to specific workflows and environments, and environments can add further restrictions, e.g. restricting runs to only the main branch (where one can set up branch protection rules to require reviews for example).
When releasing via GitHub releases, this approach doesn't work because the deployment does not happen from a single branch, it happens from tags (hence the deployment branch rules are inapplicable). With the matching trick we can create a deployment branch rule to restrict runs to the v* "branches" (which are actually tags in this case), however, then anyone with a commit right can create a new branch called v-hack, obtain an OIDC token and push whatever they want to PyPI.
With protected tags we could ensure that only maintainers are able to publish a release. Of course, having a manual approval still works, but we often would prefer to use user roles to restrict who is able to release/publish (instead of adding the friction of manual workflow approvals).

As far as I understood the idea behind environments was to restrict who is able to publish to PyPI, i.e. it's possible to set up restrictions where users with commit rights are unable to obtain an OIDC token to upload an unapproved package. This is because OIDC tokens can be restricted to specific workflows and environments, and environments can add further restrictions, e.g. restricting runs to only the main branch (where one can set up branch protection rules to require reviews for example).

Yep, that's the idea 🙂 -- an environment can include a specific list of people (or teams) that are allowed to run it, which means that someone has to manually approve the workflow (on GitHub's side) before an OIDC token is issued. For example, this is what that looks like on the pip-audit repository:

With protected tags we could ensure that only maintainers are able to publish a release. Of course, having a manual approval still works, but we often would prefer to use user roles to restrict who is able to release/publish (instead of adding the friction of manual workflow approvals).

Making sure I understand: the use case you'd like solved here is removing the manual approval step, right? And tag protections rather than environment protections enable that?
If so, that's perfectly reasonable, and something we want to support!
I can't promise an exact timeline for it, but it was raised during beta testing as well (we added environment support in response, as a starting point), but it's good to know that PyPI users want it and will benefit from it 🙂

Yes, you understand it correctly, the idea is to remove the need for a manual approve step but still have tight control over who is allowed to publish.
It's more of a feeling but I don't like the idea of manual workflow approvals that much because it is a small out-of-context action (as opposed to doing a review of a PR and approving/declining it right away as part of that process). To me it inherently feels more vulnerable to fatigue attacks (e.g. someone triggering multiple valid approval requests in a relatively short amount of time in order to let a malicious execution slip through). A smooth release-based workflow seems more natural to me (maintainer approves a PR, merges it and creates a new release which automatically runs all necessary workflows in the background without having to think about them at all), but I also admit it's probably just a mostly irrational personal preference.

CircleCI now supports a customizable aud claim: https://circleci.com/docs/api/v2/index.html#tag/OIDC-Token-Management

I think I'm going to close this: with #13883 we've removed the feature flag for this, and we're tracking additional providers in https://github.com/pypi/warehouse/issues/13551, https://github.com/pypi/warehouse/issues/13575, and https://github.com/pypi/warehouse/issues/13888.
Thanks everyone for your help rolling this out! 🎉

Is there a separate issue tracking the tag protection support feature that we discussed earlier?

Is there a separate issue tracking the tag protection support feature that we discussed earlier?

Thanks for reminding me -- I'll check for one, but if there isn't then I'll file one.

Thanks again for reminding me @GergelyKalmar; I've opened https://github.com/pypi/warehouse/issues/13911 for tracking.


Question about batched NMS

Hi,
I'm looking into the Mask R-CNN implementation. I see that NMS postprocessing (in the RoI head) is applied to each image individually as seen here. My question is, is it possible to do this in a batched fashion on all images in one go (in order to get a fixed size tensor as output, rather than a list)?
When looking at the get_bboxes method in the bounding box head, it seems that this function is defined for a batch of examples. However, this method is called for each image in a batch individually. Is this because the img_shape and scale_factor differ per image?
The ONNX version of Mask R-CNN seems to do that (apply NMS in one go on all images of a batch), I'm wondering whether this is also possible with the native PyTorch implementation?
Thanks!

Update:
it seems that one favors decoding one-by-one rather than in a batched fashion as seen by the deprecation warning here:

'please use “delta2bbox” instead. In order to improve '
'the decoding speed, the batch function will no '
'longer be supported. '

If you want to do postprocessing in a batch way, you need to modify the whole testing logic. Just have a try.

I just tried out the ONNX version of Mask R-CNN by following the guide. I see it outputs detections of shape (batch_size, max_detections_per_image, 5), e.g. (1, 100, 5). This is ideal, as it outputs fixed size tensors.
I wonder, is the same feasible with the native PyTorch implementation? Cause the ONNX implementation relies on the NonMaxSuppression method, which outputs selected_indices, of shape [num_selected_indices, 3], where each row is of the format [batch_index, class_index, box_index].
However, the PyTorch implementation relies on multiclass_nms, which I'm not sure supports batched inference.

multiclass_nms does not support batched inference. We still need to use a for-loop to do post-processing for each image in MMDetection.


config will not take effect until the project is restarted

I refer to the demo, use spring boot 2.1.9.RELEASE,、spring cloud Finchley.SR1、nacos-config 0.2.1.RELEASE、nacos-server 1.1.3，but naming-server.log show " INFO receive config info: unknown#<IP_ADDRESS>:8848#1571490357672#2"

sorry, it is version problem. using spring cloud Greenwich.RELEASE、spring-cloud-alibaba.version 0.2.1.RELEASE to solve.


Add support for aucmdwin and preview to win_gettype()

@itchyny commented on this pull request.

@@ -10826,7 +10826,10 @@ win_getid([{win} [, {tab}]])				win_getid()

win_gettype([{nr}])					win_gettype()
Return the type of the window:

	"aucmdwin"	autocommand window. Temporary window

			used to execute autocommands.

Thanks for addition but... the types are prefix for window (popup
window, preview window, command(-line) window, unknown window) so I'm
afraid aucmd or autocmd are natural.

You are right "win" is out of place here.  I think "autocmd" reads best.
--
FATHER:    You only killed the bride's father - that's all -
LAUNCELOT: Oh dear, I didn't really mean to...
FATHER:    Didn't mean to?  You put your sword right through his head!
LAUNCELOT: Gosh - Is he all right?
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar --<EMAIL_ADDRESS>-- http://www.Moolenaar.net   \
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \
\\  an exciting new programming language -- http://www.Zimbu.org        ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

Thank you for fixing (https://github.com/vim/vim/commit/40a019f157c549dcdc17c33f082975485567bb06).


Incorporate changelog for pregnancy and clinic models, in addition to patient model

Right now, the change_log partial in the pregnancy edit view is only really displaying changes made to the patient object, such as name and phone number. We should adjust so that changes to pregnancy and clinic objects are represented here as well.
Full description TK.

Cutting this corner -- this won't be in for MVP on Monday, sorry @lwaldsc

Backlogging


[1.13] Automated Bump DC/OS UI v2.82.9

High-level description
What features does this change enable? What bugs does this change fix?
Corresponding DC/OS tickets (required)
DCOS-54937
Related tickets (optional)

DCOS-54937
Checklist for component/package updates:
If you are changing components or packages in DC/OS (e.g. you are bumping the sha or ref of anything underneath packages), then in addition to the above please also include:

[ ] Change log from the last version integrated (this should be a link to commits for easy verification and review): example
[ ] Included a test which will fail if code is reverted but test is not. If there is no test please explain.
[ ] Test Results: [link to CI job test results for component]
[ ] Code Coverage (if available): [link to code coverage report]

Please update CHANGES.md file (Add or update DC/OS UI line in Notable Changes section of newest version).
* Updated DC/OS UI to [1.13+v2.82.9](https://github.com/dcos/dcos-ui/releases/tag/1.13+v2.82.9).

You can edit CHANGES.md directly here: https://github.com/mesosphere/dcos/edit/dcos-ui/bump/2019-08-12-07-45-08/1.13+v2.82.9/CHANGES.md?pr=%2Fdcos%2Fdcos%2Fpull%2F6057

@mesosphere-mergebot label [Ready for Review]


Feature: support Young & Coppersmith for subduction inversion experiments

Agree arguments and configure SubductionTargetMFD constraints and API/  Runzi configs

wrong project! see https://github.com/GNS-Science/nzshm-opensha/issues/47


Crash when attempting to import .ogg OGG Theora video as OGG Vorbis

Godot version
4.0.dev (fd5fb7d64)
System information
Linux, Mageia 9 x86_64
Issue description
Godot matches files to resource loaders based on their extension, and .ogg files are matched with the OGG Vorbis loader.
But .ogg is also a valid extension for OGG Theora video files (next to .ogv which we support) and therefore users can attempting importing .ogg video files in Godot, which goes through ResourceImporterOGGVorbis (see #56895).
The current error reporting in such situation is subpar, and in master it's actually even crashing:
WARNING: Found a non-vorbis-header packet in a header position
     at: import (modules/vorbis/resource_importer_ogg_vorbis.cpp:163)
free(): invalid pointer

Thread 1 "godot-git" received signal SIGABRT, Aborted.
0x00007ffff7aebc0c in __pthread_kill_implementation () from /lib64/libc.so.6

(gdb) bt
#0  0x00007ffff7aebc0c in __pthread_kill_implementation () from /lib64/libc.so.6
#1  0x00007ffff7aa2102 in raise () from /lib64/libc.so.6
#2  0x00007ffff7a8e43b in abort () from /lib64/libc.so.6
#3  0x00007ffff7ae0700 in __libc_message () from /lib64/libc.so.6
#4  0x00007ffff7af4dfa in malloc_printerr () from /lib64/libc.so.6
#5  0x00007ffff7af6464 in _int_free () from /lib64/libc.so.6
#6  0x00007ffff7af8b91 in free () from /lib64/libc.so.6
#7  0x0000000002cc10a9 in ogg_stream_destroy (os=0x7fffffffb430) at thirdparty/libogg/framing.c:176
#8  0x00000000027ba516 in ResourceImporterOGGVorbis::import (this=0xcc43150, p_source_file=..., p_save_path=..., p_options=..., r_platform_variants=0x7fffffffb8a8, r_gen_files=0x7fffffffb8a0,
    r_metadata=0x7fffffffb880) at modules/vorbis/resource_importer_ogg_vorbis.cpp:165
#9  0x00000000038a0882 in EditorFileSystem::_reimport_file (this=0xdbc7f20, p_file=..., p_custom_options=0x0, p_custom_importer=...) at editor/editor_file_system.cpp:1882
#10 0x00000000038a3b35 in EditorFileSystem::reimport_files (this=0xdbc7f20, p_files=...) at editor/editor_file_system.cpp:2099
#11 0x00000000038942fc in EditorFileSystem::_update_scan_actions (this=0xdbc7f20) at editor/editor_file_system.cpp:626
#12 0x0000000003899273 in EditorFileSystem::_notification (this=0xdbc7f20, p_what=17) at editor/editor_file_system.cpp:1214
#13 0x00000000038a838e in EditorFileSystem::_notificationv (this=0xdbc7f20, p_notification=17, p_reversed=false) at editor/editor_file_system.h:113
#14 0x00000000062bce03 in Object::notification (this=0xdbc7f20, p_notification=17, p_reversed=false) at core/object/object.cpp:846
#15 0x00000000047fb67b in SceneTree::_notify_group_pause (this=0xcd5afa0, p_group=..., p_notification=17) at scene/main/scene_tree.cpp:855
#16 0x00000000047f9904 in SceneTree::process (this=0xcd5afa0, p_time=0.14221099999999964) at scene/main/scene_tree.cpp:453
#17 0x00000000023ab7a6 in Main::iteration () at main/main.cpp:2691
#18 0x0000000002366e6d in OS_LinuxBSD::run (this=0x7fffffffd180) at platform/linuxbsd/os_linuxbsd.cpp:342
#19 0x00000000023634cc in main (argc=2, argv=0x7fffffffd6e8) at platform/linuxbsd/godot_linuxbsd.cpp:58

Two things need to be done:

The crash should be fixed
The error reporting for the whole vorbis module could use some love as it seems to overly depend on WARN_PRINT to report things which are actually fatal bugs. Most importantly, errors which can be triggered by end users under reasonable use conditions should be given explicit and helpful messages (see e.g. #56903).

Steps to reproduce

Load MRP, or any (?) OGG Theora file with .ogg extension (an .ogv OGG Theora file can be renamed to trigger the issue)

Minimal reproduction project
OggTheoraCrashesVorbis.zip

Oh I think I stumbled on this when testing an ogg from the web some time ago. If you want I can find it.


Don't lookup big foreign assets.

Summary
We missed the common code path in the previous hotfix, this is the same fix as before but we avoid adding these assets and apps to begin with.

@algobarb helped me run this on the stuck testnet node, it seems to be working.


Support Stripe 5 - 2v

Pull Request
Related issue

Add support to Strapi 5;
Watch: https://www.youtube.com/watch?v=ZLtyiqC_6Qo
npx @strapi/upgrade@rc codemods run --project-path ./src/plugins/strapi-plugin-meilisearch

What does this PR do?

[x] Upgrade deps;
[x] Replace EntityServiceAPI with DocumentServiceAPI: https://docs.strapi.io/dev-docs/migration/v4-to-v5/additional-resources/from-entity-service-to-document-service;
[x] Removed @strapi/helper-plugin: https://docs.strapi.io/dev-docs/migration/v4-to-v5/additional-resources/helper-plugin
[x] Renamed React files to js for jsx;
[x] Deleted PluginHeader because BaseHeaderLayout isn't exported;
[x] npm run build;
[x] npm run develop;
[ ] Other issues;

I'm stuck in this piece:

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

[ ] Does this PR fix an existing issue, or have you listed the changes applied in the PR description (and why they are needed)?
[ ] Have you read the contributing guidelines?
[ ] Have you made sure that the title is accurate and descriptive of the changes?

Thank you so much for contributing to Meilisearch!

@curquiza , could you help me to find this issue?
How reproduce the isse

Create a new Strapi 5 project npx create-strapi@latest my-strapi-project;
Git clone my repository in /src/plugins: git clone https://github.com/candidosales/strapi-plugin-meilisearch
Switch to my branch for support-strapi-5-2v in src/plugins/strapi-plugin-meilisearch; and install dependencies from the plugin and project npm install;
Back to the root folder of the strapi project and npm run build, later npm run develop;
Navigate to meilisearch page, you will see the issue;

I thought the issue was related to the metasearch config missing the collections, but it wasn't. My second assumption is related to useFetchClient; the method works differently from the request method.

@candidosales Hi can you try out the version from #964

If everyone agree I close this PR in favor of #964


Fix LEC

Not sure how you want to fix this, but this patch partially undoes a recent change:
-    if { [catch {exec $::env(SYNTH_BIN) -c $::env(SCRIPTS_DIR)/yosys/logic_equiv_check.tcl -l $log |& tee $::env(TERMINAL_OUTPUT)} ]}
 {
+    if { [run_yosys_script $::env(SCRIPTS_DIR)/yosys/logic_equiv_check.tcl -indexed_log $log]} {

There is no output from run_yosys_script, so it doesn't make sense to use it in a conditional. The current failure:
expected boolean value but got ""
    while executing
"if { [run_yosys_script $::env(SCRIPTS_DIR)/yosys/logic_equiv_check.tcl -indexed_log $log]} {
        puts_err "$::env(LEC_LHS_NETLIST) is not logicall..."
    (procedure "logic_equiv_check" line 31)
    invoked from within

@antonblanchard I think the intent was
    if { [catch {run_yosys_script $::env(SCRIPTS_DIR)/yosys/logic_equiv_check.tcl -indexed_log $log}] } {

Does that work for you ?


Enum types are not checked in binary operators

I ran into this for real while trying to fix a bug in the compiler. We disallow assigning one enum to another if you use the = operator. But we do not disallow it for any of the compound assignment operators. Nor do we disallow for bitwise operators. I think we should disallow all of them.
enum E { }
enum F { }

var e: E;
var f: F;

e = f; // Error
e |= f; // No error
var g = e | f; // No error, g is number

Looks like a regression in 1.1 from 1.0. this would be a breaking change now though.

Currently it is possible to specify ordinal values:
enum AlertButtons {
    OK = 1,
    YES = 2,
    NO = 4,
    CANCEL = 8
}

Enums are already limited in many aspects (just compare with Java enums) , disallowing bitwise operators would make them even more useless.

@kemsky the proposal isn't to disallow bitwise operators on enums. It's to disallow bitwise operators between different enums.

@RyanCavanaugh, i was not clear enough, my concern is only last line of example (it might have little sense, but in general there is nothing wrong):
var g = e | f; // No error, g is number

It is more important not to break the following statements:
var buttons = 1;
var isOk = (buttons | AlertButtons.OK) === AlertButtons.OK;

Operations between number and enum would still be allowed. The only thing to disallow is operators where both sides are enums and they are not the same enum type.


PERF: regression in transform perf

from SO
import pandas as pd
import numpy as np

df = pd.DataFrame({'group': np.repeat(np.arange(1000), 10),
                   'B': np.nan,
                   'C': np.nan})

df.ix[4::10, 'B':'C'] = 5 # every 4th row of a group is non-null

df.groupby('group').transform('first')

This is then iterating over groups. Last I can see this was changed is: here. My recollection is that this was ONLY supposed to hit in a special case, and the general case is simply a repeat based on the indices.
This seems to be hitting in all cases makes transform back to super SLOW.

cc @ajcr
cc @chris-b1
cc @evanpw

So we have a fast path for Series transforms, but not for DataFrame (on the same block) transforms.
In [17]: result1 = g.transform('first')

In [18]: result2 = pd.concat([g.B.transform('first'), g.C.transform('first')], keys=['B','C'], axis=1)

In [19]: result1.equals(result2)
Out[19]: True

In [20]: %timeit g.transform('first')
10 loops, best of 3: 170 ms per loop

In [21]: %timeit pd.concat([g.B.transform('first'), g.C.transform('first')], keys=['B','C'], axis=1)
1000 loops, best of 3: 2 ms per loop


Make linux 3rd party dependencies Static

This will solve a plethora of problems that are too hard to explain.
Make sure it doesn't break windows.

This may actually be impossible with some of the licenses that we are using.

This actually introduces nasty licensing issues. Forget it.


power-to-liquid process /  power-to-ammonia system / power-to-fuel process / power-to-fuel system

Description of the issue
We have:

And:

To have a parallel structure, we should add power-to-liquid process and power-to-ammonia system.
We might further think about adding power-to-fuel process and power-to-fuel system as superclasses for power-to-gas process/power-to-fuel process respectively power-to-gas system/power-to-fuel system.
Ideas of solution
We should add:

power-to-liquid process: A power-to-liquid process is an energy transformation that converts electrical energy to chemical energy by synthesising portions of matter into a liquid synthetic fuel.
power-to-ammonia system: A power-to-ammonia system is a power-to-gas system that implements the power-to-ammonia process.

We might add:

power-to fuel process: A power-to-fuel process is an energy transformation that converts electrical energy to chemical energy by synthesising portions of matter into a synthetic fuel.
power-to-fuel system: A power-to-fuel system is an energy transformation unit that implements a power-to-fuel process. A water electrolyser is participating in the power-to-fuel process.

Workflow checklist

[ ] I discussed the issue with someone else than me before working on a solution
[ ] I already read the latest version of the workflow for this repository
[ ] The goal of this ontology is clear to me

I am aware that

[ ] every entry in the ontology should have a definition
[ ] classes should arise from concepts rather than from words

@stap-m : Do you have any thoughts on this? This issue is basically some gap-filling so I assume we do not need a lot of discussion here.
@u-mueller : If we agree on this issue, you can implement this. It should be an easy implementation.

@stap-m : I agree to the proposed changes and will implement.

One question arose while implementing: Shouldn't the definitions of the new subclasses refer to their newly added parent class?:
power-to-liquid process :  A power-to-liquid process is a power-to-fuel process that converts electrical energy to chemical energy by synthesising portions of matter into a liquid synthetic fuel.

@stap-m und @l-emele, can you have a look at my comment? Thanks!

One question arose while implementing: Shouldn't the definitions of the new subclasses refer to their newly added parent class?: power-to-liquid process : A power-to-liquid process is a power-to-fuel process that converts electrical energy to chemical energy by synthesising portions of matter into a liquid synthetic fuel.

If we agree on adding power-to-fuel process (and power-to-fuel system), then the answer is: yes.

EDIT: If agree on adding power-to-fuel process and power-to-fuel system then also the existing power-to-X classes have to be adapted.

The power-to-X classes ("ammonia" and "methane") still correctly refer to power-to-gas process, or do I get something wrong?

If we agree on adding power-to-fuel process (and power-to-fuel system), then the answer is: yes.

I think it's good to add power-to-fuel process and power-to-fuel system. But we might also add power-to-X process and power-to-X system as equivalent terms? Both terms (power-to-fuel and power-to-X are widely used.

To precise: Only the definitions of those existing power-to-X class that will be direct subclasses of power-to-fuel process and power-to-fuel system needs to be adapted. Power-to-methane and power-to-ammonia will still refer to power-to-gas. So in the end we should have:

power-to-fuel process/system

power-to-gas process/system

power-to-ammonia process/system
power-to-methane process/system

power-to-liquid process/system

That's exactly what I mean, thanks!

I think it's good to add power-to-fuel process and power-to-fuel system. But we might also add power-to-X process and power-to-X system as equivalent terms? Both terms (power-to-fuel and power-to-X are widely used.

In my understanding power-to-X can mean anything and is not limited to power-to-fuel. Wikipedia lists even power-to-power.

You're right, so we don't use it.

You're right, so we don't use it.


Generate Resource and Image azure-arm.image: ERROR: -> Forbidden : Client address is not authorized and caller is not a trusted service.

Description
We generate windows 2022 images as part of the vmsscaleset create.
This has been working well up through last month. We attempted to run the process yesterday and at the GenerateResourceandImage step, a pkr key vault is created and the release fails with the following error:
2024-02-21T14:14:40.2381921Z ==> azure-arm.image: ERROR: -> Forbidden : Client address is not authorized and caller is not a trusted service.
2024-02-21T14:14:40.2383882Z ==> azure-arm.image: Client address: x.x.x.x from unknown subnet
2024-02-21T14:14:40.2385671Z ==> azure-arm.image: Caller: appid=;oid=29e1fbed-ab6d-4741-8d3f-48590f5943c0;iss=https://sts.windows.net/
where the IP address is our self-hosted agent. I replaced x.x.x.x with our real IP.
We have a ubuntu process that is working fine but that uses ssh over 172.x address.
Platforms affected

[X] Azure DevOps
[ ] GitHub Actions - Standard Runners
[ ] GitHub Actions - Larger Runners

Runner images affected

[ ] Ubuntu 20.04
[ ] Ubuntu 22.04
[ ] macOS 11
[ ] macOS 12
[ ] macOS 13
[ ] macOS 13 Arm64
[ ] macOS 14
[ ] macOS 14 Arm64
[ ] Windows Server 2019
[X] Windows Server 2022

Image version and build link
runner image is based in git clone of todays date from main.
Is it regression?
yes. We were able to build as of Janmuary 08, 2024.
Expected behavior
build completes and image generated without error.
Actual behavior
see above.
Repro steps
execute GenerateandResourceImage.ps1 step on our self hosted agent VM.

Hello @greadtm . Unfortunately its hard to determinate what exactly goes wrong in your case. As you can see our nightly build fished without error. Possible it can be specific network or security restriction or etc in you subscription .

Hello @greadtm. I could not reproduce the issue. Please find below the parameters I have used to generate an image:
       -SubscriptionId $SubscriptionId `
       -ResourceGroupName $ResourceGroupName -ImageGenerationRepositoryRoot "./" `
       -ImageType "Windows2022" -azurelocation $location `
       -AzureClientId $CLIENT_ID `
       -AzureClientSecret $clientSecret `
       -AzureTenantId $AZURE_TENANT

with the next GitHub workflow:

on:
    workflow_dispatch

permissions:
  id-token: write
  contents: read

jobs:
  repro:
    runs-on: ubuntu-latest
    environment: testing-images-ci
    steps:
      - uses: actions/checkout@v4
        with:
          repository: actions/runner-images

      - name: Azure login
        uses: azure/login@v1
        with:
          client-id: ${{ secrets.CLIENT_ID }}
          tenant-id: ${{ secrets.TENANT_ID }}
          subscription-id: ${{ secrets.SUBSCRIPTION_ID }}
          enable-AzPSSession: true
      - name: run imagegeneration
        shell: pwsh
        run: |
           Import-Module ./helpers/GenerateResourcesAndImage.ps1
           GenerateResourcesAndImage <parameters provided above>

It is impossible for us to reproduce this steps in azure devops, but since the images for both platforms are the same and  the GenerateResourcesAndImage.ps1 was not changed recently, I assume the platform does not matter.
To investigate the problem further, could you please try new deployment and if it fails send us the Deployment logs from Azure side. You can find them under resource group Deployments tab. How to...

I do not believe this is a code issue with the PS.
I have a RG in Azure that has a defaulting VNET. I have relaxed the service endpoints so there is no keyvault firewall.
I created a new VNET/subnet to look like the one we were using.
I setup the packer.json to specify, the VNET name, VNET subnet name, and build image resource group.
When I run the release/GenerateResourceandImage.ps1 with the proper params like I have done in the past, I get the following error:
Getting the certificate's URL ...
2024-02-27T20:39:54.8581459Z ==> azure-arm.image: -> Key Vault Name : 'pkrkvztifzt2p81'
2024-02-27T20:39:54.8583086Z ==> azure-arm.image: -> Key Vault Secret Name : 'packerKeyVaultSecret'
2024-02-27T20:39:54.9360793Z ==> azure-arm.image: ERROR: -> Forbidden : Client address is not authorized and caller is not a trusted service.
2024-02-27T20:39:54.9361545Z ==> azure-arm.image: Client address: x.x.x.x from unknown subnet
2024-02-27T20:39:54.9364202Z ==> azure-arm.image: Caller: appid=;oid=29e1fbed-ab6d-4741-8d3f-48590f5943c0;iss=https://sts.windows.net//
2024-02-27T20:39:54.9364737Z ==> azure-arm.image: Vault: pkrkvztifzt2p81;location=eastus2
where x.x.x.x=private IP address of our on prem(in Azure) build agent.
I am not sure why the script is sourcing the private IP address of the hosted build server vs a public IP. Note: this is happening for windows 2022. I can run for ubuntu image fine. Although the latter seems to use ssh to connect.


Prompt to overwrite if CIA with the same title ID is installed

Just an idea for a feature. If a CIA with the same Title ID is installed, prompt to ask if it should be overwritten. Or only if the name/short desc/long desc differ? Idk. I figured this would be a cool addition.

FBI already overwrites by default.

I know that. Because some CIAs might be different apps AND share a Title ID, I thought it'd be a good idea to TELL or ASK before doing so. That's what I mean.

That two CIAs would share a title ID is itself a problem that should be corrected, and isn't really something I think FBI should have to consider.


React Implementation Snippet

Can you give a code snippet to use this in React/next js?
I have tried to follow a lot of the ones online which use this package but none on of them seem to be working.

What do you mean by code snippets, If you want to see my notes or in progress projects you might see this React Notes and also checkout Machine Learning notes if you want to progress or contribute in it!!
Ask anytime for help
Happy Coding :)


non-ASCII in env file

The env value been dumped when I push env to my server.
env:
  clear:
    ENV_TEST: 中个

In server env file I got this:
ENV_TEST= \u4E2D\u4E2A

The value been dumped at   lib/kamal/env_file.rb:39

I found this bug since mrsk was issued, Shellescape can fix this https://github.com/basecamp/kamal/pull/750

I found this bug since mrsk was issued, Shellescape can fix this #750

This is not a good fix, also makes some other problems. I will try to fix it in another way

Here the PR can fix this issue


install: static: release tab points to page with no static instrs

afaict, our static release balls on our releases page point to our docs repo install page, but nowhere on that page does it say how to install the static binary ball?
I was looking at the v1.6.3 section on the release page.
Maybe I'm missing something?
/cc @egernst @jcvenegas

@grahamwhaley we dont have documentation for that we should add it.


Vorbis: Add mapping for InitialKey

Fixes #90 so that we don't need to keep that issue around.
TODO

[x] Add read/write tests

Thanks!


Add client-side oauth support and docs

Should be pretty trivial, just need to add support and good docs about how to use it.

Hey, will you be implementing this in the near future? would be incredible!

done - see https://theoephraim.github.io/node-google-spreadsheet/#/getting-started/authentication?id=oauth for more details


Add MinIO.Client 2024.01.18

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?
[x] This PR only modifies one (1) manifest
[x] Have you validated your manifest locally with winget validate --manifest <path>?

[x] Does your manifest conform to the 1.5 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

Automatic Validation ended with:

No errors to post.

(Automated response - build 655.)

Please add dl.min.io to allow list, as described in https://min.io/download#/windows

Automatic Validation ended with:

No errors to post.

(Automated response - build 656.)

Please add dl.min.io to allow list, as described in https://min.io/download#/windows

The general requirement is that anyone can navigate from the PackageUrl to the InstallerUrl, or failing that, find the package easily on the developer's website. An Internet search for min.io archive brought me to this archive page, which has the package on it. This satisfies our requirement.

@wingetbot waivers Add Validation-Executable-Error


[BUG] Vulnerability Assessment API error with last_sync_ts

Good afternoon,
I have found  the following problem in the vulnerability assessment API. Using the request to get an asset view with vulnerability summary (POST /vulnerability/assessment/api/v1/orgs/{org_key}/devices/vulnerabilities/summary/_search)  and adding the field "last_sync_ts" as criteria in the request body to filter with datetime, it returns a 500 error with an empty message, without indicating what happens or the reason for the error. Tested with other fields and these have worked successfully, we think that this is an error of either the API or the documentation. Any help with this is greatly appreciated, thanks!
Attached the request body  that was used:
{
    "query": "",
    "rows": 20,
    "start": 0,
    "criteria": {
      "last_sync_ts": {
        "value": "2021-09-21T12:43:46.055575Z",
        "operator": "GREATER_THAN"
      }
    },
    "sort": [
    {
     "field": "last_sync_ts",
      "order": "ASC"
    }
    ]
}

https://developer.carbonblack.com/reference/carbon-black-cloud/platform/latest/vulnerability-assessment/#criteria

Hello
I'm currently working with the Vulnerabilities API and have just ran into this issue. Is there any status on the solution yet?
Thanks.

Just tested and I'm having the exact same problem. When using last_sync_ts as criteria you get a 500 Internal Server error.

Hi geeks, good morning. I am working with this API and have a problem with this criteria, last_sync_ts , can this problem be corrected or how should I proceed?
Thanks!

Hi, apologies for the delay on closing this out - the issue has been fixed and works correctly.


Incorrect output of getindex(ts::TS, y::Year, m::Month, w::Week)

julia> ts[Year(2022), Month(8), Week(1)]
(0 x 1) TS with Date Index

But, the following returns correct output:
julia> ts[Year(2022), Month(8), Week(32)]
(7 x 1) TS with Date Index

 Index       x1
 Date        Float64
───────────────────────
 2022-08-08   0.647277
 2022-08-09   0.800605
 2022-08-10   0.698464
 2022-08-11   0.868943
 2022-08-12   0.510194
 2022-08-13   2.4704
 2022-08-14  -0.86813

This is because Dates.week() returns the $N^th$ of the year and not within the month. This getindex() method should just take year and week as arguments so that the functionality is clear.
function getindex(ts::TS, y::Year, w::Week)

Should this be even done? This will go against how Julia Dates.Week works and maybe confusing for users.


Problem in the cluster

Hi Luca,
I have been trying to test the pipeline in the cluster, and it gives me this error when I use "$RUN python --version" with singularity 2.6.1:
ERROR  : Installation error, run the following commands as root to fix:
ERROR  :     sudo chown root:root /nfs/software/as/el7.2/EasyBuild/CRG/software/Singularity/2.6.1/libexec/singularity/bin/action-suid
ERROR  :     sudo chmod 4755 /nfs/software/as/el7.2/EasyBuild/CRG/software/Singularity/2.6.1/libexec/singularity/bin/action-suid ABORT  : Retval = 255
And if I use singularity 3.2.1 I get this message:
ERROR  : Can't open /proc/self/auxv: Permission denied
I remember running the pipeline in the cluster one month ago and everything was working properly, do you know what can be the problem now?
Thank you very much,

mmm which image are you using (the latest is 0.4) and from which node?

I tried both nextflow node and ant-login and I had no problem...

Yes, I am using 0.4, and I was running it in the ant-login, because I can't even do qlogin, so the problem is mine, I will talk to IT.
Thanks and sorry for the inconvenience,


Dynamic colors in Title and Pager

Using the basic default implementation it doesn't seem like the Title text and the Pager dots use the correct dynamic colors for night mode.

Hey @massimobio, can you share the code that you've written to set the title and page indicator colors? I can't seem to recreate this when using system colors (they seem to change correctly), so I want to make sure I can accommodate your use case.

Hi @mergesort, thanks for the quick reply.
I didn't add any formatting. I was doing an initial test with the examples in the README to see if Recap would work in my app but I'm using it in UIKit which might be the issue?
let recapView = RecapScreen(releases: .appReleases)
let hostingController = UIHostingController(rootView: recapView)
splitViewController.present(hostingController, animated: true, completion: nil)

adding the formatting you suggested fixes the title coloring
RecapScreen(releases: .appReleases).recapScreenTitleStyle(.foreground)
but the Pager dots are still the wrong color in dark mode retaining the light mode colors.
I'm not too versed in SwiftUI but I noticed you used Color.black for the recapScreenTitleStyle and SelectedPageIndicatorColorKey, while in the FeatureRow you use the system .primary and .secondary for the text. Might be the issue?

Thank you for sharing the code and providing some good thoughts from your debugging process! You are spot on with your assessment, this was an issue of poorly chosen defaults.
Based on your suggestion, I went ahead and changed the recapScreenTitleStyle like this.
// Before
private struct TitleStyleKey: EnvironmentKey {
    static let defaultValue = AnyShapeStyle(Color.black)
}

// After
private struct TitleStyleKey: EnvironmentKey {
    static let defaultValue = AnyShapeStyle(ForegroundStyle.foreground)
}

And updated the default recapScreenSelectedPageIndicatorColor like so.
// Before
private struct SelectedPageIndicatorColorKey: EnvironmentKey {
    static let defaultValue = Color.black
}

// After
private struct SelectedPageIndicatorColorKey: EnvironmentKey {
    static let defaultValue = Color.primary
}

This seems to work well in my testing, so I felt confident pushing up a change to the main branch. Could I ask you to test and see if that works well for you in your UIKit app? If so, I'll create a new release tomorrow that incorporates these changes.

Yes! It's all good now. Thank you!

Perfect! I've pushed out version 1.1.3, which should have the fix above, based on your suggestions. Thank you so much @massimobio. 🙂


How to reference built assets?

The assets now have paths like:
  <link rel="stylesheet" href="{{rootURL}}assets/vendor.css">
  <link rel="stylesheet" href="{{rootURL}}assets/website.css">

How can I reference these with this addon to inline them?

@gdub22 any advice?

inlineContent: {
  vendorCSS: '/dist/assets/vendor.css',
  websiteCSS: '/dist/assets/website.css'
}

@gdub22 this doesn't seem to work. Isn't inlining the content part of generating the dist? Therefore, wouldn't there be no dist?

It's working.  Make sure you place {{content-for "vendorCSS"}} placeholders, etc in your index.html.  See README.

@gdub22 it does not work for me. It only works if you have previously run a build. The dist is not generated until you build. Blow away your dist and run a new build and you will see it does not work.

Ah ok, not sure if possible then. PRs welcome if you figure it out.

Don't think it is possible without running two builds or doing something to hijack the build

I do not think this is possible without doing some custom build stuff and essentially running the build twice, so going to close.

Could this addon be configured to run after the dist is generated? Inlining the built, minified styled would be great.

@oskarrough Did you have any success getting this working? I would love to be able to inline my minified app css straight into the index.html

@ianpetzer nah, couldn't figure it out. I ended up doing this https://gist.github.com/oskarrough/02833da29934ad34c1615ea2a15ff82e

@oskarrough That looks really interesting. Thanks so much!


UI: Workflow pagination display is off by 1

This is trivial, but the "from" value is zero-based while the "to" value is 1-based:

Displaying 0 to 100 should be Displaying 1 to 100.

Displaying 100 to 181 should be Displaying 101 to 181.

Thanks for the feedback. We will add a fix for this.


Variable Panel part 3

For #

[ ] Pull request represents a single change (i.e. not fixing disparate/unrelated things in a single PR).
[ ] Title summarizes what is changing.
[ ] Has a news entry file (remember to thank yourself!).
[ ] Appropriate comments and documentation strings in the code.
[ ] Has sufficient logging.
[ ] Has telemetry for enhancements.
[ ] Unit tests & system/integration tests are added/updated.
[ ] Test plan is updated as appropriate.
[ ] package-lock.json has been regenerated by running npm install (if dependencies have changed).

This is the next stage of the variable panel work, and now has most of the functionality hooked up. Variables are now hooked up, variables update on execute and change when swapping between active documents. Also the data frame viewer is hooked up.
There are two remaining planned chunks of work:

[ ] Adding Tests
[ ] UI clean up (there is still an open button for easy refresh testing, it's still trying to use existing height / width mechanisms instead of filling the view space)

I plan on tackling them in that order. Plus any other issue that come up. Already have one question on what we should do when changing active document to a editor that has not yet executed to one that has.

This is the next stage of the variable panel work, and now has most of the functionality hooked up. Variables are now hooked up, variables update on execute and change when swapping between active documents. Also the data frame viewer is hooked up.
There are two remaining planned chunks of work:

[ ] Adding Tests
[ ] UI clean up (there is still an open button for easy refresh testing, it's still trying to use existing height / width mechanisms instead of filling the view space)

I plan on tackling them in that order. Plus any other issue that come up. Already have one question on what we should do when changing active document to a editor that has not yet executed to one that has.

Codecov Report

Merging #4284 (50dea89) into main (c6d8c47) will increase coverage by 2%.
The diff coverage is 37%.

@@          Coverage Diff           @@
##            main   #4284    +/-   ##
======================================
+ Coverage     71%     73%    +2%
======================================
  Files        384     384
  Lines      25163   25247    +84
  Branches    3597    3608    +11
======================================
+ Hits       17884   18519   +635
+ Misses      5879    5311   -568
- Partials    1400    1417    +17

Impacted Files
Coverage Δ

.../datascience/interactive-common/synchronization.ts
84% <ø> (ø)

...lient/datascience/jupyter/kernels/cellExecution.ts
7% <0%> (-1%)
:arrow_down:

src/client/datascience/variablesView/types.ts
100% <ø> (ø)

...c/client/datascience/variablesView/variableView.ts
21% <12%> (-11%)
:arrow_down:

...ience/interactive-common/interactiveWindowTypes.ts
100% <100%> (ø)

src/client/datascience/notebookExtensibility.ts
95% <100%> (ø)

.../datascience/variablesView/variableViewProvider.ts
84% <100%> (+8%)
:arrow_up:

...t/common/variables/environmentVariablesProvider.ts
77% <0%> (-4%)
:arrow_down:

src/client/datascience/jupyter/jupyterSession.ts
82% <0%> (-4%)
:arrow_down:

...ient/datascience/interactive-ipynb/nativeEditor.ts
73% <0%> (-3%)
:arrow_down:

... and 67 more

Codecov Report

Merging #4284 (50dea89) into main (c6d8c47) will increase coverage by 2%.
The diff coverage is 37%.

@@          Coverage Diff           @@
##            main   #4284    +/-   ##
======================================
+ Coverage     71%     73%    +2%
======================================
  Files        384     384
  Lines      25163   25247    +84
  Branches    3597    3608    +11
======================================
+ Hits       17884   18519   +635
+ Misses      5879    5311   -568
- Partials    1400    1417    +17

Impacted Files
Coverage Δ

.../datascience/interactive-common/synchronization.ts
84% <ø> (ø)

...lient/datascience/jupyter/kernels/cellExecution.ts
7% <0%> (-1%)
:arrow_down:

src/client/datascience/variablesView/types.ts
100% <ø> (ø)

...c/client/datascience/variablesView/variableView.ts
21% <12%> (-11%)
:arrow_down:

...ience/interactive-common/interactiveWindowTypes.ts
100% <100%> (ø)

src/client/datascience/notebookExtensibility.ts
95% <100%> (ø)

.../datascience/variablesView/variableViewProvider.ts
84% <100%> (+8%)
:arrow_up:

...t/common/variables/environmentVariablesProvider.ts
77% <0%> (-4%)
:arrow_down:

src/client/datascience/jupyter/jupyterSession.ts
82% <0%> (-4%)
:arrow_down:

...ient/datascience/interactive-ipynb/nativeEditor.ts
73% <0%> (-3%)
:arrow_down:

... and 67 more

Only test failure was widgets test failure so merging.

Only test failure was widgets test failure so merging.


Can't subst $( in Textfile

Describe the bug
Generating .NET Core csproj files I needed to insert this string literal into the output
NETCore\bin\$(Platform)\$(Configuration)\
But there does not seem to be any way to output the sequence \$(
To reproduce clone this:
https://github.com/datalogics-robb/quote-test-scons
run scons to generate  GenFile.csproj and observe this string in the output:
NETCore\bin\$Platform)\$Configuration)\
SCons version 4.2.0
CPython 3.9.[67] tested  on Mac/Linux

Just capturing what was noted on Discord, although I got some details wrong there - the code uses some different conventions and it tripped me up. The textfile tool (which also implements substfile) sets up an action function which does substitution on the values in the SUBST_DICT, using env.subst(value). With no keyword args, this defaults to raw=0 which will end up calling scons_subst with SUBST_CMD.  But the intended usage here is just a plain textual substitution, not either the fancy "for command line" or the alternative "for signature", so this is probably not what's wanted in this context. Suggest adding raw=1 (not raw=True as I said in the Discord thread).


Feature/appcenter

Description
Expo eject 🪂 , moving out of expo managed workflow. Generated native iOS & Android projects to use.

New native iOS & Android apps to manage
Uses Fastlane build & upload to App Center
Custom beta app icon with fastlane
Multiple app identifiers management (Stage & Prod app on same device)
CI changes
Internal app distribution with App Center (aka ad-hoc builds)

Uses Fastlane

Manage iOS Certs / Provisonal profiles
Build iOS & Android Apps
Upload iOS & Android to app center

$ yarn fastlane:ios:stage
$ yarn fastlane:android:stage

CI
We now use more circle-ci jobs features such as tests reporting & artifacts
Tests report from lint & test

Artifacts from deploy-ios & deploy-android

Branch: master (Production workflow)

Branch: develop (Staging workflow)

Branch: release-x-legacy (OTA workflow)

Branch: NOT [master, develop, stage, release-x-legacy] (Default workflow)

On what platform have you tested the change?

[ ] Android - Emulator
[ ] Android - Physical device
[x] iOS - Emulator
[ ] iOS - Physical device

Screenshots
Please attach screenshots showing the change if relevant
Checklist

[ ] I have updated mockServer
[ ] I've added analytics as relevent
[x] I have run npm test
[x] I have run npm run test:i18n

Out of scope and potential follow-up
Is there any related changes that you plan to do in a follow-up PR or voluntarily excluded from the scope?

OMG....this amazing


This isnt an Issue!!!

but I do not know how to communicate with you!
I plan to use your code with an Victron Smart Shunt. It also have victron.direct. My question is, if this is possible with your code. I have seen, that the model does not exist in the code.
It would be fine to hear from you. My mailadress is<EMAIL_ADDRESS>Thanks and stay healthy.

hi for smart shunt i have a version for esphome by slightly modifying the gains mqtt if needed


Resize button text.

Is it possible to change text of reset button?

No, it's an SVG shape defined in https://github.com/ariutta/svg-pan-zoom/blob/master/src/control-icons.js
What you could to instead is add your own custom controls like in this example http://ariutta.github.io/svg-pan-zoom/demo/custom-controls.html