add support for Azure, OpenAI, Palm, Anthropic, Cohere Models - using litellm

Addressing this issue: https://github.com/emrgnt-cmplxty/automata/issues/211
I'm the maintainer of litellm https://github.com/BerriAI/litellm - a simple & light package to call OpenAI, Azure, Cohere, Anthropic API Endpoints
This PR adds support for models from all the above mentioned providers
Here's a sample of how it's used:
from litellm import completion

## set ENV variables
# ENV variables can be set in .env file, too. Example in .env.example
os.environ["OPENAI_API_KEY"] = "openai key"
os.environ["COHERE_API_KEY"] = "cohere key"

messages = [{ "content": "Hello, how are you?","role": "user"}]

# openai call
response = completion(model="gpt-3.5-turbo", messages=messages)

# cohere call
response = completion("command-nightly", messages)

# anthropic call
response = completion(model="claude-instant-1", messages=messages)

cc @emrgnt-cmplxty @NolanTrem would love your feedback when you get the chance to look at this

Unfortunately this won't work for our implementation, since we have special logic around OpenAI's function handling. I'll keep an eye on your repository and consider introducing this when we are considering the problem more seriously, thanks.

@emrgnt-cmplxty litellm does function handling too - was there something missing in the package ?

hey @emrgnt-cmplxty @NolanTrem - just wanted to bump this. Anything we're missing on our end?


Discussion: supported serializers out of the box

I recently wrote this blog post about the fact that we don't support type: Object and type: Array like Polymer did. I also made this repository.
This is a thing people assume quite often, even in the recent docs PR.
So I think we need to make a decision before 1.0, one of the following two choices:

Ship serializers for Object and Array (and possibly require that consumers import them rather than supporting them by default)
Somehow make it clearer that type is not a type constructor but rather a type serializer (at this point we can't really rename type but maybe we could document it very well)

I'm happy to PR this if we go with the former.
Right now, people almost always assume because they see examples use type: Number, type: String, etc, they should then use type: Date, type: Object, type: Array and so on. This won't work as expected, but people rarely bump into this realisation as they pass their data via properties rather than attributes.
We do want to keep the core as light as we can, so if we do introduce this, it probably belongs in an extra module we must import ourselves.
cc @justinfagnani

cc @sorvell and @kevinpschaaf
What about offering a JSON type?

FYI that's pretty much what I did in my example repo. I think it's a good idea instead of detecting usage of Object.
Reason being, it'll make it more obvious that it's a serializer, not a type constructor. As you have to explicitly import it and pass it through.

I completely agree with renaming Type to something else.
Everyone's initial thought is different than anticipated.
And it confuses both Polymer and non-Polymer folks apparently.
You can use JSON.parse for fromAttribute and JSON.stringify for toAttribute to reflect object and array values properly.
I prefer LitElement taking a serialization/deserialization path which makes the intention clear without any magic surrounding it.

If we weren't so close to 1.0, i would agree.
It depends on how breaking you feel like being just before 1.0 i suppose.
The correct solution to me seems to be to rename type to serializer or some such thing. But, if we want to maintain similarity with Polymer and previous lit versions, that isn't an option.
If you, @unrealprogrammer , have a look at the repo i threw up in OP, that implements exactly what you described. a JSON serializer pretty much, which works for both Array and Object.
At the very least, we should avoid implementing support for Object and Array, as it would lead to people assuming all other type constructors also work.

It might be useful if the documentation better explained more about the expected form of the "function used for both serialization and deserialization" (see quote below), to prevent the misunderstandings mentioned about the type field.
From readme.md:

The value can be a function used for both serialization and deserialization, or it can be an object with individual functions via the optional keys, fromAttribute and toAttribute. type defaults to the String constructor, and so does the toAttribute and fromAttribute keys.

So my understanding is that type accepts something that (1) effectively implements interface Serializable<T> { fromAttribute(v: string): T|undefined; toAttribute(v: T): string|null; }, as well as (2) "a function used for both serialization and deserialization".
When I see examples with type: String / type: Number / etc. and consider the fact that neither String nor Number have toAttribute / fromAttribute methods, I assume that they must be the former, (1).  But I still don't really understand what that means.  The Number constructor doesn't take a string and return a number.  Are those just hard-coded special cases?

I think the concept as a whole is a little too confusing going forward. It isn't an easy thing to document and should be a lot simpler really.
We could introduce a set of default serializers and make the docs reflect that, or maybe at least ensure we no longer use type: Object and such in the docs anywhere.

Marking this as high priority here since the resolution may change API.
What exists now is definitely not ideal. What we refer to externally as type is internally called an AttributeSerializer. Users can write their own AttributeSerializer's with toAttribute and fromAttribute methods.
However, there's also a private _propertyValueToAttribute which specially handles type: Boolean. We'll likely need to add more special casing here as well for other corner cases.
Previously we had a special BooleanAttribute symbol that needed to be used for boolean behavior, but users objected to this as weird. There was a strong desire to just use standard types.
I think perhaps we could leave type but disambiguate it from the AttributeSerializer. This would be the least change that might also help enhance clarity.

If you want some help, i'm happy to do a PR.
We could support type of common primitives like polymer did to avoid confusion.
Then have serializer like you say, which is what we have now.


Fixes merge bug in json

We had a bug only visible when there was more than one debug version.
This misattributed v1.18.3 as a debug version!

merging because getenvoy is broke until we do :) at least 1.18.3 isn't visible


Providing software assets for tasks

When writing DNAnexus applets, it is possible to provide tools (for example, applications like bwa) needed by the applet in the resources directory, or to use the assetDepends or execDepends keys in dxapp.json. I can't work out how to ensure these dependencies are present in a dxWLD task. WDL seems to support this information using the  runtime { } block, but I'm not sure how dxWDL would use this information.

The WDL way to do this, is to create a docker image with the necessary software tools. The runtime block can then specify the docker image, the amount of RAM required, etc.


Feat started to implement edit show views

This pull request contain:

added default representation of table's fields (mysql, postgresql)
corrected view of create/edit/show pages

Now, u have simple mapping and possibility to create/get/update instances with all fields. For customizing view we will use create_form/show_form/edit_form (this part will in next pull request).
PS: I have problem with json/array fields, because admin-on-rest don't have native realization for this data types. Now I choose the way to solve this problem 🤔

part of https://github.com/aio-libs/aiohttp_admin/issues/359

thanks!


Merge the tillig repo/extension into Stoplight.

This is an attempt to consolidate the tillig Spectral extension with the "official extension." There are a significant number of differences that necessitate some fairly major changes; hopefully this can be retrofitted as needed to fit into the Stoplight workflow.
Highlights:

It's a language server. My version of the extension uses the Language Server Protocol, similar to the eslint extension to remove the actual linting operation from the UI thread. However, this means there are two parts to the extension - the client (the UI connection) and the server (the backend part) and they both need to be packaged up. That means...
The build is different. My version uses make.js to build because it needs to coordinate the client and server pieces. I wasn't successful at getting straight-up npm or whatever to do the work in an easy way. The original yarn-based build is gone, though I'm not a yarn user, really, either, so it wasn't something I could convert. If a yarn-based build is desired, that'll have to be added back.
The packaging is different. My version uses Webpack and the build doesn't automatically increment the version or automatically publish. That may have to be put back if it's desired.
The CI build may need help. As with the build/packaging changes, I tried to get the GH actions stuff realigned but you may need to put some things back.
There aren't integration tests. I have a small number of Mocha-based tests, but I never did get a good integration test going. I see that the original Stoplight plugin had a start on that; those may need to be re-added.
Extra stuff removed from README. The README doubles as your home page in the VS Marketplace.  I put my CONTRIBUTING.md in as a different way to explain how to build and contribute, but as the build gets updated, that may also need to change. The "docs" are the README, so that got a bit consolidated. Extra files (the screenshot, the icon image) are in the assets folder.
Files may appear to be oddly ordered. I've learned from bad, bad times that merging JSON (and XML, and any other "config" sort of file) is a nightmare without an absolute predictable order. I use the JSON stable sort plugin on JSON files to ensure merges work. However, that means you won't see, say, "version" right at the top of package.json; it'll be at the bottom because that's the alphabetized predictable order. That may not work for you; you may want to re-order the files in your preferred manner.
ESLint, not TSLint. I had everything running through ESLint because it was easier to get a consistent set of rules for TS and JS (e.g., webpack.config.js) that way; and there are ESLint bindings for TypeScript. Also, my ESLint rules might be more strict than you like. I have it cranked pretty high, with stuff like JSDoc being required. I found forcing myself to document not only means it's easier to remember what's going on, but it also shows up in the VS Code Intellisense and makes the whole solution easier to work with.

I did try to keep stuff like the publisher info and all that in the package.json. The README is largely the same. I left the schemas folder despite not having Intellisense implemented. (Though I noticed it's not in the .vscodeignore so that's going to be bloat in your extension.)
One nice thing I noticed - if you leave icon.png in the root of the repo it works nicely not only for the VS Code extension, but tools like SourceTree will show your icon for the repository automatically. I didn't know that was a thing, but it's a nice surprise. If you reorder files, it might be good to leave that there.
I think the biggest place that needs help is the actual integration of Spectral itself. I sort of fudged my way through that and am likely missing some of the finer details. One thing in particular to look at is that right now there's one Spectral instance that gets shared across linting operations with just the rules changing. I'm not sure if this is a good way to go or if it'd be better to have one linter per doc. The server/linter.ts is where to look for that.
Let me know if you have any questions. I'd be happy to explain what I'm doing in any part of this.

This is awesome, thank you so much @tillig.
Some quick bits:

npm-based instead of yarn is fine, its a preference we have at the company but doesn't matter that much for this project at the moment

autopublish is a nice to have but we can figure out how to bring it back later, it's certainly not going to block this merge

@tillig :wave: Thanks a lot for this!
I've tried to start the review, but as there are a lot of changes in this PR, it's a bit difficult to review it by chunks, while keeping the overall model in mind. I'll dedicate a proper timeslot during the upcoming week-end to work on it.
Fair warning: I've got very little knowledge with vs-code extensions and their ecosystem, so it's highly possible I'll come up with newbie questions/remarks. I apologize in advance for this.

It'll probably be easiest to check the PR out and just look at the code in VS Code or something.
No worries about the questions, I'm happy to answer. I'm no extension master myself; I learned a lot from the ESLint extension.

I'll dedicate a proper timeslot during the upcoming week-end to work on it.

@tillig And... dammit! That didn't happen. :-(
I got sidetracked on other topics. I apologize for this and will find some time in the next couple of days to do this.

@tillig I've gone through all the files. Thanks a lot for the comments that helped me a lot!
I haven't tested the extension yet though. I plan on doing this tomorrow.
Below a few questions that popped up during the reading of the code:

