Add installation instructions to README

Providing installation instructions allows users to understand how to install the package without thinking and it's always nice to get a break from thinking for a sec!

For anyone reading this before it gets added:
npm install -D hotscript

import * as H from "hotscript";

type res1 = H.Pipe<
  [1, 2, 3, 4, 3, 4],
  [
    H.Tuples.Map<H.Numbers.Add<3>>,
    H.Tuples.Join<".">,
    H.Strings.Split<".">,
    H.Tuples.Map<H.Strings.ToNumber>,
    H.Tuples.Map<H.Numbers.Add<10>>,
    H.Tuples.Sum
  ]
>;

Added this to the readme, thanks


Error importing matplotlib module

I found and estrange bug. In one notebook I couldn't import Matplotlib correctly, while in other notebook I can import it without problem. I have restarted the server and the error persist.
I have run both notebooks at the same time.

Hi @dsunol,
It seems there might be a kernel mismatch between your two notebooks. Could you check if you're using the same kernel for both notebooks?
If not, please consider changing the kernel of the first notebook to match the kernel of the second one. Here's a quick guide:

My suggestion is to change the kernel of the first notebook to Conda. This could potentially resolve the issue you're facing.

Thanks, it was that!


Save member information in docdata

Should close #4609

That's for saving, but does it automatically handle merging and displaying in the editor?

@akien-mga Seems like merging is already working tools/doc/doc_data.cpp:124
And it is displayed as well, I tested it :smile:.

Awesome! :D


Difficulty catching simple exceptions

mylist = []
try:
    mylist.remove('value')
except ValueError:
    pass

Regular python handles this correctly, ignoring the thrown error, but Transcrypt gives me an ambiguous Uncaught exception message with no further info. This code works fine if I catch ALL exceptions, not just ValueErrors, but I've always been of the opinion that you should only catch what you expect to be thrown, so I'd prefer to be able to specify.
Am I doing something wrong or is this a limitation of Transcrypt, to avoid having to catch and rethrow reformatted javascript exceptions all the time?

Doesn't look like planned behaviour...
Will look into this a.s.a.p.
Thanks!

The wrong type of exception was thrown.
This really was a bug, a fix will be in the next commit.
While this case should now work properly, note that Transcrypt in some cases relies on
the underlying JavaScript exception type, rather than converting it.
This is one place where brief code and seamless integration with JS libs is favored over 100% CPython compatibility.
KR
Jacques


⚠ ClamAV has degraded performance

In 250b073, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 176 ms

Resolved: ClamAV performance has improved in 766af13.


Serverless Framework project fails to deploy because of archive size

Bug description
Generated bundle of the Serverless project has too big size and exceeds allowed by AWS Lambda 250 MB.
It happens because of big sizes of downloaded @prisma/client, which, for some reasons, downloads engines folder that has unzipped size of 96 MB. And the other big files are connected to generated using command prisma generate schema.

Dependency versions
@prisma/client: "^2.20.0"
prisma (dev) : "^2.20.1"
serverless (dev): "^2.32.1"
serverless-webpack: "^5.4.0"
webpack: "^5.11.0"
@types/webpack: "^4.41.25"

Webpack config
import nodeExternals from 'webpack-node-externals';
import slsw from 'serverless-webpack';
import { TsconfigPathsPlugin } from 'tsconfig-paths-webpack-plugin';
import CopyPlugin from 'copy-webpack-plugin';

const isOffline = !!slsw.lib.webpack.isLocal;

if (isOffline) {
    // eslint-disable-next-line no-console
    console.log('Offline mode detected!');
}

// Add plugins for the offline mode here
const offlinePlugins: NonNullable<Configuration['plugins']> = [];

const config: Configuration = {
    target: 'node',
    entry: slsw.lib.entries,
    externals: [nodeExternals()],
    mode: isOffline ? 'development' : 'production',
    devtool: 'source-map',
    module: {
        rules: [
            {
                test: /\.ts$/,
                use: [
                    'source-map-loader',
                    {
                        loader: 'ts-loader',
                        options: {
                            onlyCompileBundledFiles: true,
                        },
                    },
                ],
            },
            {
                test: /\.graphql$/,
                use: ['raw-loader'],
            },
        ],
    },
    plugins: [
        ...(isOffline ? offlinePlugins : []),
        new CopyPlugin({
            patterns: [
                { from: './src/database/prisma/schema.prisma', to: './schema.prisma' },
            ],
        })],
    resolve: {
        plugins: [
            new TsconfigPathsPlugin(),
        ],
        extensions: ['.ts', '.js'],
    },
    optimization: {
        minimize: !isOffline,
    },
    stats: 'minimal',
};

export = config;

Serverless webpack options
    webpackConfig: webpack.config.ts
    includeModules: true
    packager: npm
    packagerOptions:
      scripts:
        - prisma generate

Environment
& setup

OS:  Mac OS Big Sur 11.1
Database: PostgreSQL
Node.js version: 12
Prisma version: 2.20.1

Background
This is on the first deploy of Prisma to our existing Lambda stack. We have not been able to get Lambda working yet. We bundle our functions through webpack before deploying.
I have looked at the webpack bundle and confirm that @prisma/client is being bundled with the lambda function before deploying.

Did I understand correctly that Serverless project refer to a Serverless Framework project? And you are deploying with serverless deploy and then getting an error from AWS Lambda about the archive upload size?
It seems you already added binaryTargets = ["native", "rhel-openssl-1.0.x"] to your schema file, is that correct?
The challenge here fundamentally is that your local environment needs a different binary than the deployment platform, AWS Lambda. That is the reason why you have two binaries query-engine... and by default it seems both are included in the archive. That is not good and we will figure out a way to configure your project not to do that.

@janpio Yeah, I am already added binaryTargets = ["native", "rhel-openssl-1.0.x"] to a schema file.
I am deploying using serverless deploy and package size exceeds 250 MB. That's reason why deploy fails.

Thanks for confirming. Can you make sure the above message contains all the information so we can easily and quickly reproduce your Serverless project on our side? I will want to set up a reproduction of your problem and double check what is being uploaded to AWS Lambda etc.

@janpio
Here is my serverless.yaml file
service: prisma-test
useDotenv: true
resources: ${file(resources.yaml)}

plugins:
  - serverless-offline
  - serverless-iam-roles-per-function
  - serverless-webpack

provider:
  name: aws
  runtime: nodejs12.x
  stage: ${opt:stage, 'dev'}
  region: ${opt:region, 'us-east-1'}
  memorySize: 512
  timeout: 30
  versionFunctions: false
  apiGateway:
    shouldStartNameWithService: true
  variableSyntax: "\\${((?!AWS|SecretName)[ ~:a-zA-Z0-9._@'\",\\-\\/\\(\\)\\*\\?]+?)}"
  environment:
    DB_USERNAME: ${self:custom.db.username}
    DB_PASSWORD: ${self:custom.db.password}
    DATABASE_URL: ${self:custom.db.dbUrl}
functions:
  TestFunction:
    handler: src/lambdas/test.handler
    name: ${self:custom.servicePrefix}-test
    events:
      - http:
          path: test
          method: get
          cors: true

custom:
  webpack:
    webpackConfig: webpack.config.ts
    includeModules: true
    packager: npm
    packagerOptions:
      scripts:
        - prisma generate
  servicePrefix: ${self:service}-${self:provider.stage}
  db:
    username: ${env:DB_USERNAME}
    password: ${env:DB_PASSWORD}
    dbUrl: ${env:DATABASE_URL}

Project dependencies and scripts
{
  "name": "sls",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "sls": "sls -c ./serverless.yaml",
    "build": "npm run sls package",
    "deploy": "npm run sls deploy -- -v",
    "undeploy": "npm run sls remove",
    "start": "npm run sls offline start -- --skipCacheInvalidation",
    "prisma:generate": "prisma generate",
    "prisma:migrate": "prisma  migrate dev --name  init  --preview-feature",
    "tslint": "eslint --ext .ts ./src"
  },
  "prisma": {
    "schema": "./src/database/prisma/schema.prisma"
  },
  "husky": {
    "hooks": {
      "pre-commit": "npm run tslint"
    }
  },
  "author": "LambdaTeam",
  "license": "ISC",
  "devDependencies": {
    "@types/copy-webpack-plugin": "^6.4.1",
    "@types/node": "^14.14.37",
    "@types/uuid": "^8.3.0",
    "@types/webpack": "^4.41.25",
    "@types/webpack-node-externals": "^2.5.1",
    "@typescript-eslint/eslint-plugin": "^4.20.0",
    "aws-sdk": "^2.877.0",
    "copy-webpack-plugin": "^8.1.1",
    "eslint": "^7.23.0",
    "eslint-config-airbnb-typescript": "^12.3.1",
    "eslint-plugin-import": "^2.22.1",
    "husky": "^6.0.0",
    "prisma": "^2.20.1",
    "serverless": "^2.32.1",
    "serverless-iam-roles-per-function": "^3.1.0",
    "serverless-offline": "^6.9.0",
    "serverless-webpack": "^5.4.0",
    "source-map-loader": "^2.0.1",
    "ts-loader": "^8.1.0",
    "ts-node": "^9.1.1",
    "tsconfig-paths-webpack-plugin": "^3.5.1",
    "typescript": "^4.2.3",
    "webpack": "^5.11.0",
    "webpack-node-externals": "^2.5.2"
  },
  "dependencies": {
    "@hapi/boom": "^9.1.2",
    "@prisma/client": "^2.20.1",
    "middy": "^0.36.0",
    "uuid": "^8.3.2"
  }
}

Quick update: I can confirm that we upload both binaries, the native and the rhel one, in standard Serverless Framework projects. No Webpack required even. If your own application code is bug, this can of course lead to upload (50MB limit) or unpack (150MB limit) problems. I'll look for a solution and let you know again.

Just a note along the way: You can run serverless package to create a local version of the archive that is uploaded, then run less foo.zip to get a nice view of the contents that makes it easy to identify what is taking space in there.

And here is a quick workaround to unblock you @NikitaHarzha:
Add this block to your .serverless.yml file:
package:
  exclude:
    - node_modules/.prisma/client/query-engine-darwin

This will exclude the superfluous binary file from packaging into your zip archive that is uploaded to AWS Lamda.

And here is the generalized version of the configuration:
# only include the Prisma binary required on AWS Lambda while packaging
package:
  patterns:
    - '!node_modules/.prisma/client/query-engine-*'
    - 'node_modules/.prisma/client/query-engine-rhel-*'

