AWS ECS Service Connect support

Welcome!

[X] Yes, I've searched similar issues on GitHub and didn't find any.
[X] Yes, I've searched similar issues on the Traefik community forum and didn't find any.

What did you expect to see?
AWS ECS Service Connect was recently introduced by AWS (November 2022). This feature provides a service mesh and discovery capability to ECS. More information can be found at https://aws.amazon.com/about-aws/whats-new/2022/11/amazon-ecs-service-connect/.
It is highly likely more developers will start to need this feature as it makes up for some shortcomings ECS had in the service-to-service communications space.
As it stands, enabling Service Connect on a ECS Service causes an error in Traefik 2.9.5, as the way the network interfaces & port binding operates is not catered for. See https://github.com/traefik/traefik/issues/9658, originally logged as a defect, for any extra context.
With reference to https://github.com/traefik/traefik/blob/454f552691015d5f01041f61ae0cca0cff5d5d5d/pkg/provider/ecs/ecs.go#L317
317				if len(task.Attachments) != 0 {
318					var ports []portMapping
319					for _, mapping := range containerDefinition.PortMappings {
320						if mapping != nil {
321							protocol := "TCP"
322							if aws.StringValue(mapping.Protocol) == "udp" {
323								protocol = "UDP"
324							}
325
326							ports = append(ports, portMapping{
327								hostPort:      aws.Int64Value(mapping.HostPort),
328								containerPort: aws.Int64Value(mapping.ContainerPort),
329								protocol:      protocol,
330							})
331						}
332					}
333					mach = &machine{
334						privateIP:    aws.StringValue(container.NetworkInterfaces[0].PrivateIpv4Address),
335						ports:        ports,
336						state:        aws.StringValue(task.LastStatus),
337						healthStatus: aws.StringValue(task.HealthStatus),
338					}

You can see the conditional code does not cater for when Service Connect is enabled.
With service connect is enabled
ECS describe tasks returns an attachment of type 'ServiceConnect', but no networkInterfaces.
Note: I trimmed some excess fields from this json.
{
    "tasks": [
        {
            "attachments": [
                {
                    "id": "e74dcf96-ad50-48d1-99ad-5d181070d0e9",
                    "type": "ServiceConnect",
                    "status": "ATTACHED",
                    "details": [
                        {
                            "name": "ContainerName",
                            "value": "ecs-service-connect-9qpWT"
                        }
                    ]
                }
            ],
            "containers": [
                {
                    "containerArn": "arn:aws:ecs:ap-southeast-2:REDACTEDACCID:container/ecs-cluster/0e66e90e04694eba9c1b0593264a220b/ad26a2c7-a1bd-4ee0-b3c0-83d7dffade89",
                    "taskArn": "arn:aws:ecs:ap-southeast-2:REDACTEDACCID:task/ecs-cluster/0e66e90e04694eba9c1b0593264a220b",
                    "name": "result",
                    "image": "nginx:latest",
                    "runtimeId": "fd236fa02ef67a4c00ea6a30a0c50365c50a259135905fdd3cd4e866df24c001",
                    "lastStatus": "RUNNING",
                    "networkBindings": [
                        {
                            "bindIP": "<IP_ADDRESS>",
                            "containerPort": 80,
                            "hostPort": 49160,
                            "protocol": "tcp"
                        }
                    ],
                    "networkInterfaces": [],
                    "healthStatus": "UNKNOWN",
                    "cpu": "0"
                },
                {
                    "containerArn": "arn:aws:ecs:ap-southeast-2:REDACTEDACCID:container/ecs-cluster/0e66e90e04694eba9c1b0593264a220b/bf930cda-c08c-4168-b825-a21cbd932781",
                    "taskArn": "arn:aws:ecs:ap-southeast-2:REDACTEDACCID:task/ecs-cluster/0e66e90e04694eba9c1b0593264a220b",
                    "name": "ecs-service-connect-9qpWT",
                    "runtimeId": "6f8dab6af4db5dcb37a26686b79174e904fb912674238541be85a662cc85cd04",
                    "lastStatus": "RUNNING",
                    "networkBindings": [
                        {
                            "bindIP": "<IP_ADDRESS>",
                            "containerPort": 10000,
                            "hostPort": 49159,
                            "protocol": "tcp"
                        }
                    ],
                    "networkInterfaces": [],
                    "healthStatus": "HEALTHY"
                }
            ],
            "lastStatus": "RUNNING",
            "launchType": "EC2",
            "memory": "1024",
            "overrides": {
                "containerOverrides": [
                    {
                        "name": "result"
                    },
                    {
                        "name": "ecs-service-connect-9qpWT",
                        "environment": [
                            {
                                "name": "ENVOY_CONCURRENCY",
                                "value": "2"
                            },
                            {
                                "name": "ENVOY_ADMIN_MODE",
                                "value": "UDS"
                            },
                            {
                                "name": "ENABLE_STATS_SNAPSHOT",
                                "value": "true"
                            },
                            {
                                "name": "APPMESH_METRIC_EXTENSION_VERSION",
                                "value": "1"
                            },
                            {
                                "name": "APPNET_ENVOY_RESTART_COUNT",
                                "value": "3"
                            },
                            {
                                "name": "HC_DISCONNECTED_TIMEOUT_S",
                                "value": "10800"
                            },
                            {
                                "name": "APPNET_AGENT_ADMIN_MODE",
                                "value": "UDS"
                            },
                            {
                                "name": "APPMESH_RESOURCE_ARN",
                                "value": "arn:aws:ecs:ap-southeast-2:REDACTEDACCID:task-set/ecs-cluster/voting-result/ecs-svc/2777190142156290852"
                            }
                        ]
                    }
                ],
                "inferenceAcceleratorOverrides": []
            }
        }
    ],
    "failures": []
}

These containers in the above example are exposed on the Container Instance host, so would be routable in the same manner as if you do not have service connect enabled I believe.
Regards.

Hiya! Thanks for your suggestion. We are interested in this issue but are unsure about the use case and the traction it will receive, so we are going to leave the status as kind/proposal to give the community time to let us know that they would like this.
We will reevaluate as people respond.
If you or another community member would like to build it before that happens, let us know and we will work with you to make sure you have all the information needed.
Let us know here before you start. We prefer to work with our community members at the beginning of the design process to ensure that we are aligned and can move quickly with the review and merge process.

Would like to see this as well

We are in process of migraitng krakend gateway with traefik. Would love to see it as we are using service connect and traefik does not play well with it.

Since the issue has been closed, @aleyrizvi has expressed the intention to contribute in https://github.com/traefik/traefik/issues/10394.
Therefore, I'm re-opening this issue, so we can coordinate the work here.
Here is a quote from @aleyrizvi issue:

When service connect environment is used, I propose one of the following:

ECS provider default configuration has option to enable serviceconnect (boolean) to tell ECS provider that it should not use the task definition private IPs but query services and route requests accordingly.
Allow backend to pass additional configuration to provider about how to reach it and skip the above code.

Now I am willing to work on it. I have few questions and no idea who to reach out from Traefik team to ask general consensus > about way of dealing it :)
Would you be okay with refactoring existing provider and add service connect capability or there should be a separate provider > (e.g: ECS-SC) that handles that case?

This feature extends the capabilities of ECS, so I think it would be best to do it in the existing ECS provider.
Before proceeding, it's crucial to ensure that any changes introduced to support Service Connect on the ECS provider do not cause breaking changes, especially for those already utilizing Service Connect attachments on their tasks (along with an ElasticNetworkInterface attachment).
Then, regarding how we are going to configure whether or not to consider this new attachment: Right now the only solution I can imagine is having an option in the configuration of the provider.

Allow backend to pass additional configuration to provider about how to reach it and skip the above code.

Do you mean, annotating at the task level if Service Connect should be used? I'm worried that we would end up in something that is not standard, and hard to understand.

Since the issue has been closed, @aleyrizvi has expressed the intention to contribute in #10394. Therefore, I'm re-opening this issue, so we can coordinate the work here.
Here is a quote from @aleyrizvi issue:

When service connect environment is used, I propose one of the following:

ECS provider default configuration has option to enable serviceconnect (boolean) to tell ECS provider that it should not use the task definition private IPs but query services and route requests accordingly.
Allow backend to pass additional configuration to provider about how to reach it and skip the above code.

Now I am willing to work on it. I have few questions and no idea who to reach out from Traefik team to ask general consensus > about way of dealing it :)
Would you be okay with refactoring existing provider and add service connect capability or there should be a separate provider > (e.g: ECS-SC) that handles that case?

This feature extends the capabilities of ECS, so I think it would be best to do it in the existing ECS provider.
Before proceeding, it's crucial to ensure that any changes introduced to support Service Connect on the ECS provider do not cause breaking changes, especially for those already utilizing Service Connect attachments on their tasks (along with an ElasticNetworkInterface attachment).
Then, regarding how we are going to configure whether or not to consider this new attachment: Right now the only solution I can imagine is having an option in the configuration of the provider.

Allow backend to pass additional configuration to provider about how to reach it and skip the above code.

Do you mean, annotating at the task level if Service Connect should be used? I'm worried that we would end up in something that is not standard, and hard to understand.

I do understand and agree that there must not be any breaking changes.
My idea (without looking in depth) was to introduce a small code refactor that if it see service connect, lookup the discovery name and exposed port and use it as backend load balancer in traefik. If not, continue as it is right now.
Annotation, yes. My bad.
What I was thinking that the task itself can advertise service connect discovery name it is using such as traefik.providers.ecs.serviceconnect.endpoint=http://myservice:8080
another thought for mind. The main reason I was thinking a new provider (e.g: ecs-connect) instead of using current one, because when working with tasks, traefik should not be bothered at all looking at individual task's private IP. It is controlled by service advertising its accessible address via cloudmap. It makes sense to use separate provider that the configuration is 180 degree difference than what we have in ECS provider as of right now.


CAH event on 11/14 - invite from social (not email) with ticketing info by Fri AM 10/30

