Tag filter (tfilter) support for ip_space, address_block, and subnet

Added support for tag filters (tfilters) to the gather modules for ip_space, address_block and subnets.

Let me know if there is an alternate way you want me to do the PR

I have some quite major changes, post this PR, to fix several issues when using ansible variables and special commands for dhcp_option.routers (first|last) plus some simplification of handling the address parameter. Let me know if you want to look at this one first or close this and do a single PR with everything?


Shows a placeholder message when there are no tasks

Solves #192. Will be writing some GUI tests for this.

Coverage increased (+0.004%) to 91.799% when pulling 2147e057830d31890b3a656b716b4f1c62951594 on ui-empty-task-message into dc36be0d813a8330a57bc079660bfc38e2a42964 on development.

Coverage increased (+0.3%) to 92.058% when pulling 715e06118fbcb5f97d28f67f041bc082592d2fa9 on ui-empty-task-message into dc36be0d813a8330a57bc079660bfc38e2a42964 on development.


[Release-1.21] Restoration on a fresh node fails to verify hash for node using the node password file

Backport fix for "Restoration on a fresh node fails to verify hash for node using the node password file" to release-1.21 branch:

#3435

Validated below scenarios using v1.21.2-rc2+k3s2 following the steps below on single node and multi-node setup

Passing token using --token flag
Without passing token

Validation Steps

Create a single node cluster passing token during creation
Deploy workload
Take snapshot. Optionally store it in s3 bucket
On a new node download k3s binary
Restore from snapshot passing the token used during cluster creation
Run the install script
Verify cluster is up and workloads are deployed
Delete the old node


SLURM_ARRAY_TASK_ID = NoneType?

I got the single_agent.py to work. No problems using conda Python 3.10.10. or another Python 3.10.7 environment But I did not get further. I get the following error trying out e.g. role_playing_multiprocess.py:
role_playing_multiprocess.py, line 162, in main
array_idx = int(os.environ.get('SLURM_ARRAY_TASK_ID'))
TypeError: int() argument must be a string, a bytes-like object or a real number, not 'NoneType'
Am I missing something?

There are probably plenty of us that gets excited about this, and despite us having no right to expect such a contribution, it would be fantastic to get the bash script and maybe even a small instruction set regarding setting up/using a Slurm cluster as well.
Are there any simpler, standalone, versions of the script for the code example that you just haven't released yet?

Sorry for the late reply @phober ! This is a sample slurm script to run the generation of AI Society. In this example we chunk the 50 roles into 5 jobs each containing 10 assistant roles. Even though this used to be very helpful before, it seems that with the rate limit we are not really benefiting from this much anymore as we exceed rate limit when we do that. Setting up a slurm cluster is a way bigger thing (we ourselves never set one but rather use the one we have at the university).
#!/bin/bash --login
#SBATCH --job-name=ChatGPT
#SBATCH --output=Output/%A_%a.out
#SBATCH --error=Error/%A_%a.err
#SBATCH --array=0-4
#SBATCH --time=1:59:00
#SBATCH --mem=50G
#SBATCH --cpus-per-task=20

export OPENAI_API_KEY="..."

conda activate camel
python examples/ai_society/role_playing_multiprocess.py


SSH Key Option

My company finds itself in the position where it wants to load one of our private repos into several of our applications. Currently the ways to do that seem to be:

Running your own gem server
Using x-oauth-basic auth with a personal or machine account access token and https url
Using a service like Gemfury

Running a gem server seems like overkill for just loading one gem in a few places, we would like not to have to manage and expose personal access tokens or machine account tokens, and we don't want to pay for a service when it can be avoided.
It would be great if you could specify an ssh key to use when loading a gem through ssh. I imagine it would look something like:
gem "my_gem", git<EMAIL_ADDRESS>ssh_key: "/path/to/key.pub"

So I suppose my questions are, is this a desired feature? Had this already been discussed and decided upon somewhere else that I couldn't find? If it is a desired feature, has anyone started on it/has plans to start on it? If it's desired and not being worked on, I would be glad to take a stab at it.

Load the SSH key into an SSH agent using ssh-add before you bundle install. It will Just Work™.

Alternatively, set up an SSH config file. Either way, Bundler just runs git commands, and git provides no way to set the SSH key. You'll need to use one of the mechanisms that git supports to authenticate git clones with a key.

@indirect in some situations this doesn't work:

Even if you have multiple keys loaded in your SSH agent using ssh-add, bundler will only use the first one in the list. Could be a git issue as well, I have to check.

The SSH config file trick doesn't work if both projects are hosted at the same URL, i.e. on github.com

For people using 1 deploy key per project this is really hard to handle, you basically have to run ssh-add and bundle install in a loop, making sure you add and remove the keys in the same order as defined in the Gemfile.

The solution we ended up using for this was to wrap all our git commands in a git_ssh script:
https://gist.github.com/mcasper/9e139fb7687dc983a59a
We're in the same boat is @antoineco, using separate deploy-only keys for multiple repos, and this script allows you to run something like ~/git_ssh.sh -i ~/.ssh/id_rsa-project1 fetch.
It's not ideal, and I wish git had better support for specifying the ssh key, but it was the best we could come up with.

I don't think that an option in the Gemfile is an acceptable solution for this—a path to an SSH key is going to be machine-specific, and that's not something that you want shared between development and production.
Is there something stopping you all from creating a Github account to use for deploys and adding that account (with a single SSH key) as a read-only collaborator to all of the repos in question?
If we were to add support for this, it would be a config setting, and it would probably be something like bundle config git_ssh_key.gemname "path/to/key", but I'm not convinced that it's serving a common need, yet.

I'm not convinced that it's serving a common need, yet

Probably not. I like the suggestion of setting on key per repo inside the Bundler configuration though.


Remove SL7 support from RPM build, CI

SL7 has been past EOL for a few months now.  As such, we will stop creating releases for SL7.  This will involve:

Removing the SL7-checking code in the spec file in jobsub_lite_config.
Removing the SL7 github action workflow.

(2) is done.  (1) is waiting on the approval and merge of jobsub_lite_config:27.
Once (1) is finished, I'll update the config submodule commit in this repo, and then this will be done.

Done.  Opening PR.


NY6 | Fathi_ Kahin | Cakes.co | WEEK2

Learners, PR Template
Self checklist

[x] I have committed my files one by one, on purpose, and for a reason
[x] I have titled my PR with COHORT_NAME | FIRST_NAME LAST_NAME | REPO_NAME | WEEK
[x] I have tested my changes
[x] My changes follow the style guide
[x] My changes meet the requirements of this task

Changelist
Briefly explain your PR.
Questions
Ask any questions you have for your reviewer.

Hi there @fhkahin  . Please complete the PR message by briefly explaining your code.


feat(KONFLUX-2456): remove SEB and Env checks from rhtap-demo and remote

Description
As part of the feature of decoupling the ephemeral environments in konflux,
this PR is about removing the checks related to SEB(snapshot environment binding )
and Gitops from the e2e-test rhtap-demo .
for more details check KONFLUX-2456
this PR replaces the closed PR#1118
Type of change

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

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
Checklist:

[ ] I have performed a self-review of my code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added meaningful description with JIRA/GitHub issue key(if applicable), for example HASSuiteDescribe("STONE-123456789 devfile source")
[ ] I have updated labels (if needed)

/lgtm
/approve


Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile

This is when i run, npm run build

Hi @Arwiim
CC: @bios6
Thank you for reporting the issue. The team will look into it and get back to you shortly.
In the meantime, you can use the following workaround in your local workspace:
git diff
diff --git a/source/DruidCloudwatchExtension/pom.xml b/source/DruidCloudwatchExtension/pom.xml
index 65fe85a..634c307 100644
--- a/source/DruidCloudwatchExtension/pom.xml
+++ b/source/DruidCloudwatchExtension/pom.xml
@@ -10,8 +10,8 @@
 <properties>
     <druid.version>25.0.0</druid.version>

   <maven.compiler.source>17</maven.compiler.source>

   <maven.compiler.target>17</maven.compiler.target>

   <maven.compiler.source>8</maven.compiler.source>

   <maven.compiler.target>8</maven.compiler.target>
   <jdk.version>17</jdk.version>

This should help you pass the build.
Cheers
Frank

Same error :c, im using macos  sequoia m1

diff --git a/source/DruidCloudwatchExtension/pom.xml b/source/DruidCloudwatchExtension/pom.xml
index 65fe85a..634c307 100644
--- a/source/DruidCloudwatchExtension/pom.xml
+++ b/source/DruidCloudwatchExtension/pom.xml
@@ -10,8 +10,8 @@
 <properties>
     <druid.version>25.0.0</druid.version>

   <maven.compiler.source>17</maven.compiler.source>

   <maven.compiler.target>17</maven.compiler.target>

   <maven.compiler.source>8</maven.compiler.source>

   <maven.compiler.target>8</maven.compiler.target>
   <jdk.version>17</jdk.version>

`diff --git a/source/DruidCloudwatchExtension/pom.xml b/source/DruidCloudwatchExtension/pom.xml
index 65fe85a..634c307 100644
--- a/source/DruidCloudwatchExtension/pom.xml
+++ b/source/DruidCloudwatchExtension/pom.xml
@@ -10,8 +10,8 @@
 <properties>
     <druid.version>25.0.0</druid.version>

   <maven.compiler.source>17</maven.compiler.source>

   <maven.compiler.target>17</maven.compiler.target>

   <maven.compiler.source>8</maven.compiler.source>

   <maven.compiler.target>8</maven.compiler.target>
   <jdk.version>17</jdk.version>

`

diff --git a/source/DruidCloudwatchExtension/pom.xml b/source/DruidCloudwatchExtension/pom.xml
index 65fe85a..634c307 100644
--- a/source/DruidCloudwatchExtension/pom.xml
+++ b/source/DruidCloudwatchExtension/pom.xml
@@ -10,8 +10,8 @@

     <properties>
         <druid.version>25.0.0</druid.version>
-        <maven.compiler.source>17</maven.compiler.source>
-        <maven.compiler.target>17</maven.compiler.target>
+        <maven.compiler.source>8</maven.compiler.source>
+        <maven.compiler.target>8</maven.compiler.target>
         <jdk.version>17</jdk.version>
     </properties>

Hi @Arwiim
Which JDK version are you using? Could you paste the output of the mvn -v command?
I've been able to reproduce the issue with JDK 23, but please note that this version isn't supported. Druid is compatible with Java 11 and 17, with 17 being the preferred option.
To use Java 17, set the JAVA_HOME environment variable (e.g. export JAVA_HOME="/opt/homebrew/opt/openjdk@17") so that Maven selects the correct Java version. Then, delete the target directory under source/DruidCloudwatchExtension and rebuild the project.
Cheers
Frank

Also Maven is using jdk17
 mvn -v                                                                                <248 KiB/s >39.3 KiB/s <IP_ADDRESS> ip

Apache Maven 3.9.9 (8e8579a9e76f7d015ee5ec7bfcdc97d260186937)
Maven home: /opt/homebrew/Cellar/maven/3.9.9/libexec
Java version: 17.0.13, vendor: Homebrew, runtime<EMAIL_ADDRESS>Default locale: es_419, platform encoding: UTF-8
OS name: "mac os x", version: "15.1", arch: "aarch64", family: "mac"