Could you please describe an average contributing process from the testing perspective? (Would someone want to open a PR, how can he/she test the changes locally (especially in the code -> test -> doesn't work -> code -> test pipeline)? What are the well-known caveats to pay attention to? What if there's already a official vscode-spectral extension installed?
Would you know how one could set up an automated high level integration test that would feed vscode with some configuration, load a document, trigger a lint and examine the resulting diagnostics?

A few fixes incoming.
I don't really have a guide on how to handle contributions. I've only written one other VS Code extension, and this is like my second ever foray into TypeScript, so it's very much a learning experience.
It seems both questions revolve around "how do you test this thing?" and that's a phenomenal question. As I noted in the PR intro, there aren't integration tests. Not because I didn't want them, but because that's really hard and being the only dev on the project [at the time] the cost/benefit didn't work out.
I started looking at the docs on how to test and I learned a lot from the VS Code ESLint extension but there are no actual UI automation/integration tests in there. On my other extension (JSON stable sort) I have basically one test that just looks for a log message to see if the extension fired up. It doesn't actually execute anything. I never could figure it out, and, again, cost/benefit didn't allow me to spend a lot of time on there.
That's actually what the playground folder in my original extension repo was about - a few use cases I could try interactively for testing to make sure things seemed to work right.
(You'll probably also notice there's no CI around either VS Code plugin - I very much value CI/CD, I run teams that do that stuff at work... but for these little things I just didn't set it up.)
You can't have the extension installed while you're developing, you will run into problems there. The extension development instance that fires up when you start debugging has all the extensions installed that you have in your working copy of VS Code. That's different than when you're developing Visual Studio extensions where the dev/debug host that fires up has a sandboxed set of extensions. So, yeah, when you're working on this, you'll have to uninstall the extension before you can fire up a debugger.
Other weird stuff that I ran into was mostly around packaging the extension.
You really want to try to get Webpack working. Whenever you package the extension you're going to get warnings that the server part has thousands of files. The client is properly Webpacked, but the server part is not.
The reason for this is the way Spectral ships default rulesets and handles extensions - it requires in a JSON file from a specific location in the filesystem, then if there are functions defined in that file, it requires those in based on the path where the JSON file was found. Webpack destroys that because it's all just one file. I fought with it for a really long time and gave up.
What you'll see in the make.js is a thing during the package target where I use Webpack to just generate a list of what it thinks the server part of the plugin uses - just tree-shaking, basically. I then use that information to generate a potential .vscodeignore file which gets put in the artifacts folder. Since .vscodeignore is what tells the packaging system which files to include or ignore in the final extension package, this is the best I could come up with to trim the set of files in node_modules while still keeping all the modules required... and the Spectal rulesets.
You may have a way to Webpack in the Spectral rulesets, or you may know a way to tell Webpack "package everything up, but when you see require for one of these ruleset files, actually go get the file rather than looking in the bundle." If you know how, do that. My daily job is .NET/C#, Terraform, Go, and a few other things so I didn't have the bandwidth to become a Webpack expert. :(
Uh... I think that's it. Happy to answer more questions if you have 'em.

Curious question here. Do vscode plugins need to be webpacked? I assume so since it's using electron behind the scenes but just want to make sure.

Technically no, but they strongly encourage it, enough that the packaging process for the extension will warn you if you have a lot of files.

Gotcha. Webpack is just massive pain in general. Why projects like create react app are a blessing from the heavens

@tillig I've started to play with it locally.
As I'm working on Windows and the current setup doesn't seem to be completely plug-and-play in that context, I've locally made the following changes
diff --git a/.eslintrc.json b/.eslintrc.json
index c9139d4..6a4a99e 100644
--- a/.eslintrc.json
+++ b/.eslintrc.json
@@ -63,6 +63,7 @@
         ]
       }
     ],
+    "linebreak-style": "off",
     "max-len": "off",
     "object-curly-spacing": [
       "error",
diff --git a/.gitattributes b/.gitattributes
new file mode 100644
index 0000000..6313b56
--- /dev/null
+++ b/.gitattributes
@@ -0,0 +1 @@
+* text=auto eol=lf
diff --git a/make.js b/make.js
index 2aef296..7bbbfbd 100644
--- a/make.js
+++ b/make.js
@@ -43,7 +43,7 @@ target.package = async () => {

   rm('-rf', 'client/*.packed.js');
   rm('-rf', 'server/*.packed.js');
-  run(`node_modules/.bin/webpack-cli --config ./client/webpack.config.js`);
+  run(`node node_modules/webpack-cli/bin/cli.js --config ./client/webpack.config.js`);
   await generateServerPackagingReports();

   run(`vsce package -o ${outputPath.artifacts}`);
@@ -114,7 +114,7 @@ function run(cl, capture = false) {
  * Generates reports to help 'manually webpack' the server plugin.
  */
 async function generateServerPackagingReports() {
-  run(`node_modules/.bin/webpack-cli --config ./server/webpack.config.js --profile --json > ${outputPath.artifacts}/server-modules.json`);
+  run(`node node_modules/webpack-cli/bin/cli.js --config ./server/webpack.config.js --profile --json > ${outputPath.artifacts}/server-modules.json`);
   console.log('Generating the list of modules used by the server.');
   const serverModules = require(`${outputPath.artifacts}/server-modules.json`);
   const names = jsonpath
diff --git a/package.json b/package.json
index 9460560..f0384df 100644
--- a/package.json
+++ b/package.json
@@ -112,12 +112,12 @@
   },
   "scripts": {
     "clean": "git clean -dfX",
-    "compile": "node node_modules/.bin/tsc -b",
-    "lint": "node node_modules/.bin/eslint --ext .ts .",
+    "compile": "tsc -b",
+    "lint": "eslint --ext .ts .",
     "postinstall": "cd client && npm install && cd ../server && npm install && cd ..",
     "prepare:vsce": "npm prune --production && cd client && npm prune --production && cd ../server && npm prune --production && cd ..",
-    "test": "node node_modules/.bin/_mocha",
-    "watch": "node node_modules/.bin/tsc -b -w"
+    "test": "mocha",
+    "watch": "tsc -b -w"
   },
   "version": "0.0.0-development"
 }
diff --git a/server/package-lock.json b/server/package-lock.json
index 5c47cf6..a556cb6 100644
--- a/server/package-lock.json
+++ b/server/package-lock.json
@@ -634,6 +634,12 @@
         "mime-types": "^2.1.12"
       }
     },
+    "fs.realpath": {
+      "version": "1.0.0",
+      "resolved": "https://registry.npmjs.org/fs.realpath/-/fs.realpath-1.0.0.tgz",
+      "integrity": "sha1-FQStJSMVjKpA20onh8sBQRmU6k8=",
+      "dev": true
+    },
     "ftp": {
       "version": "0.3.10",
       "resolved": "https://registry.npmjs.org/ftp/-/ftp-0.3.10.tgz",
@@ -689,6 +695,20 @@
         }
       }
     },
+    "glob": {
+      "version": "7.1.6",
+      "resolved": "https://registry.npmjs.org/glob/-/glob-7.1.6.tgz",
+      "integrity": "sha512-LwaxwyZ72Lk7vZINtNNrywX0ZuLyStrdDtabefZKAY5ZGJhVtgdznluResxNmPitE0SAO+O26sWTHeKSI2wMBA==",
+      "dev": true,
+      "requires": {
+        "fs.realpath": "^1.0.0",
+        "inflight": "^1.0.4",
+        "inherits": "2",
+        "minimatch": "^3.0.4",
+        "once": "^1.3.0",
+        "path-is-absolute": "^1.0.0"
+      }
+    },
     "glob-parent": {
       "version": "5.1.1",
       "resolved": "https://registry.npmjs.org/glob-parent/-/glob-parent-5.1.1.tgz",
@@ -775,6 +795,16 @@
       "resolved": "https://registry.npmjs.org/immer/-/immer-4.0.2.tgz",
       "integrity": "sha512-Q/tm+yKqnKy4RIBmmtISBlhXuSDrB69e9EKTYiIenIKQkXBQir43w+kN/eGiax3wt1J0O1b2fYcNqLSbEcXA7w=="
     },
+    "inflight": {
+      "version": "1.0.6",
+      "resolved": "https://registry.npmjs.org/inflight/-/inflight-1.0.6.tgz",
+      "integrity": "sha1-Sb1jMdfQLQwJvJEKEHW6gWW1bfk=",
+      "dev": true,
+      "requires": {
+        "once": "^1.3.0",
+        "wrappy": "1"
+      }
+    },
     "inherits": {
       "version": "2.0.4",
       "resolved": "https://registry.npmjs.org/inherits/-/inherits-2.0.4.tgz",
@@ -939,6 +969,15 @@
       "resolved": "https://registry.npmjs.org/node-fetch/-/node-fetch-2.6.0.tgz",
       "integrity": "sha512-8dG4H5ujfvFiqDmVu9fQ5bOHUC15JMjMY/Zumv26oOvvVJjM67KF8koCWIabKQ1GJIa9r2mMZscBq/TbdOcmNA=="
     },
+    "once": {
+      "version": "1.4.0",
+      "resolved": "https://registry.npmjs.org/once/-/once-1.4.0.tgz",
+      "integrity": "sha1-WDsap3WWHUsROsF9nFC6753Xa9E=",
+      "dev": true,
+      "requires": {
+        "wrappy": "1"
+      }
+    },
     "optionator": {
       "version": "0.8.3",
       "resolved": "https://registry.npmjs.org/optionator/-/optionator-0.8.3.tgz",
@@ -1005,6 +1044,12 @@
       "resolved": "https://registry.npmjs.org/path-exists/-/path-exists-4.0.0.tgz",
       "integrity": "sha512-ak9Qy5Q7jYb2Wwcey5Fpvg2KoAc/ZIhLSLOSBmRmygPsGwkVVt0fZa0qrtMz+m6tJTAHfZQ8FnmB4MG4LWy7/w=="
     },
+    "path-is-absolute": {
+      "version": "1.0.1",
+      "resolved": "https://registry.npmjs.org/path-is-absolute/-/path-is-absolute-1.0.1.tgz",
+      "integrity": "sha1-F0uSaHNVNP+8es5r9TpanhtcX18=",
+      "dev": true
+    },
     "picomatch": {
       "version": "2.2.2",
       "resolved": "https://registry.npmjs.org/picomatch/-/picomatch-2.2.2.tgz",
@@ -1105,6 +1150,15 @@
       "resolved": "https://registry.npmjs.org/reusify/-/reusify-1.0.4.tgz",
       "integrity": "sha512-U9nH88a3fc/ekCF1l0/UP1IosiuIjyTh7hBvXVMHYgVcfGvt897Xguj2UOLDeI5BG2m7/uwyaLVT6fbtCwTyzw=="
     },
+    "rimraf": {
+      "version": "3.0.2",
+      "resolved": "https://registry.npmjs.org/rimraf/-/rimraf-3.0.2.tgz",
+      "integrity": "sha512-JZkJMZkAGFFPP2YqXZXPbMlMBgsxzE8ILs4lMIX/2o0L9UBw9O/Y3o6wFw/i9YLapcUJWwqbi3kdxIPdC62TIA==",
+      "dev": true,
+      "requires": {
+        "glob": "^7.1.3"
+      }
+    },
     "run-parallel": {
       "version": "1.1.9",
       "resolved": "https://registry.npmjs.org/run-parallel/-/run-parallel-1.1.9.tgz",
@@ -1355,6 +1409,12 @@
         }
       }
     },