Draft copy, waiting on info from CAH:
Saturday, November 14
Doors 7, Show 8
Sponsored by X (?)
Cards Against Humanity - the epic CC-licensed party game we all know and love - will be hosting an evening bash in Chicago, a full night of comedy all in support of Creative Commons! Join CAH co-creator Max Tempkin and CC CEO Ryan Merkley and X, Y, and Z at CAH’s new space (and former pickle factory!) to show your love for fine humor and your readiness to fight for a free and open web.
$50 tickets [TBD final price point]
All proceeds go directly to Creative Commons
Make your donation today
Creative Commons is a nonprofit organization at the center of a high-profile, international movement to promote sharing of creativity and knowledge. Our goal is to help realize the full potential of the Internet—universal access to research and education, full participation in culture—to drive a new era of development growth, and productivity.

You can change the settings for the event, including prices and address, time, date, etc here: https://donate.creativecommons.org/civicrm/event/manage/settings?reset=1&action=update&id=13
From this screen: https://donate.creativecommons.org/civicrm/event/manage?reset=1 you can click 'Event links' and then 'Registration (Live)' to get the link you need to share to get people to register for real.
CC @mmoreshead

Event postponed to Q1 2016


📂 fix: Assistants Client Initialization when Deleting Files

…rom azure
Pull Request Template
⚠ Before Submitting a PR, Please Review:

Please ensure that you have thoroughly read and understood the Contributing Docs before submitting your Pull Request.

⚠ Documentation Updates Notice:

Kindly note that documentation updates are managed in this repository: librechat.ai

Summary
Please provide a brief summary of your changes and the related issue. Include any motivation and context that is relevant to your changes. If there are any dependencies necessary for your changes, please list them here.
Change Type
Please delete any irrelevant options.

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update
[ ] Translation update

Testing
Please describe your test process and include instructions so that we can reproduce your test. If there are any important variables for your testing configuration, list them here.
Before
Files showed up again even after a successful delete message
After
Files are permanently gone
Test Configuration:
Checklist
Please delete any irrelevant options.

[x] My code adheres to this project's style guidelines
[x] I have performed a self-review of my own code
[x] I have commented in any complex areas of my code
[x] I have made pertinent documentation changes
[x] My changes do not introduce new warnings
[x] I have written tests demonstrating that my changes are effective or that my feature works
[x] Local unit tests pass with my changes
[x] Any changes dependent on mine have been merged and published in downstream modules.
[x] A pull request for updating the documentation has been submitted.

Double-checking, I'm not entirely sure what the motivation is here. The client is needed to properly delete it from OpenAI's servers. Even if the reference is deleted from LC, it will still exist on the Assistant/OpenAI if initialization fails for some reason

Double-checking, I'm not entirely sure what the motivation is here. The client is needed to properly delete it from OpenAI's servers. Even if the reference is deleted from LC, it will still exist on the Assistant/OpenAI if initialization fails for some reason

Hi Danny. If only Azure OpenAI is enabled (and not OpenAI) the documents will fail to be deleted when the OpenAI initiation fails.
The current code assumes that an OpenAI key is always present, which is not always the case.


Use input STL or OBJ mesh file as input

Hello,
would it be possible to input STL or OBJ mesh file as input (TEXT or binary format, taking only the vertices) ?
Thank you

Not directly. The vertices need to be converted, and unique as well.
Take a look at JSCAD www.openjscad.xyz

Agreed with https://github.com/mauriciopoppe/quickhull3d/issues/25#issuecomment-1547013254, the input needs to be an array of unique points.


Update image reference in edge Deployment

Description

Adds another pipeline that changes the image reference in the acm/odh-edge/apps/.../kustomization.yaml file, pushes a new branch with the change to the on-prem Git clone of the opendatahub/ai-edge repo, and creates a PR with the changes.
How Has This Been Tested?

Pipelines tested on the pplaczek-pipeline-dev and gryan-pipelines namespace on local-cluster.
Git tested on http://gitea-ai-edge-rhoai-edge-acm.apps.rhoai-edge-acm-poc.rhaiseng.com/edge-user-1/ai-edge-gitops.
See reply below for example screenshots.
Testing instructions
If you would like to try this out, the following steps should be runnable in an isolation on the cluster:

Create a project with oc new-project <something>
Apply the required resources, with oc apply -k ./pipelines/tekton/gitops-update-pipeline/
You can then either create a PipelineRun for the pipeline through the OpenShift Pipelines UI in the cluster (or presumably using tkn CLI), or by using one (or both) of the pre-canned manifests, like so:

oc create -f ./pipelines/tekton/gitops-update-pipeline/gitops-update-pipelinerun-bike-rentals.yaml
oc create -f ./pipelines/tekton/gitops-update-pipeline/gitops-update-pipelinerun-tensorflow-housing.yaml

You should then see the pipeline running immediately through the web console, and you should see a PR created in the relevant repo at the end. For the bike-rentals one that will be here, and for the tensorflow-housing one it will be here.

Merge criteria:

[x] The commits are squashed in a cohesive manner and have meaningful messages.
[x] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
[x] The developer has manually tested the changes and verified that the changes work

To run this on a cluster once applied, I've been specifying VolumeClaimTemplate for the git-workspace, and the gitea-edge-user-1-basic-auth Secret as the source for the git-basic-auth workspace.
It currently fails on the commit-image-ref task, with /tekton/scripts/script-0-2csnd: line 46: syntax error: unterminated quoted string. I don't fully understand this, but I think it's the way the git-cli task is doing an eval '<git script param>' (I don't see the closing ', but I might be wrong).
I'm not sure if this approach of trying to re-use existing tasks is the best one...maybe a single generic task from scratch with multiple steps might be another way.

I'll look into it

Got the code working, filed a PR on your fork: https://github.com/grdryn/ai-edge/pull/1
Pics for anybody looking at this in the future (do we have flying cars yet?):

This PR is related to #11 btw

I'm going to make a further change to this PR: upon further reflection I will remove the git secrets and document the requirement for them.

@grdryn I'm going to make a further change to this PR: upon further reflection I will remove the git secrets and document the requirement for them.

Surely providing template files wouldn't hurt though? I hate having to create new files and figure out what they need to look like :weary:

I've updated this with a fix for the issue that @LaVLaS noticed, and just some docs updates around the GitOps secret that I mentioned earlier, and rebased it on the latest state of main. I don't plan on making any further changes to it. If there are no further review comments on it by then, I'll merge it either later tonight or first thing tomorrow morning. Thanks for all the feedback and reviews so far :slightly_smiling_face:


docker image

my desktop is a amp system but my unraid server is nvidia but i can only run a docker image for apps.
idealy i docker image would have a web ui.
the way i see it is docker setup pass the gpu to the image and a storage link
/temp:/serverside/temp
/songs:/serverside/songs
the webui you can upload a mp3, ogg, wav, etc or paste a youtube link. this then pass it to the program to run. idealy see the progress in web ui.
then the final files are located in /songs which on the host side would be what ever you set it up as.
would be nice to be able top download a zip of the finshed files thought web ui.
i would recommended taking a look at metube docker web ui for ideas for the web ui part.
https://github.com/alexta69/metube

subgen uses whisper to generate subtitles and its setup for docker. maybe this can be applied here.
https://github.com/McCloudS/subgen

Still need an CI


m3u8: create example functions for Encode and Decode

Something that actually runs and tests output, just like Example() in scte35/codec_test.go:10.
For background, see https://go.dev/blog/examples

Resolved in 0d1506582 - thanks!


GHC-generated LINE annotation might cause non-deterministic build

AlexWrapper-basic copy.txt
theres thousands of newlines in that attached file!
also some of the source / line attributions seem likely to cause nondeterminstic builds under some conditions
eg

