Fix Nightly Tests

This ticket is to track and hopefully fix the Nightly CI tests.

MacOS Latest does not offer support for Java 8.  Minimum available is Java 11.

  Trying to resolve the latest version from remote
  Error: Could not find satisfied version for SemVer '8'.
  Available versions: 22.0.1+8, 22.0.0+36, 21.0.3+9.0.LTS, 21.0.2+13.0.LTS, 21.0.1+12.0.LTS, 21.0.0+35.0.LTS, 20.0.2+9, 20.0.1+9, 20.0.0+36, 19.0.2+7, 19.0.1+10, 19.0.0+36, 18.0.2+101, 18.0.2+9, 18.0.1+10, 18.0.0+36, 17.0.11+9, 17.0.10+7, 17.0.9+9, 17.0.8+101, 17.0.8+7, 17.0.7+7, 17.0.6+10, 17.0.5+8, 17.0.4+101, 17.0.4+8, 17.0.3+7, 17.0.2+8, 17.0.1+12, 17.0.0+35, 11.0.23+9, 11.0.22+7.1, 11.0.22+7, 11.0.21+9, 11.0.20+101, 11.0.20+8, 11.0.19+7, 11.0.18+10, 11.0.17+8, 11.0.16+101, 11.0.16+8, 11.0.15+10

JSON Infosets are not being created under certain conditions.  This can happen on Windows and MacOS.

detected java homes: [{"path":"/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/11.0.22-7/x64/Contents/Home","version":"11.0.22","security":0,"isJDK":true,"is64Bit":true,"executables":{"java":"/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/11.0.22-7/x64/Contents/Home/bin/java","javac":"/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/11.0.22-7/x64/Contents/Home/bin/javac","javap":"/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/11.0.22-7/x64/Contents/Home/bin/javap"}},{"path":"/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/17.0.11-9/x64/Contents/Home","version":"17.0.11","security":0,"isJDK":true,"is64Bit":true,"executables":{"java":"/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/17.0.11-9/x64/Contents/Home/bin/java","javac":"/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/17.0.11-9/x64/Contents/Home/bin/javac","javap":"/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/17.0.11-9/x64/Contents/Home/bin/javap"}},{"path":"/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/21.0.2-13.0/x64/Contents/Home","version":"21.0.2","security":0,"isJDK":true,"is64Bit":true,"executables":{"java":"/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/21.0.2-13.0/x64/Contents/Home/bin/java","javac":"/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/21.0.2-13.0/x64/Contents/Home/bin/javac","javap":"/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/21.0.2-13.0/x64/Contents/Home/bin/javap"}},{"path":"/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/8.0.402-6/x64/Contents/Home","version":"1.8.0","security":402,"isJDK":true,"is64Bit":true,"executables":{"java":"/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/8.0.402-6/x64/Contents/Home/bin/java","javac":"/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/8.0.402-6/x64/Contents/Home/bin/javac","javap":"/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/8.0.402-6/x64/Contents/Home/bin/javap"}},{"path":"/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/8.0.402-6/x64/Contents/Home/jre","version":"1.8.0","security":402,"isJDK":false,"is64Bit":true,"executables":{"java":"/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/8.0.402-6/x64/Contents/Home/jre/bin/java"}}]
choosing java home at undefined, version undefined, is at least JDK 17: false
detected java homes: [{"path":"/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/11.0.22-7/x64/Contents/Home","version":"11.0.22","security":0,"isJDK":true,"is64Bit":true,"executables":{"java":"/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/11.0.22-7/x64/Contents/Home/bin/java","javac":"/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/11.0.22-7/x64/Contents/Home/bin/javac","javap":"/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/11.0.22-7/x64/Contents/Home/bin/javap"}},{"path":"/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/17.0.11-9/x64/Contents/Home","version":"17.0.11","security":0,"isJDK":true,"is64Bit":true,"executables":{"java":"/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/17.0.11-9/x64/Contents/Home/bin/java","javac":"/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/17.0.11-9/x64/Contents/Home/bin/javac","javap":"/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/17.0.11-9/x64/Contents/Home/bin/javap"}},{"path":"/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/21.0.2-13.0/x64/Contents/Home","version":"21.0.2","security":0,"isJDK":true,"is64Bit":true,"executables":{"java":"/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/21.0.2-13.0/x64/Contents/Home/bin/java","javac":"/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/21.0.2-13.0/x64/Contents/Home/bin/javac","javap":"/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/21.0.2-13.0/x64/Contents/Home/bin/javap"}},{"path":"/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/8.0.402-6/x64/Contents/Home","version":"1.8.0","security":402,"isJDK":true,"is64Bit":true,"executables":{"java":"/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/8.0.402-6/x64/Contents/Home/bin/java","javac":"/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/8.0.402-6/x64/Contents/Home/bin/javac","javap":"/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/8.0.402-6/x64/Contents/Home/bin/javap"}},{"path":"/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/8.0.402-6/x64/Contents/Home/jre","version":"1.8.0","security":402,"isJDK":false,"is64Bit":true,"executables":{"java":"/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/8.0.402-6/x64/Contents/Home/jre/bin/java"}}]
choosing java home at undefined, version undefined, is at least JDK 17: false
[9767:0516/002307.262190:ERROR:gl_utils.cc(412)] [.WebGL-0x11404b06200]GL Driver Message (OpenGL, Performance, GL_CLOSE_PATH_NV, High): GPU stall due to ReadPixels
2024-05-16 00:23:18.221 Code Helper (Renderer)[9779:41228] CoreText note: Client requested name ".NewYork-Regular", it will get Times-Roman rather than the intended font. All system UI font access should be through proper APIs such as CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:].
    ✔ should output xml infoset (11879ms)
    1) should output json infoset
  Data Editor Test Suite
    ✔ data edit command exists (328ms)
    Editor Service
rejected promise not handled within 1 second: Error: ENOENT: no such file or directory, open '/Users/runner/work/daffodil-vscode/daffodil-vscode/testinfoset.json'
stack trace: Error: ENOENT: no such file or directory, open '/Users/runner/work/daffodil-vscode/daffodil-vscode/testinfoset.json'

detected java homes: [{"path":"C:\\hostedtoolcache\\windows\\Java_Temurin-Hotspot_jdk\\17.0.11-9\\x64","version":"17.0.11","security":0,"isJDK":true,"is64Bit":true,"executables":{"java":"C:\\hostedtoolcache\\windows\\Java_Temurin-Hotspot_jdk\\17.0.11-9\\x64\\bin\\java.exe","javac":"C:\\hostedtoolcache\\windows\\Java_Temurin-Hotspot_jdk\\17.0.11-9\\x64\\bin\\javac.exe","javap":"C:\\hostedtoolcache\\windows\\Java_Temurin-Hotspot_jdk\\17.0.11-9\\x64\\bin\\javap.exe"}}]
choosing java home at C:\hostedtoolcache\windows\Java_Temurin-Hotspot_jdk\17.0.11-9\x64, version 17.0.11, is at least JDK 17: true
detected java homes: [{"path":"C:\\hostedtoolcache\\windows\\Java_Temurin-Hotspot_jdk\\17.0.11-9\\x64","version":"17.0.11","security":0,"isJDK":true,"is64Bit":true,"executables":{"java":"C:\\hostedtoolcache\\windows\\Java_Temurin-Hotspot_jdk\\17.0.11-9\\x64\\bin\\java.exe","javac":"C:\\hostedtoolcache\\windows\\Java_Temurin-Hotspot_jdk\\17.0.11-9\\x64\\bin\\javac.exe","javap":"C:\\hostedtoolcache\\windows\\Java_Temurin-Hotspot_jdk\\17.0.11-9\\x64\\bin\\javap.exe"}}]
choosing java home at C:\hostedtoolcache\windows\Java_Temurin-Hotspot_jdk\17.0.11-9\x64, version 17.0.11, is at least JDK 17: true
    ✔ should output xml infoset (2129ms)
    1) should output json infoset
  Data Editor Test Suite
    ✔ data edit command exists
    Editor Service
rejected promise not handled within 1 second: Error: ENOENT: no such file or directory, open 'd:\a\daffodil-vscode\daffodil-vscode\testinfoset.json'
stack trace: Error: ENOENT: no such file or directory, open 'd:\a\daffodil-vscode\daffodil-vscode\testinfoset.json'

SBT not being found on MacOS Latest.

$ sbt debugger/Universal/packageBin
/bin/sh: sbt: command not found
error Command failed with exit code 127.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
error Command failed with exit code 127.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
error Command failed with exit code 127.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
Error: Process completed with exit code 127.

Misc Network Connectivity issues.

yarn install v1.22.22
[1/5] Validating package.json...
warning<EMAIL_ADDRESS>The engine "vscode" appears to be invalid.
[2/5] Resolving packages...
[3/5] Fetching packages...
info There appears to be trouble with your network connection. Retrying...
info There appears to be trouble with your network connection. Retrying...
info There appears to be trouble with your network connection. Retrying...
info There appears to be trouble with your network connection. Retrying...
info There appears to be trouble with your network connection. Retrying...
error Error: https://registry.npmjs.org/date-fns/-/date-fns-2.30.0.tgz: ESOCKETTIMEDOUT
    at ClientRequest.<anonymous> (C:\npm\prefix\node_modules\yarn\lib\cli.js:142037:19)
    at Object.onceWrapper (node:events:627:28)
    at ClientRequest.emit (node:events:513:28)
    at TLSSocket.emitRequestTimeout (node:_http_client:839:9)
    at Object.onceWrapper (node:events:627:28)
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
    at TLSSocket.emit (node:events:525:35)
    at TLSSocket.Socket._onTimeout (node:net:550:8)
    at listOnTimeout (node:internal/timers:559:17)
    at processTimers (node:internal/timers:502:7)
Error: Process completed with exit code 1.

Numbers 1 and 3 should be easy. In the workflow we can setup the exclusion of Java version 8 and also to install SBT when running on macos-latest. Number 2 I would need to look more into to give an update on. But number 4 we can't really do anything about that as that is a runner issue and not an issue with our repository.

Parts 1 & 3 were done for 1.4.0. 2 & 4 can be looked at more in 1.4.1. A new issue I created https://github.com/apache/daffodil-vscode/issues/1117 also kind of goes hand in hand with this issue.


feat: support offloadThreshold policy on Namespace

