Force Calls for Var references that are given arguments.

This issue has been marked as a "Good First Issue"! If you'd like to tackle this issue as your first contribution to the project, be sure to read the Get Involved section of the README for some help with how to get started.
Consider this code:
foo = fn
  ->(1) { 2 }
  ->(2) { 4 }
end

foo(2)

This code will fail to parse, because foo is considered a local variable. As such, the parser will generate a Var node, and then get confused by the LPAREN token that follows it.
I think that in this case, the parser should force the Var to become a Call with no receiver. As far as I can tell, this is unambiguous, as the opening parenthesis eliminates the possibility for infix Calls, etc.
With that, the expectation of the above code would be successful parsing and a result 4 after interpreting.
Everything in the interpreter is already set up to handle the fact that foo is a callable functor. To be sure, try the same code above with the last line changed to self.foo(2). In this case, foo is forced to be a Call (because it has an explicit receiver of self), so it runs as expected, calling the function and returning 4.

Since this is just a Parser change, the implementation is fairly straightforward. The distinction between Var and Call is made in Parser#parse_var_or_call. The exact code is here:
https://github.com/myst-lang/myst/blob/52e2b83bbff815621c74b1e2920aa98cf3f33753/src/myst/syntax/parser.cr#L714-L726
The change to make is to avoid returning early if the next significant token (not whitespace, but potentially a newline) is an LPAREN, which would indicate a forced Call.
I don't necessarily know the best way to go about this change, but here's my take:

Move the skip_space from line 725 to above the if receiver.nil?. This will skip all of the unimportant tokens in the stream, leaving current_token as the next significant token.
Add current_token.type != Token::Type::LPAREN to the if receiver.nil? condition. If either of these are not met, the Var should be forced to be a Call instead, so the condition should be falsey.

My hesitation with this implementation comes from a comment earlier in parser.cr that describes a condition that currently holds for every method in the parser:

Each method will consume exactly the number of tokens required to build its node.

Moving the skip_space to an early position, before knowing that an LPAREN will be present, violates this contract, because in the case that the next token is not an LPAREN, the method will have advanced through more tokens in the stream than have been used to build nodes for the tree. This is probably fine, and a solution that doesn't violate this contract will almost definitely be far more complex, but feel free to try out different ideas and see if you can make it work :)
The final part (or first, depending on your TDD preferences) to implementing this feature will be adding some specs in parser_spec.cr to test cases that either should or should not be forced into Calls. This section seems like the best place to add them.
I'm sure I haven't done a great job of explaining things, so please let me know if some part of this needs clarification :) The #help channel on our Discord server is a great place to get quick feedback and have a faster conversation, or you can add a comment here for a more long-winded reply.
Good luck :)

this was implemented by #54.


Release optimization pass doesn't respect input source maps?

Hey peeps! Nice work splitting this off from react-native :)
It seems that, despite best intentions, input source maps get ignored when bundling for release. Here is the culprit: https://github.com/facebook/metro-bundler/blob/e87a8205d8ca070df0fcef67dbe4f02389770b95/packages/metro-bundler/src/JSTransformer/worker/index.js#L126
The transform steps done inside both of those optimization passes seem to ignore input source maps, regardless of whether they are passed inline or not. This may well be an issue with Babel rather than Metro. Indeed, it may even be desired behaviour in babel, but metro should probably be mapping between compiled and input code properly :)
The first place that the input source map gets left behind is during the inline operation. Notice that it transforms the input with the babel option source set to false - When you do that, babel never outputs a map property during the File#generate method because it ends up calling File#makeResult in such a way that it is impossible for a map to be emitted.
However, even if you patch inline to set code: true, the emitted map appears to be based only on the code passed to the transform step, completely ignoring the inputSourceMap property.
I've done a few hours trying to debug this but gotten nowhere. Maybe one of you can look at it?
I made a failing test over here: https://github.com/ds300/metro-bundler/blob/aadd5d8303ac99c8d5e5918ac752ca90b1c2fbdb/packages/metro-bundler/src/JSTransformer/worker/tests/source-mapping-test.js
Thanks :heart:

Any chance this will get looked at?

Hey! We've completely rewritten the transforming pipeline, the new logic is available from v0.21.0 and should fix any sourcemap issue 😄


Share view does not react at all if you add a non existing user

Describe the bug
If you try to add a non exisiting user to the list of users you share your program with, the frontend will not react at all. You therefore do not know, whether or not it worked or not.
To Reproduce
Steps to reproduce the behavior:

Log into an account in the Open Roberta Lab, which has at least one saved program.
Open the "my programs" view.
Open the share view for a program.
Add a username to the share list, that does not exist.
See that you are not shown anything

Expected behavior
Any sort of indication that the frontend received my request to share with such a user, but it did not go well. For example an effect, an error message, a notification or a hover text.
Screenshots

Device information

Desktop
Windows 10
FireFox 60.9

Popup couldn't be displayed because of the error fixed with 327fe0fe973d3508e751619638e2419179ef04ad


Related Issues: https://github.com/rancher/rancher/issues/39846, https://github.com/rancher/prometheus-federator/issues/33

Checklist
In general, the rules for bumping versions are:

If the current version is an RC, increment it 0.0.0-rc1 -> 0.0.0-rc2
If the current version is not an RC, bump the patch and set it to -rc1 (0.0.0 -> 0.0.1-rc1)

Please fill out this table to identify which fields need to be modified in your PR.
Under Status, either indicate Does Not Apply or Added to this PR.

Field to be modified
Why should this be modified?
Status

version in rancher-project-monitoring Chart.yaml
- You modified the contents of the rancher-project-monitoring chart to make changes

helmProjectOperator.image.tag in prometheus-federator values.yaml
Either you modified the rancher-project-monitoring chart or you modified the main.go file

appVersion in prometheus-federator Chart.yaml
You modified the helmProjectOperator.image.tag in the above box

version in prometheus-federator Chart.yaml
Either you modified the appVersion in the above box or you modified the contents of the prometheus-federator chart to make changes

For Maintainers Releasing The Chart On QA Validation
Please checkmark both of the boxes below to indicate that you have followed the versioning guidelines for prometheus-federator:

[ ] The -rc tag has been removed from the version in packages/prometheus-federator/charts/Chart.yaml
[ ] The -rc tag has been removed from the helmProjectOperator.image.tag in packages/prometheus-federator/charts/values.yaml

diff -uNr charts/prometheus-federator/0.2.0-rc1/Chart.yaml charts/prometheus-federator/0.2.0-rc2/Chart.yaml
--- charts/prometheus-federator/0.2.0-rc1/Chart.yaml	2022-12-16 09:58:20
+++ charts/prometheus-federator/0.2.0-rc2/Chart.yaml	2022-12-16 11:08:33
@@ -9,7 +9,7 @@
   catalog.cattle.io/rancher-version: '>= 2.6.5-0 <= 2.6.100-0'
   catalog.cattle.io/release-name: prometheus-federator
 apiVersion: v2
-appVersion: 0.2.0-rc1
+appVersion: 0.2.0-rc2
 dependencies:
 - condition: helmProjectOperator.enabled
   name: helmProjectOperator
@@ -17,4 +17,4 @@
 description: Prometheus Federator
 icon: https://raw.githubusercontent.com/rancher/prometheus-federator/main/assets/logos/prometheus-federator.svg
 name: prometheus-federator
-version: 0.2.0-rc1
+version: 0.2.0-rc2
diff -uNr charts/prometheus-federator/0.2.0-rc1/charts/helmProjectOperator/Chart.yaml charts/prometheus-federator/0.2.0-rc2/charts/helmProjectOperator/Chart.yaml
--- charts/prometheus-federator/0.2.0-rc1/charts/helmProjectOperator/Chart.yaml	2022-12-16 09:58:20
+++ charts/prometheus-federator/0.2.0-rc2/charts/helmProjectOperator/Chart.yaml	2022-12-16 11:08:33
@@ -12,4 +12,4 @@
 appVersion: 0.0.1
 description: Helm Project Operator
 name: helmProjectOperator
-version: 0.0.2
+version: 0.0.3
diff -uNr charts/prometheus-federator/0.2.0-rc1/charts/helmProjectOperator/README.md charts/prometheus-federator/0.2.0-rc2/charts/helmProjectOperator/README.md
--- charts/prometheus-federator/0.2.0-rc1/charts/helmProjectOperator/README.md	2022-12-16 09:58:20
+++ charts/prometheus-federator/0.2.0-rc2/charts/helmProjectOperator/README.md	2022-12-16 11:08:33
@@ -38,7 +38,7 @@

 ### Helm Resources (HelmChart, HelmRelease)