{-# LINE 1 "/var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc64947_0/ghc_2.h" #-}

cc @hvr

I agree that it would probably be nice to remove excessive newlines, but I can't see how these, or the source line attributions could cause non-deterministic builds. Can you generate a test case that show this?

Ok so the non-determinacy comes from things like:
{-# LINE 1 "/var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc64947_0/ghc_2.h" #-}

but does that come from Alex or GHC ?

That looks a lot like a tmp-file generated by GHC... I wonder if GHC should #line-annotate positions in ephemeral tmp files... (especially if -keep-tmp-files is not active)

Is this still a problem?  Cannot reproduce atm.
We need a reproducer to report this upstream.


Enable db failure tests on non-hsqldb databases

Currently, the only DB with auto (Travis) failure tests is HSQLDB. We should try to enable them for other dbs, as this is a common pain point in JQM.

Check previously opened PR.


Ignore protobuf generated files in CAP

Why are these changes needed?
Protobuf is an industry standard format for publishing and receiving messages. CAP uses these messages in the message bus.
protoc generates files that bind the message to python. These files are not meant to be fixed by hand.
pre-commit ruff checks fails on these files.
Related issue number
Closes #2190
Checks

[x] I've included any doc changes needed for https://microsoft.github.io/autogen/. See https://microsoft.github.io/autogen/docs/Contribute#documentation to build and test documentation locally.
[x] I've added tests (if relevant) corresponding to the changes introduced in this PR.
[x] I've made sure all auto checks have passed.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 35.70%. Comparing base (8cb5c14) to head (38c35ea).
Report is 7 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2215      +/-   ##
==========================================
- Coverage   37.53%   35.70%   -1.84%
==========================================
  Files          77       77
  Lines        7710     7719       +9
  Branches     1655     1657       +2
==========================================
- Hits         2894     2756     -138
- Misses       4573     4728     +155
+ Partials      243      235       -8

Flag
Coverage Δ

unittests
35.70% <ø> (-1.82%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


DWARFImporterDelegate: Adopt the new FindFiles API

By using the new LLDB FindFiles API that llows for fuzzy CompilerContext matching, we can unify the two lookup implementations, dramatically improve the performance by only looking types up once, and look for types inside of unknown submodules.
rdar://problem/49233932
rdar://problem/54471165

@swift-ci test and merge


Update core and coreutils to v0.6

Merging #1630 which uses the rhp4 branch of hostd broke web, cluster, and benchmark. This is the bare-minimum to get everything aligned on actually merged code again.

@ChrisSchinnerl merging this because leaving everything broken over the weekend is no bueno.


[ldd-img] Add class for Charge_Smear_Correction

Requested by Kate Crombie for OSIRIS-REx

O-Rex added this to their mission dictionary


How to created SSL binding for a webapp with Azure.ResourceManager library

I use this piece of code to define ssl binding for my webapp with Microsoft.Azure.Management.Fluent
await webApp.Update().DefineSslBinding()
                .ForHostname(request.Fqdn)
                .WithPfxByteArrayToUpload(File.ReadAllBytes(pkcs12FilePath, "mypassword")
                .WithSniBasedSsl()
                .Attach()
                .ApplyAsync();

However, Microsoft.Azure.Management.Fluent is deprecated with this new library.
I couldn't find any equivalent methods in Azure.ResourceManager.AppService. How can I do it with this library?

Thank you for your feedback. Tagging and routing to the team member best able to assist.

Thanks for reaching out to us, will dig into this issue.

You can call this method to update the existing web app and manage the SSL binding by specifying HostNameSslStates.
By the way, if you want to create certificate, you can call AppCertificateCollection.CreateOrUpdateAsync.


Speech: Cannot transcribe long audio files: "google.api_core.future.polling._OperationNotComplete"

Hi there, I am using Google Speech-to-Text API for transcribing an audio that is 25 mins long. I have used the transcribe_async.py code for such task, as it is meant for long audio files.
I am using Ubuntu 16.04, and Python 3.5.2. The code certainly works on 1 min long audio files.
The error message is shown below. I can't identify the source of the problem.
Waiting for operation to complete...
Traceback (most recent call last):
  File "/usr/local/lib/python3.5/dist-packages/google/api_core/retry.py", line 177, in retry_target
    return target()
  File "/usr/local/lib/python3.5/dist-packages/google/api_core/future/polling.py", line 74, in _done_or_raise
    raise _OperationNotComplete()
google.api_core.future.polling._OperationNotComplete

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/local/lib/python3.5/dist-packages/google/api_core/future/polling.py", line 94, in _blocking_poll
    retry_(self._done_or_raise)()
  File "/usr/local/lib/python3.5/dist-packages/google/api_core/retry.py", line 260, in retry_wrapped_func
    on_error=on_error,
  File "/usr/local/lib/python3.5/dist-packages/google/api_core/retry.py", line 195, in retry_target
    last_exc)
  File "<string>", line 3, in raise_from
google.api_core.exceptions.RetryError: Deadline of 90.0s exceeded while calling functools.partial(<bound method PollingFuture._done_or_raise of <google.api_core.operation.Operation object at 0x7f10bdf7bef0>>), last exception:

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "transcribe_async.py", line 110, in <module>
    transcribe_gcs(args.path, args.outpath)
  File "transcribe_async.py", line 85, in transcribe_gcs
    response = operation.result(timeout=90)
  File "/usr/local/lib/python3.5/dist-packages/google/api_core/future/polling.py", line 115, in result
    self._blocking_poll(timeout=timeout)
  File "/usr/local/lib/python3.5/dist-packages/google/api_core/future/polling.py", line 97, in _blocking_poll
    'Operation did not complete within the designated '
concurrent.futures._base.TimeoutError: Operation did not complete within the designated timeout.

Ok this is caused by the line response = operation.result(timeout=90). By setting timeout=1000, it resolved the issue. I will close this issue now.


merge package from arlac77/npm-package-template

package.json

chore(package<EMAIL_ADDRESS>

Codecov Report

Merging #322 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##           master   #322   +/-   ##
=====================================
  Coverage      75%    75%
=====================================
  Files           1      1
  Lines           8      8
=====================================
  Hits            6      6
  Misses          2      2

Continue to review full report at Codecov.

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

Coverage remained the same at 70.0% when pulling 664e1d85a78550b3322ac1d6fdf96801678692df on template-sync-1 into cbadd1286cd9f1777aad9e15f2a5194525cb6c16 on master.


[#624] Upgrade dependencies

Description
This PR upgrades go.mod packages to their latest versions (except github.com/getkin/kin-openapi, which may have an issue validating example requests in the latest version).
Resolves #624
Resolves #593
Review Time Estimate
Please give your idea of how soon this pull request needs to be reviewed by selecting one of the options below. This can be based on the criticality of the issue at hand and/or other relevant factors.

[ ] Immediately
[ ] Within a week
[x] When possible

Type of changes
Please select a relevant option:

[ ] Bug fix (non-breaking change which fixes an issue).
[ ] New feature (non-breaking change which adds functionality).
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected).
[x] Other (any another change that does not fall in one of the above categories.)

Checklist:
Please select all applicable options:

[x] I have signed the Rokwire Contributor License Agreement (CLA). (Any contributor who is not an employee of the University of Illinois whose official duties include contributing to the Rokwire software, or who is not paid by the Rokwire project, needs to sign the CLA before their contribution can be accepted.)
[x] I have updated the CHANGELOG.
[x] I have read the Contributor Guidelines.
[x] I have performed a self-review of my own code.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] My change requires updating the documentation.
[x] I have made necessary changes to the documentation.
[ ] I have added tests related to my changes.
[x] My changes generate no new warnings.
[x] New and existing unit tests pass locally with my changes.
[x] Any dependent changes have been merged and published in downstream modules.

Thanks @petyos,

Thanks for catching this. I did not see that the kin-openapi package was updated to v0.113.0. This version changes the definition of readOnly from the definition that we have been operating under to this point. v0.110.0 seems to me to be the most recent version that does not change this definition, so downgrading the version in go.mod should allow you to run successfully. I am not sure whether we want to upgrade to v0.113.0, but if so, we will need to update our schemas to fit the new readOnly definition.

I think I understand what you are saying about the ..Fields.yaml schemas, and I agree with your comment about splitting our schemas into 3 categories. The reason why I removed the existing ..Fields.yaml schemas is because it seemed to me to be straightforward to merge them into the standard model schemas given the request and response schemas expected by the current version. You are correct about the modified LoginSession schema though, and I will go back and make sure it matches the response sent by the current version of the Core BB. I will also check to make sure the other schemas I changed match the behavior of the current version of the Core BB.

I think it is fine if we need to add new model schemas for new APIs that are slightly different from existing model schemas. This would be similar to PartialAccount.yaml, which is an account model, but slightly different from Account.yaml.
Please let me know what you think about this. Thanks!

Hi @roberlander2 ,
1.
I think for now downgrading to v0.110.0 should be good.
I think it is fine if we need to add new model schemas for new APIs that are slightly different from existing model schemas. This would be similar to PartialAccount.yaml, which is an account model, but slightly different from Account.yaml.
Basically we already have all needed types of schemas - Model schemas, APIs requests schemas and APIs responses schemas.

Model schemas
These schemas are a mirror of the structs which are placed in the model package. The reader can understand the model without reading Golang code but directly in the documentation.These schemas are not related with APIs. The only relation is that we reuse the ...Fields.yaml files for responses but this is just for files reusing as we mentioned.
If the reader wants to call the Core BB APIs he should look at the schemas in the following two sections(requests and responses) below but not the model schemas whose purpose is to explain the data model only.

APIs Requests and Responses schemas
For very simple data models the model schemas and the requests and responses schemas will be the same but for more complex models which is our case in Core BB they differ. Various requests and responses could have a substructure from the main model as we have in our APIs.

Regarding PartialAccount.yaml
If we want to be correct the place for PartialAccount.yaml is not in the model schemas but it should be in the responses schemas section. The reason is that in the model package in Golang we do not have a PartialAccount struct. This entity is needed for some of our APIs as a response. I do not say that we need to move this now in the response but I just want to be sure you understand what I mean. Imagine that we need another API which requires us to expose another substructure of our Account struct - PartialAccount2 etc.
Please let me know if you ahve any questions or comments. Thanks!

Hi @roberlander2 and @petyos, thanks for the discussion and feedback!

1.  I think for now downgrading to v0.110.0 should be good.
I think we need to find a way to use the latest version of the package with the new definition of readOnly or else we will not be able to stay up to date with the latest changes going forward. My opinion is that it is better to take care of this now while making related changes than to put it off and have to deal with it again later.

Basically we already have all needed types of schemas - Model schemas, APIs requests schemas and APIs responses schemas.

Model schemas
These schemas are a mirror of the structs which are placed in the model package. The reader can understand the model without reading Golang code but directly in the documentation.These schemas are not related with APIs. The only relation is that we reuse the ...Fields.yaml files for responses but this is just for files reusing as we mentioned.
If the reader wants to call the Core BB APIs he should look at the schemas in the following two sections(requests and responses) below but not the model schemas whose purpose is to explain the data model only.
APIs Requests and Responses schemas
For very simple data models the model schemas and the requests and responses schemas will be the same but for more complex models which is our case in Core BB they differ. Various requests and responses could have a substructure from the main model as we have in our APIs.

Regarding PartialAccount.yaml
If we want to be correct the place for PartialAccount.yaml is not in the model schemas but it should be in the responses schemas section. The reason is that in the model package in Golang we do not have a PartialAccount struct. This entity is needed for some of our APIs as a response. I do not say that we need to move this now in the response but I just want to be sure you understand what I mean. Imagine that we need another API which requires us to expose another substructure of our Account struct - PartialAccount2 etc.

Thanks @petyos for the detailed explanation of your view of the organization for the schemas! This is very clear and makes it easy for us to understand where the disconnect is. We have been thinking about the schemas differently from how you described them. Here is our understanding and some explanation of the reasoning for it:
Schemas

Model schemas: These schemas reflect the standard representation of a model in our system from the perspective of the API caller. They may or may not match the Go model structs in our model package exactly depending on whether all fields we store internally are exposed through the APIs. These should be reusable components that are used directly throughout the docs to represent this data type in the requests/responses to APIs.
APIs Requests and Responses schemas: If the schema of the data to be sent in an API request/response differs from our existing models we can create a schema specific to this API to reflect this change. This should not be as common as using the model schemas directly in the request/response, and these should never be an exact duplicate of a model schema.

Regarding PartialAccount.yaml
While I believe the naming of this type is not ideal, this was meant to reflect a standard schema that can be sent through any API that should only expose the minimum amount of personal information about an account necessary to identify who the account belongs to. This is intended to be used in any and all APIs that expose accounts to admins or anyone other than the user themself who should not access their full profile. We should not be making a different version of this model for each similar API, but rather reusing this to ensure we are enforcing the same limitations on the data available. A better name for this model could be AdminRestrictedPIIAccount or something similar. If we wanted to expose a different subset of account data on a new API we should create a similar model with a meaningful and distinct name so we know when to use one vs. the other.
Explanation
We realize that this understanding differs from yours in several key ways, but here is an explanation of why we still prefer this definition.

Maintainability:* If we have a separate identical schema for each request/response that means that if we change a model we will need to go back and update every individual schema which will take more time and make it very difficult to ensure that all of the necessary schemas are updated. As the number of APIs grow it will be hard to remember every single individual API that uses a given model.
Development speed: Making separate schemas for each request/response will slow down development and require us to do additional work to create a new schema whenever we build a new API, even if an identical schema already exists.
Clarity: While I do understand your point about using the models section to understand the internal Go structure of the model, I feel that this is not entirely necessary since these are the API docs and if a field is not exposed to the caller through an API then there is no reason we need them to be aware of these internal implementation details. In my view it is best to only present the information about the interface in these docs to keep them clear and focused.
Consistency: If we use a different schema for every request/response even if it is the same model being sent then my feeling is that the API docs will be more difficult to interpret. For example, the caller loses the ability to easily identify that it is an Account being sent to them and instead they see something with a non-meaningful name that just reflects the API they are calling. They will need to look through all of the individual fields to understand that the model being used between two APIs is actually the same model which will make it more difficult for them to know what models are necessary to build on their end.
Readability: If we have many duplicate request/response schemas, we will end up cluttering up the models section of our docs which will mean that readers have to look through a longer list to find the models they are looking for.

I realize that this is a larger conversation and that there is no definitive correct strategy to follow here, but hopefully this is helpful for you to understand the intention between the changes we made. Please let us know what you think of the organization we proposed here and the explanation we provided. Please also let us know If you have any questions or disagree with any of these points, or if we misunderstood anything about your explanation.
Thanks again for your input!

Hi @petyos, thanks for the suggestion and clarification!
As a side note we fixed the issue preventing us from upgrading to the latest version of kin-openapi.

I agree it is a long conversation and there is no definitive correct strategy. As we are already in an advanced stage of development I would suggest to mix our understandings with minimal changes. I would suggest: Let's have 4 types schemas - 3 related with APIs and 1 for the Data model of the system: APIs data model This is general what meaning you currently give to the current model schemas.  So here we would have: AccountFileds.yaml - all simple fields of the Account entity(without composition with other entities) AdminRestrictedPIIAccount.yaml - some substructure of the Account entity etc APIs Requests and Responses schemas: Specific schemas for specific requests and responses Data model schemas: It represents the data model of the system and is a mirror of it.  It could Have AccountFields.yaml + all other entities compositions
Account
{
fields AccountFields.yaml

+ all composition fields
app_org ApplicationOrganization
...
}

///////////// What do you think about this? Thanks.

I think I understand what you are saying better now. I still don't fully see the need for the "Data model schemas" but I think the strategy you proposed to manage them is a good one. If we are going to continue supporting these I would like to propose a small modification to the structure you outlined to help keep things organized and make the purpose of each schema clear. Here is the file structure I would suggest for the schemas/ directory:
fields/
  Account.yaml (name: AccountFields)
web/
  models/
    user/
      Account.yaml (name: Account)
  apis/ (matches the current docs/schemas/apis/)
internal/
  user/
      Account.yaml (name: InternalAccount)

fields: Contains the root level primitive fields (no composition) for the model to be used in both web/models/ and internal/ schemas. It is also acceptable to reference these directly from the API definitions if they match the exact requirements.
web: Contains all schemas that are used in APIs. Note that these schemas cannot contain recursive/circular references.

models: Contains all standard models for use in APIs and are composed of fields and any additional IDs or other properties using the allOf keyword to merge and flatten the elements.
apis: Same as the existing request/response schemas. Contains schemas that are specific to an individual API request/response. Should only be used if no standard web/model fits. shared requests/responses should be used if the type is not a standard model, but is used by multiple APIs (eg. across services and admin endpoints).

internal: Schemas that reflect the internal structs for standard models composed of fields and other internal models using the allOf keyword to merge and flatten elements. These are for informational purposes only and should not be used directly in API definitions. Because of this, these schemas may contain recursive/circular references, but should be ignored when generating Go types.

Note: No schemas should ever be exact duplicates.

Hi @petyos, I started attempting to implement the structure I described above and I am woried that it will still introduce a lot of extra work just to maintain the internal models since even with the shared fields we will need to essentially define every model twice and remember to update both when any changes occur.
Could you please explain why you believe it is important to maintain the internal models even though they are not being used in the APIs and this information is not really needed by the caller? While it may not detract from the quality of the docs, it does make the process of defining and maintaining these docs significantly more complicated and time consuming. I am still having a hard time understanding what benefit these provide that make them worth the extra effort.

Hi @petyos, I started attempting to implement the structure I described above and I am woried that it will still introduce a lot of extra work just to maintain the internal models since even with the shared fields we will need to essentially define every model twice and remember to update both when any changes occur.
Could you please explain why you believe it is important to maintain the internal models even though they are not being used in the APIs and this information is not really needed by the caller? While it may not detract from the quality of the docs, it does make the process of defining and maintaining these docs significantly more complicated and time consuming. I am still having a hard time understanding what benefit these provide that make them worth the extra effort.

Hi @shurwit, my point of view was that we already have data model schemas which cover the data model schemas in the way I treat it at acceptable level of implementation. But indeed, introducing internal at this stage will trigger a lot of changes. Feel free to ignore the Data model schemas/internal as you do not see a reason to support it. It was an extra information.

Hi @shurwit, my point of view was that we already have data model schemas which cover the data model schemas in the way I treat it at acceptable level of implementation. But indeed, introducing internal at this stage will trigger a lot of changes. Feel free to ignore the Data model schemas/internal as you do not see a reason to support it. It was an extra information.

Hi @petyos, thanks for the explanation and for approving. I see what you mean about these data model schemas already existing. We were trying to simplify things and reduce the amount of documentation overhead going forward, and I do feel that maintaining them will complicate things. Hopefully you agree that this will simplify things. Thanks again!


Enable persistent storage

It would be nice if persistent storage were enabled in the module for storing created tokens.
Introduced in v11 - https://github.com/foundryvtt/foundryvtt/issues/8590

Hesitant to do this as if the module is uninstalled and reinstalled you loose persistent storage, it is only retained via updates. I'm not sure it's use case is for storing things like tokens, more for things you may want to generate once or twice, or don't mind regenerating.


Code Quality: Refactored ToolbarViewModel

Summary
Refactored ToolbarViewModel and separated it into ToolbarViewModel and PathBreadcrumbViewModel.
Task Checklist

[x] Refactored ToolbarViewModel
[x] Add PathBreadcrumbViewModel
[ ] Move code from ToolbarViewModel
[ ] Clean up
[ ] Apply requested changes

Known Issues
N/A
PR Checklist

[x] Closes: N/A
[ ] Approval: Have discussed with and got approval from the team[^1]
[x] Tests: Tested accessibility on the local end
[x] Deployment: Deployed the app on the local end
[ ] Localization: Modified en-US string resources[^2]
[ ] Co-authors: N/A

Steps To Validate Changes

Launch the app
See nothing has been changed.

Screenshots
N/A
[^1]: If the request hasn't been agreed by the team, this work might be rejected. Make sure that you get approval from the team before opening any PR related the request.
[^2]: If you removed any en-US string resources, make sure that there are no references of those resources. When you add a new en-US string resources, do not make any changes on other languages' resources; Crowdin will do that, instead.

Code wise this looks good, but we'll need to do a lot of testing.

Can you merge?

Is this ready for review? You still have it marked as a draft.

Yes


Revert "Add option to remove Sandcastle, update isetup, various other stuff"

Reverts fullpwn/infinity#7
I can see why the x86 version wont boot. You removed the menu.
We will discuss this on discord. fullpwn#6315

Friend request sent.


Fixes duplicate "is" typo

Removes the duplicate "is" from the react scripts template README, from when the Changing the Page title section was added.

Thanks!


select items per page

I'm submitting a ...  (check one with "x")
[ ] bug report => search github for a similar issue or PR before submitting
[ x ] feature request
[ ] support request => Please do not submit support request here, post on Stackoverflow or Gitter

Description
I do not know if I do not know, but I would like to have in the library a select to set how many items to show in the table, example of the image below.

I would like to put this select before these fields that we already have in the library

Hi, check this sample https://github.com/swimlane/ngx-datatable/blob/master/src/app/paging/paging-server.component.ts
With server side rendering you can pass to the component the amount of items per row, the total count of the records to show and by doing so then the pages should be configured with the proper amount. With the offset property it seems you indicate at which page you are at.
So, when you select a different amount of items per page then you change the value of the components property binded to the datatable and re fetch the items to show. Hope it helps!


Update counter.current when inputValue changes

When using the setValue action, the counter.current value is not changed to reflect the new length of the inputvalue variable.
I am making this on the cleanup branch because the _toggleAction function isn't in the master branch, and the cleanup branch seems to be the one your are releasing to NPM.
Let me know if this makes sense to you.

Thanks for the pull request. Yes, I'm working on cleanup branch until everything is sorted out. After everything is update to date I will merge cleanup branch with the master branch.

Thanks.  Let me know when NPM is updated with the change.  Thanks so much
for accepting all my requests!
On Mon, Jul 20, 2015 at 9:11 AM Hetmann<EMAIL_ADDRESS>wrote:

Thanks for the pull request. Yes, I'm working on cleanup branch until
everything is sorted out. After everything is update to date I will merge
cleanup branch with the master branch.
—
Reply to this email directly or view it on GitHub
https://github.com/PearlVentures/Essence/pull/32#issuecomment-122878869.

@hartmamt npm update is changed and online. Thanks for your help!


New command: remove property bag value

Remove the the specified property from the property bag

command: spo propertybag remove -w|--webUrl <webUrl> -p|--property <property> -f|--folder [folder] --confirm
webUrl: The URL of the site from which the property bag value should be removed
property: name of the property to remove
folder: server- or site-relative URL of the folder from which to remove the property bag value
confirm: don't prompt for confirmation before removing the property bag value
requires connection to a SharePoint site

For more information see the Remove-PnPPropertyBagValue cmdlet

Hey @waldekmastykarz, feel free to assign that to me.

Excellent! All yours @VelinGeorgiev!


Allow passing tsdx.config.js file path to cli.

Current Behavior
Unable to specify custom tsdx.config.js file path.
https://github.com/jaredpalmer/tsdx/blob/158ee9a69c824b71b62cf987fe943a167f47f936/src/createBuildConfigs.ts#L17
Desired Behavior
Can specify custom tsdx.config.js file path
Suggested Solution
Like this
https://github.com/jaredpalmer/tsdx/blob/4ec56fc7ad802fbedcfb0cc500443bd34881f4c9/src/createRollupConfig.ts#L48
Who does this impact? Who is this for?
Who wants to use TSDX to build an advanced package development environment.
Describe alternatives you've considered
There are no alternatives right now.

A workaround would be to have a root tsdx.config.js that just does:
module.exports = require('custom-path/tsdx.config.js')

But yea this should be possible, I believe microbundle has a --config option.


Use int64_t instead of ssize_t

Refs https://github.com/ml-explore/mlx/issues/1513.
ssize_t is a POSIX type and not available in MSVC, I think int64_t should do the same.

ptrdiff_t is available in MSVC and everywhere else. IMO, that's a better replacement for ssize_t than hardcoding it to int64_t.


storageblob should probably be 2-3 modules

There's a lot going on in storageblob. Would suggest breaking out at least the token management stuff into its own module, and switching the actual blob/container management stuff to use a more standard "state=(present|absent|container)" arg over "mode". Blob fetching could also potentially be its own module...

Funny you should mention this. After working with Bryan on defining the Docker modules, I had similar thoughts. Breaking it into modules is a good idea. I definitely don't like it in it's current state. Will pair it down and have a limited number of states that fit the ansible style.

storageblob is refactored. Permissions and URL stuff is gone. It uses two states, present and absent. Take a look when you get a chance. Hopefully it's more sane.


Fix operationId value

In endpoint /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBforPostgreSQL/flexibleServers/{serverName}/backups for PostgreSQL Flexible server 2022-01-20-preview the operationId should be Backups_ListByServer instead of BackupListByServer, so it is consistent with the other operation Backups_Get.
Changelog
Add a changelog entry for this PR by answering the following questions:

What's the purpose of the update?

[ ] new service onboarding
[ ] new API version
[ ] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[ ] Other, please clarify

When are you targeting to deploy the new service/feature to public regions? Please provide the date or, if the date is not yet available, the month.
When do you expect to publish the swagger? Please provide date or, the the date is not yet available, the month.
If updating an existing version, please select the specific language SDKs and CLIs that must be refreshed after the swagger is published.

[ ] SDK of .NET (need service team to ensure code readiness)
[ ] SDK of Python
[ ] SDK of Java
[ ] SDK of Js
[ ] SDK of Go
[ ] PowerShell
[ ] CLI
[ ] Terraform
[ ] No refresh required for updates in this PR

Contribution checklist:

[ ] I commit to follow the Breaking Change Policy of "no breaking changes"
[ ] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

Applicability: :warning:
If your changes encompass only the following scenarios, you should SKIP this section, as these scenarios do not require ARM review.

Change to data plane APIs
Adding new properties
All removals

Otherwise your PR may be subject to ARM review requirements. Complete the following:

[ ] Check this box if any of the following appy to the PR so that the label "ARMReview" and "WaitForARMFeedback" will be added by bot to kick off ARM API Review.  Missing to check this box in the following scenario may result in delays to the ARM manifest review and deployment.

Adding a new service
Adding new API(s)
Adding a new API version
-[ ] To review changes efficiently, ensure you are using OpenAPIHub to initialize the PR for adding a new version. More details, refer to the wiki.

[ ] Ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If any of the following scenarios apply to the PR, request approval from the Breaking Change Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in a stable version
[ ] Removing properties in a stable version
[ ] Removing API version(s) in a stable version
[ ] Updating API in a stable or public preview version with Breaking Change Validation errors
[ ] Updating API(s) in public preview over 1 year (refer to Retirement of Previews)

Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.
Please follow the link to find more details on PR review process.

SDK seems not released for 2022-01-20-preview
Adding SDK owners anyway @msyyc @tadelesh @qiliao123 @ArcturusZhang @XiaofeiCao

The operations regarding backups were introduced since tag 2022-01-20-preview.

Bypass breaking changes check, as operationId only affect SDK, and no SDK is released for this api-version.


Update properties.py

What does this PR do?

Fixes #<issue_number>
Before submitting

[ ] Was this discussed/approved via a GitHub issue? (not for typos and docs)
[ ] Did you read the contributor guideline, Pull Request section?
[ ] Did you make sure your PR does only one thing, instead of bundling different changes together?
[ ] Did you make sure to update the documentation with your changes? (if necessary)
[ ] Did you write any new necessary tests? (not for typos and docs)
[ ] Did you verify new and existing tests pass locally with your changes?
[ ] Did you update the CHANGELOG? (not for typos, docs, test updates, or internal minor changes/refactorings)

PR review
Anyone in the community is free to review the PR once the tests have passed.
Before you start reviewing make sure you have read Review guidelines. In short, see the following bullet-list:

[ ] Is this pull request ready for review? (if not, please submit in draft mode)
[ ] Check that all items from Before submitting are resolved
[ ] Make sure the title is self-explanatory and the description concisely explains the PR
[ ] Add labels and milestones (and optionally projects) to the PR so it can be classified

Did you have fun?
Make sure you had fun coding 🙃

Hello @justusschock! Thanks for opening this PR.

In the file pytorch_lightning/trainer/properties.py:

Line 222:1: W293 blank line contains whitespace
Line 226:1: W293 blank line contains whitespace
Line 232:1: W293 blank line contains whitespace

Do see the Hitchhiker's guide to code style


[Enhancement] Use statistics to optimize skew join

Why I'm doing:
In this #34854, we support skew join optimize using shew hint, but it needs user to find skew value, It's not convenient. And we already support collect histogram stats for olap/hive table, we can use most common value(mcv) to find skew value for column.
What I'm doing:
if join on predicate column has histogram stats, check if it has skewed value, and use the mcv to optimize skew join
Fixes #issue
What type of PR is this:

[ ] BugFix
[ ] Feature
[x] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Does this PR entail a change in behavior?

[ ] Yes, this PR will result in a change in behavior.
[x] No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

[ ] Interface/UI changes: syntax, type conversion, expression evaluation, display information
[ ] Parameter changes: default values, similar parameters but with different default values
[ ] Policy changes: use new policy to replace old one, functionality automatically enabled
[ ] Feature removed
[ ] Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

[ ] This is a backport pr

Bugfix cherry-pick branch check:

[x] I have checked the version labels which the pr will be auto-backported to the target branch

[ ] 3.2
[ ] 3.1
[ ] 3.0
[ ] 2.5

@mergify backport branch-3.2


Use URL Helpers

Coverage increased (+0.3%) to 70.37% when pulling dfcb47ee4687f835b7917e807101ed55f073fad0 on use-url-helpers into d9b1139db5ec7622dd86664bf7ed2c121cf0026a on main.


Question: Is there support for Prisma Models?

I recently changed from TypeORM to prisma, and am wondering if there is a way to get my existing project using Nest-CASL to work with Prisma. At the moment I receive an error because Prisma models are a type, not a class.

Subject it is required to be class down in @casl/ability, but with Prisma you have schema as a source of truth, so you can generate whatever you need. Check https://github.com/vegardit/prisma-generator-nestjs-dto for example or pick one of generators from https://www.prisma.io/docs/concepts/components/prisma-schema/generators


Add/Delete some tags

Hey, sorry I haven't reviewed this PR yet. I'll be getting around to it soon. :)


Support PCNs in alerts

There are no tests for PCN alerts, but I have tested manually and got something sensible in the email.
The existing alert-sending tests don't give me much confidence that it would be worthwhile to work out how to extend them to support PCNs.  The hairy part of this is calculating interesting measures, and from what I can tell InterestingMeasureFinder.measure_filter_for_org() does the right thing.  But I'd appreciate extra care when reviewing that part of the code.

Looks good.
Re tests, I agree there's no mileage in worrying about testing the interesting measure finder stuff in any new ways.
But what do you think about adding a simple high-level test to minimally exercise the new code path? Along these lines:
https://github.com/ebmdatalab/openprescribing/blob/e604cfc20b2d66af5bf75f1ec2278efb315fa18e/openprescribing/frontend/tests/commands/test_send_monthly_alerts.py#L453-L465
The test could also assert PCN is in the email text, per Dave's wondering?

But what do you think about adding a simple high-level test to minimally exercise the new code path?

I tried this and got bogged down creating the necessary fixtures.


IRC channel

Is there a IRC channel to discuss things in realtime? If not, it's my feature request to create one.

There is #io_uring on oftc, but it's not used very much.
So while irc may seem sync/realtime, it requires someone to be there and answer questions. And that's a time luxury that isn't always available. Mailing the io-uring list is a better option.


Feature Request - Search Movie Set

Is it possible to add a filter by source or search panel to movie sets ? (In the panel movie sets).

I'll put this to the roadmap for v3 since in v2 filtering for movie sets is not planned or easy to implement

OK thank you for your answer.
When is any beta v3 planned?

in the near future

:)

v3 is currently on github, @Zwanzig2 . If you are aware of software engineering, and java, you can compile and run it. It's still under development.

Ok thank you, but unfortunately - I can not do it

a public alpha/beta will be release when all major things have been implemented (which should be soon)

OK thank you for the information.
By the way, is there a planned version 3 - actor editing (removal, reordering) with preview (Photo)?

Version 3 is already under development. This kind of feature is not planned, whatsoever all ideas are welcome and will be discussed

I think the topic can be closed THX

I will close it, when it is done ;)