(If this PR fixes a github issue, please add Fixes #<xyz>.)
Fixes #235
(or if this PR is one task of a github issue, please add Master Issue: #<xyz> to link to the master issue.)
Master Issue: #
Motivation
Explain here the context, and why you're making that change. What is the problem you're trying to solve.
Modifications
Describe the modifications you've done.
Verifying this change

[ ] Make sure that the change passes the CI checks.

(Please pick either of the following options)
This change is a trivial rework / code cleanup without any test coverage.
(or)
This change is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:
(example:)

Added integration tests for end-to-end deployment with large payloads (10MB)
Extended integration test for recovery after broker failure

Documentation
Check the box below.
Need to update docs?

[x] doc-required
(If you need help on updating docs, create a doc issue)

[ ] no-need-doc
(Please explain why)

[ ] doc
(If this PR contains doc changes)

replaced by https://github.com/streamnative/pulsar-resources-operator/pull/250


Not all simultaneous damage hits on the Player get processed correctly.

When the player gets hit by multiple damage sources during one "tick", not all of them get processed.
Convoluted example (I skip a turn at the start):

Running native, using the chapter-18 code from the tutorial (to make sure it wasn't something I introduced) :

Comparing multi damage source versus single damage source:

I think the Player Entity gets inserted into SuffersDamage once for the fireball AoE, and once right after, for the melee combat hit. Maybe specs overwrites it before the damage system can process it? https://docs.rs/specs/0.16.1/specs/struct.World.html?search=#method.insert
Going to debug it a bit more.

Specs does indeed overwrite it, not wanting more than one of the same component type. It's a pitfall of the ECS I hadn't run into before. After chapter 63, damage moves into the "effects" system which doesn't have this problem: damage is moved into a queue. I'll see if I can back-port a simpler setup up to that point (the easiest would be to have "suffer damage" be a list, with adding damage checking to make the list or append to it).

Those two commits should fix it for all chapters prior to the effects system.

Excited to test this when I get home tonight. Will report back

Nice clean solution, confirmed fixed :+1: ! Works like a charm, and is definitely worth the little bit of extra complexity.


Go code linting

Would it make sense to lint go code via https://github.com/golangci/golangci-lint or similar tools? Anyone got experience using those?

I think we have done that.

Seems so, sorry I missed it.
https://github.com/go-gitea/gitea/blob/5a187f4bcc9cbe5f44da4b623046289c97ede250/.golangci.yml


AV-73526 | Handle rate limit error

Jira

AV-73526

Description
Please include a summary of the fix/feature/change, including any relevant motivation and context.

Type of Change

[x] Bug fix (non-breaking change which fixes an issue). Please, add the "bug" label to the PR.
[ ] New feature (non-breaking change which adds functionality). Please, add the "enhancement" label to the PR.
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected). Please, add the "breaking change" label to the PR.
[ ] This change requires a documentation update
[ ] Documentation fix/enhancement

Manual Testing Approach
How was this change tested and do you have evidence? (REQUIRED: Select at least 1)

[x] Manually tested
[ ] Unit tested
[ ] Acceptance tested
[ ] Unable to test / will not test (Please provide comments in section below)

Testing

Testing
 Decreased the rate limit in local-dev manually to 3 and attempted creating 7 API Key resources
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
 Resources: 7 added, 0 changed, 0 destroyed.
=========================================================
Acceptance testing
ajayajith@Ajays-MBP-2 terraform-provider-couchbase-capella % make testacc
TF_ACC=1 go test -timeout=300m -v ./... -run TestAccOrganizationDataSource -run TestAccProjectResource -run TestAccCreateProjectWithReqFields -run TestAccCreateProjectOptFields -run TestAccValidProjectUpdate -run TestAccInvalidProjectResource -run TestAccDeleteProjectBeforeDestroy -run TestAccClusterResourceAzure -run TestAccClusterResourceGCP -run TestAccClusterResourceWithOnlyReqFieldAWS
?       github.com/couchbasecloud/terraform-provider-couchbase-capella  [no test files]
?       github.com/couchbasecloud/terraform-provider-couchbase-capella/internal/api/appservice  [no test files]
?       github.com/couchbasecloud/terraform-provider-couchbase-capella/internal/api/backup      [no test files]
?       github.com/couchbasecloud/terraform-provider-couchbase-capella/internal/api/backup_schedule     [no test files]
?       github.com/couchbasecloud/terraform-provider-couchbase-capella/internal/api/bucket      [no test files]
?       github.com/couchbasecloud/terraform-provider-couchbase-capella/internal/api/cluster     [no test files]
?       github.com/couchbasecloud/terraform-provider-couchbase-capella/internal/api/organization        [no test files]
testing: warning: no tests to run
PASS
ok      github.com/couchbasecloud/terraform-provider-couchbase-capella/internal/api     (cached) [no tests to run]
?       github.com/couchbasecloud/terraform-provider-couchbase-capella/internal/errors  [no test files]
?       github.com/couchbasecloud/terraform-provider-couchbase-capella/internal/provider        [no test files]
testing: warning: no tests to run
PASS
ok      github.com/couchbasecloud/terraform-provider-couchbase-capella/internal/datasources     (cached) [no tests to run]
testing: warning: no tests to run
PASS
ok      github.com/couchbasecloud/terraform-provider-couchbase-capella/internal/resources       (cached) [no tests to run]
?       github.com/couchbasecloud/terraform-provider-couchbase-capella/internal/testing [no test files]
?       github.com/couchbasecloud/terraform-provider-couchbase-capella/version  [no test files]
=== RUN   TestAccClusterResourceWithOnlyReqFieldAWS
=== PAUSE TestAccClusterResourceWithOnlyReqFieldAWS
=== CONT  TestAccClusterResourceWithOnlyReqFieldAWS
raw state map[%:16 audit.%:5 audit.created_at:2024-03-11 10:45:46.529028332 +0000 UTC audit.created_by:7AsCv7QPGJ6pGQEFIau2P8qlN9OlQ6gz audit.modified_at:2024-03-11 10:48:00.185446764 +0000 UTC audit.modified_by:7AsCv7QPGJ6pGQEFIau2P8qlN9OlQ6gz audit.version:5 availability.%:1 availability.type:multi cloud_provider.%:3 cloud_provider.cidr:<IP_ADDRESS>/23 cloud_provider.region:us-east-1 cloud_provider.type:aws configuration_type:multiNode couchbase_server.%:1 couchbase_server.version:7.2 current_state:healthy description: etag:Version: 5 id:abb708ed-d5cb-479c-9194-296ff5934eb4 name:acc_cluster_eugrmdysjc organization_id:7a99d00c-f55b-4b39-bc72-1b4cc68ba894 project_id:e14f20e3-42fb-4cb1-9928-2ac7826ffd48 service_groups.#:1 service_groups.0.%:3 service_groups.0.node.%:2 service_groups.0.node.compute.%:2 service_groups.0.node.compute.cpu:4 service_groups.0.node.compute.ram:16 service_groups.0.node.disk.%:4 service_groups.0.node.disk.iops:3000 service_groups.0.node.disk.storage:50 service_groups.0.node.disk.type:io2 service_groups.0.num_of_nodes:3 service_groups.0.services.#:3 service_groups.0.services.0:data service_groups.0.services.1:index service_groups.0.services.2:query support.%:2 support.plan:developer pro support.timezone:PT]raw state map[%:16 audit.%:5 audit.created_at:2024-03-11 10:45:46.529028332 +0000 UTC audit.created_by:7AsCv7QPGJ6pGQEFIau2P8qlN9OlQ6gz audit.modified_at:2024-03-11 10:48:00.185446764 +0000 UTC audit.modified_by:7AsCv7QPGJ6pGQEFIau2P8qlN9OlQ6gz audit.version:5 availability.%:1 availability.type:multi cloud_provider.%:3 cloud_provider.cidr:<IP_ADDRESS>/23 cloud_provider.region:us-east-1 cloud_provider.type:aws configuration_type:multiNode couchbase_server.%:1 couchbase_server.version:7.2 current_state:healthy description: etag:Version: 5 id:abb708ed-d5cb-479c-9194-296ff5934eb4 name:acc_cluster_eugrmdysjc organization_id:7a99d00c-f55b-4b39-bc72-1b4cc68ba894 project_id:e14f20e3-42fb-4cb1-9928-2ac7826ffd48 service_groups.#:1 service_groups.0.%:3 service_groups.0.node.%:2 service_groups.0.node.compute.%:2 service_groups.0.node.compute.cpu:4 service_groups.0.node.compute.ram:16 service_groups.0.node.disk.%:4 service_groups.0.node.disk.iops:3000 service_groups.0.node.disk.storage:50 service_groups.0.node.disk.type:io2 service_groups.0.num_of_nodes:3 service_groups.0.services.#:3 service_groups.0.services.0:data service_groups.0.services.1:index service_groups.0.services.2:query support.%:2 support.plan:developer pro support.timezone:PT]raw state map[%:16 audit.%:5 audit.created_at:2024-03-11 10:45:46.529028332 +0000 UTC audit.created_by:7AsCv7QPGJ6pGQEFIau2P8qlN9OlQ6gz audit.modified_at:2024-03-11 10:54:44.183857839 +0000 UTC audit.modified_by:7AsCv7QPGJ6pGQEFIau2P8qlN9OlQ6gz audit.version:11 availability.%:1 availability.type:multi cloud_provider.%:3 cloud_provider.cidr:<IP_ADDRESS>/23 cloud_provider.region:us-east-1 cloud_provider.type:aws configuration_type:multiNode couchbase_server.%:1 couchbase_server.version:7.2 current_state:healthy description:Cluster Updated. etag:Version: 11 id:abb708ed-d5cb-479c-9194-296ff5934eb4 if_match:5 name:Terraform Acceptance Test Cluster Update organization_id:7a99d00c-f55b-4b39-bc72-1b4cc68ba894 project_id:e14f20e3-42fb-4cb1-9928-2ac7826ffd48 service_groups.#:2 service_groups.0.%:3 service_groups.0.node.%:2 service_groups.0.node.compute.%:2 service_groups.0.node.compute.cpu:4 service_groups.0.node.compute.ram:16 service_groups.0.node.disk.%:4 service_groups.0.node.disk.iops:3001 service_groups.0.node.disk.storage:51 service_groups.0.node.disk.type:gp3 service_groups.0.num_of_nodes:3 service_groups.0.services.#:1 service_groups.0.services.0:data service_groups.1.%:3 service_groups.1.node.%:2 service_groups.1.node.compute.%:2 service_groups.1.node.compute.cpu:8 service_groups.1.node.compute.ram:32 service_groups.1.node.disk.%:4 service_groups.1.node.disk.iops:3001 service_groups.1.node.disk.storage:51 service_groups.1.node.disk.type:gp3 service_groups.1.num_of_nodes:2 service_groups.1.services.#:2 service_groups.1.services.0:index service_groups.1.services.1:query support.%:2 support.plan:enterprise support.timezone:IST]raw state map[%:16 audit.%:5 audit.created_at:2024-03-11 10:45:46.529028332 +0000 UTC audit.created_by:7AsCv7QPGJ6pGQEFIau2P8qlN9OlQ6gz audit.modified_at:2024-03-11 10:54:57.850897684 +0000 UTC audit.modified_by:7AsCv7QPGJ6pGQEFIau2P8qlN9OlQ6gz audit.version:16 availability.%:1 availability.type:multi cloud_provider.%:3 cloud_provider.cidr:<IP_ADDRESS>/23 cloud_provider.region:us-east-1 cloud_provider.type:aws configuration_type:multiNode couchbase_server.%:1 couchbase_server.version:7.2 current_state:healthy description:Cluster Updated. etag:Version: 16 id:abb708ed-d5cb-479c-9194-296ff5934eb4 name:Terraform Acceptance Test Cluster Update 2 organization_id:7a99d00c-f55b-4b39-bc72-1b4cc68ba894 project_id:e14f20e3-42fb-4cb1-9928-2ac7826ffd48 service_groups.#:2 service_groups.0.%:3 service_groups.0.node.%:2 service_groups.0.node.compute.%:2 service_groups.0.node.compute.cpu:4 service_groups.0.node.compute.ram:16 service_groups.0.node.disk.%:4 service_groups.0.node.disk.iops:3001 service_groups.0.node.disk.storage:51 service_groups.0.node.disk.type:gp3 service_groups.0.num_of_nodes:3 service_groups.0.services.#:1 service_groups.0.services.0:data service_groups.1.%:3 service_groups.1.node.%:2 service_groups.1.node.compute.%:2 service_groups.1.node.compute.cpu:8 service_groups.1.node.compute.ram:32 service_groups.1.node.disk.%:4 service_groups.1.node.disk.iops:3001 service_groups.1.node.disk.storage:51 service_groups.1.node.disk.type:gp3 service_groups.1.num_of_nodes:2 service_groups.1.services.#:2 service_groups.1.services.0:index service_groups.1.services.1:query support.%:2 support.plan:enterprise support.timezone:IST]--- PASS: TestAccClusterResourceWithOnlyReqFieldAWS (904.59s)
PASS
ok      github.com/couchbasecloud/terraform-provider-couchbase-capella/internal/resources/acceptance_tests      905.042s
testing: warning: no tests to run
PASS
ok      github.com/couchbasecloud/terraform-provider-couchbase-capella/internal/resources/acceptance_tests/security_acceptance_tests    (cached) [no tests to run]
testing: warning: no tests to run
PASS
ok      github.com/couchbasecloud/terraform-provider-couchbase-capella/internal/schema  (cached) [no tests to run]

Required Checklist:

[x] I have checked that this change does not generate any credentials and that they are NOT accidentally logged anywhere.
[x] I have added tests that prove my fix is effective or that my feature works per HashiCorp requirements
[x] I have added any necessary documentation (if required)
[x] I have run make fmt and formatted my code

Further comments

@SaicharanCB Tagging you here, so you have visibility.


Cannot get example tests or own tests to run

Describe the bug
I've tried out WDI5 a few months ago and written a few very basics tests for UI5 and it worked fine. Now I wanted to revisit it for a new project and I can not get my very basic tests or the JS example tests in this repo to work. Chrome opens only for a split second then closes with the error in the output below.
To Reproduce
Steps to reproduce the behavior:
Checked out this repo, npm install
npm run _startApp:js
then
npm run test:webserver -w examples/ui5-js-app
Expected behavior
The tests to run
Logs/Console Output
Output from tests
https://pastebin.com/Mycg2ZCF
Runtime Env (please complete the following information):

wdi5/wdio-ui5-service-version: [e.g. 0.8.1]
UI5 version: [1.109.0]
wdio-version (output of wdio --version): 7.26.0
node-version (output of node --version): v16.18.1
npm-version: 9.1.3
OS: Windows 11
Browser + Version: Chrome 108.0.5359.95

Additional context
I'm unsure if this is some kind of issue with my chrome install/version but I'm unsure how to debug this.

Thank you both, adjusting the chromedriver version to 108 did indeed fix the issue I was having and the example tests are now running without issues.
I also did the same for the project following the installation guide here: https://ui5-community.github.io/wdi5/#/installation (fresh UI5 project generated with Yo easyui5) using npm init wdi5@latest,  however even a simple test with just a console log throws the following error:

ERROR @wdio/utils:initialiseServices: Error: Couldn't initialise "wdio-ui5-service".
Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './build/multiremote' is not defined by "exports" in C:\Playground\E2ETesting\test-install2\node_modules\webdriverio\package.json
at new NodeError (node:internal/errors:387:5)
at throwExportsNotFound (node:internal/modules/esm/resolve:365:9)
at packageExportsResolve (node:internal/modules/esm/resolve:649:3)
at resolveExports (node:internal/modules/cjs/loader:522:36)
at Function.Module._findPath (node:internal/modules/cjs/loader:562:31)
at Function.Module._resolveFilename (node:internal/modules/cjs/loader:971:27)
at Function.Module._load (node:internal/modules/cjs/loader:833:27)
at Module.require (node:internal/modules/cjs/loader:1057:19)
at require (node:internal/modules/cjs/helpers:103:18)
at Object. (C:\Playground\E2ETesting\test-install2\node_modules\wdio-ui5-service\dist\service.js:50:21)
at safeRequire (C:\Playground\E2ETesting\test-install2\node_modules@wdio\utils\build\utils.js:192:15)
at initialisePlugin (C:\Playground\E2ETesting\test-install2\node_modules@wdio\utils\build\initialisePlugin.js:37:44)
at initialiseServices (C:\Playground\E2ETesting\test-install2\node_modules@wdio\utils\build\initialiseServices.js:59:56)
at initialiseLauncherService (C:\Playground\E2ETesting\test-install2\node_modules@wdio\utils\build\initialiseServices.js:86:26)
at Launcher.run (C:\Playground\E2ETesting\test-install2\node_modules@wdio\cli\build\launcher.js:73:103)
at launch (C:\Playground\E2ETesting\test-install2\node_modules@wdio\cli\build\commands\run.js:126:21)
at Object.handler (C:\Playground\E2ETesting\test-install2\node_modules@wdio\cli\build\commands\run.js:165:16)
at C:\Playground\E2ETesting\test-install2\node_modules\yargs\build\index.cjs:1:8891
at j (C:\Playground\E2ETesting\test-install2\node_modules\yargs\build\index.cjs:1:4956)
at M.handleValidationAndGetResult (C:\Playground\E2ETesting\test-install2\node_modules\yargs\build\index.cjs:1:8860)

Dependencies as installed by the wdi5 init:

"devDependencies": {
"@sapui5/ts-types-esm": "1.109.0",
"@ui5/cli": "latest",
"@wdio/cli": "^7",
"@wdio/local-runner": "^7",
"@wdio/mocha-framework": "^7",
"@wdio/spec-reporter": "^7",
"chromedriver": "^108",
"eslint": "^8.27.0",
"ui5-middleware-livereload": "^0.7.0",
"wdio-chromedriver-service": "latest",
"wdio-ui5-service": "latest"
},

That's because wdi5 currently does not support WebdriverIO V8. The npm init wdi5 installs a wrong version of the wdio-chromedriver-service. Try it with ^7.3.2 and it should work.
We are already working on a solution that npm init wdi5 works again ootb.

That's because wdi5 currently does not support WebdriverIO V8. The npm init wdi5 installs a wrong version of the wdio-chromedriver-service. Try it with ^7.3.2 and it should work.
We are already working on a solution that npm init wdi5 works again ootb.

Thank you for the quick help that did indeed fix it! Seems like it was just unlucky timing to follow the documentation right now.


/team page: Show contributions for major repos.

Have you had a chance to implement the retry loop to deal with the fact that it 202s the first time you run it pretty consistently?

Yeah it will wait 2 seconds before going back to the failed requests
https://github.com/zulip/zulip/pull/7470/files#diff-8bff50e8898986eea624743cfdd13218R107

Cool, this looks great!  I noticed two bugs:

The bottom of the "All" tab is inaccurate, in that we only fetch the top 100 server contributors, and then we add in smaller contributors from other projects (some of whom have just 1 commit, which feels unfair to the 101st server contributor with 10 or whatever).  I think we should either (1) only show the top 100 totals, or perhaps better, (2) only show the people who have more total commits than the number that was #100 in the server repo.
The first N "python-zulip-api" repo commits are also present in the server repo (since they are from before the repo split).  I'm not sure I see a good way to fix this (the best idea I have is to query GitHub for commits to the python-zulip-api repo from dates before the repo split, which I think is possible, and then subtract those "duplicate commits" from the totals in the "all repos" table to avoid them being double-counted; I don't think there's an easy way to adjust the other tables...), but perhaps we should just not worry about it since that model is kinda confusing too.

It also looks like you have a few test failures to fix.  The backend ones look fairly simple; the production ones look like maybe you used some syntax that Webpack isn't expecting in our portico code, and so minification is failing?

Oops for (x of y) is ES6 syntax. I will address the two bugs you mentioned tomorrow.

This should work now. I think we should just ignore the python-zulip-api/server commits duplication for now, we could pick that up later if necessary. Or maybe a GCI project?

This is awesome!  Merged, thanks @tommyip!

For the commit duplication thing ... I think what I'd do is just commit the static list of {github username -> count} commits for the commits that are duplicated, check that in as a fixture file, and just subtract those numbers from the server project.  So it might not be that hard.  Open an issue with a good writeup?


Timing issue at start with AbstractEventSource

This is a minor issue.  Event sources can start receiving events before the controller init is called.  This requires a null check of the eventHandler or you'll get npe exceptions for a while.  Perhaps AbstractEventSource could implement EventHandler and take care of the relevant null checks.
Related to this should the AbstractEventSource.eventHandler field be volatile?

Is this still going on in the latest version?

I haven't checked.  The event source is an application scoped bean.  Events can start flowing as a side effect of a quarkus onStart hook.  Should the operator init be guaranteed to happen before that?  And/or do you want this as a quarkus specific issue?

I think now you should override EventSource.start and EventSource.close for a proper lifecycle

/assign @jmrodri


[Feature Request]: Allow to disable public IP assignment on nodes

Description
I believe it is not necessary for nodes to have public IP if they are placed under load-balancer, or communicating using private network. Terraform provider for hetzner-cloud supports this: https://registry.terraform.io/providers/hetznercloud/hcloud/latest/docs/resources/server#basic-server-creation

@beslovas It is still necessary for changes and setup. But you can completely isolate the node via the firewall rules, see kube.tf.example, it's basically equivalent of having no public IPs.
However, in future versions of the project definitly ship this if we can.


Update Readme

Change the markup so headings display properly on Github

Oops, this change is same as for #74, so I am closing this pull request. Guess I should have checked first


Add help to subcommands, usage cleanup

Add help to all subcommands.  This causes argparse to print a brief
description next to each subcommand in the top-level usage output.  Add
descriptions to GCE commands.  Capitalize config command descriptions,
so that they are consistent with the convention that we've been
following to date.
I couldn't figure out a way to sort the list of subcommands with
descriptions.
$ ./brkt -h
usage: brkt [-h] [-v] [--version] [--no-check-version]
{config,diag,encrypt-ami,encrypt-gce-image,launch-gce-image
,make-key,make-token,make-user-data,share-logs,update-encrypted-ami
,update-gce-image}
...
Command-line interface to the Bracket Computing service.
positional arguments:
{config,diag,encrypt-ami,encrypt-gce-image,launch-gce-image,make-key
,make-token,make-user-data,share-logs,update-encrypted-ami,update-gce-
image}
diag                Diagnose an encrypted instance
encrypt-ami         Encrypt an AWS image
share-logs          Share logs
update-encrypted-ami
Update an encrypted AWS image
config              Display or update brkt-cli options
encrypt-gce-image   Encrypt a GCE image
update-gce-image    Update an encrypted GCE image
launch-gce-image    Launch a GCE image
get-public-key      Print the public part of a private key
make-key            Make a PEM key
make-user-data      Make user data for passing to Metavisor
optional arguments:
--no-check-version    Don't check whether this version of brkt-cli is
supported (default: True)
--version             show program's version number and exit
-h, --help            show this help message and exit
-v, --verbose         Print status information to the console
(default:
False)

lgtm. However is the SortingHelpFormatter adding any value here?

Yes, it sorts the options in the top level brkt command.


Give Felyx the focus for keyboard after a drag&drop

When we drag a file on Felyx, is it possible to give Felyx the focus for keyboard instead of having to reclick on it to put it as active program.
Or maybe this is a Windows parameter somewhere as it does not seem to be the main Windows mode.

I'll look into it. It looks like a bug


cucumber failures with puppet 3.7.5

The features/encrypts.feature acceptance test is failing on the current master with puppet 3.7.5.
[master] ~/github/hiera-eyaml $ git show-ref HEAD
54b62eff28d72cb8670df226e2a16b7562aa16fc refs/remotes/origin/HEAD
[master] ~/github/hiera-eyaml $ ruby --version
ruby 2.1.5p273 (2014-11-13 revision 48405) [x86_64-linux]
[master] ~/github/hiera-eyaml $ git diff
diff --git a/Gemfile b/Gemfile
index 90251e3..2c3886f 100644
--- a/Gemfile
+++ b/Gemfile
@@ -8,7 +8,7 @@ group :development do
   gem "cucumber", '~> 1.1'
   gem "rspec-expectations", '~> 3.1.0'
   gem "hiera-eyaml-plaintext"
-  gem "puppet"
+  gem "puppet", '~> 3.7'
 end

 group :test do
[master] ~/github/hiera-eyaml $ bundle show puppet
/home/jhoblitt/github/hiera-eyaml/.bundle/gems/puppet-3.7.5
[master] ~/github/hiera-eyaml $ bundle show hiera
/home/jhoblitt/github/hiera-eyaml/.bundle/gems/hiera-1.3.4
[master] ~/github/hiera-eyaml $ bundle show cucumber
/home/jhoblitt/github/hiera-eyaml/.bundle/gems/cucumber-1.3.19
[master] ~/github/hiera-eyaml $ find . -name supply_password.sh
./tmp/aruba/supply_password.sh
./features/sandbox/supply_password.sh

  Scenario: encrypt a password                                        # features/encrypts.feature:23
    When I run `./supply_password.sh eyaml encrypt -o string -p`      # .bundle/gems/aruba-0.6.2/lib/aruba/cucumber.rb:93
      No such file or directory - ./supply_password.sh (Aruba::LaunchError)
      features/encrypts.feature:24:in `When I run `./supply_password.sh eyaml encrypt -o string -p`'
    Then the file "password.output" should match /ENC\[PKCS7,(.*?)\]/ # .bundle/gems/aruba-0.6.2/lib/aruba/cucumber.rb:351

If it helps, I had this particular issue when I ran the cucumber scripts without expect having been installed.

it can be reopened if it's reproducible on the latest Puppet 4 or newer


For instance, i've just found that on MS Windows, GLFW enables a different "DPI awareness" algorithm depending on the MS Windows version : https://github.com/raysan5/raylib/blob/996f50393ec51fa33b361546986afc9762849a76/src/external/glfw/src/win32_init.c#L692C1-L697C30
Might have to document the "expected" behaviors on each and every supported platform so no one later breaks the pipeline trying to fix what they believe is a general issue when it is in fact just an "expected behavior" on a the specific OS or setup.

No wonder the whole thing is so complicated to get right ☹
I think GLFW for instance should have chosen one way to deal with high dpi and make it consistent across all platforms instead of just fixing problems separately for each platform whenever there is a problem.
That inconsistency trickles down to any code using it and it becomes almost impossible to make it consistent again...

@SoloByte  : I've found some unexpected __APPLE__ into rcore.c :
// Get current render width which is equal to screen width*dpi scale
int GetRenderWidth(void)
{
    int width = 0;
#if defined(__APPLE__)
    Vector2 scale = GetWindowScaleDPI();
    width = (int)((float)CORE.Window.render.width*scale.x);
#else
    width = CORE.Window.render.width;
#endif
    return width;
}

// Get current screen height which is equal to screen height*dpi scale
int GetRenderHeight(void)
{
    int height = 0;
#if defined(__APPLE__)
    Vector2 scale = GetWindowScaleDPI();
    height = (int)((float)CORE.Window.render.height*scale.y);
#else
    height = CORE.Window.render.height;
#endif
    return height;
}

Are the results returned by these func consistent with the new pipeline ?

THere are some others into BeginScissorMode()

Ok so now the struggle is with Wayland.
Wayland does not let know or set the position of a window.
So anything that relies on glfwGet/SetWindowPos() is broken and trigger GLFW errors.
And i'm not just talking about the changes made in this PR. Am also talking about function like GetWindowMonitor().
If a Wayland user is reading :
please, please, tell me why you absolutely need Raylib to support Wayland since Wayland provides a X11 backward compatibility extension that works pretty well.
Just compile once for X11, and it works out of the box on Wayland.
So why would you need GLFW_LINUX_ENABLE_WAYLAND=TRUE for ?

@SoloByte : I've found some unexpected __APPLE__ into rcore.c :
// Get current render width which is equal to screen width*dpi scale
int GetRenderWidth(void)
{
    int width = 0;
#if defined(__APPLE__)
    Vector2 scale = GetWindowScaleDPI();
    width = (int)((float)CORE.Window.render.width*scale.x);
#else
    width = CORE.Window.render.width;
#endif
    return width;
}

// Get current screen height which is equal to screen height*dpi scale
int GetRenderHeight(void)
{
    int height = 0;
#if defined(__APPLE__)
    Vector2 scale = GetWindowScaleDPI();
    height = (int)((float)CORE.Window.render.height*scale.y);
#else
    height = CORE.Window.render.height;
#endif
    return height;
}

Are the results returned by these func consistent with the new pipeline ?

It still causes the same problem with letting the window size grow by a factor of 2 everytime borderless fullscreen / fullscreen is exited.
But even if this would not be the case the if def should be removed in my opinion because a getter function should not alter the stored value it returns... (you can never set CORE.Window.render.width to the value GetRenderWidth() returns or it will cause problems)
//CORE.Window.render.width equals 500
//but function returns 1000
int w = GetRenderWidth();

//sometime later in the code
CORE.Window.render.width = w; //is now set to 1000

//next frame
//now it returns 2000 and so on...
int w = GetRenderWidth();

We will have to find another way to scale render size by the content scale to make macOS consistent with the other platforms when high dpi is enabled.

THere are some others into BeginScissorMode()

I don't know if this would cause issues or not... I will have to test it later.

It still causes the same problem with letting the window size grow by a factor of 2 everytime borderless fullscreen / fullscreen is exited.

does it improve if your replace GetRenderWidth/Height()with CORE.Window.render.width/height in here below ?
https://github.com/SuperUserNameMan/raylib/blob/b2c9c5ef8862c228a5be864770df5a5aa5fc6096/src/platforms/rcore_desktop_glfw.c#L219-L227

The Wayland disaster map

In orange, the two functions that we can't rely on with Wayland, because they have no effect beside triggering GLFW errors.
Consequences :

InitPlatform() can't center the window ;
ToggleFullescreen() and ToggleBorderlessWindowed() can't restore previous pos ;
SetWindowMonitor() can't move the windowed window from one monitor to an other (only work in hardware/exclusive fullscreen mode) ;
GetCurrentMonitor() allways returns the left-most monitor ;
etc.

On Ubuntu + Wayland, the window opens on the monitor where the mouse cursor is located, but the cursor coordinate system provided by GLFW is relative to the top corner of the window framebuffer. So it means we can't use the position of the mouse to guess on which monitor it was opened.
The workaround solution implemented :
So in Wayland, i managed to workaround that way :

we don't care about centering the window or guessing on which monitor it opens. We leave that to the Wayland user.

InitPlatform() set the new CORE.Window.lastAssociatedMonitorIndex to 0 (main monitor) by default ;

once the window ready, the programmer can use SetWindowMonitor() to set the value of CORE.Window.lastAssociatedMonitorIndex ;

ToggleFullscreenMode() uses CORE.Window.lastAssociatedMonitorIndex to open the exclusive/hardware fullscreen mode on the selected monitor.

It still causes the same problem with letting the window size grow by a factor of 2 everytime borderless fullscreen / fullscreen is exited.

does it improve if your replace GetRenderWidth/Height()with CORE.Window.render.width/height in here below ?
https://github.com/SuperUserNameMan/raylib/blob/b2c9c5ef8862c228a5be864770df5a5aa5fc6096/src/platforms/rcore_desktop_glfw.c#L219-L227

I will test it and report back!

It still causes the same problem with letting the window size grow by a factor of 2 everytime borderless fullscreen / fullscreen is exited.

does it improve if your replace GetRenderWidth/Height()with CORE.Window.render.width/height in here below ?
https://github.com/SuperUserNameMan/raylib/blob/b2c9c5ef8862c228a5be864770df5a5aa5fc6096/src/platforms/rcore_desktop_glfw.c#L219-L227

I will test it and report back!

Yes, because the window is properly restored after exiting borderless fullscreen.
But the borderless fullscreen is acting up in the current version because for some reason it does not set the fullscreen size to the monitor size...

int frameBufferWidth , frameBufferHeight;
glfwGetFramebufferSize(platform.handle, &frameBufferWidth, &frameBufferHeight);
CORE.Window.previousScreen = (Size){frameBufferWidth, frameBufferHeight};

On macOS getting the framebuffer size from glfw also needs a special case where the framebuffer size needs to be divided by the dpi scale to set the proper window size. (If GLFW_SCALE_FRAMEBUFFER is set to true)

The GLFW_SCALE_FRAMEBUFFERflag basically does what we want it to do and if we set it to false the framebuffer will no longer be automatically scaled by macOS as far as I can tell right now. Which means it would be consistent with the other OS's. The problem is just that once it is set to false other weird stuff happens that has to be sorted...
if ((CORE.Window.flags & FLAG_WINDOW_HIGHDPI) > 0)
    {
        glfwWindowHint(GLFW_SCALE_TO_MONITOR, GLFW_TRUE); // Only has effect on Windows and X11
        glfwWindowHint(GLFW_SCALE_FRAMEBUFFER, GLFW_TRUE); // Only has effect on MacOS and Wayland // TODO Wayland test
    }
    else
    {
        glfwWindowHint(GLFW_SCALE_TO_MONITOR, GLFW_FALSE);
        glfwWindowHint(GLFW_SCALE_FRAMEBUFFER, GLFW_FALSE);
    }

Anyways, I will just go through the entire pipeline and take my time to get macOS to work once everything is done on your end ;)
I just have to get the basics working and work my way up until all the special cases work ;)

I wanted to euthanize Wayland support, but this little beast is doing progresses.

Now SetWindowMonitor() also work on Wayland thanks to a little workaround trick : https://github.com/SuperUserNameMan/raylib/blob/1a7657ebd0b3ccbb98af0652dff41f0e870ce90d/src/platforms/rcore_desktop_glfw.c#L649-L662

So if Ubuntu is not mistaking me, on Wayland, the windows and their framebuffers are automatically rescaled according to the display scale factor.
It's like if FLAG_WINDOW_HIGHDPI was ON all the time.
So, for Wayland, GLFW_SCALE_FRAMEBUFFER must be set to FALSE all the time.
Also, instead of adding many if (glfwGetPlatform() == GLFW_PLATFORM_WAYLAND) special case everywhere, i just and simply disable FLAG_WINDOW_HIGHDPI in InitPlatform() if Wayland is detected.
https://github.com/SuperUserNameMan/raylib/blob/19020153caf585a542279e682f9af31154ed3958/src/platforms/rcore_desktop_glfw.c#L1384-L1410

FLAG_WINDOW_HIGHDPI, fullscreen mode and GetWindowScaleDPI() :
The behavior should be made consistent on all platforms :
https://github.com/SuperUserNameMan/raylib/blob/2ffca576293de1b60019ba3e14ea34cc0d757eeb/src/platforms/rcore_desktop_glfw.c#L1025-L1045
@SoloByte : something that might interest you (i forgot to add a // TODO __APPLE_ @SoloByte mission into the code)
From now on, for the sake of cross-platform consistency :

when we are in hardware fullscreen mode : GetWindowScaleDPI() must return { 1.0 , 1.0 }.

if the operating system manages the HDPI rescaling by itself : GetWindowScaleDPI() must always return { 1.0 , 1.0 }.

on other platforms where FLAG_WINDOW_HIGHDPI is enabled and effective : GetWindowScaleDPI() must return { 1.0 , 1.0 }.

GetWindowScaleDPI() must return the actual DPI scale of the display only in windowed mode if FLAG_WINDOW_HIGHDPI is effective and disabled.

There is also point 4 for consistency:
What should GetMonitorWidth/Height() return?

Always the size of the monitor the window is on? (4k monitor returns 4k always for instance)
Or always the current hardware resolution of the monitor the window is on ? So in fullscreen mode it returns the new hardware resolution otherwise it returns the monitor size either scaled by dpi factor or not?

For instance right now on macOS on a 4k monitor with the system settings set to 1080p resolution the functions GetMonitorWidth/Height() always return 1920x1080 (high dpi flag does not change this) in windowed mode and the hardware resolution in fullscreen mode.

Good point :-/
One of the problem i think is : why the user want to use GetMonitorWidth/Height() ?
Why do they want to know the resolution of the monitor current's display resolution ?
And what can they accomplish with these data ?

Good point :-/
One of the problem i think is : why the user want to use GetMonitorWidth/Height() ?
Why do they want to know the resolution of the monitor current's display resolution ?
And what can they accomplish with these data ?

I don't know :( I have used it for fullscreen before this PR ^^ But it exists so we should at least make it consistent?

Here are some idea of usage for eonitorWidth/Height( monitor ) and related functions :

know the aspect ratio of the displays
know on which display the program would be better displayed and use SetWindowMonitor() to move the window automatically on the most appropriate monitor
send system configuration info to the developer

    int GetMonitorCount(void);                                  // Get number of connected monitors
    int GetCurrentMonitor(void);                                // Get current connected monitor
    Vector2 GetMonitorPosition(int monitor);                    // Get specified monitor position
    int GetMonitorWidth(int monitor);                           // Get specified monitor width (current video mode used by monitor)
    int GetMonitorHeight(int monitor);                          // Get specified monitor height (current video mode used by monitor)
    int GetMonitorPhysicalWidth(int monitor);                   // Get specified monitor physical width in millimetres
    int GetMonitorPhysicalHeight(int monitor);                  // Get specified monitor physical height in millimetres
    int GetMonitorRefreshRate(int monitor);                     // Get specified monitor refresh rate
    const char *GetMonitorName(int monitor);

I'll make further tests on all the OS i have access to and compare returned results in different scenario and see how coherent it is in relation to the active DPI scale and rescaling.

Probably best for a different PR but we still need a function that returns all supported video modes for a monitor

I have tested some more stuff with macOS and I am pretty sure now that we have to enable the high dpi flag on macOS permanently.
On macOS GLFW_SCALE_FRAMEBUFFER flag does exactly what the name suggests. It tells macOS if it should automatically scale the framebuffer based on the dpi scale. It does not change the behaviour of macOS regarding dpi scaling. MacOS will still scale everything to the resolution set in the system settings without us being able to change that.
So if I set my system resolution to 1920x1080 on a 4k monitor everything behaves like I am actually on 1920x1080 monitor and not on a 4k monitor that is scaled down.
(A 960x540 window will always cover 1/4 of a 4k monitor set to 1920x180 no matter what we do)
It would be nice if there is some other raylib users out there that use macOS and could confirm this ?

Once it is my turn I will try to make it work with GLFW_SCALE_FRAMEBUFFER enabled.

A question regarding the WindowSizeCallback.

Why do you use it with framebufferWidth/Height arguments instead of windowWidth/Height arguments? (Theoretically it gives you the current window size and not the current framebuffer size which causes issues on macOS for instance)
Why do you not use the FramebufferSizeCallback for the framebuffer stuff and the WindowSizeCallback for windowSize stuff?

FYI: TheFramebufferSizeCallback is called before the WindowSizeCallback.

SetMouseScale() and SetMouseOffset consistency :
These are function made available to the user, so if a platform requires a mouse scaling and offset, they should not use them.
Instead they should use the new CORE.Input.Mouse.platformOffset and CORE.Input.Mouse.platformScale so that SetMouseOffset() and SetMouseScale() remains consistent on all platform and don't break the setup required by the platform.
Note : Might have to do something similar with gestures once i take the time to figure the purpose of it and find a way to test it.

Probably best for a different PR but we still need a function that returns all supported video modes for a monitor

Yep, that will have to be separate PR because it would involve all platforms.

FYI: TheFramebufferSizeCallback is called before the WindowSizeCallback.

There is no FramebufferSizeCallback() in this PR. Did I lose it in the overhaul process ? :fire:
glfwSetWindowSizeCallback() : This function sets the size callback of the specified window, which is called when the window is resized. The callback is provided with the size, in screen coordinates, of the content area of the window.
glfwSetFramebufferSizeCallback() : This function sets the framebuffer resize callback of the specified window, which is called when the framebuffer of the specified window is resized.
I'm going to try both and see if it solve an issue on Wayland.

There is no FramebufferSizeCallback() in this PR. Did I lose it in the overhaul process ?

No but GLFW has it and it might be better in the future if the framebuffer callback deals with framebuffer stuff and the window size callback with window size stuff?

Also I probably have to use it for macOS. When the window is resized on macOS the window size callback is called with the actual window size but in your pipeline you often call the window size callback with the framebuffer size instead.

Sir, i think you solved the Wayland issue i had to workaround.
I confirm that on Wyalnd, it is better to use the glfwSetFramebufferSizeCallback() instead of the glfwSetWindowSizeCallback() one.
On other platforms (X11, Win10 and Win11), it seems to make no difference, so I made it default for all.
I hope it will work out of the box for MacOS too.

On other platforms (X11, Win10 and Win11), it seems to make no difference, so I made it default for all.

I think this is the main difference between x11/win10/win11 and macOS Wayland that in the former the window size and framebuffer size are always the same per default and in the latter the os sometimes scales the framebuffer for you 👍

I've just noticed i accidentally merge some changes involved in pending #4164. I should be more careful with my copy/paste X-S
https://github.com/SuperUserNameMan/raylib/blob/df62c800faa0f7fcd155c8d495a809def613b68e/src/rcore.c#L640-L647

new FLAG_CONTENT_RESCALE_LINEAR and FLAG_TEXT_LINEAR_FILTER
When the FLAG_CONTENT_RESCALE mode is downscaled, the default "nearest pixel" filter make the text font ugly to read.
So it is possible to enable an optional "linear filter".

Note : ClearWindowState(FLAG_TEXT_LINEAR_FILTER) can also be used to disable the linear filter enabled by the FLAG_WINDOW_HIGHDPI mode.

SetMousePosition(x,y) coords given in CORE.Window.screen coordinates
Now it applies CORE.Input.Mouse.platformOffset and CORE.Input.Mouse.platformScale so it also works correctly with FLAG_WINDOW_HIGHDPI and FLAG_RESCALE_CONTENT.
This means that the coords provided to this function are always in CORE.Window.screen coordinate space.
If you want to center the mouse : SetMousePosition( GetScreenWidth()/2 , GetScreenHeight()/2 );
I think the behavior is not 100% backward compatible because it now takes the scaling involved by FLAG_WINDOW_HIGHDPI into account. Also the cursor is not allowed to be set outside the "screen" surface.
:warning: : this is the system's cursor that is moved by this function.
So the user's mouse scaling and offset set using SetMouseScale() and SetMouseOffset() are ignored by this function, as they only affect the values returned by GetMouseX/Y() and GetMousePosition().

New test example code bellow : Keypad [5] to center the cursor, and KP [1], [3] ,[7] and [9] move it in a corner.
#include <stdio.h>
#include "raylib.h"
#include "raymath.h"

void update();
void draw();

int main( int argc , char **argv )
{
//	SetWindowState( FLAG_MSAA_4X_HINT );

	SetConfigFlags(FLAG_WINDOW_HIGHDPI); // <======= ???

//	SetConfigFlags(FLAG_FULLSCREEN_MODE);
//	SetConfigFlags(FLAG_BORDERLESS_WINDOWED_MODE);

	SetConfigFlags(FLAG_RESCALE_CONTENT); //!\ HIGHLIY EXPERIMENTAL FLAG disable it for backward compatible mode
//	SetConfigFlags(FLAG_RESCALE_CONTENT_LINEAR); //!\ HIGHLIY EXPERIMENTAL FLAG disable it for backward compatible mode
//	SetConfigFlags(FLAG_TEXT_LINEAR_FILTER);

	SetConfigFlags( FLAG_WINDOW_RESIZABLE );

	InitWindow( 700 , 500 , "Test" );
//	InitWindow( 500 , 0 , "Test" ); // <== full screen windowed mode
//	InitWindow( 0 , 500 , "Test" ); // <== full screen windowed mode
//	InitWindow( 0 , 0 , "Test" ); // <== full screen windowed mode

	if ( ! IsWindowReady() )
	{
		// Platform initialization probably failed
		return -1;
	}

//	ClearWindowState( FLAG_VSYNC_HINT );

//	SetMouseOffset( 10, 10);
//	SetMouseScale( 0.5 , 0.5 );

	SetTargetFPS( 60 );

	while( ! WindowShouldClose() )
	{
		update();

		BeginDrawing();
		{
			ClearBackground( GRAY );
			draw();
		}
		EndDrawing();
	}

	CloseWindow();
}

void update()
{
	if ( IsKeyPressed( KEY_ZERO ) )
	{
		SetWindowMonitor(0);
	}
	else
	if ( IsKeyPressed( KEY_ONE ) )
	{
		SetWindowMonitor(1);
	}
	else
	if ( IsKeyPressed( KEY_F ) )
	{
//		SetWindowSize( 1280 , 720 );
		ToggleFullscreen();
		printf("Toggled, screen now %d x %d\n", GetScreenWidth(), GetScreenHeight());
		printf("Toggled, render now %d x %d\n", GetRenderWidth(), GetRenderHeight());
	}
	else
	if ( IsKeyPressed( KEY_G ) )
	{
		SetWindowState(FLAG_FULLSCREEN_MODE);
	}
	else
	if ( IsKeyPressed( KEY_B ) )
	{
		ToggleBorderlessWindowed();
		printf("Toggled, screen now %d x %d\n", GetScreenWidth(), GetScreenHeight());
		printf("Toggled, render now %d x %d\n", GetRenderWidth(), GetRenderHeight());
	}
	else
	if ( IsKeyPressed( KEY_N ) )
	{
		SetWindowState(FLAG_BORDERLESS_WINDOWED_MODE);
	}
	else
	if ( IsKeyPressed( KEY_C ) )
	{
		ClearWindowState(FLAG_FULLSCREEN_MODE);
		ClearWindowState(FLAG_BORDERLESS_WINDOWED_MODE);
	}
	else
	if ( IsKeyPressed( KEY_X ) )
	{
		MaximizeWindow();
	}
	else
	if ( IsKeyPressed( KEY_V ) )//|| !IsWindowFocused() )
	{
		MinimizeWindow();
	}
	else
	if ( IsKeyPressed( KEY_R ) )
	{
		RestoreWindow();
	}
	else
	if ( IsKeyPressed( KEY_S ) )
	{
		if ( IsWindowState(FLAG_RESCALE_CONTENT) )
		{
			ClearWindowState(FLAG_RESCALE_CONTENT);
		}
		else
		{
			SetWindowState(FLAG_RESCALE_CONTENT);
		}
	}
	else
	if ( IsKeyPressed( KEY_T ) )
	{
		if ( IsWindowState(FLAG_TEXT_LINEAR_FILTER) )
		{
			ClearWindowState(FLAG_TEXT_LINEAR_FILTER);
		}
		else
		{
			SetWindowState(FLAG_TEXT_LINEAR_FILTER);
		}
	}
	else
	if ( IsKeyPressed( KEY_KP_5 ) ) { SetMousePosition( GetScreenWidth()/2 , GetScreenHeight()/2 ); }
	else
	if ( IsKeyPressed( KEY_KP_7 ) ) { SetMousePosition( 0 , 0 ); }
	else
	if ( IsKeyPressed( KEY_KP_9 ) ) { SetMousePosition( GetScreenWidth() , 0 ); }
	else
	if ( IsKeyPressed( KEY_KP_3 ) ) { SetMousePosition( GetScreenWidth() , GetScreenHeight() ); }
	else
	if ( IsKeyPressed( KEY_KP_1 ) ) { SetMousePosition( 0 , GetScreenHeight() ); }
}

void draw()
{
	Vector2 mouse = GetMousePosition();

	int sw = GetScreenWidth();
	int sh = GetScreenHeight();

	int rw = GetRenderWidth();
	int rh = GetRenderHeight();

	Vector2 dpi = GetWindowScaleDPI();

	int monitor = GetCurrentMonitor();

	int mw = GetMonitorWidth( monitor );
	int mh = GetMonitorHeight( monitor );

	Rectangle screenRect = { 0.0 , 0.0 , sw , sh };
	Rectangle renderRect = { 0.0 , 0.0 , rw , rh };

	// Draw the border of the screen :
	DrawRectangleRec( screenRect , RAYWHITE );
	DrawRectangleLinesEx( screenRect , 4.0f , RED );
	DrawRectangleLinesEx( renderRect , 4.0f , GREEN );

	// Draw the text NOT in the center :

	int font_size = 20 ;
	int y = 0 ;

	DrawText( TextFormat( "Mouse  : %.2f x %.2f / %d x %d" , mouse.x , mouse.y , GetMouseX(), GetMouseY()  ) , 10 , y+=font_size , font_size , BLACK );
	DrawText( TextFormat( "Screen : %d x %d" , sw , sh ) , 10 , y+=font_size , font_size , BROWN );
	DrawText( TextFormat( "Render : %d x %d pixels" , rw , rh ) , 10 , y+=font_size , font_size , DARKGREEN );
	DrawText( TextFormat( "Monitor[%d] : %d x %d pixels" , monitor , mw , mh ) , 10 , y+=font_size , font_size , DARKBLUE );
	DrawText( TextFormat( "DPI : %f x %f" , dpi.x , dpi.y ) , 10 , y+=font_size , font_size , BLACK );
	y+=font_size;
	DrawText( TextFormat( "screenRect : %f x %f" , screenRect.width , screenRect.height ) , 10 , y+=font_size , font_size , RED );
	DrawText( TextFormat( "renderRect : %f x %f" , renderRect.width , renderRect.height ) , 10 , y+=font_size , font_size , GREEN );
	y+=font_size;
	DrawText( IsWindowFullscreen() ? "FULLSCREEN MODE" : "" , 10 , y , font_size , BLUE );
	DrawText( IsWindowState( FLAG_BORDERLESS_WINDOWED_MODE ) ? "BORDERLESS WINDOWED MODE" : "" , 10 , y , font_size , PINK );
	DrawText( !IsWindowFullscreen() && !IsWindowState( FLAG_BORDERLESS_WINDOWED_MODE ) ? "Windowed mode" : "" , 10 , y , font_size , YELLOW );
	y+=font_size;
	DrawText( IsWindowFocused() ? "HAS FOCUS" : "does not have focus" , 10 , y+=font_size , font_size , ORANGE );
	DrawText( IsWindowState(FLAG_RESCALE_CONTENT) ? "RESCALE CONTENT" : "does not rescale content" , 10 , y+=font_size , font_size , DARKPURPLE );
	DrawText( IsCursorOnScreen() ? "CURSOR on SCREEN" : "cursor NOT on screen" , 10 , y+=font_size , font_size , DARKGREEN );
	y+=font_size;
	DrawText( "[F] ToggleFullscreen()" , 10 , y+=font_size , font_size , GRAY );
	DrawText( "[G] SetWindowState(FLAG_FULLSCREEN_MODE);" , 10 , y+=font_size , font_size , GRAY );
	y+=font_size;
	DrawText( "[B] ToggleBorderlessWindowed()" , 10 , y+=font_size , font_size , GRAY );
	DrawText( "[N] SetWindowState(FLAG_BORDERLESS_WINDOWED_MODE);" , 10 , y+=font_size , font_size , GRAY );
	y+=font_size;
	DrawText( "[C] ClearWindowState(FLAG_xxx_MODE);" , 10 , y+=font_size , font_size , GRAY );
	y+=font_size;
	DrawText( "[X] MaximizeWindow();" , 10 , y+=font_size , font_size , GRAY );
	DrawText( "[V] MinimizeWindow();" , 10 , y+=font_size , font_size , GRAY );
	DrawText( "[R] RestoreWindow();" , 10 , y+=font_size , font_size , GRAY );
	y+=font_size;
	DrawText( "[T] toggle `FLAG_TEXT_LINEAR_FILTER`" , 10 , y+=font_size , font_size , GRAY );

	// Draw a software mouse cursor for debug purpose :

	DrawCircleSector( mouse , 30, 45, 90, 1, WHITE);
	DrawCircleSectorLines( mouse , 30, 45, 90, 1, BLACK);

	// Draw a target :

	DrawLine( GetMouseX() , 0 , GetMouseX() , sh , BLUE );
	DrawLine( 0 , GetMouseY() , sw , GetMouseY() , BLUE );

	// Center of screen :

	DrawLine( sw/2-10 , sh/2, sw/2+10, sh/2, RED );
	DrawLine( sw/2 , sh/2-10, sw/2, sh/2+10, RED );
}

IsCursorOnScreen() now consistent with FLAG_RESCALE_CONTENT
It returns true only if the cursor is over the CORE.Window.screen surface.
So, if the cursor is inside the window but still over the "blank borders" of each sides of the centered "screen", it will return false.

HELP REQUIRED : MS Windows 11 + TV as monitor
I'm having an issue between my Windows 11 laptop and my 4K TV, and I would like to know if it is limited to my hardware, or if it is a general issue.
Issue description : on Windows 11, when the TV is set as the unique monitor, when I ToggleFullscreen() in a low resolution (using the test code provided above), GLFW fails to setup the fullscreen mode with an ASSERT monitor != NULL error. I tracked down the bug as deep as I could into GLFW, and it seems to be caused because of a "monitor disconnected" event triggered somewhere and somehow for unknown reasons.
My TV is know to have a firmware bug with low resolution (thank you Philips and TMC cooperation), but the issue i'm describing only happens specifically with Win11 and this TV. Other OS works fine with this TV, and other monitor work fine with this Win11.
Help required :
Could you please test if you have similar issue with your Win11 and your TV ?
Setup your TV as unique monitor in 4K or 1080p, then run the example code above, press [F].

I'm checking this PR and I'd like to note that it is moving in a rabbit hole redesign that I won't be able to maintain... Please note that at this state I'm hardly considering merging it.

I'm checking this PR and I'd like to note that it is moving in a rabbit hole redesign that I won't be able to maintain... Please note that at this state I'm hardly considering merging it.

Thanks you for warning me.
Because I think i've already spent way too much time and energy into it anyway, and this is leading me into debugging GLFW (cause of the mentioned issue above), which is way beyond what i wanted to do initially.
In its current state, this PR managed to solve many issues mentioned in the original message, and any extra flag I added to raylib.h can be just ignored without breaking backward compatiblity.
Beside the Win11 issue mentioned just above, and beside the pending MacOS fixes, it works well on every platforms i tested : Win10, Linux + X11, Linux + Wayland.
If you don't merge it, maybe the code could serve as a study for individuals PR to fix issues in vanilla Raylib code in a manner that you'll be able to maintain.

I'm checking this PR and I'd like to note that it is moving in a rabbit hole redesign that I won't be able to maintain... Please note that at this state I'm hardly considering merging it.

@SuperUserNameMan @raysan5
After a lot of testing I think on macOS there is no proper way to disable high dpi scaling. It is possible to workaround but it is not nice nor easy to maintain.
My proposition would be (to allow this PR to be merged or a similar new one)

Remove the High DPI flag altogether and make raylib take care of dpi scaling as default. This would make raylib consistent across all platforms, it would reduce complexity and any UI that uses custom dpi scaling should also work with high dpi scaling enabled(backward compatible)
Remove the Content Scale Flag and everything it does (but keep it somewhere so people can implement it themselves)
Keep all the fixes to the fullscreen mode & borderless fullscreen mode (that's what it was about originally and keep the proper restoring window size/position functionality)
I don't know about the linear filter flag because I don't know why linear filter is enabled on high dpi mode in the first place?!

I definitive answer about this would be nice because I am not going to try to fix anything if it is not going to be merged 🙃
In my opinion the best way to go about it is to reduce complexity and try to create consistency across platforms. (The points above would do that)

Hello,
Although I don't use this part of raylib (rcore), my suggestion would be leaving the scaling to the user side. You'd have to turn raylib into an "engine" to fully manage this.
Best regards.

Are you all refering to the FLAG_RESCALE_CONTENT when talking about the content scaling thing ?
If yes :
I don't know if the way i reimplemented the effect enabled by FLAG_CONTENT_RESCALE is what @raysan5 had in mind when the CORE.Windiw.renderScale and CORE.Window.screenOffset were added to the code for the first time, but according to my tests of many Raylib's examples, when FLAG_RESCALE_CONTENT is associated to FLAG_WINDOW_RESIZE, in most cases, it will resize the 2D UI without having to recompute any UI position and size by code.
It even worked out of the box with the 3D VR stereo view example that i was the most afraid about.
So, basically, you take a Raylib example, add these two flags, and you can resize the window or toggle fullscreen directly without requiring to update the position and size of your UI and Text.
There might be some incompatible examples (like this one ), but that's no big deal.
FLAG_RESCALE_CONTENT is a very beginer and prototyper friendly feature : Write the UI once and simply for the fixed screen dimension requested in InitWindow(), and it will rescale automatically when you resize or fullscreen the window. The 3D content will behave like usual.
And as i said, it does not even change the default behavior of Raylib if you don't enable it.
It's fully backward and forward compatible.
Also, it does not add that much complexity to the code maintainability, since the computations made in _SetupFramebuffer() are separated and already functional.

After a lot of testing I think on macOS there is no proper way to disable high dpi scaling. It is possible to workaround but it is not nice nor easy to maintain.

Which one are you trying to disable ?
If you're talking about the effects enabled by FLAG_WINDOW_HIGHDPI, just do like i've done for Wayland : just disable the flag  by force into SetConfigThing(), and its effects will be disabled in the rest of the pipeline.

Are you all refering to the FLAG_RESCALE_CONTENT when talking about the content scaling thing that should be removed to try to simplify the PR and ease code maintainability ?
If yes :
I don't know if the way i reimplemented the effect enabled by FLAG_CONTENT_RESCALE is what @raysan5 had in mind when the CORE.Windiw.renderScale and CORE.Window.screenOffset were added to the code for the first time (comments mentionned black borders), but according to my tests of several Raylib's examples, when FLAG_RESCALE_CONTENT is associated to FLAG_WINDOW_RESIZE, in most cases, it resized the 2D UI without having to recompute any UI position and size by code.
With these two flags enabled, even the 3D VR stereo example that i was the most afraid of worked out of the box, so i was very optimitic for the rest of the compatibility.
Personally, i find this FLAG_CONTENT_RESCALE is a very begginer and prototyper friendly feature : Write the UI for the fixed screen dimension requested in InitWindow(), and this UI will be rescaled automatically when you resize or fullscreen the window.
It does not even change the default behavior of Raylib if you don't enable it.
The code changes involved are fully backward compatible and are, most of the time, required by the Windows's and X11's implementation of FLAG_WINDOW_HIGHDPI feature anyway.
Also, this new FLAG_CONTENT_RESCALE mode does not complexify the code maintainability that much, since the computations made into _SetupFramebuffer() are separated from each others and are already functional on all platform I tested.
So, if you really want to simplify this PR for the sake of code maintainability by removing FLAG_CONTENT_RESCALE, i'm afraid this FLAG_CONTENT_RESCALE is just the tree hiding the forest, because i did not went down the rabbit hole just for the fun of it.
If I kept trying to fix each issues independently without digging deeper into the code, I doubt i'd have managed to solve them all at once on all platforms i had access to.
If you want to go tiny PR after tiny PR, it might work, but i think you'd unavoidably have to dig your hole from the inside up to the surface.
But maybe i'm being too pessimistic.

After a lot of testing I think on macOS there is no proper way to disable high dpi scaling. It is possible to workaround but it is not nice nor easy to maintain.

Which one are you trying to disable ? OS's or Raylib's ?
If you're talking about the effects enabled by FLAG_WINDOW_HIGHDPI, have you tried doing it like i've done for Wayland ? => just disable the flag by force into SetConfigThing(), and its effets will be disabled in the rest of the pipeline. If i'm not over-optimistic, you'd only have to double check the mouse bahvior, and search for the rest of the __APPLE__ disseminated into the rest of Raylib's code.

Although I don't use this part of raylib (rcore), my suggestion would be leaving the scaling to the user side. You'd have to turn raylib into an "engine" to fully manage this.

I don't exactly know what you are refering to ? I was talking about dpi scaling and raylib already does this automatically if you enable the high dpi flag.

Which one are you trying to disable ? OS's or Raylib's ?

If you're talking about the effects enabled by FLAG_WINDOW_HIGHDPI, have you tried doing it like i've done for Wayland ? => just disable the flag by force into SetConfigThing(), and its effets will be disabled in the rest of the pipeline. If i'm not over-optimistic, you'd only have to double check the mouse bahvior, and search for the rest of the APPLE disseminated into the rest of Raylib's code.

I am not talking about this. I can not implement how raylib behaves when the high dpi flag is disabled because on macOS the automatic scaling (that raylib takes care of when high dpi flag is enabled) to different dpi scales is taken care of by the OS.
On a 4k monitor with the system resolution set to 1920x1080 if you request a window with the size of 960x540 then this window will always cover 1/4 of the screen independent of the high dpi flag. On windows it would cover 1/4 of the screen when the high dpi flag is enabled and 1/16 of the screen when the high dpi flag is disabled. (You could fake this on macOS but I don't like this really much)
So macOS behaves different then the other ones when the high dpi flag is disabled.

Right now I am trying to figure out what would be merged by @raysan5. Because I don't want that our work was pretty much for nothing but I also understand that it is a lot of changes and that we have to find some common ground here. @SuperUserNameMan I also understand that you didn't do it for the fun of it and it was probably the easiest way of getting everything to work.
So basically we should decide what raylib should take care of and what it should not.
I personally do not need the behaviour of FLAG_RESCALE_CONTENT and I do not need the behaviour when the HIGH_DPI flag is disabled. I don't know why anyone would need the behaviour when HIGH_DPI is disabled because any UI that automatically scales to different DPI values can therefore also scale to a size the comes from automatic DPI scaling from raylib.
That the flag RESCALE_CONTENT is easier for beginners when they write a hardcoded UI I can understand but on the other hand without the flag RESCALE_CONTENT it is easier to understand why a hardcoded UI can create a lot of problems.
For me personally a functioning cross-platform window system is important. (Fullscreen, Borderless Fullscreen, Maximize, Minimize, Focusing Windows, Restoring Windows, Moving Windows to different Monitors)

I can not implement how raylib behaves when the high dpi flag is disabled because on macOS the automatic scaling (that raylib takes care of when high dpi flag is enabled) to different dpi scales is taken care of by the OS.

Look, if the OS enforces DPI scaling, there is nothing you can do.
Wayland does that too.
We're not going to emulate an "unscaled" rendering when FLAG_WINDOW_HIGHDPI is disabled on MacOS and Wayland.
If the OS enforce DPI scaling all the time, then let it be.
The only thing we can do is NOT TO DO IT TWICE (once by the OS's, and once by Raylib) when FLAG_WINDOW_HIGHDPI is requested in SetConfigThing() before InitWindow().
So, in the SetConfigThing() code, jsut add a __APPLE__ disable the FLAG_WINDOW_HIGHDPI flag (like i did for wayland).
You'll still have you window DPI rescaled by the OS, but that's the way it is.
When you'll export your game to MS Windows, just add this SetConfigThing(FLAG_WINDOW_HIGHDPI) in your code, and you'll have similar results on both OS. That's it.

For the rest of your comment, regarding the future of this PR, I don't mind if @raysan5 prefers to restart the overhaul from scratch to ease code maintainability according to Raylib's standards and code-conventions.
It's better to have a code that you can maintain and understand because you wrote it, than a code wrote by someone else that you can't maintain because you don't understand why the hell this and that was added or removed or changed.
As far as i'm concerned, I'll still be able to use this code for the project i was working on just before. And when Raylib will be fixed, maybe i'll switch back to master.

I can not implement how raylib behaves when the high dpi flag is disabled because on macOS the automatic scaling (that raylib takes care of when high dpi flag is enabled) to different dpi scales is taken care of by the OS.

Look, if the OS enforces DPI scaling, there is nothing you can do. Wayland does that too. We're not going to emulate an "unscaled" rendering when FLAG_WINDOW_HIGHDPI is disabled on MacOS and Wayland. If the OS enforce DPI scaling all the time, then let it be.
The only thing we can do is NOT TO DO IT TWICE (once by the OS's, and once by Raylib) .
So, in the SetConfigThing() code, jsut add a __APPLE__ to disable the FLAG_WINDOW_HIGHDPI flag (like i did for wayland).
You'll still have you window DPI rescaled by the MacOS, but that's the way it is. When you'll export your game to MS Windows, just add this SetConfigThing(FLAG_WINDOW_HIGHDPI) in your code, and you'll have similar results on both OS. That's it.

I wasn't going to do that anyway ;) It is just something users of raylib need to be aware of. And the main problem right now is that if you enable the high dpi flag then the DPI scaling is consistent and works but the the image is still blurry because of the linear filter (that in the current master you can not disable or get rid of).

The only thing we can do is NOT TO DO IT TWICE (once by the OS's, and once by Raylib) .

Yes this is the best way to do it.

For the rest of your comment, regarding the future of this PR, I don't mind if @raysan5 prefers to restart the overhaul from scratch to ease code maintainability according to Raylib's standards and code-conventions.
It's better to have a code that you can maintain and understand because you wrote it, than a code wrote by someone else that you can't maintain because you don't understand why the hell this and that was added or removed or changed.

I absolutely understand that. My problem is that this whole thing started because the fullscreen and borderless fullscreen are not working correctly in some way on most platforms.
I still want the borderless fullscreen, fullscreen, and window restoring to be fixed ^^

What's the state of this pull request? I was happy to see issues getting relating to fullscreen handling getting fixed here (e.g. ToggleFullscreen() to get out of fullscreen resulting in a black screen for me), would be a shame if nothing improves after all.

What's the state of this pull request? I was happy to see issues relating to fullscreen handling getting fixed here (e.g. ToggleFullscreen() to get out of fullscreen resulting in a black screen for me), would be a shame if nothing improves after all.

I think the high number of small to big problems in the windowing system are too much right now. There are so many different issues all over the place that it is hard to keep track of all of them and maintaing the overview of how to fix all of it.
I made #4215 for discussing some of the smaller stuff.
I think we have to wait until we can come up with a consensus of what raylib should handle and what not and how it should be implemented to fix most (if not all the issues).

@paulmelis @SoloByte That's it. There are so many casuistics that even small changes that could fix some specific use-case can indeed break other use-cases. Definitely not an easy problem to solve. It requires lot of time and multiple environments and platforms to tests... and unfortunately at the moment I don't have any of them.
Current raylib windowing/screen system works for most of the common use-case situations in ALL platforms. I'm reticent of merging big changes on the system because, as already happened in the past, it could break some specific use-case.
A redesign/review of this system requires resources that unfortunately I don't have at the moment.

Even with a free access to time, ernergy and multiple platforms, IMHO, the main issues are :

there is no reference implementation, neither as core platform, neither as OS in the desktop core platform ;

all desktop/OS are mixed together into a unique core platform, and the merging of a single tiny PR that pretends to fix something on one OS might destabilize all the others desktop OS without noticing -- a solution, to simplify code maintainability and stability, could be to split each desktop/OS into it's own code platform, and make one of them a reference for all the others (This could be Win11) -- this would allow @raysan5 to maintain the main platform/OS he has access to, and let trusted contributors maintain the others without affecting the mains one(s) (exactly like RLGW is not maintained by @raysan5) ;

the current rcore and desktop platform source code contain dead-code, zombie-features and outdated comments that creates heavy code-debts and misleading code interpertation : you basically can't trust what you understand at some place without reviewing all the rest of the code to be sure -- that's why some structural funcs needed to be rewritten, and the whole pipeline reviewed from the bottom to the surface like i was doing in this PR ;

the desktop platform relies on some important rcore functions that contains bugs or misleading algorithms or that are heavily impacted by the code-debt, which would benefit from being rewritten too -- but rewriting them would impact all other platforms. -- The solution could be to create an alternative and temporary version of these functions like i was doing with _SetupFramebuffer() which was solving all bugs and restoring zombie-features at the same time on desktops, without even breaking backward compatibility.

Also :

the behavior of GLFW is not 100% homogeneous on each Windows version regarding DPI scaling and fullscreen toggling (trying to fix one Windows version might destabilize the others) and GLFW is hard to debug and contributes back when you find a bug because there is no comments and some algorithms are extremely complex to decipher without sacrificing neurons in the process. But at the same time, and as far as I know, GLFW is the only framework that support DPI scaling, so extra care should be taken when approving and merging PR that pretends to fix or improve issues related to DPI scaling on Windows.

I'm glad this PR is not going to be merged, because the single idea of having @raysan5 reviewing each and single line like a teacher telling a student "Raylib code does not write this that way. please change that", "This line does not follow the code convention please change that", "You did not read the code convention", "thou arst a bad student, thou can't even read the instruction. thou art stupid, merging thee PR is a privilege, not a contribution, and thou art bad, very bad", etc, was already irritating me at power 10.

Other than that, good luck.

@SuperUserNameMan Thanks for the time invested in improving this system. There was no need at all to be that rude. Good luck with your future projects. Bye.


"Măncești" is listed in the drop-down menu

Description:
"Măncești" is listed in the drop-down menu alongside its corresponding county and commune, according to the law
Precondition:
The website is up an running.

Step 1
Type "Măncești" in the search bar.

Expected results
The location is listed in the drop-down menu as "Măncești, Alba (Horea)".


Verifying all files in crate with one command

Hello,
I've been looking at Verus to see if it would be suitable for a project, and while it verifies individual Rust files well, I cannot for the life of me figure out how to verify a whole crate at once.
The command I've been attempting is:
vargo run -p rust_verify --release -- ../../myproject/kernel

(from the source directory), however this results in
error: couldn't read ../../myproject/kernel: Is a directory (os error 21)

error: aborting due to 1 previous error

so clearly I am not specifying this correctly.
I've read through the start of ther Verus book and INSTALL.md, but don't see anything about verifying whole projects.
Is it possible to verify a whole crate at once/is there documentation somewhere on how to do this?
Thanks

I think you can just point Verus at your src/main.rs file for an executable project, or src/main.rs for a library project.  You'll need to add --crate-type=lib for the latter.  Sorry that the documentation isn't clearer!

Ah, that worked great. Thanks, I'll close the issue


Handle import errors

Description

Related issue https://linear.app/serverless/issue/SC-977/user-thetie-seeing-error-in-production-mode-with-python-sdk
Handle import errors from the SDK (including 3rd party dependencies) by falling back to just executing the customer's handler function.

Testing done

Reproduced in a unit test
Unit/integration tested

@medikoo ready for review 🙏

@selcukcihan still, let's postpone this work until we agree on final solution in Linear. I'll convert it to draft for a meanitime

@selcukcihan still, let's postpone this work until we agree on final solution in Linear. I'll convert it to draft for a meanitime

Thanks @medikoo I think this is still relevant and a good practice to implement, after we solve the problem of managing conflicting versions we should bake this in as well.

Thanks @medikoo I think this is still relevant and a good practice to implement, after we solve the problem of managing conflicting versions we should bake this in as well.

But if we ensure that we import the module we packaged, then there's no chance that import may crash, right?

Thanks @medikoo I think this is still relevant and a good practice to implement, after we solve the problem of managing conflicting versions we should bake this in as well.

But if we ensure that we import the module we packaged, then there's no chance that import may crash, right?

Yes 💯

Closing as I believe with taken approach is not longer needed


Stencil to Angular component: chef-button

An ongoing effort to convert Stencil components over to Angular components.
User Story
As a Developer, I will use this work when I want to build out any html template that uses a <button> element.  This will allow us to re-use a component with minimal effort and consistent styling across automate, while at the same time increasing performance.
Definition of Done

[ ] Angular component built that returns a native <button> element
[ ] Chef specific styles applied
[ ] current chef-button stencil is replaced where used across the site

closed with epic https://github.com/chef/automate/issues/2061


add more descriptive error for badly formed DOTENV_VAULT_ENVIRONMENT

If you have a badly formed DOTENV_VAULT_DEVELOPMENT key (for example) in your .env.vault, the error is not useful when running encrypt.
➜  mar-18 git:(add-vault) dotenvx encrypt apps/backend/
✖ Invalid authentication tag length: 9

DUDE="hi"
WHAT="ok"
DOTENV_VAULT_DEVELOPMENT="encrypted text"

https://github.com/dotenvx/dotenvx/pull/171


CSOT

Description
This PR introduces a new timeoutMS option in alignment with the Client-Side Operations Timeout (CSOT) specification. The CSOT feature is currently in Alpha status.
The timeoutMS option governs the maximum amount of time a single operation can execute before control is returned to the user, covering all aspects of the operation, including server selection, connection checkout, and server-side execution.
Key Changes:

timeoutMS Option: Introduced to specify per-operation timeouts. This option applies to MongoClient, MongoDatabase, MongoCollection, GridFsBucket and ClientSession's.
Error Handling: Introduced a new timeout exception type MongoOperationTimeoutException to distinguish CSOT related failures.
Compatibility: Maintained backward compatibility by ensuring pre-CSOT timeout options are honored if timeoutMS is not set.

Reviewers:
@rozza: Since you have made many of the changes in this branch, I have added you as a reviewer. I have addressed and answered some comments on this PR but would appreciate if you could double-check and comment if you have any objections. A full review of the PR is not expected.
@stIncMale: Could you please check if your previous comments have been addressed and resolve them as needed? A full review of the PR is not expected.
For reviewers:

Test Verification: Ensure all tests are passing and all important build variants are tested.
Verify that the ClientSideOperation* test suites does not have any ignored tests without a valid reason.

Context:
This PR focuses on the alpha changes of CSOT and includes changes from the EPIC: JAVA-3828.
Description is updated by @vbabanin.

Kicked off a full build just to check.
https://spruce.mongodb.com/version/6698dcbb688ab00007faac91/

The MongoCluster concept has been introduced in CSOT and is not marked with the @Alpha annotation, except for timeout-related methods like getTimeout and withTimeout. Although it originated in CSOT, it is applicable beyond this context, so the class MongoCluster has not been marked with @Alpha. If there are any objections, please share your feedback.


[REQUEST] Add a [minimal] version of rich without commonmark and pygments

Rich comes with 2 required dependencies: commonmark and pygments.
CommonMark for Markdown parsing and rendering. Pygments for code syntax highlighting.
I'm often pulling in rich for colorised outputs, tables, and progress bars. None of these require those libs.
It would be nice to have a "minimal" version of rich that doesn't itself have dependencies, e.g.:
$ pip install rich[minimal]

Thanks for your consideration

I've had the same point myself, but AFAIK the extras can't subtract dependencies, only add them.
An alternative might be to have a new package called rich-minimal.

Or second option is to rewrite rich and setup.py to optionally install syntax highlight and markdown render

That's not an option, since it will break people's code.

@willmcgugan I have a question.
Why don't vendor every dependency rich has locally? It would reduce size since it would be possible to remove unwanted functions and variables.

@willmcgugan one solution is using env variable in pip to control the "subtracted" dependency, example
https://github.com/jina-ai/jina/blob/c056fad074ae6f46a61b193fd89af6b7f0751be8/setup.py#L135

There doesn't seem ti be a great deal of appetite for this. Let me know if anyone wants to take the lead on it.


Documentation Site Demo

I don't know whether there is a documentation site for getx or not. I just tried a demo using your readme.md files. You can check it out. If this kind of work is useful for the community then let me know I will work on it for further improvement.
demo link : https://alpondith.gitbook.io/getx/

This is a great feature, why closed this issue?

really?? i did not get any reply thats why i thought this is not helpfull enough. thats why i closed it.
ok i will start work on it again and i will take it to the next level.
let's see how far i can go.
Thanks


chore: refactor server tests

simplify tests by using supertest expectations
remove unnecessary async functions

Contributes to: strimzi/strimzi-ui#117
Signed-off-by: Nic Townsend<EMAIL_ADDRESS>

LGTM - no objection to the change - it achieves the same assertions as before. I am curious to what benefit using request.expect brings (other than the removal of async/await and using it to deal with the async side of things)

My thoughts were:

Async/await worked if we needed to wait for the response, but as expect(res => {}) handled all those cases, it seemed more confusing to await the request promise but do nothing with it, than return it for jest to handle
Removing the then got rid of the "catch and rethrow" behaviour
The request.expect function are mostly shorthand, but it simplified a lot of cases that just cared about headers or status codes


Base Interface Change

Here's a quick proposal for a change to our base interface... I've chatted with @rmfarrell, and he has also independently come up with this solution, as he's run into the same exact problem with our base interface.
Currently
Currently, our base interface is this:
{
    "success": true,
    "status_code": 200,
    "status_text": "OK",
    "error_details": [
        {
            "code": 1,
            "text": "Invalid email"
        }
    ],
    "content": {
        // ...
    }
}

I've not run into many problems with this base interface in use, but documenting this base interface in swagger is extremely repetitive, due to the lack of flexibility of json-ref (not to the fault of json-ref, it's just how it is).
Currently, for documenting an endpoint swagger documentation ends up looking like something like this:
get:
  tags:
  - Applications
  summary: Index
  description: Fetches and displays all applications.
  produces:
  - application/json
  responses:
    200:
      description: OK
      schema:
        type: object
        properties:
# ----------------------------------------
          success:
            type: boolean
          status_code:
            type: integer
          status_text:
            type: string
          error_details:
            type: array
            items:
              $ref: '#/definitions/ErrorDetail'
# ----------------------------------------
          content:
            type: array
            items:
              $ref: '#/definitions/Application'

Proposal
If we wrap all of the non-content information in a meta object, we'll be able to use a json-ref for all of its content.
{
    "meta": {
        "success": true,
        "status_code": 200,
        "status_text": "OK",
        "error_details": [
            {
                "code": 1,
                "text": "Invalid email"
            }
        ]
    },
    "content": {
        // ...
    }
}

Then our swagger for each endpoint would look something more like this
get:
  tags:
  - Applications
  summary: Index
  description: Fetches and displays all applications.
  produces:
  - application/json
  responses:
    200:
      description: OK
      schema:
        type: object
        properties:
# ----------------------------------------
          meta:
            $ref: '#/definitions/Meta'
# ----------------------------------------
          content:
            type: array
            items:
              $ref: '#/definitions/Application'

a bit of a digression but have we investigated (and subsequently dismissed) this existing spec - http://jsonapi.org/ ?

This might be totally too far of a tangent, but this seems like it would be a really great candidate for GraphQL ✨

@kylemac I've totally checked it out recently actually.
This change was largely brought back into my mind because of the readings from there.
Beyond the value of matching an existing specification, I didn't find any additional value in switching to match anything else from that spec (beyond this).

@BrandonRomano that's enough for me. just wanted to be sure we weren't looking past it

Nope, I still to plan to go through it again with a fine-tooth comb, and I will close out #7 once I end up doing that.
I did a high level sweep of it last week during some down-time

But, in short it felt the JSON API specification seemed to trade a lot of fluency for standardization, which IMO wouldn't be a win for us.  It was particularly specific on how you should define relationships and your data.

👍 from me. Makes sense

@tmilewski, thoughts?  Want to get a unanimous decision on this one before I go and do this


Add Steps component to flyio.mdx

Add Steps component to flyio.mdx
Adds the Step component where needed.

Lunaria Status Overview
🌕 This pull request will trigger status changes.

Learn more
By default, every PR changing files present in the Lunaria configuration's files property will be considered and trigger status changes accordingly.
You can change this by adding one of the keywords present in the ignoreKeywords property in your Lunaria configuration file in the PR's title (ignoring all files) or by including a tracker directive in the merged commit's description.

Tracked Files

Locale
File
Note

en
guides/deploy/flyio.mdx
Source changed, localizations will be marked as outdated.

Warnings reference

Icon
Description

🔄
The source for this localization has been updated since the creation of this pull request, make sure all changes in the source have been applied.

!coauthor