Add support for json logging format

Pull Request Motivation

Structured logging (JSON format) can be enabled.
Related issue: #2605
Kind

feature
Release Note

NONE

@malovme I think what we want to do is update our github.com/cert-manager/cert-manager/pkg/logs wrapper and use k8s.io/component-base/logs in that wrapper (see https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/migration-to-structured-logging.md and https://pkg.go.dev/k8s.io/component-base/logs for more info).
BTW: feel free to ask any remaining small questions via Slack

/ok-to-test

/kind feature

Great, I now have these options:

I think we have to use InfoS everywhere (see https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/migration-to-structured-logging.md) to make sure the json is better structured (see last line in example below).
$ _bin/server/controller-linux-amd64 --logging-format=json
{"ts":1678180968324.884,"caller":"clientcmd/client_config.go:618","msg":"Neither --kubeconfig nor --master was specified.  Using the inClusterConfig.  This might not work.\n","v":0}
{"ts":1678180968324.9226,"caller":"clientcmd/client_config.go:623","msg":"error creating inClusterConfig, falling back to default config: unable to load in-cluster configuration, KUBERNETES_SERVICE_HOST and KUBERNETES_SERVICE_PORT must be defined\n","v":0}
{"ts":1678180968325.4653,"caller":"./main.go:39","msg":"cert-manager \"msg\"=\"error while executing\" \"error\"=\"error creating rest config: invalid configuration: no configuration has been provided, try setting KUBERNETES_MASTER environment variable\" \n"}

I just tried --logging-format=json and it works fantastic! One tiny question: why is cert-manger/ prepended to every message? Example:
{"ts":1678458147099.5852,"caller":"controller/controller.go:174","msg":"cert-manager/orders: finished processing work item","v":4,"key":"default/cert-1-xhstw-3944277267"}

It seems redundant, no?

I just tried --logging-format=json and it works fantastic!
One tiny question: why is cert-manger/ prepended to every msg? Example:
{
  "ts":<PHONE_NUMBER>099.5852,
  "caller": "controller/controller.go:174",
  "msg": "cert-manager/orders: finished processing work item",
  "v": 4,
  "key": "default/cert-1-xhstw-3944277267"
}

It seems redundant, no? We already know that this is the cert-manager controller, I don't understand why cert-manager/ is prepended.

the prefix is coming since we use logger with name https://github.com/cert-manager/cert-manager/blob/6ba1dcaf4375b9526815a62af14872e68883a6b8/pkg/logs/logs.go#L38. I didn't thought if it is redundant or not but I guess we may keep it as it was for cases when logs from all components goes to same destination like common file or stderr

Agreed. We ought to first deprecate the flags and remove them in a later version of cert-manager 6 to 12 month after having deprecated it.
I suggest that we do not remove the line klog.InitFlags(fs) yet. We should also do something to warn people that these flags will be removed.
I'd suggest the following shedule:

cert-manager 1.12 (end of April 2023): start of the deprecation period for the flags --log_dir, --log_file, --log_flush_frequency, --logtostderr, --alsologtostderr, --one_output, --stderrthreshold, --log_file_max_size, --skip_log_headers, --add_dir_header, --skip_headers, --log_backtrace_at.
cert-manager 1.15 (approx 6 month afterwards, Nov 2023): removal of the flags.

I have re-added klog.InitFlags(fs). All the old flags are there, including --log-flush-frequency.
--- /tmp/before	2023-03-27 15:30:14.910373140 +0200
+++ /tmp/after	2023-03-27 15:30:24.878621161 +0200
@@ -54,10 +54,13 @@
       --leader-election-renew-deadline duration
       --leader-election-retry-period duration
       --log-flush-frequency duration
+      --log-json-info-buffer-size quantity
+      --log-json-split-stream
       --log_backtrace_at traceLocation
       --log_dir string
       --log_file string
       --log_file_max_size uint
+      --logging-format string
       --logtostderr
       --master string
       --max-concurrent-challenges int
@@ -69,4 +72,4 @@
       --skip_log_headers
       --stderrthreshold severity
   -v, --v Level
-      --vmodule moduleSpec
+      --vmodule pattern=N,...

I think the PR looks good to me now!
/approve

I have re-added klog.InitFlags(fs). All the old flags are there, including --log-flush-frequency.
--- /tmp/before	2023-03-27 15:30:14.910373140 +0200
+++ /tmp/after	2023-03-27 15:30:24.878621161 +0200
@@ -54,10 +54,13 @@
       --leader-election-renew-deadline duration
       --leader-election-retry-period duration
       --log-flush-frequency duration
+      --log-json-info-buffer-size quantity
+      --log-json-split-stream
       --log_backtrace_at traceLocation
       --log_dir string
       --log_file string
       --log_file_max_size uint
+      --logging-format string
       --logtostderr
       --master string
       --max-concurrent-challenges int
@@ -69,4 +72,4 @@
       --skip_log_headers
       --stderrthreshold severity
   -v, --v Level
-      --vmodule moduleSpec
+      --vmodule pattern=N,...

I think the PR looks good to me now!
/approve

@maelvls thanks for review. It makes sense to me to deprecate flags before removal, but this way with both klog.InitFlags and component-base logging AddFlags some flags are added twice and it cause error like panic:  flag redefined: v.

@malovme Ah, good catch. We can work around that by not adding v and vmodule when klog.InitFlags is run. I drafted a PR on your PR in https://github.com/malovme/cert-manager/pull/2. Please let me know what you think.

/retest

@malovme I created a patch for the make update-licenses target in this PR, can you check whether this command fixes the CI failure now?

/test pull-cert-manager-master-license

@inteon I've tried your make changes. It did go mod tidy but didn't fix e2e licences. Thank you for fixing them.

It all looks to me. The flag diff for the three binaries look OK.

Full diff
--- /tmp/controller-before	2023-04-14 10:48:37.379789260 +0200
+++ /tmp/controller-after	2023-04-14 10:48:40.351868899 +0200
@@ -56,10 +56,13 @@
       --leader-election-renew-deadline duration             The interval between attempts by the acting master to renew a leadership slot before it stops leading. This must be less than or equal to the lease duration. This is only applicable if leader election is enabled. (default 40s)
       --leader-election-retry-period duration               The duration the clients should wait between attempting acquisition and renewal of a leadership. This is only applicable if leader election is enabled. (default 15s)
       --log-flush-frequency duration                        Maximum number of seconds between log flushes (default 5s)
+      --log-json-info-buffer-size quantity                  [Alpha] In JSON format with split output streams, the info messages can be buffered for a while to increase performance. The default value of zero bytes disables buffering. The size can be specified as number of bytes (512), multiples of 1000 (1K), multiples of 1024 (2Ki), or powers of those (3M, 4G, 5Mi, 6Gi). Enable the LoggingAlphaOptions feature gate to use this.
+      --log-json-split-stream                               [Alpha] In JSON format, write error messages to stderr and info messages to stdout. The default is to write a single stream to stdout. Enable the LoggingAlphaOptions feature gate to use this.
       --log_backtrace_at traceLocation                      when logging hits line file:N, emit a stack trace (default :0)
       --log_dir string                                      If non-empty, write log files in this directory (no effect when -logtostderr=true)
       --log_file string                                     If non-empty, use this log file (no effect when -logtostderr=true)
       --log_file_max_size uint                              Defines the maximum size a log file can grow to (no effect when -logtostderr=true). Unit is megabytes. If the value is 0, the maximum file size is unlimited. (default 1800)
+      --logging-format string                               Sets the log format. Permitted formats: "json" (gated by LoggingBetaOptions), "text". (default "text")
       --logtostderr                                         log to standard error instead of files (default true)
       --master string                                       Optional apiserver host address to connect to. If not specified, autoconfiguration will be attempted.
       --max-concurrent-challenges int                       The maximum number of challenges that can be scheduled as 'processing' at once. (default 60)
@@ -71,4 +74,4 @@
       --skip_log_headers                                    If true, avoid headers when opening log files (no effect when -logtostderr=true)
       --stderrthreshold severity                            logs at or above this threshold go to stderr when writing to files and stderr (no effect when -logtostderr=true or -alsologtostderr=false) (default 2)
   -v, --v Level                                             number for the log level verbosity
-      --vmodule moduleSpec                                  comma-separated list of pattern=N settings for file-filtered logging
+      --vmodule pattern=N,...                               comma-separated list of pattern=N settings for file-filtered logging (only works for text log format)

--- /tmp/webhook-before	2023-04-14 10:48:42.067914885 +0200
+++ /tmp/webhook-after	2023-04-14 10:48:44.935991748 +0200
@@ -31,6 +31,10 @@
       --log-dir string                               If non-empty, write log files in this directory (no effect when -logtostderr=true)
       --log-file string                              If non-empty, use this log file (no effect when -logtostderr=true)
       --log-file-max-size uint                       Defines the maximum size a log file can grow to (no effect when -logtostderr=true). Unit is megabytes. If the value is 0, the maximum file size is unlimited. (default 1800)
+      --log-flush-frequency duration                 Maximum number of seconds between log flushes (default 5s)
+      --log-json-info-buffer-size quantity           [Alpha] In JSON format with split output streams, the info messages can be buffered for a while to increase performance. The default value of zero bytes disables buffering. The size can be specified as number of bytes (512), multiples of 1000 (1K), multiples of 1024 (2Ki), or powers of those (3M, 4G, 5Mi, 6Gi). Enable the LoggingAlphaOptions feature gate to use this.
+      --log-json-split-stream                        [Alpha] In JSON format, write error messages to stderr and info messages to stdout. The default is to write a single stream to stdout. Enable the LoggingAlphaOptions feature gate to use this.
+      --logging-format string                        Sets the log format. Permitted formats: "json" (gated by LoggingBetaOptions), "text". (default "text")
       --logtostderr                                  log to standard error instead of files (default true)
       --one-output                                   If true, only write logs to their native severity level (vs also writing to each lower severity level; no effect when -logtostderr=true)
       --profiler-address string                      Address of the Go profiler (pprof). This should never be exposed on a public interface. If this flag is not set, the profiler is not run. (default "localhost:6060")
@@ -43,4 +47,4 @@
       --tls-min-version string                       Minimum TLS version supported. Possible values: VersionTLS10, VersionTLS11, VersionTLS12, VersionTLS13
       --tls-private-key-file string                  path to the file containing the TLS private key to serve with
   -v, --v Level                                      number for the log level verbosity
-      --vmodule moduleSpec                           comma-separated list of pattern=N settings for file-filtered logging
+      --vmodule pattern=N,...                        comma-separated list of pattern=N settings for file-filtered logging (only works for text log format)

--- /tmp/cainjector-before	2023-04-14 10:48:46.104023051 +0200
+++ /tmp/cainjector-after	2023-04-14 10:48:48.196079122 +0200
@@ -24,10 +24,13 @@
       --leader-election-renew-deadline duration   The interval between attempts by the acting master to renew a leadership slot before it stops leading. This must be less than or equal to the lease duration. This is only applicable if leader election is enabled. (default 40s)
       --leader-election-retry-period duration     The duration the clients should wait between attempting acquisition and renewal of a leadership. This is only applicable if leader election is enabled. (default 15s)
       --log-flush-frequency duration              Maximum number of seconds between log flushes (default 5s)
+      --log-json-info-buffer-size quantity        [Alpha] In JSON format with split output streams, the info messages can be buffered for a while to increase performance. The default value of zero bytes disables buffering. The size can be specified as number of bytes (512), multiples of 1000 (1K), multiples of 1024 (2Ki), or powers of those (3M, 4G, 5Mi, 6Gi). Enable the LoggingAlphaOptions feature gate to use this.
+      --log-json-split-stream                     [Alpha] In JSON format, write error messages to stderr and info messages to stdout. The default is to write a single stream to stdout. Enable the LoggingAlphaOptions feature gate to use this.
       --log_backtrace_at traceLocation            when logging hits line file:N, emit a stack trace (default :0)
       --log_dir string                            If non-empty, write log files in this directory (no effect when -logtostderr=true)
       --log_file string                           If non-empty, use this log file (no effect when -logtostderr=true)
       --log_file_max_size uint                    Defines the maximum size a log file can grow to (no effect when -logtostderr=true). Unit is megabytes. If the value is 0, the maximum file size is unlimited. (default 1800)
+      --logging-format string                     Sets the log format. Permitted formats: "json" (gated by LoggingBetaOptions), "text". (default "text")
       --logtostderr                               log to standard error instead of files (default true)
       --namespace string                          If set, this limits the scope of cainjector to a single namespace. If set, cainjector will not update resources with certificates outside of the configured namespace.
       --one_output                                If true, only write logs to their native severity level (vs also writing to each lower severity level; no effect when -logtostderr=true)
@@ -36,5 +39,5 @@
       --skip_log_headers                          If true, avoid headers when opening log files (no effect when -logtostderr=true)
       --stderrthreshold severity                  logs at or above this threshold go to stderr when writing to files and stderr (no effect when -logtostderr=true or -alsologtostderr=false) (default 2)
   -v, --v Level                                   number for the log level verbosity
-      --vmodule moduleSpec                        comma-separated list of pattern=N settings for file-filtered logging
+      --vmodule pattern=N,...                     comma-separated list of pattern=N settings for file-filtered logging (only works for text log format)
       --watch-certificates                        Watch cert-manager.io Certificate resources as potential sources for CA data. Requires cert-manager.io Certificate CRD to be installed. It is not required to watch Certificates if you only use cainjector as cert-manager's internal components and in that case setting this flag to false might slightly reduce memory consumption. (default true)

My last interrogation is the "alpha" flags that got added. They both mention the feature gate LoggingAlphaOptions, but I don't think we have this feature flag in cert-manager. Is that correct?
+      --log-json-info-buffer-size quantity        [Alpha] In JSON format with split output streams, the info messages can be buffered for a while to increase performance. The default value of zero bytes disables buffering. The size can be specified as number of bytes (512), multiples of 1000 (1K), multiples of 1024 (2Ki), or powers of those (3M, 4G, 5Mi, 6Gi). Enable the LoggingAlphaOptions feature gate to use this.
+      --log-json-split-stream                     [Alpha] In JSON format, write error messages to stderr and info messages to stdout. The default is to write a single stream to stdout. Enable the LoggingAlphaOptions feature gate to use this.

🎯 Release 1.12: We will have a code freeze for 1.12 starting Wed 19 April 2023. The code freeze will be waived after the release of 1.12 on Wed 26 April 2023. Let's aim to merge this PR before Wednesday 😅

I propose that we stick to Kubernetes' LoggingAlphaOptions and LoggingBetaOptions. It isn't perfect and adds more noise, but since we are relying on k8s.io/component-base/logs, it make sense to also adopt these feature gates.
@malovme I wrote a quick PR to add the feature gates: https://github.com/malovme/cert-manager/pull/3/files

🎯 Release 1.12: We will have a code freeze for 1.12 starting Wed 19 April 2023. The code freeze will be waived after the release of 1.12 on Wed 26 April 2023. Let's aim to merge this PR before Wednesday 😅

Release has been delayed, so I think we can still merge this PR.

Thank you @malovme for the PR, I added a few remaining fixes (removed the Alpha flags & added flags to acmesolver).
Now the diffs look like this:

cert-manager-controller
--- /dev/fd/63  2023-04-27 19:51:16.509324110 +0200
+++ /dev/fd/62  2023-04-27 19:51:16.509324110 +0200
@@ -9,7 +9,7 @@
   cert-manager-controller [flags]

 Flags:
-      --acme-http01-solver-image string                     The docker image to use to solve ACME HTTP01 challenges. You most likely will not need to change this parameter unless you are testing a new feature or developing cert-manager. (default "quay.io/jetstack/cert-manager-acmesolver:v1.12.0-beta.0-30-geafe0d0aae4b7a")
+      --acme-http01-solver-image string                     The docker image to use to solve ACME HTTP01 challenges. You most likely will not need to change this parameter unless you are testing a new feature or developing cert-manager. (default "quay.io/jetstack/cert-manager-acmesolver:v1.12.0-beta.0-32-g2a4e518794d141")
       --acme-http01-solver-nameservers strings              A list of comma separated dns server endpoints used for ACME HTTP01 check requests. This should be a list containing host and port, for example <IP_ADDRESS>:53,<IP_ADDRESS>:53
       --acme-http01-solver-resource-limits-cpu string       Defines the resource limits CPU size when spawning new ACME HTTP01 challenge solver pods. (default "100m")
       --acme-http01-solver-resource-limits-memory string    Defines the resource limits Memory size when spawning new ACME HTTP01 challenge solver pods. (default "64Mi")
@@ -62,6 +62,7 @@
       --log_dir string                                      If non-empty, write log files in this directory (no effect when -logtostderr=true)
       --log_file string                                     If non-empty, use this log file (no effect when -logtostderr=true)
       --log_file_max_size uint                              Defines the maximum size a log file can grow to (no effect when -logtostderr=true). Unit is megabytes. If the value is 0, the maximum file size is unlimited. (default 1800)
+      --logging-format string                               Sets the log format. Permitted formats: "json" (gated by LoggingBetaOptions), "text". (default "text")
       --logtostderr                                         log to standard error instead of files (default true)
       --master string                                       Optional apiserver host address to connect to. If not specified, autoconfiguration will be attempted.
       --max-concurrent-challenges int                       The maximum number of challenges that can be scheduled as 'processing' at once. (default 60)
@@ -73,4 +74,4 @@
       --skip_log_headers                                    If true, avoid headers when opening log files (no effect when -logtostderr=true)
       --stderrthreshold severity                            logs at or above this threshold go to stderr when writing to files and stderr (no effect when -logtostderr=true or -alsologtostderr=false) (default 2)
   -v, --v Level                                             number for the log level verbosity
-      --vmodule moduleSpec                                  comma-separated list of pattern=N settings for file-filtered logging
+      --vmodule pattern=N,...                               comma-separated list of pattern=N settings for file-filtered logging (only works for text log format)

acmesolver
--- /dev/fd/63  2023-04-27 19:51:16.557323850 +0200
+++ /dev/fd/62  2023-04-27 19:51:16.557323850 +0200
@@ -4,8 +4,23 @@
   acmesolver [flags]

 Flags:
-      --domain string     the domain name to verify
-  -h, --help              help for acmesolver
-      --key string        the challenge key to respond with
-      --listen-port int   the port number to listen on for connections (default 8089)
-      --token string      the challenge token to verify against
+      --add_dir_header                   If true, adds the file directory to the header of the log messages
+      --alsologtostderr                  log to standard error as well as files (no effect when -logtostderr=true)
+      --domain string                    the domain name to verify
+  -h, --help                             help for acmesolver
+      --key string                       the challenge key to respond with
+      --listen-port int                  the port number to listen on for connections (default 8089)
+      --log-flush-frequency duration     Maximum number of seconds between log flushes
+      --log_backtrace_at traceLocation   when logging hits line file:N, emit a stack trace (default :0)
+      --log_dir string                   If non-empty, write log files in this directory (no effect when -logtostderr=true)
+      --log_file string                  If non-empty, use this log file (no effect when -logtostderr=true)
+      --log_file_max_size uint           Defines the maximum size a log file can grow to (no effect when -logtostderr=true). Unit is megabytes. If the value is 0, the maximum file size is unlimited. (default 1800)
+      --logging-format string            Sets the log format. Permitted formats: "text".
+      --logtostderr                      log to standard error instead of files (default true)
+      --one_output                       If true, only write logs to their native severity level (vs also writing to each lower severity level; no effect when -logtostderr=true)
+      --skip_headers                     If true, avoid header prefixes in the log messages
+      --skip_log_headers                 If true, avoid headers when opening log files (no effect when -logtostderr=true)
+      --stderrthreshold severity         logs at or above this threshold go to stderr when writing to files and stderr (no effect when -logtostderr=true or -alsologtostderr=false) (default 2)
+      --token string                     the challenge token to verify against
+  -v, --v Level                          number for the log level verbosity
+      --vmodule pattern=N,...            comma-separated list of pattern=N settings for file-filtered logging (only works for text log format)

webhook
--- /dev/fd/63  2023-04-27 19:51:16.573323764 +0200
+++ /dev/fd/62  2023-04-27 19:51:16.573323764 +0200
@@ -1,4 +1,4 @@
-Webhook component providing API validation, mutation and conversion functionality for cert-manager (v1.12.0-beta.0-30-geafe0d0aae4b7a) (eafe0d0aae4b7a9411825424f6b43fb623e1ba65)
+Webhook component providing API validation, mutation and conversion functionality for cert-manager (v1.12.0-beta.0-32-g2a4e518794d141) (2a4e518794d141f2140394ab17b86446bd41ba2e)

 Usage:
   webhook [flags]
@@ -31,6 +31,8 @@
       --log-dir string                               If non-empty, write log files in this directory (no effect when -logtostderr=true)
       --log-file string                              If non-empty, use this log file (no effect when -logtostderr=true)
       --log-file-max-size uint                       Defines the maximum size a log file can grow to (no effect when -logtostderr=true). Unit is megabytes. If the value is 0, the maximum file size is unlimited. (default 1800)
+      --log-flush-frequency duration                 Maximum number of seconds between log flushes (default 5s)
+      --logging-format string                        Sets the log format. Permitted formats: "json" (gated by LoggingBetaOptions), "text". (default "text")
       --logtostderr                                  log to standard error instead of files (default true)
       --one-output                                   If true, only write logs to their native severity level (vs also writing to each lower severity level; no effect when -logtostderr=true)
       --profiler-address string                      Address of the Go profiler (pprof). This should never be exposed on a public interface. If this flag is not set, the profiler is not run. (default "localhost:6060")
@@ -43,4 +45,4 @@
       --tls-min-version string                       Minimum TLS version supported. Possible values: VersionTLS10, VersionTLS11, VersionTLS12, VersionTLS13
       --tls-private-key-file string                  path to the file containing the TLS private key to serve with
   -v, --v Level                                      number for the log level verbosity
-      --vmodule moduleSpec                           comma-separated list of pattern=N settings for file-filtered logging
+      --vmodule pattern=N,...                        comma-separated list of pattern=N settings for file-filtered logging (only works for text log format)

cainjector
--- /dev/fd/63  2023-04-27 19:51:16.585323700 +0200
+++ /dev/fd/62  2023-04-27 19:51:16.585323700 +0200
@@ -33,6 +33,7 @@
       --log_dir string                                      If non-empty, write log files in this directory (no effect when -logtostderr=true)
       --log_file string                                     If non-empty, use this log file (no effect when -logtostderr=true)
       --log_file_max_size uint                              Defines the maximum size a log file can grow to (no effect when -logtostderr=true). Unit is megabytes. If the value is 0, the maximum file size is unlimited. (default 1800)
+      --logging-format string                               Sets the log format. Permitted formats: "json" (gated by LoggingBetaOptions), "text". (default "text")
       --logtostderr                                         log to standard error instead of files (default true)
       --namespace string                                    If set, this limits the scope of cainjector to a single namespace. If set, cainjector will not update resources with certificates outside of the configured namespace.
       --one_output                                          If true, only write logs to their native severity level (vs also writing to each lower severity level; no effect when -logtostderr=true)
@@ -41,4 +42,4 @@
       --skip_log_headers                                    If true, avoid headers when opening log files (no effect when -logtostderr=true)
       --stderrthreshold severity                            logs at or above this threshold go to stderr when writing to files and stderr (no effect when -logtostderr=true or -alsologtostderr=false) (default 2)
   -v, --v Level                                             number for the log level verbosity
-      --vmodule moduleSpec                                  comma-separated list of pattern=N settings for file-filtered logging
+      --vmodule pattern=N,...                               comma-separated list of pattern=N settings for file-filtered logging (only works for text log format)

The PR is now ready to be merged.
/approve

/retest

/retest

/retest

@inteon thanks for pushing on this!

@inteon thanks for pushing on this!

np, should be ready to be merged now that tests are successful.

@maelvls I updated the PR with the requested changes, could you take a look?

Why do need to add all those new flags to acmesolver? I understand that adding -v to the acmesolver makes things more consistant, but I don't see the use-case. I can't see why someone would like to use -v in the first place. IMO, acmesolver should log in debug mode at all times since the only thing it logs is the incoming HTTP requests.
Furthermore, people have no way to configure the acmesolver with the new flags. It makes little sense to add all these new flags when people can't use them.
Could you move the acmesolver changes to a new PR?

Why do need to add all those new flags to acmesolver? I understand that adding -v to the acmesolver makes things more consistant, but I don't see the use-case. I can't see why someone would like to use -v in the first place. IMO, acmesolver should log in debug mode at all times since the only thing it logs is the incoming HTTP requests.
Furthermore, people have no way to configure the acmesolver with the new flags. It makes little sense to add all these new flags when people can't use them.
Could you move the acmesolver changes to a new PR?

I removed the flags from acmesolver.


AmazonCloudWatchLogsClient.GetLogEvents does not return any event

Describe the bug
I use the following code to retrieve LogEvents from CloudWatch (shortened for brevity):
var request = new GetLogEventsRequest
{
	LogGroupName = <valid log group name>,
	LogStreamName = <valid log stream name>
};

var response = await amazonCloudWatchLogsClient.GetLogEventsAsync(request);

response.Events.ForEach(t =>
{
    Console.Write ($"{t.Timestamp}: {t.Message}");
});

However, response.Events always contains 0 items. And despite response.NextForwardToken being non-empty, the request never returns any events and may be repeated forever. And I know the connection works and the log stream name is valid, because the name comes from an enumeration of log streams done just before. And the log steam contains events since I can see them in CloudWatch console.
Expected Behavior
The returned response contains a reasonable number of events together with a non-null NextForwardToken if more events are available or NextForwardToken being null if there are no more events to be retrieved.
Current Behavior
In the returned response, the Events collection contains 0 elements and the NextForwardToken is set. Repeating the request with NextToken set returns 0 events again.
Reproduction Steps
See code sample above
Possible Solution
No response
Additional Information/Context
No response
AWS .NET SDK and/or Package version used
AWSSDK.CloudWatchLogs 3.7.304.8
Targeted .NET Platform
.NET 8
Operating System and version
Windows 10

Yes, setting StartFromHead to true does the Trick! So this means we can only get events in ascending order (oldest first). But I still get several results with 0 events before NextForwardToken equals the previous token.
It would be nice if StartFromHead would work as described and NextForwardToken was set to null upon delivery of the last chunk of events (to avoid unnecessary roundtrips).

@gerdb42 If tailing a log is what you want, CloudWatchLogs added a StartLiveTail API recently, and there is an example of how to configure it here. I helped write the example so I know that the code in there works. It might feel more natural than the current API you're using.
Example in docs

Today's release of the AWSSDK.CloudWatchLogs package (3.7.305.24) includes a fix so that the SDK built-in paginator works as expected with this API. That means you can use the following snippet (instead of the example I sent earlier):
var logs = new AmazonCloudWatchLogsClient();
var getLogsRequest = new GetLogEventsRequest
{
    LogGroupName = "my-log-group",
    LogStreamName = "my-log-stream",
    StartFromHead = true,
};

var paginator = logs.Paginators.GetLogEvents(getLogsRequest);
await foreach (var logEvent in paginator.Events)
{
   Console.WriteLine(logEvent.Message);
}

And as Peter suggested, check out the StartLiveTail API as it may be more applicable to your use case.


From QUEUE page, attempts to contact requester fail on Submit.

Issue summary
From QUEUE page, attempts to contact requester fail on Submit. (havent tested the other pages since your recent update)
Malformed message
Your message subject or body is missing or exceeds the maximum length. Please revise and try submitting your message again.
Expected behavior
Well.. it should say the request was successful, and send me to Mturks HIT page.
Actual behavior
Error Message:
Malformed message
Your message subject or body is missing or exceeds the maximum length. Please revise and try submitting your message again.
http://prntscr.com/je45tr
I contacted Amazon about this before, and after 2 weeks said they had researched it, and that Mturk Engine was the cause. (I can contact requester successfully from normal Mturk pages)
http://prntscr.com/je46tq
Steps to Reproduce the Problem

Have a HIT in queue
Try to contact requester from the drop down menu
Type in a short test message
Submit

Specifications

Mturk Engine version: 1.7.0
Browser: Version 66.0.3359.139 (Official Build) (64-bit)

Some additional info. Here are the two URLs generated by Mturk, and Mturk Engine, for the same requester and HIT and the QUEUE:
Yours:
https://worker.mturk.com/contact_requester/assignment_messages/new?assignment_id=3E1QT0TDFP9GLW3VZML6OS6G066I8T&hit_type_message[hit_description]=Investigate what is happening in the video from the beginning to the end%2C ear up to %240.75 when you complete the HIT&hit_type_message[hit_title]=Chat about what is happening in the video. ** Earn up to %240.75 per HIT **&hit_type_message[hit_type_id]=32RJU5X1ZP9V6DK4741DB803V5RVD2&hit_type_message[requester_id]=A1CEBF7WRZ74YK&hit_type_message[requester_name]=Research Tasks&hit_type_message[subject]=Regarding Amazon Mechanical Turk Project (HIT Type) 32RJU5X1ZP9V6DK4741DB803V5RVD2
Mturks:
https://worker.mturk.com/contact_requester/assignment_messages/new?assignment_message[assignment_id]=3VSOLARPKB919Y4MJBKXKIZ20Z393U&assignment_message[subject]=Regarding+Amazon+Mechanical+Turk+HIT+3UL5XDRDNCJ1MOAM2ZXABZ6N2KU85Q&completed_date=2018-04-26&hit_id=3UL5XDRDNCJ1MOAM2ZXABZ6N2KU85Q&requester_id=A1CEBF7WRZ74YK&requester_name=Research+Tasks&title=Chat+about+what+is+happening+in+the+video.+**+Earn+up+to+%240.75+per+HIT+**
On the ACCOUNT page, when I lookup a completed HIT, the format is more in line with Mturks.
There are times I really want to complain to a requester about his HIT time lengths, broken content, or other things from the Queue (before it refreshes and disappears)

This fix just shipped with 1.8.0. Feel free to reopen this issue if it persists after updating.


Django 1.11 compatibility

Django 1.11 has changed Widget.build_attrs and now it doesn't accept kwargs, so some adjustments need to be made in order to make them compatible with this version.
Also, when rendering a response for a test, it adds additional new lines and whitespaces, so this test failed. All these additional characters were removed from the response and now all tests pass for current master.
Tested with django 1.8 to 1.11

Coverage increased (+0.05%) to 87.366% when pulling 4728d2ed42494fe9628d15db88147f4fbe69dd7e on vborras:django-11-compatibility into 8c9b5dc2cef34179b77ddd306e58320056737afb on digi604:master.

Coverage increased (+0.05%) to 87.366% when pulling 3d8f777bd0cfab255c29f2f86f019b877754208f on vborras:django-11-compatibility into 8c9b5dc2cef34179b77ddd306e58320056737afb on digi604:master.

Coverage increased (+0.05%) to 87.366% when pulling 40bdf701527d8a6bdd2d4159b953f883e3d36424 on vborras:django-11-compatibility into 8c9b5dc2cef34179b77ddd306e58320056737afb on digi604:master.

Coverage increased (+0.05%) to 87.366% when pulling 0161706b91f7508c1f0040e072f7f79949ae6140 on vborras:django-11-compatibility into 8c9b5dc2cef34179b77ddd306e58320056737afb on digi604:master.

Coverage increased (+0.05%) to 87.366% when pulling 0161706b91f7508c1f0040e072f7f79949ae6140 on vborras:django-11-compatibility into 8c9b5dc2cef34179b77ddd306e58320056737afb on digi604:master.

Coverage increased (+0.05%) to 87.366% when pulling 0161706b91f7508c1f0040e072f7f79949ae6140 on vborras:django-11-compatibility into 8c9b5dc2cef34179b77ddd306e58320056737afb on digi604:master.

Coverage increased (+0.05%) to 87.366% when pulling 0161706b91f7508c1f0040e072f7f79949ae6140 on vborras:django-11-compatibility into 8c9b5dc2cef34179b77ddd306e58320056737afb on digi604:master.

Coverage increased (+0.05%) to 87.366% when pulling 0161706b91f7508c1f0040e072f7f79949ae6140 on vborras:django-11-compatibility into 8c9b5dc2cef34179b77ddd306e58320056737afb on digi604:master.

Coverage increased (+0.05%) to 87.366% when pulling 0161706b91f7508c1f0040e072f7f79949ae6140 on vborras:django-11-compatibility into 8c9b5dc2cef34179b77ddd306e58320056737afb on digi604:master.

Coverage increased (+0.05%) to 87.366% when pulling 0161706b91f7508c1f0040e072f7f79949ae6140 on vborras:django-11-compatibility into 8c9b5dc2cef34179b77ddd306e58320056737afb on digi604:master.


Unnecessary escaping of strings

According to RFC4627[ https://www.rfc-editor.org/rfc/rfc4627#section-2.5 ], strings do not need escaping except for some prohibited characters.
However, cjson.ahk seems to escape all characters except US-ASCII. This replaces my native language with numbers and eliminates the readability and versatility of JSON.
If you feel up to it, I would appreciate it if you could create a switch to work around this.

This has been supported since January 2022: 9b01c6e384e4855637cf17893b3c4feefb94afe7


issue with SQL set command

Describe the bug
set variable = value; causes a java run time error
To Reproduce
Steps to reproduce the behavior:

Connect to SQL JOB MANAGER
Open any edit tab and make sure language is SQL
Create a variable if one does not exist to update, like create or replace variable myvarible char(10);
Key a set command like set myvariable = 'ME';
java error appears in IBM i: Results output channel.

Expected behavior
Statement is run to completion.
Screenshots

Environment

OS: Windows 10.0
Extension Version 0.3.2

Additional context
This is a high priority for me.

Does the latest build you downloaded (from my comment in #82) fix this issue?
(Sorry, I commented on the wrong issue, and meant to comment here rather than #82)

I had some troubles for some reason.  I reset the extension back, restarted VSC, connected, opened a SQL JOB, and tried again to get the problem (I did).  Then I loaded the version you passed on to me and restarted VSC.  I was able to run the sets commands successfully.


Not compatible with Swift 3.0

Try this in your pod:
pod 'DKImagePickerController', :git => 'https://github.com/zhangao0086/DKImagePickerController.git', :branch => 'master'

This did work. Thanks. 👍
You should mention this on installation process. I installed as just pod 'DKImagePickerController' and it gave my app a cancer! :|


Fix waymo messages.

This was a simple fix for a logging issue that was bugging me.

@sah-huawei, sorry, force of habit.


Bulk User Creation

Just wanted to flag that your super-useful script for bulk user creation -  openvpn-useradd-bulk.sh - is returning multiple errors when run after installing OpenVPN server with the latest script. It looks like some directory locations have changed since the time this script was created.
I understand you made it as a one-off deal and are not maintaining it actively. While I've already created new users individually, I was hoping that you might be able to tweak your script at some point - perhaps even make it do double duty for bulk user creation for either OpenVPN or WireGuard installs? Given it's utility, I'm sure it will be deeply appreciated by your user base, as it's a huge time saver for multi user setup on a new server.
Thank you!

I hope your problem is already gone.
I'm writing this just for the records, should it solve anyone else's problem.
The attached file is tested on a Debian 9 (stretch) and can add multiple users at once by providing a list containing the usernames (splitted by newlines).
FYI: As I reckon there is no systematic versioning schema in this repo, openvpn-install.sh script was downloaded on Dec 17, 2020.
openvpn-useradd-bulk.sh.txt

Just spun up a nw VPN server for the 2023-24 academic year using Nyr's incomparable script. Used @dozham script to attempt creating 40+ users in bulk but each the script now requires manual intervention "Type the word 'yes' to continue, or any other input to abort" and in it's absence it aborts without confirmation. See full error below:
Notice------Keypair and certificate request completed. Your files are:.reqq: /etc/openvpn/server/easy-rsa/pki/reqs/SM-MBP-USVPN.key : /etc/openvpn/server/easy-rsa/pki/private/SM-MBP-USVPN
You are about to sign the following certificate.Please check over the details shown below for accuracy. Note that this requesthas not been cryptographically verified. Please be sure it came from a trustedsource or that you have verified the request checksum with the sender.
Request subject, to be signed as a client certificate for '825' days:
subject=    commonName                = SM-MBP-USVPN
Type the word 'yes' to continue, or any other input to abort.  Confirm request details:
Notice------Aborting without confirmation.
.crt: No such file or directoryrver/easy-rsa/pki/issued/SM-MBP-USVPNcat: '/etc/openvpn/server/easy-rsa/pki/private/SM-MBP-USVPN'$'\r''.key': No such file or directory
.ovpnd, configuration is available at /root/SM-MBP-USVPN
Any chance you might have pointers on how to fix this? Not looking forward to creating so many users manually.
Thank you SO much for cosidering...

The reason the script does not work is because the author forgot to use Easy-RSA --batch mode.

@TinCanTech Thank you for the update.
As I'm a newbie at shell scripts, any chance you can update it with the corrections so it can be fed a list of users, one per line, to create them in batch mode?

@wicknet Please report the issue to the correct repository.


inventory item definitions fail to parse tags

hey morphan
i'm looking at you morphanone
definitions:
fancy_item: <proc[fancy_item]context.[bananas]>
it just doesn't work
neither does
slots:

[<proc[fancy_item]context.[bananas]>] [] [] [] [] [] [] [] []

it just doesn't do the procedure
i tried using flags
it didn't do it either
morphanone
could you please make it do that
please
thanks
amen

also when going from any script to an inventory script (to an item script) to a procedure script it loses the player linked! :(

@Morphan1 ?

@Morphan1 ??!!??!

@mcmonkey4eva I don't know what's happening here. The tags he specified aren't even valid. But besides that, the code for tags definitely exists.

Lmao he has a stray . on his tags. Nice job @BlackCoyote
Feel free to comment below if you can replicate this with valid input, and we'll reopen.

i've spent my time finding a workaround for this so theres no point in me reopening this, but besides this example i did try it in different tags including flags.. once again, no point for me to reopen, but if i encounter it again i'll let you know

@BlackCoyote for what it's worth, this issue should be resolved and your workarounds are now nil


Address hangs in tls connect when the handshaking is interrupted.

Observed when the transport destination is shutdown during the SSL_connect.
resolves #665

@jrcheli Looks good to me. I was able to reproduce the original issue on master branch using the instruction from: https://github.com/criblio/appscope/issues/665#issuecomment-1101784339
Using the same scenario on branch presented in this Pull Request I did not saw hanging application, which confirms the fix.


add dot products and precomputed norms to CEuclideanDistance

w.r.t discussion in #2987 .

distance computed using dot products as  dist(x, y) = sqrt(dot(x, x) - 2 * dot(x, y) + dot(y, y))
precompute lhs and rhs squared norms
unit tests

Updated to remove the bools.
Also @karlnapf I did check there is no way to know for sure when rhs/lhs is modified. replace_rhs( ) only changes the CFeature object. but we cannot know when its feature matrix is modified , as is happening in KMeans too. So we may have to rely on public precompute only to compute new norms.

Ok I see, you are right. I still am unsure whether this addition is really a good idea as people might forget about it and then get wrong results without a warning or an error.
The final option I see is to add a method to compute pairwise distances for all features rhs/lhs. In this case, we can definitely precompute the norms internally. I think this would also fit into KMeans wouldnt it?
You can use subsets on the features to specify which indices you want to use.
Let me know what you think about that!

Yes that could lead to problems if people forget to do it right actually.
computing pairwise distance for all is good idea but then we have to store extra  numofsamples*numofcenters size matrix per iteration
The way scikit do it is:

have percomute_distance argument which if true and numofsamples*numofcenters < some number (so not too much memeory used) they will store all pairwise distances in matrix.
They actually let the user compute norms externally and pass them as arguments. This norms are then used to compute multipe pairwise distances.

I think we can have a function to compute multiple distances (which could compute single pairwise distance too if only 2 indices passed as args). We can use user calculated norms passed as arguments so things dont go wrong.

Storing this matrix is a bad idea indeed.
I think let's maybe keep it as it is now, no need to let users pass things ...
But make sure to add reset() calls in all places where the features do get changed, to avoid problems described above.

Good to merge apart from the minors. Can you also squash all this into a single commit?

Done. btw does travis still check integration tests ? :)

Nope, we disabled them. Soon to be replaced though

No, dont bother

travis is fine, merging

hmm  - http://buildbot.shogun-toolbox.org/builders/precise - libshogun/builds/1140/steps/compile/logs/stdio . Is this because of  guards for linalg ?

yes, please fix this soon
Also will make some minor comments above

Thanks for the comments
well the options are straight forward, i will summarize again:

we handle precompute in distance class: No way to know when feature matrix changes. hence cant automatically reset. User has to reset precomputations

let user pass precomputed norms: user has to reset here too.

or calculate mutiple distance pairs : only in this case can we precompute and reset safely.

But this comes at a cost:
have to store a results in a matrix
some unnnecessary computations if only one feature side is changing.

Let us take option 1, reset the norms whenever we know that the distance is changed (we know often), add a warning for the cases we dont know


Feature windows install

Added support for windows installation
Still far from perfect, but updated the documentation to indicate what needs
to be done to at least have a shot at this working.
Setup.py now explicitly checks what OS it is running on, and in case of windows
sets the location of embree to the standard install location.
Sorry, I am not aware of/could not get a more generic command line option which
adds to the library path to work, so this was ultimately what let me install
pyemblite on windows machines.
A weird quirk is that this only worked for me in the conda base environment, not
sure why it would fail in other environments...

For MS Build Tools looks like you can set environment variables to point to libraries/headers:
set INCLUDE="C:\Path\to\embree\include\dir:%INCLUDE%"
set LIB="C:\Path\to\embree\lib\dir:%LIB%"
python setup.py build

?

You are of course right. How about just updating the readme then?


I failed to download the dataset, how should I resolve the voice

I failed to download the dataset, how should I resolve the voice

You can try with any voice dataset. Currently Im testing with my one recorded voice.


wallet desktop redesign

Now I'm curious about this

@alexvandesande Just minor cosmetic changes, nothing very different from what you already seen :)


SchemaBuilder Per Connection Grammar

Summary
The Laravel Framework added some new methods (ie: getIndexes(), getColumns()) to the Schema Builder, and in order to do so, they needed to break out the Schema Builder implementations per Database Connection Grammar.
As a result, we also need to provide a Grammar specific set of SnapshotSchemaBuilders in order to expose the new methods add in Laravel.
This should be a non breaking change, as the service container bindings should still resolve to the old base builder if the new framework builder classes aren't there.
Tests

Covered with auto tests

Closes #24
Closes #26


[BUG] support casts of decimal to numeric

This is something that @ttnghia found while working on tests for https://github.com/NVIDIA/spark-rapids/pull/3373, it looks like we cannot cast from decimal to other types (like Double) in his case:
scala> df.printSchema
root
 |-- value: decimal(5,1) (nullable = true)

scala> spark.sql("select cast(value as float) from foo").explain
21/09/22 20:56:49 WARN GpuOverrides:
!Exec <ProjectExec> cannot run on GPU because not all expressions can be replaced
  @Expression <Alias> cast(value#0 as float) AS value#4 could run on GPU
    !Expression <Cast> cast(value#0 as float) cannot run on GPU because Cast from DecimalType(5,1) to FloatType is not supported
      @Expression <AttributeReference> value#0 could run on GPU
  *Exec <FileSourceScanExec> will run on GPU

== Physical Plan ==
*(1) Project [cast(value#0 as float) AS value#4]
+- GpuColumnarToRow false
   +- GpuFileGpuScan parquet [value#0] Batched: true, DataFilters: [], Format: Parquet, Location: InMemoryFileIndex[file:/tmp/abellina], PartitionFilters: [], PushedFilters: [], ReadSchema: struct<value:decimal(5,1)>

I am not entirely sure what types we want to enable, and we also need to add tests as suggested by @revans2

I am seeing failures when casting from Decimal(7,-3) to LongType.  That appears to be a bug in cudf, but there is no time to fix this in 12.10, so I will get a repro case and file the issue, but in the short term I think we have to not cast negative scale decimals.  Note that this appears to only be an issue when going to longs, and really just for scales up to 9.  It looks like the conversion is happening in 32-bit mode and then cast to 64-bits at the end, which does not really work.


Fixed broken AWS Pipelines link for 1.3 docs branch

Fixed relative link to new AWS Pipelines page

/approve

@judyheflin can we point to the relevant section as well?

Added

@judyheflin can we point to the relevant section as well?

Added

/approve

/approve

@Arhell can you take a look, same as #3176

@Arhell can you take a look, same as #3176

@Arhell @Ark-kun review please, thanks

/lgtm
/approve

@Arhell please merge this PR

@Arhell PR is ready to merge

https://github.com/kubeflow/website/pull/3188#issuecomment-1064502539

@Bobgy, @IronPan, @neuromage, @chensun can one of you approve this tiny PR?

/approve

@Bobgy, @IronPan, @neuromage, @Ark-kun, @numerology can one of you approve this tiny PR?

@Bobgy, @IronPan, @neuromage, @Ark-kun, @numerology can one of you approve this tiny PR?


question about using  the HTTP1.1  to send a single segment object in JSON format

Please answer these questions before submitting your issue.

Why do you submit this issue?
[*] Question or discussion
[ ] Bug
[ ] Requirement
[ ] Feature or performance improvement

Question

What do you want to know?
SW version : 8.6.0
HI  ,  I want to send a single segment object in JSON format  to the  OAP follows the document. However when I use postman to post the data  the UI only shows the ServiceName，the uploaded segment is not shown in the trace.   Did I  miss something？thanks in advance
(https://skywalking.apache.org/docs/main/v8.6.0/en/protocols/http-api-protocol/#post-httplocalhost12800v3segment)

If you are playing protocol, read the source codes. This is a very advanced integration.

ok, thanks for your reply


Allow to suppress StringLiteralDuplication on class level - closes #442

Closes # 442

Probably worth to write Fixes #442 in the description so it gets auto closed.

I think closes in the title works too. Have both now :)

Although it seems like you're having a white space too much there. # 442


proposal: spec: various changes to :=

This code is subtly wrong:

func f() (err os.Error) {
  v, err := g();
  if err != nil {
    return;
  }
  if v {
    v, err := h();
    if err != nil {
      return;
    }
  }
}

The := in the if statement causes a new err variable that shadows the
return parameter.

Maybe doing this should be an error. Maybe return parameters should be
special so that := doesn't ever shadow them. (I like the latter.)

Moving priority-someday to the Unplanned milestone.

Summarizing the discussion.
The original problem report was fixed before the Go 1 release by https://golang.org/cl/5245056.  That code (if updated to current syntax) now gets an error at compilation time: err is shadowed during return.
Suggestions made in this issue and its duplicates:

Don't permit shadowing variables in general.
Don't permit shadowing variables declared in the same function (but do permit shadowing global variables).
Allow arbitrary expressions on the left hand side of :=, treating them as though they appeared on the left hand side of =.
Don't require a new variable declaration on the left hand side of :=.
Permit declaring new variables using =, but require at least one of the variables to already exist.
Use  a per-variable syntax with := to indicate which variables are being declared.

Put a : before each variable being declared.
Use (var v) for each variable being declared.

Don't use an implicit block for := declares in if, for, switch, since the lack of a { makes them seem to be in the outer block.

FWIW, my suggestion:

Permit shadowing with var but not with :=.

Another possibility that may have been mentioned elsewhere:
Currently := permits redeclaring variables that were declared earlier in the same block, as long as at least one of the variables is new.  We could change that so that := redeclares variables declared earlier in the same block or in any surrounding block within the same function, as long as at least one of the variables is new.

Somewhat related to #20802.

I am new to Go; please disregard this feedback if it isn't helpful.  The problem, as I see it, is that the behavior of := is overly subtle.  Maybe when := was first invented, that was in a simpler context, and it might have been very elegant.  But with redeclaration, multiple assignment, and scoping/shadowing effects, it can be unclear what is going on.  Again, I am a Go-newbie and am still learning the language, but this is my memory of the problem from several months ago when I looked at it.  Also, in reading the proposals above, I hope that changes to := (if any) will make the language simpler rather than more complicated.

I'm a supporter of the colon-prefix syntax proposed above, for example :n, err = f()
@ianlancetaylor has mentioned a per-variable syntax in his summary, but the one I'm talking about is to be used with =, not :=. That is to say, this kind of short declaration would be just a special L-value on the left side of a normal assignment.
I think it could be also fully backward compatible.
Some time ago I wrote a hackish code rewriter for this syntax, and I would be glad if anyone wants to try it out to get a feel of the syntax.
If you do, please read the caveats in the README file that I just jotted down (sorry, I wish I had more time), and keep in mind that I'm publishing this only as a demonstration for this issue.
https://github.com/pam4/gooey
I've used this syntax for some time now, and I find it easier to read and to write, specially in cases similar to the examples reported here and in related issues.

Just got caught by this while using filepath.Walk with an anonymous function, because Walk returns an error and the anonymous function has to accept an error, and they're not the same error.

More generally, I would like to make the argument for the need for a per-variable short declaration syntax.
When you assign to some variables you have a specific intention (for example "I want a new instance of x, and I want to use the existing instance of y").
It would be very beneficial to be able to express such intention right there, in the statement you are writing, but with multi-variable/tuple assignment this cannot be accomplished with a per-statement switch (= / :=), no matter what magic you put into it.
A per-variable short declaration syntax can be nearly as terse as a := declaration but would allow finer control, would be more informative, and the compiler would be able to catch more errors.
Multi-variable := can confuse people reading code (and not only beginners); several examples have been reported.
While writing, it happens to be forced to give up a short declaration because := wouldn't do what you want, or worse but fortunately not so common, you may get confused about where the block boundary is, and end up with a hard to find bug.
We've seen many seemingly unrelated variations of this issue and I think they are all just addressing different symptoms of this problem.
As it is generally expected of block scoped languages, in Go, if you have two independent blocks, you can always nest one inside the other without changes (even if they use the same names for their variables). Multi-variable := behavior seems to have been conceived to preserve such property.
By introducing special cases about shadowing we would loose such property and add complexity but we would still be without a short declaration mechanism that works well with tuple assignment.
I'm also fearful of proposals like this one:

Permit declaring new variables using =, but require at least one of the variables to already exist.

Out of the frying pan and into the fire, for what I consider to be a lack of explicitness problem.

A backwards-compatible approach to shadowing: let var name override shadows within its scope. Although this would not prevent unintended shadows, maybe go vet can catch those...
x, err := fa()
if err == nil {      // OR: if var err; err == nil
   var err           // override shadowing in if-scope
   y, z, err := fb() // preferable to separate declarations of y & z
}
if err != nil { ... }

To silence go vet re intended shadows
x, err := fa()
if err == nil {      // NOT: if var err error; err == nil (valid but wrong)
   var err error     // explicit shadowing; not flagged by go vet
   y, z, err := fb()

Et voila, the scope of err is clear in both cases.

Would like to add a gopher talk illustrating that many people struggle with shadowing including me and hope desperately this will make it in Go2
https://www.youtube.com/watch?v=zPd0Cxzsslk

The most common case in which := is used to redeclare an existing variable, while also defining a new variable, is for the variable err.  If we adopt the error handling design draft linked from https://go.googlesource.com/proposal/+/master/design/go2draft.md then it is possible that it will no longer be important to be able to use := to redeclare err.  In that case, perhaps we could consider dropping the redeclaration aspect of :=.  Instead, all variables on the left hand side of := would be defined for the first time, and if there were already a variable of that name it would be an error.  That would be a simple change that might address many people's concerns.
I think that concerns about variable shadowing should be considered separately from := redefinitions, perhaps in a different issue, though I don't know if there is one open for that right now.

I've branched my comment above to #30321

@ianlancetaylor, there is an old proposal above, which is equivalent* to #30318 plus dropping the redeclaration aspect of :=.
I'm highly in favor of it: if both of those things were to happen I think all the problems I listed could be solved.
Unfortunately dropping the redeclaration aspect of := is not backward compatible (but #30318 is). On the contrary the colon-prefix syntax is as effective but also backward compatible.
(* actually nsf proposal differs in its point #2, but it's just a matter of symmetry and doesn't change the substance)

I just got an idea which acts like an inverse of @niemeyer's idea.
The idea removes redeclarations and tries to solve both the problem mentioned in the current proposal and this one.
The following code shows the logic of the idea:
package main

var a int
var b bool
var err error

type T struct {
	i *int
	s []int
}
var t T
var p = new(int)

func foo() {
   var x, err = f()
   ...
   // Here ":err" means "err" is redeclared.
   var y, z, :err = g()
   ...
   {
   	// In fact, ":id" means the innermost already declared "id"
   	var w, :err = h()
   	...
   	// "::id" means the package-level declared "id".
   	var u, v, ::err = j()
   	...
   	// This "err" is a new declared one.
   	var m, n, err = k()
   	...
   }
}

Selectors, dereferences, and element indexing are allowed to
show up in a variable declaration only if there is a new declared
identifier in the declaration:
func bar{
   var *p, t.i, tis[1], err = 1, p, 2, ::err
   ...
}

The var keyword can be omitted in the short statements in all kinds of control flows.
For example,
if a, b := c, d; a {
}
//<=>
if var a, b := c, d; a {
}

The idea should be Go 1 compatible.

Sorry, the two := in the last code snippet should be both =.

Sorry, the description for control flow short statements are not correct. In fact, the := redeclaration syntax should be kept, but ONLY for the short statements in control flows, just for aesthetics reason.

Another simple fix is to prefix *& to re-declared identifiers to indicate the prefixed identifiers are redeclared.
var a, err = A()
var b, *&err = B()

Is *& a nop at runtime, or are you suggesting it should be? It feels like the compiler should be smart enough to figure it out today.

Yes, it has already been a nop now.

Could we consider a clearer (but more verbose) solution to the problem in the same spirit as global keyword in Python which is widely used?
Proposal

A new keyword outerScp is introduced to the language.

Usage: outerScp var1, var2, var3
It may be used only in the beginning of a scope
var1, var2 etc. are variables declared in the outer scope

Whenever a variable name is encountered in the inner scope that has been explicitly specified in the outerScp statement, it is not shadowed
In the absence of this, the standard Go 1 variable shadowing rules apply

Current Go 1  variable shadowing

package main

import (
	"fmt"
)

var a int

func printGlobal() {
	fmt.Printf("Print Global: %d\n", a)
}

func getNum() (int, error) {
	return 4, nil
}

func main() {

	a, err := getNum()
	if err != nil{
		fmt.Printf("error")
		return
	}

	printGlobal()
	fmt.Printf("Printing in main: %d\n", a)
}

Output
Print Global: 0
Printing in main: 4

With outerScp keyword

package main

import (
	"fmt"
)

var a int

func printGlobal() {
	fmt.Printf("Print Global: %d\n", a)
}

func getNum() (int, error) {
	return 4, nil
}

func main() {
        outerScp a

	a, err := getNum()
	if err != nil{
		fmt.Printf("error")
		return
	}

	printGlobal()
	fmt.Printf("Printing in main: %d\n", a)
}

Output
Print Global: 4
Printing in main: 4

Advantages:

Maintains compatibility with Go 1
Explicitly identifies which variables to not be shadowed improving clarity

DisAdvantages:

The outerScp keyword looks ugly. However

no public Go code uses this term currently
outerScope keyword is used in several public repositories
outer, global etc. are of course used in many repos as identifiers

@srinathh That problem with a keyword like outerscp is that it only helps if you know that you have a problem.  If you know that you have a problem, there are other things you can do, like not use :=.

@ianlancetaylor  Yes you're right... but that criticism is equally applicable to any other proposal short of completely removing support for the := operator.
I think the key to reducing possibility of subtle bugs is reduce cognitive load so programmers can better maintain contextual awareness. A keyword approach I think makes things a lot more obvious vs. introducing cryptic notations into the := assignment statement and should be familiar at least to Python programmers who forms the biggest chunk of Go users who use multiple languages as per the survey.

@srinathh Fair point.  I guess what I'm mean is that while cryptic notations are definitely cryptic, and perhaps not a good idea, at least they are short.  If I have to write out outerscp v, then I might as well just write var v as needed and stop using :=.

Hi, I came up with a slightly different approach for this issue. Will be glad to hear the community's thoughts on this.
Problem
In my point of view, one of the main problems with := is that it hides which variables are actually being declared.
a, b := 1, 1 // depending on the context, this might mean 3 different things
// a and b are declared and initialized
// a is declared and initialized, b is only assigned a new value
// a is only assigned a new value, b is declared and initialized

This might seem harmless but can be very misleading specially when it is combined with shadowed variables:
a, err := foo() // a and err are declared and initialized
b, err := bar() // b is declared and initialized, err is assigned a new value
if c, err := foobar(); err != nil { // c and err are declared and initialized inside
                                    // the scope of the if, err is shadowed
}
// now err has the value returned by bar, not foobar

In this example, the programmer might have expected the same behaviour in the assignments of err from bar and foobar. Assuming that variable masking is here to stay (although that might an interesting debate), I think that the best solution is to change the ambiguity of := declarations. More specifically, the problem is this part of the specification:

Unlike regular variable declarations, a short variable declaration may redeclare variables provided they were originally declared earlier in the same block (or the parameter lists if the block is the function body) with the same type, and at least one of the non-blank variables is new. As a consequence, redeclaration can only appear in a multi-variable short declaration. Redeclaration does not introduce a new variable; it just assigns a new value to the original.

Source
This "redeclaration" in the same block which "does not introduce a new variable" does not only cause the aforementioned confusions, but I also find it difficult to understand conceptually. Why is it even called redeclaration, when this is just simply an assignment? Reading this made me doubt if the address of a "redeclared" variable was preserved (it is).
Proposal

All identifiers in the left hand of a := are always declared as new variables, and redeclarations inside the same block are not allowed without exceptions.

a, err := foo()
b, err := foo() // compilation error because var err is already declared in this block

A mixed used of = and := is allowed in a single line, as shown in the following examples.

a:=, err:= foo() // a and err are declared and initialized (equivalent to: a, err := foo())
b:=, err= foo() // b is declared and initialized, whereas err is only assigned a new value
if true {
    c:=, err= foo() // c is declared and initialized in the if block, and err is assigned a new value
}
if true {
    d:=, err:= foo() // d and err are declared in the if block, err is shadowed
}

Similar proposals
This is similar to other proposals such as using :a, a', ^a or (a) to distinguish which variables are declared and which are just assigned. In my opinion my proposal is clearer and more in line with how the language looks currently. The meanings of := as short declaration+initialization, and = as just assignment is preserved and strengthened.
Backwards compatibility
Part 1 of the proposal is not backwards compatible. Part 2 could be introduced as a Go 1 minor release.
With a partial adoption, we could use automatic tools to break problematic expressions such as a, b := foo() to less ambiguous a:=, b= foo(), a=, b:= foo() or a:=, b:= foo() (the last one could remain as a, b := foo(), at this point this depends on the preferred format).
Pros and cons

Pros

Avoids confusions in current ambiguous mixed assignment+declarations using :=
Does not add unnecessary extra verbosity
(In my opinion) it's clearer than other proposals such as a'
Eliminates a confusing exception in the current language spec.

Cons

Can be visually and aesthetically problematic. The order of priorities of = and , is altered, which can be something difficult to get used to.
Does not solve the problem of unwanted redeclarations in an inner scope.

Some remarks
With this change, single-variable short declarations (a := 1) and assignments (a = 1) can be viewed as a specific case of the new rule. Moreover, current multivariable expressions such as a, b := foo() and a, b = foo() could be viewed as a simplification of a:=, b:= foo() and a=, b= foo(), respectively.
I suggest as a default gofmt to eliminate the space between identifier and short declaration / assignment operator when there is more than one operator, to emphasize that the operator only applies to the identifier that precedes the operator. Ie: a:=, b= foo() instead of, eg, a :=, b = foo().

@a-canya, thanks for the proposal.
the lack of such a mechanism has always been the single most annoying property of the language for me (I've been using a code rewriter for years), therefore at this point I would be happy with (almost) any syntax.
But at first glance I'm not convinced that this one is "clearer and more in line with how the language looks currently".
Your syntax has only an optional space separating the LHS from the RHS; I think having a single operator in the middle is clearer. And we are already familiar with a tuple of the form expr1, expr2,... but not with one of the form expr1 oper1, expr2 oper2,..., and they would have to coexist.
Compare:
a:=, b= c, d

vs.
:a, b = c, d

The := itself is just an assignment plus something more. It feels natural to me to untie : and =, since the = is still meaningful for the whole tuple while the "something more" (:) should be per-variable.
The latter syntax is also totally backward compatible.
That one is still my favorite, though unlikely to go anywhere after 10+ years, that's why I'm pushing for the more popular #30318 (which is just another equivalent syntax, once we get rid of redeclarations).

Why is it even called redeclaration, when this is just simply an assignment?

Good question.
It's a confusing choice of word and a very roundabout way of describing what is essentially an assignment to an existing variable. It seems to me that most users think of it as a reuse/assignment, and many don't know what a "redeclaration" is, or they tend to confuse it with shadowing.

I haven't seen strong opposition to @nsf's suggestio. IMHO, this is the best way to solve this problem by far. It is just a little (but acceptably) verbose.

@pam4 thanks for the answer! Very valid point indeed, and you show a good example of something that would confusing ugly if my proposal were accepted.
I'd like to remark that using the := with a mix of variables that are declared and "redeclared" only makes sense to me when using a function in the RHS:
// Case 1
a, b:= foo(1, "hello", x)  // current ambiguous approach
:a, b = foo(1, "hello", x) // alternative 1
a:=, b= foo(1, "hello", x) // alternative 2

// Case 2. IMO that's simply bad programming. Just break it into 2 lines for God's sake
a, b := 1, 2 // current ambiguous approach
:a, b = 1, 2 // alternative 1
a:=, b= 1, 2 // alternative 2

I don't like mixing assignments and declarations, they are essentially different operations. I understand that's convenient for function returns, but other than that I would strongly discourage anyone from doing it. And looking at case 1 I don't think I'd have a problem visually distiguishing the RHS and LHS.
In any case, which implementation looks better si very subjective. I hope we can find one alternative that's good enough for everyone to make a change.

Here is my proposal. Assume a go.mod gated roll out.
There are various situations in which it is annoying or impossible to specify the type for a variable. For example, a recursive closure must be written as
var f func(a B, b B) c C
f = func(a B, b B) c C {
   // ...
}

This is because f won't be in its own scope if it is assigned with :=. OTOH, if you have an exported function that returns an unexported type, you have to use assignment for initialization:
var x pkg.xtype // illegal
x := pkg.Xer() // ok
var x = pkg.Xer() // ok
var y pkg.Ytype; x, y = pkg.XAndYer() // illegal and no way to do without reinitializing y

So, what should we do? Let's take the auto keyword from the C family. auto means "create a new variable whose type is based on its subsequent first assignment". While we're at it, let's make shadowing with := illegal.
So, the classic nested err thing becomes
a, err := firstOperation()
{  // new scope
    auto b
    b, err = secondOperation() // b has the type of secondOperation's first return value
    c, err := thirdOperation() // illegal! no shadowing err
}

Tricky bits:

If an auto variable is not assigned to, or is read before assignment, that's illegal.
This needs to be illegal

auto a
if cond {
   a = 1
} else {
   a = "string"
}

OTOH, I think this should probably be legal, so having the assignment to an auto in an inner scope should be okay:
auto a
if a, err = operation(); err != nil {
   // ...
}
// a is in scope here

Advantages of auto:

No weird symbols
Fixes the := shadowing problem
Also useful for recursive closures and unexported variables

@go101

I haven't seen strong opposition to @nsf's suggestion.

As I noted above, nsf's suggestion is basically #30318 plus 2 points:

Allow no new variables on the left side of :=
this is just cosmetic, if there are no new variables you can use =.
Eliminate := redeclaration
this is important but it must wait for Go2 (not backward compatible).

There is already some consensus about getting rid of redeclaration, so I think that if we can push through #30318 we're nearly there.

IMHO, this is the best way to solve this problem by far.

I can't think of any (technical) advantage over the backward compatible colon-prefix syntax, but #30318 is far more popular, with many upvotes, and already implemented!
@a-canya

I'd like to remark that using the := with a mix of variables that are declared and "redeclared" only makes sense to me when using a function in the RHS:

I agree, but I think it's important to also consider edge cases.

I don't like mixing assignments and declarations, they are essentially different operations. I understand that's convenient for function returns, but other than that I would strongly discourage anyone from doing it.

I think of the initialization part of a declaration as being an assignment, that's why extending the = operator for this purpose feels natural to me.
But yes, I agree with your point. Without a function returning multiple values there is no advantage in mixing declarations and pure assignments in the same statement.

In any case, which implementation looks better si very subjective.

Indeed.

I hope we can find one alternative that's good enough for everyone to make a change.

Hopefully the steady stream of similar proposals over many years will convince the core team that there is a need for such a mechanism.

@pam4

As I noted above, nsf's suggestion is basically #30318 plus 2 points:

Allow no new variables on the left side of :=
this is just cosmetic, if there are no new variables you can use =.

Almost, but not for the declaration in if (oldV), newV := expr; condition {...}

Eliminate := redeclaration
this is important but it must wait for Go2 (not backward compatible).

What's the backward compatibility problem here?

@go101

Allow no new variables on the left side of :=
this is just cosmetic, if there are no new variables you can use =.

Almost, but not for the declaration in if (oldV), newV := expr; condition {...}

I don't understand.
Your example is perfectly valid under #30318 alone, because there is one new variable (newV).
According to nsf's proposal, x.b, (err) := B() should be valid too, but he admits that it's just a matter of preference: if there are no new variables there's no need for a := in the first place.
I don't see the connection between my point (#2 in nsf's post) and your example, please explain.

Eliminate := redeclaration
this is important but it must wait for Go2 (not backward compatible).

What's the backward compatibility problem here?

Without redeclaration, a bare identifier on the LHS of a := would always cause a compile error if it was already declared in the same scope.
// this code currently compiles, but it should fail per nsf's proposal
a, ok := f()
if !ok {
    //...
}
b, ok := g() // ok is redeclared

// it should be written like this instead:
a, ok := f()
if !ok {
    //...
}
b, (ok) := g()

// under #30318 alone, both are supposed to work

Comparing to the "colon-prefix syntax" one, nsf's solution don't need to invent a syntax.
If we do need to invent a new syntax, I prefer .oldV to :oldV.

Just to be sure there's no misunderstanding, the "colon-prefix syntax" works with the = operator (not :=), and it's the new variables that are marked with :, not the old.
The idea is that the : in := is the part that means "declare", so we move it in front of the variables to declare.
I.e. :a, b = f() would correspond to a, (b) := f() (declare a and reuse b).
That said, the actual choice of symbol is not that important to me.

@pam4
I admit I did misunderstood your first point.
The intention of  the other issue (https://github.com/golang/go/issues/30318) is to allow non-pure-identifier items on the left of :=. I think, for code readability and easy-explanation, it is good to make all pure identifiers on the left of := new declared+initialized and non-pure-identifier items modified. The  "colon-prefix syntax" :newV conflicts with this design.
There are some possible ways to go through:

Remove the  ... := ... syntax and allow non-pure-identifier items on the left of a variable declaration var ... = ..., and  define var ... = ... as simple statement (otherwise there will be no ways to declare new variables at the beginning of if, switch and for code blocks).
Keep the  ... := ... syntax but call it as assignment and declaration (instead of the current redeclaration), and allow non-pure-identifier items on the left of := and allow (oldV) in the left list.
2.a. Still allow oldV on the left of :=
2.b. Disallow oldV  on the left of :=

The way #2.a will keep compatibility but it also keeps the confusion cases the current issue tries to avoid.
I admit the ways #1 and #2.b will break compatibility, but they both can be viewed as feature removal. In other words, the compatibility breaking is controllable with the help of language feature version.

@go101

The intention of the other issue (#30318) is to allow non-pure-identifier items on the left of :=. I think, for code readability and easy-explanation, it is good to make all pure identifiers on the left of := new declared+initialized and non-pure-identifier items modified. The "colon-prefix syntax" :newV conflicts with this design.

Sorry, you lost me again. The colon-prefix syntax doesn't use the := operator, so I don't see the conflict.
Of course it doesn't make sense to implement both, but either one or the other. If we go for the colon-prefix syntax there is no need for #30318 anymore (in fact there is no need for := anymore).

Keep the ... := ... syntax but call it as assignment and declaration (instead of the current redeclaration), and allow non-pure-identifier items on the left of := and allow (oldV) in the left list.
2.a. Still allow oldV on the left of :=
2.b. Disallow oldV on the left of :=

The way #2.a will keep compatibility but it also keeps the confusion cases the current issue tries to avoid.

What you describe as #2.a is exactly #30318 (as nicely explained here).

I admit the ways #1 and #2.b will break compatibility, but they both can be viewed as feature removal. In other words, the compatibility breaking is controllable with the help of language feature version.

If we go for #30318, dropping redeclarations (#2.b) is the obvious next step. I was just saying that we cannot have it before Go2 because it's a huge break and we have a compatibility promise in place.
OTOH the colon-prefix syntax has no compatibility problems (:= could be deprecated but maintained as long as it's convenient), and it has exactly the same advantages as #1 or #2.b.

@pam4

If we go for the colon-prefix syntax there is no need for #30318 anymore (in fact there is no need for := anymore).

Do you mean, if we go for the colon-prefix syntax there, the #30318 cases can be solved as
oldv1.field, oldV2,  :newV = f()

? If this is true, I think this is not an elegant design, for code readability and easy-explanation reasons, and it needs to invent a new expression syntax.

OTOH the colon-prefix syntax has no compatibility problems (:= could be deprecated but maintained as long as it's convenient),

So do you mean the new syntax will coexist with the old redeclartion syntax, to keep back compatibility? If this is true, it doesn't remove the confusion the current issue tries to remove. IMHO, #2.a is more elegant than this design for the same keep-compatibility goal, for no new expression syntax needs to be invented.

If we go for #30318, dropping redeclarations is the obvious next step (#2.b).

No, it is not #2.b, it is more similar to #1.

@go101, ok, it seems that we understood each other now.
oldV1.field, oldV2, :newV = f()   // colon-prefix syntax
oldV1.field, (oldV2), newV := f() // #30318

If this is true, I think this is not an elegant design, for code readability and easy-explanation reasons, and it needs to invent a new expression syntax.

Readability: I think it's more readable to mark variables that need to be declared than vice versa, but readability is very subjective and I respect other people views.
Easy-explanation: I think the colon-prefix syntax is easier to explain: "the declare operator (:) can be used in front of any bare identifier on the LHS of an assignment; it causes such identifier to be declared", that's all.
OTOH, the "parenthesized identifier" trick is clever but not as straightforward: var and (var) currently have the same effect on the LHS of an =, so you have to explain why on the LHS of a := they don't (not because parentheses have a special meaning but because a parenthesized identifier is not bare).
New syntax: yes, one simple operator (:) is introduced while a complex and problematic one (:=) is removed. I think it's a good trade-off.

So do you mean the new syntax will coexist with the old redeclartion syntax, to keep back compatibility? If this is true, it doesn't remove the confusion the current issue tries to remove.

No, the intent is for the := to be abandoned. I'm just saying that it could be done in 2 steps if necessary:

the colon-prefix syntax is introduced; := is deprecated and not used in new code but old code still works; confusion is limited because := keeps the old familiar behavior; new code without := has all the advantages of #2.b;
:= is removed when possible.

The other solution can also be done in 2 steps (#30318 and then dropping redeclarations), but before the second step there is always the possibility of forgetting a () and using redeclarations accidentally.
Anyway, regardless of my preference I'm just arguing that the colon-prefix syntax is a viable alternative. I think your preference is still good and more likely to happen (because of the popularity of #30318). So it's not me that you have to convince, I would gladly introduce #30318 today and drop redeclarations in Go2.

This code is subtly wrong:
func f() (err os.Error) {
v, err := g();
if err != nil {
return;
}
if v {
v, err := h();
if err != nil {
return;
}
}
}
The := in the if statement causes a new err variable that shadows the
return parameter.
Maybe doing this should be an error. Maybe return parameters should be
special so that := doesn't ever shadow them. (I like the latter.)

//Hand Error

func main() {

    f, err := os.Open("/test.txt") :e {
            fmt.Println( e )
    }

    f, err := os.Open("/test.txt") :e HandEorr( e )

    //or
    f, err := os.Open("/test.txt") e: {
        fmt.Println(e)
    }

    f, err := os.Open("/test.txt") e:

}


Git/github Integration

Focus on git integration. Add a support to github to.
Integrate Git to commit, see the last commits, change the current branch, and others usual tasks.
Display branch name on status bar.

Git tools:

Non-git repo:

Git diff:


Can i use this on Multi Auth ?

let say i have 3 Model that Uses 3 Different Auth Guard
set in config/auth.php
one for web(default user) , admin , employee...
Do i Need to Do Set Up Anything to Make it Work For Multi Auth?

see #333

I don't think so, it'll just work.

Hi Freek After Testing Out Using 3 Different Auth....
This Would NOT Work on the Fly If You Use 3 Different Auth
IT Always Uses The Default Driver which is 'web'
the only work around on this is if i edit your
public function __construct
this line on ActivityLogger.php
else {
            $this->causedBy = $auth->guard($this->authDriver)->user(); // replace this line
        }

replace with
$guards = collect(config('auth.guards'))->keys()->all();
foreach ($guards as $guard) {
           if(auth()->guard($guard)->check()){
            $this->causedBy = auth()->guard($guard)->user();
            break;
           }
        }

Basically I fetch all the Guards I Created On auth.php ...
then Loop on the guards to check what guard has a Login User
If there is a login User then that will be set as $this->causeBy value...
Hope you can Merge this piece of code... i made ...
thanks

Coul you create a PR for this, with tests to prove that there is a problem and this is a right fix?


backport of 'fix inappropriate invoke in unsubscribe retry task'

What is the purpose of the change
(backport of https://github.com/apache/dubbo/pull/12231 for 3.2 branch.)
fix inappropriate invoke in unsubscribe retry task
Brief changelog
Verifying this change

Checklist

[x] Make sure there is a GitHub_issue field for the change (usually before you start working on it). Trivial changes like typos do not require a GitHub issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[ ] Each commit in the pull request should have a meaningful subject line and body.
[ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[ ] Check if is necessary to patch to Dubbo 3 if you are work on Dubbo 2.7
[ ] Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
[ ] Add some description to dubbo-website project if you are requesting to add a feature.
[ ] GitHub Actions works fine on your own branch.
[ ] If this contribution is large, please follow the Software Donation Guide.

Codecov Report

Merging #12235 (d19ed65) into 3.2 (c5f8ce6) will increase coverage by 2.14%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##                3.2   #12235      +/-   ##
============================================
+ Coverage     67.39%   69.54%   +2.14%
+ Complexity       22        2      -20
============================================
  Files          3541     1603    -1938
  Lines        152589    65805   -86784
  Branches      23337     9598   -13739
============================================
- Hits         102838    45761   -57077
+ Misses        40151    15652   -24499
+ Partials       9600     4392    -5208

see 1974 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


StructureRepresentation.selection referenced before definition

Hi again,
Just a quick one - If I load a structure then add a cartoon representation I get an error because StructureView hasn't got a selection attribute defined yet. I think this is down to the order attributes are defined in StructureRepresentation. This PR fixes it for me (though that's possibly more by luck than judgement!)
Cheers,
Fred

You are exactly right, I already have that fixed locally, will upload later. Thanks

done 636964ca4c2e23daf3c9f4de3018ae7501d0fdd8


Division error at Python 2.7

For some weird reason i am getting errors with division at python 2.7
That is my ipython session that replicates the error:
In [1]: from moneyed.classes import Money,  CURRENCIES

In [2]: Money(amount=10, currency=CURRENCIES['USD']) / 2
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-2-5831df76cb8f> in <module>()
----> 1 Money(amount=10, currency=CURRENCIES['USD']) / 2

TypeError: unsupported operand type(s) for /: 'Money' and 'int'

The strange part is that running the tests from project test file using pytest it passes without getting any errors with division, but, outside that i get this error.

It looks like you need from __future__ import division.
Money only support supports the new type of division. The old type does rounding, which isn't useful for our use case. This should definitely be documented better.

Yeah i found that jus now and made a PR to document that #104

Fixed with PR


Add loading screen to Downloads/Published area

The Issue
If you navigate to the downloads/published area before the app can load file_list or claim_list_mine, you just see "Nothing has been downloaded/published". It should show a loading dialog.
System Configuration

LBRY Daemon version:
LBRY App version:
LBRY Installation ID:
Operating system:

Anything Else

Screenshots

Happening subscription page too.

Sean added a loading indicator (which could use some text such as "loading..." or "fetching..."), but when you clear app cache and go to subscriptions, it's still missing.

This LGTM!


[CMT-629-955] translation 2021-07-30-The-Blue-Pill-Ann.md

I translated 2021-07-30-The-Blue-Pill-Ann.md into indonesia
Description

Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context.

This pull request ...
Fixed issue

Please indicate the fixed issues with this exact format Fixes #232 where 232 is the number of the issue. This will trigger an auto-close if the issue when this PR is merged.
Supported keywords:
Fixes #1,#2,#3
close #1, #2, #3
fix #1 #2 #3
resolve #1,#2 #3
Resolves: #1,#2,#3
closed : #1, #2, #3

Fixes #(issue)
Type of change

Please delete options that are not relevant and check the box.

[ ] Add a new article/page
[ ] Fix a Typo
[ ] Add a new translation
[ ] Other

Resources

Any screenshots, links or relevant resources to explain better the changes.

Hi @gateway-504 I'm new to this repository, are we supposed to use the .id.md or use the indonesian branch entirely for our translations?

Use indonesia branch for entire
On Thu, 24 Mar 2022, 02:30 mpj, @.***> wrote:

Hi @gateway-504 https://github.com/gateway-504 I'm new to this
repository, are we supposed to use the .id.md or use the indonesian
branch entirely for our translations?
—
Reply to this email directly, view it on GitHub
https://github.com/yearn/yearn-comms/pull/955#issuecomment-1076740536,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AR7S7S3H7TGSY3UX4QZ3BU3VBNWORANCNFSM5ND6XHBQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

Hi @gateway-504 I think it is looking good now, but if I'm not mistaken now everything is goes to the english branch and we need to recreate the PR.
Please CMIIW @DarkGhost7


Parameter 'values' is not executed correctly

// code 1
connection.query(SELECT * FROM shop_product WHERE productid in(1,2,3,4,5)` ,(error, results, fields)=> {...})
// results length is 5
//code 2
connection.query(SELECT * FROM shop_product WHERE productid in(?)`,["1,2,3,4,5"] ,(error, results, fields)=> {...})
// results length is 1
The results are different？？？

Hi @dabaii this is because in your first example, you have a list of numbers, but in your second, you have a single string. You can see the same results in the second if you used strings in the first like
SELECT * FROM shop_product WHERE productid in('1,2,3,4,5')

You want to use an array of numbers in your values, like the following:
connection.query('SELECT * FROM shop_product WHERE productid in(?)`,[[1,2,3,4,5]] ,(error, results, fields)=> {...})

👍


⚠ ClamAV has degraded performance

In 092934b, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 70 ms

Resolved: ClamAV performance has improved in 1f37ca8.


Fix window is undefined

Moving global window access to onMount hook for to fix "window is undefined" error when using with sapper, etc.

@pbxothi Thank you for the PR.
Could you use the svelte:window API so that the event listener is also removed when the component is destroyed?

Thank you @pbxothi – patched in v0.3.3


Circuits with if_test fail when running on compatible hardware

Environment

Qiskit Terra version: 0.43.3 meta package, 0.24.2 terra
Python version: 3.9
Operating system: Windows 11

What is happening?
Basic circuits containing an if_test statement incur a TypeError upon execution on ibm_sherbrooke and other backends with dynamic circuit support. The specific error message is: TypeError: Type is not JSON serializable: QuantumCircuit
I mention ibm_sherbrooke since it was used in the recent IBM Quantum Challenge where if_test circuits were run extensively.
How can we reproduce the issue?
Run the following (with your own provider inserted):
from qiskit import QuantumCircuit, QuantumRegister, ClassicalRegister
from qiskit_ibm_provider import IBMProvider
provider = IBMProvider(name=your_provider_name)
sherbrooke = provider.get_backend('ibm_sherbrooke')

qr = QuantumRegister(1)
cr = ClassicalRegister(2)
qc = QuantumCircuit(qr, cr)
(q0,) = qr
b0, b1 = cr

qc.h(q0)
qc.measure(q0, b0)
with qc.if_test((b0, 1)):
    qc.x(q0)
qc.measure(q0, b1)

job = sherbrooke.run(qc, shots=1024)

Once the job has run on the device, job.status() returns <JobStatus.ERROR: 'job incurred error'> and job.error_message() returns 'TypeError: Type is not JSON serializable: QuantumCircuit'.
Using, for example, the aer_simulator_statevector backend instead, the job executes successfully.
What should happen?
The job should execute successfully.
Any suggestions?
No response

If this is still occurring after you've updated your version of qiskit_ibm_provider (and even if not), it would potentially be a bug on their side, not Terra's - the error message should have been raised by that package.  I suspect the most likely is that your version of qiskit_ibm_provider was a bit old, and you still needed to pass dynamic=True to backend.run if you wanted to run a dynamic circuit.
Either way, I'm going to close this here because the problem isn't in Terra.  You might want to ask in Qiskit Slack or at the GitHub page for qiskit-ibm-provider, but this stuff does work in general.
Fwiw, I was able to run your code verbatim (except for providing a name for the provider) with qiskit_ibm_provider==0.6.2 on Sherbooke.


DataCiteClient: Bugs found while testing client

Minor changes , and some more detailed exceptions. The bug were about setLandingPage which only eats text/plain ..

@janbj @axthosarouris @brinxmat : Codacy is down atm, so ignore that one. Failing for deltas: Can't retry the analysis right now. Please, try again later!


Inconsistent this result

@ifyour frome windows ?

@jaywcjlove yap.. need more detail?

@ifyour Later, I debug it.

@ifyour windows 10 ? There are no problems with linux and Mac.

@jaywcjlove This is Windows 7 Enterprise Edition. :confused:

@ifyour My test returned is correct.

node v8.11.3
Windows 10


[ja] Translate content/en/docs/concepts/storage/volume-attributes-classes.md into Japanese

This is a Feature Request
What would you like to be added
Translate content/en/docs/concepts/storage/volume-attributes-classes.md into Japanese
Why is this needed
There is no Japanese translation for this page
Comments

File to translate:

https://github.com/kubernetes/website/blob/main/content/en/docs/concepts/storage/volume-attributes-classes.md

Original:

https://kubernetes.io/docs/concepts/storage/volume-attributes-classes/

日本語に翻訳する際は、以下のドキュメントを参考にしてください。

Japanese Localization document: https://kubernetes.io/ja/docs/contribute/localization/

/area localization
/language ja
/help
/triage accepted

/kind feature

/assign


fixed bower.json

@cryigenian Did you mean to close this???

Yep. Working version is a fork from particular commit. It will be fixed with halogen 0.7 update


Add a settings module

To avoid mucking up the API to allow for idiosyncratic use cases (e.g. looping over preproc files instead of event files), add a settings module to configure certain behaviors.

Added in #197.


tsSetup: use relative path to each data vrt file in stack vrt file

This PR replaces the absolute file path of the individual data vrt file in the stack/*Stack.vrt files with the relative path, so that prep_aria.py would still work if one moved the root directory.

@yunjunz it fails a unit test where it calls prep_aria.py.
Are you suggesting to change the unit test to allow this behavior?
See here: https://github.com/aria-tools/ARIA-tools/blob/a9de4fc5e7bda8dff04f6056ff7c43a7f8e6bfa5/.circleci/config.yml#L81

Hi @dbekaert, it turns out we need to add relativeToVRT="1" to allow for this behavior, as described here: https://gdal.org/drivers/raster/vrt.html#simplesource.

@dbekaert looks good to me, thanks @yunjunz!