vcpkg integrate bug

Describe the bug
I set the project’s use vcpkg to false
However, the installed directory of vcpkg is still in the includes
Environment

OS: windows
Compiler: msvc

To Reproduce
Steps to reproduce the behavior:

./vcpkg integrate install

Expected behavior

@chriscp-cat Thanks for posting this issue,

The Use vcpkg function is set to No: it will disable the project to use the library and header files provided by vcpkg.

For External Include Directories, you need to run ./vcpkg integrate remove and restart VS.

If you do not restart vs, the path of vcpkg still exists, but you cannot use vcpkg(error LNK2019). This is because the integration of vcpkg and vs (MSBuild) is implemented by importing.props and .targets files. Therefore, you need to run the command to restart VS and it will disappear.
View https://github.com/microsoft/vcpkg/blob/master/docs/users/buildsystems/msbuild-integration.md for more help.

But when I run ./vcpkg integrate remove Even without restart vs The path of vcpkg in the External Include Directories will also be removed
I have tried to restart vs before, but my problem has not been solved

this problem did not exist before

Yes, at present, this function can only implicitly disable the library provided by vcpkg, and cannot be explicitly displayed.
It's a vcpkg bug. 🧐

I contacted them, but the problem was not solved thoroughly This time we will thoroughly improve this method. :)