This is pretty explicit: It includes all query-engine-* files from node_modules/.prisma/client/, but then includes all the query-engine-rhel-* ones (which only 1 exists). This way you only get 1 Query Engine binary in your packaged archived that is uploaded to AWS Lambda.
(We are now also testing this in our e2e tests at https://github.com/prisma/e2e-tests/tree/dev/platforms-serverless to make sure it does not break with updates in tooling.)
Can you confirm @NikitaHarzha using this package pattern in your serverless configuration fixes the problem for you?

By the way @NikitaHarzha, can you still share the error message you are getting? That would help for people to arrive here via Google when they have the same problem as you had - and then they can find the solution right here as well 👍

@janpio Thanks for your help!
Unfortunately, it didn't worked for me. Files are still included in a package and package size is too big.
I tried to implement this in different ways, but still I am not able to deploy my changes

Hm, that is weird. Some files need to be included of course, otherwise Prisma can not work - so the node_modules/.prisma/client/query-engine-rhel-* file is indeed required and that takes ~50MB unpacked.

Did you deploy this project before successfully?
Can you use serverless package and then less .sererless/####.zip to look into the generated archive, what is taking space in there?

Feel free to also send me the zip file privately to<EMAIL_ADDRESS>if you want me to take a look. I know what to look for now.

Is your project expected to use >200MB for the rest of the code?

@janpio I deployed this project successfully, but it was deployed without prisma generate command and still had 50 MB zipped size.
I've checked archived file and it seems that these files take all the space there

Expected project size is about 5 MB, there is no code and dependencies that can use such a big files, except Prisma

Oooookay, seems you are bundling the CLI as well here - I overlooked that before.
Where do these files live?
Do you need the CLI in the built project? Otherwise, if you put the prisma dependency into the devDependencies of your project this would automatically be excluded from the package completely.

I deployed this project successfully, but it was deployed without prisma generate command and still had 50 MB zipped size.

Do you know what changed since then? You said "it was deployed without prisma generate command" - what does that mean exactly?

It didn't generate prisma schema and I got an error

Ok, that looks like an error on AWS Lambda. You should probably generate the Client locally using prisma generate, then upload the generated artifact (that you are outputting into ./src/database/client via your schema file) with the package - and then this error should not appear any more. That did not work?

@janpio I've attached config in description of the bug

Anything special about your handler: src/lambdas/test.handler file? My sls package is currently failing around the step. If you could post the exact path and maybe even content might help.

@janpio Resources file just contains CORS settings
Resources file
Resources:
  GatewayResponseDefault4XX:
    Type: 'AWS::ApiGateway::GatewayResponse'
    Properties:
      ResponseParameters:
        gatewayresponse.header.Access-Control-Allow-Origin: "'*'"
        gatewayresponse.header.Access-Control-Allow-Headers: "'*'"
      ResponseType: DEFAULT_4XX
      RestApiId:
        Ref: 'ApiGatewayRestApi'

src/lambdas/test.handler is an exact path to the lambda in my project
Lambda function just has test of the setup of Prisma, just one test request
Test lambda function
import { apiGatewayResponse } from '@/middlewares/apiGatewayResponse';
import { APIGatewayEvent, DefaultEvent, DefaultResponse } from '@/types/aws';
import { APIGatewayResponse } from '@/utils/aws';
import middy from 'middy';
import { v4 as uuidv4 } from 'uuid';
import { jsonBodyParser } from 'middy/middlewares';
import { PrismaClient } from '@prisma/client';

const prisma = new PrismaClient();

const rawHandler = async (
    event: APIGatewayEvent<DefaultEvent>,
): Promise<APIGatewayResponse<DefaultResponse>> => {
    const newUser = await prisma.user.create({
        data: {
            id: uuidv4(),
            name: 'Top',
            email<EMAIL_ADDRESS>            role: 'FREELANCER',
            createdAt: new Date(),
        },
    });

    console.log('New user', newUser);

    return { message: 'Success' };
};

export const handler = middy(rawHandler)
    .use(jsonBodyParser())
    .use(apiGatewayResponse<APIGatewayEvent<DefaultEvent>,
    APIGatewayResponse<DefaultResponse>>());

But it has my custom types for the event and response, you will need to use similar types from aws-sdk to make lambda work as expected

Could not get the serverless-webpack plugin to work yet (some strange TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string. Received undefined error) but I can already reproduce a far to big archive with that plugin disabled - something is strange here and different to our serverless Framework end to end test. Will keep looking into this.

Did you specify path for the lambda function? It seems like nothing was provided there.

When and where would I specify that path?

TestFunction:
    handler: src/lambdas/test.handler
    name: ${self:custom.servicePrefix}-test
    events:
      - http:
          path: test
          method: get
          cors: true

It has to be specified like this
test is the path for lambda function

Ah yes, I copy pasted your configuration from above - that is what is confusing me.
But I'll continue the investigation into the size first before trying to fix this now.

@janpio

Some files need to be included of course, otherwise Prisma can not work - the node_modules/.prisma/client/query-engine-rhel-* file is indeed required and that takes ~50MB unpacked. We are working on getting this file smaller over time.

Is there any way not to have such big dependency size? It's so much for lambda (20% of lambda size limit)
I don't think, that it's good for any project

See the "We are working on getting this file smaller over time." part of my message 😄
But: Can you maybe open a feature request about this so we can track it separately? Your reasoning is also enough as the description of the issue 🙇♂

@janpio sure, no problems!

Small side note:
As I was investigating this using a Windows computer, I actually uncovered another bug that affects only Windows and creates much bigger archives there: https://github.com/prisma/prisma/issues/6670
(Actual investigation still ongoing)

And another side note, this thing seems to be deep:
As I was investigating the macOS archives from our end to end test runs (which include a Serverless Framework tests) I noticed that the archive was much smaller than on Windows, but still had a few funny files that I could not place why they were included. Turns out that might be another bug causing a 10MB unpacked (2MB packed) size increase that could be avoided: https://github.com/prisma/prisma/issues/6671
(Actual investigation still ongoing)

It didn't generate prisma schema and I got an error

Ok, I think I figured out at least why that is happening:

You set output = "./src/database/client" in the generator block of the schema. So when you run prisma generate the client is generated to that folder.
In your handler file you import import { PrismaClient } from '@prisma/client'; which imports from the usual Client location, where there is only a default PrismaClient that gives you this error message.

If you update that import, or remove the output property in the generator, this should work together much better.
This does not explain the too big binary though. Still looking into this.

Ok, I think I got something:
It seems Serverless Framework has a bug/regression in the packaging behavior (exclusion of DevDependencies) when using Node 15. See the file sizes in an absolutely minimal project with Prisma CLI and Prisma Client (no binaryTargets - so would not work on Lambda) for the two node versions:

Node 14 is around 20MB https://github.com/janpio/repro6644_3/actions/runs/768797405
Node 15 is around 80MB https://github.com/janpio/repro6644_3/actions/runs/768802907

This also explains why I had terrible results with your reproduction, and all my tries in between - I was using Node 15.12.0.

Problem: Above you reported you are using "Node 12" @NikitaHarzha. What version exactly? Maybe the problem also exists in new Node 12 versions?
To simplify the problem understanding, it would probably be best if you could use my reproduction at https://github.com/janpio/repro6644_3. Please check it out and run the following commands:
yarn
yarn prisma generate
yarn sls package
ls -l .serverless

How big is the .zip file for you?

I tried to apply this Node version knowledge to the reproduction project that I created based on your information earlier, but could see no change. Also removing the prisma and @prisma/client dependencies did not create a considerable change in the file size of the generated archive.
Would it be possible that Serverless Framework has a problem with your project setup in general @NikitaHarzha, possibly since a recent version? Do you have a lockfile of when this used to work for your project (without Prisma or whatever working state it was in before)?

@janpio just lost track a little bit for current config

package:
patterns:
- '!node_modules/.prisma/client/query-engine-'
- 'node_modules/.prisma/client/query-engine-rhel-'

Seems like it didn't help
Still have all query-engine-* files inside .zip package uploading to lambda

Have also tried the following config for webpack and the additional files are included.
webpack:
    webpackConfig: webpack.config.js
    includeModules:
      forceExclude:
        - aws-sdk
    packager: npm
    excludeFiles:
      - node_modules/.prisma/client/query-engine-darwin
    packagerOptions:
      scripts:
        - 'prisma generate'

I have tested with and without the prisma generate script. And the rouge engines are still included in both situations.
query-engine-darwin is the engine for Mac OS. I am testing the bundle locally on MacOS and on the pipeline runner, which uses Debian.

I've tried all possible exclude dependency setup.
Tried to use forceExclude, excludeFiles, excludeRegex all of these are serverless-webpack options, but any of this work for me.

@AndriiSherman That is weird, as you are explicitly asking Serverless Framework to exclude that path, right? Can you please open a new issue? Then we can debug this in detail.
@allanitis The explicit excludeFiles is ignored, or are there other engines in the archive? Optimally also create a new issue and we can debug this individually.
@NikitaHarzha In your project I am observing Serverless Framewor including all devDependencies, even when Prisma and Prisma Client are not installed. Can you confirm this behavior? The bundled file via sls package should in theory only include dependencies and their dependencies in the node_modules folder.

I will come up with a more general package.patterns entry that should include all files from Prisma CLI and Prisma Client later, to work around Serverless Framework somehow, sometimes not excluding devDependencies. But this will unfortunately only help for Prisma itself. I fear you are only noticing the Prisma inclusion because of the file size (which of course makes it most pressing and relevant), but it looks to me that Serverless Framework is failing to exclude unneeded dependencies in general somehow.

Hm, that is weird @NikitaHarzha - sorry about that.
Some files need to be included of course, otherwise Prisma can not work - the node_modules/.prisma/client/query-engine-rhel-* file is indeed required and that takes ~50MB unpacked. We are working on getting this file smaller over time.

Did you deploy this project before successfully?

Can you use serverless package and then less .sererless/####.zip to look into the generated archive, what is taking space in there?

Feel free to also send me the zip file privately to<EMAIL_ADDRESS>if you want me to take a look. I know what to look for now.

Is your project expected to use >200MB for the rest of the code?

Deploying with Vercel we also experience this problem. Since vercel does the deployment only the query-engine for AWS is in the output by default. So no steps are required to exclude or remove others. However going from version 2.19.x to 2.20.1 the size of query-engine-rhel-openssl-1.0.x has increased a lot. It has gone from about 25MB to 45MB causing our deployments to fail because of the 50MB limit upload limit of AWS lambda.
If others are experiencing this the solutions would be to use 2.19 for now, as they are working on getting the size down as denoted by @janpio

It has gone from about 25MB to 45MB causing our deployments to fail because of the 50MB limit upload limit of AWS lambda.

Note that the file increase of the binary is unpacked, while the 50MB limit is for the zip file. But yes, in general this is a valid concern. You thankfully opened an additional issue at https://github.com/prisma/prisma/issues/6746, so let's debug your case there. Usually the binary size it not that big of a problem for projects.

@janpio I created a minimum repro at https://github.com/jsw/prisma-issue-6644
Also, I fixed part of the issue by moving the packages.patterns from function scope to file scope, though both are supposed to work if I'm correctly following the serverless docs. Take a look at my serverless.yml. And @prisma/engines and prisma are still included unless your workaround above is applied.

@janpio Could this suggestion solve the Vercel cold start issues #7303 ?

I am not sure, best you just try it.

For those using serverless platform, since upgrading to prisma 3, I have updated my serverless package patterns to the following, which seems to cover everything

Thanks @jsw - do you want to send a PR to these docs pages?

As my development environment is Windows 10. After using @jsw solution, my package size is still 62MB.  I have updated my serverless package patterns to the following, and now my package size is 19MB.
`
- '!node_modules/.prisma/client/libquery_engine-'
- 'node_modules/.prisma/client/libquery_engine-rhel-'
- '!node_modules/prisma/libquery_engine-*'
- '!node_modules/@prisma/engines/**'
# EXCLUDE query_engine-windows.dll.node
- '!node_modules/.prisma/client/query_engine-*'
# EXCLUDE .cache folder
- '!node_modules/.cache/**'
# EXCLUDE .bin folder
- '!node_modules/.bin/**'

`

I'm having the same issue on windows 10, but this package pattern doesn't change anything for me.

@C5H8NNaO4 Could you open a new bug issue her, this issue is old and filling a new issue with your details will be useful, it might be a bit different in your case.

Today's release 4.8.0 has significantly (average 50%, on some platforms even more) decreased the size of our engine files:

Improved serverless experience — smaller engines size
In this release, we have decreased the size of our engine files by an average of 50%. The size of the Query Engine used on Debian, with OpenSSL 3.0.x, for example, went from 39MB to 14MB. We will also remove some smaller engines to decrease the total size in future versions.
Additionally, we have started optimizing how the Prisma schema is loaded in Prisma Client. You should notice a considerable improvement when executing the first query if you're working with a bigger schema with many models and relations.
We will continue investing in this direction in the next releases and further improve the experience with Prisma and serverless environments.

https://github.com/prisma/prisma/releases/tag/4.8.0
We know we still have duplicated engine files in multiple locations, and that we are including too many of our engine files - but this was the obvious place to start and we are happy how significantly we could improve the situation already. Expect more updates like this in the coming releases from us.

As written before, we have reduced the size of our engines a lot and as far as we know, this solved this problem for most our user and their use cases. Hence I am closing this issue for now.
If you and your project are still having problems because of the remaining size of our engines, please open a new issue and describe your situation - we are happy to take a look and hopefully fix that. Thanks!

This problem raised it head again for me after performing an npm update, either serverless or npm is now additionally generating under node_modules/.cache/prisma which were getting included in the zip and exceeding the 250mb limit. I updated my serverless.yml to also exclude this directory as follows:
  patterns:
    - '!node_modules/.prisma/client/libquery_engine-*'
    - 'node_modules/.prisma/client/libquery_engine-rhel-*'
    - '!node_modules/prisma/libquery_engine-*'
    - '!node_modules/@prisma/engines/**'
    - '!node_modules/.cache/prisma/**'

my global package versions are as follows:
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>and<EMAIL_ADDRESS>

@bjj951 please open a new issue or a discussion as this issue is closed since almost a year. So we can process this.
I think this would be best as an issue in our docs repository: https://github.com/prisma/docs
From what I understand, you are on Windows? I think this directory node_modules/.cache/prisma/ is what you are talking about? It is only present for Windows users.
The related pages in the docs should be:

https://www.prisma.io/docs/orm/prisma-client/deployment/serverless/deploy-to-aws-lambda#deploy-only-the-required-files
https://www.prisma.io/docs/orm/more/upgrade-guides/upgrading-versions/upgrading-to-prisma-5#example-with-the-serverless-framework

@Jolg42, i created a patch for the docs here to add that missing pattern for Windows.
https://github.com/prisma/docs/compare/main...bjj951:docs:patch-1

Thanks, I opened a PR from your patch at https://github.com/prisma/docs/pull/5726


adoptopenjdk-bin: 11.0.2 -> 11.0.3 [Security fixes]

Motivation for this change

Security fixes
Other fixes

https://adoptopenjdk.net/release_notes.html#jdk11_0_3
Things done

[X] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[X] NixOS
[X] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Assured whether relevant documentation is up to date
[X] Fits CONTRIBUTING.md.

Backported in 63f8025e231f9ed44cb6197753f62cdcebbc2dda


Events will no longer be fired, because Chrome has dropped support for some event types

A standard Piral.Blazor Settup throws errors in the Chrome devtools console.
My Google Chrome Version is 127.0.6533.100
Those Errors are thrown:
events.js:157 [Deprecation] Listener added for a 'DOMNodeInsertedIntoDocument' mutation event. Support for this event type has been removed, and this event will no longer be fired. See https://chromestatus.com/feature/5083947249172480 for more information.

events.js:157 [Deprecation] Listener added for a 'DOMNodeRemovedFromDocument' mutation event. Support for this event type has been removed, and this event will no longer be fired. See https://chromestatus.com/feature/5083947249172480 for more information.

events.js:61 Uncaught ReferenceError: MutationEvent is not defined
    at PiralPortal.dispatchToRoot (events.js:61:1)

I have created an example Project here:
https://github.com/luckyluggi/piral_mutationevent

This was discussed on discord already - it's not a bug.
https://discord.com/channels/1222632475449229352/1223198584447434803/1263200293206888589


Undefined index: server

PHP Notice:  Undefined index: server in /var/www/html/xyz/vendor/gos/web-socket-bundl /DependencyInjection/GosWebSocketExtension.php on line 203 while clearing the cache

Could you send your Symfony config file, where you included WebSocketBundle configuration?

@miljojohn It happened to me aswell. The asnwer is to manually delete everything in cache folder and it will work
@mwsv It happened on composer require command when clearCache executes.


Correct Data Alert repr

Fixes the data alert item repr.

looks good, I'm afraid we caused a conflict by changing the code style to use double quotes and some newline changes - can you fix those and then I'll merge?
cheers

Thanks @jorwoods for the corrections here - merged.


fix: typo in service call

Type of change

[ ] Dependency upgrade
[x] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (which adds functionality)
[ ] Breaking change (fix/feature causing existing functionality to break)
[ ] Code quality improvements to existing code or addition of tests
[ ] Documentation update
[ ] Adds a new shipper
[ ] Update existing shipper

Additional information
There was a typo in the service call :)

