[Concurrency] Infer @Sendable for globally isolated function types and allow globally isolated closures to capture non-Sendable values.

Globally isolated function types may never be called concurrently, so they are data-race safe. Thus, they should be implicitly @Sendable.

For the same reason as above, globally isolated closures should be allowed to capture non-Sendable values.

This is the second part of the changes proposed by this pitch.

@swift-ci Please smoke test

@swift-ci please smoke test

@swift-ci please clean smoke test


Shape Card Client Crash

My client crashes when I try to cycle through the different shapes in the Shape card. I get 3 or so either direction and it just shuts down Minecraft.
Playing on SkyFactory 3, latest build.
No crash log is generated when crash happens.

There is always a crash log somewhere. Did you check all files in the logs folder? Also crash reports folder? Without a crash log I cannot do anything really

I'm sorry, I loaded up the game so when I replicated the crash I could at least get the MultiMC Log, but when I stated I trashed the Shape Card First then tried it with a new crafted one. It didn't crash. I did update from an older version.

I have had the same crash. On a sponge-powered FTBBeyond1.5.3-Server in Aroma1997's Miningworld.
The builder never worked in the mining dimension haven't tried it in the overworld. The builder has been set with preview mode on, loop operation and maybe with move entities.
Logfile created and uploaded by MultiMC
Screenshots of the F3-Debugscreen and the quarry-shapecard settings


Addition of the njit.hu domain.

Request to add the "njit.hu" domain, belonging to the BMSZC John von Neumann Secondary School, or it's Hungarian name, "BMSZC Neumann János Informatikai Technikum" in Budapest, Hungary. I've noticed that the "njszg.hu" domain is also present in the lib, this was the old domain of this school, before its renaming a few years ago.

@rMate2005 Thank you for your patience while waiting for a review and processing your request. Pull request merged.
Please start requesting the licenses in about an hour, to let the changes to propagate through our system.


Screenshot in the README.md

Hello,
I think a screenshot, an animated GIF or a link to a video would be a great addition to the README.md in order to “hook” potential users or contributors.

That's a great idea!
I'll figure something out when the 0.2.0 release is ready.


Move CopHelper to a file in lib so it can be included outside RuboCop?

Recently at GitLab we've begun writing custom cops to enforce some things that are very specific to our style preferences and/or our codebase. Obviously we want to make sure these cops are covered by automated tests, but the tests make use of the methods from CopHelper.
For now I've gotten by just copying the relevant parts of CopHelper into a file in our own spec/support directory, but I'm wondering if it would make sense to move the file into RuboCop's lib folder as something like test_helper, so that it can be required as-needed for testing custom cops.

Since cop_helper.rb is packaged in the rubocop gem, you can require it by hacking your load path:
require 'rubocop'
require 'rspec'
$LOAD_PATH << $LOAD_PATH.grep(/rubocop-/).first.sub(/lib$/, '')
require 'spec/support/cop_helper'

How do you feel about that?

How do you feel about that?

@jonas054 Not great, but thanks for the suggestion. 😃  #3179 has what we need.

I agree with @jonas054's suggestion. No need to expose more in our "public interface", which must then be kept and supported (because we'll break people's code if we change or remove it).
Better that @tsigo just copies the code and maintains his own version, which can be tailored to his team's needs.


Integrate OSM in Machine Controller

User Story
In order to enable machines to be provisioned using OSM instead of the user data plugins, we have to enable osm in machine controller so that the provisioning and bootstrapping script is used.
Acceptance Criteria

Integrate OSM related configurations in machine controller
Adding a feature flag which decides whether to use OSM or user data plugins
Bootstrapping mechanism is moved to machine controller

@moadqassem I think this is done right?


Can't find artifact

Just looking for some help.
I'm having a hard time getting this to find my artifacts.  I'm using the artifacts in other build steps, so I know they're there, but this action doesn't seem to be able to find them.
Build & Upload (after build):
- name: Install dependencies
  run: dotnet restore
- name: Build
  run: dotnet build --configuration Release --no-restore
- name: Test
  run: dotnet test --no-restore --verbosity normal --logger:"trx;LogFileName=test-results.trx"
- name: Upload Unit Test Results
  if: always()
  uses: actions/upload-artifact@v2
  with:
    name: unit-test-results
    path: '**/*/test-results.trx'

Report Step:
  test-report:
    runs-on: ubuntu-latest
    needs: build
    if: success() || failure()
    steps:
      - name: Download Artifacts  # I've tried with and without this, makes no difference
        uses: actions/download-artifact@v2
        with:
          path: artifacts
      - uses: dorny/test-reporter@v1
        with:
          artifact: unit-test-results       # artifact name
          name: Test Results (test)                 # Name of the check run which will be created
          path: '**/*/test-results.trx'                     # Path to test results (inside artifact .zip)
          reporter: dotnet-trx              # Format of test results

Report Step Output:
Run dorny/test-reporter@v1
  with:
    artifact: unit-test-results
    name: Test Results (test)
    path: **/*/test-results.trx
    reporter: dotnet-trx
    path-replace-backslashes: false
    list-suites: all
    list-tests: all
    max-annotations: 10
    fail-on-error: true
    only-summary: false
    token: ***
Action was triggered by pull_request: using SHA from head of source branch
Check runs will be created with SHA=a6f0b4ad7583baa6bf3a164d0c511b004f0af689
Fetching list of tracked files from GitHub
  Fetching tree f091f1105b88b341cc4be9716ae77957[2](https://github.com/gregsdennis/json-everything/actions/runs/4378590562/jobs/7663570386#step:3:2)fd70994
Found 791 files tracked by GitHub
Using test report parser 'dotnet-trx'
Warning: No artifacts found in run 4[3](https://github.com/gregsdennis/json-everything/actions/runs/4378590562/jobs/7663570386#step:3:3)78[5](https://github.com/gregsdennis/json-everything/actions/runs/4378590562/jobs/7663570386#step:3:5)905[6](https://github.com/gregsdennis/json-everything/actions/runs/4378590562/jobs/7663570386#step:3:6)2
Error: No test report files were found

Example of failed build

I think I got it to find the files by removing the artifact name (so it's searching in all artifacts, I think).  But now I get a git error:
Run dorny/test-reporter@v1
  with:
    name: Test Results (test)
    path: **/*/test-results.trx
    reporter: dotnet-trx
    path-replace-backslashes: false
    list-suites: all
    list-tests: all
    max-annotations: 10
    fail-on-error: true
    only-summary: false
    token: ***