I see. Thank you for your help

@chriscp-cat Coule you please test PR #28216 ? :)

@FrankXie05 I've already tested,it solved my problem


Buffer is needed, but not working?

Hi there,
I'm using now the Version 2.1.0.
I understood the buffer in such a way, that with a buffer of 20 the Soyo is not producing 500W (with that demand) but 480W.
But this is not the case. It's producing exactly, what the demand requests.
How to make it work, that the Soyo produces $Buffer Watts less, than the demand, which comes from a SmartMeter?
Thanks,
best,
Olaf

My .yaml code:
substitutions:
  name: soyosource-line1
  device_description: "Monitor and control the WiFi version of the Soyosource GTN using the OEM WiFi dongle with a alternative firmware"
  external_components_source: github://syssi/esphome-soyosource-gtn-virtual-meter@main
  tx_pin_ttl_wifi: GPIO1
  rx_pin_ttl_wifi: GPIO3
  tx_pin_rs485: GPIO14
  rx_pin_rs485: GPIO5

esphome:
  name: ${name}
  comment: ${device_description}
  project:
    name: "syssi.esphome-soyosource-gtn-virtual-meter"
    version: 2.1.0

esp8266:
  board: esp12e

external_components:
  - source: ${external_components_source}
    refresh: 0s

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