Whoops, this should be targeting the dev branch, not master.

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 93.31%. Comparing base (8608d22) to head (75429df).
Report is 20 commits behind head on dev.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files

@@            Coverage Diff             @@
##              dev     #943      +/-   ##
==========================================
- Coverage   95.07%   93.31%   -1.77%
==========================================
  Files           8        8
  Lines        1482     1555      +73
==========================================
+ Hits         1409     1451      +42
- Misses         73      104      +31

see 4 files with indirect coverage changes

Cheers!


Update README.md

Updated instructions to ensure that the user is logged in before triggering the GitHub Actions PR.

Thanks for your submission!  I don't really know if this is necessary the and makes the text longer?  GitHub lets you know that you must login to proceed, so don't see the need for the additional instruction here.
Closing this PR for now, happy to keep discussing.

Makes sense, but I received a 404 and the silly me took a moment to figure out that I was not logged in.


Allow FakeHttpConnection to gracefully handle GOAWAY frame

Allow FakeHttpConnection to gracefully handle GOAWAY frame.
For an explanation of how to fill out the fields, please see the relevant section
in PULL_REQUESTS.md
Commit Message:
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Deprecated:]

Hi Matt, this change is needed for a fuzz test that we use in google, but I thought it might be useful to other users as well.

Thanks for the help, Matt!


update veracode.yaml

Update and try with my user

Hi @fabiodmota,
can you please provide a better PR title and a description on the changes and improvements a merge would bring.
There are >100 files changed, to i think it is not just 'update veracode.yaml' :)
Same would be great for commit messages. Try to also use the commit message to shortly describe what changes and improved.
ECA has to be signed before contributions can be accepted


[file-picker] Helper text styling and area present even when there is no helper text

Describe the bug:
Even if there is no helper text, the helper text box still appears under the file picker.  This causes layout and styling issues for pages it is used in.  This issue is present (though not disruptive) on the storybook example.
The helper text also appears to be outside the bounds of the height assigned to the file picker, causing it to shift layouts when present.
To Reproduce:
Steps to reproduce the behavior:

Go to 'forge wiki page for file picker'
Right click on file picker and click inspect element
Navigate to the shadow root of the file picker
Mouse over The div with part="helper-text-container"
See that it is present in the layout despite there being no text.

Expected behavior:
The helper text box should not be present in the layout if there is no helper text.
Screenshots:
Here, the helper text area is present despite the absence of helper text, and it is placed in addition to the area assigned to the file picker, causing unwanted scrolling.

Please complete the following information:

Forge version: 2.4.0
I have searched existing issues before creating this report? Y
Browser: All
Platform: Desktop
OS: Windows

I think the culprit is this css rule
.forge-file-picker__helper-text::before {
    display: inline-block;
    width: 0;
    height: 16px;
    content: "";
    vertical-align: 0;
}

Which I believe comes from the helper-text mixin include here which in turn includes this mixin from material/mixin/_typography and looks like
/// Creates a baseline strut from the top of a container. This mixin is for
/// advanced users, prefer `baseline()`.
///
/// @param {Number} $distance - The distance from the top of the container to
///     the text's baseline.
@mixin baseline-top($distance, $query: feature-targeting.all()) {
  $feat-structure: feature-targeting.create-target($query, structure);

  &::before {
    @include feature-targeting.targets($feat-structure) {
      @include baseline-strut_($distance);

      vertical-align: 0;
    }
  }
}

As a work around use
forge-file-picker::part(helper-text-container) {
  display: none:
}


Should I copy graphql schema in each lambda function?

Note: If your question is regarding the AWS Amplify Console service, please log it in the
official AWS Amplify Console forum

Which Category is your question related to?

So I just pushed my lambda functions to the cloud and it doesn't have access to files outside the lambda function name - since I need to access the generated schema from src/graphql so I don't duplicate mutations. Should I copy the schema in each lambda function? or other ways?

I don't think it's wise to duplicate schema - I mean I can create scripts that will copy every time I compile a schema - but this can lead to bugs in future if a developer forgets to do that.
Amplify CLI Version

You can use amplify -v to check the amplify cli version on your system
What AWS Services are you utilizing?
amplify, lambda
Provide additional details e.g. code snippets
{
  "data": {
    "getSomeThing": null
  },
  "errors": [
    {
      "path": [
        "getSomeThing"
      ],
      "data": null,
      "errorType": "Lambda:Unhandled",
      "errorInfo": null,
      "locations": [
        {
          "line": 2,
          "column": 3,
          "sourceName": null
        }
      ],
      "message": "Error: Cannot find module '../../../../../../src/graphql/es2015/mutations'"
    }
  ]
}

@gautamkshitij the current tooling does not have out of box support for this kind of code sharing as it can be done in a lot of different ways from published packages to local file copying during the build process. The generated source files are outside of the lambda directory and are not deployed with the lambda, hence the error message. As you've stated you've to add this functionality to your project that fit your needs. Either as a script or some other ways.
Personally when I was in this situation I had a node package in the root of my repository and followed yalc guide to allow me to reference local packages in a clean way. It still requires yarn like commands to keep up to date with the references, but it worked well for me.
I'm closing the issue are the question is answered, if you have other related question feel free to reopen the issue or create a new one.


Error 503, no healthy upstream on API triggered runs