+    "wrappy": {
+      "version": "1.0.2",
+      "resolved": "https://registry.npmjs.org/wrappy/-/wrappy-1.0.2.tgz",
+      "integrity": "sha1-tSQ9jz7BqjXxNkYFvA0QNuMKtp8=",
+      "dev": true
+    },
     "xregexp": {
       "version": "2.0.0",
       "resolved": "https://registry.npmjs.org/xregexp/-/xregexp-2.0.0.tgz",
diff --git a/server/package.json b/server/package.json
index 1731fac..055eb46 100644
--- a/server/package.json
+++ b/server/package.json
@@ -10,7 +10,8 @@
   },
   "devDependencies": {
     "@types/minimatch": "^3.0.3",
-    "@types/node-fetch": "^2.5.5"
+    "@types/node-fetch": "^2.5.5",
+    "rimraf": "^3.0.2"
   },
   "engines": {
     "node": "*"
@@ -24,7 +25,7 @@
   },
   "scripts": {
     "_comment": "Post-install deletes the .mjs file from decimal.js because because Webpack messes up the VSIX when it's present. Deleting it fixes the issue; this seems related: https://github.com/MikeMcl/decimal.js/issues/59",
-    "postinstall": "rm -f node_modules/decimal.js/decimal.mjs"
+    "postinstall": "rimraf node_modules/decimal.js/decimal.mjs"
   },
   "version": "0.0.1"
 }

Those changes allow node make.js all to pass when ran from PowerShell. Could you please review them and (provided I didn't break any xplat build feature, add them on top of your branch)?

I think most of this is fine. However, this change:
-    "compile": "node node_modules/.bin/tsc -b",
-    "lint": "node node_modules/.bin/eslint --ext .ts .",
+    "compile": "tsc -b",
+    "lint": "eslint --ext .ts .",

The point of using the installed version of these things rather than global tools is to ensure everyone is building using the same version(s) of the tools. Need a new version of TypeScript? Update the local version; everyone gets it. Same with eslint, mocha, etc.
It may be that we need to change the path into the node_modules folder to use something other than .bin, but I strongly recommend you keep things pointed at local versions rather than global tools.

I think most of this is fine. However, this change:
-    "compile": "node node_modules/.bin/tsc -b",
-    "lint": "node node_modules/.bin/eslint --ext .ts .",
+    "compile": "tsc -b",
+    "lint": "eslint --ext .ts .",

The point of using the installed version of these things rather than global tools is to ensure everyone is building using the same version(s) of the tools. Need a new version of TypeScript? Update the local version; everyone gets it. Same with eslint, mocha, etc.
It may be that we need to change the path into the node_modules folder to use something other than .bin, but I strongly recommend you keep things pointed at local versions rather than global tools.

@tillig I do agree with you. In the sense that I stay away from globally installed packages. And, after having double-checked, I can confirm (with a slight sigh of relief... ;-) ) that neither typescript nor eslint are globally installed on my box.
Besides, the doco https://docs.npmjs.com/cli/run-script seems to agree with this as it states
In addition to the shell’s pre-existing PATH, npm run adds node_modules/.bin to the PATH provided to scripts. Any binaries provided by locally-installed dependencies can be used without the node_modules/.bin prefix. For example, if there is a devDependency on tap in your package, you should write:

"scripts": {"test": "tap test/\*.js"}

instead of

"scripts": {"test": "node_modules/.bin/tap test/\*.js"}

to run your tests.

Fair enough. I'm a fan of being explicit, but I'll do the update.

@tillig Awesome. I've successfully built and installed the vsix.
I've played a bit with the installed version.
I've opened the Spectral repo and created a .spectral.yaml ruleset at the root of it.
.spectral.yaml
extends: spectral:oas

rules:
  openapi-tags: off
  oas3-openapi-servers: error

And although, I've tried to re-start vscode, this doesn't seem to be taken into account.

openapi-tags is still popping up
oas3-openapi-servers is still reported as a warning

Any idea? Can you also repro this on your side?

Before I dive in here, given that there's some general understanding that you will absolutely have to update the internals of this with your own subject matter expertise on the usage of the Special engine, I'm curious how "perfect" this needs to be before the PR is taken. Are some of these things issues than can be handled post-merge or does it all have to be 100% complete first?

I'm not able to reproduce this with the installed extension - it works fine.
However, I bet I know what you're seeing. In your current CI build, your build is what updates the semantic version of the package and your default version is 0.0.0-development in package.json. In my pull request I followed your pattern there and left it 0.0.0-development.
You have version 0.1.0 published in the VS Code marketplace.
As soon as you install 0.0.0-development via VSIX, it sees 0.1.0 in the marketplace, recognizes that as an update, and immediately updates it to the published version. That means the installed plugin you're testing isn't actually the thing you think you installed; it's the previous codebase that's already published.
If you change the version in package.json to be, like, 10.0.0-development then it's vastly newer and it won't update out from under you. That's what I did, and it works like a charm.
This is one of the drawbacks of letting the build control versioning: it makes things like this harder to test and because it's really hard for a build to know what the right semver should be. But I left it that way to make it easier for you to re-implement your build processes, which I don't really have a way to test or execute since it's all yarn-based and I don't do yarn.
Anyway, I tested the installed package (version 10.0.0-development) against a custom ruleset like this:
extends: spectral:oas
formats: ["oas3"]
rules:
  contact-properties: true

  # Custom rules.
  contact-name:
    description: Contact name should be `Test Support`.
    given: $.info.contact
    then:
      field: name
      function: pattern
      functionOptions:
        match: ^Test Support$

And I was able to change, say, the contact info or whatever as needed, totally custom rules, and it all triggered correctly.

As soon as you install 0.0.0-development via VSIX, it sees 0.1.0 in the marketplace, recognizes that as an update, and immediately updates it to the published version. That means the installed plugin you're testing isn't actually the thing you think you installed; it's the previous codebase that's already published.

@tillig Thanks a lot for sharing this! This is very valuable information I didn't know about. And I'm very grateful you spent some time double checking my report.
I've worked a little bit more on this.
First, I fixed a typo in the ruleset (oas3-openapi-servers -> oas3-api-servers).
Then I copied over the common.yaml file to the root of the repository, next to the .spectral.yaml ruleset.
As you can see on the screenshot below, the new common.yaml file (left) is properly dealt with, whereas the second one is not (right).

Please note that I haven't configured vscode-spectral in any way.
I eventually went through server.ts code again and I now believe that the rightmost common.yaml is linted through a Spectral instance loaded with the default oas ruleset from the line below.

So, it doesn't look like a Windows-related defect (which my my initial fear), but a rather the result of the current ruleset resolution mechanism. Which could be re-worked post-merge.

You have version 0.1.0 published in the VS Code marketplace.

I now indeed have it installed. But at the time I made the analysis above, I'm 100% sure I was running 0.0.0. I was able to see the logs in the Task output panel. Those logs were completely in line with the code of that PR. Now that 0.1.0 is deployed, there's no longer any available Task output for Spectral

Are some of these things issues than can be handled post-merge or does it all have to be 100% complete first?

@tillig Thanks to your very clear explanations, I've now got a much better understanding of the overall architecture and code/build/test process.
I like you work a lot! However, there are still some minor things I'd like to see fixed before it gets merged. In order to move this forward and to allow me to get a better grasp at the maintenance of a vscode extension, I'm going to create a branch off of yours and create a new PR. In that PR, I'll add some commits on top of yours and (try to) learn the ropes by myself.
Once again, I'm very thankful for all the time you've invested in making that PR happen and sharing your knowledge.

:tada: Yay! I'll prep an update for my extension to direct folks to this version. I'll release mine with the notification once your new one is out.


feat: 🎸 add 6.0 chain

Description
Adds chain 6.0 support
Breaking Changes
None
JIRA Link
DA-810
Checklist

[ ] Updated the Readme.md (if required) ?

:tada: This PR is included in version 5.13.0-alpha.1 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release
v5.13.0-alpha.1
v5.13.0-alpha.1

Your semantic-release bot :package::rocket:


Styles not working

Styles are not working it seems. Or maybe I'm not using this properly
I import and I'm using the project like this

....
const wb = XLSX.utils.book_new();
  const ws = XLSX.utils.aoa_to_sheet(fullData);

  ws["A1"].s = {
    fill: {
      bgColor: {rgb: 'FF000000'}
    },
    font: {
      name: '宋体',
      sz: 24,
      bold: true,
      color: {rgb: "FFFFAA00"}
    },
  };

I tried also with different fonts. I tried without the font block and just see if I could fillt the cell, but the A1 cell is showing unformatted
How we should use this? Seems like it is being totally ignored
Many thanks!

This works for me
use fill object like this:
fill:{
    patternType:"solid",
    fgColor:{ rgb: "00dce6f1" },
    bgColor:{ rgb: "00dce6f1" }
}

use both fgColor and bgColor and give them same hex code

Same issue -- unable to use the styles:
let wsSummary: XLSX.WorkSheet = XLSX.utils.json_to_sheet(Summary);
   wsSummary['A1'].s = {
    font: {
      sz: 24,
      bold: true
      // color: { rgb: "FFFFAA00" }
     },
    };
  XLSX.utils.book_append_sheet(wb, wsSummary, 'Summary');
  XLSX.writeFile(wb, fileName + ' ' + new Date().getTime() + EXCEL_EXTENSION);

I also can't seem to get even the simplest code to work....
Is there something i'm missing?
// test table
let table = [ [0, 1, 2], [3, 4, 5], [6, 7, 8] ];

let fileName = "asd.xlsx"; // file name
let ws_name = "Raportti"; // sheet name

let wb = XLSX.utils.book_new(), ws = XLSX.utils.aoa_to_sheet(table); // create a work sheet

ws["A1"].s = {	// set the style for target cell
    font: {
      bold: true,
    },
};

XLSX.utils.book_append_sheet(wb, ws, ws_name); // add worksheet to workbook

XLSX.writeFile(wb, fileName); // write workbook

return window.showSaveFilePicker(wb); // show pop up

This works but it doesn't format anything

Same here. The workSheet object is being updated before the addition to the workbook, but no styles are applied.
`let workSheet = XLSX.utils.aoa_to_sheet(sheetData);
	sheet.rowsData.forEach((row) => {
		if (!row.consistant && row.failPoint) {
			workSheet[`${row.failPoint}${row.row}`].s = {
				font: {
					color: { rgb: "b50e0e" },
				},
			};
		}
	});
	workBook.Sheets[sheet.name] = workSheet;`

Got the same problem. No styling applied what-so-ever.
Do I need to include anything, or make reference to the library at all?
Instructions just advise to download the package and apply the sytling.

Any updates on this? Styles are still not working.

Looks like this works only via import. Use webpack.

replace:  import * as XLSX from 'xlsx';  to : import * as XLSX from 'sheetjs-style';

use
import * as XLSX from 'sheetjs-style';

const XLSX = require('sheetjs-style');
const wb = XLSX.utils.book_new();
const ws = XLSX.utils.json_to_sheet([{
  0: 0,
  1: 1,
  2: 2
}], {
  header: ['0', '1', '2'],
});

ws["A1"].s = { // set the style for target cell
  font: {
    name: '宋体',
    sz: 24,
    bold: true,
    color: {
      rgb: "FFFFAA00"
    }
  },
};

XLSX.utils.book_append_sheet(wb, ws, 'sheet1'); // add worksheet to workbook

XLSX.writeFile(wb, 'test.xlsx'); // write workbook

This works for me
use fill object like this:
fill:{
    patternType:"solid",
    fgColor:{ rgb: "00dce6f1" },
    bgColor:{ rgb: "00dce6f1" }
}