captive_portal:

web_server:
  local: true

ota:

# If you use Home Assistant please remove this `mqtt` section and uncomment the `api` component!
mqtt:
  broker: !secret mqtt_host
  username: !secret mqtt_username
  password: !secret mqtt_password
  id: Soyosource_L12
  discovery: false

# api:

logger:
  baud_rate: 0
  level: INFO
  logs:
    soyosource_display: ERROR

uart:
  - id: uart0
    baud_rate: 9600
    tx_pin: ${tx_pin_ttl_wifi}
    rx_pin: ${rx_pin_ttl_wifi}
  - id: uart1
    baud_rate: 4800
    tx_pin: ${tx_pin_rs485}
    rx_pin: ${rx_pin_rs485}

soyosource_modbus:
  - id: modbus0
    uart_id: uart1
    # flow_control_pin: GPIO12

    # Optional settings
    #
    # The name is used as prefix for some log messages and should
    # help to distinguish between different instances/devices
    name: soyosource-line1

soyosource_virtual_meter:
  - id: virtualmeter0
    soyosource_modbus_id: modbus0

    # the state of this sensor (instantaneous power in watt) is used as source
    power_id: powermeter0

    # Optional settings
    power_sensor_inactivity_timeout: 0s
    power_demand_calculation: NEGATIVE_MEASUREMENTS_REQUIRED
    min_power_demand: 0
    max_power_demand: 900
    zero_output_on_min_power_demand: true
    # Split/distribute the power demand if you have multiple inverters attached to the same RS485 bus
    power_demand_divider: 1
    # A positive buffer value (10) tries to avoid exporting power to the grid (demand - 10 watts)
    # A negative buffer value (-10) exports power to the grid (demand + 10 watts)
    buffer: 0
    # The operation_status_id sensor is expected here. Passing the operation_status won't work
    # The state is used to suspend the limiter if the operation status of the inverter isn't 0x0 (normal)
    operation_status_id: operation_status_id0

    # The update interval is important and defaults to 3 seconds. If the demand is sent too frequently
    # or rarely the interverter stops. TODO: Identify and validate the lower and upper update limit
    update_interval: 3s

soyosource_display:
  - id: display0
    uart_id: uart0
    protocol_version: SOYOSOURCE_WIFI_VERSION
    update_interval: 20s

binary_sensor:
  - platform: soyosource_display
    fan_running:
      name: "${name} fan running"
    limiter_connected:
      name: "${name} limiter connected"

button:
  - platform: soyosource_display
    restart:
      name: "${name} restart"

number:
  - platform: soyosource_virtual_meter
    soyosource_virtual_meter_id: virtualmeter0
    buffer:
      name: "${name} buffer"
      initial_value: 0
      restore_value: true
    manual_power_demand:
      name: "${name} manual power demand"
      max_value: 900
    max_power_demand:
      name: "${name} max power demand"
      initial_value: 900
      max_value: 900
      restore_value: false
    power_demand_divider:
      name: "${name} power demand divider"
      initial_value: 1
      restore_value: true

  - platform: soyosource_display
    start_voltage:
      name: "${name} start voltage"
    shutdown_voltage:
      name: "${name} shutdown voltage"
    # Maximum output power in limiter mode / Output power in constant power mode
    output_power_limit:
      name: "${name} output power limit"
    start_delay:
      name: "${name} start delay"

select:
  - platform: soyosource_display
    operation_mode:
      name: "${name} operation mode"
      optionsmap:
        1: "PV"
        2: "Battery Constant Power"
        17: "PV Limit"
        18: "Battery Limit"

sensor:
  - platform: soyosource_virtual_meter
    soyosource_virtual_meter_id: virtualmeter0
    power_demand:
      name: "${name} power demand"

  - platform: soyosource_display
    error_bitmask:
      name: "${name} error bitmask"
    operation_mode_id:
      name: "${name} operation mode id"
    operation_status_id:
      name: "${name} operation status id"
      id: operation_status_id0
    battery_voltage:
      name: "${name} battery voltage"
    battery_current:
      name: "${name} battery current"
    battery_power:
      name: "${name} battery power"
    ac_voltage:
      name: "${name} ac voltage"
    ac_frequency:
      name: "${name} ac frequency"
    temperature:
      name: "${name} temperature"
    total_energy:
      name: "${name} total energy"
    output_power:
      name: "${name} output power"

  # mqtt subscribe example
  - id: powermeter0
    internal: true
    platform: mqtt_subscribe
    name: "${name} instantaneous power consumption"
    topic: "soyosource-line1/sensor/powerdemand/value"
    accuracy_decimals: 2
    unit_of_measurement: W
    device_class: power
    filters:
      - throttle_average: 15s

#   # import smartmeter reading from homeassistant
#   # requires the "api" component see above
#   - platform: homeassistant
#     id: powermeter0
#     name: "${name} smartmeter instantaneous power"
#     entity_id: sensor.firstfloor_smartmeter_instantaneous_power
#     filters:
#       - throttle_average: 15s

switch:
  - platform: soyosource_virtual_meter
    soyosource_virtual_meter_id: virtualmeter0
    manual_mode:
      name: "${name} manual mode"
      restore_mode: RESTORE_DEFAULT_OFF
    emergency_power_off:
      name: "${name} emergency power off"
      restore_mode: RESTORE_DEFAULT_OFF

text_sensor:
  - platform: soyosource_virtual_meter
    soyosource_virtual_meter_id: virtualmeter0
    operation_mode:
      name: "${name} limiter operation mode"

  - platform: soyosource_display
    errors:
      name: "${name} errors"
    operation_mode:
      name: "${name} operation mode"
    operation_status:
      name: "${name} operation status"

Does it mean, that the power_demand is reduced of the amount of buffer?

Does it mean, that the power_demand is reduced of the amount of buffer?

For my understanding and in my experience so far, yes.
I can see clearly a change, when I change the buffer value. I track my total consumption on all 3 phases by using a Shelly 3EM.
If I set the buffer to 10, I clearly see a power import of around 10 Watts. Same thing changes for a negative value -> export to grid.
As a suggestion: I recommend using a WT32-ETH01 device instead of an ESP8266 ;)

Good job guys! :-) I have nothing to add.


Move time-varying thermal test to Inlet

This is sort of a follow-up to #363 in that it integrates the new custom function signatures from Inlet.
I also "borrowed" the very useful exact solution checking logic from #373

Codecov Report

Merging #392 (8dc459f) into develop (27472bd) will increase coverage by 0.19%.
The diff coverage is 0.00%.

@@             Coverage Diff             @@
##           develop     #392      +/-   ##
===========================================
+ Coverage    93.16%   93.36%   +0.19%
===========================================
  Files           43       43
  Lines         2019     2019
===========================================
+ Hits          1881     1885       +4
+ Misses         138      134       -4

Impacted Files
Coverage Δ

src/serac/physics/utilities/equation_solver.cpp
87.50% <0.00%> (ø)

src/serac/physics/base_physics.cpp
83.60% <0.00%> (+6.55%)
:arrow_up:

Continue to review full report at Codecov.

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

Yeah, that branch got eaten by feature stuff and will probably be a while before it is merged. Thanks for putting this together!

LGTM


Prices in CSV doesnt match the price in the live table

Pick the example of c5.12xlarge on Ireland, export the CSV and check hourly prices with SUSE Licenses. Doesnt match.

Unfortunately the CSV export option is a bit buggy and doesn't work with regions other than US East. Please see #274. Sorry!


Enable EPEL on s390x

This repo now works and is needed on s390x.
Signed-off-by: Lance Albertson<EMAIL_ADDRESS>

!bump patch ~

Jenkins has merged this PR into master and has automatically performed a patch-level version bump to v2.0.2.  Have a nice day!


New UI