We recommend using Java Correto 17. Could you try that?
> java --version
> openjdk 17.0.13 2024-10-15 LTS
> OpenJDK Runtime Environment Corretto-<IP_ADDRESS>.1 (build 17.0.13+11-LTS)
> OpenJDK 64-Bit Server VM Corretto-<IP_ADDRESS>.1 (build 17.0.13+11-LTS, mixed mode, sharing)

If that does not work, please provide more information as follows:

What version of the solution you are trying to deploy?
Has the build ever worked for you on this macos sequoia m1 before? If so, have you upgraded your OS recently? Please provide the detail of your OS.
Please provide a complete log of your console including all the commands you ran and the output.

Sme error with Corretto
java --version                                                                         <9.71 KiB/s >5.37 KiB/s <IP_ADDRESS> ip
openjdk 17.0.13 2024-10-15 LTS
OpenJDK Runtime Environment Corretto-<IP_ADDRESS>.1 (build 17.0.13+11-LTS)
OpenJDK 64-Bit Server VM Corretto-<IP_ADDRESS>.1 (build 17.0.13+11-LTS, mixed mode, sharing)

This is the solution, im taking the template of the quickstart
{
    "app": "npx ts-node --prefer-ts-exts bin/druid-infra.ts",
    "watch": {
        "include": ["**"],
        "exclude": [
            "README.md",
            "cdk*.json",
            "**/*.d.ts",
            "**/*.js",
            "tsconfig.json",
            "package*.json",
            "yarn.lock",
            "node_modules",
            "test"
        ]
    },
    "context": {
        "@aws-cdk/aws-apigateway:usagePlanKeyOrderInsensitiveId": true,
        "@aws-cdk/core:stackRelativeExports": true,
        "@aws-cdk/aws-rds:lowercaseDbIdentifier": true,
        "@aws-cdk/aws-lambda:recognizeVersionProps": true,
        "@aws-cdk/aws-lambda:recognizeLayerVersion": true,
        "@aws-cdk/aws-cloudfront:defaultSecurityPolicyTLSv1.2_2021": true,
        "@aws-cdk-containers/ecs-service-extensions:enableDefaultLogDriver": true,
        "@aws-cdk/aws-ec2:uniqueImdsv2TemplateName": true,
        "@aws-cdk/core:checkSecretUsage": true,
        "@aws-cdk/aws-iam:minimizePolicies": true,
        "@aws-cdk/aws-ecs:arnFormatIncludesClusterName": true,
        "@aws-cdk/core:validateSnapshotRemovalPolicy": true,
        "@aws-cdk/aws-codepipeline:crossAccountKeyAliasStackSafeResourceName": true,
        "@aws-cdk/aws-s3:createDefaultLoggingPolicy": true,
        "@aws-cdk/aws-sns-subscriptions:restrictSqsDescryption": true,
        "@aws-cdk/aws-apigateway:disableCloudWatchRole": true,
        "@aws-cdk/core:enablePartitionLiterals": true,
        "@aws-cdk/aws-s3:serverAccessLogsUseBucketPolicy": true,
        "@aws-cdk/core:target-partitions": ["aws", "aws-cn"],

        "retainData": false,
        "vpcCidr": "<IP_ADDRESS>/20",
        "druidVersion": "30.0.0",
        "druidOperationPlatform": "eks",
        "druidClusterName": "dev",
        "internetFacing": true,
        "druidExtensions": [
            "druid-hdfs-storage",
            "druid-kafka-indexing-service",
            "druid-datasketches",
            "druid-kinesis-indexing-service",
            "druid-avro-extensions",
            "druid-parquet-extensions",
            "druid-protobuf-extensions",
            "druid-orc-extensions"
        ],
        "druidEksConfig": {
            "endpointAccess": "PUBLIC",
            "clusterMasterPrincipalArn": "arn:aws:iam::211255090713:role/aws-service-role/eks.amazonaws.com/AWSServiceRoleForAmazonEKS",
            "capacityProviderType": "fargate",
            "capacityProviderConfig": {
                "historical": {
                    "minNodes": 3,
                    "maxNodes": 3,
                    "cpu": 4,
                    "memory": "16Gi"
                },
                "middleManager": {
                    "minNodes": 3,
                    "maxNodes": 3,
                    "cpu": 4,
                    "memory": "16Gi"
                },
                "broker": {
                    "minNodes": 3,
                    "maxNodes": 3,
                    "cpu": 2,
                    "memory": "8Gi"
                },
                "router": {
                    "minNodes": 3,
                    "maxNodes": 3,
                    "cpu": 2,
                    "memory": "8Gi"
                },
                "coordinator": {
                    "minNodes": 1,
                    "maxNodes": 1,
                    "cpu": 2,
                    "memory": "8Gi"
                },
                "overlord": {
                    "minNodes": 1,
                    "maxNodes": 1,
                    "cpu": 2,
                    "memory": "8Gi"
                },
                "zookeeper": {
                    "minNodes": 3,
                    "maxNodes": 3,
                    "cpu": 2,
                    "memory": "4Gi"
                }
            }
        },
        "druidMetadataStoreConfig": {
            "metadataStoreType": "aurora",
            "metadataStoreConfig": {
                "rdsInstanceType": "t3.medium",
                "rdsInstanceCount": 3
            }
        }
    }
}

This is the first time building the proyect Mac M1 Sequoia 15.1
The steps was in the src proyect
npm install
npm run build

Thanks for the info. Unfortunately I am not able to create a macos sequoia m1 instance therefore I won't be able to replicate that particular issue. A workaround is to build the solution on Amazon Linux 2.

Hi @Arwiim
It looks like a JDK compiler issue to me. Here’s another fix you can try. This solution worked for me to resolve the same issue with JDK 23.
`
caof@603e5f40ecc2:~/workspace/scalable-analytics-using-apache-druid-on-aws4/source/DruidCloudwatchExtension$ git diff
diff --git a/source/DruidCloudwatchExtension/src/main/java/com/amazon/solutions/druid/cloudwatch/CloudwatchEmitter.java b/source/DruidCloudwatchExtension/src/main/java/com/amazon/solutions/druid/cloudwatch/CloudwatchEmitter.java
index 639a89a..c798c12 100644
--- a/source/DruidCloudwatchExtension/src/main/java/com/amazon/solutions/druid/cloudwatch/CloudwatchEmitter.java
+++ b/source/DruidCloudwatchExtension/src/main/java/com/amazon/solutions/druid/cloudwatch/CloudwatchEmitter.java
@@ -71,7 +71,7 @@ public class CloudwatchEmitter implements Emitter {
private final ObjectMapper jsonMapper;
 // set to nosonar because it causes a false positive

private final CloudwatchEmitterConfig config; // NOSONAR

private CloudwatchEmitterConfig config; // NOSONAR
private final DruidMonitoringMetricsFactory druidMonitoringMetricsFactory;

diff --git a/source/DruidCloudwatchExtension/src/main/java/com/amazon/solutions/druid/cloudwatch/DruidMonitoringMetricsFactory.java b/source/DruidCloudwatchExtension/src/main/java/com/amazon/solutions/druid/cloudwatch/DruidMonitoringMetricsFactory.java
index c188a6b..4f3e2a5 100644
--- a/source/DruidCloudwatchExtension/src/main/java/com/amazon/solutions/druid/cloudwatch/DruidMonitoringMetricsFactory.java
+++ b/source/DruidCloudwatchExtension/src/main/java/com/amazon/solutions/druid/cloudwatch/DruidMonitoringMetricsFactory.java
@@ -67,7 +67,7 @@ public class DruidMonitoringMetricsFactory {
 private final List<String> dimensionBlacklist;

private final CloudwatchEmitterConfig config;

private CloudwatchEmitterConfig config;
public DruidMonitoringMetricsFactory(CloudwatchEmitterConfig config) {
this.config = config;
`
Cheers