use both fgColor and bgColor and give them same hex code

This trick works fine!


Update plugin to support multi-project builds

What

Add support for configuring the package name where the snapshot config will be generated.

Why

To avoid name clashes in multi-project builds.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Thanks so much for contributing @dabd !
We're double checking the escaping of the package name, but are otherwise happy to accept this.

Hi @dabd,
Could you give some more details on your multi-module setup? It would be great if you could provide a snippet of your build.sbt.
For context, I'm working on a scripted test for multi-module support here.
Snapshot4s works correctly for the core, utils and framework modules in the scripted test.
To illustrate a bug, there's a extra module with the same test->test dependency, but which omits the Snapshot4sPlugin. This bug is a bit complex. Since the snapshot4s.generated.snapshotConfig for extra isn't generated, there is only a snapshot4s.generated.snapshotConfig corresponding to core on the classpath. The core module gets updated with the extra snapshot values. This only happens for file snapshots, as we have validation for inline snapshots that prevents this.
We might be able to address this bug through better validation for file snapshots.
Going back to your suggestion of custom package names, sbt-buildinfo's approach of having a configurable package name and package-private object might be event better.  It wouldn't be possible to compile a test with the wrong SnapshotConfig.

Hi @dabd,
Could you give some more details on your multi-module setup? It would be great if you could provide a snippet of your build.sbt.
For context, I'm working on a scripted test for multi-module support here.
Snapshot4s works correctly for the core, utils and framework modules in the scripted test.
To illustrate a bug, there's a extra module with the same test->test dependency, but which omits the Snapshot4sPlugin. This bug is a bit complex. Since the snapshot4s.generated.snapshotConfig for extra isn't generated, there is only a snapshot4s.generated.snapshotConfig corresponding to core on the classpath. The core module gets updated with the extra snapshot values. This only happens for file snapshots, as we have validation for inline snapshots that prevents this.
We might be able to address this bug through better validation for file snapshots.
Going back to your suggestion of custom package names, sbt-buildinfo's approach of having a configurable package name and package-private object might be event better. It wouldn't be possible to compile a test with the wrong SnapshotConfig.

I tried to use the library at work, so unfortunately I can't share the build.sbt file :)   It looks like following the same approach as in sbt-build-info, with configurable package names and package-private object would fix the bug you have found.

Thanks for taking a look @dabd . If that's the bug you're experiencing, you should be able to resolve it by adding the Snapshot4sPlugin to each module in your project that contains snapshot tests.
If that doesn't work, it would be very helpful if you could describe exactly what's going wrong. For instance:

Whether you're running assertInlineSnapshot or assertFileSnapshot.
Whether snapshot4s is updating your files or not.
What the contents of the Snapshot4sBuildInfo.scala in each module is (feel free to obfuscate paths here).

It would be good to understand the root cause of the issue, regardless of whether we move to a package-private object.

Thanks for taking a look @dabd . If that's the bug you're experiencing, you should be able to resolve it by adding the Snapshot4sPlugin to each module in your project that contains snapshot tests.
If that doesn't work, it would be very helpful if you could describe exactly what's going wrong. For instance:

Whether you're running assertInlineSnapshot or assertFileSnapshot.
Whether snapshot4s is updating your files or not.
What the contents of the Snapshot4sBuildInfo.scala in each module is (feel free to obfuscate paths here).

It would be good to understand the root cause of the issue, regardless of whether we move to a package-private object.

To be clear, I didn't find a bug, this PR was intended to provide a solution for name clashes in multi-module projects.
As you said above, the sbt-buildinfo approach should avoid this issue and prevent the classpath bug you discovered, so feel free to close this PR if you decide to go with that.

I'd like to wrap up the discussion and set everyone on the same page. To start with, the main motivation for the change is "to avoid name clashes in multi-project builds". I totally see where you're coming from with adding an sbt config parameter. That might be the solution, but I'm not sure if we even have the issue in the first place.
In https://github.com/siriusxm/snapshot4s/compare/main...zainab-ali:multi-module-setup @zainab-ali has demonstrated a working multi-module setup so, if I understand everything correctly, I think there's nothing to address in the first place.
I really appreciate the controbution! The discussion has helped us better understand the corner cases of user setup. However, I'm reluctant to implement the change that requires users to switch from a generic import snapshot4s.generated.snapshotConfig' to a specific import snapshot4s.my_project.generated.snapshotConfig' plus adding an extra configuration flag. This makes the usage side of things more complicated and requires additional maintenance. It's easy to expose an additional sbt setting, but hard to migrate/deprecate one
That said, if we are able to handle the case of multi-project builds with detailed documentation, I'd prefer that over extending plugin's interface.


Add files via upload

Machine Learning in R - Brett Lantz
What does this PR do?
Add resource
For resources
Description
Machine learning in R,written by Brett Lantz.
Why is this valuable (or not)?
This book helps readers understand the mathematics of machine learning, and apply them in different situations.
How do we know it's really free?
It is the entire pdf.
For book lists, is it a book? For course lists, is it a course? etc.
It is a book.
Checklist:

[done ] Read our contributing guidelines
[done ] Search for duplicates.
[ done] Include author(s) and platform where appropriate.
[done ] Put lists in alphabetical order, correct spacing.
[done ] Add needed indications (PDF, access notes, under construction)

Follow-up

Check the status of GitHub Actions and resolve any reported warnings!

The repo does not host books. Please read CONTRIBUTING.md guidelines. If the book is free licensed, consider depositing in archive.org or unglue.it


Program to test if multiple URLs can be cached and generates a report on the cache headers

Example report:
Total Tested: 10000
Response Codes:
	200: 9784 (97.84%)
Freshness:
	0: 30 (0.30%)
	1 minute: 7 (0.07%)
	1 hour: 1289 (12.89%)
	1 day: 148 (1.48%)
	1 week: 102 (1.02%)
	1 month: 786 (7.86%)
	1 year: 122 (1.22%)
	> 1 year: 5829 (58.29%)
	undef: 1471 (14.71%)
Freshness with Heuristic using Last-Modified (RFC 7234 4.2.2):
	0: 30 (0.30%)
	1 minute: 8 (0.08%)
	1 hour: 1305 (13.05%)
	1 day: 1602 (16.02%)
	1 week: 102 (1.02%)
	1 month: 786 (7.86%)
	1 year: 122 (1.22%)
	> 1 year: 5829 (58.29%)
	undef: 0 (0.00%)
Headers:
	Cache-Control:
		max-age: 8520 (85.20%)
		maxage: 4 (0.04%)
		no-cache: 32 (0.32%)
		no-store: 25 (0.25%)
		private: 34 (0.34%)
		undef: 1113 (11.13%)
	Expires:
		defined: 1406 (14.06%)
		undef: 8378 (83.78%)
	Last-Modified:
		defined: 8678 (86.78%)
		undef: 1106 (11.06%)
	Pragma:
		undef: 9784 (97.84%)
Extra:
	Cache-Control / Expires not set: 1113 (11.13%)
	Cache-Control / Expires / Last-Modified not set: 0 (0.00%)
	ATS Cache Hit: 485 (4.85%)

[approve ci autest]


Update zxcvn 4.3.0 > 4.4.2

Resolves #44