See [this] (https://forums.adobexdplatform.com/t/is-it-possible-to-load-svgs-inside-the-dialog/103/11) for svg support.

Archiving this repo


Update to chose the VM XML file

Update to chose the VM XML file not the VHD that fails

@TomHickling : Thanks for your contribution! The author(s) have been notified to review your proposed change.

thanks for your feedback. The correct steps are now in https://docs.microsoft.com/en-us/azure/migrate/tutorial-assess-hyper-v
#please-close


Does not support 4-byte emojis

I am looking for a method which takes the first character from a string, even if it is multibyte. For 2-byte emojis, this lib works, but not for 4-byte emojis, e.g.:
val length = "🇫🇷 fries".offsetByCodePoints(0, 1)
println(this.substring(0, length)) //  instead of 🇫🇷

Probably not something you can easily fix, because kotlin.text.codePoints has the same issue...

That emoji is represented by two codepoints from the regional indicator symbol block of unicode. If you only grab one of them, you only grab "half" of the symbol.

I guess codepoints is the wrong tool for this then, I managed to solve my issue using an additional emoji library, see https://stackoverflow.com/a/79054558/2260402
You can close this issue if you like

It's not that they're the wrong tool, more that they don't represent what you're after. You seem to want grapheme clusters which are comprised of one or more codepoints.
I would strongly suggest renaming your function to not use the word "character" which is far too overloaded to be precise as to what its implementation is doing.

I would also double check that library correctly supports things like 🧑🌾, which are actually two discrete emoji (🧑 and 🌾) with a zero-width joiner to ultimately produce a single grapheme cluster.

Support for grapheme clusters is outside the scope for this library. The library could be used as a building block for code dealing with text segmentation. But I want to keep this library focused on code point essentials.
However, if someone is building such functionality on top of kotlin-codepoints and discovers that changes to its API would make that job easier, I'm keen on hearing about that. In that case please open a new issue.


Go1.6Early: html/template: cannot redefine "_default/single.html" after it has executed

Just an early heads up of what is to come:
Since a day or two ago, the Travis CI test for building Hugo with "Go tip", i.e. the development tip for the future Go 1.6, no longer passes, and instead failing with the errors when running go test:
html/template: cannot redefine "_default/single.html" after it has executed

Example build that exhibits this error: https://travis-ci.org/spf13/hugo/jobs/83273687
It seems to have to do with this recent commit (diff) to Go:

text/template, html/template: add block keyword and permit template redefinition
This change adds a new "block" keyword that permits the definition
of templates inline inside existing templates, and loosens the
restriction on template redefinition. Templates may now be redefined,
but in the html/template package they may only be redefined before
the template is executed (and therefore escaped).
The intention is that such inline templates can be redefined by
subsequent template definitions, permitting a kind of template
"inheritance" or "overlay". (See the example for details.)
Fixes #3812

It would be useful if you could spin up a Hugo site with Go 1.6 and see if same happens. If yes, I would say that this is a breaking change and a bug in Go.

I  built my site with a 1.6 Hugo, and it works fine. It is some of our tests that needs fixing. Should be doable.

I finally did some testing.  Hugo's own documentation would trigger the error, i.e. by running hugo -s docs from the root of the hugo Git repository.
I was also able to reproduce the error on my own yet-to-be-published blog.  I soon discovered that I had a zero-byte content/a.md that I had inadvertently left behind some months ago.
I was then able to reproduce the error on a minimal site like so (with hugo compiled with the go1.6 branch):
$ hugo new site testsite
$ cd testsite
$ touch content/a.md
$ touch content/b.md
$ hugo

Need to create at least two such empty files to trigger the error.  And indeed, no theme is needed.
The hugo run would also list available templates, among which __a.html and __b.html are also available.  That __ prefix led me to the following snippet in pageRenderer() in hugolib/site.go (https://github.com/spf13/hugo/blob/master/hugolib/site.go#L938-L961):
		if !p.IsRenderable() {
			self := "__" + p.TargetPath()
			_, err := s.Tmpl.New(self).Parse(string(p.Content))

Since fmt.Errorf("html/template: cannot redefine %q after it has executed", name) comes from go/src/html/template/template.go (https://github.com/golang/go/blob/master/src/html/template/template.go#L180), this looks like the suspect.
And indeed, when I add a continue to skip _, err := s.Tmpl.New(self).Parse(string(p.Content)) altogether, the html/template: cannot redefine XXXXXX after it has executed error goes away.
Why would Hugo try to create a template out of a unrenderable file?  That did not make sense to me, so I used a series of git blame to trace the "culprit", and eventually found this:
commit 311e10222301d47422f970c460383879ad78f681
Author: Noah Campbell<EMAIL_ADDRESS>Date:   Wed Sep 18 14:21:27 2013 -0700

    Allow non-markdown content in content directory

    Allow content that is not markdown and does not need to be rendered to
    exists in the content directory.  Currently any valid html or xml
    document can exist.  Templates are applied to these documents as well.
    If you need to have content that doesn't have templates or AbsUrlify
    like operations, then continue to put this content in static and it will
    be copied over.

"Templates are applied to these documents as well."...  Okay... Hmm...
What about the addition of this new error message html/template: cannot redefine... in Go1.6?
commit 12dfc3bee482f16263ce4673a0cce399127e2a0d
Author: Andrew Gerrand<EMAIL_ADDRESS>Date:   Fri Aug 28 15:31:51 2015 +1000

    text/template, html/template: add block keyword and permit template redefinition

    This change adds a new "block" keyword that permits the definition
    of templates inline inside existing templates, and loosens the
    restriction on template redefinition. Templates may now be redefined,
    but in the html/template package they may only be redefined before
    the template is executed (and therefore escaped).

    The intention is that such inline templates can be redefined by
    subsequent template definitions, permitting a kind of template
    "inheritance" or "overlay". (See the example for details.)

    Fixes #3812

    Change-Id: I733cb5332c1c201c235f759cc64333462e70dc27
    Reviewed-on: https://go-review.googlesource.com/14005
    Reviewed-by: Rob Pike<EMAIL_ADDRESS>
Now, what intrigues me is that in the minimal site example above, the html/template: cannot redefine "__a.html" after it has executed is not because s.Tmpl.New("__a.html").Parse(string(p.Content)) is called twice—hugo only makes the call once.  The error actually happens during the call to s.Tmpl.New("__b.html").Parse(string(p.Content))!  How on earth would the definition of template __b.html lead to the redefinition of template __a.html?
As it turns out, it is Go's html/template’s Parse() own doing (https://github.com/golang/go/blob/master/src/html/template/template.go#L169-L186):
	// In general, all the named templates might have changed underfoot.
	// Regardless, some new ones may have been defined.
	// The template.Template set has been updated; update ours.
	t.nameSpace.mu.Lock()
	defer t.nameSpace.mu.Unlock()
	for _, v := range ret.Templates() {
		name := v.Name()
		tmpl := t.set[name]
		if tmpl == nil {
			tmpl = t.new(name)
		} else if tmpl.escapeErr != nil {
			return nil, fmt.Errorf("html/template: cannot redefine %q after it has executed", name)
		}
		// Restore our record of this text/template to its unescaped original state.
		tmpl.escapeErr = nil
		tmpl.text = v
		tmpl.Tree = v.Tree
	}

So, why does Parse() go through all the previously defined templates and set them again?  I know too little about Go's template system to be able to answer that.

Curious to find what the actual escapeErr it is, I decided to print it out:
_internal/shortcodes/ref.html: escapeErr = <nil>
_internal/shortcodes/relref.html: escapeErr = <nil>
_internal/shortcodes/highlight.html: escapeErr = <nil>
...
__a.html: escapeErr = template escaped correctly

(then comes the error when creating "__b.html" template: html/template: cannot redefine "__a.html" after it has executed)

What!?  "template escaped correctly" is the escapeErr?  That's weird interesting...
From type template struct { } definition (https://github.com/golang/go/blob/master/src/html/template/template.go#L19-L29):
	// Sticky error if escaping fails, or escapeOK if succeeded.
	escapeErr error

And from https://github.com/golang/go/blob/master/src/html/template/template.go#L31-L32:
// escapeOK is a sentinel value used to indicate valid escaping.
var escapeOK = fmt.Errorf("template escaped correctly")

Then I found it used in a few places, e.g., in lookupAndEscapeTemplate(), like so:
	if tmpl.escapeErr != nil && tmpl.escapeErr != escapeOK {
		return nil, tmpl.escapeErr
	}

But not so in Parse()—escapeErr is currently not checked against escapeOK there:
		} else if tmpl.escapeErr != nil {
			return nil, fmt.Errorf("html/template: cannot redefine %q after it has executed", name)
		}

And the following patch seems to have squelched the error with hugo -s docs and go test ./... etc.:
--- a/src/html/template/template.go
+++ b/src/html/template/template.go
@@ -176,7 +176,7 @@ func (t *Template) Parse(src string) (*Template, error) {
 		tmpl := t.set[name]
 		if tmpl == nil {
 			tmpl = t.new(name)
-		} else if tmpl.escapeErr != nil {
+		} else if tmpl.escapeErr != nil && tmpl.escapeErr != escapeOK {
 			return nil, fmt.Errorf("html/template: cannot redefine %q after it has executed", name)
 		}
 		// Restore our record of this text/template to its unescaped original state.

So, is that it?  A possible bug in the current Go1.6 branch?

Sorry for the very wordy and long message.  My puny little brain was exploding and needed to do a "brain dump", hehe.

@anthonyfok I have looked into this myself and didn't get too bright about it. But I still don't understand the  _, err := s.Tmpl.New(self).Parse(string(p.Content)) and Page.IsRenderable logic.
I would says this looks like a bug in Go, at least in the sense in that this is a pretty breaking change; but if we could fix this by removing functionality we just don't use (or understand.)

@bep Thanks for the note.  Just a quick update: my proposed patch to go/src/html/template/template.go does not fly: It fails at go/src/html/template/clone_test.go:92.  The "template escaped correctly" is set intentionally after an ExecuteTemplate() call, and Go1.6 uses that to test for "redefinition after execute".
Another note: hugo -s docs fails because of two empty files docs/content/indexes/category.md and docs/content/taxonomies/category.md which somehow did not get deleted (commit a87f171) but got left behind as zero-length files on my computer.  hugo -s docs run fine from a fresh git clone https://github.com/spf13/hugo.git.

But I still don't understand the  _, err := s.Tmpl.New(self).Parse(string(p.Content)) and Page.IsRenderable logic.

Me neither.  @noahcampbell, could you please enlighten us?  :-)

2013 was a long time ago :).  I'm not sure I remember my intent.

My hunch is that this is not a Go bug.  The _, err := s.Tmpl.New(self).Parse(string(p.Content)) line (hugolib/site.go:L958) is the same one that's triggering a race condition in Go 1.5 (see #1601).
@natefinch is the one responsible for those changes in pageRenderer.

This issue is a dupe of #1601.

Closing as a duplicate.

It's still an issue after the fix for #1601.

See my https://github.com/spf13/hugo/issues/1601#issuecomment-165349295.
I think the root cause of this issue and #1601 is that we are rendering into and reusing a single Template instance (Site.Tmpl).  PR #1717 only solved the race condition because you removed concurrency in the rendering process.
I haven't messed with Go 1.6, but here's what Andrew said in the Go commit message:  "Templates may now be redefined, but in the html/template package they may only be redefined before the template is executed (and therefore escaped)."  See Go Change 14005.  Again, I think once the first template is defined and executed, you can't redefine that template instance in Go 1.6.
My suggestion is to return to using concurrency in pageRenderer (ie. revert part of #1717) and creating a new Template instance for each page.  I haven't had time to work on a fix for this issue or #1601, but I would hope that removing the single template instance would solve both problems.

I have a fix to this issue. Will commit in a few minutes.


Cleanup KDD upgrade status

Description
@fasaxc noticed that the status for the KDD upgrade had some incorrect information. This PR cleans that up, the previous status I believe was just copied from the etcd and isn't quite the same.
Release Note
None required

Looks right to me, backport to v3.0 dir?

The upgrade directions haven't been copied to the v3.0 dir yet.
@emanic I assume this is still on the list of things to do before v3.0 is released?

Hi @tmjd correct, I am just doing this now. OK to merge this one then?

I'll have it rebased in a minute

Great thank you @tmjd . I've also merged a PR that moves the upgrade docs to the v3.0 directory so if you could make the matching change there, that would be a great help.

Awesome, I can do that


Enable/Disable Specific WASI Host Functions

Is your feature request related to a problem? Please describe.
Sometimes I want to run WASM modules that I don't necessarily trust - when I don't enable WASI this is straight forward, however there are a lot of modules (especially those compiled with tinygo with the target -target=wasi) that only need a subset of the WASI spec.
Currently, Wazero requires me to enable all of the WASI host functions, or none of them.
Describe the solution you'd like
I would like to be able to enable WASI support using the wasi_snapshot_preview1 package, and then disable certain host functions. Another option would be to selectively enable certain WASI functions using some sort of config file, and that would be a solid solution as well - though it will probably require more work.
Describe alternatives you've considered
There doesn't seem to be any alternative path forward - save for using an alternative wasm runtime.

I've got a potential solution here: https://github.com/loopholelabs/wazero/commit/ed5fdbf3a02cbdbfdbb26a9d0cf6c115a0accf8c

Hi, @ShivanshVij
So I'm curious about the approach of removing the imports because it is hard to control compilation of guests. Actually there is no access to anything by default even if the the functions are imported. That's because ModuleConfig controls the resources WASI (or otherwise) can access. I expect us to continue that path vs have 40+ settings because the issue applies to anything that accesses resource, not just snapshot01. Make sense?

Wait so @codefromthecrypt what happens if I want to run a wasm module that wants to open a socket? Will wazero allow it to open the socket?

That completely solves my problem - thank you!

no worries. thanks for your interest and giving wazero a try!

We're actually building a new embedded function runtime (https://github.com/loopholelabs/scale-go) on top of wazero - I'd love to find some way to advertise wazero/give credit to the maintainers. Maybe even help out if there are issues that need tending to.


Update pyperplan version

Codecov Report
Patch and project coverage have no change.

Comparison is base (b34f1d7) 86.94% compared to head (c56309b) 86.94%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@           Coverage Diff           @@
##           master     #369   +/-   ##
=======================================
  Coverage   86.94%   86.94%
=======================================
  Files         176      176
  Lines       22764    22764
=======================================
  Hits        19792    19792
  Misses       2972     2972

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


outline-solid uses dotted?

Not sure if this is a bug or if i am missing something.
But classes like "outline-solid-black" equals
.outline-solid-black {   outline: 2px dotted black;   outline-offset: 2px; }
which just seems wrong to me, as it clearly states that it's solid.

I still seem to have the issue even on 2.5.11, is it perhaps something on my side, some cache that needs clearing?

What plugin are you using? Did you upgraded it to latest version?

oh didn't think about the plugin for some reason.
i am using vite-plugin-windicss 0.12.5, so it might not be using the latest windicss.

oh okay it seems to just be parts that aren't working.
outline-solid-black/white are still dotted.
But outline-solid-gray-50 isn't (which i think was before, but not really sure as i focused on the solid-black.
Not sure if that explains something or not though.


docs: add JSON For You to "Projects using Vitest"

Description

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

[ ] It's really useful if your PR references an issue where it is discussed ahead of time. If the feature is substantial or introduces breaking changes without a discussion, PR might be closed.
[ ] Ideally, include a test that fails without this PR but passes with it.
[ ] Please, don't make changes to pnpm-lock.yaml unless you introduce a new test example.

Tests

[ ] Run the tests with pnpm test:ci.

Documentation

[ ] If you introduce new functionality, document it. You can run documentation with pnpm run docs command.

Changesets

[ ] Changes in changelog are generated from PR name. Please, make sure that it explains your changes in an understandable manner. Please, prefix changeset messages with feat:, fix:, perf:, docs:, or chore:.

We no longer accept new entries to this list.


fish: 2.3.1 -> 2.5.0

Things done

[x] Tested using sandboxing
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] Linux

[x] Tested compilation of all pkgs that depend on this change
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

I briefly tested the shell with my setup and I couldn't find any obvious issue but there probably are a few things to patch/update. I would be best if someone else tested this.

Works for me. Are there any particular changelog items we should be concerned about?

I read the NEWS of all intermediate releases and saw nothing suspicious.  I've been using it a little for a couple hours now.  All seems OK so far.

@joachifm No, nothing in particular just a big changelog.


removed breaking change: equal alias is '=' again

In my last pull request, you noted that the breaking change could be a problem.
I forgot that I already solved the problem by adding a 'Level' to each condition in the FilterMap. Because of this, 'Contains=' for example is checked first, before checking the shorter aliases like '='.
I have changed the code to use '=' as an alias again.
Kr,
Appsum

thanks for your contribution,
i'll release a new version of the package soon 🎉


Contracts: update SafeMath

This PR updates SafeMath (resolves #24).

Closing in favor of omnibus PR #48.


Need to update target API level before Aug 31, 2024

I'm still the admin of the app in the Google Play Store. I received this email from Google:

Someone needs to fix this and publish a new version.
@osmdroid/admins

tracking. i'll cut to cut a release this weekend if i have time

@spyhunter99 did you see the email I sent you?


Extension API for sending status information storage system in EVE

This PR proposes an API extension for sending storage in EVE status information.

If something is missing, or something is superfluous, let's discuss it

Second of all, I am actually not convinced this is needed at all. Why would we periodically send information back to the controller that is effectively one shot decisions during installer time.

We can move StorageInfo into another type of info message and send it once per boot. Will it make sense?
But for metric part we have no "infrequent metrics", so having state of disk inside deviceMetric is what we can do right now.

We can move StorageInfo into another type of info message and send it once per boot. Will it make sense?

I've been meaning to propose some hardwareinfo message which would be sent once per boot. Starting that now with this new disk drive info probably makes sense, and then we can add or move other parts of hardware inventory from the device info message to thr new hardware info. The hardware info only needs to be sent once on boot for now.
Separately there is a question on how many bytes this adds to metrics; the observation is that we prresumbly do not need these metrics every 60 seconds; every hour might be sufficient if folks want to see the health of the disks and pools.
I think with the recent changes in the controller it should be easy to define a separate hardware metrics (or storage metrics) message.

So how do we immediately report the failed disk status ? Say a disk went offline/faulted, we certainly need to report that immediately. I believe we should be polling very frequently say at least 60 secs and send the status of disks/zpool to zed control. If we decide to send only if disk/zpool status changes, then we need to cache the previous state somewhere.

What about the size when sending, at the moment:
info.StorageInfo - 80
metrics.StorageMetric:
(for 4 disks, without smart data) - 70
(for 1 disk, without smart data) - 28
The measurements were made by filling in the structures, then the length was measured (len()), for the result of the proto.Marshal() function

I can also redo the sending of information about the smart to put it in a separate independent structure so that it is sent less often (how much less often, this needs to be discussed), since its importance is not as important as, for example, the state of the disks that @zedi-pramodh  wrote about above
This will allow our to stay in the calculations that I wrote about above.

I've been meaning to propose some hardwareinfo message which would be sent once per boot. Starting that now with this new disk drive info probably makes sense, and then we can add or move other parts of hardware inventory from the device info message to thr new hardware info. The hardware info only needs to be sent once on boot for now.

At the very minimum we should absolutely do what @eriknordmark is proposing above

What about the size when sending, at the moment: info.StorageInfo - 80 metrics.StorageMetric: (for 4 disks, without smart data) - 70 (for 1 disk, without smart data) - 28
The measurements were made by filling in the structures, then the length was measured (len()), for the result of the proto.Marshal() function

Thanks. We can keep it in the existing messages since the addition is quite small.
So if you can do this as two commits as Roman asked (one with just the proto files and second commit with the rest) then we can move forward.

Updated


Support new confidence changes

Shouldn't be a massive change:
https://medium.com/blockcypher-blog/important-changes-to-blockcypher-s-confidence-api-7bbd283e099c

Closing out in favor of this PR: https://github.com/blockcypher/php-client/pull/11 . Thanks @josecelano!


The scripting tool need to be manyally run after creating a control module

The control module is not calling the tool making the users to call it manually

This is part of DCAFSampleProjects, see issue #20