Hello,
as per title, in the last two days I get Error 503 (no healthy upstream) when trying to trigger runs through API. This is happening on two of my projects (one of which isn't receiving configuration changes since a month ago, so I tend to exclude this is due to changes on my part). When I trigger the run from the interface, it works just fine.
Are there currently server problems?

I'm seeing the same problem in my two projects since yesterday, I trigger the run from the API and it completes successfully, but the HTTP response for that API call is Error 503, no healthy upstream.
The first time I saw the problem was Feb 13, 2022 1:14:33 AM UTC

as of February 21th the problem seems to be solved, still I would like to know what caused and (expecially) if we can expect to see it again.

ARe you facing similar issues? I have an issue stating a lack of upstream availability?

Does anyone know why it was caused? I have a similar issue stating a lack of upstream availability?

No, I think it's related to Dataform being acquired by Google and being integrated into GCP. I contacted them some time ago and they basically told me that Dataform legacy (the standalone version) will not receive fixes because they will focus on the GCP version. It may be a good idea to perform a migration to Dataform GCP, if you can.


Investigate inactivation of Pod/functions not used

There is  a socket activation mechanism potentially usable, or to be developed in k8s upstream.
https://github.com/kubernetes/kubernetes/issues/484

I don't know where this ended up but it seems https://github.com/openshift/service-idler is doing some work on idling/unidling. Anything that can be leveraged from it?


Support for labels in apps

I'm using it in zoidberg already.

My other feature is missing as well, do you want a PR for it? mesosphere/marathon#1096

Sorry for the delay. Another PR would be cool ... though I'll merge this one is now ..


Remote Docker Engine

Use DOCKER_HOST or dockerode everywhere.
Needs to research on remote (ssh) docker engine access.

It is implemented, but not the remote resource checking (that will come soon).


Initial list of subjects/learning resources

:leaves: Add comments and subjects or learning resources are found.

Math:
https://www.khanacademy.org/math
http://ocw.mit.edu/courses/find-by-topic/#cat=mathematics


Support entry post templates

Is your feature request related to a problem? Please describe.
I have been using Netlify CMS for a short while, mostly for my team's wiki so we use a template for creating our wiki entries. Currently, we have a template in our collection that we duplicate but as the site has grown in entries it has become increasingly laborious to go to the template and duplicate each time we make a post.
Describe the solution you'd like
What would be really great is if when we create a new entry for a collection we can assign a default template to use when creating a new post for example

when clicking the "New RFCs" button instead of being presented with a blank entry we can use a template for the RFC then be presented with the template text already in the editor like this:

In the config,yml file we could have a field called new_entry_template:
collections:
  - label: RFCs
    name: rfcs
    folder: rfcs
    slug: "{{title}}"
    create: true
    new_entry_template: rfcs/template.md
    editor:
      preview: false
    fields:
      - label: Title
        name: title
        widget: string
      - label: Summary
        name: summary
        widget: text
        required: true
        hint: What is the overall goal of this RFC?
      - label: Body
        name: body
        widget: markdown
      - label: Sidebar
        name: sidebar
        widget: hidden
        default: true

Describe alternatives you've considered
Well, the only alternative that I know of so far is to duplicate an existing entry in a collection or have a template.md file in a collection that we can duplicate every time but this just pollutes the entries in the CMS and does not really solve the problem at hand

As a workaround, you could set a default value for the markdown widget like so:
- name: body
  label: Body
  widget: markdown
  default: >-
    # This is a title

@tomrutgers Thanks for the tip, but I think that would pollute the config drastically if your template is huge which in my case it is unless I resort to generating the config.yml file and injecting the default template but that can get messy quickly. Thanks :smile:

enerating the config.yml file and injecting the default template but that can get messy quickly

You could use JavaScript to initialise the config:
https://www.netlifycms.org/docs/beta-features/#manual-initialization
Which might make that easier

Dupplicate of this : https://github.com/netlify/netlify-cms/issues/4664#issuecomment-736450898
I think more of this feature like the gitlab options (see my issue).
Having a dropdown, and then selecting the template that we want.
In the config file, we would have a template option that points to a folder or a list of files.
What do you think @ShailenNaidoo  ?


Improvement lru support evict expired entries

Proposed changes
Lru cache support evict expired entries.
Problem summary
When the LRUCache is full and there are slow queries which scan a lot of bytes, the LRUCache may have side effect. We can avoid this by evict expired entries using background thread every minute.
Checklist(Required)

[x] Does it affect the original behavior
[x] Has unit tests been added
[ ] Has document been added or modified
[ ] Does it need to update dependencies
[x] Is this PR support rollback (If NO, please explain WHY)

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run buildall

run buildall

run buildall

run buildall

run buildall


Unconditional dependency on pandas/numpy increases package size by ~24x (<6MB -> 135MB)

Thank you for publishing a client library!
Issue
The here-location-services package currently unconditionally depends on pandas, which depends on numpy, pytz and python-dateutil. On x86-64 Linux (for Python 3.9), these end up being very large (~130MB), with all of the rest of the dependencies being ~5MB. However, pandas is only used for converting the result for two functions associated with the matrix routing API:
https://github.com/heremaps/here-location-services-python/blob/325b4c08bddcce49c08b6eaf8660e9d1a30022fb/here_location_services/responses.py#L151-L182
It seems unfortunate to require these huge dependencies to be installed for only these wo functions when many people are likely to not be calling them anyway, and when the dependencies seemingly aren't required for any additional functionality within this client library.
Potential alternatives

Have pandas be an optional dependency (for example, via extra_requires={"pandas": ["pandas"]} in setup.py), and import it on-demand in the individual functions that need it. For example:def to_distnaces_matrix(self):
    """Return distnaces matrix in a dataframe."""
    try:
        from pandas import DataFrame
    except ImportError as e:
        raise ImportError("pandas is not installed, run `pip install here-location-services[pandas]`) from e

    # ... existing implementation as before ...

For an example of prior art, this option is what the popular Pydantic library does:

'extra' dependency on python-dotenv: https://github.com/samuelcolvin/pydantic/blob/8846ec4685e749b93907081450f592060eeb99b1/setup.py#L134-L137
importing from dotenv within a function (not at the top level) and catching the ImportError to provide additional help to the user: https://github.com/samuelcolvin/pydantic/blob/8846ec4685e749b93907081450f592060eeb99b1/pydantic/env_settings.py#L297-L300

Remove the pandas dependency totally, and have the functions return the nested lists (nested_distances) without converting to a DataFrame. A user who wants to use pandas can still convert to a DataFrame themselves: DataFrame(result.to_distnaces_matrix()) (the columns= argument seems to be unnecessary, as doing that call gives the same result AFAICT).

Both of these are probably best considered as breaking changes.
Context
We were attempting to use this package in an AWS Lambda, which has strict size limits on the size of the code asset, and exceeding it results in errors like 'Unzipped size must be smaller than 262144000 bytes' when deploying (relevant docs: https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html#function-configuration-deployment-and-execution "Deployment package (.zip file archive)"). Additionally, larger packages result in slower cold starts: https://mikhail.io/serverless/coldstarts/aws/ .
There's various ways to provide more code beyond the size limits (layers or docker images), but this provides some context for why someone might care about the size of a package and its dependency. (Those methods are fiddly enough and the cold start impact large enough that we've actually switched away from using this client library for now.)
Package size details
Here's some commands I used to investigate the size impact, leveraging pip install --target to install a set of packages to a specific directory:
uname -a # Linux 322c9a327f85 5.10.104-linuxkit #1 SMP PREEMPT Wed Mar 9 19:01:25 UTC 2022 x86_64 GNU/Linux
python --version # Python 3.9.10

pip install --target=everything here-location-services
pip install --target=deps-no-pandas requests geojson flexpolyline pyhocon requests_oauthlib
pip install --target=deps-no-pandas requests geojson flexpolyline pyhocon requests_oauthlib pandas

du -sh everything # 135M
du -sh deps-pandas # 134M
du -sh deps-no-pandas # 5.1M
du -sh everything/here_location_services # 484K

That is, without pandas, the total installed package size would be 5.1M (deps-no-pandas) + 484K (everything/here_location_services) = ~5.6MB, down from 135MB (everything).
Summary of individual packages (reported by du -sh everything/*, ignoring the $package.dist-info directories that are mostly less than 50k anyway):

package
size
only required for pandas?

pandas
58M
yes

numpy.libs
35M
yes

numpy
33M
yes

pytz
2.8M
yes

oauthlib
1.4M

urllib3
872K

dateutil
748K
yes

idna
496K

here_location_services
484K

8 others
1.5M

Upvote this as well. Just ran into this with our AWS lambda as well. Are there any alternatives to make this work with lambda without doing too much work around?


Pool does not exist error after mysql services restarted.

Hello,
I am using poolCluster.
It works great, unless I reboot mysql or restart the mysql services.  Then poolcluster seems to break, and returns the error "Pool does not exist".  If I restart my node application, everything works fine again.
app (err):     at PoolCluster._getConnection (/home/ssp/node_modules/mysql/lib/PoolCluster.js:151:13)
app (err):     at PoolNamespace.getConnection (/home/ssp/node_modules/mysql/lib/PoolCluster.js:190:11)
app (err):     at /home/ssp/node_modules/mysql/lib/PoolCluster.js:195:24
app (err):     at /home/ssp/node_modules/mysql/lib/PoolCluster.js:154:7
app (err):     at Handshake.onConnect (/home/ssp/node_modules/mysql/lib/Pool.js:54:9)
app (err):     at Handshake.Sequence.end (/home/ssp/node_modules/mysql/lib/protocol/sequences/Sequence.js:96:24)
app (err): Error: connect EHOSTUNREACH
app (err):     at exports._errnoException (util.js:746:11)
app (err):     at TCPConnectWrap.afterConnect [as oncomplete] (net.js:983:19)
app (err):     --------------------
app (err):     at Protocol._enqueue (/home/ssp/node_modules/mysql/lib/protocol/Protocol.js:135:48)
app (err):     at Protocol.handshake (/home/ssp/node_modules/mysql/lib/protocol/Protocol.js:52:41)
app (err):     at PoolConnection.connect (/home/ssp/node_modules/mysql/lib/Connection.js:109:18)
app (err):     at Pool.getConnection (/home/ssp/node_modules/mysql/lib/Pool.js:45:23)
app (err):     at PoolCluster._getConnection (/home/ssp/node_modules/mysql/lib/PoolCluster.js:151:13)
app (err):     at PoolNamespace.getConnection (/home/ssp/node_modules/mysql/lib/PoolCluster.js:190:11)
app (err):     at /home/ssp/node_modules/mysql/lib/PoolCluster.js:195:24
app (err):     at /home/ssp/node_modules/mysql/lib/PoolCluster.js:154:7
app (err):     at Handshake.onConnect (/home/ssp/node_modules/mysql/lib/Pool.js:54:9)
app (err):     at Handshake.Sequence.end (/home/ssp/node_modules/mysql/lib/protocol/sequences/Sequence.js:96:24)
Could anyone shed some light on this, and offer any suggestions on how to fix this problem?
Thank-you!

This is because in PoolCluster, after you reach removeNodeErrorCount errors in a row (defaults to 5), then the server is completely removed. What it sounds like is you need to set the restoreNodeTimeout option so after a while, the cluster will once again attempt to connect.
You can read more about the options at https://github.com/felixge/node-mysql#poolcluster-option

Thanks for the quick response -- I'll experiment with this

@rabbitfufu - Did you get anywhere with this? I'm working on the same problem.

Closing due to lack of response or activity. Please feel free to post back here and I can always reopen :)


[Features Request] Regarding the 'TV Shows -> Progress'

I decided to make a new issue so it will be easier to follow.

Add the aired date info also next to each episode name in the start of the line.
Because the air dates are one of the thing here, and some of the View Modes in the skin doesn't show it.

In addition to (1), add an option (In the Settings) for setting the date format, for example %d-%m-%y or %y-%m-%d etc. (Text input by user)

Add an options (In the Settings) for sorting this progress list:
• By Air Date / Previously aired
• By Title (Name)
• Recently collected
In SALTS it is done by the addon and selected in its Settings and not by kodi.
Kodi has only two option 'Date' and 'Genre' and this is no what I meant.
And by the way, kodi built-in sorting by 'Date' doesn't work or affect the list order.

Change the name. Instead of 'Progress' ,change it to "My Next Episodes".

I have already understood that you don't like it, but maybe one day in the future:
To colorize the air date and the aired/not aired episode title in different color for distinction and nice look (Like in the example below)
No one has ever complained about it or had a skin issues about it.

Examples (According to SALTS addon):

Settings:

'Progress' list (My Next Episode)

Currently implementation in Elementum 0.0.39:

Regarding the future episodes - Thumbnail image:
For regular exist episodes, the fanart that is shown is the episode image, and also the thumbnail (which  based on this episode's fanart image)
But, because you are using the TVDB, for future unaired episodes, these episodes doesn't have an episode image, so thumbnail is shown as blank, but the fanart image shows the TV Show fanart which is good.
So my request here is to do a check, so if there is no episode/thumbnail image, use the TV Show fanart image as the thumbnail image instead of the episode image.

This is how it's look today:
https://s18.postimg.org/c0hpr8iax/screenshot015.png

This is how it's look today:
https://s18.postimg.org/c0hpr8iax/screenshot015.png

That is only on progress page?

From what I have checked so yes. As I said only in 'progress' you can see future episodes and future episodes still haven't image yet in TVDB. This is why you show it as blank. But they do have their TV-Show fanart instead so you can use it as thumbnail instead on this case.

Please add these new options in the Settings for the 'Progress' section:

Show unaired/future episodes in 'Progress' - Enable/Disable (Default=Enable/On)
Exclude Completed/Ended shows from 'Progress' - Enable/Disable (Defualt=Disable/Off)
(Similar to the SALTS settings example)

@hoshsadiq
According to this: https://github.com/elgatito/plugin.video.elementum/issues/46#issuecomment-363451251

This is how it's look today:
https://s18.postimg.org/c0hpr8iax/screenshot015.png

That is only on progress page?

@elgatito

This is how it's look today:
https://s18.postimg.org/c0hpr8iax/screenshot015.png

That is only on progress page?

In addition to that I have now new episodes that don't get their thumbnail/fanart image.
I see why it happens, you are using TMDB for TV Shows and here for the 'Progress' section, instead of taking the images from TVDB or Trakt. TMDB is basically for Movies and not for TV Shows.
This is the reason why I still think it better to implement this request of selecting the main info source (Trakt/TVDB/TMDB)
https://github.com/elgatito/plugin.video.elementum/issues/87

@elgatito
Hi, This request is from old days, is there any chance that something would be done here according to all sections that mentioned?

Changes in v0.0.54:

Added settings for: colorize items, date format, sort of items in the list, allowing non-aired episodes.

Closing this issue. Future requests can be made in a separate issue.


Refactor driver to include Windows support (includes new transport for all supported platforms)

This pull request adds Windows support to the Kitchen driver.  It also includes a new transport which supports all supported Linux platforms and Windows.  We decided to add a new transport to leverage a lot of the same code the driver uses in the same code base so we can continue to build support for both Windows and Linux in one location within this gem.
I’m requesting feedback (and a code review) from the community on this approach and some help with additional testing.
This update fixes issues #259, #318, #338

@jeffreycoe This looks like a great effort. I have also been looking into this recently and as you have probablly seen, InSpec's Train docker transport doesn't understand how to detect Docker on Windows. As you probably found out, the docker-api gem used needs a bit of modernization in order to use the right Docker API version too when on Windows.  I have also been playing with this in a separate standalone driver that offers a 'dockercli' transport (name required by kitchen-inspec I believe).
Feel free to rescue any of the bits out of there you need. The driver with all my bits and monkeypatched DockerAPI and Train transport is at: https://github.com/stuartpreston/kitchen-dockerwin/

@stuartpreston Appreciate the feedback.  I’ll take a look at merging the code you referenced to see if we can get these updates working with InSpec.  Thanks!

I have tested this PR in the following environment:
OS: Windows 2019 Core Server
Ruby: ruby 2.6.3p62 (2019-04-16 revision 67580) [x64-mingw32]
MingGW: msys2 20180531.0.0
I had to install the Ruby Development Kit when installing the ruby gem from source code in order to compile the dependencies that require low level libraries.
gem list --local
PS C:\Users\vagrant\test-kitchen-poc> gem list --local

*** LOCAL GEMS ***

bcrypt_pbkdf (1.0.1 x64-mingw32)
bigdecimal (default: 1.4.1)
builder (3.2.3)
bundler (default: 1.17.2)
cmath (default: 1.0.0)
csv (default: 3.0.9)
date (default: 2.0.0)
dbm (default: 1.0.0)
did_you_mean (1.3.0)
e2mmap (default: 0.1.0)
ed25519 (1.2.4)
equatable (0.5.0)
erubis (2.7.0)
etc (default: 1.0.1)
fcntl (default: 1.0.0)
ffi (1.11.1 x64-mingw32)
fiddle (default: 1.0.0)
fileutils (default: 1.1.0)
forwardable (default: 1.2.0)
gdbm (default: 2.0.0)
gssapi (1.3.0)
gyoku (1.3.1)
httpclient (2.8.3)
io-console (default: 0.4.7)
ipaddr (default: 1.2.2)
irb (default: 1.0.0)
json (default: 2.1.0)
kitchen-docker (2.9.0)
license-acceptance (1.0.13)
little-plugger (1.1.4)
logger (default: 1.3.0)
logging (2.2.2)
matrix (default: 0.1.0)
minitest (5.11.3)
mixlib-install (3.11.18)
mixlib-shellout (2.4.4 universal-mingw32)
mixlib-versioning (1.2.7)
multi_json (1.13.1)
mutex_m (default: 0.1.0)
necromancer (0.5.0)
net-scp (2.0.0)
net-ssh (5.2.0)
net-ssh-gateway (2.0.0)
net-telnet (0.2.0)
nori (2.6.0)
openssl (default: 2.1.2)
ostruct (default: 0.1.0)
pastel (0.7.2)
power_assert (1.1.3)
prime (default: 0.1.0)
psych (default: 3.1.0)
rake (12.3.2)
rdoc (default: 6.1.0)
rexml (default: 3.1.9)
rss (default: 0.2.7)
rubyntlm (0.6.2)
rubyzip (1.2.3)
scanf (default: 1.0.0)
sdbm (default: 1.0.0)
shell (default: 0.7)
stringio (default: 0.0.2)
strings (0.1.5)
strings-ansi (0.1.0)
strscan (default: 1.0.0)
sync (default: 0.5.0)
test-kitchen (2.2.5)
test-unit (3.2.9)
thor (0.20.3)
thwait (default: 0.1.0)
tomlrb (1.2.8)
tracer (default: 0.1.0)
tty-box (0.4.0)
tty-color (0.4.3)
tty-cursor (0.7.0)
tty-prompt (0.19.0)
tty-reader (0.6.0)
tty-screen (0.7.0)
unicode-display_width (1.6.0)
unicode_utils (1.4.0)
webrick (default: 1.4.2)
win32-process (0.8.3)
winrm (2.3.2)
winrm-elevated (1.1.1)
winrm-fs (1.3.2)
wisper (2.0.0)
wmi-lite (1.0.2)
xmlrpc (0.3.0)
zlib (default: 1.0.0)

kitchen.yml
---
driver:
  name: docker

platforms:
- name: windows
  driver_config:
    image: mcr.microsoft.com/windows/servercore:ltsc2019
    platform: windows

provisioner:
  name: shell

transport:
  name: docker
  env_variables:
    TEST_KEY: TEST_VALUE

suites:
  - name: default
    verifier:
      inspec_tests:
        - test/integration/default
      attributes:

output
PS C:\Users\vagrant\test-kitchen-poc> kitchen test
-----> Starting Kitchen (v2.2.5)
-----> Cleaning up any prior instances of <default-windows>
-----> Destroying <default-windows>...
       Finished destroying <default-windows> (0m0.00s).
-----> Testing <default-windows>
-----> Creating <default-windows>...
       Sending build context to Docker daemon  9.728kB
       Step 1/1 : FROM mcr.microsoft.com/windows/servercore:ltsc2019
        ---> 3e9dc86c64a9
       Successfully built 3e9dc86c64a9
       21a58d6a8e64333bbaa14f37c772bdb699cd0f0d5fca0b29eae5f5b54456009a
       Finished creating <default-windows> (0m1.72s).
-----> Converging <default-windows>...
       Preparing files for transfer
       Preparing script
       No provisioner script file specified, skipping
       [Docker] Executing command on container
       Transferring files to <default-windows>
       Downloading files from <default-windows>
       Finished converging <default-windows> (0m16.73s).
-----> Setting up <default-windows>...
       Finished setting up <default-windows> (0m0.00s).
-----> Verifying <default-windows>...
       Preparing files for transfer
       Transferring files to <default-windows>
       Finished verifying <default-windows> (0m0.02s).
-----> Destroying <default-windows>...
       [Docker] Destroying Docker container 21a58d6a8e64333bbaa14f37c772bdb699cd0f0d5fca0b29eae5f5b54456009a
       Name                PID                 CPU                 Private Working Set
       smss.exe            2904                00:00:00.109        278.5kB
       csrss.exe           3192                00:00:00.171        1.098MB
       wininit.exe         836                 00:00:00.062        1.118MB
       services.exe        844                 00:00:00.421        1.831MB
       lsass.exe           3340                00:00:00.218        3.453MB
       svchost.exe         3960                00:00:00.234        1.937MB
       fontdrvhost.exe     1924                00:00:00.000        577.5kB
       svchost.exe         2228                00:00:00.140        2.2MB
       svchost.exe         2868                00:00:00.359        4.841MB
       svchost.exe         1508                00:00:00.062        2.441MB
       CExecSvc.exe        2768                00:00:00.078        983kB
       svchost.exe         2608                00:00:00.437        5.882MB
       PING.EXE            3708                00:00:00.046        598kB
       svchost.exe         784                 00:00:02.375        4.059MB
       svchost.exe         3232                00:00:00.015        892.9kB
       svchost.exe         2052                00:00:00.390        6.963MB
       svchost.exe         2720                00:00:00.031        1.118MB
       21a58d6a8e64333bbaa14f37c772bdb699cd0f0d5fca0b29eae5f5b54456009a
       21a58d6a8e64333bbaa14f37c772bdb699cd0f0d5fca0b29eae5f5b54456009a
       Finished destroying <default-windows> (0m1.38s).
       Finished testing <default-windows> (0m20.09s).
-----> Kitchen is finished. (0m20.38s)
PS C:\Users\vagrant\test-kitchen-poc>

It created the container and destroys it but seems that is not executing my test yet.
Will add a few tests and get back.

@jeffreycoe
I did another test using the verifier section pointint to inspec and I got the following results...
https://gist.github.com/lmayorga1980/8c3922f6133d16dfc9025938bd2b3049

@lmayorga1980 Thanks for testing and glad to see the create, converge, and destroy phases worked so far. I'm still looking into the InSpec verifier to see what needs to be updated to support Windows.

I see, I guess change beed to through kitchen-inspec first since its crashing on the Transport piece

@jeffreycoe
Using the last commit of the PR.
...
Using net-ssh-gateway 2.0.0
Using winrm-elevated 1.1.1
Using test-kitchen 2.2.5
Using kitchen-docker 2.9.0 from git://github.com/jeffreycoe/kitchen-docker.git (at windows-support@9ceb39d)
Using kitchen-inspec 1.1.0
Bundle updated!

PS C:\users\vagrant\test-kitchen-poc> bundle exec kitchen test
-----> Starting Kitchen (v2.2.5)
-----> Cleaning up any prior instances of <default-windows>
-----> Destroying <default-windows>...
       [Docker] Destroying Docker container 91e5b7503de0acc7c95ca966adc5afab26cd910d47468eca8882cab155676450
       Error response from daemon: No such container: 91e5b7503de0acc7c95ca966adc5afab26cd910d47468eca8882cab155676450
       Finished destroying <default-windows> (0m0.17s).
-----> Testing <default-windows>
-----> Creating <default-windows>...
       Sending build context to Docker daemon  24.58kB
       Step 1/1 : FROM mcr.microsoft.com/windows/servercore:ltsc2019
        ---> 3e9dc86c64a9
       Successfully built 3e9dc86c64a9
       932e38f4674f1de22cfe9d151bbc77db17717157d60c2f864b98b717459cbfd5
       Finished creating <default-windows> (0m1.52s).
-----> Converging <default-windows>...
       Preparing files for transfer
       Preparing script
       No provisioner script file specified, skipping
       [Docker] Executing command on container
       Transferring files to <default-windows>
       Downloading files from <default-windows>
       Finished converging <default-windows> (0m14.24s).
-----> Setting up <default-windows>...
       Finished setting up <default-windows> (0m0.00s).
-----> Verifying <default-windows>...
>>>>>> ------Exception-------
>>>>>> Class: Kitchen::ActionFailed
>>>>>> Message: 1 actions failed.
>>>>>>     Failed to complete #verify action: [Verifier Inspec does not support the Docker Transport] on default-windows
>>>>>> ----------------------
>>>>>> Please see .kitchen/logs/kitchen.log for more details
>>>>>> Also try running `kitchen diagnose --all` for configuration

---
driver:
  name: docker

provisioner:
  name: shell

verifier:
  name: inspec

platforms:
- name: windows
  driver_config:
    image: mcr.microsoft.com/windows/servercore:ltsc2019
    platform: windows

transport:
  name: docker
  env_variables:
    TEST_KEY: TEST_VALUE

suites:
  - name: default
    verifier:
      inspec_tests:
        - test/integration/default/default_spec.rb
      attributes:

stacktrace
I, [2019-06-16T05:58:48.479991 #5072]  INFO -- Kitchen: -----> Starting Kitchen (v2.2.5)
I, [2019-06-16T05:58:53.320514 #5072]  INFO -- Kitchen: -----> Cleaning up any prior instances of <default-windows>
I, [2019-06-16T05:58:53.325610 #5072]  INFO -- Kitchen: -----> Destroying <default-windows>...

I, [2019-06-16T05:58:54.971480 #5072]  INFO -- Kitchen: Sending build context to Docker daemon  27.14kB
I, [2019-06-16T05:58:54.982985 #5072]  INFO -- Kitchen: Step 1/1 : FROM mcr.microsoft.com/windows/servercore:ltsc2019
I, [2019-06-16T05:58:54.983134 #5072]  INFO -- Kitchen:  ---> 3e9dc86c64a9
I, [2019-06-16T05:58:54.987040 #5072]  INFO -- Kitchen: Successfully built 3e9dc86c64a9
I, [2019-06-16T05:58:55.177957 #5072]  INFO -- Kitchen: d94c425d4b9ee60b57903d99f44739e9979c1e9e5a02dcae33731ac1dd1c05e7
I, [2019-06-16T05:58:56.257466 #5072]  INFO -- Kitchen: -----> Converging <default-windows>...
I, [2019-06-16T05:58:56.460254 #5072]  INFO -- Kitchen: [Docker] Executing command on container
I, [2019-06-16T05:59:11.349503 #5072]  INFO -- Kitchen: -----> Setting up <default-windows>...
I, [2019-06-16T05:59:11.355550 #5072]  INFO -- Kitchen: -----> Verifying <default-windows>...
  (Thanks @stuartpreston for the code). So far, it seems to be working. I haven't encountered any issues.
Looking for some feedback and some additional testing with these latest commits. Thanks.

Also, I was testing with an older version of the ChefDK (v3.10.1), but I found there have been updates to the Train gem (starting in version 2.1.0) which help with detecting the Windows platform. I upgraded to the latest Chef Workstation 0.4.1 and it has been working with no issues.

Platform: Windows 2019 Core
Docker Version:
Client: Docker Engine - Enterprise
 Version:           18.09.6
 API version:       1.39
 Go version:        go1.10.8
 Git commit:        1578dcadd2
 Built:             05/04/2019 02:34:11
 OS/Arch:           windows/amd64
 Experimental:      false

Server: Docker Engine - Enterprise
 Engine:
  Version:          18.09.6
  API version:      1.39 (minimum version 1.24)
  Go version:       go1.10.8
  Git commit:       1578dcadd2
  Built:            05/04/2019 02:32:24
  OS/Arch:          windows/amd64
  Experimental:     false

Ruby: ruby 2.6.3p62 (2019-04-16 revision 67580) [x64-mingw32]
Results: https://gist.github.com/lmayorga1980/436d1a9011d6681267ee6ccc3410404a
I am not using ChefDK and using just the gems coming from rubygems.org

@lmayorga1980 Forgot to mention it doesn't support named pipes yet, so by default the transport has to be configured to use a TCP socket so the InSpec verifier works.
Can you configure the Docker engine to listen on a TCP port and try again? I updated the readme to include this info now.
You'll need to update the C:\ProgramData\docker\config\daemon.json file and add the following value (and recycle the Docker services):
"hosts": ["tcp://<IP_ADDRESS>:2375"]

Example configuration is shown below:
{
  "registry-mirrors": [],
  "insecure-registries": [],
  "debug": true,
  "experimental": false,
  "hosts": ["tcp://<IP_ADDRESS>:2375"]
}

Then update your .kitchen.yml file to include the socket option in the transport section:
transport:
  name: docker
  socket: tcp://localhost:2375

@jeffreycoe ,
It worked 👍 🎉 🎈
PS C:\Users\vagrant> $env:DOCKER_HOST="tcp://localhost:2375"

PS C:\Users\vagrant\test-kitchen-poc> bundle exec kitchen test
-----> Starting Kitchen (v2.2.5)
C:/tools/ruby26/lib/ruby/gems/2.6.0/bundler/gems/kitchen-docker-ba58e25f34a3/lib/kitchen/docker/helpers/inspec_helper.rb:27: warning: already initialized constant Docker::API_VERSION
C:/tools/ruby26/lib/ruby/gems/2.6.0/gems/docker-api-1.34.2/lib/docker/version.rb:6: warning: previous definition of API_VERSION was here
-----> Cleaning up any prior instances of <default-windows>
-----> Destroying <default-windows>...
       [Docker] Destroying Docker container 06e6f383d15a83f6416857a68c0bc0424d14c1661133588764735e04bd909c46
       Error response from daemon: No such container: 06e6f383d15a83f6416857a68c0bc0424d14c1661133588764735e04bd909c46
       Finished destroying <default-windows> (0m0.18s).
-----> Testing <default-windows>
-----> Creating <default-windows>...
       Sending build context to Docker daemon  2.048kB
       Step 1/1 : FROM mcr.microsoft.com/windows/servercore:ltsc2019
        ---> 3e9dc86c64a9
       Successfully built 3e9dc86c64a9
       ef03a05e94064b1ee075702eea92e4e63a1c37baf21cb0da2348ceded648b1a6
       Finished creating <default-windows> (0m1.61s).
-----> Converging <default-windows>...
       Preparing files for transfer
       Preparing script
       No provisioner script file specified, skipping
       Transferring files to <default-windows>
       [Docker] Executing command on container

       Name             : ConsoleHost
       Version          : 5.1.17763.503
       InstanceId       : 0620a69a-d5d7-45f3-93b1-fc946c0b6a55
       UI               : System.Management.Automation.Internal.Host.InternalHostUserI
                   nterface
       CurrentCulture   : en-US
       CurrentUICulture : en-US
       PrivateData      : Microsoft.PowerShell.ConsoleHost+ConsoleColorProxy
       DebuggerEnabled  : True
       IsRunspacePushed : False
       Runspace         : System.Management.Automation.Runspaces.LocalRunspace

       Downloading files from <default-windows>
       Finished converging <default-windows> (0m17.83s).
-----> Setting up <default-windows>...
       Finished setting up <default-windows> (0m0.00s).
-----> Verifying <default-windows>...
[2019-06-17T18:56:39-07:00] WARN: DEPRECATION: InSpec Attributes are being renamed to InSpec Inputs to avoid confusion with Chef Attributes. Use --input-file on the command line instead of --attrs.
       Loaded tests from {:path=>"C:.Users.vagrant.test-kitchen-poc.test.integration.default"}
       Loaded tests from {:path=>"C:.Users.vagrant.test-kitchen-poc.test.integration.default.default_spec.rb"}

Profile: tests from {:path=>"C:/Users/vagrant/test-kitchen-poc/test/integration/default"} (tests from {:path=>"C:.Users.vagrant.test-kitchen-poc.test.integration.default"})
Version: (not specified)
Target:  docker://ef03a05e94064b1ee075702eea92e4e63a1c37baf21cb0da2348ceded648b1a6

  File c:\
     [PASS]  should exist

Profile: tests from {:path=>"C:/Users/vagrant/test-kitchen-poc/test/integration/default/default_spec.rb"} (tests from {:path=>"C:.Users.vagrant.test-kitchen-poc.test.integration.default.default_spec.rb"})
Version: (not specified)
Target:  docker://ef03a05e94064b1ee075702eea92e4e63a1c37baf21cb0da2348ceded648b1a6

  File c:\
     [PASS]  should exist

Test Summary: 2 successful, 0 failures, 0 skipped
       Finished verifying <default-windows> (0m7.31s).
-----> Destroying <default-windows>...
       [Docker] Destroying Docker container ef03a05e94064b1ee075702eea92e4e63a1c37baf21cb0da2348ceded648b1a6
       Name                PID                 CPU                 Private Working Set
       smss.exe            4916                00:00:00.093        282.6kB
       csrss.exe           4940                00:00:00.171        1.122MB
       wininit.exe         4980                00:00:00.078        1.126MB
       services.exe        5024                00:00:00.281        1.929MB
       lsass.exe           5032                00:00:00.328        3.445MB
       svchost.exe         552                 00:00:00.109        2.159MB
       fontdrvhost.exe     4168                00:00:00.015        573.4kB
       svchost.exe         3904                00:00:00.062        1.942MB
       svchost.exe         4116                00:00:00.546        8.454MB
       svchost.exe         2848                00:00:00.046        2.408MB
       CExecSvc.exe        3080                00:00:00.140        958.5kB
       svchost.exe         1048                00:00:00.312        5.943MB
       PING.EXE            4132                00:00:00.031        606.2kB
       svchost.exe         4276                00:00:02.109        4.141MB
       svchost.exe         3364                00:00:00.031        892.9kB
       svchost.exe         1764                00:00:00.484        7.172MB
       svchost.exe         712                 00:00:00.015        1.118MB
       WmiPrvSE.exe        648                 00:00:00.078        2.535MB
       ef03a05e94064b1ee075702eea92e4e63a1c37baf21cb0da2348ceded648b1a6
       ef03a05e94064b1ee075702eea92e4e63a1c37baf21cb0da2348ceded648b1a6
       Finished destroying <default-windows> (0m1.44s).
       Finished testing <default-windows> (0m28.49s).
-----> Kitchen is finished. (0m35.74s)

Please Merge this. Looks good.

@lmayorga1980 I made some minor updates to organize things a little better for the overridden classes  to support the InSpec verifier on Windows.  CI tests have been updated for Windows, too.
As long as the tests complete successfully, and no one has any issues with the code, we should be able to merge now.

@jeffreycoe :+1: I will be running some specific tests this week but everything in the PR looks good.
Thanks for including this desired feature...

@lmayorga1980 Thanks for all of your help with testing.
Looks like my testing completed successfully, and the CI tests passed with the last commit. This PR is ready to be merged.

@jeffreycoe no problem. Let me know if there is something I could do.

@stuartpreston Thanks for approving. Would we be able to merge the code at this point?
Let us know if you need anything else from us. Thanks.

@stuartpreston Can you merge this PR?

Happy to merge the PR but we need someone with the relevant org access to push the gem, etc. I'll see if I can find someone with the correct permissions.

Much appreciated :+1:

@stuartpreston Thank you!

@stuartpreston Would you mind creating a new release with this code included?

Hi @yeoldegrove - @stuartpreston isn't able to release the gem, but only merge code into this repo. I've reached out to someone who is working on getting the right individuals involved who can release this gem. It should be available soon, hopefully.

Hi @jeffreycoe !
Thank you for the rework.
Unfortunately when destroying the instances, however, the docker images are automatically removed, but then it produces an exception:
>>>>>> ------Exception-------
>>>>>> Class: Kitchen::ActionFailed
>>>>>> Message: 1 actions failed.
>>>>>>     Failed to complete #destroy action: [Expected process to exit with [0], but received '1'
---- Begin output of docker -H unix:///var/run/docker.sock rmi 29d6ee71040d ----
STDOUT:
STDERR: Error response from daemon: conflict: unable to delete 29d6ee71040d (cannot be forced) - image is being used by running container a980e8f5cefc
---- End output of docker -H unix:///var/run/docker.sock rmi 29d6ee71040d ----
Ran docker -H unix:///var/run/docker.sock rmi 29d6ee71040d returned 1] on manager-amazonlinux-latest-kitchen-chef
>>>>>> ----------------------
>>>>>> Please see .kitchen/logs/kitchen.log for more details
>>>>>> Also try running `kitchen diagnose --all` for configuration

This image ID does not exist at all in my image list!
anyone is facing the same issue?
Kr,
Rshad

Hi @rshad - Could you open a new issue with the steps to reproduce? Are you using the code from the master branch? I have been running this code on macOS, Linux, and Windows machines and have not encountered this error yet.

Hi @jeffreycoe !
Yes, I first took the master branch, to solve the issue commented in #338, but I got an error when creating the container for each Kitchen instance, which was reported here https://github.com/test-kitchen/kitchen-docker/issues/355 and solved here https://github.com/test-kitchen/kitchen-docker/pull/356.
So I then took the fork branch of https://github.com/test-kitchen/kitchen-docker/pull/356 and got such error.
Kr,
Rshad

Hi @jeffreycoe !
I created an issue https://github.com/test-kitchen/kitchen-docker/issues/360 and the corresponding PR with the fix https://github.com/test-kitchen/kitchen-docker/pull/361.
Kr,
Rshad


[libjpeg-turbo/mozjpeg] Add conflict messages

Describe the pull request

What does your PR fix? Fixes #13323

libjpeg-turbo and mozjpeg cannot be installed at the same time, since mozjpeg is based on libjpeg-turbo.
The references are as follows:
https://github.com/mozilla/mozjpeg/blob/master/README.md
https://github.com/mozilla/mozjpeg/blob/master/README-mozilla.txt
Note: No need to test features.

/azp run

/azp run

@BillyONeal
Could you please help take a look what's wrong on CI pipelines in this PR?
Thanks.

@NancyLi1013 It fails vcpkg's end to end tests:
Failed at [../src/vcpkg-test/manifests.cpp(635)] with message:
value was error

if I had to guess because you said Port-version rather than Port-Version in the CONTROL here.

@NancyLi1013 It fails vcpkg's end to end tests:
Failed at [../src/vcpkg-test/manifests.cpp(635)] with message:
value was error

if I had to guess because you said Port-version rather than Port-Version in the CONTROL here.

Thanks for your help to pointing this out @BillyONeal.
Sorry, it's my mistake. Hope all checks pass this time.

Thanks for your help to pointing this out @BillyONeal.
Sorry, it's my mistake. Hope all checks pass this time.

/azp run

/azp run

Maybe we should add a vcpkg_conflict_port function instead.

Maybe we should add a vcpkg_conflict_port function instead.


securefs-mac 0.13.0

Created by brew bump

Created with brew bump-formula-pr.

Thanks for the heads-up, bottling in progress.

Wouldn't it be easier to implement the same Actions workflow as homebrew-core?

No. Unlike Homebrew, I don't have enough hardware to dedicate a single box per macOS version, so I can't afford to have one PR automatically trigger 4 simultaneous bottling process.


add SIP 010 - Key-Value Storage

SIP — https://github.com/dicej/spin/blob/sip-010-key-value/docs/content/sips/010-key-value.md

@lann I think the idea with consume-async would be that it returns a pseudo-stream handle which you could read from in chunks and thereby avoid buffering the whole thing in memory.  Although consume-chunked would be a better name for that.  Or we could go a step further and mimic WASI Preview 2's pseudo-streams and pseudo-futures (now called waitable, I believe) for a more genuine async experience, all while still using the plain old modules and the antiquated WIT syntax.  I do think that's all out of scope for the initial implementation, though.

I do think that's all out of scope for the initial implementation, though.

No concerns from me then.

I realize this is late in the review process for the SIP, so apologies.
Do we think that we could also add a list or get-all (as it is defined in the upstream WASI KV proposal) operation to the initial API?
I could imagine this being extremely useful for various (even early) scenarios, and I would like to use it in Spin components soon.

Do we think that we could also add a list or get-all (as it is defined in the upstream WASI KV proposal) operation to the initial API?

I'm not seeing list or get-all in the upstream proposal.  I'm guessing list would get all the keys in a store, while get-all would get all the key-value pairs in a store?  If so, they seem reasonable to add.

list-keys is probably the most generally applicable feature. Getting all values might be getting into "probably want some kind of streaming/pagination" territory.

Sorry, get-keys is the function:
interface "wasi:kv/data/get-many" {
  // get_many returns a stream of key-value pairs.
  // Notice hat this interface is non-atomic, meaning that the key-value pairs
  // returned may not be consistent.

  use { Error, payload } from "wasi:kv/types"

  get-many: func(keys: keys) -> result<stream<payload>, Error>

  get-keys: func() -> result<keys, Error>
}

Recent changes:

change error::runtime to error::io
add get-keys function to interface
add Implementation requirements section
remove --key-value-database CLI option in favor of a runtime config CLI


Support for per-cluster and operator global sidecars

Based on the work of @theRealWardo to to implement per-cluster sidecards

Add support for operator-global sidecards (currently crude, as we only allow the list of docker images, and the optional variables (besides mandatory POD_NAME, POD_NAMESPACE, POSTGRES_USER and POSTGRES_PASSWORD ) can only be propagated via either pod_environment_configmap or Pod Presets. Should be improved once https://github.com/zalando-incubator/postgres-operator/pull/326 is merged).

Do refactoring around the code that generates the statefulset, particularly, decouple most of the helper routines from the cluster object in order to simplify their testing in the future, as well as to convert the scalar configuration internally to a sidecar structure to use the common code path.

How would this solution help us with our Scalyr Sidecar? I dont see how to inject the key on global level?

Well, outside of making the code less horrible by converting the scalyr hard-code to the same sidecar structure used to inject other sidecars so far it doesn't. However, I don't think it should be our goal to cram those things into the operator; what I propose instead is to rely on the Kubernetes feature called PodPresets to inject environment variables and remove all duplication of it (namely, https://postgres-operator.readthedocs.io/en/latest/administrator/#custom-pod-environment-variables) from the operator altogether.

👍

Coverage decreased (-0.2%) to 4.676% when pulling e4f60e89d34df6864ac5bf3864534bbabff8d047 on refactoring/sidecars into 74b19b449e5c77b15cc4ccae0d96ce537392ca57 on master.

:+1:

👍

:+1:

awesome! thanks for carrying this through!


Only bar buttons?

Does It work with normal buttons? Or only bar buttons?

As of right now it is only designed to work on the right side of the navigation bar using bar buttons.


Add W, B, E hints

Feature Request: Adding W, B, E, gE hints will be useful. Showing the position directly could greatly improve the efficiency!

Big word motions are something I want to support, but its probably after count motions and % motion gets implemented
Thanks for the suggestion
If this is something you or somebody else wanted to work on, I would be more than happy to help with how the implementation should work


[BUG] SSH Shell instant disconnects

Rancher Server Setup

Rancher version: 2.7.6
Installation option (Docker install/Helm Chart): Helm

If Helm Chart, Kubernetes Cluster and version (RKE1, RKE2, k3s, EKS, etc): RKE2 1.26.8

Information about the Cluster

Kubernetes version: 1.26.8
Cluster Type (Local/Downstream): Local (RKE2 1.26.8) and Downstream (vSphere provisioned RKE2 1.26.8)

User Information

What is the role of the user logged in? Admin

Describe the bug
When trying to connect to the host using the SSH Shell feature in Rancher the terminal is disconnected right away. Looking into the logs of the rancher pods it gives the followin error [ERROR] Unknown error: dial tcp: address fe80::250:56ff:fe9a:3d45:22: too many colons in address.
The host is actually configured with an IPv4 and IPv6 address, but even after removing / disabling IPv6 on the host Rancher still tries to use the old IPv6 address.
vSphere states only one IP address (the IPv4), but Rancher still favours the IPv6 address. Where is this IPv6 address configured and how can I force Rancher to use the IPv4 address for the SSH Shell.
Note; it looks like it happens random on nodes. I have nodes with exactly the same configuration which works fine using SSH shell, while others goes into Disconnected state right away.

Looking further into this issue, it looks like it is related to the OS version the hosts are running. The hosts which works as expected have Ubuntu 22.04.1 running, while the others are running Ubuntu 22.04.3.

Hi, I have the same problem trying new ubuntu version (24.04) and I have worked around the issue disabling ipv6 at GRUB level following this article option 2. Disable Ipv6 using GRUB. Now I can ssh from the dashboard without issues.
I had to reprovision the machines in order for this to work. It's like you need to have ipv6 disabled during the machine provision so Rancher cannot save any Ipv6 that will be used later to try to connect.


fix(tiller): s/POD_NAMESPACE/TILLER_NAMESPACE/

Yup, just checked the installer, and I see that it was set to TILLER_NAMESPACE. I don't even want to know how you found that error.

photographic memory of environment variables


[AutoPR managementpartner/resource-manager] Add managementpartner/resource-manager/readme.typescript.md

Created to sync https://github.com/Azure/azure-rest-api-specs/pull/4198

(message created by the CI based on PR content)


⚠ Adacta-fintech.com has degraded performance

In d82bd79, Adacta-fintech.com (https://www.adacta-fintech.com) experienced degraded performance:

HTTP code: 200
Response time: 861 ms

Resolved: Adacta-fintech.com performance has improved in 3c645a9.


Cleared 2-3!

Purpose
Updated links Colaboratory notebooks and trained models.
I also updated the status of 1-4.

Awesome!


Add social media links on Alumni page

Validate the social media links added to the people on this page,
Add missing links.
https://sefglobal.org/about/alumni.html

I will do it

I will do it

I have finished this issue.have you finished this one or will I commit it?


⚠ Bofrost.es has degraded performance

In 1c6bf9c, Bofrost.es (https://www.bofrost.es) experienced degraded performance:

HTTP code: 200
Response time: 1536 ms

Resolved: Bofrost.es performance has improved in d51fbdf after 16 minutes.


How to access environment or Key values from a 'active build preset'

[Enter feedback here]
While the document seems to talk about 'active configuration preset' it does not say how to access it from 'active build preset'. Any details on this will help.

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

ID: 18671a37-b8d9-b8cd-51fc-c1cd267e6af5
Version Independent ID: 6f0932ad-998a-9449-dfff-259452ba20d5
Content: Configure and build with CMake Presets
Content Source: docs/build/cmake-presets-vs.md
Product: visual-cpp
Technology: cpp-tools
GitHub Login: @corob-msft
Microsoft Alias: corob

@harshakm-50063
I'm sorry you're not finding the information you need. I'd expect a build preset to include a configuration preset. It ought to provide access to the same environment values as the configuration preset. But perhaps I don't understand your question.

@harshakm-50063
I'm sorry you're not finding the information you need. I'd expect a build preset to include a configuration preset. It ought to provide access to the same environment values as the configuration preset. But perhaps I don't understand your question.

Yes. Build Preset, does includes a configuration preset. I can access environment variables defined in a 'configuration preset' using a ${env.Variable} as well as cmake preset tags as well using '$cmake.key}.
However, this works for the 'active configuration preset' and does NOT work for 'active build preset'


Do no longer reference (potentially outdated) versions in README

Instead just use a placeholder so there is no need to update the README after every release.

Thanks kwin, does indeed make it more safe for people who are oblivious of versions 😄


Unable to encode value as half-float

Trying to convert either a double or a single to a half float using the ICBORConverter, but not sure how to flag the value as a half float instead of a double.

For anyone else needing this:
   public sealed class HalfCBORConverter : ICBORConverter<Half>     {         public CBORObject ToCBORObject(Half obj)         {             byte[] bytes = Half.GetBytes(obj);             ushort bits = Half.GetBits(obj);             return CBORObject.FromFloatingPointBits(bits, bytes.Length);         }     }


TMC Location tables question

Sorry to bother you, but I just don't know where else to ask this question
I am playing with a map for VW/seat/Skoda cars (RNS510), trying to add our Slovenian TMC location tables to the map
Just wondering if anyone maybe saw this file format before
TMC consists of TMCINFO.ini which looks like this
[PROD]
PROD =  "RNS_EU_38"
SCOPE = "EU"
; DATE "2019_06_07H16:56"
;IoCo: Updated Austria, Belgium, Finland, France, Germany, Italy, Norway, Switzerland, UK with new versions.
[LT]
AUSTRIA        = 0xa,  1, "AT",   "aut_A_1_3_4",    9.53485,   46.41923,   17.11080,   48.99898, 0,       272678, , "A"
BELGIUM        = 0x6,  1, "BE",   "bel_6_1_3_1",    2.55995,   49.50883,    6.34339,   51.48590, 0,       187900, , "B"
SWITZERLAND    = 0x4,  9, "CH",   "che_4_9_6_7",    5.96445,   45.64020,   10.58965,   48.00405, 0,       167488, , "CH"
CZECH_REPUBLIC = 0x2, 25, "CZ",  "cze_2_25_7_0",   12.16019,   48.56245,   18.85167,   51.02279, 0,       407735, , "CZ"
GERMANY1       = 0x1,  1, "DE",  "deu_D_1_18_0",    5.87690,   47.38710,   15.00870,   55.01726  0,       857037, , "D"
GERMANY2       = 0xd,  1, "DE",  "deu_D_1_18_0",    5.87690,   47.38710,   15.00870,   55.01726, 0,       857037, , "D"
DENMARK        = 0x9,  9, "DK",  "dnk_9_9_12_0",    7.91384,   54.18433,   15.14151,   59.18825, 0,       229504, , "DK"
SPAIN          = 0xe, 17, "ES",  "esp_E_17_4_1",  -16.74393,   27.75962,    3.18844,   43.73141, 0,       593935, , "E"
FINLAND        = 0x6, 17, "FI",  "fin_6_17_2_5",   19.00100,   59.82831,   31.48623,   70.35791, 0,       668423, , "FIN"
FRANCE         = 0xf, 32, "FR", "fra_F_32_12_1",   -4.77149,   42.36702,    8.18458,   51.06969, 0,       950911, , "F"
UNITED_KINGDOM1= 0xc,  7, "GB",   "gbr_C_7_4_1",   -8.09545,   43.33306,    8.43887,   60.48963, 0,       519343, , "GB"
ITALY          = 0x5,  1, "IT",   "ita_5_1_4_3",    6.67319,   36.69411,   18.51336,   47.04999, 0,       922643, , "I"
NETHERLANDS    = 0x8, 17, "NL",  "nld_8_17_9_5",    3.35977,   50.75458,    7.22918,   53.44311, 0,       200305, , "NL"
NORWAY         = 0xf, 49, "NO",  "nor_F_49_6_0",    4.67033,   57.98448,   31.11448,   71.16779, 0,       320330, , "N"
SWEDEN         = 0xe, 33, "SE",  "swe_E_33_3_2",   11.15119,   55.34201,   24.14387,   68.44281, 0,       366049, , "S"
[LTX]
CZEECH_cs_utf8  = 0x2, 25, "CZ", "cze_2_25_7_0_1",   12.16019,   48.56245,   18.85167,   51.02279, 0,       425838, , "CZ", "cs"
[ET]
DANISH      = "dk", "danish",     "dansk",      0, 14413,
DUTCH       = "nl", "dutch",      "nederlands", 0, 18902,
ENGLISH     = "en", "english",    "english",    0, 13200,
FINNISH     = "fi", "finnish",    "suomi",      0, 14332,
FLEMISH     = "nl-BE", "flemish",    "vlaams",  0, 20388,
FRENCH      = "fr", "french",     "francais",   0, 14454,
GERMAN      = "de", "german",     "deutsch",    0, 10605,
ITALIAN     = "it", "italian",    "italiano",   0, 15510,
PORTUGUESE  = "pt", "portuguese", "portuguese", 0, 15231,
SPANISH     = "es", "spanish",    "espanol",    0, 12908,
CZECH       = "cs", "czech",      "czech",      0, 23183,
HUNGARIAN   = "hu", "hungarian",  "hungarian",  0, 16437,
NORWEGIAN   = "no", "norwegian",  "norwegian",  0, 10866,
POLISH      = "pl", "polish",     "polish",     0, 12236,
RUSSIAN     = "ru", "russian",    "russian",    0, 17280,
SWEDISH     = "sv", "swedish",    "svenska",    0, 13619,
TURKISH     = "tr", "turkish",    "turkish",    0, 11968,
CHINESE     = "zh", "chinese",    "chinese",    0, 16716,
[CAT]
CAT = "eventinfo_2011_11_30_eu_nar_chnexc"
[SETTINGS]
[ACP]
F-VM = "@Ps|YudMWEEGSxx|"

Looking at this file, it appears that
[LT] references files inside LOC folder and
[ET] references files inside LAN folder
all the files have readable strings inside
This file looks very familiar to me for some reason, I just don't know what it belongs to
I also have the program that supposebly reads this file format called DBAL.OUT (sadly only in binary form, and to make situation worse, the program is supposed to run on VxWorks (although if I am not mistaken, thats similar to linux, since it supports POSIX commands)
So yea, I am just wondering if anyone, maybe, just maybe would know this format
DBAL.zip
TMC2.zip
I know this is totaly not the right place to ask this thing, but not realy sure where would I, since you know TMC better then anyone else

I'll actually move this to the newly created Discussions section, then it's exactly in the right place!
Personally I haven't seen this kind of a binary location table format before. Normally LT's are in the "TMC Exchange" (CSV-based) format. This could also be their own proprietary database format.


SOLR-14607: LTR Query, the TimeAllowed parameter causes a timeout exception after no results

Description
When timeAllowed parameter is set, the SolrQueryTimeoutImpl function will be started to detect whether it has timed out when the term is loaded. When overtime, an ExitingReaderException is thrown.
In the process of scoreFeatures of LTRQuery, ExitingReaderException will occur in two stages.

scorer: Occurs when a term needs to be loaded to the LeafReaderContext when creating Weight.
score: The term needs to be loaded when some functions call getValue. For example, FloatPayloadValueSource.

So it can be compatible with this ExitingReaderException, and partly return. At least it's better than empty.
Solution
In scoreFeatures method, catch ExitingReaderException and return the currently loaded document.
Tests
Simulation throws ExitingReaderException in the scorer process, and partially returns the loaded document.
Simulation throws ExitingReaderException in the score process of Feature, partially returning the calculated document.
Checklist
Please review the following and check all that apply:

[x] I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
[x] I have created a Jira issue and added the issue ID to my pull request title.
[x] I have given Solr maintainers access to contribute to my PR branch. (optional but recommended)
[x] I have developed this patch against the master branch.
[x] I have run ant precommit and the appropriate test suite.
[x] I have added tests for my changes.

@cpoerschke I have resubmitted it. Please review this PR again, thanks.

@alessandrobenedetti Add a parameter to LTR that lets the user choose what to do with the timeout? What do you think?

@alessandrobenedetti Add a parameter to LTR that lets the user choose what to do with the timeout? What do you think?

mmm personally I don't think it is useful to have some results reranked and some not, depending on a time-out and with little control over knowing "up to what" was reranked.
So, in my opinion, I would not add it as a parameter, it will just add unnecessary complexity.


use datafusion plan_to_sql function instead of expr_to_sql

Hello,
This PR addresses the the issue #103

We need to use datafusion version 42  to make this PR work because of this patch https://github.com/apache/datafusion/commit/ddbdf4bf7f215c01aca435f8edd00412e84aab60.
We will wait until we merge the spiceai branch that has already updated to Datafusion version 42 #112