Thanks for submitting an issue/PR but this change is not necessary. If you want latest zxcvbn just run `npm update zxcvbn in your project.


Threshold tBTC v2

tBTC is a wrapped version of BTC that lives as an ERC-20 token on EVM-based blockchains. Its accounting ledger is Ethereum. The BTC backing tBTC is secured by a distributed signer set and staking mechanism.
Our review for this project is live. We need to review cross-chain contracts for some implementations. I'll add relevant links below in the comment soon.
Find the review here: https://github.com/bitcoinlayers/bitcoinlayers/blob/main/content/infrastructures/threshold-tbtc.ts

Don't want to blow up issues so marking this "closed" as i cant revert it back to draft. the PM board is up to date.


[Data Request] Missing Gaps in NDGD Precip 1hr

Hello,
I am looking to download hourly grided precipitation data for the IL River Basin from Oct 2019 through Oct 2020. The only dataset that spans this timeframe is the NDGD Precip 1hr. However, there are many time steps with missing data.
I wanted to confirm that this is correct and that the gaps are present in the dataset. I was also wondering if you had any recommendations for alternative datasets for the missing time steps. One possibility is NEXRAD, but this would require a lot of data processing and downloading (> 1 TB of data, 90,000+ images). I also worry that NEXRAD is more for real-time situational awareness than tracking hourly precipitation totals. Another options is URMA (https://data.eol.ucar.edu/dataset/21.093), but the resolution is 4 km.
Thank you in advance for your assistance,
LRB

I have an airflow DAG setup to copy raw files from S3 to appropriate destination with a task to notify the Cumulus API.  Jan 2020 raw files have been loaded as a test in develop, but the Airflow DAG cannot read from the bucket/key location due to:
botocore.exceptions.ClientError: An error occurred (AccessDenied) when calling the ListObjectsV2 operation: Access Denied
Raw Filenames can't be predicted at the minutes/seconds varies: 2<IP_ADDRESS>009--NCEP-rtma_precip--RT.23.ds.precipa.bin  Reading from a certain directory inside S3 with a prefix search was the method I settled on.

Going to try to script file renaming prior to Airflow.  This will remove the unpredictable minutes/seconds.  Hopefully airflow can reach each file in the acquirables/tbd_dir to copy original raw file and rename to appropriate name while notifying API.

CPC Import to Stable Corps.Cloud

Year-Month
Before
After
Delta

2019-12
345
709
+364

2020-01
-
-

Airflow states for CPC processed files: Dec-2019 - Jun-2021

closing for now.  may reopen to resume back-filling more data or may open a new issue.


Improved confidence metric

Using temperature, per-species accuracy and num-samples per species, design a formula to display the confidence from the softmax function.

Temperature calibration. Setting all the configuration details aside, it is known that the NNs tend to be “too confident” when predicting the classes [GPSW17, MDR+21]. Here, confidence means the probability of the correctness of the prediction (e.g., softmax probability for the predicted class). In deep learning-related literature, methods have been developed to calibrate the confidence, i.e., going closer to the true probability. One simplest and common calibration factor is called the temperature, T, which “softens” the softmax in a way that T → 1 indicates the estimated output probability is close to its true probability cf. [GPSW17].

I believe this is the paper that introduced this concept of temperature calibration and outlines a practical implementation (2017)
https://arxiv.org/abs/1706.04599
Here is survey of multiple methods (updated in 2024)
https://arxiv.org/abs/2308.01222


[Bug] Regression: code examples are missing in rendered docs

Component
contract
What version of Alloy are you on?
No response
Operating System
None
Describe the bug
Current rendered documentation has some code examples missing, see:
https://alloy-rs.github.io/alloy/alloy/sol_types/macro.sol.html

For now you can view them on docs.rs


About section january implementations

Covers more than it should, but it updates about sections (no yet finished), removes the default parameters from all methods that still had it and, changes the title texts on the blocks to improve clarity and consistency between methods.

@JamieMaclean all comments addressed.


collect multiple namespaces

Update: support multiple namespaces
Chore: copy right + envrc

Hi,
I'll add some context:
I wanted to start pulling multiple namespaces instead of deploying this importer multiple times. So here is that. By default, it will continue to work as is (hopefully), but if you leave -namespace empty, it will start pulling namespaces from k8s and then expose metrics for all ports.
I also added a flag -ignore-namespaces to ignore namespaces that should not be pulled. Been running the code for a bit with a test cluster and it seems to work. Adding namespaces (and their pods) that are created and also removing namespaces (and their pods) from /metrics.
Thanks for sharing your project, it got me started in no time.

Released as https://github.com/itzg/kube-metrics-exporter/releases/tag/v1.2.0


Add a Page in the Docusaurus Docs About How Dev in Examples Works and How Tags Are Used

Describe how to set up local development using npm link (reference this medium article https://medium.com/@AidThompsin/how-to-npm-link-to-a-local-version-of-your-dependency-84e82126667a)
What is the dev process for code in examples directory?
How does testing work?
When do we create new tags and update examples code to point to them?

Closing this since official docs start to take shape.


Cannot call service from Dapr sidecar - Misleading error message

This issue is a: (mark with an x)

[x ] bug report -> please search issues before submitting
[ ] documentation issue or request
[ ] regression (a behavior that used to work and stopped in a new release)

Issue description
I have created a simple test case for this:
https://github.com/guidoffm/dapr-test
You can use the pre-compiled images from Docker Hub.
 Call its URL in the browser and you see an error message:

Error: {"errorCode":"ERR_DIRECT_INVOKE","message":"failed getting app id either from the URL path or the header dapr-app-id"}
    at HTTPClient.<anonymous> (/home/node/node_modules/dapr-client/implementation/Client/HTTPClient/HTTPClient.js:116:23)
    at Generator.next (<anonymous>)
    at fulfilled (/home/node/node_modules/dapr-client/implementation/Client/HTTPClient/HTTPClient.js:5:58)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)

Dapr secret stores are not implemented in Azure Container Apps and are on the roadmap. We are updating documentation for clarity already @guidoffm

So there are still two issues here:
1st: Azure CLI. You should not be allowed to configure a secret resource. The command should say this is not supported (at the moment).
2nd: Dapr API. The next problem is the missleading error message when I try to accee the secret resource with Dapr.
The message should be that secrets are not supported.

There is likely another problem you are facing in your api call, because you will get a not implemented exception when you try to access the secret store via dapr in container apps


Promise where T is an object allows additional keys on T

🔎 Search Terms
Promise, Promise Generic
🕗 Version & Regression Information

This is the behavior in every version I tried

⏯ Playground Link
https://www.typescriptlang.org/play/?ts=3.3.3#code/C4TwDgpgBAKhDOwoF4oG8CGAuKiBOAlgHYDmAvgFAUDGA9kYlNrAkqpjgOQacA0UUAEZdBnSlToMkwqAAU8tALYF4EADxxEAPhRyFy1QDo8CWgBsAbhAAUHKNz4CZnUWQCUQA
💻 Code
type Test = {a: string}
const a: Test = {a: 'a',  b: 'b'}
const b: Promise = Promise.resolve({a: 'a',  b: 'b'})
🙁 Actual behavior
const b: Promise<Test> = Promise.resolve({a: 'a',  b: 'b'}) does not highlight error in return type
🙂 Expected behavior
const b: Promise<Test> = Promise.resolve({a: 'a',  b: 'b'}) should show error as b does not appear on Test
Additional information about the issue
n/a

This is working as intended.
The type for your resolve call is inferred by the argument, and then compatibility with the variable type is checked. Additional properties are allowed, objects are not sealed. If you want the excess property check to kick in here you must let TypeScript explicitly know the type of your resolve call: Promise.resolve<Test>(...)


fix: removed unused parameter

:tada: This PR is included in version 0.3.5 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


[Firebase Storage] <Uploading an image succeeds but in the Firebase console the path is different and URL gives 404>

Whenever I attempt to upload a sample image (JPEG) to Firebase, it never presents an error client-side, however, once I go to the console to try and open it, it gives a 404 error. Also, the path in the console is altered and the image doesn't preload.
To reproduce, just make a button and execute the following:
var result = await FilePicker.getMultiFile(type: FileType.IMAGE);
if (result != null) {
    print(basename(result.first.path));
    FirebaseStorage.instance.ref().child("images").child("test.jpeg").putFile(result.first, StorageMetadata(contentType: "image/jpeg")).onComplete.then((
}

I use:
firebase_storage: ^3.1.0
file_picker: ^1.4.3+1

This is what happens (in the client app, no error occurs):

As you can see, the path is different from what I coded and the image does not load.
The image is no problem, as if I upload it through the Firebase console it uploads normally, just the Flutter upload gives this behavior.
If I need to add any more information, please ask. I've been trying for days now.

In order to generate a "public URL" you need to call the getDownloadURL method: https://pub.dev/documentation/firebase_storage/latest/firebase_storage/StorageReference/getDownloadURL.html
When you upload the image via the console yourself, this is automatically handled for you, but with SDKs you need to do it yourself.


Proposal to create donate button in order to accelerate the development process

Hi. Guys
Lot of things should be done in this language.
The result javascript should be beautiful.
Language should support latest ES5 ES6 updates.
Typescript interfaces should be added
All these things are required for enterprise environement. Otherwise it rejects this language.
How many developers in our community?
Maybe we can join together and help guys to accelerate development.

The result javascript should be beautiful.

I think it's pretty readable as-is, and we have source maps.

Language should support latest ES5 ES6 updates.

Latest es5 updates? Which features of es6?

Typescript interfaces should be added

I might actually agree with that, I'd like it (and also get variable declaration).

gkz does not seem to have a gratipay page yet : https://gratipay.com/gkz

The result javascript should be beautiful.
I think it's pretty readable as-is, and we have source maps.
x$ should be removed "..in-contexts" and piping looks not so good when is it transformed

I just want to brint to front
The result code should be beautiful not readable!

It is additional use case for language. I will show it to developers and proud

I've created a gratipay page: https://gratipay.com/gkz/
My top priorities  for the future are:

Fixing bugs
ES6 support
Allowing type annotations (for use with other systems such as TypeScript)


os: Mkdir ignores perm on Windows

Go version
go version go1.21.6 windows/amd64
Output of go env in your module/workspace:
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\xiaqq\AppData\Local\go-build
set GOENV=C:\Users\xiaqq\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\xiaqq\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\xiaqq\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Program Files\Go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLCHAIN=auto
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.21.6
set GCCGO=gccgo
set GOAMD64=v1
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=0
set GOMOD=NUL
set GOWORK=
set CGO_CFLAGS=-O2 -g
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-O2 -g
set CGO_FFLAGS=-O2 -g
set CGO_LDFLAGS=-O2 -g
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -fno-caret-diagnostics -Qunused-arguments -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=C:\Users\xiaqq\AppData\Local\Temp\go-build2957556198=/tmp/go-build -gno-record-gcc-switches

What did you do?
package main

import (
	"fmt"
	"os"
)

func main() {
	file, err := os.OpenFile("f", os.O_CREATE|os.O_TRUNC|os.O_WRONLY, 0o444)
	if err != nil {
		panic(err)
	}
	file.Close()
	stat("f")

	os.Mkdir("d", 0o555)
	stat("d")
}

func stat(name string) {
	info, err := os.Stat(name)
	if err != nil {
		panic(err)
	}
	fmt.Println(info.Mode())
}

What did you see happen?
Command output:
-r--r--r--
dr-xr-xr-x

What did you expect to see?
Command output:
-r--r--r--
drwxrwxrwx

According to the OS package's documentation on FileMode:

A FileMode represents a file's mode and permission bits. The bits have the same definition on all systems, so that information about files can be moved from one system to another portably. Not all bits apply to all systems. The only required bit is ModeDir for directories.

This may just be a situation where the write bit doesn't have any meaning on Windows for directories.

Actually, I don't know what the write behavior here is. I can tell that os.Mkdir just ends up calling CreateDirectory on Windows and skips passing the SECURITY_DESCRIPTOR. However, that kind of makes sense, since the descriptor looks nothing like file modes.
But, I don't know if the correct thing to do here is to just set the mode afterwards on Windows. I'm guessing since os.Mkdir has, AFAICT, operated this way forever, I'm not sure we can change it now without breaking backwards compatibility either anyway.
CC @qmuntal ... maybe? I'm not sure if this specifically is really your area of expertise with Windows, so apologies for the noise if not.

According to the OS package's documentation on FileMode:

A FileMode represents a file's mode and permission bits. The bits have the same definition on all systems, so that information about files can be moved from one system to another portably. Not all bits apply to all systems. The only required bit is ModeDir for directories.

This may just be a situation where the write bit doesn't have any meaning on Windows for directories.

It does, if you call os.Chmod with 0o555 it will set the read-only bit on directories.
Both os.OpenFile and os.Chmod treats absence of the write bit to mean read-only on Windows, it would make sense for os.Mkdir to be consistent with them.

It does, if you call os.Chmod with 0o555 it will set the read-only bit on directories.

We could use os.Chmod to set the read-only bit on directories, but os.Chmod uses SetFileAttributesW under the hood, and it's documentation says that FILE_ATTRIBUTE_READONLY is not honored for directories:

A file that is read-only. Applications can read the file, but cannot write to it or delete it. This attribute is not honored on directories.

This limitation doesn't seem specific to SetFileAttributesW, other sources contain the same warning, e.g.: https://learn.microsoft.com/en-us/windows/win32/fileio/file-attribute-constants.
IMO there is nothing we can do here. os.Mkdir ignores the passed permission bits, but so does Windows.

It does, if you call os.Chmod with 0o555 it will set the read-only bit on directories.

We could use os.Chmod to set the read-only bit on directories, but os.Chmod uses SetFileAttributesW under the hood, and it's documentation says that FILE_ATTRIBUTE_READONLY is not honored for directories:

A file that is read-only. Applications can read the file, but cannot write to it or delete it. This attribute is not honored on directories.

This limitation doesn't seem specific to SetFileAttributesW, other sources contain the same warning, e.g.: https://learn.microsoft.com/en-us/windows/win32/fileio/file-attribute-constants.
IMO there is nothing we can do here. os.Mkdir ignores the passed permission bits, but so does Windows.

Interesting! Didn't know that setting read-only on a directory doesn't actually make it read-only.
However, contrary to documentation, setting read-only on a directory does do something: it prevents deletion:
md d
attrib +r d
REM will fail with "access denied"
rd d
attrib -r d
REM will succeed
rd d

However, contrary to documentation, setting read-only on a directory does do something: it prevents deletion:

Good catch. Then it is ok for me to honor the permissions by calling Chmod just after CreateDirectory. Do you want to submit the fix yourself?


Pylance not recognizing properties and methods from injected dependencies after v2023.12.1 update

Environment data

Language Server version: v2023.12.1
OS and version: Windows 11
Python version (& distribution if applicable, e.g. Anaconda): 3.11.6

Code Snippet
class NewClass:
    def __init__(self, injected_dependency: InjectedClass) -> None:
        self.new_prop = injected_dependency
        self.new_prop.old_prop_or_method # Intellisense not working after v2023.12.1 update

Expected behavior
I expected intelisense to show me the properties and methods available to the original class, as well as carry the correct types, same as it was working up to v2023.11.10.
Actual behavior
It doesn't recognize any properties and methods for injected dependencies anymore.

I also have a similar problem, after updating can not find the subclass
Back to 2023.11.10 will be fine.

Thanks for the issue. @l1h2 I'm not sure what you mean by an injected dependency. This works for me:

Can you provide a more complete example?
@a690089735 it looks to me like we're not finding the PySide2 modules. That doesn't seem related to me. That's an import resolution problem. That works fine for me:

You might just need to restart VS code.

I tried restarting VS code and even my machine a few times, but the only thing that solved the problem was going back to v2023.11.10. Then everything works perfectly.
Here is the actual code I was looking at:
class BuildOrderManager:
    def __init__(self, bot: "Sc2City"):
        self.bot = bot
        self.scv_manager = SCVManager(bot)
        self.structure_manager = StructureManager(bot)
        self.__order_managers = {
            OrderType.STRUCTURE: self.scv_manager.scv_build,
            OrderType.PRODUCTION: self.structure_manager.produce,
            OrderType.ACTION: self.structure_manager.execute_action,
            OrderType.SCV_ACTION: self.scv_manager.execute_action,
        }

    def production_complete(self, unit: Unit) -> None:
        order_id = (
            AbilityId.CALLDOWNMULE_CALLDOWNMULE
            if unit.type_id == UnitTypeId.MULE
            else unit.type_id
        )
        order = next(
            (
                order
                for order in self.bot.queue # This is the line that lost intellisense
                if order.id == order_id and order.status == Status.STARTED
            ),
            None,
        )
        # More code...

Do you have a repo I can look at? That has a bunch of dependencies that I can stub out, but I imagine that wouldn't reproduce the problem for me.

Forgot to send the original class, but this is the relevant part:
class Sc2City(BotAI):
    def __init__(self, settings: Settings) -> None:
        self.queue: list[Order] = []

Okay but I'd still need your Settings and BotAI class to reproduce.

Do you have a repo I can look at? That has a bunch of dependencies that I can stub out, but I imagine that wouldn't reproduce the problem for me.

https://github.com/savelas81/Sc2City/blob/new-architecture/sc2city/managers/build_order_manager/main.py

Which part of that code isn't working? It seems to work for me:

In the Sc2City module:

Although maybe this is a linux only problem. I'm trying this on Windows at the moment.

Hmm, I get different results on Linux for the type of bot:
Windows:

Linux:

Windows with 2023.11.10:

So there is some difference. We not resolving the same type for some reason as we used to.

Here are some more examples from places I'm seeing this problem
On v2023.12.1:

On older versions:

Repro steps:

git clone https://github.com/savelas81/Sc2City.git
git checkout new-architecture at this commit id: 0fd2e3aa93a5e6eaa4e693bed6f7c707428e08cf
create venv
install requirements.txt (I had to remove the git requirement and set platformdirs to not set a version for it to work)
Open sc2city\managers\build_order_manager\main.py
Hover over the bot object passed in. The type is wrong. It should be just Sc2City and it's Module Sc2City.Sc2City

Doesn't seem to repro on WSL for me.

I believe the root cause of the problem is case sensitivity. On linux, Sc2City is unambiguously resolved to the Sc2City.py:

On windows, sc2city and Sc2City are resolving the same way. I'm guessing we removed a realcase check somewhere that's causing the issue.

I can reproduce with this much simpler setup:

root

module

init.py
Module.py
test.py

Where Module.py has:
class Module():
    def return_int(self):
        return 42

And test.py has:
from Module import Module

x = Module()
y = x.return_int()
reveal_type(y)

On Windows, the type of y is Any
On Linux, the type of y is Literal[42]

Yeah with that simpler test case, with 2023.11.10, Windows produces the correct results.

This issue has been fixed in prerelease version 2023.12.100, which we've just released. You can find the changelog here: CHANGELOG.md


feat(fx-2845): directly stages custom filter input on mobile

Closes: FX-2845
We definitely need to ensure this is a usable experience on staging. It works but there may be some input lag as the context updates cause the entirety of filters to re-render on every keystroke. I wasn't able to fix this with memoization and there are a lot of issues with debouncing the input in this case. AFAIK the correct way to optimize this appears to be splitting the context which is what easy peasy should do out of the box.

@mzikherman conflicts addressed


Denying cookie does not work properly

When a user denies a cookie this information is not stored. So every time they return back to the main page it asks them if they accept the cookies or not.  Fix this. Only saw it on the phone but it likely applies to the computer too

On second thought this is okay. Since a user deny's cookies, we cant store that info for them so this is just a side effect of that


chore(main): release 0.2.11

:robot: I have created a release beep boop
0.2.11 (2023-04-26)
Miscellaneous

deps: bump jvm from 1.8.20 to 1.8.21 (f1dedf0)
deps: bump jvm from 1.8.20 to 1.8.21 (#42) (1954441)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/paulschuberth/mdgen/releases/tag/v0.2.11 :sunflower:


X-Authenticated-Sender header

The X-Authenticated-Sender header might be interesting to display. It's syntax is like:
X-Authenticated-Sender<EMAIL_ADDRESS>
It appears to show the 'real' sender (mailserver account of sender) if the From: address is overridden to something else in the senders mail client.

This ticket used to read something different. In the end it was a customer who tried to send mail as us, from his ISP mailserver. Which is understandably blocked by Gmail. Sorry for the confusion. The header is still interesting.

Great, I'll add it given a free minute! Thanks Henk :)

Got it:
-----------------------------------------
(3) Test: The Real Sender - via Authenticated-Sender

HEADER:
    X-Authenticated-Sender

VALUE:
<EMAIL_ADDRESS>
ANALYSIS:

- This user has authenticated to the mail server to send that e-mail:
        -<EMAIL_ADDRESS>
        - Mismatch with From header!
                - Authenticated user is not the same as declared in From header:

                        - Authenticated as<EMAIL_ADDRESS>                        - Sent e-mail as<EMAIL_ADDRESS>
Thanks, closing it now :)

Of course all of this can be forged. But I think proper language about that might get unintelligible.

Hmmm, so how do you propose to change the description or parsing logic @HenkPoley ?

Another one of these sender's IP headers:
x-originating-ip: [<IP_ADDRESS>]


Store installation fails

I'm trying to install gocache for the first time. That in itself seemed fine, but installing stores seems to be broken.
Steps for Reproduction
Follow the instructions written in the README for installing gocache

with Bigcache
or with Ristretto store.

Expected behavior:
Bigcache or Ristretto stores installed.
Actual behavior:
Failure to install stores (2 out of 2)
$ go get github.com/eko/gocache/store/bigcache/v4
go: downloading github.com/eko/gocache/store/bigcache/v4 v4.1.2
go<EMAIL_ADDRESS>reading github.com/eko/gocache/lib/go.mod at revision lib/v4.1.1: unknown revision lib/v4.1.1

go get github.com/eko/gocache/store/ristretto/v4
go: downloading github.com/eko/gocache/store/ristretto/v4 v4.1.2
go<EMAIL_ADDRESS>reading github.com/eko/gocache/lib/go.mod at revision lib/v4.1.1: unknown revision lib/v4.1.1

Platforms:
OS: Linux (Fedora 38)
Go: go1.20.4 linux/amd64
Versions:
Which versions are you running? v4.1.3

The same with go_cache v4.1.2 - it refers to not existing github.com/eko/gocache/lib/v4 v4.1.1 - see https://github.com/eko/gocache/blob/store/go_cache/v4.1.2/store/go_cache/go.mod

https://github.com/eko/gocache/issues/214. Redis cluster is also impacted.
@eko Sorry to tag, can you do a quick release as the gocache lib is currently broken for 3 of the stores on master.

Hi @Ashtonian,
Thank you, I am currently off and have no laptop but I write on top of my todo list to make a new release on monday.

Hi @peteraba @Ashtonian,
All stores should now be updated and tagged to use lib v4.1.3 (latest one).
If you still have any issue with Go module cache, please for the version with the latest store version, for instance:
$ go get<EMAIL_ADDRESS>
go: downloading github.com/eko/gocache/store/ristretto/v4 v4.2.0
go: added github.com/eko/gocache/lib/v4 v4.1.3
go: added github.com/eko/gocache/store/ristretto/v4 v4.2.0
go: added github.com/golang/mock v1.6.0
go: added golang.org/x/exp v0.0.0-20230315142452-642cacee5cc0

Sorry about that and thank you for your patience!

Closing this issue for now but feel free to reopen if you still have any issue!

works, thank you!


refractor summary api

Signed-off-by: Prateeknandle<EMAIL_ADDRESS>refactoring summary api:
changes :

returning the summary output when GetSummary() is called
printing the output is now done by Summary() func, when comand is used

after this we can use summary api to get the karmor summary command output rather than executing command in code.

@Prateeknandle If you can attach a screenshot of a JSON output, that would be better.

screenshot was not possible because summary is big, therefore pasting the output with command

@yasin-cs-ko-ak is it okay to merge this PR now?

@Prateeknandle @yasin-cs-ko-ak IMO we're good to merge it.
// cc: @seswarrajan


Let precompiled script plugins compiled with Gradle 6.x work with previous versions of Gradle

Starting with Gradle 6.0, Kotlin DSL precompiled script plugins are compiled against a new base class which is not available in previous Gradle versions and because of that, precompiled script plugins built with Gradle 6.0 won't be compatible with previous Gradle versions.
Gradle should provide a mechanism to allow plugins compiled against Gradle 6.x to be used with Gradle versions prior to 6.0.

A follow-up of #10822.

In general, we don't support taking any kind of plugin compiled against a given version Gradle and running it in an older version of Gradle. Whether we should support this or not is another question, but I wouldn't fix this in an ad hoc way just for this case.


tag talksprites

Link to Sprites: https://drive.google.com/file/d/1_gBO8Dl_Om2hxb20uLAEHac8-VgSQZ9K/view?usp=sharing
Credit to gomigg.
^ implement this


Disabling only Policy does not work

Describe the bug
PR #9722 introduced option to enable/disable individual components of mixer - policy and telemetry. However I am not able to have policy disabled - telemetry enabled in mixer. Although I can enable policy and disable telemetry.
Expected behavior
Policy disabled but telemetry to be enabled.
Steps to reproduce the bug
Install via helm install with options --set mixer.policy.enabled=false and check deployments in istio-system namespace. There is no telemetry deployment.
Version
istio - release-1.1-20181120-09-15
kubectl - Client Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.1", GitCommit:"b1b29978270dc22fecc592ac55d903350454310a", GitTreeState:"clean", BuildDate:"2018-07-17T18:53:20Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.1", GitCommit:"b1b29978270dc22fecc592ac55d903350454310a", GitTreeState:"clean", BuildDate:"2018-07-17T18:43:26Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}
Installation
helm install install/kubernetes/helm/istio --name istio --namespace istio-system --set mixer.policy.enabled=false
Environment
Baremetal

Caused by this - https://github.com/istio/istio/commit/89297445b3bc057e440eebae2dc8ad94b35ef524#r31306948

Let's close this, as the issue has been addressed. Thanks @ymesika and @linsun !

@linsun @ymesika @douglas-reid I cannot make the bookinfo works when disable the policy. here are my steps:

install the latest 0211 release-1.1 build from https://gcsweb.istio.io/gcs/istio-prerelease/daily-build/release-1.1-latest-daily/

helm install install/kubernetes/helm/istio-init --name istio-init --tls
helm install install/kubernetes/helm/istio --name istio --namespace istio-system --set mixer.policy.enabled=false --tls

install bookinfo with auth-injection=true for default namespace

kubectl apply -f samples/bookinfo/networking/bookinfo-gateway.yaml  -n default
kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml -n default

access the bookinfo -  http://xxxxx:31380/productpage
the output is UNAVAILABLE:Cluster not available

the bookinfo pods cannot start successfully in this case:
root@icpmaster-cyang:~/istio-release-1.1-20190211-09-16# kubectl get pod -n default
NAME                             READY     STATUS    RESTARTS   AGE
details-v1-756886897d-dgbgn      1/2       Running   0          13m
productpage-v1-8fcdcb496-hgs8t   1/2       Running   0          13m
ratings-v1-7fc6ccbbbb-5r7db      1/2       Running   0          13m
reviews-v1-59ff68c6cf-kpw4q      1/2       Running   0          13m
reviews-v2-58f7dbbf8c-725kh      1/2       Running   0          13m
reviews-v3-654d6f5b95-sff8k      1/2       Running   0          13m

the logs of sidecar is
* failed checking application ports. listeners="<IP_ADDRESS>:15090","<IP_ADDRESS>:443","<IP_ADDRESS>:15030","<IP_ADDRESS>:5601","<IP_ADDRESS>:42422","<IP_ADDRESS>:9200","<IP_ADDRESS>:443","<IP_ADDRESS>:443","<IP_ADDRESS>:15031","<IP_ADDRESS>:15443","<IP_ADDRESS>:443","<IP_ADDRESS>:15032","<IP_ADDRESS>:31400","<IP_ADDRESS>:15029","<IP_ADDRESS>:24224","<IP_ADDRESS>:15443","<IP_ADDRESS>:443","<IP_ADDRESS>:15011","<IP_ADDRESS>:9090","<IP_ADDRESS>:8060","<IP_ADDRESS>:80","<IP_ADDRESS>:9901","<IP_ADDRESS>:9080","<IP_ADDRESS>:15010","<IP_ADDRESS>:9091","<IP_ADDRESS>:15004","<IP_ADDRESS>:8080","<IP_ADDRESS>:15014","<IP_ADDRESS>:3333","<IP_ADDRESS>:9999","<IP_ADDRESS>:15001"
* envoy missing listener for inbound application port: 0
* envoy missing listener for inbound application port: 9080
2019-02-12T10:19:41.006474Z	info	Envoy proxy is NOT ready: 3 errors occurred:

I can execute kubectl exec -it -n default productpage-v1-8fcdcb496-hgs8t bash -c istio-proxy to access the container and then run curl htttp://<IP_ADDRESS>:9080/productpage, it works well.
any thoughts? Thanks.

@clyang82 Can you share the generated istio ConfigMap?

@ymesika here is istio configmap
apiVersion: v1
data:
  mesh: "# Set the following variable to true to disable policy checks by the Mixer.\n#
    Note that metrics will still be reported to the Mixer.\ndisablePolicyChecks: false\n\n#
    Set enableTracing to false to disable request tracing.\nenableTracing: true\n\n#
    Set accessLogFile to empty string to disable access log.\naccessLogFile: \"/dev/stdout\"\n\n#
    If accessLogEncoding is TEXT, value will be used directly as the log format\n#
    example: \"[%START_TIME%] %REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%\\n\"\n#
    If AccessLogEncoding is JSON, value will be parsed as map[string]string\n# example:
    '{\"start_time\": \"%START_TIME%\", \"req_method\": \"%REQ(:METHOD)%\"}'\n# Leave
    empty to use default log format\naccessLogFormat: \"\"\n\n# Set accessLogEncoding
    to JSON or TEXT to configure sidecar access log\naccessLogEncoding: 'TEXT'\n#\n#
    Deprecated: mixer is using EDS\nmixerCheckServer: istio-policy.istio-system.svc.cluster.local:9091\nmixerReportServer:
    istio-telemetry.istio-system.svc.cluster.local:9091\n# Let Pilot give ingresses
    the public IP of the Istio ingressgateway\ningressService: istio-ingressgateway\n\n#
    Unix Domain Socket through which envoy communicates with NodeAgent SDS to get\n#
    key/cert for mTLS. Use secret-mount files instead of SDS if set to empty. \nsdsUdsPath:
    \n\n# This flag is used by secret discovery service(SDS). \n# If set to true(prerequisite:
    https://kubernetes.io/docs/concepts/storage/volumes/#projected), Istio will inject
    volumes mount \n# for k8s service account JWT, so that K8s API server mounts k8s
    service account JWT to envoy container, which \n# will be used to generate key/cert
    eventually. This isn't supported for non-k8s case.\nenableSdsTokenMount: false\n\n#
    This flag is used by secret discovery service(SDS). \n# If set to true, envoy
    will fetch normal k8s service account JWT from '/var/run/secrets/kubernetes.io/serviceaccount/token'
    \n# (https://kubernetes.io/docs/tasks/access-application-cluster/access-cluster/#accessing-the-api-from-a-pod)
    \n# and pass to sds server, which will be used to request key/cert eventually.
    \n# this flag is ignored if enableSdsTokenMount is set.\n# This isn't supported
    for non-k8s case.\nsdsUseK8sSaJwt: false\n\n# The trust domain corresponds to
    the trust root of a system.\n# Refer to https://github.com/spiffe/spiffe/blob/master/standards/SPIFFE-ID.md#21-trust-domain\ntrustDomain:
    \n\n# Set the default behavior of the sidecar for handling outbound traffic from
    the application:\n# REGISTRY_ONLY - restrict outbound traffic to services defined
    in the service registry as well\n#   as those defined through ServiceEntries\n#
    ALLOW_ANY - outbound traffic to unknown destinations will be allowed, in case
    there are no\n#   services or ServiceEntries for the destination port\noutboundTrafficPolicy:\n
    \ mode: REGISTRY_ONLY\ndefaultServiceExportTo:\n  - \"*\"\ndefaultVirtualServiceExportTo:\n
    \ - \"*\"\ndefaultDestinationRuleExportTo:\n  - \"*\"\n\ndefaultConfig:\n  #\n
    \ # TCP connection timeout between Envoy & the application, and between Envoys.\n
    \ connectTimeout: 10s\n  #\n  ### ADVANCED SETTINGS #############\n  # Where should
    envoy's configuration be stored in the istio-proxy container\n  configPath: \"/etc/istio/proxy\"\n
    \ binaryPath: \"/usr/local/bin/envoy\"\n  # The pseudo service name used for Envoy.\n
    \ serviceCluster: istio-proxy\n  # These settings that determine how long an old
    Envoy\n  # process should be kept alive after an occasional reload.\n  drainDuration:
    45s\n  parentShutdownDuration: 1m0s\n  #\n  # The mode used to redirect inbound
    connections to Envoy. This setting\n  # has no effect on outbound traffic: iptables
    REDIRECT is always used for\n  # outbound connections.\n  # If \"REDIRECT\", use
    iptables REDIRECT to NAT and redirect to Envoy.\n  # The \"REDIRECT\" mode loses
    source addresses during redirection.\n  # If \"TPROXY\", use iptables TPROXY to
    redirect to Envoy.\n  # The \"TPROXY\" mode preserves both the source and destination
    IP\n  # addresses and ports, so that they can be used for advanced filtering\n
    \ # and manipulation.\n  # The \"TPROXY\" mode also configures the sidecar to
    run with the\n  # CAP_NET_ADMIN capability, which is required to use TPROXY.\n
    \ #interceptionMode: REDIRECT\n  #\n  # Port where Envoy listens (on local host)
    for admin commands\n  # You can exec into the istio-proxy container in a pod and\n
    \ # curl the admin port (curl http://localhost:15000/) to obtain\n  # diagnostic
    information from Envoy. See\n  # https://lyft.github.io/envoy/docs/operations/admin.html\n
    \ # for more details\n  proxyAdminPort: 15000\n  #\n  # Set concurrency to a specific
    number to control the number of Proxy worker threads.\n  # If set to 0 (default),
    then start worker thread for each CPU thread/core.\n  concurrency: 0\n  #\n  tracing:\n
    \   zipkin:\n      # Address of the Zipkin collector\n      address: zipkin.istio-system:9411\n
    \ #\n  # Mutual TLS authentication between sidecars and istio control plane.\n
    \ controlPlaneAuthPolicy: NONE\n  #\n  # Address where istio Pilot service is
    running\n  discoveryAddress: istio-pilot.istio-system:15010"
  meshNetworks: 'networks: {}'
kind: ConfigMap
metadata:
  creationTimestamp: 2019-02-12T10:08:00Z
  labels:
    app: istio
    chart: istio-1.1.0
    heritage: Tiller
    release: istio
  name: istio
  namespace: istio-system
  resourceVersion: "29862919"
  selfLink: /api/v1/namespaces/istio-system/configmaps/istio
  uid: 1417381e-2eae-11e9-87e5-fa163e6df362

Ok, so Mixer policy check is still enabled in this configmap because mixerCheckServer: istio-policy.istio-system.svc.cluster.local:9091\n exists there. Can you try changing it to #mixerCheckServer...?
Can you also let me know if you have istio-policy service/pod running under istio-system namespace?
It's an issue and deserves a new one. Thanks.

I have made the change to comment the mixerCheckServer. the pods are running. but still get UNAVAILABLE:Cluster not available message.
root@icpmaster-cyang:~/istio-release-1.1-20190211-09-16# kubectl get pod -n default
NAME                             READY     STATUS    RESTARTS   AGE
details-v1-756886897d-dgbgn      2/2       Running   0          4h
productpage-v1-8fcdcb496-hgs8t   2/2       Running   0          4h
ratings-v1-7fc6ccbbbb-5r7db      2/2       Running   0          4h
reviews-v1-59ff68c6cf-kpw4q      2/2       Running   0          4h
reviews-v2-58f7dbbf8c-725kh      2/2       Running   0          4h
reviews-v3-654d6f5b95-sff8k      2/2       Running   0          4h

there is no istio-policy service or pod running under istio-system
root@icpmaster-cyang:~/istio-release-1.1-20190211-09-16# kubectl get pod
NAME                                      READY     STATUS      RESTARTS   AGE
istio-citadel-554c7fcdd7-2hrfd            1/1       Running     0          4h
istio-egressgateway-db8bbc974-cfw59       1/1       Running     0          4h
istio-galley-5858d77d8b-k7q8w             1/1       Running     0          4h
istio-ingressgateway-6fbdb68fcf-qbjv5     1/1       Running     0          4h
istio-init-crd-10-6zh7f                   0/1       Completed   0          4h
istio-init-crd-11-scmnc                   0/1       Completed   0          4h
istio-init-crd-certmanager-10-8t6n9       0/1       Completed   0          4h
istio-pilot-7ff5cf8bdc-hw5gl              2/2       Running     0          4h
istio-sidecar-injector-5bfd5dccb8-7sd7r   1/1       Running     0          2m
istio-telemetry-84b8c4f956-8g6jc          2/2       Running     2          4h
prometheus-566f9c4bdb-p4gbz               1/1       Running     0          4h
root@icpmaster-cyang:~/istio-release-1.1-20190211-09-16# kubectl get svc
NAME                     TYPE           CLUSTER-IP   EXTERNAL-IP   PORT(S)                                                                                AGE
istio-citadel            ClusterIP      <IP_ADDRESS>   <none>        8060/TCP,15014/TCP                                                                                4h
istio-egressgateway      ClusterIP      <IP_ADDRESS>     <none>        80/TCP,443/TCP,15443/TCP                                                                                4h
istio-galley             ClusterIP      <IP_ADDRESS>   <none>        443/TCP,15014/TCP,9901/TCP                                                                                4h
istio-ingressgateway     LoadBalancer   <IP_ADDRESS>   <pending>     80:31380/TCP,443:31390/TCP,31400:31400/TCP,15029:30866/TCP,15030:32281/TCP,15031:31067/TCP,15032:30952/TCP,15443:31362/TCP   4h
istio-pilot              ClusterIP      <IP_ADDRESS>   <none>        15010/TCP,15011/TCP,8080/TCP,15014/TCP                                                                                4h
istio-sidecar-injector   ClusterIP      <IP_ADDRESS>   <none>        443/TCP                                                                                4h
istio-telemetry          ClusterIP      <IP_ADDRESS>   <none>        9091/TCP,15004/TCP,15014/TCP,42422/TCP                                                                                4h
prometheus               ClusterIP      <IP_ADDRESS>   <none>        9090/TCP                                                                                4h

My assumption is that you also need to have policyCheckFailOpen: true in the configmap in this case.
We definitely need to take care of those in the Helm charts when you chose policy disabled.

@ymesika Thanks. I have opened a new issue to address this problem. refer to https://github.com/istio/istio/issues/11699

If policy is not enabled ‘policyCheckFailOpen’ should not matter

@clyang82 You need to set disablePolicyChecks: true in values.yaml to disable policy completely.

@harpratap Thanks for your information. You are right. set disablePolicyChecks: true can be able to disable policy. but it is better to use mixer.policy.enabled as a top-level parameter to decide disablePolicyChecks is true or false. refer to @douglas-reid 's PR - https://github.com/istio/istio/pull/11707

+1 it is very much easier if we can just have 1 flag especially when mixer policy is not even installed.


MVP

### Tasks
- [x] Update README.md.
- [x] Add Pulumi YAML as an extension dependency.
- [x] Block on core contribution: https://github.com/pulumi/pulumi/pull/14516
- [x] Write a command to enumerate the stacks, and polish the launch configuration experience
- [x] Support interactive stack selection
- [x] Don't hardcode the `dev` stack in the dynamic launch configuration.
- [x] Add useful configuration settings, e.g. an override for `PULUMI_HOME`.
- [x] Build a [private package](https://code.visualstudio.com/api/working-with-extensions/publishing-extension) for local testing of the extension.
- [x] Write a "dogfooding" document
- [x] Cleanup any remaining template code.
- [x] Remove "hello world" command
- [x] Automatically install Pulumi (https://github.com/microsoft/vscode-discussions/discussions/516)
- [x] Unify the ESC bits
- [x] Publish to the marketplace.
- [x] bundling
- [x] license update
- [x] Make this repository be public.
- [ ] Write extension tests.
- [ ] Add some documentation to the Pulumi site.
- [ ] Write a blog post to announce the feature.
- [ ] Show an useful error when pulumi isn't logged in
- [ ] Support Pulumi DIY
- [ ] Add useful launch configuration properties, e.g.`target`.
- [ ] tweak for https://github.com/pulumi/pulumi/pull/16783

We'll create some tickets for follow ups


use Karma to test

i wanna use something like this
http://karma-runner.github.io/0.13/index.html
to do testing on multiple platforms and work out some bugs.

ISNT THE POINT OF TESTING THAT YOU DO IT ON THE SYSTEM THAT BREAKS
ALSO THAT SITE USES AN IMAGE OF AN EMBEDDED YOUTUBE VIDEO
http://i.imgur.com/zUk38W9.png

Ok, Travis does about as much as we'll need, so this is closed.


Disable topLevelAutopopulate if toolbox has categories

It doesn't make sense to enable this option if the toolbox has categories, and that invalid combination led to a confusing bug recently.

Codecov Report

Merging #144 into master will decrease coverage by 0.01%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master     #144      +/-   ##
==========================================
- Coverage   54.96%   54.95%   -0.02%
==========================================
  Files          96       96
  Lines       11439    11443       +4
==========================================
  Hits         6288     6288
- Misses       5151     5155       +4

Impacted Files
Coverage Δ

core/initialization/inject.js
11.11% <0%> (-0.76%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8581582...512164a. Read the comment docs.


wsl is freezed after latest build update and not working

Windows Build Number
Microsoft Windows [Version 10.0.22000.168]
WSL Version

[X] WSL 2
[ ] WSL 1

Kernel Version
wsl command isn't working
Distro Version
kali-linux
Other Software
No response
Repro Steps
when i type bash or wsl the command is keep waiting and nothing returns to me the cursor keep blanking though everything worked just fine before latest build update
Expected Behavior
doing commands
Actual Behavior
keep waiting to be executed
Diagnostic Logs
No response

Same here with ubuntu. File Explorer also hangs if you try to browse wsl home via it.
PS C:\Users\User> wsl
The operation timed out because a response was not received from the virtual machine or container.

Possibly related to #7351


Community page in website

I would like to suggest to add a "community page". Something like the following:

There are some communities out there already:
https://twitter.com/typescriptpdx
https://twitter.com/var_tsbr
https://twitter.com/DubTypeScript
https://twitter.com/TypeScriptFR
But I think it would be great to encourage it more :smile:

some more:
http://www.meetup.com/Dublin-TypeScript-Meetup/
http://www.meetup.com/Paris-Typescript/
http://www.meetup.com/Paris-Typescript/
http://www.meetup.com/Portland-TypeScript-Meetup/
http://www.meetup.com/Bangalore-Typescript-Meetup/
http://www.meetup.com/Bay-Area-Typescript-Meetup/
http://www.meetup.com/TypeScript/


window walker plugin crash

Microsoft PowerToys version
0.41.3
Running as admin

[X] Yes

Area(s) with issue?
PowerToys Run
Steps to reproduce

Active the window walker plugin
Search and open the window (e.g. a web browser)
Change the window title(e.g. click another browser tab)
Active the power toys run, and then press enter

✔ Expected Behavior
Keep tracking the window title when open powertoys again. (aka, don't cache the plugin's result)
❌ Actual Behavior
Show old title of the application, and crash (not always) when try to switch.
Version: <IP_ADDRESS>
OS Version: Microsoft Windows NT 10.0.19043.0
IntPtr Length: 8
x64: True
Date: 2021/7/8 10:46:42
Exception:
System.InvalidCastException: Unable to cast object of type 'System.Windows.Documents.Run' to type 'System.Windows.FrameworkElement'.
   at PowerLauncher.MainWindow.SuggestionsList_PreviewMouseLeftButtonUp(Object sender, MouseButtonEventArgs e)
   at System.Windows.RoutedEventArgs.InvokeHandler(Delegate handler, Object target)
   at System.Windows.EventRoute.InvokeHandlersImpl(Object source, RoutedEventArgs args, Boolean reRaised)
   at System.Windows.UIElement.ReRaiseEventAs(DependencyObject sender, RoutedEventArgs args, RoutedEvent newEvent)
   at System.Windows.RoutedEventArgs.InvokeHandler(Delegate handler, Object target)
   at System.Windows.EventRoute.InvokeHandlersImpl(Object source, RoutedEventArgs args, Boolean reRaised)
   at System.Windows.UIElement.RaiseEventImpl(DependencyObject sender, RoutedEventArgs args)
   at System.Windows.ContentElement.RaiseTrustedEvent(RoutedEventArgs args)
   at System.Windows.Input.InputManager.ProcessStagingArea()
   at System.Windows.Input.InputProviderSite.ReportInput(InputReport inputReport)
   at System.Windows.Interop.HwndMouseInputProvider.ReportInput(IntPtr hwnd, InputMode mode, Int32 timestamp, RawMouseActions actions, Int32 x, Int32 y, Int32 wheel)
   at System.Windows.Interop.HwndMouseInputProvider.FilterMessage(IntPtr hwnd, WindowMessage msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
   at System.Windows.Interop.HwndSource.InputFilterMessage(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
   at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
   at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
   at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)

Other Software
No response

@codehz This bug was fixed with version 0.41.4. Please update your PowerToys installation.


Autofocus search field

Lots of discussion about this in #854 and #3440.

@nlhkabu can you confirm that autofocus on mobile causes keyboard popup? I would appreciate a prooflink, because it sounds like a bug rather than expected behavior for HTML5 element. Also @di previous patch didn't use HTML5, but JavaScipt - https://github.com/nlhkabu/warehouse/commit/0d45556a2ed10c27d4ed677cfaf14fb9f3bf42c5 so I think it should be safe.
@dstufft already merged HTML5 fix in https://github.com/pypa/warehouse/pull/985 but I don't see why it was reverted.

The only argument that is left is accessibility of the top menu. While accessibility touches the focus issue, I think that Accessibility should be addressed site-wide with PSF funding, which could result in proper coverage and development and guidelines for contributors.

@dstufft already merged HTML5 fix in #985 but I don't see why it was reverted.

@nlhkabu removed it in https://github.com/pypa/warehouse/pull/2822, though I'm not sure why.

@nlhkabu Can you merge/close this issue as you see fit?

Hi @techtonik thanks for this PR
Thanks to the recent OTF funding for accessibility, I've had time to look into the issue of whether or not this is a good idea. I've opened a ticket with my findings here: #6088
TLDR: Based on the available accessibility recommendations, and the data that shows how users are using the page, we should not focus the search box.
Thanks again for your PR.

@nlhkabu I can not comment on your research in #6088, because comments are locked.
Am I reading your results right?

52.9% use search after landing
8.5% do something else
38.6% people bounce and leave the site

If that is so, that means that 84.5% of site users are doing search, which also means its the primary site function for the 84.5% of users. Do they do extra clicking? Or sole keyboard navigation?


How to detect if a call is being monitored

When a manager is live monitoring a voice call, I can see a connection of type "monitoring", however connection.getMonitorInfo() always returns null. Has this been implemented? How can I determine which agent and contact is being monitored?
When I look at the agent being monitored, I can see two connections, one of type "agent" and one of type "inbound". There is no indication that anything is being monitored. How can I determine if the call is being monitored?
How can we match the monitoring connection to the agent connection to determine if a call is being monitored?
NOTE: It looks like getMonitorInfo() is populated during Chat monitoring connections but not Voice monitoring connections (however, the monitor info does contain enough information to determine which call is being monitored).

Anyone care to comment?

Hi @andrei-at-work , sorry for the delayed response.
I can reproduce that getMonitorInfo() always returns undefined for voice connections as opposed to chat connections. I believe this is a bug as the data populated there is not specific to chat connections. We'll take this into our backlog to address the issue.
// example object you get from getMonitorInfo()
{
    "agent": {
        "agentName": "xxxxxxxx"
    },
    "joinTimeStamp": "2021-05-28T14:10:48.401Z"
}

Speaking of the agent being monitored, there's no way to know if there's a connection that's being monitored from the agent's perspective, as of now.

closing as duplicate of #293 and tracking there -- this is still in our backlog, but is a longer term effort as the fix for the bug is in systems owned by partner teams.