Action was triggered by pull_request: using SHA from head of source branch
Check runs will be created with SHA=9db890f0760bf[2](https://github.com/gregsdennis/json-everything/actions/runs/4379273569/jobs/7665090699#step:3:2)567[3](https://github.com/gregsdennis/json-everything/actions/runs/4379273569/jobs/7665090699#step:3:3)8[4](https://github.com/gregsdennis/json-everything/actions/runs/4379273569/jobs/7665090699#step:3:4)3de316[5](https://github.com/gregsdennis/json-everything/actions/runs/4379273569/jobs/7665090699#step:3:5)ff218221848[6](https://github.com/gregsdennis/json-everything/actions/runs/4379273569/jobs/7665090699#step:3:6)e
Listing all files tracked by git
  /usr/bin/git ls-files -z
  fatal: not a git repository (or any of the parent directories): .git

Error: Error: The process '/usr/bin/git' failed with exit code 12[8](https://github.com/gregsdennis/json-everything/actions/runs/4379273569/jobs/7665090699#step:3:8)


docs: explain why and how kubefirst uses ngrok and atlantis

closes #891
Signed-off-by: João Vanzuita<EMAIL_ADDRESS>

@fharper tks a lot! Im following your suggestions in the last commit


Improve CI/CD automations

Description
This PR contains updates to most (GitHub Actions) CI/CD automations used by this repository.
The intent of these changes is to provide improvements in the following areas of impact:

Administrative burden: Streamline build-and-deploy steps by reenforcing existing PR review activities as the primary mechanism for promoting changes to Staging environments, with a single admin approval activity remaining as a prerequisite for Production deployments.

Our current CI/CD processes are quite noisy and require more manual approval steps (up to 1 for each commit to an open pull request, and up to 3 for each deployment) than necessary, which causes confusion around deployments and and a high burden of manual effort for contributors, maintainers, and stakeholders.
DORA metrics: Deployment frequency, change lead time
KPIs: Time to first review, review time, time to approval

Contributor experience: The changes in this PR significantly reduce manual approval activities and are designed to be compatible with pull requests based on forked repositories.

As noted above, certain workflows currently require manual admin approval for each commit made to an open pull request, which frustrates contributors and slows down PR review activities. Additionally, several CI steps are currently incompatible with fork-based PR workflows, which increases the learning curve for (especially new) contributors.
DORA metrics: Change lead time, deployment frequency
KPIs: Review time, time to approval, time to first hello world, contributor engagement

Stakeholder confidence: Allows for Staging deployments to occur immediately upon PR merge, and promotes visibility of Production release contents by using tagged releases as the mechanism for driving deployments to Production. This mechanism is further supported by automatically drafting release notes that inventory the changes associated with a deployment.

Current branch management practices and deployment ceremonies tend to result in opacity around release contents for both contributors and stakeholders, who often cite confusion about what is being staged and/or released, as well as when a deployment will occur (or has occurred). Altogether, these issues result in a lack of awareness and/or preparedness around rollouts, or in some cases cause contributions to become stale.
DORA metrics: Change lead time, change failure rate
KPIs: Time to approval, deployment frequency

Predictability: Coalesces multiple deployment roll-out mechanisms into a single activity (driven by Terraform) and uses immutable identifiers tied to a single commit hash for deployment artifacts, in order to promote git revision consistency across deployed runtime code and its infrastructure.

Certain conditional aspects of the current CI/CD workflows, along with branch management practices and deployment ceremonies, have resulted in issues such as out-of-order deployments and hampered recovery efforts around failed/problematic deployments. It's worth noting here that low confidence in deployment systems tends to increase time spent preparing deployments and reduce their overall frequency.
DORA metrics: Change failure rate, deployment frequency, recovery time
KPIs: Deployment frequency

Summary of changes

Workflows

aws-auth.yml: Reusable workflow that uses OIDC auth to create temporary AWS credentials for use in other workflows. Since workflows cannot inherently share secrets, credentials are first GPG-encrypted using a common secret available to GitHub Actions in this repository.
build.yml: Reusable workflow that provides two jobs, which respectively:

Build and push Docker images, refactored from our build-api.yml workflow. New: images built for PRs are now published and tagged as pr-<number>.
Build and upload website (packages/client) webpack bundles, refactored from our build-website.yml workflow.

ci.yml: Workflow triggered on pull request events and runs reusable workflows that test branch contents and generate Terraform plans.
deploy-production.yml: Workflow triggered when a release/** tag is pushed (i.e. a release is published). Runs reusable workflows to build and deploy to Production, then updates the release to include deployment history, assets, and removes the pre-release label.
deploy-staging.yml: Workflow triggered when a commit to main is pushed (i.e. a PR is merged). Runs reusable workflows to build and deploy to Staging.
pr-tidying.yml: Test workflow that may ultimately serve as a helpful resource for standardizing pull requests with minimal developer friction. Publishes comments like this one.
publish-qa-results.yml: Reusable workflow that adds comments (like this one) to pull requests in order to report the status of various QA jobs and provide test coverage results. Comments are updated after every CI run.
publish-terraform-plan.yml: Reusable workflow called by CI/CD workflows that provides the Terraform plan for the changes (against Staging) to review before approval. Plans are published as PR comments for CI jobs, as well as step summaries available when viewing workflow history, which allows them to be historically reviewed for Staging deployments and admin-reviewed prior to Production deployment approval.
qa.yml: Reusable job called during CI in order to run all QA-related (test suites and linters) tasks.
release-drafter.yml: Does two things:

Tags pull requests based on various matching rules, which are defined in .github/release-drafter.yml
Generates/updates draft release notes when a commit is pushed to main (i.e. a PR is merged), the contents of which are categories according to matching rules defined in .github/release-drafter.yml.

terraform-apply.yml: Reusable workflow called from deploy-staging.yml and deploy-production.yml and is responsible for applying Terraform deployment plans generated in earlier steps by terraform-plan.yml. This is the mechanism that is actually responsible for driving deployments to a target environment.
terraform-plan.yml: Reusable workflow called during CI and deployment workflows to generate a Terraform plan for the deployment, potentially (during deployment workflows) to be used by terraform-apply.yml at a later step.
validate-deployment.yml: Reusable workflow used as a security/compliance gate during deployment. It is responsible for inspecting the commits related to the changes being deployed and ensuring that all commits exist on the main branch (or were cherry-picked from main). This helps ensure that all changes originate from an approved pull request, which protects our target environments.

Terraform:

Changes that allow input variables pertaining to deployment artifacts to be provided by GitHub Actions workflows. In particular, these changes make Terraform responsible for shipping static website files and specifying the immutable (not rolling-tag) Docker image that should be pulled by ECS tasks.

How does this affect me?
If you are a contributor:

Changes to branch conventions:

The current main branch will be renamed (to something like main-<datetime>) and locked as read-only.
The current _staging branch will be renamed to main.
The default branch for this repository will become main.
Open pull requests will be reconfigured to target main (which should effectively mean very little, given the _staging->main transition).

Depending on your preference, you may (as always) clone and work on branches directly against this repository. However, these changes will also make it possible to develop and submit changes from a personal fork.
When you submit a pull request, automated CI activities ("checks") will not require approval unless you are an outside collaborator (i.e. not a member of the @usdigitalresponse/grants-developers team).

Note that some PRs may (still) require approval from specific reviewers depending on their changes, per responsibilities defined in our CODEOWNERS policy. However, these changes tend to be less common, and will not prevent any automated CI checks from running.

CI automations will provide more helpful feedback by creating comments that provide updated status reports about tests, lint/formatting checks, and Terraform deployment plans.
When your pull request is approved and merged, changes will deploy to Staging immediately (although you may (still) need to wait in line if there are other pending changes in the pipeline that were merged ahead of your own).
Releases to which you contributed changes will mention you as a valued contributor in published release notes, which you can brag about to friends, family, members of your professional network, and/or anyone else you deem worthy to inform of your amazingness ❤ .

If you are a maintainer:

You will receive fewer notifications from GitHub, and have fewer manual tasks to complete for pull requests and deployments.
You can release to Production with the push of a button. No more accumulating commits into release branches!
No more ever-growing commit list obscuring the differences between main and _staging branches / Production and Staging environments.
You will only need to approve things when:

A release is ready to be deployed to Production (and only after terraform plan has finished).
A pull request is submitted by an outside collaborator.
A pull request contains changes for which you are listed as responsible in CODEOWNERS.

If you are a stakeholder
(This includes PMs, researchers, users, and anyone else who cares about releases.)

You may refer to to serve as itemized, historical inventory of what was deployed, and when that deployment occurred. You can find all releases from the repository homepage in GitHub.
If you are an active collaborator, you may refer to draft release notes as itemized inventory of changes on Staging that are not yet live on Production – there will always be a latest release enumerating the most recent changes, and a pending draft release for what's being QA'd on Staging.
You can expect PRs from contributors to be ready for QA (and on to Production!) in less time.

I'm a visual learner! How do the automations work?

Here's a diagram

@aprilselby88

What does renaming the main branch to main-date help you do?

Renaming the current main branch to main-<date> is just something we'd do for archival purposes and/or so that in case of a problem, we would have some kind of known ref to use for restoration.

How does it benefit over just having the commit sha?

Having the commit sha could work just as well, but would be harder to keep track of. I suppose a tag could also be used instead of an entirely new branch.

Also how long-lived do you anticipate a main-date branch to be?

Honestly if there isn't an immediate issue that requires restoration (which I'm having trouble envisioning), I hope to forget about it pretty much as soon as the cutover is complete. That might be a further argument for using something like a tag, or just noting the sha somewhere.

@aprilselby88

What does renaming the main branch to main-date help you do?

Renaming the current main branch to main-<date> is just something we'd do for archival purposes and/or so that in case of a problem, we would have some kind of known ref to use for restoration.

How does it benefit over just having the commit sha?

Having the commit sha could work just as well, but would be harder to keep track of. I suppose a tag could also be used instead of an entirely new branch.

Also how long-lived do you anticipate a main-date branch to be?

Honestly if there isn't an immediate issue that requires restoration (which I'm having trouble envisioning), I hope to forget about it pretty much as soon as the cutover is complete. That might be a further argument for using something like a tag, or just noting the sha somewhere.

I'd 100% go tag over entirely new branch!  I can see how the sha might get lost, but having a branch can be confusing.

If there was a problem with a release, would you apply a patch in main or release or always rollback?

If there was a problem with a release, would you apply a patch in main or release or always rollback?

Typically we'll prefer additive changes (patching) to rolling back; if the release included any DB migrations, we'll pretty much always patch. However, I think that has become a precedent at least in part because our primary release mechanism has historically been triggered by pushing a commit to main. The changes in this PR may contribute to rollbacks becoming a more viable option for dealing with problematic releases.


[DOCS] Improve serverless operation summaries

Now that https://github.com/elastic/elasticsearch-specification/issues/2314 is fixed, we can have operation summaries that diverge from operation descriptions.  This meta-issue tracks the operation summary review and edits for the serverless APIs in each of these sections:
Done

Alias APIs https://github.com/elastic/elasticsearch-specification/pull/2718
Analyze https://github.com/elastic/elasticsearch-specification/pull/2924
Application https://github.com/elastic/elasticsearch-specification/pull/2926
Async search https://github.com/elastic/elasticsearch-specification/pull/2924
Bulk https://github.com/elastic/elasticsearch-specification/pull/2719
Cat https://github.com/elastic/elasticsearch-specification/pull/2734
Component template https://github.com/elastic/elasticsearch-specification/pull/2719
Connector https://github.com/elastic/elasticsearch-specification/pull/3051
Data stream https://github.com/elastic/elasticsearch-specification/pull/2711
Delete by query https://github.com/elastic/elasticsearch-specification/pull/2734
Doc https://github.com/elastic/elasticsearch-specification/pull/2734
Document https://github.com/elastic/elasticsearch-specification/pull/3052
Enrich https://github.com/elastic/elasticsearch-specification/pull/2734
Eql https://github.com/elastic/elasticsearch-specification/pull/3207
Esql https://github.com/elastic/elasticsearch-specification/pull/3208
Graph https://github.com/elastic/elasticsearch-specification/pull/3217
Index template https://github.com/elastic/elasticsearch-specification/pull/2634
Inference
Info https://github.com/elastic/elasticsearch-specification/pull/2734
Ingest https://github.com/elastic/elasticsearch-specification/pull/3218
License https://github.com/elastic/elasticsearch-specification/pull/2718
Lifecycle https://github.com/elastic/elasticsearch-specification/pull/2718
ML: https://github.com/elastic/elasticsearch-specification/pull/2453, ...
Mapping https://github.com/elastic/elasticsearch-specification/pull/2734
Query rules https://github.com/elastic/elasticsearch-specification/pull/3219
Refresh https://github.com/elastic/elasticsearch-specification/pull/2718
Reindex https://github.com/elastic/elasticsearch-specification/pull/2718
Rollover https://github.com/elastic/elasticsearch-specification/pull/2718
Root https://github.com/elastic/elasticsearch-specification/pull/2732
Search https://github.com/elastic/elasticsearch-specification/pull/3053, https://github.com/elastic/elasticsearch-specification/pull/3080
Scripts https://github.com/elastic/elasticsearch-specification/pull/2719, https://github.com/elastic/elasticsearch-specification/pull/3054
Security https://github.com/elastic/elasticsearch-specification/pull/2719, https://github.com/elastic/elasticsearch-specification/pull/3035, https://github.com/elastic/elasticsearch-specification/pull/3036
Settings https://github.com/elastic/elasticsearch-specification/pull/2718
Sqlhttps://github.com/elastic/elasticsearch-specification/pull/3221
Synonyms https://github.com/elastic/elasticsearch-specification/pull/3220
Tasks https://github.com/elastic/elasticsearch-specification/pull/2719
Template https://github.com/elastic/elasticsearch-specification/pull/2634
Transform https://github.com/elastic/elasticsearch-specification/pull/2734
Update by query https://github.com/elastic/elasticsearch-specification/pull/2734
Validate https://github.com/elastic/elasticsearch-specification/pull/2734

Since there's only one category left unedited and it exists in both OpenAPI documents, I've moved it over to https://github.com/elastic/elasticsearch-specification/issues/3226 and will close this issue (yay!)


Add Contributing.md with a set of label descriptions.

Fix for #64.
@hubuk, @sharwell: I would appreciate for the review.

I too would appreciate the review :smile:

Looking at the issue list, I believe the project could benefit from two additional labels:

Label
Meaning on Issue
Meaning on Pull Request

erroneous contract
The issue concerns an incorrect contract in the reference source code
The issue concerns an incorrect contract in the reference source code

missing contract
The issue concerns a missing contract in the reference source code
The issue concerns a missing contract in the reference source code

The erroneous contract and missing contract labels are the equivalent of bug and enhancement respectively, and are used when talking about contracts for the reference source code.

Part of me just wants one label for a contract change, mostly because a method may have a contract that allows all input and guarantees nothing for the input. Externally for users a method that previously had no preconditions which after an update has preconditions added will appear as a contract change.
On the other hand I see benefit to the distinct labels as we don't have a good way to distinguish between a method that does not restrict input and another that was neglected. I also see the bug vs enhancement point of view but you could also apply two labels, one being contract-change and another being enhancement.

I would feel comfortable with a contract issue (or similar), where in addition to that label we can apply bug if the code already has a contracts but the contract is incorrect, or enhancement if the update is simply an improved contract representing existing behavior.

Requiring those tags will probably be important for generating release notes, which is another topic that may be important.

@aarondandy The primary benefit I see to the contract tag is many contributors will feel comfortable updating reference contracts but might not feel comfortable editing the implementation. I want those users to have quick/easy access to our list of outstanding issues that they're more likely to be able to help with. :+1:

Good point, I think most of those "jump-in" sites that pop up can be configured to take different labels too

It seems that some general label would be very useful. But can we come up with more descriptive name?
I mean 'contract' as a label sounds a bit weird for me. Maybe 'contract issue' or something similar?
P.S. @sharwell I'll take a look at your PR, but I don't have experience with VSIX and other black magic that you've done in #66.

I have proposed labels for NuGet as a starting point because they appear to be self explanatory. Assigned colors make them easy to read and understand what set of labels are possible on single issue. Having some explanation in project wiki or other document is also a good thing. So to utilize both ideas I come with the following proposition (source markdown available on my Wiki):
Labels
This project uses many labels for categorizing issues and pull requests. Labels are grouped according to their category:

Label
Meaning

0 - Backlog
Issue not in the scope of the current milestone.

0 - Blocked
Issue blocked by some external or internal dependencies.

1 - Ready
Issue is ready to be fixed.

2 - Working
Someone is currently working on the issue.

3 - Done
Issue already addressed and a solution has been proposed.

Area: ccrewrite
Issue related to Code Contracts rewriter.

Area: cccheck
Issue related to Code Contracts static analyzer.

Area: ccdocgen
Issue related to contracts documentation generator.

Area: ccrefgen
Issue related to contract reference assemblies generator.

Area: contract
Issue related to contracts for .Net Framework assemblies.

Area: installer
Issue related to Code Contracts installer.

Area: editor extension
Issue related to Code Contracts Editor Extension.

Area: property page
Issue related to Visual Studio property pages for Code Contracts.

Area: documentation
Issue related to product documentation.

ClosedAs: ByDesign
The current behavior is by design and will not be changed.

ClosedAs: Duplicate
Another issue contains a description of the same problem.

ClosedAs: Invalid
The issue concerns a documented and correct behavior.

ClosedAs: Question
The issue is a question for which an answer has been provided.

ClosedAs: Fixed
The issue has been resolved.

Type: Bug
The issue concerns a bug in the code.

Type: Enhancement
The issue concerns an improvement to an existing functionality.

Type: Feature
The issue concerns a completely new functionality to be implemented.

@hubuk I don't think that we need so many different labels right now. I would like to stay with minimum number of labels and add them along the way when it would be obvious that wee need all of them.
For instance, all this different labels per area would be useful only when we really would have tens of issues per each area. It could be true but could be not. The same is true for ClosedAs. Right now we have less issues than proposed labels.
As I said, I would prefer evolve those labels based on real needs. Is it ok for you?


Fix doc typos

Hi there,
Many thanks for a cool repo! Makes for interesting holiday reading :)
Just fixed some minor typos in the docs, done on a branch.
Cheers

Thanks! lgtm


Add bitwise air constraints with currently supported syntax

This PR adds a modified version of existing bitwise air constraints to work with currently supported syntax and adds an integration test to check for expected code generation.

Thank you @grjte for the review. Made suggested changes and fixes.

I'm not sure that it makes sense to have the duplication or to have unsupported syntax in our examples (although we can use a variation of that file for the next version)

I've removed the examples directory entirely as we have all those files in the integration tests now.

I don't think we should delete all the examples though, since in the docs & CLI examples we mention that they can be used for testing transpilation with the CLI. Maybe it would be best to just restore them for this PR and then submit a separate PR that has just one example which could be the example from the docs that includes all the syntax. What do you think?

Makes sense. I've opened #74 based on your suggestion.

@tohrnii is this ready for me to review again?


Update data-box-disk-system-requirements.md

@alkohli please review and merge

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

@madhurinms looks good. Please merge. #sign-off

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

Minor fix: Added missing space to added content.


Fix #865 Re-org the source tree

Fix #865

202430f eliminates the missing languages in the .adoc files.


Add license information to package.json

Adding license type to package.json helps license tools to identify this package's license, e.g. license-checker or license-report.

Thanks! Can you please base your PR on the dev branch?

Fixed in dev branch. Thank you 🐙


Render size width sets width to the longest word

When a node with a DOMElement is marks to be render sized width with content being a string, the width is is determined by the longest individual word.  I would imagine that this example would have a single line of text.
// Famous dependencies
var DOMElement = require('famous/dom-renderables/DOMElement');
var FamousEngine = require('famous/core/FamousEngine');
FamousEngine.init();

var scene = FamousEngine.createScene();
var root = scene.addChild();
root
  .setSizeMode(1, 1, 1)
  .setAlign(.5, .5, .5)
  .setMountPoint(.5, .5, .5)
  .setAbsoluteSize(400, 400);

new DOMElement(root, {
  properties: {
    backgroundColor: 'red'
  }
})

var node = root.addChild();
var element = new DOMElement(node, {
  content: 'Hello the following word will determine the width: bananananananana',
  properties: {
    background: 'yellow'
  }
});

node
  .setSizeMode(2, 2)
  .setMountPoint(.5, .5)
  .setAlign(.5, .5)

Probably caused by incorrectly setting the initial container size. I remember that we had a similar issue when the root element was detached instead of hidden. This might be a regression.

That is not the case.  It has to do with the fact that we need the content div to have position absolute since it would otherwise affect the positioning of children.  As such, it stops the div from growing in a strange way.


update primitives pages to use circuit library and 127q hardware

Fixes #255.
Fixes #256.

Instead of random_circuit, use IQP from the circuit library
Instead of ibmq_qasm_simulator, use the 127-qubit device ibm_brisbane
Increase circuit sizes to 127 qubits. As part of this, I deleted any code that draws the circuits, as these circuits are too large to display in a reasonable way.

how confident are you that this code is runnable on a real device? Hypothetically could a user copypaste these code snippets and run it?

For all the snippets, I tested that the jobs submitted successfully. Due to queue times I couldn't find out if they would run successfully, but as far as I can tell there's no reason they should fail.

we got feedback about not using random circuits but instead using the circuit library, I see now you are mostly using the circuit library but with random hermitians. Are random hermitians much better than random circuits? At least for the get started code snippets could we use something a bit more real?

IQP circuits were invented to demonstrate the hardness of simulating quantum circuits, not for any inherently useful purpose, so I think it makes to generate them randomly. For the examples where I used IQP, I needed a non-parameterized circuit, so variational ansatzes like RealAmplitudes or EfficientSU2 were out of the question. The "useful" choices like QFT or PhaseEstimation aren't actually practical to run on noisy devices. This is why I went with IQP.


Updates to ignoredProperties in memory getting lost

This could very well just be me doing something stupid. Basically, I have an Object that has a list of child objects, and when I try to modify an ignoredProperty on a child object and then access it, it still has the default value. I've put together a little sample project that demonstrates this.
class SomeObject: Object {
    dynamic var name = ""
    var children = List<ChildObject>()
}

class ChildObject: Object {
    var enteredValue = ""
    dynamic var name = ""

    override static func ignoredProperties() -> [String] {
        return ["enteredValue"]
    }
}

let realm = try! Realm()

let newObj = SomeObject()
newObj.name = "Parent object name"
let child = ChildObject()
child.name = "Child name"
newObj.children.append(child)

try! realm.write {
    realm.add(newObj)
}

array = Array(realm.objects(SomeObject.self))

let newString = "Some new string"
array.first!.children.first!.enteredValue = newString
assert(newString == array.first!.children.first!.enteredValue)

That assert fails for some reason.
Here is the full project.
RealmTest.zip

Thanks for getting in touch with us.
Unfortunately, the behavior you're seeing is expected. Ignored properties are only guaranteed to be consistent across individual Swift instances, but retrieving an object from a collection creates a new Swift instance each time, thus the behavior that you see.
Normally this isn't problematic, since the Swift instance serves as a lightweight view to the underlying object in the database (and thus all instances of an Object pointing to the same underlying object should behave consistently), but ignored properties don't care about this relationship.
Hope that helps.

Thanks for the prompt response, that does help.


[Improvement] Possible thread issue in MemoryConnectorAdapter.java

What would you like to be improved?
A static field version is being updated in a non-static method buildInternalConnectorConfig.
Correctly updating a static field from a non-static method is tricky to get right and could easily lead to bugs if there are multiple class instances and/or multiple threads in play. Ideally, static fields are only updated from synchronized static methods.
How should we improve?
Make the method static?

Fixed by @coolderli in #2139

@coolderli
The same applies to this issue.

Closed by https://github.com/datastrato/gravitino/pull/2139


Portfolio skeleton

Added main contents and pages (gallery, projects).

Nice! Love the photos and quotes :)

Thanks! Merging


Enable support for generics in trait-less impl

rust:
    struct Wrapper<A> {
        v: A,
    }

    impl<A> Wrapper<A> {
        #[spec]
        pub fn take(self) -> A {
            self.v
        }
    }

    #[proof]
    fn test_impl_1(a: int) {
        let w = Wrapper { v: a };
        assert(w.take() == a);
    }

air:
 ;; Function-Decl crate::Wrapper::take
 (declare-fun Wrapper.take.? (Type Wrapper.) Poly)

 ;; Function-Axioms crate::Wrapper::take
 (axiom (fuel_bool_default fuel%Wrapper.take.))
 (axiom (=>
   (fuel_bool fuel%Wrapper.take.)
   (forall ((A& Type) (self@ Wrapper.)) (!
     (= (Wrapper.take.? A& self@) (Wrapper./Wrapper/v self@))
     :pattern ((Wrapper.take.? A& self@))
 ))))
 (axiom (forall ((A& Type) (self@ Wrapper.)) (!
    (=>
     (has_type (Poly%Wrapper. self@) (TYPE%Wrapper. A&))
     (has_type (Wrapper.take.? A& self@) A&)
    )
    :pattern ((Wrapper.take.? A& self@))
 )))

 ;; Function-Def crate::test_impl_1
 (check-valid
  (declare-const a@ Int)
  (declare-const tmp%1@ Bool)
  (declare-const tmp%%1@ Wrapper.)
  (declare-const w@ Wrapper.)
  (axiom fuel_defaults)
  (block
   (assume
    (= tmp%%1@ (Wrapper./Wrapper (I a@)))
   )
   (assume
    (= w@ tmp%%1@)
   )
   (assume
    (= tmp%1@ (= (%I (Wrapper.take.? INT w@)) a@))
   )
   (block
    (assert
     "test.rs:21:5: 21:26 (#0)"
     (req%pervasive.assert. tmp%1@)
    )
    (assume
     (ens%pervasive.assert. tmp%1@)
 ))))

This isn't quite right yet, the generated air isn't quantifying over B& here,
 (axiom (forall ((A& Type) (self@ Wrapper.) (b@ Poly)) (!
    (=>
     (and
      (has_type (Poly%Wrapper. self@) (TYPE%Wrapper. A&))
      (has_type b@ B&)
     )
     (has_type (Poly%Two. (Wrapper.take.? A& self@ b@)) (TYPE%Two. A& B&))
    )
    :pattern ((Wrapper.take.? A& self@ b@))
 )))


[RFC] Get a Provider Bearer Token from Backstage

Status: Open for comments
Need
We need to be able to fetch the catalog data via API from other microservices and cloud scripts. We use Okta authentication therefore backstage is issuing a token for the logged in user. This is fine if the user is logged in via the sign in page from the portal and after that, we can use the catalog API to fetch the entities without a problem.
However, if the API is accessed from another microservice or script the request is not authorized.
So far, I was unable to find an appropriate endpoint that will issue a token for the given provider based on the clientid and secret from within the backstage APIs.
Is there a way to achieve this in backstage or do we need to get the token from Okta API and pass it down to the backstage request that we want to access/authorize?

This has begun being introduced in #7943, although it's not at the point of issuing tokens for external services yet. A stop-gap could be a simple utility that is able to generate a key in the same way as the ServerTokenManager does

Thanks @Rugvip
I'm aware of the change and we have the API protected with ServerTokenManager.fromConfig with some weak string until the change you are making settles.
I opened this issue to find out if there is a way to achieve what I need without adding utilities or customizations because I could not find anything in the backstage source code that proves it possible. Thank you for the quick answer 👍
So for now, it is either that we need to use ServerTokenManager.noop or create something like a utility/custom API endpoint to issue a token, and in the upcoming releases, we will have this integrated into the core? Is this a correct assumption?

@ProticM yep something custom for now. If you make it an endpoint then you ofc wanna make sure that's protected in some way. We'll definitely want to provide a solution for this long term but no plans yet, happy to discuss the way forward in this issue.
And correct, this does not relate to any of the auth providers as those are all for individual user authentication. The service-to-service auth is a parallel track that lives alongside the user auth system, although they ofc intersect that the point of protecting backends and some other places.

@Rugvip Yes, our instance is behind Cloudflare so we should be good 😸
To clarify, I was thinking about having something exposed from backstage to be used by external systems to fetch the token/key and that resulting token/key to be used as an authorization in any further requests towards our backstage instance.
I was not thinking of having a utility to create a key outside of backstage, but it is worth considering that approach. When you say utility, did you have something like this in mind, outside of backstage?

What I had in mind was just a simple Node script or something of that sort, where you provide the secret and it hands you back a key that can then be configured in your external services.

Yes, I assumed something like that based on your comments thus I asked just to be on the same page 👍

I guess I'm trying to understand how the custom generated key/token (based on our secret in the config auth.keys section), unrelated to the provider, will bypass the Okta sign-in protection that we have in place, without the Okta token 🤔
This is what the ServerTokenManager generates, to my understanding, and if that is the only thing we provide from an external system, I assume it will not be enough because of the Okta sign-in in place.

@ProticM It won't, you'll need to update your middleware to allow backend tokens through as well. Wanna emphasize again that deploying behind a reverse proxy or some other form of perimeter is the only way of protecting a Backstage instance the we recommend right now, as the authenticating middleware isn't something we're officially supporting.
The current use-case for backend authentication is for use with the permission plugin only, although you can bend it to protect the backend as well, that's not something we support out of the box. It likely will be built into the core in the future, but we're not there yet. But more context over here as well https://github.com/backstage/backstage/pull/7943#discussion_r755054836

@Rugvip Yes, thanks for clearing it out. I can add here once more that we have it deployed behind Cloudflare

@ProticM ah are you looking into having external services get through cloudflare and reach your instance?

@Rugvip Yes, this is the case that I'm looking into
I was trying to get the info is it possible to get the required token from backstage directly somehow, from the external service, since we already passed down okta client id and secret via config.
I did not find something like this in the source code.
But the main goal here is to find the best approach to get through the cloudflare and I'm looking into the posibilities

@ProticM ah alright, that's really gonna be up to cloudflare/okta then tbh and not something we can handle in Backstage. Typically it'd be called "service account" or something or something like that, perhaps this? https://developers.cloudflare.com/cloudflare-one/identity/service-auth/service-tokens

@Rugvip Yes, this is expected, but nice to have it confirmed. I was investigating, more or less, the usual flow where the service you want to access gives you the access token.
As for me, we can close this RFC


Wrapping everything in nextTick() should be optional

Calling nextTick is good for letting other parts of application to execute, but it may cause nonobvious problems when dealing with streams in node.js.
For example, creating ReadStream and then using it after resolve will end up in skipping some "data" events on it, because we skipped one event-loop tick.

The purpose of calling nextTick in this case is not so much to permit interleaving, but to force deterministic interleaving of the callbacks. Callbacks are required to occur in future turns, instead of occurring either on the stack or in a future turn. Using nextTick increases the robustness of everything built on top of Q.
It’s relatively straightforward to safely handle a readable stream in conjunction with promises.
https://github.com/kriskowal/q-io/blob/master/q-io.js#L13-100
(Needs further work to support throttling, but has been indispensable for my stack.)

Yes, running callbacks on stack is not preferable for flow control module, I agreed.
But can you please point me to any place where such nextTick behaviour is documented? I spent some time on figuring out, why streams was broken in my app, and it'll be great to let everyone know that callbacks are running not immediately.

Thanks. The documentation needs another pass for clarity, for sure. nextTick reads as “called in a future turn of the event loop” throughout README.md
excerpt:
when(value, fulfilled_opt, rejected_opt)
Arranges for fulfilled to be called:

with the value as its sole argument
in a future turn of the event loop
if and when the value is or becomes a fully resolved

Arranges for rejected to be called:

with a value respresenting the reason why the object will
never be resolved, typically an Error object.
in a future turn of the event loop
if the value is a promise and

if and when the promise is rejected

Returns a promise:

that will resolve to the value returned by either of the
callbacks, if either of those functions are called, or
that will be rejected if the value is rejected and no
rejected callback is provided, thus forwarding
rejections by default.

The value may be truly any value.  It can be a function.
It can be a promise.
Either callback may be falsy, in which case it will not be
called.
Guarantees:

fulfilled will not be called before when returns.
rejected will not be called before when returns.
fulfilled will not be called more than once.
rejected will not be called more than once.
If fulfilled is called, rejected will never be called.
If rejected is called, fulfilled will never be called.
If a promise is never resolved, neither callback will
ever be called.

Now tracking as #31.


Writing observations

Hello @mbaske. Can you explain what part of your code actually writes observations to the agent? I see Write(ObservationWriter writer) functions at AudioSensor.cs and AudioSensorProxy.cs but apparently they are never called? At least I tried to see if they are ever called by some Debug.Log statements, which were never invoked. I want to see which observations are actually processed by the agent. My task is fairly simple, identifying 5 piano keys when played, but no matter what I tried, the agent is not being trained. I also tried your ChordDetection example. I did not change anything, just started training using supplied training config, however the model could not train. It just did not converge, the loss kept fluctuating.
Thanks.

Hi - sensors implementing ISensor provide the public int Write(ObservationWriter writer) method for the ml-agents code. Please see<EMAIL_ADDRESS>

Thanks for your reply. Turns out the problem was with the fact that we need to use --time-scale 1 when training a model, not with the observations that are supplied to the agent. Great repo btw!


Adds boilerplate for adding fully-executed Jupyter notebooks

@robertness if you want to add your Jupiter notebook into here, this also provides the skeleton for organizing the Jupiter notebook tutorials into more semantically involved sections.
Before submitting

[ ] I've read and followed all steps in the Making a pull request
section of the CONTRIBUTING docs.
[ ] I've updated or added any relevant docstrings following the syntax described in the
Writing docstrings section of the CONTRIBUTING docs.
[ ] If this PR fixes a bug, I've added a test that will fail without my fix.
[ ] If this PR adds a new feature, I've added tests that sufficiently cover my new functionality.

After submitting

[ ] All GitHub Actions jobs for my pull request have passed.

Codecov Report

:exclamation: No coverage uploaded for pull request base (tutorial@62f15c5). Click here to learn what that means.
The diff coverage is n/a.

:exclamation: Current head 5e45ff4 differs from pull request most recent head c6d8f81. Consider uploading reports for the commit c6d8f81 to get more accurate results

@@             Coverage Diff             @@
##             tutorial      #68   +/-   ##
===========================================
  Coverage            ?   82.11%
===========================================
  Files               ?       20
  Lines               ?     1303
  Branches            ?      246
===========================================
  Hits                ?     1070
  Misses              ?      152
  Partials            ?       81

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Chrisda to Main

Docs Build status updates of commit eeb0806:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

exchange/exchange-ps/exchange/Get-MessageTrace.md
:white_check_mark:Succeeded
View (exchange-ps)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Added devcontainer for wash

Simple devcontainer that installs rust and bind mounts this project into a container. Should work with codespaces and make it easy to develop wash even on machines with no Rust tooling!

From the way you've written the PR it sounds like you haven't tested the container? "should work with codespaces".
I don't think we should add extra config files to the repo if they haven't been tested / aren't being used. Then it's on us to maintain them later. However if this is being used by you or someone else then I'll approve

@mattwilkinsonn I tested this locally with devcontainer open, which worked swimmingly! I didn't quite figure out a good workflow for starting a codespace using this devcontainer, but it turns out that just navigating to the branch and creating a codespace will use this by default.

Works great 😄


Put rules and configuration in /etc/apache2/.d/ folders

I'm not sure why we're overriding the entire httpd.conf file. It should be possible to use place configuration file in conf-available.d/ and sites-available.d/ folders, and add symlinks to those files in the respective <foo>-enabled.d/ folders to activated them (which is the typical Apache configuration pattern).
The rules for ModSecurity seem to go into a dedicated configuration folder, namely /etc/apache2/modsecurity.d/, IIRC.
Unless there are really good reasons to override the main httpd.conf I believe we should take the granular, modularized configuration file approach.

There are some setup hints in the crs-setup.conf.example file of the owasp-modsecurity-crs repository. Maybe that's helpful.

I've started to tackle this on the feature/modularize-configuration branch.


add slowg analyzer to check inappropriate use of log/slog

Will this analyzer run by default?

I've enabled it by default, yes.

If so, I'm worried that it will break the cilium repo.

In which way? I don't understand your concern as Cilium is not even using log/slog yet 🤔

Converted back to draft, the log functions were renamed from XXXCtx to XXXContext and thus the linter needs an update.

CI is now failing as there is no tagged release of Go 1.21 that includes this change yet. Unfortunately, it looks like we cannot specify tip or a commit sha as the Go version to use in the matrix of tests.

I'll mark the PR as ready to merge. CI should turn green once we update Go 1.21 to the RC.3.

Go v1.21.0-rc.3 is out so I updated the Go matrix in the CI tests and, as expected, the tests now pass.
@nathanjsweet Could you please check this PR again or give a rationale as to why you think we shouldn't merge it as is?


fix:Output stdout errors if no stderr exist

Codecov Report
Attention: 610 lines in your changes are missing coverage. Please review.

Comparison is base (c9fcd60) 44.65% compared to head (e087091) 45.02%.
Report is 159 commits behind head on main.

Files
Patch %
Lines

dbt_coves/tasks/load/airbyte.py
13.28%
111 Missing :warning:

...coves/tasks/generate/airflow_generators/airbyte.py
0.00%
79 Missing :warning:

...bt_coves/tasks/generate/airflow_generators/base.py
0.00%
78 Missing :warning:

...oves/tasks/generate/airflow_generators/fivetran.py
0.00%
63 Missing :warning:

dbt_coves/tasks/generate/docs.py
38.75%
49 Missing :warning:

dbt_coves/tasks/generate/airflow_dags.py
75.89%
47 Missing :warning:

dbt_coves/tasks/load/fivetran.py
18.60%
35 Missing :warning:

dbt_coves/utils/flags.py
61.01%
23 Missing :warning:

dbt_coves/utils/secrets.py
15.38%
22 Missing :warning:

dbt_coves/core/main.py
51.16%
21 Missing :warning:

... and 14 more

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #426      +/-   ##
==========================================
+ Coverage   44.65%   45.02%   +0.37%
==========================================
  Files          34       42       +8
  Lines        2770     3500     +730
==========================================
+ Hits         1237     1576     +339
- Misses       1533     1924     +391

Flag
Coverage Δ

unittests
45.02% <41.06%> (+0.37%)
:arrow_up:

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.


Opening a background tab and going back to tabs makes tabs window to scroll to top

Describe the bug
Opening an uncached/not loaded/background page in tabs window and then going back to tabs seems to scroll it to the top which may get annoying if you have a lot of tabs open
How to Reproduce
Steps to reproduce the behavior:
The most reliable way would probably be..

Open some page and open a new background tab from there
Return to tabs
Enjoy the scroll

Expected behavior
Tabs window should stay at the same position you are opening the link from, as it has been in previous builds
Smartphone (please complete the following information):

DDG App Version: 5.87.0
Device: Xiaomi Redmi 8
OS: Android 10

@eccul I'm trying to reproduce this issue, but it seems to work for me. So let me double check with you if I understand the steps you posted there.

Open some page and open a new background tab from there -> I have multiple tabs open. From any tab, I long click a link and then I select "Open in Background tab"
Return to tabs
Enjoy the scroll -> In my case, the tab selected is the one where I was and I don't need to perform any scroll.

am I missing any step? thanks

Thanks for trying to reproduce this! I think a consistent way to repro this is:

Let's assume you have a handful of tabs opened. Focus on a tab from somewhere in the middle (from my testing, there's no issue with tabs at the bottom)
Close the app and reopen it
Return to tabs

But generally you should be able to reproduce whenever you open a non-loaded page and return to tabs, or open a background tab from such page.

Does it still happen in the latest release (5.88.0)? I managed to reproduce the issue on 5.87.0 but not in the latest one.

Yeah, I've been on 5.88.0 all this time, so I can reproduce on latest.

Hi all - just going to jump in on this one. I'm also able to reproduce it on 5.88.0
Attaching video: https://drive.google.com/file/d/1YJfP-jeKJaCTv4NwBZxvq6AuaJ42nxi9/view?usp=sharing
To be honest I'm not sure that this is related to background/cache loading etc. It seems like Recycler / UI thing. It's not in a video but I am also able to notice a moment the list scroll up even before new tab slides in from the bottom. I would need to take a peek into the code to verify any of this.

Thanks, we have created a task to investigate the bug and try to fix it.

Thanks @cmonfortep seems to be working fine now. Not ideal though. Using .post { } is an obvious quick fix but the list will still jump around. If you select tab tile that's currently at the top of the list and then "go back" (as the Activity is actually recreated) the Recycler will scroll to it's bottom.
 I see current implementation and see how this might be a little bit more tricky to do 100% perfect.
Thanks again.

Hey, don't know if it matters, but seems fixed in 5.89.1 as I can't repro anymore. (:

@eccul Thanks for reaching us to confirm the issue was fixed. We included a fix in our latest release. 👍


HSearch numeric ranges use wrong precision

When Elastic/Lucene is enabled, search for numeric values doesn't respect precision specification
To Reproduce

Add a resource with a quantity of 100
(according to spec, the search range should be 99.5-100.5)
Search for resources with defined quantity of 99.4
Resource is found

Expected behavior
Resource not found, as search was out of specified range
Environment (please complete the following information):

HAPI FHIR v6.0.4

Fixed by:   https://github.com/hapifhir/hapi-fhir/pull/3871


queryselector: Remove blog link, deadurl

https://cjihrig.com/ "is parked free, courtesy of GoDaddy.com."

Thanks!


Add doctests on runners with regards to exit code checking

Add doctests on runners with regards to exit code checking, see https://github.com/neuromation/cookiecutter-neuro-project/pull/191#discussion_r353233793

outdated


Released web map "Foundation Data - Terrain Overlays" references unreleased services

Web map "Foundation Data - Terrain Overlays" 506ad5fc2bcb423a9ded96180e5cd9f5  is owned by DemoNationalSecurity however it references the following services which are not released and not in the review process:
b9ef7590b9c9440c87ce17c448b38b53, HMMWV_CCM

This was in #1209

Closing as duplicate.


Add KeyStateTracker.enabled

From https://github.com/phetsims/phet-io/issues/995

Enabled added above, plus tests. I'll set it in Sim.activeProperty back over in https://github.com/phetsims/phet-io/issues/995. @jessegreenberg please review.

This looks great, thanks @zepumph.

Actually, reviewing https://github.com/phetsims/phet-io/issues/995 made me wonder if we need to broadcast an event when we clear the keystate. Most listeners on the globalKeyStateTracker are attached to keyup so this isn't a problem in sims. But imagine a listener is on keydown and they sim became inactive while keys are down. When becoming active components wouldn't get the message that the keystate was cleared.
keyupEmitter and keydownEmitter emit with a DOMEvent, so we can't use those. Maybe the keyState should be a public observable or something. @zepumph assigning to you if you have thoughts or we could work on this during a dev meeting.

Actually, this applies more generally to KeyStateTracker.clearState, im going to create a new issue and re-close this one.


[WIP] Lazy start database service

Only starts the database service when necessary. The main motivation here is to keep import time low so that simple non-DB CLI commands (for example) can run faster.
Marked as WIP until we formalize the interface for "things that require DB access" a bit. The current approach probably doesn't cover all cases...

@benjaminpkane this is not high priority, but, if you have a minute at some point, I'd be interested to hear if you have any ideas for how to formalize this a bit better

Just tried to run fiftyone quickstart on this branch after merging latest develop and encountered this error. Looks like the recent App browser changes would necessitate more work to get this working.
It occurs to me that another approach to reduce import times could be to allow the DB service to run as a daemon.

Just tried to run fiftyone quickstart on this branch after merging latest develop and encountered this error. Looks like the recent App browser changes would necessitate more work to get this working.
It occurs to me that another approach to reduce import times could be to allow the DB service to run as a daemon.


BigQuery module in Pandas not working for Chrome App

I have this working in iPython notebook on my desktop but get the error below when trying to run through the chrome app. This is the query
import pandas as pd
from pandas.io import gbq

project_id = "XXXXXXXXX" # used real project id but removed for issue

query = "SELECT repository_name, repository_url FROM [githubarchive:github.timeline] LIMIT 100"

df = gbq.read_gbq(query, project_id)

The error returned
---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)
<ipython-input-24-eb99f9b53906> in <module>()
      3 query = "SELECT repository_name, repository_url FROM [githubarchive:github.timeline] LIMIT 100"
      4
----> 5 df = gbq.read_gbq(query, project_id)

/usr/lib/python2.7/site-packages/pandas-0.13.1-py2.7-linux-x86_64.egg/pandas/io/gbq.py in read_gbq(query, project_id, destination_table, index_col, col_order, **kwargs)
    512                                       'yet')
    513         else:
--> 514             raise ImportError('Could not import Google BigQuery Client.')
    515
    516     if not _BQ_VALID_VERSION:

ImportError: Could not import Google BigQuery Client.

This version of colaboratory is no longer supported, please switch to https://colab.research.google.com.


plans pre v0.4.0 do not get deleted automatically and can cause periodic flapping

Version

v0.4.0

Platform/Architecture

linux/amd64

Describe the bug
Since v0.4.0 plans are created, by default, with the upgrade.cattle.io/ttl-seconds-after-finished annotation to allow the SUC to replicate the TTL Controller for Finished Resources style of garbage collection for the Jobs that it creates to apply Plans. Jobs created by SUC prior to v0.4.0 were left to be garbage-collected manually and it turns out that these legacy Jobs confuse the new enqueue-or-delete cleanup logic such that the controller will delete Jobs with the upgrade.cattle.io/ttl-seconds-after-finished annotation but then next cycle it will process the legacy jobs as complete and label the node as per their stale Plan Latest Hash. This causes a Job to be created to apply the Plan again (because of a mismatch in the value of the plan.upgrade.cattle.io/${plan.name} label) and if it has drain configured it will terminate non-DaemonSet Pods
To Reproduce

install k3OS v0.9.1
kubectl edit -n k3os-system plan/k3os-latest # set version=v0.10.0
kubectl label node -l k3os.io/mode plan.upgrade.cattle.io/k3os-latest=enabled --overwrite
watch the apply-k3os-latest-on-* Job get re-created and run approximately every 15 minutes

Expected behavior
The upgrade job should apply only once.
Actual behavior
The upgrade job will be applied periodically ad nauseum.
Additional context
https://github.com/rancher/k3os/issues/432

The current work-around is to delete all Jobs in the SUC namespace.


Offers pagination

@gzili I disagree with your statement about page numbering as i think it is more important for users to see actual page number starting from 1

@gzili all requested changes added

Sorry but I was too lazy to explain everything and fixed all the performance issues myself. I also generalized the PaginatedListDto and extracted most of the code into the service. It still needs some cleanup before merging but that's the implementation that I was looking for. Anyhow, thanks for your contribution.


Consider providing mechanism resolve topic id to topic name

Apache Kafka protocol has gradually been transitioning from using topic names to using topic ids.   The current work of
KAFKA-10551 and KAFKA-10549 applying the new pattern to produce and offset requests.    Fetch filter already works in that way.
Some filters may accept configuration in terms of topic name or topic name patterns.  Those filters may need to resolve topic ids into topic names in order to do their processing.   Whilst it is possible for each filter to builds its own metadata cache, Kroxylicious may wish to offer an API to relieve the filter of this burrden.

I think this opens another question : how to inform the client about supported versions through the filter chain ?
Idea is, when a client send an ApiVersion request, we must be able to answer with an evaluated version through the filter chain.
sequenceDiagram
    participant Client
    box Kroxylicious
    participant Filter 1
    participant Filter 2
    end
    participant Kafka
    Client->>Filter 1: Api Versions request
    Filter 1->>Filter 2: Api Versions request
    Filter 2->>Kafka: Api Versions request
    Kafka-->>Filter 2: Api Versions response
    Note over Kafka,Filter 2: api_key: 9
min_version: 0
max_version: 9
    Filter 2-->>Filter 1: Api Versions response
    Note over Filter 1,Filter 2: api_key: 9
min_version: 8
max_version: 9
    Filter 1-->>Client: Api Versions response
    Note over Filter 1,Client: api_key: 9
min_version: 8
max_version: 9

In this example, Filter 2 requires a minimal version of 8 for api key 9, so we set in the chain that minimal version is 8.
This should let client fail fast for versions incompatibility.
As I understand, currently this behavior is possible, but each filter must override the ApiVersionsResponseData and evaluate the versions to rewrite (or not).

Currently the upstream Kafka issues are tagged for Kafka 3.9, so this is not a blocker for Kafka 3.8 support.


Mac version possible?

Hi, this project looks very promising, thank you so much!
Would it be possible to get this working on a Mac? Or is there any dependency that only runs natively in Windows? If it is possible could maybe someone guide me on how to get this working on a Mac? Maybe the python requirements.txt or all the needed dependencies.
Greetings.

I second this

yes, mac version please :)

Has anyone given the latest Vulcan branch of geopix a try? It in theory should sort of work now on macs, though there are still some windows things going on that will prevent it from being fully compatible.. however a big step closer.
If anyone does get the chance to try it out please let me know how it goes and leave any specific issues you find here.

How would we go about installing it on a mac?

You can download a zip of the repo of the Vulcan branch here:
https://github.com/EnviralDesign/GeoPix/tree/vulcan-update
Uncompress the zip file to a folder, then open the geopix.toe with the notes version of touchdesigner that is listed in the readme.
I need to update it to latest soon, but it's very close.

I made a bash version of the assets download script in #63 which removes the Windows req. As others have pointed out, launching on Mac is a matter of just opening the toe in TD, but right now it has a bunch of errors. Happy to help debug if there's interest.

SOURCE: DAT : 3 : /software/top/Time/timeline_collapsed/timePreview/script2_callbacks
ERROR: (95) Traceback (most recent call last):
File "/software/top/Time/timeline_collapsed/timePreview/script2_callbacks", line 12, in onCook
td.tdError: Module compilation error. See /software/top/PixelMapEditor/logic/local/modules/tdUtils for details.
SOURCE: DAT : 3 : /software/top/PixelMapEditor/logic/local/modules/tdUtils
ERROR: (95) Traceback (most recent call last):
File "/software/top/PixelMapEditor/logic/local/modules/tdUtils", line 19
r = previousimport(*args, **kw)
ModuleNotFoundError: No module named 'natsort'
SOURCE: DAT : 3 : /UberGui/Scheduler/chopexec_updateTime
ERROR: (110) Traceback (most recent call last):
File "/UberGui/Scheduler/chopexec_updateTime", line 5, in whileOn
td.tdAttributeError: 'td.containerCOMP' object has no attribute 'GetCurrentTime_Epoch' Context:/UberGui/Scheduler


The default IamFleetRole changed on AWS-side?

kube-aws: v0.9.9-rc.3, but any version would be affected
I've just added a spot-fleet based node pool to my cluster and it failed like this:

The value for the IamFleetRole property was:
"IamFleetRole":{"Fn::Join":["",["arn:aws:iam::",{"Ref":"AWS::AccountId"},":role/aws-ec2-spot-fleet-role"]]}

which had certainly worked before.
As far as I remember, aws-ec2-spot-fleet-role was taken from the "Request Spot Instances" on AWS console because it was the default role at that time.
However, interestingly the default shown today is aws-ec2-spot-fleet-tagging-role.

Can we just change the default to the new role?
Does your AWS account shows the new role as the default one once you've browsed to the "Request Spot Instances" pane?

I checked our accounts and it's still aws-ec2-spot-fleet-role there. Can't find aws-ec2-spot-fleet-tagging-role anywhere. Probably we need to just include our own role with the same permissions.

@c-knowles Would you mind reviewing your IAM roles after you've navigated to the second page after clicking "Request Spot Instances" button in your AWS console?
The reason I'm asking is that the new role seems to have CreateTags permission, which probably is missing in the old role. So whenever you navigate there today, I suppose the new default role should be created.

Update: docs.aws.amazon.com seems to include the new role in all the examples I've reviewed today.
Also relevant: https://github.com/terraform-providers/terraform-provider-aws/issues/1232
I'm not saying we should completely drop support or comment for the old role.
We should, at least, suggest in cluster.yaml comments to encourage users to navigate to the spot fleet request page once again to create the new role(if it is created in such way

@mumoshu yes it has aws-ec2-spot-fleet-tagging-role there now I've clicked that so that does assume the user has taken the manual step to request a spot fleet prior to deploying. Since it's only a managed policy and not a managed role or service linked role, it seems like we could just create this role ourselves and remove that potential manual step?

@c-knowles Thanks for confirming!

it seems like we could just create this role ourselves and remove that potential manual step?

I had initially thought that I'd rather prefer not to create it ourselves - so that we can save number of IAM roles created by kube-aws.
However, I'm now convinced to do it - manual steps should be eliminated whereas possible :trollface:
I'll open an another issue for that.

@mumoshu yeah that's all I mean, if it's not a managed role then we're forced to include it 👍


Tests - test creation - label

Besides, would it be good to adjust some fixtures to have a label included?


x86_64 virtio:get interrupt vector for virtio dev on x86_64

obtain the routing info from PCIe device pin to  IOAPIC irq pin using ACPI table.
route IOAPIC irq to interrupt vector by programming IOAPIC.

Thanks! Please fix CI.

Thanks! Please fix CI.

OK! I managed to fix some CI problem related to this PR. But dev branch itself does not compile before this PR, so i can not get this PR to fully pass CI :( .

Thanks! Please fix CI.

OK! I managed to fix some CI problem related to this PR. But dev branch itself does not compile before this PR, so i can not get this PR to fully pass CI :( .

You can re-open a PR based on the main branch


Smallest Nodepool chosen regardless of pending Pods scale

Description
Observed Behavior:
After upgrading to Karpenter 0.32 (also in 0.35) and migrating from provisioners to nodepools, we observed that our on-demand pods are not being scheduled on the most suitable node size with the lowest price. Instead, Karpenter always provision from the smallest nodepool possible, regardless of the pending pods scale, leading to suboptimal node utilization.
We use to split our provisioners into different sizes with identical weights but varying CPU and EBS sizes to accommodate the ephemeral storage requests of our pods.
Expected Behavior:
The scheduler should evaluate all nodepools with the same weight and select the most cost-effective node size that can accommodate all pending pods, thereby optimizing node utilization.
Reproduction Steps :

Create the following nodepools with identical weights:

NodePool with "karpenter.k8s.aws/instance-cpu" requirements of "2" (small) with 100GB storage
NodePool with "karpenter.k8s.aws/instance-cpu" requirements of "4" (medium) with 150GB storage
NodePool with "karpenter.k8s.aws/instance-cpu" requirements of "8" (large) with 200GB storage

Deploy a simple deployment with a single core request.
Scale the deployment to various sizes (e.g., from 1 to 10 or 40 replicas).
Observe that all pods are scheduled on the 'smalll' nodepool, regardless of the number of replicas.

apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: small
spec:
  disruption:
    consolidationPolicy: WhenUnderutilized
    expireAfter: Never
  template:
    spec:
      nodeClassRef:
        name: default-ec2-node-class-100gb
      requirements:
        - key: karpenter.k8s.aws/instance-cpu
          operator: In
          values:
            - '2'
        - key: karpenter.k8s.aws/instance-family
          operator: In
          values:
            - c6i
        - key: karpenter.sh/capacity-type
          operator: In
          values:
            - on-demand
        - key: kubernetes.io/arch
          operator: In
          values:
            - amd64
        - key: kubernetes.io/os
          operator: In
          values:
            - linux
  weight: 100
---
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: medium
spec:
  disruption:
    consolidationPolicy: WhenUnderutilized
    expireAfter: Never
  template:
    spec:
      nodeClassRef:
        name: default-ec2-node-class-150gb
      requirements:
        - key: karpenter.k8s.aws/instance-cpu
          operator: In
          values:
            - '4'
        - key: karpenter.k8s.aws/instance-family
          operator: In
          values:
            - c6i
        - key: karpenter.sh/capacity-type
          operator: In
          values:
            - on-demand
        - key: kubernetes.io/arch
          operator: In
          values:
            - amd64
        - key: kubernetes.io/os
          operator: In
          values:
            - linux
  weight: 100
---
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: large
spec:
  disruption:
    consolidationPolicy: WhenUnderutilized
    expireAfter: Never
  template:
    spec:
      nodeClassRef:
        name: default-ec2-node-class-200gb
      requirements:
        - key: karpenter.k8s.aws/instance-cpu
          operator: In
          values:
            - '8'
        - key: karpenter.k8s.aws/instance-family
          operator: In
          values:
            - c6i
        - key: karpenter.sh/capacity-type
          operator: In
          values:
            - on-demand
        - key: kubernetes.io/arch
          operator: In
          values:
            - amd64
        - key: kubernetes.io/os
          operator: In
          values:
            - linux
  weight: 100

Versions:

Chart Version: 0.35.2
Kubernetes Version:  1.26.13

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request

Can you give an example of when Karpenter could have chosen a cheeper bigger node than a set smaller node from your cluster? Are you seeing Karpenter choose smaller nodes resulting in a higher cluster cost? Also, do you have any topology spread or pod antiAffinity for your workloads?

Indeed, I have observed a significant increase in our cluster costs post-upgrade. Previously, the majority of our nodes were configured with 48/64 cores, but now we are only seeing smaller nodes being provisioned, which has a substantial impact on costs. This cost increase seems to stem from the fact that each node incurs the overhead of daemonsets and system-reserved space, which, when multiplied across a larger number of smaller nodes, results in higher overall expenses.
To illustrate this behavior with above reproduction steps, you can deploy a daemonset with a request for 0.75 core and observe the provisioning behavior. Regardless of the scale of the test pod, Karpenter consistently launches only small, 2 cores nodes. This leads to a scenario where each node hosts only one test pod alongside the daemonsets, as opposed to a more cost-effective approach of provisioning fewer, larger nodes that could accommodate multiple replicas.

Can you share your deployment spec for the pods you try and schedule?

@engedaam  @tzneal As previously mentioned, when deploying a daemonset with a request of 1 core and pods of 700m CPU, then scaling it to numerous pods, it should ideally result in the provisioning of a few large nodes. However, what’s actually occurring is the creation of many smaller nodes, accompanied by an excessive number of unnecessary daemonset replicas, leading to significantly higher costs. Please do not reclassify this issue from a bug to a feature until it’s confirmed whether this is occurring only in my cluster or not. This has led to substantial expenses since the upgrade.
Here is an example of our cluster; with this deployment and daemonset setup, you can see that Karpenter consistently chooses c6i.large, even though it is the wrong selection:
kubectl get po

this deployment has no special affinity rules, nodeSelectors or topologySpreadConstraints
kubectl get node:

kubectl describe node (all identical)

Karpenter evaluates node pools in order of weight.  If pools are the same weight, it will use the first one that the pod can schedule against in an order that we don't currently guarantee and does not consider the other potential node pools.
I marked this as a feature request since the expected behavior described:

The scheduler should evaluate all nodepools with the same weight and select the most cost-effective node size that can accommodate all pending pods, thereby optimizing node utilization.

it not something that Karpenter currently does.

This is not accurate. Even if Karpenter never evaluates unnecessary daemonset replicas and only focuses on optimizing node utilization based on CPU total requests, providing larger nodes will consistently result in higher node utilization. Let’s look at the following example: in the first image, I scale 10 replicas of the deployment, and Karpenter deploys 10 small nodes, achieving 81% total node CPU requests:

However, in the second image, using the same deployment with identical resource requirements and replica count, after forcing Karpenter to select the larger nodes (statically increasing the weight of the larger node pool), we observe a 90% node CPU utilization:

In the first scenario, Karpenter launches 10 nodes with 2 cores, while in the second scenario, it deploys 2 nodes with 4 cores, which is significantly more efficient.
This behavior was not observed in Karpenter 0.31. Back then, we had many 64/128 CPU machines, but after the upgrade, none remain. This is definitely a bug because the behavior has changed, and the nodes are less utilized.
Regarding your suggested workaround, we don’t want to increase the EBS disk size for all nodes, as this would inflate our costs and lead to underutilized storage for smaller machines.

After further investigation, I believe I understand what is happening here. In Karpenter version v0.32 and earlier, the weights field was the only field that ordered the NodePools on provisioning  https://github.com/kubernetes-sigs/karpenter/blob/3d8192ce1f5adf79a3b8f5b5d27bd5fe76b3d678/pkg/apis/v1beta1/nodepool.go#L146 After v0.32 and later, Karpenter would order NodePools first by weights and then by NodePool Name.  This would explain why you see the smallest NodePool be chose first, as Karpenter will sort NodePool by name in descending order https://github.com/kubernetes-sigs/karpenter/pull/860. The intension was to make sure that there is consistent ordering for when Karpenter launched nodes.
As @tzneal  mentioned, Karpenter would always use the first NodePool that it found suitable for the workloads. Prior to this change, Karpenter would use the order that is provided by the API Server List call(which does not guarantee any order). As the NodePool list was randomized, Karpenter would not have consistent ordering on node launch, if the NodePools have the same weight. Furthermore, Karpenter can consolidate the nodes and use a larger NodePool, since each node provisioning round would have a different orderly set of NodePools.


DS4Windows.com exceeded bandwidth

Bandwidth Limit Exceeded
The server is temporarily unable to service your request due to the site owner reaching his/her bandwidth limit. Please try again later.
Also getting stuck at "Opening Installer" when running the latest DS4Windows.exe
Are you able to fix either of these?
Thanks

I got the website issue too :(


Using custom trained model as backbone [Patchcore]

Describe the bug
Hi,
Thanks for anomalib library.
I am able to do Patchcore based anomaly detection, but the performance seems to be stagnant at some point.
I am playing with parameters:
number of neighbours, coreset ratio, model architecture, making dataset diverse.
I am also using pretrained models.
However, I thought if I can use a model trained specifically on my dataset. How can I load a resnet34 model pretrined on my dataset for feature extraction?
Dataset
Folder
Model
PatchCore
Steps to reproduce the behavior
How to use custom pretrained model
OS information
OS information:

OS: [e.g. Ubuntu 20.04]
Python version: [e.g. 3.10.0]
Anomalib version: [e.g. 0.3.6]
PyTorch version: [e.g. 1.9.0]
CUDA/cuDNN version: [e.g. 11.1]
GPU models and configuration: [e.g. 2x GeForce RTX 3090]
Any other relevant information: [e.g. I'm using a custom dataset]

Expected behavior
Able to load model pretrained on custom dataset, for ex: using pretrained resnet34 model
Screenshots
NA
Pip/GitHub
GitHub
What version/branch did you use?
1.1.0
Configuration YAML
using engine.train function required parameters

Logs
NA

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Hi @lathashree01, you could refer to this documentation section for custom bacbones
https://anomalib.readthedocs.io/en/latest/markdown/guides/how_to/models/feature_extractors.html
Let us know if there is anything that is not clear


Gist issue20 dc

Standardized the labels.
Added usage of skos:prefLabel and (for the ontology itself) skos:note.
Fixed some of the definitions. (And added periods to the end of lots more.)
NOTE: I thought I had deleted the pull request ed56a20.  If there is a way to do that, please let me know.  Only the changes included in pull request 5c4241d should be merged.  (Presumably the later should overwrite the former.  But I just want to be sure there's no scrambling.)

Now I'm really confused. I thought this was closed yesterday. Why is new stuff coming in?

@DanCarey404 @uscholdm @marksem @ungricht @daliadahleh
I don't have time to review what issues were pushed or PRs merged, but the bottom line is this:

The task is to modify the TEXT of labels only
No other annotations are to be added
labels currently remain as rdfs:label
Any other issues have already been submitted as github issues and will be reviewed when their turn comes up

I don't know why there are now 4 reviewers on this PR. As a minor change, it requires only 2, and adding this many cooks to the broth does nothing but spread confusion.
We also don't have a "fixes #20" on this issue.
Of the reviewers here, only MarkW and I have permission to merge this PR to commit. I am pretty sure @marksem knows what's  going on so I'm going to reassign it to him. Mark, any questions can be referred to me.
Thanks to all.

@DanCarey404 @uscholdm @marksem @ungricht @daliadahleh
I have not yet looked at what has been pushed or merged, but the bottom line, based on our agreements at review meetings and notes on #20, is:

The task is to modify the TEXT of labels only
No other annotations are to be added
labels currently remain as rdfs:label
There is at least one GitHub issue related to specifying which annotation properties to use, and that question should not be brought in here.

Some process notes:

There should not have been four reviewers on this PR. As a minor change, it requires only two, and we have found that adding additional reviewers tends to spread confusion. I have pared back the list of reviewers to the required two.
We discussed at the last meeting (@DanCarey404 I'm not sure if you heard that part or if it was before you arrived) that PR titles should append the words "fixes #20" (or whatever the related issue number is) - this ensures that when the PR is merged, the referenced issue is automatically closed and thus moved to the Done column of the project board.
This PR should be assigned to the relevant project when it is submitted - in this case, April 2020.

Of the reviewers here, only @marksem  and I have permission to merge this PR to commit. Based on our discussion in the first half of the Thursday meeting, I believe @marksem, @uscholdm, and I are in agreement about what this issue encompasses and what should be merged to develop. I think @marksem should continue with the review and either merge, close or request changes, as appropriate.
At the next review meeting, I will conduct a demonstration of the process so that everyone is clear and comfortable with the process moving forward.
Thanks to all.


Per mille symbol (‰) cannot be set using range (not in unicode-math-table.tex)

Description
The per mille symbol ‰ (U+2030 PER MILLE SIGN, known in LaTeX as \permil in the wasysym package) is not part of unicode-math-table.tex and thus, because of #381, it is not possible to take it from another font using the range option. As it can reasonably be expected to be used in math mode (just like the percent sign %), I think it should be added to unicode-math-table.tex.
(More generally, #381 should be fixed, though.)
Check/indicate

[x] Relevant for XeTeX
[x] Relevant for LuaTeX
[x] Issue tracker has been searched for similar issues?
[x] Links to <tex.stackexchange.com> discussion if appropriate – none

Minimal example demonstrating the issue
\documentclass{article}
\usepackage{unicode-math}
\setmainfont{texgyrepagella-math.otf}
\setmathfont{latinmodern-math.otf}
\setmathfont{texgyrepagella-math.otf}[
	range={
		"2030, % ‰
	}
]
\begin{document}
	‰$‰$
\end{document}

Further details
The same applies to ‱ (U+2031 PER TEN THOUSAND SIGN), but since that one is so rarely used, I don’t think it’s nearly as important.

Thanks. I’d be happy adding \permil I’d say. (Maybe \mathpermil instead.)


fix wildcard cookie

SameSite=None requires the Secure attribute in latest browser versions.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite#:~:text=The warning appears because any,marked Secure will be rejected.&text=To fix this%2C you will,to your SameSite%3DNone cookies.&text=A Secure cookie is only,request over the HTTPS protocol

@exsver
Consider a case when protected site is HTTP only.
How setting 'Secure' = True in a cookie would impact this sites?


Create packages to install rustic

Is it possible to create packages that can be installed from apt and yum? This would surely make it easier for people to use and adopt Rustic, as well as update it.

I agree that this makes life easier for some people. However, the best benefit would come from packaging rustic directly into a distro, which is out of my hands.
That said, I appreciate to get a PR which includes this into the CI pipeline or adds packages by other means.
As rustic is only a single binary to install, I think it's feasible to live without it; at least I won't be able to put energy into it in the near future.

About updating: I think adding a self-update functionality would be a good feature. I added this as #119

I added the low-prio tag as #124 is now merged.

Given the fact that this package is dynamic-linked, creating native packages for various distro's would be problematic, since you'd need a separate package for each release of a distro.  However, this would seem to be a prime candidate for something like Snap, Flatpak, or AppImage distribution, or even run within a docker container.

You are right, Rust normally compiles to a dynamically-linked binary, basically linking to libc. I didn't get many problems so far with recent distributions to get the pre-compiled binary running. Also I thought that most distros would create their packages by compiling the source code themselves - this wouldn't be too much of a problem. For instance, debian has a ready-to-build template for Rust CLIs, IIRC.
But I would also appreciate having rustic in Snap, Flatpak, or whatever else. If you can propose a PR I'll most probably merge it!
Besides this, there is the option to compile Rust completely statically using musl-libc. This is done in the -musl binary. For machines where I got libc dependency problems, I used the -musl binary.

It's a difference of which libc they use/link to. Most Linux distributions use GNU libc (glibc) while I can think of two that offer musl libc.
Glibc requires dynamic linking -- that is, the rustic binary will use whichever version of glibc is provided by the Linux distribution. Musl libc, on the other hand, can be statically linked, or built directly into the restic binary.
The benefit of glibc is a smaller binary file, as the libc code is located elsewhere.  The downside is that,  in certain (rare) circumstances,  the system glibc is not compatible with the one restic was compiled with, and so the program breaks. With musl, you have larger binary files, because a copy of the libc is built into the program, but that also means you can run it on almost any system without worrying about any dynamic library dependencies.

Is there a preference for using one?

Just personal preference. GNU works for you, so you should be fine to continue using it.

I prefer using glibc, because of bugs and missing implementations in musl.  But regarding the comment above

The benefit of glibc is a smaller binary file, as the libc code is located elsewhere. The downside is that, in certain (rare) circumstances, the system glibc is not compatible with the one restic was compiled with, and so the program breaks. With musl, you have larger binary files, because a copy of the libc is built into the program, but that also means you can run it on almost any system without worrying about any dynamic library dependencies.

just a note, that a sizable population of linux distributions ship an older glibc which is incompatible:

older Debian and Ubuntu distributions,
RHEL <=9 (which as of writing is all of them) and derivatives (CentOS, Rocky, Alma, Oracle, ...),
possibly others.

I'd prefer if rustic would be built on a slightly older system so that at least glibc 2.34 is supported.

There is no bug affecting rustic in musl, that I know of.  DNS resolution is the very big problem, but that's not relevant afaict because rustic is using trust-resolver.  I'll test rustic in kubernetes, where these issues usually manifest and will add a PR documenting problems, if I find some.

I've been using the mazzolino/restic docker image with restic, and am now running a self-made image for rustic. Maybe it can be a starting point for others.
This is my Dockerfile:
FROM alpine:3

# Install required packages
RUN apk add --update --no-cache curl rclone tzdata

WORKDIR /root

# Rustic: download, unpack, move into PATH
RUN curl -L -o rustic.tar.gz 'https://github.com/rustic-rs/rustic/releases/download/v0.5.3/rustic-v0.5.3-x86_64-unknown-linux-musl.tar.gz' && \
  tar xzf ./rustic.tar.gz && \
  mv rustic /bin/ && \
  rm ./rustic.tar.gz

# Add crontab file
COPY crontab /etc/crontabs/root

# Run cron
ENTRYPOINT crond -f -d 8

The crontab would need to be at the root of the build context, and for me looks something like this:
0 3 * * * rustic backup
0 5 * * * rustic prune

You could of course throw a rustic check or even a rustic self-update in there.
This is how I spin up the container with docker-compose, bind-mounting the data directory and config files and providing some env variables:
  rustic:
    build: ${build_root}  # wherever you've placed the Dockerfile
    container_name: rustic
    hostname: ${HOSTNAME}
    environment:
      AWS_ACCESS_KEY_ID: ${RESTIC_AWS_KEY_ID}
      AWS_SECRET_ACCESS_KEY: ${RESTIC_AWS_KEY_SECRET}
      RCLONE_CONFIG: /root/rclone.conf
      RUSTIC_PASSWORD: ${RUSTIC_PASSWORD}
      TZ: ${TZ}
    volumes:
      - ${data_dir}:/data:ro
      - ${build_root}/rustic.toml:/root/rustic.toml:ro
      - ${build_root}/rclone.conf:/root/rclone.conf:ro
    restart: unless-stopped

@lephyrus Thanks a lot for sharing! Would you mind creating a PR which adds Dockerfiles etc. to the git repository?

Please also include homebrew (Mac OS). It is very easy to implement, and you can find details in the link i provided.

@z3cko Would you be able to implement the homebrew distribution? I can easily create a homebrew-rustic project for this, but I fear I'm missing time to actually working on it (and as non-Mac user it honestly isn't too much on my personal prio list...)

Please also include homebrew (Mac OS). It is very easy to implement, and you can find details in the link i provided.

I've made an unofficial formula for rustic. https://github.com/snorremd/homebrew-tap/pkgs/container/tap%2Frustic
Two caveats:

I don't provide notarized binaries as I don't have an Apple developer account to use for code signing
I don't provide pre-bottled binary for OSX Arm64 (M1, M2, etc) as GitHub Actions don't provide runners for this platform yet, and renting a Mac M1 to run continuously for 24 hours (per Apple license) from a cloud provider just to build a bottle seems a bit overkill

Use at your own discretion.


Make flaky tag work with Scalacheck suites

Previously, the Scalacheck suite transform was registered after the
.flaky transform so a flaky test would fail even if it was OK to
ignore flaky failures. Reordering the transforms fixes the issue.

Mm the CI failure looks legit

The test failure was a legitimate bug, which only got surfaced now because of the change. The problem was that the JS/Native test reporter reported that ignored tests also succeeded.


Implement pagination for search results

Developer

[ ] All new ENV is documented in README
[ ] All new ENV has been added to Heroku Pipeline, Staging and Prod
[ ] ANDI or Wave has been run in accordance to
our guide and
all issues introduced by these changes have been resolved or opened as new
issues (link to those issues in the Pull Request details above)
[ ] Stakeholder approval has been confirmed (or is not needed)

Code Reviewer

[ ] The commit message is clear and follows our guidelines
(not just this pull request message)
[ ] There are appropriate tests covering any new functionality
[ ] The documentation has been updated or is unnecessary
[ ] The changes have been verified
[ ] New dependencies are appropriate or there were no changes

Requires database migrations?
YES | NO
Includes new or updated dependencies?
YES | NO

Pull Request Test Coverage Report for Build 6ab99179e1e34530d4304f869221d573626ea867-PR-41

21 of 21 (100.0%)  changed or added relevant lines in 4 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 0a6e5fd0f5def867b481a3ca18270a33364ac8dc:
0.0%

Covered Lines:
147

Relevant Lines:
147

💛  - Coveralls


Updating Entity/Golden/ Summary metrics

Relevant information
Adding more metrics in entity
Modifying golden/summary metrics
Entity dashboard with test data - https://onenr.io/08jqnYe9OQl
More details - https://newrelic.slack.com/archives/C0363ANU1UG/p1664488799945619?thread_ts=1663942099.254239&cid=C0363ANU1UG
Checklist

[x] I've read the guidelines and understand the acceptance criteria.
[x] The value of the attribute marked as identifier will be unique and valid.
[x] I've confirmed that my entity type wasn't already defined. If it is I'm providing an
explanation above.

Closing this PR, will create another one


HDDS-7600. [Snapshot] Mark all new proto message fields as optional

What changes were proposed in this pull request?
Mark all new proto message fields as optional before snapshot feature branch is merged to master branch.
Context: https://github.com/apache/ozone/pull/3985/files#r1041505724
What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-7600
How was this patch tested?

Existing tests should pass.

@smengcl, why do we need to mark the field as optional? If the message itself is optional, then the fields are never used.
If someone wants to use that message, we should have the mandatory fields as required.

@smengcl, why do we need to mark the field as optional? If the message itself is optional, then the fields are never used. If someone wants to use that message, we should have the mandatory fields as required.

Hi Nanda, as I mentioned previously in this PR comment:
https://github.com/apache/ozone/pull/3824#discussion_r1011376445
required field is an outdated concept in proto2, where protobuf 3 has completely ditched this concept, so every single field in proto3 is implicitly optional, reason being that user can always check the whether the field is set with hasABCField().
A significant drawback of required is that it makes it significantly harder to deprecate and remove a field in the future, which IIRC was also blocking Hadoop from moving to pure proto3. Although we are still using proto2 syntax, I would suggest strongly moving away from required and embrace optional.

Thanks @nandakumar131 and @prashantpogde for the reviews.