-On deploying a ProjectHelmChart, the Prometheus Federator will automatically create and manage two child custom resources that manage the underlying Helm resources in turn:
+On deploying a ProjectHelmChart, the Helm Project Operator will automatically create and manage two child custom resources that manage the underlying Helm resources in turn:
 - A HelmChart CR (managed via an embedded [k3s-io/helm-contoller](https://github.com/k3s-io/helm-controller) in the operator): this custom resource automatically creates a Job in the same namespace that triggers a `helm install`, `helm upgrade`, or `helm uninstall` depending on the change applied to the HelmChart CR; this CR is automatically updated on changes to the ProjectHelmChart (e.g. modifying the values.yaml) or changes to the underlying Project definition (e.g. adding or removing namespaces from a project).
 > **Important Note: If a ProjectHelmChart is not deploying or updating the underlying Project Monitoring Stack for some reason, the Job created by this resource in the Operator / System namespace should be the first place you check to see if there's something wrong with the Helm operation; however, this is generally only accessible by a Cluster Admin.**
 - A HelmRelease CR (managed via an embedded [rancher/helm-locker](https://github.com/rancher/helm-locker) in the operator): this custom resource automatically locks a deployed Helm release in place and automatically overwrites updates to underlying resources unless the change happens via a Helm operation (`helm install`, `helm upgrade`, or `helm uninstall` performed by the HelmChart CR).
@@ -48,7 +48,7 @@

 ### RBAC

-As described in the section on namespaces above, Prometheus Federator expects that Project Owners, Project Members, and other users in the cluster with Project-level permissions (e.g. permissions in a certain set of namespaces identified by a single label selector) have minimal permissions in any namespaces except the Project Registration Namespace (which is imported into the project by default) and those that already comprise their projects. Therefore, in order to allow Project Owners to assign specific chart permissions to other users in their Project namespaces, the Helm Project Operator will automatically watch the following bindings:
+As described in the section on namespaces above, Helm Project Operator expects that Project Owners, Project Members, and other users in the cluster with Project-level permissions (e.g. permissions in a certain set of namespaces identified by a single label selector) have minimal permissions in any namespaces except the Project Registration Namespace (which is imported into the project by default) and those that already comprise their projects. Therefore, in order to allow Project Owners to assign specific chart permissions to other users in their Project namespaces, the Helm Project Operator will automatically watch the following bindings:
 - ClusterRoleBindings
 - RoleBindings in the Project Release Namespace

diff -uNr charts/prometheus-federator/0.2.0-rc1/charts/helmProjectOperator/questions.yaml charts/prometheus-federator/0.2.0-rc2/charts/helmProjectOperator/questions.yaml
--- charts/prometheus-federator/0.2.0-rc1/charts/helmProjectOperator/questions.yaml	2022-12-16 09:58:20
+++ charts/prometheus-federator/0.2.0-rc2/charts/helmProjectOperator/questions.yaml	2022-12-16 11:08:33
@@ -1,7 +1,7 @@
 questions:
 - variable: helmController.enabled
   label: Enable Embedded Helm Controller
-  description: 'Note: If you are running Prometheus Federator in an RKE2 cluster, this should be disabled.'
+  description: 'Note: If you are running this chart in an RKE2 cluster, this should be disabled.'
   type: boolean
   group: Helm Controller
 - variable: helmLocker.enabled
diff -uNr charts/prometheus-federator/0.2.0-rc1/charts/helmProjectOperator/templates/psp.yaml charts/prometheus-federator/0.2.0-rc2/charts/helmProjectOperator/templates/psp.yaml
--- charts/prometheus-federator/0.2.0-rc1/charts/helmProjectOperator/templates/psp.yaml	2022-12-16 09:58:20
+++ charts/prometheus-federator/0.2.0-rc2/charts/helmProjectOperator/templates/psp.yaml	2022-12-16 11:08:33
@@ -1,4 +1,4 @@
-{{- if .Values.global.rbac.pspEnabled }}
+{{- if and .Values.global.rbac.pspEnabled (.Capabilities.APIVersions.Has "policy/v1beta1/PodSecurityPolicies") }}
 apiVersion: policy/v1beta1
 kind: PodSecurityPolicy
 metadata:
diff -uNr charts/prometheus-federator/0.2.0-rc1/charts/helmProjectOperator/values.yaml charts/prometheus-federator/0.2.0-rc2/charts/helmProjectOperator/values.yaml
--- charts/prometheus-federator/0.2.0-rc1/charts/helmProjectOperator/values.yaml	2022-12-16 09:58:20
+++ charts/prometheus-federator/0.2.0-rc2/charts/helmProjectOperator/values.yaml	2022-12-16 11:08:33
@@ -127,7 +127,7 @@

 image:
   repository: rancher/helm-project-operator
-  tag: v0.0.1
+  tag: v0.0.3
   pullPolicy: IfNotPresent

 helmController:
@@ -177,7 +177,7 @@
 cleanup:
   image:
     repository: rancher/shell
-    tag: v0.1.18
+    tag: v0.1.19-rc7

   nodeSelector: {}

diff -uNr charts/prometheus-federator/0.2.0-rc1/values.yaml charts/prometheus-federator/0.2.0-rc2/values.yaml
--- charts/prometheus-federator/0.2.0-rc1/values.yaml	2022-12-16 09:59:43
+++ charts/prometheus-federator/0.2.0-rc2/values.yaml	2022-12-16 11:08:33
@@ -56,7 +56,7 @@

   image:
     repository: rancher/prometheus-federator
-    tag: v0.2.0-rc1
+    tag: v0.2.0-rc2
     pullPolicy: IfNotPresent

   # Additional arguments to be passed into the Prometheus Federator image

diff -uNr charts/rancher-project-monitoring/0.2.0-rc1/Chart.yaml charts/rancher-project-monitoring/0.2.0-rc2/Chart.yaml
--- charts/rancher-project-monitoring/0.2.0-rc1/Chart.yaml	2022-12-16 10:08:58
+++ charts/rancher-project-monitoring/0.2.0-rc2/Chart.yaml	2022-12-16 11:08:33
@@ -30,4 +30,4 @@
   url: https://github.com/geethub97
 name: rancher-project-monitoring
 type: application
-version: 0.2.0-rc1
+version: 0.2.0-rc2
diff -uNr charts/rancher-project-monitoring/0.2.0-rc1/questions.yaml charts/rancher-project-monitoring/0.2.0-rc2/questions.yaml
--- charts/rancher-project-monitoring/0.2.0-rc1/questions.yaml	2022-12-16 10:08:58
+++ charts/rancher-project-monitoring/0.2.0-rc2/questions.yaml	2022-12-16 11:08:33
@@ -11,12 +11,12 @@
   group: Grafana
   show_subquestion_if: true
   subquestions:
-  - variable: grafana.admin.adminUser
+  - variable: grafana.adminUser
     label: Grafana Admin User
     type: string
     default: admin
     group: Grafana
-  - variable: grafana.admin.adminPassword
+  - variable: grafana.adminPassword
     label: Grafana Admin Password
     type: string
     default: prom-operator

Note: rancher/shell will need to be un-RCed before we un-RC the Prometheus Federator chart

Cannot validate this via CI runs until Rancher Monitoring is fixed to work in 1.25:
https://github.com/rancher/prometheus-federator/actions/runs/3715535272/jobs/6300818879
However, Prometheus Federator does not add any workloads on top of Helm Project Operator (which means no additional PSPs) and Helm Project Operator passed in a 1.25 cluster in its own PR: https://github.com/rancher/helm-project-operator/pull/27

I'm removing flakey tests in this PR; will be tracked in https://github.com/rancher/prometheus-federator/issues/40


Add Videos to Tutorials

Description
Most of the tutorials (i.e., all of the first ~10 tutorials) should have a video that cover the described content.
That way the described tutorial is more accessible and - potentially - easier to follow.
Background
Having a video just shows the written content again and strengthens the presence of Piral on YouTube.
Discussion
Desired length is up to 5 minutes, but obviously it fully depends on the tutorial.
The tutorial should not just be read, but its contents should be transported. So its fine for the video to differ in wording, but technical flows should be used in the same way as in the written tutorial.

The videos are all online in our YouTube channel.
There is a playlist with the available tutorials: https://www.youtube.com/watch?v=ltTXWEwhSiY&list=PLQ9i8GS-LNXkHE8fbkU4Qwgbak4Rwjbg-


Change indentation in .json files to 4

Emacs version: 28.1
~/.emacs:
;;; .emacs --- My custom .emacs config.
;;; Commentary:
;;; Installs different packages for code linting and formatting to enable user feel Emacs like an IDE.
;;; Code:

(require 'package)
(require 'lsp-mode)

(add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/") t)

(defvar emacs-themes '(soft-stone-theme) "Themes installed as packages.")
(defvar emacs-linters '(flycheck json-mode yaml-mode markdown-mode) "Code linters installed as packages.")
(defvar emacs-language-servers '(lsp-mode lsp-pyright lsp-java) "Language servers installed as packages.")
(defvar emacs-formatters '(format-all) "Code formatters installed as packages.")
(defvar emacs-other '(company) "Other packages installed as packages.")

(defvar emacs-packages (append emacs-themes emacs-linters emacs-language-servers emacs-formatters emacs-other))
(dolist (package emacs-packages)
  (package-install package))

(setq emacs-language-servers '(bash-ls csharp-ls))
; (dolist (server emacs-language-servers)
;  (lsp-install-server nil server)) ; Reinstallation occures even when UPDATE? is nil

(defvar bookmark-save-flag 1)
(load-theme 'soft-stone t)
(setq-default tab-width 4)
(setq-default display-line-numbers 'relative)
(add-hook 'prog-mode-hook #'flycheck-mode)
(add-hook 'prog-mode-hook #'company-mode)
(add-hook 'prog-mode-hook #'format-all-mode)
(defvar emacs-hooks '(shell-mode-hook python-mode-hook java-mode-hook csharp-mode-hook c++-mode-hook))
(dolist (hook emacs-hooks)
  (add-hook hook #'lsp))
(defvar format-all-formatters '(("JSON" prettier)
				("YAML" prettier)
				("Shell" shfmt)
				("Python" black)
				("Java" clang-format)
				("C#" clang-format)))

(custom-set-variables
 ;; custom-set-variables was added by Custom.
 ;; If you edit it by hand, you could mess it up, so be careful.
 ;; Your init file should contain only one such instance.
 ;; If there is more than one, they won't work right.
 '(package-selected-packages
   '(lsp-java csharp-mode company lsp-pyright lsp-mode format-all yaml-mode json-mode markdown-mode flycheck soft-stone-theme)))
(custom-set-faces
 ;; custom-set-faces was added by Custom.
 ;; If you edit it by hand, you could mess it up, so be careful.
 ;; Your init file should contain only one such instance.
 ;; If there is more than one, they won't work right.
 )

(provide '.emacs)
;;; .emacs ends here

Steps to reproduce

Type the following json file:{
    "a": 1
}

Press C-x C-s and obtain decreased indention level

Here is how it looks in a real life config:

Pay attention to the last line with a comma in my JSON file: it's indented as expected when other lines have smaller indentation level.

https://prettier.io/docs/en/options.html
https://prettier.io/docs/en/configuration.html


istio-performance-dashboard: 11829 grafana dashboard not visible under https://grafana.com/orgs/istio/dashboards

Bug Description
Still mentioned with the others on https://github.com/istio/istio/blob/master/samples/addons/README.md#grafana
and https://github.com/istio/istio/blob/master/prow/release-commit.sh#L87
yet gone from grafana (the others are fine)
Version
1.14.5 but n/a

Additional Information
https://grafana.com/grafana/dashboards/7645/revisions now redirects to https://grafana.com/grafana/dashboards/7645-istio-control-plane-dashboard/?tab=revisions and is fine but not 11829 ( https://grafana.com/grafana/dashboards/11829/revisions )
also missing from https://grafana.com/orgs/istio/dashboards

looks like a bug in the grafana UI / redirect logic and attribution because
curl -v --connect-timeout 60 --max-time 60 -H 'Accept: application/json' -H 'Content-Type: application/json;charset=UTF-8' https://grafana.com/api/dashboards/11829/revisions/137/download

still works and gets 1.14.5 version

it seems ok now?

Yes, I think John fixed it, thanks!


Please help me.

I have a powkiddy x28 but I don't know which download link to use. Please help me.

Powkiddy x28 is not a supported device.  None of the available images will work for that unit as it is an Android Only device.

I have no idea.  I know nothing about this unit.


Nuxt 3 integration

Hi, trying to integrate this plugin with NUXT 3, I created this plugin:
import { createManager } from '@vue-youtube/core';

export default defineNuxtPlugin(({ vueApp }) => {
    vueApp.use(createManager());
});

But I get a Nuxt error:

500
document is not defined

at Object.install (./node_modules/@vue-youtube/core/dist/index.js:12:29)
 at Object.use (./node_modules/@vue/runtime-core/dist/runtime-core.cjs.js:4377:28)
 at ./plugins/youtube.js:7:12
 at fn (./node_modules/nuxt/dist/app/nuxt.mjs:151:27)
 at Object.callAsync (./node_modules/unctx/dist/index.mjs:49:19)
 at callWithNuxt (./node_modules/nuxt/dist/app/nuxt.mjs:153:23)
 at applyPlugin (./node_modules/nuxt/dist/app/nuxt.mjs:97:29)
 at Module.applyPlugins (./node_modules/nuxt/dist/app/nuxt.mjs:107:11)
 at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

For reference: the nuxt plugin needs to be marked as client only, and the youtube-iframe component wrapper with <ClientOnly>

Did you make it work? Because there is an open issue over at vue-youtube/vue-youtube#4. I was unable to make it work because of multiple errors.

@Techassi yes its all working now with that change I mention


"javascript.suggest.completeFunctionCalls" but without parameter signature.

When "javascript.suggest.completeFunctionCalls" is enabled, VS Code always complete its parameter signatures, doesn't that conflict with the ParameterHints feature?
It would be nice if we have another option for it instead of just on and off.
For example:
{
    "javascript.suggest.completeFunctionCalls": "always",
    "javascript.suggest.completeFunctionCalls": "withoutParameterSignature",
    "javascript.suggest.completeFunctionCalls": "never"
}

After:

Duplicate of #109997


Example Not Working : ChartsExplorer

Not able to configure the example project.
following instruction given in here
on giving command
" pod install " inside projects ios folder this is what I am getting in response.
Analyzing dependencies
Pre-downloading: Charts from https://github.com/danielgindi/Charts.git, commit 2dd22b903a78d0d34d07ef71728c41ac22f6a114
[!] Error installing Charts
[!] /usr/local/bin/git -C /var/folders/nz/9d7wt8wx2sgg674ycggp3p2w0000gn/T/d20170308-767-km5q0s checkout --quiet 2dd22b903a78d0d34d07ef71728c41ac22f6a114
fatal: reference is not a tree: 2dd22b903a78d0d34d07ef71728c41ac22f6a114
Thanks.

you can try the new project react-native-charts-wrapper which merged iOS and Android platform.

@L-Jovi : Thank You very much. Will try the new one.


This shell script:
#!/bin/bash
export RESTIC_PASSWORD=my_key_goes_here
export RESTIC_REPOSITORY=sftp:root@<IP_ADDRESS>:/mnt/user/backups/restic/monorepo

restic backup /boot --tag storage1-flash -v

This is running on Unraid, in this case /boot is my boot drive, but this issue appears when backing up any directory on the system.
What backend/server/service did you use to store the repository?
SFTP to a second unraid server.
Expected behavior
restic should back up to the remote server without issue from my local system.
Actual behavior
Backup succeeds initially, then any further runs fail with the following error:
repository 792e6a71 opened (version 2, compression level auto)
using parent snapshot c9707c94
invalid character '\x04' in string literal
DecodeIndex
github.com/restic/restic/internal/index.DecodeIndex
/restic/internal/index/index.go:523
github.com/restic/restic/internal/index.ForAllIndexes.func1
/restic/internal/index/index_parallel.go:29
github.com/restic/restic/internal/restic.ParallelList.func2
/restic/internal/restic/parallel.go:45
golang.org/x/sync/errgroup.(*Group).Go.func1
/home/build/go/pkg/mod/golang.org/x/sync@v0.3.0/errgroup/errgroup.go:75
runtime.goexit
/usr/local/go/src/runtime/asm_amd64.s:1598
If I delete the cache located at the directory that restic cache spits out, I can then run a backup again successfully.
Steps to reproduce the behavior
This is entirely reproducible on my primary Unraid storage server - the first time that a restic backup is run will succeed, any further attempts will fail with some variant of 'invalid character in string literal'. Sometimes the character is '\x04', sometimes '\x00', or others. After deleting the local cache directory a backup will succeed again.
This has been occurring for months for me, on various versions of restic, including the latest.
I am able to successfully back up to this same repository from many other machines, windows, mac, and linux over SFTP.
Do you have any idea what may have caused this?
Unsure but I suspect it's some behavior unique to the Unraid OS.
Do you have an idea how to solve the issue?
Did restic help you today? Did it make you happy in any way?
I love restic, I hope this issue can get solved :)

This is entirely reproducible on my primary Unraid storage server - the first time that a restic backup is run will succeed, any further attempts will fail with some variant of 'invalid character in string literal'. Sometimes the character is '\x04', sometimes '\x00', or others. After deleting the local cache directory a backup will succeed again.

This is very likely a hardware problem (either CPU or RAM) or a serious bug in the OS. DecodeIndex() only runs after decrypting and verifying the integrity of the loaded index. This leaves only two possibilities how this data corruption can occur: either when writing the index during a backup (not the case as other machines can access the repository) or while decrypting / processing it. With the given information, the latter is the most likely explanation.

After deleting the local cache directory a backup will succeed again.

That is likely just a coincidence. If the cached data on disk were corrupt, then restic would print a different error message.

Thanks for the reply. I will see if I can troubleshoot the hardware to rule it out.

After deleting the local cache directory a backup will succeed again.

That is likely just a coincidence. If the cached data on disk were corrupt, then restic would print a different error message.

It definitely is not a coincidence - after running the first backup and having the local cache created, all further backup attempts will fail 100% of the time. Deleting the local cache directory immediately resolves this problem for a single backup, which creates the cache files, and then further backups continue to fail 100% of the time.

could you run shasum -a256 path/to/cache/index/*/* with such a damaged cache? The sha256 hash should match each file's filename.
Please also use shasum to verify the file in the repositories index folder.

I used the following commands to test the index folders as you asked:
On the local machine
shasum -a256 /mnt/user/appdata/.restic_cache/792e6a71d1b3ba8ba5b70608f63298b3555c9bdb6d0025a2a56d739380a1286f/index/*/* | awk '{split($2, a, "/"); if ($1 != a[length(a)]) print $0}'
On the remote repository:
shasum -a256 /mnt/user/backups/restic/monorepo/index/* | awk '{split($2, a, "/"); if ($1 != a[length(a)]) print $0}'
I tested the command by intentionally editing one of the file names in the cache, which it properly identified as a mismatch. Both of these commands yielded no mismatch between the file names in the index folders and their hashes.

Hmm, if the cache content isn't damaged, then the only difference between downloading and using the cache version is timing. In particular, with an already filled cache, restic is likely to put more stress on the hardware than when having to download the files from scratch. That suggests that the hardware becomes unstable under load or on sudden load changes.
Does setting the environment variable GOMAXPROCS=1 change anything?

GOMAXPROCS=1 actually seems to have fixed things. I adjusted my scripts to set this and so far things look good.

Thanks for the reply. As that behavior neatly fits with some weird things happening in the hardware, I'll close the issue for now. Feel free to reopen it if something changes.


Build dependency (emscripten) not downloaded

Not so long ago, emscripten was added as a dependency when building dart-sdk.
It is needed only (for now) for some ffi tests in utils/dart2wasm module.
This was found by building dart-sdk for Windows on Arm with this command:
python3 ./tools/build.py --arch arm64 --mode release

and fails with this:
FAILED: wasm/ffi_native_test_module.wasm
<EMAIL_ADDRESS>../../build/gn_run_binary.py compiled_action C:/ci/457aV6KG/0/Linaro/windowsonarm/nightly/dart/sdk/third_party/emsdk/upstream/emscripten/emcc --no-entry C:/ci/457aV6KG/0/Linaro/windowsonarm/nightly/dart/sdk/tests/web/wasm/ffi_native_test_module.c -o C:/ci/457aV6KG/0/Linaro/windowsonarm/nightly/dart/sdk/out/ReleaseXARM64/wasm/ffi_native_test_module.wasm -O
Binary not found: C:\ci\457aV6KG\0\Linaro\windowsonarm\nightly\dart\sdk\third_party\emsdk\upstream\emscripten\emcc

Other platform are probably concerned too.
This PR added workaround to allow emscripten to download x64 toolchain when building for Windows on Arm. However, that's not enough, as this download is not enabled by default:
https://github.com/dart-lang/sdk/blob/a1b669fda1e238845784edebfc859d1cc57cba6f/DEPS#L197

Should we enable this download by default, or deactivate concerned test if download_emscripten is not true?
https://github.com/dart-lang/sdk/blob/a1b669fda1e238845784edebfc859d1cc57cba6f/utils/dart2wasm/BUILD.gn#L56
That would be nice to get dart-sdk to build without adding any build target or gn args, as it was the case before introduction of this dependency.

@athomas @osa1


Azure pipelines improvements

All CI tests pass!

Merged. Regarding that conftest - did you check that tests work not in docker?

Merged. Regarding that conftest - did you check that tests work not in docker?

Merged. Regarding that conftest - did you check that tests work not in docker?

@aeantipov Yes, if you put the correct path to python2 in tests/host_environment.yml it works. If you don't, it never worked before, but now falls back to a default that is correct in the Docker image.


Link to docs.rs documentation page from each crate README

Closes #155

Thanks for the PR!
As the README files are auto-generated by scripts/makecrates.py it would be better to add the change there (in the README_TPL template, where {crate} will expand to stm32f0 etc), otherwise the changes will be overwritten every time the script is run (to add a new device or update version number, etc).
The actual change to the README itself looks great.

Ahh I didn't realize that, thanks. I'll get that fixed up today.


Fix compatibility issues with UFW Firewall

This fixed no tunnel connectivity issue for me using UFW

LGTM

Tested 👍 thanks!


Create file structure, add sample test for scrape function

Created a structured project to improve aspects related to scalability(to eventually evolve into a simple  API).

Thanks for this PR. Unfortunately I can't merge it as it stands.
This adds a lot of binary files as well as .DS_Store files. These are undesirable so I won't merge them in.
I like what you've done with the package structure but you've changed the namespace so it's not in line with the repository (I'm pretty sure I don't want the html pacakge sources in the repo, there is a tool that lets you manage dependencies that way but without committing the sources).
I think the correct way to add these changes is check out this repository as normal
go get -u github.com/sleepypikachu/still-good-food
Then add your clone as a remote so that you preserve the namespace and commit to the clone. If you want to set it up so that it works with an internalised copy of the repos then feel free to check out godep which I would merge if it works.
Very interested in seeing how your tests work so I hope you can get those running but currently I'm having difficulty running them.

Thanks for the feedback. I’ll get to it immediately. I like the way this scraper can be used a simple API for building applications(food related) for IOTG devices such as the Amazon Echo(as BBCfood, as per my knowledge, does not have its own API).
-Vikhyath Mondreti

On 25-Jun-2016, at 5:15 PM, sleepypikachu<EMAIL_ADDRESS>wrote:
Thanks for this PR. Unfortunately I can't merge it as it stands.
This adds a lot of binary files as well as .DS_Store files. These are undesirable so I won't merge them in.
I like what you've done with the package structure but you've changed the namespace so it's not in line with the repository (I'm pretty sure I don't want the html pacakge sources in the repo, there is a tool that lets you manage dependencies that way but without committing the sources).
I think the correct way to add these changes is check out this repository as normal
go get -u github.com/sleepypikachu/still-good-food
Then add your clone as a remote so that you preserve the namespace and commit to the clone. If you want to set it up so that it works with an internalised copy of the repos then feel free to check out godep which I would merge if it works.
Very interested in seeing how your tests work so I hope you can get those running but currently I'm having difficulty running them.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/sleepypikachu/still-good-food/pull/2#issuecomment-228535445, or mute the thread https://github.com/notifications/unsubscribe/ARHpBsNo49duewzUosonIN8715F8eV96ks5qPRTfgaJpZM4I-UYl.

Fixed the issues. Tests should work (using go test in the food folder).
-Vikhyath Mondreti

On 25-Jun-2016, at 5:27 PM, Vikhyath Mondreti<EMAIL_ADDRESS>wrote:

go get -u github.com/sleepypikachu/still-good-food http://github.com/sleepypikachu/still-good-food

Hi Vikhyath,
Thanks for fixing these issues. I'm really keen to get these changes in but the repository is still organised strangely. You seem to have committed an entire gopath rather than a single repository. When I switch to your branch from my checkout main.go and the food package end up:
$GOPATH/src/github.com/sleepypikachu/still-good-food/src/github.com/icecrasher321
but they should end up
$GOPATH/src/github.com/sleepypikachu/still-good-food/
This is significant because go build doesn't work in the correct path with your changes. At this point the easiest thing to do is probably to repatch your changes by hand into a fresh copy of the repository.
To achieve this:
Check out the current master from this repository
go get -u github.com/sleepypikachu/still-good-food
Head into the repo
cd $GOPATH/src/github.com/sleepypikachu/still-good-food
Manually copy in your changes, such as the new main.go and food/Scrape.go without the breaking changes like committing goquery (Don't forget to run go fmt on all your sources!)
Make sure you can run go build and go test at the root of the repository.
Then set up a new remote and push your changes to that (you probably want to create a new branch on your repo from before your first commit for this since we don't want to muddy the history with adding and removing your other changes!)
Once you've pushed your changes to the new branch then we should be good to go if you set up a new pull request :-) Feel free to ping me if you get stuck.

See https://github.com/sleepypikachu/still-good-food/pull/3#issuecomment-228553503


Remove unnecessary RefCell from FileSource

Which issue does this PR close?

Closes #.
Rationale for this change

This isn't actually necessary
What changes are included in this PR?

Are there any user-facing changes?

Closing in favour of #4156


Updated SimpleLineIcons link in README to a github hosted link

The SimpleLineIcons website goes down more often than necessary, as such a new website has been made using github's hosting:
https://simplelineicons.github.io/
I have updated the link in the README.md file.

OK, that's weird. This is not the official website so I feel somewhat uneasy linking to it, but with the official one down and no indication of that changing let's merge this 👍


Allow optionally forwarding the client cert if one is provided

Allow a client cert to be optionally provided and its details forwarded to the cluster.
Description:
Right now Envoy only forwards client cert information (through forward_client_cert_details) if a validation context is provided. We would like to allow clients to optionally validate through client certs by having the details forwarded to the backing service that, itself, does the validation. This is not currently possible because the client cert details are only forwarded if a client cert is required.
This change would allow client cert details to be forwarded if the property is set to SANATIZE_SET regardless of whether the client cert is required.

This makes sense to me. @PiotrSikora @lizan any concerns here?

Sounds fine to me.

SGTM


Add event for the default rule "Adding ssh keys to authorized_keys"

Motivation
As there is a default rule Adding ssh keys to authorized_keys here So adding event for it will be really helpful.

Feature

Alternatives

Additional context

/assign


work with multiple nodes

(optionally) share the counts across erlang nodes. Maybe with mnesia

options:

sharding ets (https://github.com/cabol/shards)
mnesia (easiest)
riak core (each key has a specific node that manages the data)
crdts (check lasp)

I think it is a great idea to use a driver strategy and implement a driver for each option. It is a good way of learning more advanced erlang architecture and it will be really interesting to do some benchmark comparison.

created issues for each multi node driver, closing this one.


if vue has iframe in page, the router will not back to previous page

What problem does this feature solve?
I have 2 pages
pages/a.vue
pages/b.vue

a push b use $router.push, b.vue has a navbar with back button and a  in the template, if the iframe has some redirect to other url, the browser history will be changed, at this time i use router.go(-1) on navbar back button in b.vue , it actually operating on iframe's back not the router's previous page, if many redirect in iframe, user will back so many times to page a , I want it back to pages/a just click once.
What does the proposed API look like?
have a list of the router push history, when back button clicked, have a way to confirm which page I really want to back to.

Please follow the Issue Reporting Guidelines and provide a minimal JSFiddle or Github repository containing a set of reproducible steps that can lead to the behaviour you described. Make sure to boil down the problem as much as possible. Thanks!
It can also be a simple HTML file

Closing due to inactivity. Please open a new issue with a reference to this one if you can follow up with more information.

@posva  I am seeing this as well, though I only just realized it and ( on a mac at least ) I am only seeing it in Chrome. The back button works as expected in Firefox and Safari. In Chrome the first back press does the iframe on the page and the second does what I expect. Any chance it could be a Chrome issue? The route looks like
path: 'stream/:findBy',
props: true,
etc.....

It could be but I need a simple repro like a repo with some basic html files to check 🙂

Sorry, I should have noted I opened a new issue here: https://github.com/vuejs/vue-router/issues/2403, I hope that helps isolate it.

I'm using a key prop for the component, it seems to work. When data changed, state of child component will be reset or child will be recreated which contains the iframe element.
  watch: {
    data() {
      // this.$forceUpdate();
      this.renderCount++;
    },
  },

    <component
      :is="component"
      v-for="(item, i) in filteredData"
      :key="i + '-' + renderCount"
      v-bind="Object.assign({ index: i, dataTestKey: i + '-' + renderCount }, item, props)"
      v-on="getHandlers(item, i)"
    />


added lfe-doc-finder

It is a work in progress that is supposed to help with autocompletion and documentation lookup

Two things:

Could you please rebase this to the develop branch instead as I never pull into the master branch?
Could please add an open source reference licensing this under the Apache License V2.0 as in the other emacs files as I only include open source files in the distribution? You name of course.

Thank you

Ok, I will do it tomorrow.
On 9 January 2017 at 17:59, Robert Virding<EMAIL_ADDRESS>wrote:

Two things:

Could you please rebase this to the develop branch instead as I
never pull into the master branch?
Could please add an open source reference licensing this under the
Apache License V2.0 as in the other emacs files as I only include open
source files in the distribution? You name of course.

Thank you
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/rvirding/lfe/pull/315#issuecomment-271356494, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAX9MqKKxaxlyHcduefETe5NPAWa3fY3ks5rQnVygaJpZM4LdpwU
.

I'm going to apply the suggestions and create a PR for develop branch


Array value objects don't work

Describe the bug
Array types don't work apparently:

Repro:
using Vogen;

Hash hash = Hash.From(new byte[] { 1, 2, 3 });

[ValueObject<byte[]>]
public readonly partial struct Hash;

Also, the README claims that "any type can be wrapped", which does not actually seem to be true.

Repro:
using System.Collections.Immutable;
using Vogen;

[ValueObject<ImmutableArray<int>>]
public readonly partial struct Hash;

Am I missing something?
Steps to reproduce
Outlined above.
Expected behaviour
Should just work.

Collections aren't supported because they don't exhibit value semantics. For instance, a Hash.From([1, 2, 3]) == Hash.From([1, 2, 3]) is false.
Also, serialization probably wouldn't work for collections, e.g. when [ValueObject<IEnumerable<byte>>] and instantiating with `Hash.From([1,2,3]) (an array)

An alternative is to use a "deep-equatable" array, and have that as the underlying type for a value object.
Here is such an array implementation:
https://github.com/eiriktsarpalis/typeshape-csharp/blob/main/src/TypeShape.Roslyn/IncrementalTypes/ImmutableEquatableArray.cs
You can then do:
[ValueObject<ImmutableEquatableArray<byte>>]

Actually, that won't work either, as it delves into the hierarchy to see if it's a collection.
This works, kinda:
public class Hash<T> : IEquatable<T> where T : IEquatable<T>
{
    private readonly ImmutableEquatableArray<T> _items;
    public Hash(T[] items) => _items = items.ToImmutableEquatableArray();

    protected bool Equals(Hash<T> other) => _items.Equals(other._items);

    public bool Equals(T? other) => _items.Equals(other);

    public override bool Equals(object? obj) => _items.Equals(obj);

    public override int GetHashCode() => _items.GetHashCode();

    public static implicit operator Hash<T>(T[] items) => new(items);
}

[ValueObject<Hash<byte>>]
public readonly partial struct FileHash;

The only reason it doesn't currently work is that Vogen emits incorrect triple-slash comments when the underlying type is a generic - which I'll fix soon.
To be honest, I'm now re-thinking the whole thing of constraining the underlying type so that it can't be a collection.
Leave this with me, and I'll think it over again. Thanks for your input, and if you have any thoughts or suggestions on this topic, please let us know.

Also, for array, I don't know what ToString would do by default...

After careful consideration, I've left the restriction on ICollection, purely because it enables an easy way to mutate the data in the value object, which Vogen goes to considerable lengths (via the analyzers) to stop.
However, you can achieve the same result by using an intermediary underlying type that wraps your collection. I've added an example test to demonstrate.
Thanks for reporting - please let me know if you need any further assistance or clarification

Wouldn't it be feasible then to only allow immutable collection types?


Enhancement: Charset with similar characters excluded

Hello, I wonder if additional charsets could be added, that would exclude visually similar characters, e.g. O vs. 0 or l vs. I vs. 1.
Additionally, letters Z and Y are swapped in many european countries, so we tend to not include Z, z, Y, and y in password charsets.
The easiest and most universal solution would probably be to add a user-defined custom charset that would be read from a configuration file during app init.

What the problem with letters Z and Y?

What the problem with letters Z and Y?

That's a central European thing. In Germany for example, many developers have both DE/DE keyboard layout (QWERTZ) and EN/US keyboard layout (QWERTY) configured on their computers and switch between them regularly. They then tend to type Z instead of Y and vice versa and not notice such mistakes in masked password fields (***********), which then sometimes leads to account lockouts. IT workers in Germany, Austria, Poland, Switzerland, Czechia, Slovakia, Croatia, or Hungary thus prefer having passwords that do not contain letters Y and Z.
As I was saying, it is impossible to satisfy all users with predefined character sets, so a user-defined custom charset would be a great feature.


URLs to be allowed when using dialogflow-android in restricted network. . .

I am using dialogflow integrated android-application in restricted-internet environment. . . Can some one give me a list of URLs that I need to WHITELIST so that the application's dialogflow part has access to internet inside restricted-internet environment. . . I completely understand that this information can't be shared, but this is something much required by many people who are security conscious. . .

I do not have list of URLS, but I can give you some advice:

APIs are open, you can probably find URLs in docs https://cloud.google.com/dialogflow/docs/reference/rest/v2-overview, depending on what version of protocol you are using.
When you issue query from Dialogflow console, there is Copy Curl button there, it contains URL.
If you use client library, you can probably find urls in source code, I think all dialogflow libraries are opensourced.
You can try to use network sniffer to sniff URLs out. For instance you can install one on your laptop and run your app in android emulator on your laptop.


WEBSITE_CONTENTAZUREFILECONNECTIONSTRING docs update?

This section states:

Only used when deploying to a Consumption or Premium plans running on Windows. Not supported for Linux. Changing or removing this setting may cause your function app to not start. To learn more, see this troubleshooting article.

The setting appears to be supported for Linux Functions Premium plans. Likewise, for the closely related "WEBSITE_CONTENTSHARE".

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 18aa54fd-3aa1-37c5-925c-51a0195b1030
Version Independent ID: 60198016-1ea9-e7ae-b00b-2c665d5ad8ca
Content: App settings reference for Azure Functions
Content Source: articles/azure-functions/functions-app-settings.md
Service: azure-functions
GitHub Login: @ggailey777
Microsoft Alias: glenga

Hello @vlkuznet,
Thank you for your feedback! We will review and update as appropriate.

Hello @vlkuznet,
Thank you for your feedback! We will review and update as appropriate.

@vlkuznet Functions on windows and Linux work differently. Those settings are not needed/ expected for Linux function apps. Also, for Linux it is recommended to use the run from package instead and/or use a container. Did you encounter any issue when you don't include these settings?

@vlkuznet Functions on windows and Linux work differently. Those settings are not needed/ expected for Linux function apps. Also, for Linux it is recommended to use the run from package instead and/or use a container. Did you encounter any issue when you don't include these settings?

@vlkuznet thanks for point this out. It seems that I screwed-up in my recent update to this article. The linked PR in our private repo will fix this to read as mentioned by Jaya.

@vlkuznet thanks for point this out. It seems that I screwed-up in my recent update to this article. The linked PR in our private repo will fix this to read as mentioned by Jaya.

@vlkuznet  Thanks for reporting this item! The author has updated the doc ( Thanks to @ggailey777) and it will be published soon. We appreciate the feedback! We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.

@vlkuznet  Thanks for reporting this item! The author has updated the doc ( Thanks to @ggailey777) and it will be published soon. We appreciate the feedback! We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.


Controller/Guns Tilted

Hey everyone,
I'm running v2.4.0-alpha5 on my Oculus Quest. I also installed the controller patch as referenced in #491 which got both my Oculus Quest controllers working (although in SteamVR they model after the gen1 Rift touch controllers vs the new Quest/Rift S touch controllers. Interestingly enough, when in-game in Half Life Alyx they seem to update to the new touch controllers).
I'm still having the same problem as brought up in #356 and was wondering if there's been a fix since the issue was originally posted over a year ago. I've done a bunch of googling and am at a loss.
Thanks!

Please check this fork made for the quest:
https://github.com/JackD83/ALVR


Settings system

This is big one, and the earliest commits only modify a line or two here and there in the current source. Everything else is a brand-new addition. The new MGSFragariaViewModern demo still needs a lot of work, but for now it demonstrates the new settings panels.
The demo doesn't demonstrate it yet, but the idea is the panels can be used for user defaults, but also for non-persistent changes. Tomorrow I'll revamp the demo app to take advantage of those, but this is a useful preview.

Nice!
(Before you add something to the bottom of them, the new prefpanes almost take the whole screen height on a 13'' screen. They should just fit on a 11'' screen, though I didn't check.)
The second view shows the wrong text color because the text color is stored in the text storage, which is shared. I filed bug #71 for this.

Issue seems resolved. I'll be sure not to add any height.


Added strikethrough prices on PLP & PDP

Hey @SGD1953! Sorry for the delayed response. I'm reviewing your contribution--looking good so far 👍 -- and will post next steps soon.
CC @bfeister

@SGD1953 Would it be difficult to apply strikethrough pricing (which doesn't require a coupon code) beyond the PDP and PLP pages? For example, strikethrough pricing in the cart page.

It is not difficult, the main question is where to get the information from. The cart APIs don't provide the list price, thus it would require a hook like for the PLP to add it in. For the PLP I have built it so that if the custom hook is not there the strike price will disappear.
@hnestmann any plans to add list price for basket imtes to the hooks collection?

@hnestmann any plans to add list price for basket imtes to the hooks collection?
No plans so far, but feel free to create an issue in the repo. Should be fairly straight forward to plonk the product extend call in basket APIs

Issue created https://github.com/SalesforceCommerceCloud/sfcc-hooks-collection/issues/29

@SGD1953 @hnestmann rather than hold this up, Nathan Marcus and @uxphilforce and I discussed, we're going to default this to be hidden behind a config variable (a constant, specifically) until it works end to end.
@SGD1953 can you add  const SHOW_STRIKETHROUGH_PRICE = false to the constants file here and then make the feature shown conditional on that being set to true?
https://github.com/SalesforceCommerceCloud/pwa-kit/blob/develop/packages/template-retail-react-app/app/constants.js#L52-L64

@bfeister before I do that, let me explain again the current behaviour. Currently the strike-price (was price) will be show on PDP and omitted on PLP. Once you plug in the cartridge from https://github.com/SalesforceCommerceCloud/sfcc-hooks-collection strike prices will be shown on both PLP & PDP. That would be an improvement of current behaviour (strike-price on PDP) in any case and with a small extra step one would get both. It will also be easier to setup/demo and one does not need to fiddle with the code to get things enabled. The frontend will have the capability one the APIs supply the data.

@SGD1953 @hnestmann rather than hold this up, Nathan Marcus and @uxphilforce and I discussed, we're going to default this to be hidden behind a config variable (a constant, specifically) until it works end to end.

This bears the risk of starting a pattern of making too many things configurable and ending up with tons of configs (puma has more then 1000 after 7 years of SFRA). I might be mistaken, but I don't know any shop without a strike price - it's just like this in pwa kit due to a shortcoming of SCAPI / OCPAPI

@hnestmann I'm comfortable with that risk. We will move forward. We already use the pattern, we will continue to monitor constant.js as a centralized place for reasoning about our level of combinatorial complexity. Currently it is low and I'd like to move forward with this.
@SGD1953 I think I didn't realize this appears on only on the PDP and not PLP. In that case, all the more reason to put it behind a feature flag per my description

@bfeister Can we go ahead and close this one due to inactivity?

Closing due to inactivity, can re-open as needed


Errors using OpenGL and DirectX 11 BackendType

Choosing Wgpu.BackendType.OpenGL or Wgpu.BackendType.D3D11 as the backend type on Windows for RequestAdapter results in the error
Unhandled Exception: WGPU.NET.ResourceCreationError: There has been an error creating this Adapter, handle was null
   at WGPU.NET.Adapter..ctor(Wgpu.AdapterImpl) + 0x3a
   at WGPU.NET.Instance.<>c__DisplayClass10_0.<RequestAdapter>b__0(Wgpu.RequestAdapterStatus s, Wgpu.AdapterImpl a, String m, IntPtr _) + 0x38

DirectX 12 and Vulkan work fine.
Also of note, the latest webgpu headers now have WGPUBackendType backendType; as part of the WGPURequestAdapterOptions struct. Annoyingly, they've also added another enum to WGPUBackendType, WGPUBackendType_Undefined = 0x00000000, which offsets all of the previous enums, where WGPUBackendType_Null was originally 0x00000000.
No idea if this is easier to wrap now that you don't have to use a chained struct (correct me if I'm wrong), and also no idea if that will manage to resolve some of these adapter handle issues. I would imagine the problem runs a bit deeper, but I'm not sure where to look.

This is an issue with wgpu-native, not the bindings.


Place to Upload

Create a datadog user in MySQL and grant it permission to run metric queries on your behalf.
Copy Datadog’s conf.d/mysql.yaml.example template to conf.d/mysql.yaml to create a configuration file for Datadog.

/etc/datadog-agent/conf.d/mysql.d/conf.yaml.example

Add the login credentials for your newly created datadog user to conf.d/mysql.yaml.
Restart the Agent.

MySQL

Getting my_metric

The  instances shouldn't have an indent
init_config:

 instances:
    - min_collection_interval: 30

Alert Conditions

email template

https://docs.datadoghq.com/agent/faq/how-datadog-agent-determines-the-hostname/?tab=agentv6
sudo /etc/init.d/datadog-agent info

Usage: /etc/init.d/datadog-agent {start|stop|restart|status}

Downtime

Monitor email

ddtrace-run not found even after installing pip install ddtrace.

https://www.datadoghq.com/blog/monitoring-flask-apps-with-datadog/#capturing-traces-and-logs-from-your-flask-app
mkdir conf.d/python.d # Create a Python config directory under conf.d vi
conf.d/python.d/conf.yaml # Create and open the config file`

Should be
mkdir conf.d/python.d # Create a Python config directory under conf.d
vi conf.d/python.d/conf.yaml # Create and open the config file

Configuration file has incorrect formatting on https://www.datadoghq.com/blog/monitoring-flask-apps-with-datadog/#configure-the-python-integration.

https://docs.datadoghq.com/logs/log_collection/python/#configure-the-datadog-agent

'Simple' has a number of requirements and likely should link to docs instead.

https://www.datadoghq.com/blog/monitoring-flask-apps-with-datadog/#update-the-python-code
Formatting of Python is incorrect

Directions for configuring Python should suggest enabling APM in agent : https://docs.datadoghq.com/tracing/setup/#agent-configuration.

I had an issue where i had python set up on a non-root user account that didn't have access to ddtrace-run.

Running into ["400", {"errors"=>["The 'definition' parameter is required for all graphs"]}]

Documentation for https://docs.datadoghq.com/graphing/dashboards/widgets/#timeseries should indicate that it will also have a field definitation that can be obtained from an existing Dashboard (JSON).

Anomaly screenshot

Combined mix


DNS and AllowedIP as Global Config

Is your feature request related to a problem? Please describe.
Currently, you need to type everytime again the dns servers for every peer
Also, AllowedIPs ist <IP_ADDRESS>/0 default which is not good if u just want specific ips

Hi, yes this function has been added already.

Where can i find it? I only find <IP_ADDRESS>/0 in conf_get.html but not in the Dashboard

I haven't commit the newest one yet. There's still some bug need to be fix


Added Optional Registration Parameter (as a Map)

Client can now be passed a free-form map of registration query parameters.
Some context :
I have a custom ClientRegistry, that will respond to Register requests with an extra, non-standard "imei" parameter. It needs to do some validation on this parameter.
Rather than adding yet another field to the RegisterRequest, I added a free-form map (String to String) with all register query parameters. (Sounds future-proof enough)
I initially though about passing the RegisterRequest object in ClientRegistry.register, but I suppose this would break backward compatibility. So instead, I attached the parameter map to the client itself.
(An alternative would be to have two register method with different arities , and using defaults methods - but is leshan supposed to be compiled for java 8 compatibility ?)
What do you think ?

It's pretty strange to add query params to RegisterRequest and Client.
I mean why just this CoAP option ? and why just on Register Request ?
I think if we want to expose CoAP information in Leshan API, we must have a more global thought about that.
Currently, I see 2 possible solutions :

add a Object getCoapRequest() on lwM2mRequest and Object getCoapResponse() on lwM2mResponse, return type wil depends of the CoAP implementation used by Leshan.
expose our own minimalist CoAP message abstraction. A CoAP message is mainly a type, a code,  a payload and a set of option.

Having access to CoAP messages is a good idea, but I don't think it's the good level in the stack.
LWM2M is modeled on top of REST and is going to be ported to HTTP/2 & MQTT, I  would prefer to expose common REST concepts like URL & parameters.

I like the idea of being able to process not only standard query params but also have access to all query params submitted by a client.
@sbernard31, I do not see a general need to have access to basic CoAP concepts like codes and options which in my opinion should not be exposed to user space code. I do see value though in exposing application level information contained in URL and query params as @jvermillard already pointed out. We could extend LwM2mRequest with methods to get access to  query parameters and URL for that purpose. Consequently, we should then also provide access to this information in upstream listeners like the ClientRegistryListener.

@sophokles73 : after some discussions with @sbernard31 and @jvermillard , here is another proposition : it's basically the same except we only add the "other" parameters in a free-form map. This way :

it's still open enough to support extra params
this is not as far reaching a adding info to all requests (which is a bit of an overkill ; and we're not sure which abstraction we would expose that is not too tied to a particular coap implementation)

As the Client constructor was getting too big, I took the liberty to add a Builder pattern - that can be a separate topic if you prefer.

I am ok with the approach of adding the additional registration attributes.
I also love the introduction of a Client.Builder :-) I don't think that we need a separate PR for it but maybe have a separate commit?

@sophokles73 I renamed the map, and made it unmodifiable.
I'd rather keep everything in a single commit ( my git-fu is not strong enough to separate the past commits without breaking or having to rewrite stuff, and @sbernard31  will be squashing things anyway :) )

I see, no sweat.
@sbernard31: +1 for merging then :-)

Integrated in master (commit a3eb59dd782da8d6fe6deb04155e89c15acd9d3d)


proposal: permit blank (_) separator in integer number literals

This has come up before, specifically during discussions of #19308 and #28256. I am writing this down so we have a place for discussing this independently. I have no strong feelings about this proposal either way.
Proposal
This is a fully backward-compatible proposal for permitting the use of a blank (_) as a separator in number literals. Specifically, we change the integer literal syntax such that we also allow a "_" after the first digit (the change is the extra "_"):

int_lit     = decimal_lit | octal_lit | hex_lit .
decimal_lit = ( "1" … "9" ) { decimal_digit | "_" } .
octal_lit   = "0" { octal_digit | "_" } .
hex_lit     = "0" ( "x" | "X" ) hex_digit { hex_digit | "_" } .

And we change the floating-point number literal syntax correspondingly (the change is the extra "_"):

float_lit = decimals "." [ decimals ] [ exponent ] | decimals exponent | "." decimals [ exponent ] .
decimals  = decimal_digit { decimal_digit | "_" } .
exponent  = ( "e" | "E" ) [ "+" | "-" ] decimals .

For complex number literals the change is implied by the change to floating-point literals.
Examples:
123_456_789
1_000_000_000
0b0110_1101_1101_0010  // if we had binary integer literals
0xdead_beef
3.1415_9265

but also:
0___         // 0
0_77         // 77 decimal, or perhaps not permitted (TBD)
01_10        // 0110 (octal)
1_2__3___    // 123
0x1_23_0     // 0x1230
0__.0__e-0__ // 0.0e-0

Discussion
The notation follows more or less the syntax used in other languages (e.g., Swift).
The implementation is straight-forward (a minor change to the number scanner). As the examples show, the separator, if judiciously used, may improve readability; or it may degrade it significantly.
A tool (go vet) might impose restrictions on how the separator is used for readability.

What would be the reason for allowing the underscore to appear anywhere instead of limiting it to (multiples of) commonly used places?
1_000_000_000
0xDEAD_BEEF
0b0101_1111_0001

What would be the reason for allowing the underscore to appear anywhere instead of limiting it to (multiples of) commonly used places? E.g.,
1_000_000_000
0xDEAD_BEEF
0b0101_1111_0001

ISTM being too permissive only degrades readability.

I agree. Though, it’s always possible to make the language more permissive in the future without breaking existing programs. The reverse isn’t true.
Envoyé de mon iPhone

Le 30 oct. 2018 à 16:27, Damian Gryski<EMAIL_ADDRESS>a écrit :
@ericlagergren It seems more Go-like to leave the grammar more free-form with regards to placement of _, but leave the enforcement of style (how many digits in each group) to tooling and code review.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@ericlagergren What's a commonly used placement of _? That's really difficult to impossible to answer and shouldn't be decided by the language. Also, note that other languages also don't try to pin that down.

Well, if you asked me, I’d say:
decimals: 3
hex: 2, 4, ...
octal: ??
binary: 2, 4, 8, ...
But I get your point. :)
Envoyé de mon iPhone

Le 30 oct. 2018 à 16:51, Robert Griesemer<EMAIL_ADDRESS>a écrit :
@ericlagergren What's a commonly used placement of _? That's really difficult to impossible to answer and shouldn't be decided by the language. Also, note that other languages also don't try to pin that down.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

I think this is an excellent idea if we are to have binary literals (which otherwise become unreadable after one or two bytes) and also helps with the readability of other long numbers.
Several other languages have a similar feature.
As far as placement is concerned, we'll just have to leave that to the good taste of gophers :)

I don’t think this improves readability. For example, which is more readable?
x := 100000000
y := 100_000_000
const million = 1000000
z := 100 * million
The latter is, IMO, the more descriptive, leverages the qualities of untyped constants, the lineage of the time package, and exists today without new syntax.

Are there any concrete examples of existing code where this would help readability significantly? Adding a separator does make sense for big numbers but are they common enough to warrant changing the language for?
I've spent a bit of time working with Swift code and in my limited experience I've seen that underscores tend to get used inconsistently. I think they end up making it harder (for me anyway) to parse the code.
Go already has quite a few ways to write constants, I'm not sure we need more.

When programming in other languages which have digit separators (C#, Java, Kotlin), I generally split binary literals into nybbles and add thousand separators for decimal literals >= 1,000. That more or less mimics how I'd write them down on paper (with space and comma as respective separators).
Of course, that doesn't mean I find longer numbers without separators unreadable - I'm OK up to about twice those lengths - but, when you have something, you tend to use it.
Very long decimal literals don't crop up very often (except perhaps powers of 10) but when they do it really is good to have the digit separator in the toolbox :)
If this proposal is accepted, then no doubt there will be people who abuse it or use it inconsistently but I don't really think it is practical to limit placement in some way. Other languages don't seem to bother either.

decimals: 3

oh boy, someone has to learn about international number formatting

I think it would be better to rule out adjacent or trailing underscores, and to always want at least one digit between the base indicator and the first underscore, e.g. 0_7 is invalid, effectively ruling out a leading underscore on the value's digits.
int_lit = decimal_lit | octal_lit | hex_lit .
decimal_lit = ( "1" … "9" ) { decimal_digit | "_" decimal_digit } .
octal_lit = "0" [ octal_digit { octal_digit | "_" octal_digit } ] .
hex_lit = "0" ( "x" | "X" ) hex_digit { hex_digit | "_" hex_digit } .

@RalphCorderoy Note that the proposed syntax already requires at least one digit after the base indicator before the first blank (_). Based on that rule, 0_7 would be decimal 7; but for this specific case of octals, I agree it should be invalid.
I'm not convinced about ruling out adjacent separators. For one, other languages permit it, and not permitting it would truly make the literal syntax quite a bit more complex. As is, it simply follows the same pattern we already have for identifiers.
Also, consider as a counter-example: 0b0110_0111_1010_1100__0011_0100_0101_1100 .

Hi @griesemer, the double underscore for a 16-bit boundary is a good example of why it should be permitted.
With leading underscores, including octal, ruled out, is there a reason to permit trailing ones? It's allowed in identifiers, but this change is about separating digits for readability. The lexing of 42_____x can complain about the trailing _ on peeking the x because lexing as 42 and _____x instead, after much backtracking, wouldn't be valid for later parsing anyway AFAIK.

0_77         // 77 decimal, or perhaps not permitted (TBD)

Definitely should not be permitted. It looks like the proposed syntax prevents this though.

[...] is there a reason to permit trailing ones? It's allowed in identifiers [...]

I can't think of any reasons. Also, identifiers allow leading underscores as well, and we've ruled those out so not sure if that logic applies

This is a fully backward-compatible proposal for permitting the use of a blank (_) as a separator in number literals.

I don't think this is the case. Currently 123_456 forms three valid tokens while under the proposal it would become just one.
I'm aware the compatibility guarantee is narrowed to "continues to compile", but that's not the same as "fully backwards compatible", as that should IMHO include not breaking also any of the existing tools.

@cznic As you say, the compatibility guarantee only says that valid code will continue to work; it makes no particular guarantees about invalid code.
The cost of updating tools to support new language features is something that has to be considered with any language change, but that is a separate issue from backward compatibility.

While doing embedded programming, I often use hexadecimal constants and I feel that 0x0f00_0000 is a big readability improvement over 0x0f000000, as it's too easy to miss a digit.

1+
This feature has been implemented lately in Kotlin and has been of great help. Would love to see it in Golang!

I don’t think this improves readability. For example, which is more readable?
x := 100000000
y := 100_000_000
const million = 1000000
z := 100 * million
The latter is, IMO, the more descriptive, leverages the qualities of untyped constants, the lineage of the time package, and exists today without new syntax.
@davecheney

For simple, small(er) numbers, this argument holds. But it starts breaking down once we start talking about numbers that are larger than a billion. I'd rather not have to look back and count 9 zeroes just to verify that 100000000 is actually a billion so that I can do 5 * billion.
The argument also starts to break down when we start to talk about numbers which aren't as simple as 100 million, for instance, a large prime number<PHONE_NUMBER>9
x := 10_107_476_689

// alternatively
const thousand = 1000
const million = thousand * 1000;
const billion = million * 1000;
const trillion = billion * 1000;
y := 10 * billion + 107 * million + 476 * thousand + 689

The argument also breaks down when you're not talking about decimal notation, which has already been brought up so I won't go into depth, but it's very useful to be able to break up binary/hex into nybbles/bytes.

I don't believe it is a good idea to enforce restrictions on where the underscores must go, as I can imagine some people preferring 1234_567_890 to 1_234_567_890. It should be down the coder to write nice looking code.

It looks like this proposal is very similar to Python's PEP-515
Ideally, we would also like to have rules for fmt also. For example:
a :=<PHONE_NUMBER>9
fmt.Printf("%#_d", a) // 10_107_476_689
fmt.Printf("%#_x", a) // '2_5a73_dad1'

@theodesp again I bring up international number formatting
Is there any reason to put it in fmt? We do not have comma separators in fmt today, and I think for good reason. Number formats are localized, so I'm not sure if it's a good idea for fmt. Maybe it'd be good for the text package, but we already have comma separation there, so I don't see much use
Also, the # parameter is already taken by "alternate form". For instance, it adds a leading "0x" for "%x". Not sure if you knew this or not. If you did, you forgot to put it in your outputs, and there is no "%#d". If you didn't, well I hope you learned something new 😃

Ideally, we should not involve any locale-specific rules and keep it simple and relevant for only one thing - separating digits of numbers using underscore for readability.
The format rules come in handy when you want a default but not locale-aware string representation of a value based on some flags and that should be the scope of fmt.
If you want a more localizable approach then the https://godoc.org/golang.org/x/text/message#hdr-Localized_Formatting should also be able to handle rules (if any) for underscores with commas or separators or whatever. Ideally, it should ignore them for simplicity and avoiding confusion or enabled where it has meaning.

Here's related Python PEP 515 (Underscores in Numeric Literals) with their proposed syntax plus a discussion of pros/cons: https://www.python.org/dev/peps/pep-0515/ .

@theodesp I was saying that we should not include in fmt because the "#######" format is locale specific, where fmt should be locale-independent ideally. I think if people want number separation, they should look in the text package.

On a separate note -
The kotlin proposal brings up some other good use cases that we have not discussed (translated to Go):
const creditCard = 1234_5678_9012_3456
const socialSecurity = 999_99_9999

A tool (go vet) might impose restrictions on how the separator is used for readability.

In addition to the Kotlin examples @deanveloper mentioned, I've also used the separator for:
const cents = 123_45

The linters for other languages would yell at me. So I'd rather not have a vet rule and allow people use the feature in whatever way they wish.

Credit Cards are an example of unusual, but not uncommon, number separation. I have often needed  4111_1111_1111_1111, 5105_1051_0510_5100, and 3714_496353_98431 in my test suites.

Credit cards have already been given as an example: https://github.com/golang/go/issues/28493#issuecomment-435999989
Though long, please read all the comments before posting to avoid duplicates. It also gives opportunity to thumb-up or thumb-down comments. https://github.com/golang/go/wiki/NoPlusOne

There are situations where (especially hex and binary literals), arbitrary positioning of _ would be beneficial. I do have some pieces of code that interact with hardware or binary formats that do use (in D language) _ in some strange positions, just to indicate better the encoding. Another example could be UUID.
As for the decimals Currencies (bitcoin = 1_000_000_00, cents = 123_45) , would be a good example, use of numbers in some non Western languages/countries (most notably China 12_3456_7890_2345; and India, 10_00_00_00_00_000), postal codes, and structured serial numbers. Or numbers used for describing groups, i.e. when I decompose some problems to run on multiple shards I leave the last few digits to indicate a shard / partition, and it doesn't need to be 3. ie. id = 11_123_33, I use decimals, because these are easy to work with, track progress by a human, and type manually and sort correctly (i.e. files/directory names).

There are plenty of good arguments as to why an implementation should not require a specific spacing of _. That said, the original proposal's syntax permits a _ anywhere after the first digit, and this seems sufficiently undesirable that we shouldn't leave it to go vet to complain, but make it invalid in the first place.
How do people feel about Python's approach ( https://www.python.org/dev/peps/pep-0515/ )? It basically allows _ between numbers. There can't be consecutive _'s, and they can't be trailing. So things like this are allowed:
123_456_789
1_000_000_000
0xdead_beef
0x_dead_beef           // _ allowed after 0x, 0b
0b0110_1101_1101_0010  // if we had binary integer literals
3.1415_9265

but things like this wouldn't be:
0___
1_2__3___
0x1__23_0
0__.0__e-0__

There is a question regarding octal numbers: Should 0_1 be permitted, and if so, is it an octal number? (Probably, analogous to 0x_dead_beef and 0b_1100_0011 where it's nice to be able to separate the prefix from the number). Note that in Python, octals use the 0o prefix.

Adjacent separators do seem useful in some cases, as per https://github.com/golang/go/issues/28493#issuecomment-434754745 0b0110_0111_1010_1100__0011_0100_0101_1100.
I don't see any reason for leading or trailing underscores in numeric literals.
As 012 is currently octal, I think that 0_12 should also be octal. Removing the separators before determining the base -- keeping the rules for separators and base prefixes orthogonal.

@nathany Yes, that's an important point you're making: The value of a literal should be the same with or without the _.

I'd be comfortable with disallowing leading and trailing underscores as I can't think of any use cases for them.
As for adjacent underscores, I'd be inclined to disallow them too as they're ugly and I can't think of any use cases apart from the one mentioned by @nathany  which I don't think is particularly important.
As for octal literals, one could argue that 0_1 should not be allowed because '0' is the base indicator - not really a digit as such - and therefore the first digit is '1'. Of course 01_2 would be fine.
However, if it is decided to use '0o' as an alternative to (or instead of) the present leading zero, then there would be a potential inconsistency with the above argument in that 0o0_1 should be allowed (because '0' is a digit here not a base indicator) as well as 0o1. So maybe it's best to allow 0_1 after all.
Whatever is decided about octal, I agree with the important principle that the value of a literal should be the same with or without underscores.

I've dug out Java's rules on underscores for numeric literals for comparison with those of Python.
Notice that the octal literal 0_1 is allowed and so are adjacent underscores but leading and trailing underscores are disallowed including after 0x or 0b.
Notice also that you can't place an underscore next to a decimal point which I think would be a sensible rule for Go as I can't think of any good reason why anyone would want to do that.

There's a trend in this discussion that I'd like to argue against. A few examples plucked at random from recent comments:

[snip] as I can't think of any use cases for them.

[snip] as I can't think of any good reason why anyone would want to do that

I don't see any reason for [snip]

There are lots of Go programmers, some working on unusual projects. And machine-generation of code often is easier when you do things that there's no good reason for a human to do. Unnecessary restrictions punish such cases disproportionately.
I think the formulation of the rules should be whatever is simple, clear, and general. If that means a few weird warts are accepted, that's ok. There are better places to put effort and spec length than into trying to spell out a bunch of exceptions on the grounds that we can't currently imagine a good use for them.

@josharian
So, just to be clear, is your suggestion then that we should simply allow underscores (single or multiple) to be placed anywhere within numeric literals except, of course, as the first character (when it would become an identifier) or within a base specifier (0_x etc.)?

If the purpose of _ is for readability, why not allow spaces as well (or instead)? E.g.:
123 456 789
1 000 000 000
0b0110 1101 1101 0010  // if we had binary integer literals
0xdead beef
3.1415 9265

I realize it conflicts with the spec as-written:

White space, formed from spaces (U+0020), horizontal tabs (U+0009), carriage returns (U+000D), and newlines (U+000A), is ignored except as it separates tokens that would otherwise combine into a single token.

See https://golang.org/cl/152377 for spec changes pertinent to this issue (including binary integer literals, but can be discussed independently).
This CL is a refinement of the original grammar suggestion in that it only allows single underscores (_) between digits.

@magical

Python is one such language, and many consider it to be a serious wart. It is super easy to accidentally leave a comma out of a list of strings and silently end up with the wrong data.

I am in violent agreement with you, and to be clear I am not proposing that numeric literals should cross line boundaries.
@griesemer I appreciate the detail. I think it's important to have this included with the proposal. I see now that - 123 is a UnaryExpr.
It's worth noting this was proposed long ago: https://github.com/golang/go/issues/42
with a similar note:

avoids the issue of a spaced-out hexadecimal literal with a segment beginning with [a-fA-f] seeming like a non-number

For the record, I'm not actually for any language change here. Just because it's an easy fix, and other languages do it, I'm not convinced it actually improved readability, though I understand the desire to align numerics.

@lrewega Thanks for the link to #42.
Upon further reflection, it's probably a lot easier to handle white space separators at the lexical level as well; I think that's what C does with strings. This would not require higher level syntax changes. But it would still complicate scanning/lexing a bit and still have problems with fragility of source code. In short, still not desirable but perhaps not as involved implementation wise as suggested before.

@griesemer I just finished reading your blog post on the transition of this and a few other proposals into the evaluation phase of the new community driven language spec process.  Where/how should we signify support for the proposed changes, including this one?

@zacsketches If you like it, give the respective issue a Thumbs Up. If you like it and have arguments in favor, comment on the issues. If you don't like it and have a reason why you believe we should not pursue a proposal, comment on the proposal as well. Thanks.

After rethinking my initial implementation a bit, I need to revise my https://github.com/golang/go/issues/28493#issuecomment-457017743: My initial implementation was trying overly hard to only accept valid literals and stop tokenization early.
In retrospect this was clearly the wrong approach and led to an overly complex solution. It's much better to accept a more lenient number literal syntax (separators everywhere, etc.) and check after the fact (basically what https://go-review.googlesource.com/c/go/+/160243 is doing for strconv). The resulting implementation is massively simpler (simpler in fact than what was there before and more reliably testable) and also leads to better error messages from the compiler. For instance, instead of tokenizing 123__45_ as 123, __45, _ per the spec's tokenization rule it's better to accept 123_45_ as a single token and complain about the incorrect '_''s (either way the program is not correct, so it's ok to slightly deviate from how tokens are split up).
In short, separators are actually straight-forward to handle correctly.

As a reminder, we introduced a new process for these Go 2-related language changes in our blog post blog.golang.org/go2-here-we-come. The Go 1.13 development cycle is now over and it’s time for the final decision.
The feedback on the Go 2 number literal changes has been strongly positive, with very few negative voices. These changes modernize and harmonize Go’s number literal syntax without adding significant complexity to the language: There is now a uniform prefix notation for the three common non-decimal number bases, which matches the notation used in other modern programming languages. The introduction of hexadecimal floating-point literals addresses a pain point for people concerning themselves with numeric code. The suffix “i” may now be used with any (non-imaginary) number literal to create an imaginary constant in a uniform way. And finally, underscores may be used to split longer literals into groups of digits for improved readability.
Proposal accepted for Go 1.13. Closing because the changes have landed.
- rsc for proposal review

This would reduce probability of success when grepping code for a constant (grep -Rnw 100000 .), which may lead to wrong conclusions by those analyzing the codebase in a hurry.

Well thats a fair point. I have done that in some JS programs


error CS0103: The name 'Formatter' does not exist in the current context

Describe the bug
I was following the tutorial An Introduction to DataFrame and somehow the code for formatting the dataframe as table started throwing error "error CS0103: The name 'Formatter' does not exist in the current context". It used to work for me in the past, today seems something is broken.
Please complete the following:
Which version of .NET Interactive are you using? There are a few ways to find this out:
.NET Interactive
© 2020 Microsoft Corporation
Version: 1.0.230701+897ec27256aa312cc872b52b261726684b29d42b
Build date: 2021-06-09T11:13:17.2992510Z

OS

[X] Windows 10
[ ] macOS
[ ] Linux (Please specify distro)
[ ] iOS
[ ] Android

Browser

[ ] Chrome
[X] Edge
[ ] Firefox
[ ] Safari

Frontend

[ ] Jupyter Notebook
[X] Jupyter Lab
[ ] nteract
[ ] Visual Studio Code
[ ] Visual Studio Code Insiders
[ ] Other (please specify)

Screenshots
If applicable, add screenshots to help explain your problem.

The using for the namespace is no longer included by default but it should work if you add:
using Microsoft.DotNet.Interactive.Formatting;

But I think the latest version of Microsoft.Data.Analysis might also include the table formatter.

Thanks @jonsequitur for prompt response.
Adding 'Microsoft.DotNet.Interactive.Formatting' package, it's working fine in Visual Studio.
However, it failed to identify Register Method in Jupyter Lab notebook.

Also, default version of ''Microsoft.DotNet.Interactive.Formatting' is not installed properly in Notebook. As a result, I had to specify version '1.0.0-beta.20074.3' which got installed without any error.

We already ship with this package in the build, so you don't need to do #r for it.
I just realized that there's another breaking change that we've made since that sample was published. Sorry I missed that before. The API now is Formatter.Register<T> rather than Formatter<T>.Register.

Awesome... It worked... thanks!
Any idea how to enable intellisense?

Hi @jonsequitur, @praveenraghuvanshi1512
many thanks for your hints related to the "Formatter not exist" problem. Unfortunately, I wasn't able to adapt the introduction example to the new formatter definition. Which additional steps would be necessary to use the existing formatter  configuration?
First, according to @jonsequitur,  a separate download is not necessary anymore?
#r "nuget:Microsoft.Data.Analysis"
using Microsoft.Data.Analysis;
using Microsoft.DotNet.Interactive.Formatting;

Second step, extending the Formatter definition according to comments of @praveenraghuvanshi1512 to the new API:
using Microsoft.AspNetCore.Html;
// Formatter<DataFrame>.Register((df, writer) =>  // original version
Formatter.Register<DataFrame>(formatter: (df, writer) =>
{
    var headers = new List<IHtmlContent>();
    headers.Add(th(i("index")));
    headers.AddRange(df.Columns.Select(c => (IHtmlContent) th(c.Name)));
    var rows = new List<List<IHtmlContent>>();
    var take = 10;
    for (var i = 0; i < Math.Min(take, df.Rows.Count); i++)
    {
        var cells = new List<IHtmlContent>();
        cells.Add(td(i));
        foreach (var obj in df.Rows[i])
        {
            cells.Add(td(obj));
        }
        rows.Add(cells);
    }

    var t = table(
        thead(
            headers),
        tbody(
            rows.Select(
                r => tr(r))));

    writer.Write(t);
// }, "text/html"); =>  // original version
}, mimeType: "text/html");

Unfortunately, th, i ... table are not known now. How to adapt this code?
Many thanks!
Sebastian

It seems this is needed:
using static Microsoft.DotNet.Interactive.Formatting.PocketViewTags;
Take a look at https://github.com/dotnet/interactive/blob/main/samples/notebooks/csharp/Samples/HousingML.ipynb

@SebastianZug @jonsequitur the docs don't actually mention importing Microsoft.DotNet.Interactive.Formatting; maybe this is something to fix (https://github.com/dotnet/interactive/blob/main/docs/formatting.md)?

I've made some updates to that document. Let me know what you think.


Edit->Settings->Keybindings work does not work

Copied from zulip:
Jan T: Does Edit->Settings->Keybindings work for you? For me it does nothing, besides the ImageJ status saying : "Running command: key bindings"
Curtis Rueden: @Jan T Testing now...
Curtis Rueden: Also does nothing for me. Debugging...
Curtis Rueden: My poor brain, trying to memorize IDEA keyboard shortcuts on top of Eclipse shortcuts... :exploding_head:
Curtis Rueden: There is an exception, and we never see because we are bitten by scijava/scijava-common#452
Curtis Rueden: It is fixed, but I need to reread to remember how to deal with it.
Curtis Rueden: And then, we will need to fix the actual problem in sciview.
Curtis Rueden: The actual issue is that ui-behaviour's VisualEditorPanel now requires a non-null commandDescriptions, if one is given. But scenery's InputHandler is passing null for this. Probably the fix is to simply use the one-arg VisualEditorPanel constructor where only the config is passed, and the code takes care of constructing a so-called "empty command descriptions" object.
Curtis Rueden: @Jan T Would you care to test? I'm working on something else... all you need to do is change line 317 of InputEditor.kt to remove the , null argument, rebuild and link to sciview, and see if things work better.

should be fixed by https://github.com/scenerygraphics/scenery/pull/549


DOC: Re-write the getting started section

The getting started section of the docs has a number of problems:

There is some duplication of commands for installing droneapi (ie done as a dependency and at the end)
The instructions to install Mavproxy aren't really needed as this is done automatically as it is a Droneapi dependency in pip
The instructions stop after installation. A get started should really go through to running an example.

This was addressed in an earlier pull request


Renaming file case. A Rename record is not generated in git records

VSCode Version: 1.46.1
OS Version: Darwin x64 19.5.0

Steps to Reproduce:

rename file case
git status show a new untraced files, should show renamed file

Does this issue occur when all extensions are disabled?: Yes

Duplicate of #93299


(GH-1597) Add write_file plan function

This adds a new write_file plan function that writes content to a
specified file on the given targets. Internally, the function uses the
file::write function to write content to a tempfile on localhost and
then uses the upload_file function to upload the tempfile to the
destination on the given targets.
Closes #1597

CLA signed by all contributors.


User is not able to create clusters

What kind of request is this (question/bug/enhancement/feature request): bug
Steps to reproduce (least amount of steps as possible):

Login to rancher
Add cluster --> Select custom cluster
The page is stuck in loading
Error in console:

component.js:935 Uncaught (in promise) TypeError: Cannot read property 'toString' of undefined
    at n.initUpgradeStrategy (component.js:935)
    at n.setupComponent (component.js:1652)
    at t.invoke (backburner.js:371)
    at e.t.flush (backburner.js:263)
    at e.t.flush (backburner.js:470)
    at e.n._end (backburner.js:1044)
    at _boundAutorunEnd (backburner.js:684)

Result:
Other details that may be helpful:
Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI): master-head - commit id: 9124f6ed
Installation option (single install/HA): single

This is caused by bee119b8f8e0af2c49b2732fc97cefd0383b08d5.  That commit is on the 2.5 release branch.

The issue I'm guessing is that a the Drain field is coming back as null when that previously wasn't possible.

Ive added a UI check for this here that handles the nullable state of drain. From what I understand it seems like the backend change will on affect terraform provider but the UI check is low impact and prevents us from hitting this same bug again.

Rancher version: v2.5-head (10/22/2020) 1599dc1
Edit custom cluster and I get this error. I can't edit there's this overlay that prevents me from selecting anything unless I hit back on the browser.

User is able to select an option from the Cloud Provider options seen.
Select Amazon as the cloud provider.
Deploy a cluster.
User is able to deploy a cloud provider enabled cluster.


the eos code doesn't operate and look like dead

After I use the command as following:
./nodeos -e -p eosio --plugin eosio::chain_api_plugin --plugin eosio::history_api_plugin
My eos node can't produce block and it seems like dead as the following pic:

@zhaokanghuiasd your node is not producing because you didn't enable producer_plugin.
If you want to run blockchain on a single node, you can try something like
nodeos --plugin eosio::wallet_api_plugin --plugin eosio::chain_api_plugin --plugin eosio::producer_plugin --plugin eosio::history_plugin --plugin eosio::history_api_plugin --contracts-console --delete-all-blocks --genesis-timestamp now -e

(will start blockchain from scratch every time you re-run it, if you want to continue existing chain - remove -delete-all-blocks --genesis-timestamp now)

@moskvanaft After using your method, it still can't build block. It even miss the final two raws at the above pic. Can you help me?? Thank you

@zhaokanghuiasd make sure that you have following parameters in you config file (not commented out)
producer-name = eosio
private-key = ["<public>","<private"]


Request for feature - CUDA_COMPILE

We are in the process of porting OpenCV and we are having trouble with the cmake script to build OpenCV with HIP. It will be great if you guys could support features from FindCUDA.cmake like cuda_compile_base.

@mangupta  any info on this ?

I have not had a look at the cuda macro, but I think it can be supported. Might take a week+ before I can get to it though.

@mangupta any update please? A macro "HIP_COMPILE" like the function of "CUDA_COMPILE" is indeed needed.

@schwarzschild-radius, apologies for the lack of response.  Can you please check latest ROCm 6.0.2 (HIP 6.0.32831) to see if your query has been addressed? Thanks.