Hi Frank,
Do you see this comment of yours in GitHub? We (Abhay and me) don’t see it in GitHub. This is strange. Could you repost it if you want the comment to be seen by public?
Thank you!
Regards,
Aijun
From: Frank Cao @.>
Reply-To: aws-solutions/scalable-analytics-using-apache-druid-on-aws @.>
Date: Monday, November 11, 2024 at 3:42 PM
To: aws-solutions/scalable-analytics-using-apache-druid-on-aws @.>
Cc: "Peng, Aijun" @.>, Comment @.***>
Subject: Re: [aws-solutions/scalable-analytics-using-apache-druid-on-aws] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (Issue #37)
Hi @Arwiimhttps://github.com/Arwiim
It looks like a JDK compiler issue to me. Here’s another fix you can try. This solution worked for me to resolve the same issue with JDK 23.
`
@.***:~/workspace/scalable-analytics-using-apache-druid-on-aws4/source/DruidCloudwatchExtension$ git diff
diff --git a/source/DruidCloudwatchExtension/src/main/java/com/amazon/solutions/druid/cloudwatch/CloudwatchEmitter.java b/source/DruidCloudwatchExtension/src/main/java/com/amazon/solutions/druid/cloudwatch/CloudwatchEmitter.java
index 639a89a..c798c12 100644
--- a/source/DruidCloudwatchExtension/src/main/java/com/amazon/solutions/druid/cloudwatch/CloudwatchEmitter.java
+++ b/source/DruidCloudwatchExtension/src/main/java/com/amazon/solutions/druid/cloudwatch/CloudwatchEmitter.java
@@ -71,7 +71,7 @@ public class CloudwatchEmitter implements Emitter {
private final ObjectMapper jsonMapper;
// set to nosonar because it causes a false positive

private final CloudwatchEmitterConfig config; // NOSONAR

private CloudwatchEmitterConfig config; // NOSONAR

private final DruidMonitoringMetricsFactory druidMonitoringMetricsFactory;
diff --git a/source/DruidCloudwatchExtension/src/main/java/com/amazon/solutions/druid/cloudwatch/DruidMonitoringMetricsFactory.java b/source/DruidCloudwatchExtension/src/main/java/com/amazon/solutions/druid/cloudwatch/DruidMonitoringMetricsFactory.java
index c188a6b..4f3e2a5 100644
--- a/source/DruidCloudwatchExtension/src/main/java/com/amazon/solutions/druid/cloudwatch/DruidMonitoringMetricsFactory.java
+++ b/source/DruidCloudwatchExtension/src/main/java/com/amazon/solutions/druid/cloudwatch/DruidMonitoringMetricsFactory.java
@@ -67,7 +67,7 @@ public class DruidMonitoringMetricsFactory {
private final List dimensionBlacklist;

private final CloudwatchEmitterConfig config;

private CloudwatchEmitterConfig config;

public DruidMonitoringMetricsFactory(CloudwatchEmitterConfig config) {
this.config = config;
`
Cheers
—
Reply to this email directly, view it on GitHubhttps://github.com/aws-solutions/scalable-analytics-using-apache-druid-on-aws/issues/37#issuecomment-2468986884, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALR7P4T5CLZJDKRZUHGAAPL2AEJAJAVCNFSM6AAAAABRMBY7UOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRYHE4DMOBYGQ.
You are receiving this because you commented.Message ID: @.***>

Hi Aijun,
I deleted my original comment because I found that this fix only works intermittently. It appears to be a compiler issue, though the root cause is still unclear. I'd like to spend more time understanding the problem to develop a more reliable fix. For now, I agree that suggesting the customer move to an EC2 host for building is a sensible approach.
Cheers,
Frank
From: "Peng, Aijun" @.>
Date: Wednesday 13 November 2024 at 5:37 AM
To: aws-solutions/scalable-analytics-using-apache-druid-on-aws @.>, aws-solutions/scalable-analytics-using-apache-druid-on-aws @.>, "Cao, Frank" @.>, "Joshi, Abhay" @.>
Cc: Comment @.>
Subject: Re: [aws-solutions/scalable-analytics-using-apache-druid-on-aws] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (Issue #37)
Hi Frank,
Do you see this comment of yours in GitHub? We (Abhay and me) don’t see it in GitHub. This is strange. Could you repost it if you want the comment to be seen by public?
Thank you!
Regards,
Aijun
From: Frank Cao @.>
Reply-To: aws-solutions/scalable-analytics-using-apache-druid-on-aws @.>
Date: Monday, November 11, 2024 at 3:42 PM
To: aws-solutions/scalable-analytics-using-apache-druid-on-aws @.>
Cc: "Peng, Aijun" @.>, Comment @.***>
Subject: Re: [aws-solutions/scalable-analytics-using-apache-druid-on-aws] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (Issue #37)
Hi @Arwiimhttps://github.com/Arwiim
It looks like a JDK compiler issue to me. Here’s another fix you can try. This solution worked for me to resolve the same issue with JDK 23.
`
@.***:~/workspace/scalable-analytics-using-apache-druid-on-aws4/source/DruidCloudwatchExtension$ git diff
diff --git a/source/DruidCloudwatchExtension/src/main/java/com/amazon/solutions/druid/cloudwatch/CloudwatchEmitter.java b/source/DruidCloudwatchExtension/src/main/java/com/amazon/solutions/druid/cloudwatch/CloudwatchEmitter.java
index 639a89a..c798c12 100644
--- a/source/DruidCloudwatchExtension/src/main/java/com/amazon/solutions/druid/cloudwatch/CloudwatchEmitter.java
+++ b/source/DruidCloudwatchExtension/src/main/java/com/amazon/solutions/druid/cloudwatch/CloudwatchEmitter.java
@@ -71,7 +71,7 @@ public class CloudwatchEmitter implements Emitter {
private final ObjectMapper jsonMapper;
// set to nosonar because it causes a false positive

private final CloudwatchEmitterConfig config; // NOSONAR

private CloudwatchEmitterConfig config; // NOSONAR

private final DruidMonitoringMetricsFactory druidMonitoringMetricsFactory;
diff --git a/source/DruidCloudwatchExtension/src/main/java/com/amazon/solutions/druid/cloudwatch/DruidMonitoringMetricsFactory.java b/source/DruidCloudwatchExtension/src/main/java/com/amazon/solutions/druid/cloudwatch/DruidMonitoringMetricsFactory.java
index c188a6b..4f3e2a5 100644
--- a/source/DruidCloudwatchExtension/src/main/java/com/amazon/solutions/druid/cloudwatch/DruidMonitoringMetricsFactory.java
+++ b/source/DruidCloudwatchExtension/src/main/java/com/amazon/solutions/druid/cloudwatch/DruidMonitoringMetricsFactory.java
@@ -67,7 +67,7 @@ public class DruidMonitoringMetricsFactory {
private final List dimensionBlacklist;

private final CloudwatchEmitterConfig config;

private CloudwatchEmitterConfig config;

public DruidMonitoringMetricsFactory(CloudwatchEmitterConfig config) {
this.config = config;
`
Cheers
—
Reply to this email directly, view it on GitHubhttps://github.com/aws-solutions/scalable-analytics-using-apache-druid-on-aws/issues/37#issuecomment-2468986884, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALR7P4T5CLZJDKRZUHGAAPL2AEJAJAVCNFSM6AAAAABRMBY7UOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRYHE4DMOBYGQ.
You are receiving this because you commented.Message ID: @.***>

Close the ticket for now. Feel free to reopen the ticket if there is any new information.


"Technical results" in Bisimulation

In Bisimulation Chapter, the phrase "technical result" is used to describe the lemmas that simulation commutes with value, renaming, and substitution.
Based on how the "techncial results" are introduced, namely:

We need a number of technical results.

May I suggest to change that phrase to something like "mechanical lemmas" or "mechanical results"?
Alternatively, any clarification on how this phrase is intended to mean is helpful for me to translate this chapter.
Many thanks in advance

"Technical result" is a standard phrase in the literature, and I think it is the correct one to use.
Typically, one uses this phrase for a result that is important, and possibly difficult, but uninteresting. "As a technical result, we require a substitution lemma".
I don't think "mechanical lemma" or "mechanical result" is commonly used, but "technical result" is.


termlet_matcher: Added functionality to search users by email.

Added feature to search users in buddy_list and stream_search (while adding people when creating a new stream) by their email address.
CZO topic : https://chat.zulip.org/#narrow/stream/101-design/topic/Search.20by.20email.20domain.
Feature :
(Here, Test user is having a email address (delivery email) of<EMAIL_ADDRESS>
Fixes #12050
Would love an review @showell.
Edit: Working on failing tests.

@aero31aero @ryanreh99 can you help do a first review on this?

@aero31aero @ryanreh99 can you help do a first review on this?


Modify scan all API to support scan all images under a project.

POST api/repositories/scanAll?project_name=xxx

Fixed in #2856


translate English Whitepaper into Malay

translated initial Whitepaper into Malay

Thanks for the contribution.

no worries! will submit a PR for yellowpaper by tomorrow.


Vendor-agnostic tracing (OpenTelemetry)

Instead of requiring developers to use a specific vendor, convert this (or create a separate) library to use OpenTelemetry.
Tracing is incredibly valuable, but for several reasons, isn't readily available for Workers.
I think the benefits are too valuable to be limited to a single vendor and too burdensome to ask developers to roll their own.
An OpenTelemetry-based implementation would benefit many additional people and (I believe) still allow traces to be sent to Honeycomb.
Apologies if this isn't the right place/way to discuss this, but I wasn't sure where else to start the discussion.

Apologies for the late response, but it wasn't possible to do this earlier because of a technical limitation in the Workers runtime. With the recent release of AsyncLocalStorage that is however possible.
I have been working on it over here: https://github.com/evanderkoogh/otel-cf-workers

@evanderkoogh if it was possible for to send them to Honeycomb it was possible to send them elsewhere, right?
Either way, I'm also very excited about nodejs_compat and was about to do try this in our project. Thanks for the link and work on your project.  I'll take a look soon and see how it goes.
In case you or anyone else is interested, I had good success with https://github.com/RichiCoder1/opentelemetry-sdk-workers while testing but never switched over to it
Thanks again and here's to getting some traces from Workers to an OTEL collector!

Hey @jfsiii, oh it would have absolutely been possible to have an Open Telemetry exporter and change this library to support that. But that is very much what the library did which you linked to, so there was little point to change this library to do that.
But Open Telemetry is more than just the export format. It is also about specifying a way for applications and libraries to integrate seamlessly. And that wasn't possible before AsyncLocalStorage and what I am tackling now with the other project.


feat(image widget): media library gallery tools (#6087)

Summary
When using a media library with multiple images option, the user had to replace all images in case they wanted to change the selection in any way (except reorder). The idea was, to give them the ability to remove only certain images, add extra to the selection or replace certain images.
The button wording also needed an update to match the use case.
Closes #6087
Test plan

Usage video
https://user-images.githubusercontent.com/19568230/155301973-bf757da2-7d51-405c-b620-c45003c27057.mov)
I tested with both cloudinary and uploadcare.
config.yml used for testing (single image widget added to see that nothing changed there):
local_backend: true

backend:
  name: git-gateway
  branch: main
  squash_merges: true

display_url: #your-display-url
logo_url: /media/brand/logo.svg
media_folder: static/media/uploads
public_folder: /media/uploads

media_library:
  name: cloudinary
  config:
    cloud_name: #cloudinary-name
    api_key: #cloudinary-key

slug:
  encoding: ascii
  clean_accents: true

collections:
  - name: posts
    label: Posts
    label_singular: post
    folder: content/posts
    create: true
    slug: "{{slug}}"
    editor:
      preview: false
    fields: [
      {name: title, widget: string},
      {name: gallery, widget: image, i18n: duplicate, hint: Select at leat 3 images, required: false, media_library: {config: {multiple: true}}},
      {name: single, widget: image, i18n: duplicate, hint: Only one image, required: false, media_library: {config: {}}}
    ]

Checklist
Please add a x inside each checkbox:

[x] I have read the contribution guidelines.
[x] Code is formatted via running yarn format.
[x] Tests are passing via running yarn test.
[x] The status checks are successful (continuous integration). Those can be seen below.

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

This is great new @erezrokah, thanks.
I will try to add tests the next time we get some new ideas for the widget and contact you guys on slack if I find myself struggling :)
Looking forward to future contributions.

This is shipped in<EMAIL_ADDRESS>and<EMAIL_ADDRESS>That you for the contribution @demshy!


updating VS with hist

Great! 😁

We need to show the what Swiss quality is. At the moment there is some upward potential until we reach the level of e.g. Korea. Thanks for the initiative !


Creation typings to provide TypeScript support

In order to import and use this within TypeScript projects @types are needed.

@AlejandroMoran Any chance you can submit a PR?

@otisg Sorry I think I'm not able to do that due lack of knowledge, I have tried with an automatic generation with 'tsc' but it seems there's more work needed.

Fixed in #16 :ok_hand:


Renamed ESCAPE_EVENT to escapeEvent to follow camelCase convention

Overview
This pull request addresses the naming convention for the constant field previously defined as ESCAPE_EVENT. To align with best practices and improve code readability, the field has been renamed to escapeEvent.
Changes Made
Renamed the constant field from ESCAPE_EVENT to escapeEvent to adhere to the camelCase naming convention for variable names.
Impact
Improved Readability: The change enhances clarity regarding the purpose of the variable, making it easier for developers to understand its usage.
Consistency: This update aligns with standard naming conventions across the codebase, fostering better practices for future contributions.
Link to the issue - https://github.com/anshuman0799/jmonkeyengineFall2024/issues/6

Looks Good, Thanks for your contribution!


Announcement post for Django India X PyDelhi meetup

Closes #1

@Daksh777 Looks good! Thankyou so much 👍


Failed to symlink, File exists

Describe the bug
I run lorri daemon in its own shell. It had been working correctly for quite some time before it crashed with this error log:
name = 'lorri'
operating_system = 'unix:Unknown'
crate_version = '1.0.0'
explanation = '''
Panic occurred in file 'src/build_loop.rs' at line 135
'''
cause = '''
Unrecoverable error:
Io {
    msg: "Failed to symlink /home/user/.cache/lorri/gc_roots/43b29393751a4b4155eb2df05ec2bf91/gc_root/shell_gc_root to /nix/var/nix/gcroots/per-user/user/43b29393751a4b4155eb2df05ec2bf91-shell_gc_root: File exists (os error 17)",
}'''
method = 'Panic'
backtrace = '''

   0: 0x55ace73cf8f9 - std::panicking::try::do_call::h701385363879df93
   1: 0x55ace75c8b4a - __rust_maybe_catch_panic
   2: 0x55ace73ed1a6 - core::ops::function::FnOnce::call_once{{vtable.shim}}::h7d93166c1161340f
   3: 0x55ace75a88bf - <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once::h3e052558cbe55fd8
   4: 0x55ace75ae620 - std::sys::unix::thread::Thread::new::thread_start::h5262a6ff4b26522f
   5: 0x7fe132c17ef7 - start_thread
   6: 0x7fe13293722f - __GI___clone
   7:        0x0 - <unknown>'''

To Reproduce
I'm not completely sure the steps that lead to the error, but I did notice before it crashed that my shell was missing a library I had specified and lorri wasn't building a new environment, so I ran touch default.nix to refresh the shell. After restarting lorri daemon it built the new environment without crashing.
Metadata
The exact version of lorri I'm running is: /nix/store/slvajmdzd3v080fn9b9kqypqdb4bgwnk-lorri-1.0/bin/lorri. I setup lorri with services.lorri.enable = true; in my configuration.nix. I'm on nixos-19.09.2470.4a0df0ce263 (I got that from the channel's manifest file)

Thanks! Here's what I've found:
Bottom-up:

lorri attempted to create a symlink in /nix/var/nix/gcroots, but that symlink already existed
these symlinks are created in Roots::add, which is only called from Roots::create_roots

Top-down:

BuildLoop::forever calls BuildLoop::once calls BuidLoop::root_result calls Roots::create_roots

I can think of two explanations:

There were two lorri instances that raced to build the project; one succeeded, the other failed with the error in the description. There cannot be two daemons at the same time because only one process can own the daemon socket, but there could have been a lorri daemon and a lorri watch process, for instance.
There was a hash collision. Unlikely.

@Skyfold, is it possible that there was a lorri daemon and a lorri watch process running at the same time here?
In terms of fixes / mitigations, I can think of the following:

The code that creates the symlink could check if the symlink already exists and points to the right cache directory. If so, there is no need to create the symlink. If the symlink already exists but points somewhere else, that's an issue. I think lorri should probably fail with a helpful error in that case since it points to a larger problem with the cache. This would be a safe way to deal with a race.

I was only running a lorri daemon. I checked my shell history and the last time I ran lorri watch was before my last restart (more than a month ago).
Is it possible lorri daemon duplicated the build? I'm only guessing this because I edited my cabal file, which should have triggered a build, but there was no notification that a new build had started. So, I manually triggered one with touch default.nix. Maybe lorri was already building the shell, but failed to notify or keep track of this, so it started a second build resulting in the above error?
Either way checking if the symlink already exists would handle this and cases where someone was running lorri watch and lorri daemon at the same time.

I was only running a lorri daemon. I checked my shell history and the last time I ran lorri watch was before my last restart (more than a month ago).

Thanks for the clarification.

Is it possible lorri daemon duplicated the build? I'm only guessing this because I edited my cabal file, which should have triggered a build, but there was no notification that a new build had started. So, I manually triggered one with touch default.nix. Maybe lorri was already building the shell, but failed to notify or keep track of this, so it started a second build resulting in the above error?

#341 is about lorri duplicating builds. Crucially, lorri should never run multiple builds for the same project in parallel; #341 is about lorri enqueueing redundant builds and then running them sequentially.

Either way checking if the symlink already exists and points to the right cache directory would handle this and cases where someone was running lorri watch and lorri daemon at the same time.

:+1:

Either way checking if the symlink already exists and points to the right
cache directory would handle this and cases where someone was running lorri
watch and lorri daemon at the same time.

The symlink check overlaps with https://github.com/target/lorri/issues/387,
which is about checking whether the symlink is exactly the same before
overwriting it.
Which makes me wonder: we already have situations where the same symlink is
overwritten multiple times, right? So how is this different?
On Wed, May 6, 2020 at 11:19 AM Leonhard Markert<EMAIL_ADDRESS>wrote:

I was only running a lorri daemon. I checked my shell history and the
last time I ran lorri watch was before my last restart (more than a month
ago).
Thanks for the clarification.
Is it possible lorri daemon duplicated the build? I'm only guessing this
because I edited my cabal file, which should have triggered a build, but
there was no notification that a new build had started. So, I manually
triggered one with touch default.nix. Maybe lorri was already building
the shell, but failed to notify or keep track of this, so it started a
second build resulting in the above error?
#341 https://github.com/target/lorri/issues/341 is about lorri
duplicating builds. Crucially, lorri should never run multiple builds for
the same project in parallel; #341
https://github.com/target/lorri/issues/341 is about lorri enqueueing
redundant builds and then running them sequentially.
Either way checking if the symlink already exists and points to the right
cache directory would handle this and cases where someone was running lorri
watch and lorri daemon at the same time.
👍
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/target/lorri/issues/389#issuecomment-624535838, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAYB5ZWTL2VAMUYFC4R3DCTRQETRRANCNFSM4MYFORIA
.


extending the "realClick" function to iframes, etc...

(cant name more than 1 example xd)
the title is self explanatory

xd
https://github.com/zfcsoftware/puppeteer-real-browser/issues/154


How to compile this shit?

I need to use this advanced hacked client however i can't understand how to build it from source. Please, provide build instructions.

Yeah, bro I was about to add build instructions, but I needed to take a massive SHIT, so please be patient.


Removing objects from scene.

Hi,
Great work.
I cannot find the implementation of removing objects by their ID during rendering in the test phase.
Can someone help me with the implementation?
Thanks

How to remove the objects from scene.


Proposal: Granular Targeting

This proposal is based on a working implementation at:
https://github.com/yortus/TypeScript/tree/granular-targeting
To try it out, clone it or install it with npm install yortus-typescript
Problem Scenario
The TypeScript compiler accepts a single target option of either ES3, ES5 or ES6. However, most realistic target environments support a mixture or ES5 and ES6, and even ES7, often known in advance (e.g. when targeting Node.js, and/or using polyfills).
Using TypeScript with target environments with mixed ES5/5/7 support presents some challenges, many of which have been discussed in other issues. E.g.:

(#4389) Support compile targets between ES5 and ES6
(#4168) Normalize our lib files by compiler settings
(#3215) New APIs added to lib.d.ts may break client codes. Allow duplicated members in interfaces? Make lib.d.ts overridable?
(#3005) Using ES6 type default library when targetting ES5 output
(#2695) for-of does not work with DOM collections when target is ES6
(somewhat related: (#2481) Create DOM-Level specific dom-version.d.ts)

In summary:

The default lib either includes all ES6 types and properties, or none of them.
Specifying --noLib and/or manually maintaining lib.b.ts files brings other problems:

separate core typings are a burden to maintain.
problems of missing symbols and clashing symbols.
burden of manually tracking fixes and additions made in the default libs.

Targeting ES5 as the 'lowest common denominator' means some language features known to be supported cannot be used (eg generators in Node.js).
Targeting ES6 (e.g. to take advantage of Node.js' support for many ES6 features) leads to further complications:

CommonJS modules won't compile, even though that's the only module system Node supports.
The compiler emits ES6 even for features that are known not to be supported, which would fail at runtime.
Adding babel.js to the build pipeline adds complexity.

Workarounds
To achieve mixed ES5/ES6 core typings:

specify --target ES5 and selectively add ES6 typings in separately maintained files (eg from DefinitelyTyped).
specify --target ES6 and be careful to avoid referencing unsupported ES6 features (the compiler won't issue any errors).
specify --noLib and manually maintain custom core typings in your own project.

To use ES6 features supported by the target platform

specify --target ES5 and (a) convert everything from CommonJS to ES6 modules, (b) accept that things will be down-level emitted, and (c) don't use features with no down-level emit yet (ie generators).
specify --target ES6 and (a) add babel.js to the build pipeline, and (b) configure babel.js to do either pass-through or down-level emit on a feature-by-feature basis.

Proposed Solution
This proposal consists of two parts:
1. Support for conditional compilation using #if and #endif directives, so that a single default lib can offer fine-grained typings tailored to a mixed ES3/5/6/7 target environment.
The conditional compilation part is detailed in a separate proposal (#4691) with its own working implementation.
2. Support for additional compiler options allowing the target environment to be described on a feature-by-feature basis.
Under this proposal, the target option remains, but is now interpreted as the 'baseline' target, determining which features the target supports by default. For instance, ES6 symbols and generators are supported by default if target is set to ES6 or higher.
The additional compiler options have the form targetHasXYZ, where XYZ designates a feature. These options are used to override the target for a particular language feature. They instruct the compiler that the target environment explicitly does or does not support a particular feature, regardless of what the target option otherwise imples.
The working implementation currently supports the following additional compiler options (all boolean):

targetHasArrowFunctions: specify whether the target supports ES6 () => {...} syntax
targetHasBlockScoping: specify whether the target supports ES6 let and const
targetHasForOf: specify whether the target supports ES6 for..of syntax
targetHasGenerators: specify whether the target supports ES6 generators
targetHasIterables: specify whether the target supports ES6 iterables and iterators
targetHasModules: specify whether the target supports ES6 modules
targetHasPromises: specify whether the target supports ES6 promises
targetHasSymbols: specify whether the target supports ES6 symbols

These options work both on the command line and in tsconfig.json files.
Example tsconfig.json Files and their Behaviour
A.
{
    "target": "es6",
    "targetHasModules": false,
    "targetHasBlockScoping": false,
    "module": "commonjs"
}

Emits ES6 JavaScript, except with CommonJS module syntax, and with let/const down-leveled to var. This might match a Node.js environment.
B.
{
    "target": "es5",
    "targetHasSymbols": true
}

Emits ES5 JavaScript, except with Symbol references emitted as-is, and with full type support for well-known symbols from the default lib.
C.
{
    "target": "es5",
    "targetHasPromises": true
}

Emits ES5 JavaScript, except with full type support for ES6 promises from the default lib. This would work in an ES5 environment with a native or polyfilled Promise object.
Backward Compatibility, Design Impact, Performance, etc

There is no impact on existing TypeScript projects. The additional options and preprocessor directives only modify the compiler's behaviour if they are explicitly used.
The preprocessor directives #if and #endif add new language syntax. No existing language features are affected.
There is negligable impact on compiler performance.
Only one default lib is needed (lib.es6.d.ts). It contains many conditionally compiled sections (ie with #if and #endif)

Remaining Work and Questions

Support compiler options for more target features, e.g.:

template strings
classes
Map/Set/WeakMap/WeakSet
binary and octal literals
destructuring
default, rest, and optional parameters

How granular could/should targets be? Feature support is naturally hierarchical. E.g. block scoping may be separated into (a) let, (b) const and (c) block-level function declaration. This is true of most features and their realistic implementations (the Kangax ES6 compatibility table has a three-level hierarchy down the left side).

This is probably just bikeshedding, but would it be possible to consider target: "ES3/5/6" to desugar to some collection of these flags, and then make each flag an option like
target: {
  "asyncAwait": false,
  "decorators": false,
  "arrowFunctions": true,
  "blockScoping": true,
  "forOf": true,
  "generators": true,
  "iterables": true,
  "modules": {"emit": "commonjs"}, //or any of our other options or "esm" for ECMAscript module
  "promises": true,
  "symbols": true,
  "templateLiterals": true,
  "destructuring": true,
  "defaultParameters": true,
  "namespaces": false
}

Where the true can additionally be a configuration object for the feature (as "modules" above, which could deprecate the top-level "module" flag), for example, if the runtime supports let but not const, it could be indicated there. (Otherwise, if having configurable features seems wrong, it could simply be an array of strings, like babel's whitelist argument.)
I'd rather like see the old target syntax get deprecated for a purely flags-based one. (Though I imagine the old style will still get used as a shortcut for certain bundles of features.)
Mostly because I feel like using the target: string style alongside all these top-level flags is building a huge amount of conditional complexity within the compiler (you must have seen the many places checking for ScriptVersion.ES6 and the module flag while implementing this), and would like to see the former go away in favor of just the more versatile feature flags scheme to help unify how that feature checking is done internally.
More seriously: I like the proposed end result of this, by and large, but I don't like that it was coupled to the preprocessor feature (for reasons stated in that issue). As far as the lib file issue goes, I think this comes with the how you're trying to represent the lib as dependent on configuration without allowing the lib to be configured to an acceptable degree.
An alternate solution would be allowing one to specify, internally with each feature, lib.d.ts parts for each, and parts which are dependent on other features to be included. Just like how .es6.d.ts is conditionally included by target right now - Meaning we'd specify lib.d.ts component flag dependencies in code in the compiler, rather than in the .d.ts file with directives.
Beyond that, it may be acceptable to include some kind of feature-dependency pragma within a triple-slash comment in an entire .d.ts, which sets some kind of conditional inclusion/potential error for the entire file... but I don't feel like that's necessarily the right direction to go with this solution.

I agree with @weswigham 's idea of having the feature flags be under their own hash instead of at the top-level, if only to not collide with other top-level properties.
One question - would newly introduced feature flags (say for ES2016 features as they get standardized) default to true or false?

If true, since I cannot list future feature-flags in my project's current tsconfig.json, so by upgrading the compiler I would be opting in to new features that may not be available on my target platforms.

If false, when would they start defaulting to true? One minor release later? One major release later?

Perhaps they wouldn't default to any value. The compiler could require that all feature flags must be explicitly specified, and error out if they're not / prompt at the CLI for the new values. This does make it harder for someone using the CLI without a tsconfig.json, since their commandline would grow longer and longer with every new feature.

@Arnavion Likely false unless a feature doesn't break back-compat when true (meaning it uses new syntax which doesn't change the interpretation of older code), at which point it would be decided on a per-feature basis, I imagine. Everything presently the default for an empty tsconfig would likely start as true. The defaults would likely be driven by backwards compatibility of config files until we wanted to take a large breaking change.

(meaning it uses new syntax which doesn't change the interpretation of older code)

false is good, but to clarify - the back-compat consideration is not just whether existing TS code gets broken, but whether adding new TS code that uses newly available features is allowed by default or not.
Eg: Say TS 1.7 gets released with support for the proposed bind operator ::. If the switch were to default to true, someone may start using it in their project and not understand why it's not being downlevel-emitted, until they spelunked through the source or release notes to find the magic feature flag they must set to false.

@Arnavion I think that's something we'd have to configure via flags  - I mean, we error on async/await unless you pass the flag to compile it, same with decorators. :: would be the same way - we only recognize it as valid if we've been told to compile it. (Now, weather it should be recognized and not downleveled would need to be a configuration option on the feature - we don't do that at all right now except for features that we don't have a downlevel emit for, like generators)

I like the concept of the emit, but the addition of #if and #endif kind of scares me a little.
Instead of using conditional compilation in a base .d.ts file, there should just be extra .d.ts files included with each feature level.

In the past we discussed pre-processor directives like #if and the general consensus is that we'd like to avoid adding that to the language.
We have been considering future support for "design-time" decorators, which only affect the compiler (and would not be written to the output file):

@@conditional("ES6") - The body of the function/method is elided unless the named parameter is supplied to the compiler. Other examples could include: @@conditional("DEBUG"), etc.
@@profile("dom") - The decorated member's type information is only visible when the "dom" profile is selected. Other examples could include: @@profile("es6"), @@profile("webworker"), etc.
`@@obsolete("message") - Use of the decorated member in non-ambient code reports an error at compile time.

We haven't settled on a final design yet.

@weswigham @Arnavion I agree that targets would be better represented by (possibly nestable) sub-hashes. But looking at tsc's commandLineParser.ts, it is clearly oriented toward a flat list of top-level options with simple string/boolean values, which are then used to parse both the command line and tsconfig.json files. So rather than proposing to also re-engineer this mechanism, I took the pragmatic way of just adding top-level options. I think that also overhauling the compiler options mechanism in the same proposal might distract from the key concept of granular targeting. But it would certainly make a good proposal on its own. It does have its own key questions, such as how to specify hierarchical options on the command line, which at this point is equally as capable as tsconfig.json.

@Arnavion regarding default values: under this proposal if a particular option is not explicitly given, the default value is neither true nor false; it is determined by the target option, which is either ES3, ES5, or ES6. So for example, if your project does not explicitly specify an option for targetHasPromises, then the compiler will look at the target option. If that is >= ES6, then it will be as if you had specified targetHasPromises: true, otherwise, it would be as if you had specified targetHasPromises: false.
This means there is no danger of implicitly changing options when you upgrade the compiler.
@weswigham this is also a good reason for keeping (ie not deprecating) the target option. It provides a succinct baseline that imples the value for all the other targetHas... options if they are not explicitly overridden.
As is already the case, if you don't specify a target, the compiler picks ES3 for you. So a blank tsconfig.json file would imply target: ES3 (that is the current compiler behaviour), and hence false for all the other targetHas... options.
Alternatively if you set target: ES6 and nothing else, you would get true for all the ES6 targetHas... options, and false for any ES7+ targetHas... options.

@weswigham @LPGhatguy there no need for this proposal to be wedded to the #if...#endif proposal. The important thing is to get just the core typings needed for the target features specified.
Some solutions to this:

#if...#endif directives as is currently proposed (probably overkill since we just need conditional inclusion just in the core lib files)
one big lib.d.ts with triple-slash pragmas for conditionally including parts of the file as @weswigham suggested (effectively a form of conditional compilation)
the design time decorators that @rbuckton is working on (also a form of conditional compilation?)
having no physical lib.d.ts file but have the compiler internally piece together the definitions it needs somehow, as suggested by @weswigham (although I suspect the cleanest way to implement this would probably involve a physical file with conditional pragmas behind the scenes)
Having many small core lib files for each feature as suggested by @LPGhatguy and elsewhere - but I think this is harder than it sounds due to feature inter-relationships.

@rbuckton:

@@profile("dom") - The decorated member's type information is only visible when the "dom" profile is selected. Other examples could include: @@profile("es6"), @@profile("webworker"), etc.

If I understand correctly, this would work at compile time and in ambient contexts like lib.d.ts. Is it effectively a conditional compilation mechanism, or something else? Also could such a decorator be specified on a property within a type? That would be needed to fully modularize the core types.
Eg would something like this be possible?
@@profile("targetHasPromises")
interface PromiseConstructor {

    prototype: Promise<any>;

    new <T>(executor: (resolve: (value?: T | PromiseLike<T>) => void, reject: (reason?: any) => void) => void): Promise<T>;

    all<T>(values: ArrayLike<T | PromiseLike<T>>): Promise<T[]>;

    @@profile("targetHasIterables")
    all<T>(values: Iterable<T | PromiseLike<T>>): Promise<T[]>;

    race<T>(values: ArrayLike<T | PromiseLike<T>>): Promise<T>;

    @@profile("targetHasIterables")
    race<T>(values: Iterable<T | PromiseLike<T>>): Promise<T>;

    reject(reason: any): Promise<void>;

    reject<T>(reason: any): Promise<T>;

    resolve<T>(value: T | PromiseLike<T>): Promise<T>;

    resolve(): Promise<void>;

    @@profile("targetHasSymbols")
    [Symbol.species]: Function;
}

@yortus:

it is clearly oriented toward a flat list of top-level options with simple string/boolean values, which are then used to parse both the command line and tsconfig.json files. So rather than proposing to also re-engineer this mechanism, I took the pragmatic way of just adding top-level options.

It's better to get it right first than have to go back and re-engineer it later while still also needing to support some half-done bit to get another feature out the door. The interface to the user is very much an important part of this feature, and deserves to be gotten right in a maintainable way.

this is also a good reason for keeping (ie not deprecating) the target option. It provides a succinct baseline that imples the value for all the other targetHas... options if they are not explicitly overridden.

No no, I mean we say this is still valid, this way old configs still work
"target": "ES5"

but identical to this in the new style (in effect, "ES5" expands to a set of flags):
"target": {
  "asyncAwait": false,
  "decorators": false,
  "arrowFunctions": true,
  "blockScoping": true,
  "forOf": true,
  "generators": false,
  "iterables": false,
  "modules": {"emit": "commonjs"},
  "promises": false,
  "symbols": false,
  "templateLiterals": true,
  "destructuring": true,
  "defaultParameters": true,
  "namespaces": true
}

And the two cannot coexist in the same command line/config (they're the same key). This means that if you want newer features, you must swap your config to the newer syntax. Simple enough.
Having many sets of baselines plus flags that modify them is part of the current command-line-option-configuration-explosion problem.

one big lib.d.ts with triple-slash pragmas for conditionally including parts of the file as @weswigham suggested (effectively a form of conditional compilation)

No no, I would never suggest having a conditional pragma control something for only part of a file. I mean for extra metadata per-file. I don't like it very much, but I mean something like so (for, say symbols):
symbols.lib.ts:
///<feature provides="symbols" requires="computedProperties">
interface Symbol {
    toString(): string;
    valueOf(): symbol;
    [Symbol.toStringTag]: string;
}

interface SymbolConstructor {
    prototype: Symbol;
    (description?: string|number): symbol;
    for(key: string): symbol;
    keyFor(sym: symbol): string;

    // Well-known Symbols
    hasInstance: symbol;
    match: symbol;
    replace: symbol;
    search: symbol;
    species: symbol;
    split: symbol;
    toPrimitive: symbol;
    toStringTag: symbol;
    unscopables: symbol;
}
declare var Symbol: SymbolConstructor;

symbols+promises.lib.ts:
///<feature provides="symbols" requires="computedProperties promises">
interface Promise<T> {
      [Symbol.toStringTag]: string;
}

interface PromiseConstructor {
      [Symbol.species]: Promise<any>;
}
//...

symbols+iterators.lib.ts:
///<feature provides="symbols" requires="computedProperties iterators">
interface SymbolConstructor {
    isConcatSpreadable: symbol;
    iterator: symbol;
}
//...

(As a trimmed down example. Interface merging make it all pretty nice.)
When a feature is enabled, all stdlib files which provides that feature are loaded where their requires are met. It's just a simple way of codifying the breakdowns which would need to happen internally, and by no means would I cram all that logic into a single massive conditionally compiling lib. And I'm not even suggesting something like this be publicly exposed - this would simply be an acceptable way to build up a final environment from many tiny parts by feature flags internally to the typescript compiler and language service, while still actually having readable individual "lib files". All of the constraints could be captured in code, though, so the comments are not really required, nor do they need to become part of the language.
IMO, avoiding any more /// directives would be a good idea. I always feel that hiding meaningful syntax in comments is never really the right solution. Personally. I usually try to make a point of avoiding /// ref's where possible, since external modules and tsconfig.json exist to specify file dependencies nowadays.

@weswigham I apologise for misunderstanding your suggestions. I think your examples make it clear now.
So how to avoid the combinatorial explosion of tiny lib files? Just for every combination of symbols, promises, and iterables features, there might be:
symbols+promises+iterables.lib.ts
symbols+promises.lib.ts
symbols+iterables.lib.ts
promises+iterables.lib.ts
symbols.lib.ts
promises.lib.ts
iterables.lib.ts

I'm trying to work out how many files would be needed altogether for every combination of features that has core lib types. It's obviously the inter-dependent types that require the most chopping up.
Anyway this can really be made just an internal implementation detail of the compiler, so the exact method of assembling the right types might come down to maintainability of the compiler. I'm not convinced the ///feature pragma would come out easier or cleaner, but it may I guess.
Point taken about getting the proposal right with regard to using sub-hashes in the tsconfig.js. As I mentioned above that was my original intention until I looked at commandLineParser.ts, although that shouldn't have been relevent to the proposal. Any ideas how such config might be input on the command line?

No no, I mean we say this is still valid, this way old configs still work

"target": "ES5"
but identical to this in the new style (in effect, "ES5" expands to a set of flags):

"target": {
"asyncAwait": false,
"decorators": false,
...

That's effectively how the proposal works, except that they are not mutually exclusive. The target option does effectively expand into a set of feature flags, and the targetHas... options just optionally override those. It actually makes the checker.ts and emitter.ts code clearer IMO, because instead of having things like:
    if (languageVersion >= ScriptTarget.ES6 && node.asteriskToken) {
        write("*");
    }

it looks like:
    if (languageVersion.hasGenerators && node.asteriskToken) {
        write("*");
    }

What I don't like about making target mutually exclusive with the feature-specific options, is that:

(a) if you specify target you achieve brevity but cannot achieve any feature granularity
(b) if you don't specify target you probably have to specify all the feature-specific options explicitly to get a deterministic build (the defaults might not be clear), and as more options are added to new tsc versions, you may get unexpected results anyway.

With the current proposal you can be both concise and deterministic:
{
    "target": "es5",
    "targetHasPromises": true
}

Its clear here what all the omitted targetHas options will be - they will be true if they are <= ES5 features, and false if they are >= ES6 features. And that won't change when building with a different tsc version.

@yortus Potentially instead of targetHas, it might be better to just have an extensions hash.
Instead of
{
    "target": "es5",
    "targetHasPromises": true
}

It might be
{
    "target": "es5",
    "extensions": {
        "promises": true
    }
}

@LPGhatguy yes, or even:
{
    "target": {
        "baseline": "es5",
        "promises": true,
        "blockScoping": true
    }
}

That would provide a path to further sub-dividing features on an optional basis, eg:
{
    "target": {
        "baseline": "es5",
        "promises": true,
        "blockScoping": {
            "baseline": false,
            "let": true
        }
    }
}

So how to avoid the combinatorial explosion of tiny lib files? Just for every combination of symbols, promises, and iterables features:

You don't. If you were using a single file to hold all that information, you'd have that same combinatoric expansion of configurations hidden behind a single monolith file, misleading you about the complexity hidden within it. Small files can be understandable, self-contained, and generally easy to reason about (if I edit/delete this file, it impacts this feature) - especially when they have explicit, well-defined dependencies. Monolith files are difficult to reason over as a unit and, usually, there's no desire to reason over them as a unit - you normally only care about a small part of them at a given instant, anyway. This is true both in code and in definitions.
Some large projects cough like TS cough started with somewhat grokkable, simple file/responsibility boundaries - as a project grows those can become less true. (For example, checker.ts is 15728 lines and contains roughly 300 unique references to identifiers created in other files. It's massive and tightly coupled to a lot of other code. At sha 214df64e (just a single year ago!), checker.ts was just 5797 lines (and some number fewer references). We've almost tripled the code in the checker since TS was open sourced on github, apparently.) You have to make a conscious effort as you grow a project to keep breaking parts out just to compartmentalize the responsibilities of each component.
/rant

Any ideas how such config might be input on the command line?

There's a number of accepted syntaxes for this circulating in the JS community (depends on what opts parser you've used or if you've rolled your own, really), but, IMO, the best is just accepting an actual stringified JSON object on the command line once you're beyond the top level. Other argument nesting schemes are pretty much just unfamiliar cmd DSLs anyway. Others with nested configuration, like tslint, just require a config file. When your command line is longer than a few characters (ie, tsc), who was typing them all out by hand each time, anyway? Hopefully nobody.
Anyways, there's a another what-does-target-mean issue here, though. At present, ES3/5/6 target means "accept and emit everything which can be emitted for these target API levels". Additional flags like --experimentalDecorators augment those with additional features (and are blocked when they can't be downcompiled to the chosen target). We need the ability to control this targeted API level on a per-feature basis, for example, if I wanted to downlevel classes and disable destructuring:
{
    "target": {
        "baseline": "es6",
        "classes": "es5",
        "destructuring": false
    }
}

But, then, what does "es6" vs "es5" vs "es3" mean in the case of classes? From experience, ES6 means preserve TS class keyword, ES5 means emit with property descriptors on a constructor function, and ES3 means do best effort with members on a function. If we could quantify what these emits were dependent on in the environment (class keyword, property descriptors) and target those features too, then we can safely compile to least common denominator given the backing features we claim to support. This would imply that the list of possible features in "target" goes well beyond the obvious top-level ones which would directly enable/disable high-level features.

But, then, what does "es6" vs "es5" vs "es3" mean in the case of classes?
That's why I wouldn't be keen on an option like "classes": "es5". It's unclear. But "classes":"false" specifically means that ES6 classes cannot be emitted as-is. How the down-level emit works may be subject to other true/false feature flags, or if it depends on something where there is no flag, the baseline ES3/5/6 target. This keeps all the flags decoupled.

One advantage of conditionally compiling declarations in lib.d.ts files (whether by directives, pragmas, decorators or whatever) is that picking the right declarations is a completely orthogonal concern to how the declarations should be broken up across files. All of the following would be equally possible:

one huge lib.d.ts file
many separate lib files divided by features, where individual type declarations may be split across several files (eg ssymbols.d.ts, symbols+iterables.lib.ts, promises+iterables.lib.ts etc
many separate lib files that keep each type (and its close relatives) in one place (eg Promise, WeakMap, Symbol etc)

In the latter two cases there is no need for special logic to work out which files to include. Just grab them all and let the conditional compilation mechanism pick the right parts at compile time.

Very similar to #3538. :wink: and some of the commentary there I suspect would apply here as well.
Personally, I think full static resolution in tsconfig.json is limiting.  It would be better to allow expression of a run-time conditional which can potentially be statically defined at build time.  That way, you give the end developer full control.

@kitsonk runtime is a bit late to apply granular targets - the JS has already been emitted and the types have already been checked.

Depends on what type of constructs... Polyfilling functionality, like Promises/WeakMaps/Sets/etc. is perfectly acceptable at runtime and you can make code that works transparently, of which if the end developer should be able to choose.  It is true that largely TypeScript has avoided filling any of this functionality, but providing a generic feature flag mechanism should consider both the build and runtime functionality, otherwise it will likely be DOA.
When you are targeting fundamental language constructs like arrow functions, rest and spread operators, sure, the code is already emitted.

@kitsonk if your project polyfills some ES6 builtins, say Promise and Map, that you know statically that your target supports ES6 promises and maps, so you can tell the compiler to statically type-check the code involving promises and maps. The compiler won't know whether they are native promises or bluebird promises, but that won't matter for type checking.
Since you can't postpone type checking to runtime, and TypeScript already has no problem with polyfilling, I'm not sure what kind of runtime checks you are suggesting would be better?

As an end user, sometimes I might want to create a build that is a bit more "bloated" but allows run-time code path selection, because maybe I am not 100% sure of my user base and I want to hedge my bets, or while I am in development, I don't want to create all my target builds for all my end user agents.  But once everything is settled down, I want to create my final "distribution" I will then want to statically define my features and have a slimmed down targeted emit.
I am suggesting something like has.js in combination with allowing the flags to be statically defined at build time.  That way, the end developer has a choice of controlling the emit.  For example:
has.add('es6-promise', typeof Promise === 'function');

if (has('es6-promise')) {
  console.log('I Promise to always love you');
}
else {
 console.log('I cannot Promise you anything.');
}

When the feature es6-promise is not statically defined, the code would get emitted as a whole, leaving the code path to be determined at run time.  But if statically defined, tree shaking would occur.  So if "es6-promise": true:
console.log('I Promise to always love you');

And if "es6-promise": false:
console.log('I cannot Promise you anything.');

Of course flags could be expressed with no run-time evaluation, ones where only the target and the compiler will change the emit.

@kitsonk I think I get you now, if I understand correctly you are proposing (a) using runtime constants that may be compile-time constants known by the compiler, and (b) doing some control flow analysis and dead code elimination.

@yortus yes, a compiler constant can be a run-time variable, or just a compiler constant and a run-time variable might be overriden by a compiler constant or just have it's run-time representation.  When the compiler constant is used the AST is shaken for dead code removal.

@kitsonk got it. Surely compile-time constants and dead-code elimination would be useful for things other than just granular targeting of ES features (eg eliding debug calls in production builds, etc). If that's the case, wouldn't it be better handled as a feature on its own, with its own proposal? Both proposals are useful with or without the other, they just happen to have a sweet spot where they overlap (ie having both proposals implemented would allow the full control you spoke of).

+1
"Emits ES6 JavaScript, except with CommonJS module syntax, and with let/const down-leveled to var.."
Exactly what I need.

@yortus I am not trying to derail this proposal, but I guess what I am saying is that I don't think it is a full solution.  What I am trying to say is that a full solution would address feature flags as a whole incorporating a run-time semantic as well which would be built out.  For example Promises/Sets/WeakMaps/Maps/Harmony Object.observe... The TypeScript team have made it clear they don't want to (and I agree with them) provide a lot of higher order functionality constructs that is part of the ES standards (or the DOM for that matter).  They are only interested in the language semantics.  If the proposed solution doesn't solve how to deal with those type of features, or give the end developer a framework to express those features...
Essentially #3538 is that proposal that I have been talking about here, though I am more arguing the concept that build-time feature flags should complement some sort of run-time feature expression and code path choices.

I am more arguing the concept that build-time feature flags should complement some sort of run-time feature expression and code path choices.

@kitsonk I have no objection to that. The key word there for me is complement, as in they are complementary proposals that would work well together. You seem to be suggesting that they should all be put into one proposal. I guess I'm not convinced of that. On the static side, the issue is granular static type checking (by conditionally bringing in the right bits of the default lib) and granular choice over what is emitted as-is and what is down-leveled. On the dynamic side, there is control flow analysis and dead code emilination. That would be a lot to tackle in a single proposal, especially when they can be considered separately and still work perfectly fine together.

Runtime overhead is the job of polyfills like core-js, not TypeScript. That will provide automatic polyfilling now and going forward into the future.
TypeScript's language filling are all syntactical, not practical to detect at runtime, and would be nice to decide the level of.

One of the main draws of TS is supposed to be the support for newer syntax, but the current implementation doesn't allow for taking advantage of it without compromises or workarounds, and it significantly detracts from the appeal of TS. It makes sense that TS doesn't do runtime stuff, but it doesn't make sense that I have to target ES5 for platforms that support ES6 features, or that I have to use a tool like babel that duplicates syntax related functions of TS if I want to target ES6 because the targeting is stupidly all or nothing.

I just wanted to see if there's any renewal of this issue. I just discovered with https://github.com/TypeStrong/ts-node/issues/43#issuecomment-160785145 that node supports some ES6 features but doesn't seem to support others such as destructuring. Seems like a pretty major bottleneck for people wanting to use ES6 features but using a runtime like node. It would be great to have something like:
{
  "target": "ES6",
  "features": {
    "destructuring": false
  }
}

Where the compiler can support certain downgrades/upgrades in syntax output based on the initial target.

I'd also be interested if the team has had further thoughts on this. In the v1.7 release (congrats team on this and thanks!) blog post it states:

For example, it is now a breeze to target Node.js v4 and beyond, which doesn't support ES6 modules (but does support several other ES6 features).

//tsconfig.json targeting node.js v4 and beyond
{
    "compilerOptions": {
        "module": "commonjs",
        "target": "es6"
    }
}

But to take @blakeembrey's example, anybody doing this and using destructuring in their code will find themselves getting runtime errors from node but no errors from tsc. And more of this kind of situation can be expected in future as ES7 matures.

For Node 5, I'm currently using a two-step build/run:
tsconfig.json:
{
  "compilerOptions": {
    "target": "ES6"
  }
}

Then a final pass through babel (requires npm i babel-preset-node5, a little preset I wrote to polyfill most of the missing 41% of the ES2015 spec in Node 5.x)
.babelrc
{
  "presets": [
    "node5"
  ]
}

... which can now be run with babel-node [script.js]
Benefits:

Working async/await (for TypeScript 1.7) - babel 6 is broken
No need to remember 'use strict' at the top of every file.
Native Node 5 functionality... let, const, generators, fat arrows, typed arrays, etc, without polyfilling what V8 can already do well
Awesome workflow in WebStorm - compilation and linting happens at code level, and running a script just means babel-node everywhere you'd run node
Works today - no hacks

Targeting node via typescript without babel is still a mess due to lack of granular targeting. I updated to TypeScript 1.7.3 and the spread operator fails on node yet compiles fine with tsc.
If toggles for each feature is going to take a while then maybe a node target would be a good short term fix. It doesn't make sense to only have ES targets when in the real world support varies on a feature by feature basis. Ultimately I think babel has the correct approach (preset options plus individual feature toggles).

@bootstraponline I agree. Without granular (i.e. per feature) targets, native node targeting is going to be tough.
The problem is that Node ES2015 support differs by version. In the 4.x branch, it's 49%. In 5.x, it's 54%. If TypeScript allow a single "node" target, it would mean polyfilling the missing features in the lowest usable node version, which is probably still the 0.10+ branch. And then of course there's MS's Chakra-based Node fork, which is at 90%. The majority of Node users are still going to find native features "over-transpiled" where it's not necessary.
The neat solution is a preset/plugin option, like babel.
For now, specifically targeting Node 4/5 with my babel-preset-node5 preset and then targeting "es6" with tsc should do the trick. It's an extra step, but it's generally a small one. Just configure your build dev to run babel-node instead of plain node and that fixes most things.

@leebenson @bootstraponline looks like an external solution will be the way to go for a good while yet. I can't speak for the language team but I have noticed that of the many features added to the roadmap  recently, right out to v2.1, granular targeting is not one of them

yup. Add babel and be done with it (for now.) It adds ~1s to the build time but otherwise, is pretty much invisible.

@leebenson unfortunately that still doesn't help with the lib.d.ts issues outlined in the OP, which can be just as painful.

@yortus understood. That hadn't been an issue I came across, but I can see how that could be a show-stopper.

My current build pipeline is emit ES6 with async/await, and then pipe in to Babel and down emit an __awaiter and use Generators, supported in Node 5.x.
The __awaiter is designed to allow drop-in Promise replacement but the lib.es6.d.ts tramples that by declaring a global Promise type. That's fair enough as ES6 has native promises.
I would like to not use native promises but instead use Bluebird and it's bluebird.d.ts.
Is there another issue that covers this one more accurately? Or a solution? Can I just pull Promise from the lib.es6.d.ts definition?

@nevercast have you come across discussion here and here?
There is no 'easy' solution at present. You can tell the compiler to use a lib.d.ts file that you specify by using the --noLib flag and including a custom lib file in your build. You must maintain that file manually with the mix of ES5/ES6 types you want ambiently defined. Doable but not exactly fun.

Ya, this is the whole reason Babel broke out their plugins like this. I think flags for each feature would be a great start.

@yuit is tackling this

Awesome! Will Granular Targeting be added to the roadmap?

We are starting with the library first (tracked by https://github.com/Microsoft/TypeScript/issues/494).

I know this is not a good idea for many other things, but I've got a radical proposal, add a "node" as a target in addition to ES6, I suppose node is so popular target it should be maintained in TypeScript.

@Ciantic I'm not sure that makes sense: es5/es6 contain a fixed list of language features declared by their respective specifications (when finalized.) "node" is a moving target.

The node target idea was already discussed.
https://github.com/Microsoft/TypeScript/issues/4692#issuecomment-163557313

With the support of --lib flag and breaking up the library in multiple parts, most of this request has been addressed.
the other part is about transformations being picked up a la cart, is something we would not consider in the time being. supporting an ES Next mode however is still something we are interested in.


Minicpm-V-2.6 Llama.cpp and Ollama Support

Hi,
Minicpm-V is a very popular model these days, although it has not been supported by the current version of llama.cpp and ollama, please refer to the following submission:
https://github.com/ollama/ollama/issues/6417
https://github.com/ggerganov/llama.cpp/releases/tag/b3598
BR

Hi @RobinJing ,
ipex-llm‘s ollama is upgrade to 0.3.6 with ipex-llm[cpp]>=2.2.0b20240827, you may have a try with latest llama.cpp / ollama 😊


Example notebook: typo

fig.suptitle('Stress-Strain')
I guess this should be fig.subtitle ...?
Perhaps re-running the whole notebook would be a good idea to catch any more of these?

My bad - suptitle is a thing. I just hadn't come across it :)


Track resources that are pending external name assignment

Description of your changes

Edit: I had originally hoped this would fix https://github.com/crossplane/provider-aws/issues/802, but it appears there was a simpler fix for that specific case. Nonetheless, I do believe we're hypothetically vulnerable to the issue this PR addresses, so we may want to consider merging it anyhow.
Some Crossplane resources have non-deterministic external names that are returned at Create time. We must record those names and rely on them to determine whether the external resources exist during subsequent Observe calls.
The absence of an external name does not guarantee that we didn't create an external resource. It's possible that we created the resource but failed to update its name. It's also possible that we did update the name but have since read a stale, unnamed, version of the resource from cache.
To deal with this we set a 'pending external name' annotation immediately before creating our external resource. If we get to the Create call because we have a stale view of our managed resource the Update call that persists the annotation will fail. If we are already pending external name assignment when we get to the Create call we know it's possible that we created an external resource but did not persist its name, so we refuse to proceed rather than creating a duplicate.
I have:

[x] Read and followed Crossplane's contribution process.
[x] Run make reviewable test to ensure this PR is ready for review.

How has this code been tested

It has not yet. I'll move it out of draft once it has been tested.

Closing in favor of https://github.com/crossplane/crossplane-runtime/pull/283.


Custom Windows is illegal

Hello. My name's Britec and tech YouTuber. If see "Tiny11'', "Nese 7" or other operating systems (not including Microsoft Windows), don't download iso files. I recommended to check my video to about custom Windows and not recommended:
https://youtu.be/gcHmY-aRBds

I'm not NeseOS fan, I'm YouTuber of Britec09. So, I'm protecting everyone against Microsoft copyright policy, Microsoft Terms of service, Microsoft's illegal police

or other operating systems (not including Microsoft Windows), don't download iso files
I think, you should rephrase this sentence to say to not install custom Windows isos and not "other operatic systems". There are legit systems for computers that are not Windows, like GNU/Linux (distros like Ubuntu, Debian, Fedora, kubuntu, etc) or MacOS

Also, i don't think this is a relevant place to post this to.
I remember that there was someone advertising his bootleg in the issues, it would be better to post this as comment on his issue or add a post somewhere else to not overwhelm developers with issues, that are not related with the browser.

or other operating systems (not including Microsoft Windows), don't download iso files

I think, you should rephrase this sentence to say to not install custom Windows isos and not "other operatic systems". There are legit systems for computers that are not Windows, like GNU/Linux (distros like Ubuntu, Debian, Fedora, kubuntu, etc) or MacOS

I'm using Windows 11 IoT Enterprise LTSC 2024. So, I don't trust any iso files like NTDev

This is not related to Supermium either so the issue will be closed.

Win32ss plus, any custom Windows iso files is malware than stock or custom own Windows operating system (not including people) or Windows IoT Enterprise LTSC versions

Modern Windows is better than old, customized Windows versions. I highly recommend to upgrade to Windows 10 IoT Enterprise LTSC 2021 or later. It's still supported until January 13, 2032

I'm not NeseOS fan, I'm YouTuber of Britec09.

Are you sure that you're actually him and not impersonator? Britec09 said that he never had a github account


Recent changes added a bunch of warnings to the build

The changes in #730 introduced a number of warnings to the build that need to be fixed:
/usr/bin/ld: /tmp/go-link-041944162/000034.o: in function `unixDlOpen':
/home/travis/gopath/pkg/mod/github.com/mattn/go-sqlite3@v1.10.0/sqlite3-binding.c:38461: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: /tmp/go-link-041944162/000010.o: in function `mygetgrouplist':
/usr/local/go/src/os/user/getgrouplist_unix.go:16: warning: Using 'getgrouplist' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: /tmp/go-link-041944162/000009.o: in function `mygetgrgid_r':
/usr/local/go/src/os/user/cgo_lookup_unix.go:38: warning: Using 'getgrgid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: /tmp/go-link-041944162/000009.o: in function `mygetgrnam_r':
/usr/local/go/src/os/user/cgo_lookup_unix.go:43: warning: Using 'getgrnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: /tmp/go-link-041944162/000009.o: in function `mygetpwnam_r':
/usr/local/go/src/os/user/cgo_lookup_unix.go:33: warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: /tmp/go-link-041944162/000009.o: in function `mygetpwuid_r':
/usr/local/go/src/os/user/cgo_lookup_unix.go:28: warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: /tmp/go-link-041944162/000007.o: in function `_cgo_26061493d47f_C2func_getaddrinfo':
/tmp/go-build/cgo-gcc-prolog:58: warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

Originally posted by @tolikzinovyev in https://github.com/algorand/indexer/issues/730#issuecomment-946131008
Additional details
This occurs when using go-algrand/rel-beta as a sub-module
Acceptance criteria
Investigate and root cause where the issues is coming from.
Note: Only spend up to 3 days on this and then if there's no progress pull in others from dev if that's not already being done.

The changes that introduced this problem have been reverted.


Recently played / Recently added

Add these to the frontend

Recently added is available. Based on vpx file date. See #288


Add api key option

The https://pkg.go.dev/github.com/elastic/go-elasticsearch/v8 client supports both username/password auth, as well as API Key. However the Terraform provider currently only supports username/password. I've made a quick change to allow the API Key to be specified instead. It is mainly just a schema change, and then the API client config needs to use the value from the provider schema.
I've tested this with one of my local projects, and it successfully created the user and role resources using only the API Key. Also the acceptance tests pass:
TF_ACC=1 go test -v ./... -count 1 -parallel 10  -timeout 120m
?       github.com/elastic/terraform-provider-elasticstack      [no test files]
?       github.com/elastic/terraform-provider-elasticstack/internal/acctest     [no test files]
?       github.com/elastic/terraform-provider-elasticstack/internal/clients     [no test files]
=== RUN   TestAccResourceClusterSettings
--- PASS: TestAccResourceClusterSettings (14.60s)
=== RUN   TestAccResourceSLM
--- PASS: TestAccResourceSLM (14.59s)
=== RUN   TestAccDataSourceSnapRepoFs
--- PASS: TestAccDataSourceSnapRepoFs (9.49s)
=== RUN   TestAccDataSourceSnapRepoUrl
--- PASS: TestAccDataSourceSnapRepoUrl (9.49s)
=== RUN   TestAccResourceSnapRepoFs
--- PASS: TestAccResourceSnapRepoFs (6.98s)
=== RUN   TestAccResourceSnapRepoUrl
--- PASS: TestAccResourceSnapRepoUrl (10.43s)
PASS
ok      github.com/elastic/terraform-provider-elasticstack/internal/elasticsearch/cluster       65.782s
=== RUN   TestAccResourceComponentTemplate
--- PASS: TestAccResourceComponentTemplate (12.73s)
=== RUN   TestAccResourceDataStream
--- PASS: TestAccResourceDataStream (9.19s)
=== RUN   TestAccResourceILM
--- PASS: TestAccResourceILM (11.57s)
=== RUN   TestAccResourceIndex
--- PASS: TestAccResourceIndex (11.79s)
=== RUN   TestAccResourceIndexTemplate
--- PASS: TestAccResourceIndexTemplate (10.19s)
PASS
ok      github.com/elastic/terraform-provider-elasticstack/internal/elasticsearch/index 55.673s
=== RUN   TestAccResourceIngestPipeline
--- PASS: TestAccResourceIngestPipeline (14.66s)
=== RUN   TestAccDataSourceIngestProcessorAppend
--- PASS: TestAccDataSourceIngestProcessorAppend (10.00s)
=== RUN   TestAccDataSourceIngestProcessorBytes
--- PASS: TestAccDataSourceIngestProcessorBytes (8.86s)
=== RUN   TestAccDataSourceIngestProcessorCircle
--- PASS: TestAccDataSourceIngestProcessorCircle (9.30s)
=== RUN   TestAccDataSourceIngestProcessorCommunityId
--- PASS: TestAccDataSourceIngestProcessorCommunityId (5.90s)
=== RUN   TestAccDataSourceIngestProcessorConvert
--- PASS: TestAccDataSourceIngestProcessorConvert (8.71s)
=== RUN   TestAccDataSourceIngestProcessorCSV
--- PASS: TestAccDataSourceIngestProcessorCSV (9.53s)
=== RUN   TestAccDataSourceIngestProcessorDate
--- PASS: TestAccDataSourceIngestProcessorDate (8.04s)
=== RUN   TestAccDataSourceIngestProcessorDateIndexName
--- PASS: TestAccDataSourceIngestProcessorDateIndexName (11.23s)
=== RUN   TestAccDataSourceIngestProcessorDissect
--- PASS: TestAccDataSourceIngestProcessorDissect (5.55s)
=== RUN   TestAccDataSourceIngestProcessorDotExpander
--- PASS: TestAccDataSourceIngestProcessorDotExpander (5.16s)
=== RUN   TestAccDataSourceIngestProcessorDrop
--- PASS: TestAccDataSourceIngestProcessorDrop (5.13s)
=== RUN   TestAccDataSourceIngestProcessorFail
--- PASS: TestAccDataSourceIngestProcessorFail (5.12s)
=== RUN   TestAccDataSourceIngestProcessorFingerprint
--- PASS: TestAccDataSourceIngestProcessorFingerprint (4.84s)
=== RUN   TestAccDataSourceIngestProcessorForeach
--- PASS: TestAccDataSourceIngestProcessorForeach (3.85s)
=== RUN   TestAccDataSourceIngestProcessorGeoip
--- PASS: TestAccDataSourceIngestProcessorGeoip (4.74s)
=== RUN   TestAccDataSourceIngestProcessorGrok
--- PASS: TestAccDataSourceIngestProcessorGrok (3.88s)
=== RUN   TestAccDataSourceIngestProcessorGsub
--- PASS: TestAccDataSourceIngestProcessorGsub (4.20s)
=== RUN   TestAccDataSourceIngestProcessorHtmlStrip
--- PASS: TestAccDataSourceIngestProcessorHtmlStrip (4.38s)
=== RUN   TestAccDataSourceIngestProcessorJoin
--- PASS: TestAccDataSourceIngestProcessorJoin (3.94s)
=== RUN   TestAccDataSourceIngestProcessorJson
--- PASS: TestAccDataSourceIngestProcessorJson (3.94s)
=== RUN   TestAccDataSourceIngestProcessorKV
--- PASS: TestAccDataSourceIngestProcessorKV (3.95s)
=== RUN   TestAccDataSourceIngestProcessorLowercase
--- PASS: TestAccDataSourceIngestProcessorLowercase (3.60s)
=== RUN   TestAccDataSourceIngestProcessorNetworkDirection
--- PASS: TestAccDataSourceIngestProcessorNetworkDirection (3.92s)
=== RUN   TestAccDataSourceIngestProcessorPipeline
--- PASS: TestAccDataSourceIngestProcessorPipeline (4.27s)
=== RUN   TestAccDataSourceIngestProcessorRegisteredDomain
--- PASS: TestAccDataSourceIngestProcessorRegisteredDomain (3.50s)
=== RUN   TestAccDataSourceIngestProcessorRemove
--- PASS: TestAccDataSourceIngestProcessorRemove (3.73s)
=== RUN   TestAccDataSourceIngestProcessorRename
--- PASS: TestAccDataSourceIngestProcessorRename (3.74s)
=== RUN   TestAccDataSourceIngestProcessorScript
--- PASS: TestAccDataSourceIngestProcessorScript (3.56s)
=== RUN   TestAccDataSourceIngestProcessorSet
--- PASS: TestAccDataSourceIngestProcessorSet (3.39s)
=== RUN   TestAccDataSourceIngestProcessorSetSecurityUser
--- PASS: TestAccDataSourceIngestProcessorSetSecurityUser (3.73s)
=== RUN   TestAccDataSourceIngestProcessorSort
--- PASS: TestAccDataSourceIngestProcessorSort (3.65s)
=== RUN   TestAccDataSourceIngestProcessorSplit
--- PASS: TestAccDataSourceIngestProcessorSplit (4.85s)
=== RUN   TestAccDataSourceIngestProcessorTrim
--- PASS: TestAccDataSourceIngestProcessorTrim (3.41s)
=== RUN   TestAccDataSourceIngestProcessorUppercase
--- PASS: TestAccDataSourceIngestProcessorUppercase (4.14s)
=== RUN   TestAccDataSourceIngestProcessorUriParts
--- PASS: TestAccDataSourceIngestProcessorUriParts (4.40s)
=== RUN   TestAccDataSourceIngestProcessorUrldecode
--- PASS: TestAccDataSourceIngestProcessorUrldecode (4.42s)
=== RUN   TestAccDataSourceIngestProcessorUserAgent
--- PASS: TestAccDataSourceIngestProcessorUserAgent (4.75s)
PASS
ok      github.com/elastic/terraform-provider-elasticstack/internal/elasticsearch/ingest        208.315s
=== RUN   TestAccResourceSecurityRole
--- PASS: TestAccResourceSecurityRole (15.28s)
=== RUN   TestAccDataSourceSecurityUser
--- PASS: TestAccDataSourceSecurityUser (13.49s)
=== RUN   TestAccResourceSecurityUser
--- PASS: TestAccResourceSecurityUser (10.84s)
PASS
ok      github.com/elastic/terraform-provider-elasticstack/internal/elasticsearch/security      39.764s
?       github.com/elastic/terraform-provider-elasticstack/internal/models      [no test files]
=== RUN   TestProvider
--- PASS: TestProvider (0.01s)
PASS
ok      github.com/elastic/terraform-provider-elasticstack/internal/provider    0.021s
=== RUN   TestFlattenMap
=== PAUSE TestFlattenMap
=== RUN   TestDiffIndexTemplateSuppress
=== PAUSE TestDiffIndexTemplateSuppress
=== CONT  TestFlattenMap
--- PASS: TestFlattenMap (0.00s)
=== CONT  TestDiffIndexTemplateSuppress
--- PASS: TestDiffIndexTemplateSuppress (0.00s)
PASS
ok      github.com/elastic/terraform-provider-elasticstack/internal/utils       0.031s

Great work @bengesoff this is literally what my organization had need of. @tobio could you please look into this?

jenkins test this

@tobio thanks for taking a look! I have updated the changelog - does it look ok?

jenkins test this

@tobio looks like the tests were ok - is there anything else I need to do? 🙂

is there anything else I need to do?

Nope, this is great thanks!


[NEW ICON] swagger

Skill Name
swagger
Why?
So that we can demonstrate our skills more accurately by displaying these skills.
Reference Image

I created a new project since this project is no longer updating & the author left it, swagger is available skills-icons
https://skills-icons.vercel.app/api/icons?i=swagger