amr is an array

http://openid.net/specs/openid-connect-core-1_0.html#IDToken
amr
OPTIONAL. Authentication Methods References. JSON array of strings that are identifiers for authentication methods used in the authentication. For instance, values might indicate that both password and OTP authentication methods were used. The definition of particular values to be used in the amr Claim is beyond the scope of this specification. Parties using this claim will need to agree upon the meanings of the values used, which may be context-specific. The amr value is an array of case sensitive strings.

This will result in a OM change. We should tackle this soon.


fix: examples cdn

Description
fix examples cdn.
Type of change
Please select the relevant option.

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

Codecov Report

Merging #126 (2ee2872) into master (9dad4d2) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #126   +/-   ##
=======================================
  Coverage   90.77%   90.77%
=======================================
  Files         155      155
  Lines        7375     7375
  Branches     2026     2026
=======================================
  Hits         6695     6695
  Misses        559      559
  Partials      121      121

Continue to review full report at Codecov.

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


Bulbs styles v2

@collin @mparent61

Changes Unknown when pulling f2c2c3031fc80be1d6dbe0aa15fcf0f5114a180b on bulbs-styles-v2 into ** on master**.

Coverage remained the same at 85.258% when pulling 5ef55db8814654907840c1ecb08a90e153194951 on bulbs-styles-v2 into 1de1310271468f5648fe289abca82e72ccb170ce on master.

👍

👍  - assuming it won't break any integrating apps?

@spra85 AVC is the only site using bulbs-styles at the moment. I have an updated PR there: https://github.com/theonion/avclub/pull/459

Coverage remained the same at 85.258% when pulling ea045e8baa5abb348c4ddf3d57fde6f61723f6cd on bulbs-styles-v2 into 1de1310271468f5648fe289abca82e72ccb170ce on master.


Where is the book?

@tomer-ben-david It is in gitbook but as it is said still it is written. At first it will be written in Chinese then will be translated.

@tomer-ben-david have you found a similar book maybe?

@tonto although not stricktly about go system programming I have found the following book network programming with go to be extremely helpful.  http://tumregels.github.io/Network-Programming-with-Go/

@tomer-ben-david tnx, I also found this one https://www.amazon.com/Go-Systems-Programming-Master-programming/dp/1787125645/


Improving Navbar

In navbar options are showing multiple time which harness the UI of website. Will be happy to work on this issue. @skmirajulislam   Please assign me this issue under gssoc-extended , hacktober fest accepted and with appropriate level.

@Devanshu1603 resolved this issue!


'extend google.protobuf.FileOptions' in .milvus.proto.milvus Langchainjs 0.0.83 Nextjs

Describe the bug:
Langchainjs nextjs application Milvus.fromExistingCollition request is failing due to below error. compiled milvus-sdk-node is failing
Steps to reproduce:

Install latest version on LangChainjs 0.0.83
Dockerize as Langchainjs nextjs application
Error thrown in following line

const vectorStoreMilvus = await Milvus.fromExistingCollection(
      new OpenAIEmbeddings({}),
      {
        collectionName:  <>
      }
    );

Error :
error Error: unresolvable extensions: 'extend google.protobuf.FileOptions' in .milvus.proto.milvus
    at Root.resolveAll (/app/node_modules/protobufjs/src/root.js:256:15)
    at loadProtosWithOptionsSync (/app/node_modules/@grpc/proto-loader/build/src/util.js:68:16)
    at loadSync (/app/node_modules/@grpc/proto-loader/build/src/index.js:197:61)
    at getGRPCService (/app/node_modules/@zilliz/milvus2-sdk-node/dist/utils/Grpc.js:26:57)
    at MilvusClient.BaseClient (/app/node_modules/@zilliz/milvus2-sdk-node/dist/milvus/BaseClient.js:58:56)
    at MilvusClient.Collection [as constructor] (/app/node_modules/@zilliz/milvus2-sdk-node/dist/milvus/Collection.js:87:42)
    at MilvusClient.Data [as constructor] (/app/node_modules/@zilliz/milvus2-sdk-node/dist/milvus/Data.js:81:47)
    at MilvusClient.Index [as constructor] (/app/node_modules/@zilliz/milvus2-sdk-node/dist/milvus/MilvusIndex.js:72:42)
    at MilvusClient.Partition [as constructor] (/app/node_modules/@zilliz/milvus2-sdk-node/dist/milvus/Partition.js:61:42)
    at MilvusClient.Resource [as constructor] (/app/node_modules/@zilliz/milvus2-sdk-node/dist/milvus/Resource.js:61:42)

Milvus-node-sdk version:
Milvus version:

Let me do some test.

Would you like to share you code?

I have the same issue, running on vercel, sveltekit setup.
"@zilliz/milvus2-sdk-node": "^2.2.10",
relevant code 👇
`
import { DataType, MilvusClient } from '@zilliz/milvus2-sdk-node';
const client = new MilvusClient(address, secure, user, password);
	const collection_name = 'foobar';
	await client.loadCollectionSync({
		collection_name
	});

            const vector = [...Array(512)].map(() => Math.random());

	const res = await client.search({
	  collection_name,
	  vectors: [vector],
	  search_params: {
	    anns_field: "vector",
	    metric_type: "L2",
	    params: JSON.stringify({ nprobe: 64 }),
	    topk: '5',
	  },
	  output_fields: ['baz'],
	  vector_type: DataType.FloatVector,
	});

`

vercel

Thanks. maybe there is some limitation on vercel platform. let me test it.

it's the same for lower vector dims like 128

It breaks on Netlify as well, edge function related maybe.

Nextjs doesn't load proto files by default, you should modify webpack config: copy these file into the build folder.
This config works for me.
const path = require("path");
const CopyWebpackPlugin = require("copy-webpack-plugin");

/** @type {import('next').NextConfig} */
const nextConfig = {
  webpack: (config, { isServer }) => {
    config.module.rules.push({
      test: /\.(proto)$/,
      type: "asset/source",
    });

    if (isServer) {
      // Copy the proto files to the server build directory
      config.plugins.push(
        new CopyWebpackPlugin({
          patterns: [
            {
              from: path.join(
                __dirname,
                "node_modules/@zilliz/milvus2-sdk-node/dist"
              ),
              to: path.join(__dirname, ".next"),
            },
          ],
        })
      );
    }
    // Important: return the modified config
    return config;
  },
};

module.exports = nextConfig;

Nextjs 默认不加载 proto 文件，你应该修改 webpack 配置：将这些文件复制到构建文件夹中。
这个配置对我有用。
const path = require("path");
const CopyWebpackPlugin = require("copy-webpack-plugin");

/** @type {import('next').NextConfig} */
const nextConfig = {
  webpack: (config, { isServer }) => {
    if (isServer) {
      // Copy the proto files to the server build directory
      config.plugins.push(
        new CopyWebpackPlugin({
          patterns: [
            {
              from: path.join(
                __dirname,
                "node_modules/@zilliz/milvus2-sdk-node/dist"
              ),
              to: path.join(__dirname, ".next"),
            },
          ],
        })
      );
    }
    // Important: return the modified config
    return config;
  },
};

module.exports = nextConfig;

👋 我也碰到了类似的问题：ENOENT: no such file or directory, open 'C:/Users/Administrator/Desktop/official-website/.next/server/app/proto/proto/schema.proto'，你这个方案貌似解决了我的问题，棒棒哒🤣

@shanghaikid
Can the protoPath variable be configured? From the code, it seems to use __dirname, which would cause the protoPath to constantly change by caller route in Next.js, making it more troublesome to use.

Or make it next-milvus

v2.3.0 works like a charm. Thanks @shanghaikid

Hello,
I have the some problem with Nuxt3 when build app.
Package version : @zilliz/milvus2-sdk-node": "^2.3.1"
Error message:
unresolvable extensions: 'extend google.protobuf.FileOptions' in .milvus.proto.milvus
at Root.resolveAll (//.output/server/node_modules/protobufjs/src/root.js:256:15)
at loadProtosWithOptionsSync (//.output/server/node_modules/@grpc/proto-loader/build/src/util.js:68:16)
at loadSync (//.output/server/node_modules/@grpc/proto-loader/build/src/index.js:197:61)

Nextjs doesn't load proto files by default, you should modify webpack config: copy these file into the build folder.
This config works for me.
const path = require("path");
const CopyWebpackPlugin = require("copy-webpack-plugin");

/** @type {import('next').NextConfig} */
const nextConfig = {
  webpack: (config, { isServer }) => {
    if (isServer) {
      // Copy the proto files to the server build directory
      config.plugins.push(
        new CopyWebpackPlugin({
          patterns: [
            {
              from: path.join(
                __dirname,
                "node_modules/@zilliz/milvus2-sdk-node/dist"
              ),
              to: path.join(__dirname, ".next"),
            },
          ],
        })
      );
    }
    // Important: return the modified config
    return config;
  },
};

module.exports = nextConfig;

so this problem can not resolve? I think copy-webpack is a dirty code for me.

Nextjs doesn't load proto files by default, you should modify webpack config: copy these file into the build folder.
This config works for me.
const path = require("path");
const CopyWebpackPlugin = require("copy-webpack-plugin");

/** @type {import('next').NextConfig} */
const nextConfig = {
  webpack: (config, { isServer }) => {
    if (isServer) {
      // Copy the proto files to the server build directory
      config.plugins.push(
        new CopyWebpackPlugin({
          patterns: [
            {
              from: path.join(
                __dirname,
                "node_modules/@zilliz/milvus2-sdk-node/dist"
              ),
              to: path.join(__dirname, ".next"),
            },
          ],
        })
      );
    }
    // Important: return the modified config
    return config;
  },
};

module.exports = nextConfig;

so this problem can not resolve? I think copy-webpack is a dirty code for me.

You can define the milvus proto file in the clientOptions.  or you can create a pr to make it better.

Hey @shanghaikid .
I managed to run nextjs with your solution but just on "npm run dev"(when changing to what you said) but when I'm doing npm run build I get this error:
Collecting page data ..Error: Unable to load service: milvus.proto.milvus.MilvusService from XXXXXX/.next/proto/proto/milvus.proto but the file exists in the direcoty

Hey @shanghaikid . I managed to run nextjs with your solution but just on "npm run dev"(when changing to what you said) but when I'm doing npm run build I get this error: Collecting page data ..Error: Unable to load service: milvus.proto.milvus.MilvusService from XXXXXX/.next/proto/proto/milvus.proto but the file exists in the direcoty

same question here.

Hey @shanghaikid . I managed to run nextjs with your solution but just on "npm run dev"(when changing to what you said) but when I'm doing npm run build I get this error: Collecting page data ..Error: Unable to load service: milvus.proto.milvus.MilvusService from XXXXXX/.next/proto/proto/milvus.proto but the file exists in the direcoty

same question here.

https://github.com/milvus-io/milvus-sdk-node/tree/main/examples/nextjs you can check this example.

https://github.com/milvus-io/milvus-sdk-node/tree/main/examples/nextjs
Readme upgraded, close the issue.


Error: "Object of type Series[Unknown] is not callable" on groupby().size().to_frame()

Describe the bug
Calling to_frame() on a groupby().size() object causes the reportCallIssue: error: Object of type "Series[Unknown]" is not callable
To Reproduce
Minimal example:
import pandas as pd

data = [
    {"date": "2023-12-01", "val": 12},
    {"date": "2023-12-02", "val": 2},
    {"date": "2023-12-03", "val": 1},
    {"date": "2023-12-03", "val": 10},
]

df = pd.DataFrame(data)
groupby = df.groupby("date")
size = groupby.size()
frame = size.to_frame()
d = frame.reset_index()

Checking:
$ pyright test.py
test.py:14:9 - error: Object of type "Series[Unknown]" is not callable (reportCallIssue)

Please complete the following information:

OS: MacOS
OS Version: 14.3.1
python version: 3.12.2
version of type checker: 1.1.352
version of installed pandas-stubs: <IP_ADDRESS>218

Additional context
Issues was not present in pandas-stubs <IP_ADDRESS>227 with pyright 1.1.348

The error message here is a bit misleading, but the issue happens because the result of size() is a DataFrame or Series, dependent on whether the parameter as_index is False or True, respectively.  So we'd need to update the stubs to know whether as_index=False was passed in order to be able to type this correctly.
Closing as it is a duplicate of #652 and related to #203


Angular CLI 6.0.0 and Karma: Karma server don't rebuild code changes

Bug Report or Feature Request (mark with an x)
- [x] bug report
- [ ] feature request

Area
- [x] devkit
- [ ] schematics

Versions

     _                      _                 ____ _     ___
    / \   _ __   __ _ _   _| | __ _ _ __     / ___| |   |_ _|
   / △ \ | '_ \ / _` | | | | |/ _` | '__|   | |   | |    | |
  / ___ \| | | | (_| | |_| | | (_| | |      | |___| |___ | |
 /_/   \_\_| |_|\__, |\__,_|_|\__,_|_|       \____|_____|___|
                |___/

Angular CLI: 6.0.8
Node: 8.11.2
OS: darwin x64
Angular: 6.0.5
... common, compiler, compiler-cli, core, forms, http
... platform-browser, platform-browser-dynamic, router, upgrade

Package                           Version
-----------------------------------------------------------
@angular-devkit/architect         0.6.8
@angular-devkit/build-angular     0.6.8
@angular-devkit/build-optimizer   0.6.8
@angular-devkit/core              0.6.8
@angular-devkit/schematics        0.6.8
@angular/cli                      6.0.8
@ngtools/webpack                  6.0.8
@schematics/angular               0.6.8
@schematics/update                0.6.8
rxjs                              6.2.1
typescript                        2.7.2
webpack                           4.12.1

and my test.ts
import "zone.js/dist/zone-testing";
import { getTestBed } from "@angular/core/testing";
import {
  BrowserDynamicTestingModule,
  platformBrowserDynamicTesting
} from "@angular/platform-browser-dynamic/testing";

// Unfortunately there"s no typing for the `__karma__` variable. Just declare it as any.
declare var __karma__: any;
declare var require: any;

// Prevent Karma from running prematurely.
__karma__.loaded = () => undefined;

// First, initialize the Angular testing environment.
getTestBed().initTestEnvironment(
  BrowserDynamicTestingModule,
  platformBrowserDynamicTesting()
);
// Then we find all the tests.
const context = require.context("./", true, /\.spec\.ts$/);
// And load the modules.
context.keys().map(context);
// Finally, start Karma to run the tests.
__karma__.start();

and     Karma.conf.js
module.exports = function (config) {
  config.set({
    basePath: '',
    frameworks: ['jasmine', '@angular-devkit/build-angular'],
    plugins: [
      require('karma-jasmine'),
      require('karma-chrome-launcher'),
      require('karma-jasmine-html-reporter'),
      require('karma-coverage-istanbul-reporter'),
      require('@angular-devkit/build-angular/plugins/karma')
    ],
    client:{
      clearContext: false // leave Jasmine Spec Runner output visible in browser
    },

    coverageIstanbulReporter: {
      reports: ['text-summary'],
      fixWebpackSourcePaths: true
    },

    reporters: config.angularCli && config.angularCli.codeCoverage
              ? ['progress', 'coverage-istanbul']
              : ['progress', 'kjhtml'],
    port: 9876,
    colors: true,
    logLevel: config.LOG_INFO,
    autoWatch: true,
    browsers: ['ChromeHeadless'],
    singleRun: false
  });
};

and package.json
"devDependencies": {
    "@angular-devkit/build-angular": "~0.6.8",
    "@angular/cli": "6.0.8",
    "@angular/compiler-cli": "6.0.5",
    "@types/angular-ui-router": "^1.1.40",
<EMAIL_ADDRESS>"^0.0.28",
    "@types/jasmine": "^2.8.7",
    "@types/node": "^8.0.51",
    "codelyzer": "~2.0.0",
    "cross-env": "^5.1.1",
    "graceful-fs": "^4.1.11",
    "jasmine-core": "~2.5.2",
    "jasmine-reporters": "^2.3.1",
    "jasmine-spec-reporter": "~4.2.1",
    "jshint": "^2.9.1",
    "karma": "~1.7.1",
    "karma-chrome-launcher": "^2.2.0",
    "karma-cli": "~1.0.1",
    "karma-coverage-istanbul-reporter": "0.2.0",
    "karma-jasmine": "~1.1.0",
    "karma-jasmine-html-reporter": "0.2.2",
    "karma-junit-reporter": "^0.4.1",
    "karma-phantomjs-launcher": "^1.0.0",
    "less": "^3.0.4",
    "livereload": "^0.6.3",
    "parallelshell": "^3.0.2",
    "phantomjs-prebuilt": "^2.1.7",
    "pre-commit": "^1.2.2",
    "protractor": "5.3.0",
    "protractor-console": "^2.0.1",
    "protractor-console-plugin": "^0.1.1",
    "rimraf": "^2.6.2",
    "ts-loader": "^3.1.1",
    "ts-node": "~2.0.0",
    "tslint": "~5.8.0",
    "typescript": "2.7.2",
    "webpack": "^4.12.0",
    "webpack-stream": "^4.0.0"
  },

Repro steps

When I first run the build and serve the app, it's run as normal, but if I do any edition then Karma triggered an new test the error will shown as below:
The log given by the failure
<!-- Normally this include a stack trace and some more information. -->
 10% building modules 0/2 modules 2 active …-web/client/app/app.module.ngfactory.jHeadlessChrome 67.0.3396 (Mac OS X 10.13.5) ERROR                                         Uncaught ReferenceError: Zone is not defined
  at http://localhost:9876/_karma_webpack_/vendor.js:120672
HeadlessChrome 67.0.3396 (Mac OS X 10.13.5) ERROR
  Uncaught ReferenceError: Zone is not defined
  at http://localhost:9876/_karma_webpack_/vendor.js:120672

HeadlessChrome 67.0.3396 (Mac OS X 10.13.5) ERROR
  Uncaught ReferenceError: Zone is not defined
  at http://localhost:9876/_karma_webpack_/vendor.js:120672
HeadlessChrome 67.0.3396 (Mac OS X 10.13.5) ERROR
  Uncaught ReferenceError: Zone is not defined
  at http://localhost:9876/_karma_webpack_/vendor.js:120672

Desired functionality

Mention any other details that might be useful

The weird thing is that if I ignore the error continue to edit my code and trigger Karma to run the test,  the test will succeed dramatically.

This seems like a bug but we'll need to look at a reproduction to find and fix the problem. Can you setup a minimal repro please?
You can read here why this is needed. A good way to make a minimal repro is to create a new app via ng new repro-app and adding the minimum possible code to show the problem. Then you can push this repository to github and link it here.

Closing as no reproduction was received. Please update to the most recent Angular CLI version.
If the problem persists after upgrading, please open a new issue, provide a simple repository reproducing the problem, and describe the difference between the expected and current behavior.


Investigate adding ListClients and DeleteClient operations

Summary
There is a use case for Parsec to be able to eliminate and forget all keys/resources associated with a particular client application identity. This can be achieved by introducing new admin-level operations to enumerate and delete clients. This issue is a request to break down the work into individual issues in all required repos.
Requirements

There is a dependency on admin-level operations. See https://github.com/parallaxsecond/parsec/issues/292
A ListClients Parsec opcode will be introduced. This opcode will be an admin-level operation, and must fail with an appropriate permission denied error if any call is attempted from a non-admin client, subject to the design for admin-level operations. This opcode will take no inputs. It will return as its output an unordered set of strings that are application identities according to the endpoint's currently-configured auth/identity mechanism. Each identity returned should be one for which at least one key (or other object/resource) has been stored within the Parsec service,
A DeleteClient Parsec opcode will be introduced. This opcode will be an admin-level operation, and must fail with an appropriate permission denied error if any call is attempted from a non-admin client, subject to the design for admin-level operations. This opcode will take a single string as its input. The string must be an application identity according to the endpoint's currently-configured auth/identity mechanism. The string should be a string that was previously returned by a call to ListClients, since the intention is that callers would call ListClients first to determine the set of clients for which keys exist, and would then call DeleteClient one or more times to delete the resources of some subset of those clients. The Parsec service must be robust against the possibility that the string is either invalid or corresponds to a client identity for which no keys or other resources currently exist. It should return a suitable status code and take no other action for such cases.
The DeleteClient operation should be absolute in terms of all keys or other resources that might be stored within Parsec. When Parsec is expanded to include things such as secure blob storage, then DeleteClient would apply to these as well, not just keys that were provisioned through PSA Crypto operations.
There is no atomicity requirement in Parsec. Race conditions can exist if clients are being deleted while their resources are being used, or if the client creates new resources during the deletion process. It is the responsibility of the integrated system to ensure that DeleteClient is called at times when the system is appropriately quiesced.
The ListClients and DeleteClient operations must be accessible at least through the Rust client library and the parsec-tool. Access via other client libraries is optional, and can be supported later on an as-needed basis.

Definition of Done
There should be an open PR into parsec-book indicating the ListClients and DeleteClient opcodes and their contracts. There should also be GitHub issues for the individual work items needed to implement and plumb these through all of the layers, including e2e tests and parsec-tool integration.

Some questions:

Should the DeleteClient operation be valid for the admin deleting itself as well?
Are the operations supposed to be directed to the Core provider? I remember a discussion around it, but I can't recall whether it should be core provider-only, or if all providers should implement it, for more granular control.
Would we want, in the ListClients operation, to also return a list of providers per client as well, indicating where the client has a "presence"? My thought was that we shouldn't necessarily tie this down to DeleteClient and to what we need for that operation

Some questions:

Should the DeleteClient operation be valid for the admin deleting itself as well?
Are the operations supposed to be directed to the Core provider? I remember a discussion around it, but I can't recall whether it should be core provider-only, or if all providers should implement it, for more granular control.
Would we want, in the ListClients operation, to also return a list of providers per client as well, indicating where the client has a "presence"? My thought was that we shouldn't necessarily tie this down to DeleteClient and to what we need for that operation

My answers to your questions

I would say yes, similarly that it is possible on Unix to delete privileged files if you have the privilege.

I would say that those should be core operations as well. Very similar to ListKeys, which also takes authentication.

Agree that we want to make sure if it's needed to know which client is using which provider. The ListClients operations could return a map of list of application names per provider ID or something similar. But I am not sure if that would not make this operation too "heavy". Maybe it's possible to get that information with another new operation, in the future if it is needed. Maybe another ListClients with a provider ID parameter or put that in this one? I guess that's what you meant with "granular-control" in your question 2.

One more question
If we have at some point in the future the possibility of multiple authenticators being supported in parallel (see #271), we might not be able to select a client in the DeleteClient operation with just an application name as multiple authentication methods can yield the same client name. For example, it might be a tuple (AuthenticationType, ApplicationName) to only select a client in one authentication method. It depends to what we want to do in the future.
If we just use a string corresponding to the application name, we might have problem to scale that to a Parsec service that supports multiple authenticators.
The design indicates:

It will return as its output an unordered set of strings that are application identities according to the endpoint's currently-configured auth/identity mechanism.

"according to the endpoint's currently-configured auth/identity mechanism" works nicely if only one authentication method is currently used at the endpoint. If multiple are used, we can precise the design by saying that ListClients will only return application names "created" with the same authentication type that is specified in the auth type field of the ListClients request. This is similar than what ListKeys is currently doing.

My answers to your questions

I would say yes, similarly that it is possible on Unix to delete privileged files if you have the privilege.

I would say that those should be core operations as well. Very similar to ListKeys, which also takes authentication.

Agree that we want to make sure if it's needed to know which client is using which provider. The ListClients operations could return a map of list of application names per provider ID or something similar. But I am not sure if that would not make this operation too "heavy". Maybe it's possible to get that information with another new operation, in the future if it is needed. Maybe another ListClients with a provider ID parameter or put that in this one? I guess that's what you meant with "granular-control" in your question 2.

One more question
If we have at some point in the future the possibility of multiple authenticators being supported in parallel (see #271), we might not be able to select a client in the DeleteClient operation with just an application name as multiple authentication methods can yield the same client name. For example, it might be a tuple (AuthenticationType, ApplicationName) to only select a client in one authentication method. It depends to what we want to do in the future.
If we just use a string corresponding to the application name, we might have problem to scale that to a Parsec service that supports multiple authenticators.
The design indicates:

It will return as its output an unordered set of strings that are application identities according to the endpoint's currently-configured auth/identity mechanism.

"according to the endpoint's currently-configured auth/identity mechanism" works nicely if only one authentication method is currently used at the endpoint. If multiple are used, we can precise the design by saying that ListClients will only return application names "created" with the same authentication type that is specified in the auth type field of the ListClients request. This is similar than what ListKeys is currently doing.

If multiple are used, we can precise the design by saying that ListClients will only return application names "created" with the same authentication type that is specified in the auth type field of the ListClients request.

Would this rely on the further partitioning that we'll do within the providers?
This sounds like a neat idea, it would allow different admins to manage different authentication mechanisms or endpoints (actually yeah, we have to think about service endpoints too 😬 )

If multiple are used, we can precise the design by saying that ListClients will only return application names "created" with the same authentication type that is specified in the auth type field of the ListClients request.

Would this rely on the further partitioning that we'll do within the providers?
This sounds like a neat idea, it would allow different admins to manage different authentication mechanisms or endpoints (actually yeah, we have to think about service endpoints too 😬 )

Would this rely on the further partitioning that we'll do within the providers?

I think that it would. If we support only one authentication method per endpoint and multiple endpoint then that's not needed. Maybe it does not harm anyway to check that the auth type in the ListClients operation is the same as the current authentication method used by the service for now.

Would this rely on the further partitioning that we'll do within the providers?

I think that it would. If we support only one authentication method per endpoint and multiple endpoint then that's not needed. Maybe it does not harm anyway to check that the auth type in the ListClients operation is the same as the current authentication method used by the service for now.

About atomicity, since our key info managers are accessed in parallel, they must be guarded by locking mechanisms and hence are protected against data races. I believe that ListClients will ultimately lock the KIM for reading and DeleteClient for writing and it would prevent creating or deleting keys while that happens.

About atomicity, since our key info managers are accessed in parallel, they must be guarded by locking mechanisms and hence are protected against data races. I believe that ListClients will ultimately lock the KIM for reading and DeleteClient for writing and it would prevent creating or deleting keys while that happens.

I'm not so sure, unless you design it like that - I was thinking the core provider would just issue a series of DestroyKey operations for DeleteClient, so it could overlap with other operations from other clients.

I'm not so sure, unless you design it like that - I was thinking the core provider would just issue a series of DestroyKey operations for DeleteClient, so it could overlap with other operations from other clients.

Design proposal of operations
They would both be core operations, adressed to provider ID 0.
ListClients
Lists all clients currently having keys in the service. Opcode: 27 (0x001B)
Parameters
No parameters are needed for this operation.
Results

Name
Type
Description

clients
Vector of String
List of clients

Specific response status codes
No specific response status codes returned.
Description
This operation lists all clients that are currently storing keys in the Parsec service. The clients field contain a vector of the application names used by clients.
This operation necessitates admin privilege.
Only the clients using the same authentication method as this request will be listed. It has no impact currently as only one authentication method in the service is supported but might do if the service supports multiple.
Contract
No contract yet.
DeleteClient
Delete all keys a client has in the service. Opcode: 28 (0x001C)
Parameters

Name
Type
Description

client
String
Client to delete

Results
No values are returned by this operation.
Specific response status codes
No specific response status codes returned.
Description
This operation deletes all keys a client owns in all Parsec providers. The client parameter string must be one of the clients returned by the ListClients operation.
This operation necessitates admin privilege.
Only the clients using the same authentication method as this request will be deleted. It has no impact currently as only one authentication method in the service is supported but might do if the service supports multiple.
Contract
No contract yet.
Design proposal of implementation
They would need an implementation in the interface as well, which would be straightforward as other operations.
We can let the filtering per provider to a future operation if that's needed, to keep those one simple.
In the service
Implemented similarly as other operations (before the provider level), but they would require admin privilege.
Provide trait method:
    fn list_clients(
        &self,
        op: list_clients::Operation,
    ) -> Result<list_clients::Result> {

In the future this would also contain as parameter the authentication type to only return clients of that type.
The operation would be implemented in the core provider.
The core Provider structure would contain a vector of all Key Info Manager (that it would share concurrently with the providers), which is passed during service build-up. The avantage of that instead of using the providers directly is for the RWLock that would have to be taken: a key would not be able to be deleted while ListClients is being called and keys won't be able to be read/write while DeleteClient is called.
For ListClients, I believe the get_all method on all provider IDs can be called and then we can return a set of application names.
For DeleteClient, we would do a get_all and then as many remove as needed.
In the Rust client
Admin operations can only be executed by the admins. But clients can not know if they are admin or not 😔 I guess that would be a reason why adding a new response status is needed so that clients can return the appropriate error and the user can know if either their auth token is wrong or if they are not admin?
To list/delete clients on other auth methods, it should be possible for the clients to change its current authentication method as well. I guess they can already use the set_auth method to change it.
The rest of the implementation is straightforward.
Testing
We can test this in the all-providers multitenancy tests. Making sure that the admin can see all clients and that he can delete all keys of the other one 💯
Documentation
We need to add in the book the new operations. As far as I know, no more threat model updates are needed than the ones already done in the admin feature PR.
Question
This relies on the fact that "only clients created with the same auth method as the request will be listed/destroyed". Is this good? Should we already think about the multiple authenticators scenario and make the ListClients operations return clients created with all authentication method or is this too complicated for now?

Design proposal of operations
They would both be core operations, adressed to provider ID 0.
ListClients
Lists all clients currently having keys in the service. Opcode: 27 (0x001B)
Parameters
No parameters are needed for this operation.
Results

Name
Type
Description

clients
Vector of String
List of clients

Specific response status codes
No specific response status codes returned.
Description
This operation lists all clients that are currently storing keys in the Parsec service. The clients field contain a vector of the application names used by clients.
This operation necessitates admin privilege.
Only the clients using the same authentication method as this request will be listed. It has no impact currently as only one authentication method in the service is supported but might do if the service supports multiple.
Contract
No contract yet.
DeleteClient
Delete all keys a client has in the service. Opcode: 28 (0x001C)
Parameters

Name
Type
Description

client
String
Client to delete

Results
No values are returned by this operation.
Specific response status codes
No specific response status codes returned.
Description
This operation deletes all keys a client owns in all Parsec providers. The client parameter string must be one of the clients returned by the ListClients operation.
This operation necessitates admin privilege.
Only the clients using the same authentication method as this request will be deleted. It has no impact currently as only one authentication method in the service is supported but might do if the service supports multiple.
Contract
No contract yet.
Design proposal of implementation
They would need an implementation in the interface as well, which would be straightforward as other operations.
We can let the filtering per provider to a future operation if that's needed, to keep those one simple.
In the service
Implemented similarly as other operations (before the provider level), but they would require admin privilege.
Provide trait method:
    fn list_clients(
        &self,
        op: list_clients::Operation,
    ) -> Result<list_clients::Result> {

In the future this would also contain as parameter the authentication type to only return clients of that type.
The operation would be implemented in the core provider.
The core Provider structure would contain a vector of all Key Info Manager (that it would share concurrently with the providers), which is passed during service build-up. The avantage of that instead of using the providers directly is for the RWLock that would have to be taken: a key would not be able to be deleted while ListClients is being called and keys won't be able to be read/write while DeleteClient is called.
For ListClients, I believe the get_all method on all provider IDs can be called and then we can return a set of application names.
For DeleteClient, we would do a get_all and then as many remove as needed.
In the Rust client
Admin operations can only be executed by the admins. But clients can not know if they are admin or not 😔 I guess that would be a reason why adding a new response status is needed so that clients can return the appropriate error and the user can know if either their auth token is wrong or if they are not admin?
To list/delete clients on other auth methods, it should be possible for the clients to change its current authentication method as well. I guess they can already use the set_auth method to change it.
The rest of the implementation is straightforward.
Testing
We can test this in the all-providers multitenancy tests. Making sure that the admin can see all clients and that he can delete all keys of the other one 💯
Documentation
We need to add in the book the new operations. As far as I know, no more threat model updates are needed than the ones already done in the admin feature PR.
Question
This relies on the fact that "only clients created with the same auth method as the request will be listed/destroyed". Is this good? Should we already think about the multiple authenticators scenario and make the ListClients operations return clients created with all authentication method or is this too complicated for now?

The core Provider structure would contain a vector of all Key Info Manager (that it would share concurrently with the providers), which is passed during service build-up. The avantage of that instead of using the providers directly is for the RWLock that would have to be taken: a key would not be able to be deleted while ListClients is being called and keys won't be able to be read/write while DeleteClient is called.

I don't think you can do that. For TPM it works out because we store the keys themselves in the KIM, but for Mbed Crypto and PKCS11 it means the keys would never be deleted.

The core Provider structure would contain a vector of all Key Info Manager (that it would share concurrently with the providers), which is passed during service build-up. The avantage of that instead of using the providers directly is for the RWLock that would have to be taken: a key would not be able to be deleted while ListClients is being called and keys won't be able to be read/write while DeleteClient is called.

I don't think you can do that. For TPM it works out because we store the keys themselves in the KIM, but for Mbed Crypto and PKCS11 it means the keys would never be deleted.

I don't think you can do that. For TPM it works out because we store the keys themselves in the KIM, but for Mbed Crypto and PKCS11 it means the keys would never be deleted.

Ah yes you are totally right, forgot about that 🤕
In that case I can propose the following:
For ListClients to do something similar than ListKeys: have the list_clients method be implemented by all providers to use the key info manager implementation they are using to return a list of client. The Core provider would call list_clients on all of its Provide implementations (which it already has) and merge them.
As far as I know, this would not prevent ListClients to be called on a specific provider rather than the core one only? But then it seems that we have the same behaviour with ListKeys? Is that a bug or a feature 😋?
For DeleteClient, we can either do something similar by making all providers implement this method or we can use a mix of existing methods: list_keys on the application name given as parameter and then psa_destroy_key on each one of them. The first one is consitent with the other similar operations as it would allow to be called on independent provider, the second one would prevent that. The second option would lock the key info manager for a longer time leaving less option for concurrent calls.
This will break the atomicity of these operations but they will still be safe.

I don't think you can do that. For TPM it works out because we store the keys themselves in the KIM, but for Mbed Crypto and PKCS11 it means the keys would never be deleted.

Ah yes you are totally right, forgot about that 🤕
In that case I can propose the following:
For ListClients to do something similar than ListKeys: have the list_clients method be implemented by all providers to use the key info manager implementation they are using to return a list of client. The Core provider would call list_clients on all of its Provide implementations (which it already has) and merge them.
As far as I know, this would not prevent ListClients to be called on a specific provider rather than the core one only? But then it seems that we have the same behaviour with ListKeys? Is that a bug or a feature 😋?
For DeleteClient, we can either do something similar by making all providers implement this method or we can use a mix of existing methods: list_keys on the application name given as parameter and then psa_destroy_key on each one of them. The first one is consitent with the other similar operations as it would allow to be called on independent provider, the second one would prevent that. The second option would lock the key info manager for a longer time leaving less option for concurrent calls.
This will break the atomicity of these operations but they will still be safe.

Is that a bug or a feature 😋?

I'd rather leave that question to @paulhowardarm 😁
I'm not sure about how to implement DeleteClient - on one hand, it feels safer/better to not have it on every provider (though it might just be paranoia). On the other hand, implementing it in the provider would probably be more efficient and simpler...

Is that a bug or a feature 😋?

I'd rather leave that question to @paulhowardarm 😁
I'm not sure about how to implement DeleteClient - on one hand, it feels safer/better to not have it on every provider (though it might just be paranoia). On the other hand, implementing it in the provider would probably be more efficient and simpler...

Ah check this

Although we need to be sure somewhere that ListKeys can not be called directly on the crypto providers. Probably somewhere higher on the stack.

Here as well:

The check I was talking in the other comment could be here but could also be in the is_capable method where we would check if the request's opcode is a Core or a Crypto operation and based on that check if the provider can do it or not.

Seems like I forgot to add that check somewhere! We should probably add it with a test.

Ah check this

Although we need to be sure somewhere that ListKeys can not be called directly on the crypto providers. Probably somewhere higher on the stack.

Here as well:

The check I was talking in the other comment could be here but could also be in the is_capable method where we would check if the request's opcode is a Core or a Crypto operation and based on that check if the provider can do it or not.

Seems like I forgot to add that check somewhere! We should probably add it with a test.

Issues created:

#311
#310
https://github.com/parallaxsecond/parsec-book/issues/79
https://github.com/parallaxsecond/parsec-client-rust/issues/66
https://github.com/parallaxsecond/parsec-interface-rs/issues/94
https://github.com/parallaxsecond/parsec-tool/issues/22
https://github.com/parallaxsecond/parsec-operations/issues/26

Issues created:

#311
#310
https://github.com/parallaxsecond/parsec-book/issues/79
https://github.com/parallaxsecond/parsec-client-rust/issues/66
https://github.com/parallaxsecond/parsec-interface-rs/issues/94
https://github.com/parallaxsecond/parsec-tool/issues/22
https://github.com/parallaxsecond/parsec-operations/issues/26


Send Keystrokes to Desktop

Adds keyboard hotkey that disables/enables keyboard capture on the xfreerdp client window.
Previously in X11, you were stuck in fullscreen mode and graphics would break on the normal CTRL+ALT+ENTER; This made multitasking with workspaces near impossible.
Added Keystrokes (captures both uppercase and lowercase):
Ctrl + Atl + R: Releases keystrokes until window regains focus.
Ctrl + Atl + U: Recaptures keystrokes (they get sent back to rdp), only used if the rdp window doesn't not refocus.
Example Usage:
Case (Ubuntu 16.04, multiple workspaces, RDP on workspace 1 of 4 [2x2]):
command: xfreerdp /u:user /p:password /d:domain /f /multimon /v:rdphost.somehost.com

First. user sends keystroke Ctrl + Alt + r
Then user send Ctrl + Alt + →
Outcome workspace changes to workspace 2

@freerdp-bot can you test this please ?

I am using multiple workspaces (and multiple monitors) on 16.04 gnome 3.20 & do not experience graphics breaking.
It is true that once focus is on freerdp  all input is directed to the rdp window (which prevents ubuntu handling the super key for instance) & the patch is a worthwhile approach for that without having to use the mouse to change focus.
It is not clear what is meant by "Graphics breaking" above, but I experienced a gnome 3.18 defect  whereby a fullscreen freerdp window would remain visible after I select a different workspace, but putting input focus back into rdp required a switch back to the original workspace [even though the "window" is visible]
Understanding the problem is made harder in fullscreen since the thumbnail for fullscreen rdp windows is missing from the workspace previews  & gnome 3.18 does not support any previews for secondary monitors
I have since upgraded to Gnome 3.20 desktop to get a secondary monitor preview extension installed & resolves the window paint issue on workspace selection. freerdp can now be moved between workspaces as expected & my monitors now display the expected windows only from the selected workspace.
The issue of missing preview thumbnails is still present.
There is also a slight conflict with my multimonitor extension which has added the gnome notification bar to all monitors & is grabbing the clicks in that area even though it is "hidden" under the xfreerdp fullscreen window, I will either get used to it or workaround by reducing screen dimensions slightly if I want to click in the top of maximised windows without thinking about it..

I had the same issue and solved it using the undocumented (?) action.sh-feature.
Create the file /usr/share/freerdp/action.sh with the following contents and make it executable. After that Ctrl+Alt+Left/Right work for workspace switching and Scrolllock for minimizing the current window.
#!/bin/sh

if [ $# -eq 1 ]; then
  echo "Ctrl+Alt+Left"
  echo "Ctrl+Alt+Right"
  echo "Scroll_Lock"
  exit 0
elif [ $# -eq 2 -a "$1" = "key" ]; then
  if [ "$2" = "Ctrl+Alt+Left" ]; then
    xdotool set_desktop 0
  elif [ "$2" = "Ctrl+Alt+Right" ]; then
    xdotool set_desktop 1
  elif [ "$2" = "Scroll_Lock" ]; then
    xdotool getactivewindow windowminimize
  else
    echo "Unknown hotkey: $2" >&2
  fi
else
  echo invalid usage >&2
  exit 1
fi

It is more a workaround than a pretty solution, just some thought-sharing ;)

@caramorsimon -grab-keyboard should help too

Hm... I've skimmed through xf_keyboard.c and it seems we've already ungrabbing keyboard when Right Ctrl  is pressed. Why that doesn't work?..
Other than that, the changes seem to be okay. I've tested this with Unity and GNOME 3 from a couple of Ubuntus and it helps with workspace switching (at least until I switch back to the workspace with XFreeRDP and it grabs the keyboard again because mouse cursor has entered the window).


HIVE-27794: Iceberg: Implement Copy-On-Write for Merge queries

What changes were proposed in this pull request?

COW support for merge operation
Why are the changes needed?

part of COW support
Does this PR introduce any user-facing change?

No
Is the change a dependency upgrade?

No
How was this patch tested?

mvn clean test -Dtest=TestIcebergCliDriver -Dqfile=merge_iceberg_copy_on_write_partitioned.q
mvn clean test -Dtest=TestIcebergCliDriver -Dqfile=merge_iceberg_copy_on_write_unpartitioned.q

@zhangbutao, could you please check if I haven't messed up the input params in TestHiveIceberg tests you created (branch, tag, etc).  tried to remove redundant combinations in some of them, however, I feel we still fire many duplicates

@zhangbutao, could you please check if I haven't messed up the input params in TestHiveIceberg* tests you created (branch, tag, etc). tried to remove redundant combinations in some of them, however, I think we still have many of those remaining

Hi @deniskuzZ , I am ok with your current change. IMO, branch&tag&snapshot related tests are mostly DDL tasks, so it is safe to be tested by one time (HiveCatalog, Parquet, V1), and the test times can be reduced from 9 time to 1 time.
For other tests i also think it should be ok as I often see the Apache Iceberg souce code tested with just one catalog.
We can think more how to find a best way to optimize all tests in the future work.


invocation_directory incorrect on Windows (nushell)

With the following Justfile:
set shell := ['nu', '-c']

JUST_INVOKE_DIR := invocation_directory()

Use just --evaluate to show env vars will got:
JUST_INVOKE_DIR := "/d/Data/iWork/termix-nu"

However the path is invalid:
> ls /d/Data/iWork/termix-nu
error: No matches found
  ┌─ shell:5:4
  │
5 │ ls /d/Data/iWork/termix-nu
  │    ^^^^^^^^^^^^^^^^^^^^^^^ no matches found

Env:
just version: 0.10.2
nushell version detail:

key
value

version
0.37.0

short_commit
f9ae8820

commit_hash
f9ae882012e87e328adbe8da90d3a37ba8aa0448

commit_date
2021-09-14 19:45:30 +00:00

build_os
windows-x86_64

rust_version
rustc 1.55.0 (c8dfcfe04 2021-09-06)

rust_channel
stable-x86_64-pc-windows-msvc (default)

cargo_version
cargo 1.55.0 (32da73ab1 2021-08-23)

pkg_version
0.37.0

build_time
2021-09-14 20:08:37 +00:00

build_rust_channel
release

features
clipboard-cli, ctrlc, dataframe, default, rustyline, term, trash, uuid, which, zip

installed_plugins
binaryview, chart bar, chart line, fetch, from bson, from sqlite, inc, match, post, ps, query json, s3, selector, start, sys, textview, to bson, to sqlite, tree, xpath

This is a consequence of a somewhat weird compatibility hack. I originally thought that the most common way to run just on windows would be with a unix userland provided by cygwin. Cygwin userland tools (cp, rm, etc) expect forward-slash-separated paths, like /d/Data/iWork/termix-nu, so just translates the invocation directory,  which is a windows-style path, into a forward-slash-separated path.
Since you're using nushell, which doesn't understand these unix-style paths, you get an error when you try to use it.
I believe this error is specific to invocation_directory(), since cygpath isn't used in a user-visible way otherwise.
Given the benefit of hindsight, maybe doing this translation isn't a good idea, since it's very confusing, but changing it now might not be a good idea for backwards-compatibility.
One option would be to add an invocation_directory_native() function, which would always return a native path, without doing the translation with cygpath.

One option would be to add an invocation_directory_native() function, which would always return a native path, without doing the translation with cygpath.

Thanks for your reply. How about add a parameter for invocation_directory() function, like invocation_directory(isNative), the default value for isNative is false, if we call it by invocation_directory(true) will get the native path?
BTW:

Given the benefit of hindsight, maybe doing this translation isn't a good idea, since it's very confusing, but changing it now might not be a good idea for backwards-compatibility.

In the long term，remove the translation is still a good choice before the v1.0 version, IMO.

Whoops! I accidentally edited your comment instead of replying. I tried to revert my edit. Here's my reply:

Thanks for your reply. How about add a parameter for invocation_directory() function, like invocation_directory(isNative), the default value for isNative is false, if we call it by invocation_directory(true) will get the native path?

Currently, just doesn't have booleans, and adding an argument would break users of the old zero-argument function.

In the long term，remove the translation is still a good choice before the v1.0 version, IMO.

I agree, although I'd have to think about it. People do use cywin userlands, and so this might break other users.

When I call absolute_path got an error:
$> just --evaluate

error: Call to unknown function `absolute_path`
   |
32 | just_invoke := absolute_path(invocation_directory())
   |                ^^^^^^^^^^^^^

When I call absolute_path got an error, not sure if this is a bug? :

The absolute_path() and error() functions were just added, so they weren't in the version of just you were using. I just published 1.1.0 which includes both functions.

How are variables treated?
I would expect them to be set once upon initialization but seems they're reinited on each just reinvocation from inside the justfile:
set shell := ["bash", "-uc"]
JUST_INVOKE_DIR := invocation_directory()

test_invocation:
    #!/bin/bash
    echo {{ JUST_INVOKE_DIR }}
    just test_invocation2

test_invocation2:
    #!/bin/bash
    echo {{ JUST_INVOKE_DIR }}

This works the 1st time but seems incorrect the 2nd time around:
/tmp » just --justfile ~/git/pass/Justfile test_invocation
/tmp
/home/mihai/git/pass

Anyway, in this specific case, even if the vars are reinited, shouldn't invocation_directory() propagate the current directory on each subsequent just invocation?

@mihaigalos When just reinvokes itself, it's a completely new process with no knowledge of the parent process, so invocation_directory() will be the new invocation directory.

Any update on this issue?  Is there anyway to get the correct path of just invoke directory on Windows?

Hmmm, how about this:
export JUST_INVOKE_DIR := env_var_or_default("JUST_INVOKE_DIR", invocation_directory());

@casey I mean the original issue described here: https://github.com/casey/just/issues/984#issue-1013494964
JUST_INVOKE_DIR := invocation_directory() will be evaluated as "/d/Data/iWork/termix-nu" on Windows, I have just tried yesterday

Ah, sorry, I was reading recent comments, not the OP. No, unfortunately there still isn't a workaround.
What do you think of invocation_directory_native(), which would return the unmodified invocation directory?

That's fine for me. Thanks

Added in #1507!


Lucy 2016

she is becoming a computer size of universe at the end

Hi there. Please:

[ ] Resolve conflicts.

Thank you for your contribution!
@axet

Conflicts don't seem to be resolved. Please resolve them and reopen the issue.


The asnumpy() function costs most of the time during infer, how to use numpy to compute directly ranther than use tvm NDarray()?

After I complete tune module, I build the tvm module,set_input() and run, then I use GraphModule.get_out() funtion to get TVM compute result,  the result is a class named "tvm.runtime.ndarray.NDArray".
However, I need 'numpy.ndarray' to do the following operations,such as get data by index,numpy.expand_dims(),and so on. So I use the asnumpy() function to convert the data type, but the asnumpy() funtion costs a lot of time even surpass the TVM module run time! This make the whole inference time much big than "no TVM tuned DeepLearning model"
The following is part of my inference code, which indicate how the asnumpy enlarge the whole inference time!
`
    # set input_data
    self.tuned_module.set_input("Input", data)
    # execute
    self.tuned_module.run()#12ms
    # get outputs
    result = self.tuned_module.get_output(0)
    print(type(result)) # <class 'tvm.runtime.ndarray.NDArray'>

    t1 = time.time()
    result = result.asnumpy()  #
    t2 = time.time()
    print("asnumpy_time:", t2-t1) #255ms
    print(type(result)) # <class 'numpy.ndarray'>

    result = result[:, 0, :]
    result = numpy.expand_dims(result, 1)

`
If I don't use asnumpy,the error is:
`
result = result[:, 0, :]

TypeError: 'NDArray' object is not subscriptable
`
Consequently, my questions are:

Why the TVM use "tvm.runtime.ndarray.NDArray" to compute data, rather than numpy library? The numpy library have many useful funtion to process data which can't find in "tvm.runtime.ndarray.NDArray".

How to use numpy to compute directly ranther than  tvm NDarray()?  This will save much time during the whole DeepLearning inference

How to get the TVM run (or compute) result in the memery address, to prevent  convert & copy result to NDarray again(the input data already convertd to NDarray by set_input())?

Looking forward to your reply! @tqchen
Thank you very much!

You can try dlpack in tvm

Thanks @wxyhv , can you open a new thread on https://discuss.tvm.apache.org/ about the question. The time of asnumpy could also due to the fact that previous computations are asynchronous, so the cost comes from the actual compute instead of the copy


Publish Linux release packages to packagecloud in VSTS builds

One of the final tasks to get us fully moved over to VSTS for automated draft release creation is to publish Linux packages for the release over on our packagecloud repository.
Tasks to complete:

[x] Move over package publishing code from Atom Release Publisher
[x] Make sure that packages get published to the staging feed for Stable/Beta and to the main feed for Nightly

This work was completed as part of https://github.com/atom/atom/pull/17862.


ENH: create a hello-world toy catalog

To use in tutorials, quick examples, etc

command: datalad catalog hello-world:

create catalog at temp location
add metadata from some template source*
set-super
serve said catalog

toy metadata to be added to package data

The datalad-catalog walkthrough in the datalad handbook basically solved this.


Accept punctuation following a score pattern when matching

Proposal to accept common punctuation that may follow a score.
Currently, scores must precede the end of the message, or a whitespace character. Some observed messages are unable to contribute a score due to their use of punctuation. For example:
"10/10"            # trailing quotation marks
some text, 10/10.  # trailing period
10/10, some text   # trailing comma
text (10/10)       # trailing parenthesis

We conservatively accept common "trailing" punctuation characters for the time being. Candidate character set: [!"'),.:;?]

Not convinced that "coupled punctuation" such as "...", (...), and '...' are that common. The use of quotation marks is typically referring to others submitting such a score, while likely not intending for that score to be submitted.
The character set that was decided on was: [,.!?]. The two colon characters appear to also be uncommon, and will be dropped (for right now at least).


Does recast4j keeping follow Recast&Detour?

hi, does recast4j keeping follow master branch of Recast&Detour? if not, which commit of Recast&Detour  is used as base by recast4j?

Yes, it follows master.


Issue #3 Component Cards

I created an animated card with a front and a back.

can u add a image of the card @alexchrysovergis

Great work keep contributing to the repository!!! @alexchrysovergis

Don't forget to star the repository @alexchrysovergis


--silent, --bash flags ignored for terminus drush command

The output from "terminus drush" is not bash-ready and not silent when these flags are specified.
e.g. the command:

terminus --bash --site=example --env=test drush help

Pre-pends the following to its output, which breaks things:

Running drush help  on example-test

I've got the similar issue. When I run
terminus drush rr --no-cache-clear --site=example --env=test

cli invokes "drush rr --cache-clear" on pantheon environment. So I have to use the following workaround:
terminus drush rr --no-no-cache-clear --site=example --env=test

The command above executes "drush rr --no-cache-clear" test environment. I think that cli "eats" a part of attributes passed to terminus.


HADOOP-18921. upgrade to avro 1.11.3

https://issues.apache.org/jira/browse/HADOOP-18921

@steveloughran is there a release planned for hadoop-thirdparty? There are a few PRs open that might warrant inclusion - https://github.com/apache/hadoop-thirdparty/pulls


Contribute X plugin

Overview
Contribute X plugin, the initial version from https://github.com/mszostok/botkube-plugins/tree/main/cmd/exec
Acceptance Criteria

Example usage:

Testkube
Flux

Run each installed binary with RBAC (save and export KUBECONFIG)

Follow-ups

[ ] add opt to define a dedicated RBAC per installed app
[ ] add opt to refresh and register external templates:

[ ] @Botkube x template refresh
[ ] @Botkube x template add {url}
[ ] @Botkube x template list

Tasks:

https://github.com/kubeshop/botkube/pull/1112
https://github.com/kubeshop/botkube-docs/pull/233
https://github.com/kubeshop/botkube/pull/1117
https://github.com/kubeshop/botkube/pull/1127
rename x to exec and add x alias in Botkube repo


New German Translation Progress

Maintainer List

@ChrisB9
@ph1p
@miku86

For New Translators
To translate a page:

Check that no one else has claimed your page in the checklist and comments below.
Comment below with the name of the page you would like to translate. Please take only one page at a time.
Clone this repo, translate your page, and submit a pull request!

Before contributing, read the glossary and style guide (once they exist) to understand how to translate various technical and React-specific terms.
Please be prompt with your translations! If you find that you can't commit anymore, let the maintainers know so they can assign the page to someone else.
For Maintainers
When someone volunteers, edit this issue with the username of the volunteer, and with the PR. Ex:

[ ] Quick Start (@tesseralis) #12345

When PRs are merged, make sure to mark that page as completed!
Main Content
To do before releasing as an "official" translation. Please translate these pages first.
Note that each section has an index page, which needs to be translated too.
Learn React

[ ] Quick Start

[ ] Tutorial: Tic Tac Toe (@jackblackCH)
[ ] Thinking in React (@ameetmadan )

[ ] Installation

[ ] Start a New React Project
[ ] Add React to an Existing Project
[ ] Editor Setup
[ ] React Developer Tools

[ ] Describing the UI

[ ] Your First Component
[ ] Importing and Exporting Components
[ ] Writing Markup with JSX
[ ] JavaScript in JSX with Curly Braces
[ ] Passing Props to a Component
[ ] Conditional Rendering
[ ] Rendering Lists
[ ] Keeping Components Pure

[ ] Adding Interactivity

[ ] Responding to Events
[ ] State: A Component's Memory
[ ] Render and Commit
[ ] State as a Snapshot
[ ] Queueing a Series of State Updates
[ ] Updating Objects in State
[ ] Updating Arrays in State

[ ] Managing State

[ ] Reacting to Input with State
[ ] Choosing the State Structure
[ ] Sharing State Between Components
[ ] Preserving and Resetting State
[ ] Extracting State Logic into a Reducer
[ ] Passing Data Deeply with Context
[ ] Scaling Up with Reducer and Context

[ ] Escape Hatches

[ ] Referencing Values with Refs
[ ] Manipulating the DOM with Refs
[ ] Synchronizing with Effects
[ ] You Might Not Need an Effect
[ ] Lifecycle of Reactive Effects
[ ] Separating Events from Effects
[ ] Removing Effect Dependencies
[ ] Reusing Logic with Custom Hooks

API Reference

[ ] react: Hooks

[ ] useCallback
[ ] useContext
[ ] useDebugValue
[ ] useDeferredValue
[ ] useEffect
[ ] useId
[ ] useImperativeHandle
[ ] useInsertionEffect
[ ] useLayoutEffect
[ ] useMemo
[ ] useReducer
[ ] useRef
[ ] useState
[ ] useSyncExternalStore
[ ] useTransition

[ ] react: Components

[ ] <Fragment> (<>)
[ ] <Profiler>
[ ] <StrictMode>
[ ] <Suspense>

[ ] react: APIs

[ ] createContext
[ ] forwardRef
[ ] lazy
[ ] memo
[ ] startTransition

[ ] react-dom: Components

[ ] Common (e.g. <div>)
[ ] <input>
[ ] <option>
[ ] <progress>
[ ] <select>
[ ] <textarea>

[ ] react-dom: APIs

[ ] createPortal
[ ] flushSync
[ ] findDOMNode
[ ] hydrate
[ ] render
[ ] unmountComponentAtNode

[ ] react-dom/client: Client APIs

[ ] createRoot
[ ] hydrateRoot

[ ] react-dom/server: Server APIs

[ ] renderToNodeStream
[ ] renderToPipeableStream
[ ] renderToReadableStream
[ ] renderToStaticMarkup
[ ] renderToStaticNodeStream
[ ] renderToString

Navigation and UI
We suggest to leave most of the UI translation until the end. We plan to do some invasive changes to the website folder layout and components, so postponing this until your translation is almost complete would make it easier to merge the changes from our side later. It might make sense to translate the homepage above the fold early, but leave the rest for later. As individual pages get translated, you can change the page titles in the corresponding sidebar files. Finally, when you're translating the navigation, make sure to test both desktop and mobile layouts.

[ ] Homepage (currently in HomeContent.js)
[ ] Sidebars (currently in src/sidebar*.json)
[ ] Top-level navigation (currently in TopNav.tsx)

When You're Ready...
After everything above is translated, add your language to deployedLanguages in Seo.tsx of the original reactjs/react.dev repository.
Secondary Content
These API pages should ideally be translated too, but they're less urgent and can be done after the others:

[ ] Legacy React APIs

[ ] Children
[ ] cloneElement
[ ] Component
[ ] createElement
[ ] createFactory
[ ] createRef
[ ] isValidElement
[ ] PureComponent

Optional Content
These aren't the main translation targets, but if you'd like to do them, feel free to expand the list to include their subpages:

[ ] Community
[ ] Blog
[ ] Warnings

I would love to help! 👍🏼

Thank you @ameetmadan, I added you

I start to contribute with: Tutorial: Tic Tac Toe

Oh, does it even make sense? I would rather do something new. I checked the list above and did not see @TheFireCircle's name next to TicTacToe. Can you update the list with the pages that are in progress?

@jackblackCH please check with @TheFireCircle in #290 whether you and him can merge your efforts

I added you to that list to spearhead this. That tutorial is just a lot of changes and I didnt really want his past effort go entirely to waste without including him.

I can start with "Start a New React Project".

Quick question because it was a big problem with the German Gatsby translations at the time: do we already know how to translate "you"?
Example:

If you want to build a new app or a new website fully with React, we recommend picking one of the React-powered frameworks popular in the community.

Would it be:

Passive: Um eine neue App order Website mit React zu bauen, empfehlen wir eines der populären React-basierten Frameworks der Community zu verwenden.

Active: Wenn du eine App oder Website mit React bauen willst, empfehlen wir eines der populären React-basierten Frameworks der Community zu verwenden.

Also: do you think we might need a list of words which we do not want to translate (e.g. Community)?

@gu-stav I'll add you
The latter part, there already is a glossary: https://github.com/reactjs/de.react.dev/issues/10 If you feel like words are missing there, just comment and we can add it to the list
Regarding active/passive du. I personally prefer the passive one, as it does sound more documentation-like. But the active is more in-line with the english version. How about you try it out both ways for a couple sentences, and then we decide the best approach when seeing the results
cc: @ph1p

@ChrisB9 Thanks - I missed the Glossary 🙏🏼
Active/ Passive: I would prefer the passive too - active "du" always sounds a bit awkward and too close I think. From my experience, this is something that should be decided early on because otherwise you'd end up with a mix. If everyone agrees I'd suggest to start with passive and see if that feels to distant.

Sure I can add them to the list, but they are already pinned issues right next to this one. I think the pinned issues is a much easier place than a wall of text

@ChrisB9 @ph1p @miku86
Can you confirm whether the maintainer list is up-to-date, and whether you'd be able to steer and maintain this translation? I'd like to get https://github.com/reactjs/translations.react.dev/blob/main/langs/de.json reflect the current list. Thank you!

I am still maintaining (: I do not know about the others

@ph1p Alright, I'll leave the current list as is, but if you don't hear from other maintainers for some period of time, please send a PR to trim down the list to who's active.

@gaearon I am still there, too, but not as active as @ph1p

I added you to that list to spearhead this. That tutorial is just a lot of changes and I didnt really want his past effort go entirely to waste without including him.

 Sadly, the effort which went into the last translation is obsolete now. But I can understand that @jackblackCH wants to start over.

Hi, I would like to take the following:

Describing the UI (the index page of that section).
Describing the UI -> Your First Component.

@krsilas added you
@marvhock added you, but just one at a time, trying to prevent stale translation processes

Hi I would like to translate the Quick Start page!

@ChrisB9 @ph1p @miku86
Can you confirm whether the maintainer list is up-to-date, and whether you'd be able to steer and maintain this translation? I'd like to get https://github.com/reactjs/translations.react.dev/blob/main/langs/de.json reflect the current list. Thank you!

I'm not that much into React anymore, but I'm open to help to discuss pull requests, language-wise.

Sounds good, I'll add you

"Add React to an Existing Project" is already done. I thought i am assigned to the whole "Installation" section. Sorry for the confusion
I am almost done, think one  "Deep Dive" section to go and then read through again.
just commited my latest state

I would like to translate Editor Setup page

I would like to translate React Developer Tools

I would also want to translate Your First Component

Is there a reason Using TypeScript isn't in the list?

Is there a reason Using TypeScript isn't in the list?

Probably because the todo list might be out of date

Would like to translate the landing page if no one has already done that.

@timowenz go ahead, currently no one is working on anything so feel free 👍


Module 4 Unit 6 - Removal of Contoso-RG-TM2 is missing

Module: 4
Lab/Demo: 6
Task: 5
Step: 2
Description of issue: Removal of Contoso-RG-TM2 is missing, only Contoso-RG-TM1 is listed whereas Contoso-RG-TM2 is also created during the lab.
Repro steps:

Contoso-RG-TM2 is created in Task 1 Step 7 and not deleted in Task 5 Step 2

MOC Labs review has solved this issue with pull request #117


MQTT as input to topics

Is it possible to use MQTT as the input to topics rather than sensors?
Currently the example is
topic:
      song_title: "{{ states('sensor.musicbee_nowplaying_songtitle') }}"

But I would like to do something like this but have had little success so far.
topic:
      song_title: "{{ states('mqtt.shairport-sync-living-room/title') }}"

I know shairport-sync-living-room/title works because I have a test sensor it works for.
Thank you

In the beginning the plugin used to use the example you provided (where you put the topic right in the config for the plugin). I forgot the reason I changed away from this, but I think it's because I wanted to remove a dependency within the plugin and it made more sense for Home Assistant to handle the subscribing to the topic.
It's more work to create sensors for each topic, but it should give less problems overall.
Does this example work for you? (This is how I have mine setup) ex:
    - platform: "mqtt"
      state_topic: "musicbee/song/artist"
      name: "Musicbee_Song_Artist"

I have a custom sensor setup like above, and then I can just use that sensor name in the plugin config.

Yeah I'm using sensors now but at the time it would have been nice to not need to add these :)


ignoring root readme

It doesn't conform to the X client library for Python It's a root about an entire repo as a whole, not a specific package.

Can one of the admins verify this patch?


Congratulations popup after buying an NFT is not availiable anymore?

I bought an NFT, and the only popup I got was this one:
NFT bought on ahk - tested only on production

Where is our nice, pretty Congratulations popup created by exez we had till now?

👋


Logic App Standard Deployment Issue to Government Cloud - Cannot read properties of undefined (reading 'kind')

Describe the Bug with repro steps
Deploying a Standard Logic App using VS Code does not work as expected when using the Azure Government Cloud.
Other items, like Azure Resources, work as expected using the Azure Government Cloud to view and create Azure Artifacts.
Changing the account to a non-government cloud results in a successful deployment.
This was tested on two new VS Code environments running Windows 10 and 11 with the same results.

Sign into Azure Government Cloud inside VS Code
Create a Standard Edition Logic App
Navigate to Azure - Workspaces on the left toolbar
Select the Logic App icon - Deploy to logic app…
One of two errors is seen.

Cannot read properties of undefined (reading 'kind')
The access token has been obtained for wrong audience or resource 'https://management.core.usgovcloudapi.net'. It should exactly match with one of the allowed audiences 'https://management.core.windows.net/','https://management.core.windows.net','https://management.azure.com/','https://management.azure.com'.

What type of Logic App Is this happening in?
Standard (VSCode)
Which operating system are you using?
Windows
Are you using new designer or old designer
New Designer
Did you refer to the TSG before filing this issue? https://aka.ms/lauxtsg
No
Workflow JSON
No response
Screenshots or Videos
No response
Browser
Latest version of VS Code
Additional context
No response

Both of the errors referenced above happen when I try to deploy a Logic App Standard created locally in VS Code to US Government Azure.  When I get past the token issue, usually by signing in and out and opening and closing the VS Code, I get the kind error.
I can create workflows without issues in the portal and see them under Azure Resources.
To recap, as of now, I am unable to move the locally created Logic Apps into the US government cloud using VS Code.  I do not have this issue deploying the same Logic Apps into the commercial cloud.
Thanks.

I tested this again tonight with the latest Function and C# extensions released today, and I'm still getting the same issue.  I have tried deployment to 2 different Government Cloud instances using 2 separate accounts on different VMs, both with the same error.
Does the Logic App Standard Extension support deployment into the Azure US Government Cloud?
Error Message:
The access token has been obtained for wrong audience or resource 'https://management.core.usgovcloudapi.net/'. It should exactly match with one of the allowed audiences 'https://management.core.windows.net/','https://management.core.windows.net','https://management.azure.com/','https://management.azure.com'.

Hi @StephenWThomas yes we support deployment to non-public clouds.
For this issue that you are experiencing this shouldn't affect the functionality of the extension, except for the Azure panel on the left toolbar. If you experience that your remote Logic Apps aren't loading properly, you should be able to see them correctly by clicking on the refresh icon on the top of the panel

Looking here: (https://learn.microsoft.com/en-us/azure/logic-apps/create-single-tenant-workflows-visual-studio-code#deploy-to-azure)
It crashes with one of the two errors at step 2.
Note if I just switch accounts to a non-govenment cloud, it works just fine.  Only when using US Government Cloud it doesn't work
All other areas of VS code seem to work fine, I can view items in the Government Cloud.  I just can not deploy.
Below are the detailed steps I just ran.
Step 1

Step 2

Step 3

Step 4 - Error

Hi @StephenWThomas thanks for the detailed screenshots on this, now I am able to repro it. I will come up with a fix and let you know

Hi @StephenWThomas we will be releasing a new version of the vscode extension today. Its the 4.107.4. Could you please give it a try?

I was not able to get it to work with the new extension.
I have tried on two different environments connecting to two different US Govenment Cloud accounts.  Like before, I can view everything fine in Azure Resources.  When I go to deploy, I get the same error in both places as shown below.  It is a different error from before, though.
The error is:
EnvironmentCredential is unavailable. No underlying credential could be used. To troubleshoot, visit https://aka.ms/azsdk/js/identity/environmentcredential/troubleshoot.

Yes, I have those set correctly in both of my separate environments, which both give the same error.
I even put together a post and video in case anyone else needs to update these: https://www.stephenwthomas.com/azure-integration-thoughts/configuring-us-government-cloud-in-visual-studio-code-for-developers/
Are there any other settings I'm missing?
VS Code was just updated a few days so, as well as C# and Funcations runtime.  Those have any impacts?

Alright, I just wanted to make sure this was properly set up. The error is coming from the  Azure SDK for JavaScript, I don't really think this might be affecting it. But I am checking it.

Something else I should add, I just got this EvnionmentCredentail issue on another, non Govenment, system trying to deploy.
It did work a few weeks ago with this same code.

@StephenWThomas ok ok, I am still looking around on what would be happening over here

I finally got it working in the government cloud!!!!
I created a new Workspace without custom code.  I did a deployment using VS Code and it worked!  Note this did not work last week due to the other issue you fixed Friday.
Then, I opened the other workspace with the .Net 8 custom code, and the deployment worked perfectly!
I'll try again tomorrow without doing the first deployment and see if it still works.
It seems something just needed to be configured or set somewhere.
Maybe this is related to using .Net 8 custom code?  I have had a lot of issues with it the past few weeks.

@StephenWThomas Amazing!!! Yep, the fix that it was made on Friday was related to the credentials in Gov cloud. Despite the .NET 8 configuration, I am not aware of any specific settings, please if you find something let me know.
Also, if you face any other issue let me know


Replace lib/getProxyFromURI.js with proxy-from-env

I was looking for a package that implements support for the (de facto) standard proxy environment variables, but didn't find any except for getProxyFromURI.js in this library. My two main issues with the implementation is that it uses suffix matching (e.g. NO_PROXY=example.com also matches notexample.com) and that it uses HTTP_PROXY even for https URLs). The latter is problematic if I want to proxy all HTTP requests, but not HTTPS requests, because there is no way to get NO_PROXY to stop matching https requests.
I've fixed all of the above issues and published the result as https://www.npmjs.com/package/proxy-from-env, and decided to submit a PR here so that eventually all Node.js applications/libraries that want to support setting the proxy via the environment variables do so in a consistent and standard way.
Compared to the existing implementation in request, there are two backwards-incompatible changes (see the commit message for other differences and more details):

HTTP_PROXY is no longer used for https requests (use HTTPS_PROXY
or ALL_PROXY).
The items in NO_PROXY are no longer used in suffix matching, but used as an exact match (unless the item starts with a dot or asterisk, then suffix matching will be used).

The proxy-from-env library has an extensive set of tests. With a small modification, the tests can also be used to check the existing implementation:
git clone https://github.com/Rob--W/proxy-from-env.git
cd proxy-from-env

# Get current implementation from request
wget https://github.com/request/request/blob/c2dab797d362ad158e0399140aa59829fa50d9b3/lib/getProxyFromURI.js?raw=true -Oindex.js

# Change module signature to match the library.
echo "module.exports={getProxyForUrl: function(s) { return getProxyFromURI(require('url').parse(s)) || ''; }};" >> index.js

# Install dependencies and run tests
npm install
npm test

Here is the test output: http://pastebin.com/raw/Dk9f79Vq (anything without a checkmark is a test failure).

That's great, but I'm worried about breaking changes as we don't follow semver for the current major version 2.x. At this point a better approach would be to pass an option to request and specify which getProxyFromURI implementation you want to use.

What do you mean by "I'm worried about breaking changes as we don't follow semver for the current major version 2.x. "?
The README of request states:

When HTTP_PROXY / http_proxy are set, they will be used to proxy non-SSL requests that do not have an explicit proxy configuration option present.

The "non-SSL" qualifier rules out that the variable can be used for HTTPs requests (even though the implementation falls back to http_proxy when https_proxy is missing). And I've checked many implementations of the proxy, and none of them use http_proxy for proxing HTTPS requests (see the README of the proxy-from-env library for sources that I checked), so users cannot realistically expect that http_proxy is also used for https URLs.
Assuming that users don't rely on undocumented features, merging this PR should be safe.

Ok, I'm getting your point now, let's hope for the best!
cc @jvmccarthy @samcday @seanstrom

I rebased the PR to resolve the merge conflict in package.json. Did you already have a chance to review it?

This PR has been closed as "abandoned" as a part of an automated cleanup. If this is a mistake and you are still interested in merging this PR, please do the following:

[ ] Rebase your changes onto the master branch (even if there are no merge conflicts, we want to make sure your change is under the most recent tests).
[ ] Push your updated branch to Github to update this PR.
[ ] Make sure this PR's Travis tests are still passing. (Run npm test locally if tests are still failing).
[ ] Comment here to let us know that you've updated the PR and are still interested in getting it merged. Somebody from the project will respond and work with you to review.

Thank you for your understanding. If you have any questions, please check out https://github.com/request/request/issues/2556 and feel free to comment / ask anything there.

@FredKSchott I rebased my branch on master and verified locally that the tests still pass. The PR is not automatically updated because you've closed it though.


Remove reference to react-router-native

We're currently taking ownership of react-router-native and have shipped several beta releases that do not wrap the NavigationExperimental API. In order to avoid confusion, I'd appreciate it if we could avoid mentioning react-router-native here. Thanks :)

Thanks for clearing up the confusion! Once your library is rolled out, we can also mention it on this page if you'd like- we should keep the core RN docs impartial :-D


MudAutocomplete ability to customize results view list items

Feature request type
Enhance component
Component name
MudAutocomplete
Is your feature request related to a problem?
No response
Describe the solution you'd like
I would like to be able to add more information to the results items layout of autocomplete.
For example, to display per each result item in the list, one avatar (profile image), a title and a small description.
Have you seen this feature anywhere else?
No response
Describe alternatives you've considered
No possible alternative at the moment. Can only display strings through ToStringFunc.
Pull Request

[ ] I would like to do a Pull Request

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Isn't this now available in v5.2?
https://mudblazor.com/components/autocomplete#presentation

Thats right. Thanks


Sample uses old Bot Framework version

I wanted to build a Teams app and started with this sample. However, as I tried to understand the code for the Bot and modify it for my scenario, I got confused. It turns out this sample uses v3 of the Bot Framework, but the Bot Framework documentation on their site is for v4. This made it hard to know what the code from this sample does, and how to modify it to achieve what I was trying to do. I gave up.

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

ID: 33cdb816-f2b6-31a4-0e4c-d730435d0a6b
Version Independent ID: c111eaef-ac66-e245-b2bc-623c1801a7db
Content: Get started with App Studio and Node.js - Teams
Content Source: msteams-platform/get-started/get-started-nodejs-app-studio.md
Product: msteams
GitHub Login: @o365devx
Microsoft Alias: o365devx

Hi - yes, it is a bit confusing right now. We're planning on full support for v4 soon. In the interim, you can use the Teams bot documentation (https://docs.microsoft.com/en-us/microsoftteams/platform/concepts/bots/bots-overview), and the Bot Framework documentation can also be changed to v3 using the option on the top-left of their documentation repository:

If you have specific questions that you can't find the answer to please feel free to reach out to us using one of the methods outlined here and we'll be happy to help.


Added in initial lines for Cronjob

JIRA link (if applicable)
https://tools.hmcts.net/jira/browse/EM-3581
Change description
Added in logic for Cronjob
Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[X] No

Not required


Build documentation lacking

The readme needs to include what this project is / does and how to build it.

Addressed in REAME updates


feat(perf): exit early when filtering props

What: This adds an if statement to exit early in the splitProps function

Why: If the rootEl is a component, then we can forward all props to it without worrying about attaching props to DOM nodes. So we can skip the reduce function entirely.

How: Running the tests in watch mode and hitting random keys until they passed.

Helps with #43

Unfortunately, we currently have no way to measure whether this even makes an impact, but this is something that's been on my mind. I'm pretty sure it's a bit of a bottleneck so it's probably a good idea :)

Codecov Report

Merging #44 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##           master    #44   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files           4      4
  Lines          89     92    +3
  Branches       21     22    +1
=====================================
+ Hits           89     92    +3

Impacted Files
Coverage Δ

src/index.js
100% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


Apply PPSR_CORE metadata standard to projects

It would be nice to get iNaturalist project metadata in this standard format eventually. Filing it here so I don't have to worry about forgetting that this exists.
Fields defined here:
http://citizenscience.org/2015/10/09/ppsr_core-metadata-standard/

is this a software ticket carrie? or a best practices discussion more suitable for the google group?

I suppose it could be up for discussion about how interested other people are in this, but my intention was primarily to bookmark it as something for incorporation into a larger projects overhaul (if funding materializes for that). I didn't intend for it to be high priority but more of a back-burner feature improvement.

might be better to put in in a google doc and float it by the google group. We're trying (and I'm guilty of not doing this) to restrict github issues to well fleshed out software tickets that are ready to be implemented, or at least have technical details discussed. This seems like its still in the functional spec phase


Load Testing

In the long run I want to use persurl to persist a lot of PURLs.
Some numbers
PURL creation
A rough estimation which I have repeatedly used:

1000 users creating purls
1000 purls created / per day * per user (= 40 / hour ~ 0.6 / minute)
purls have a minimum lifespan of 10 years

With these numbers the application would have to persist 3.650.000.000 purls after 10 years.
That is ~ 11.5 PURLs / second or ~ 695 per minute
Side note on data types: A database using a 32-bit integer will be able to address ~4 billion PURLs. With 64 bit that would go up to 18.446.744.073.709.551.615
PURL resolution
In my use case I expect that PURLs will be resolved infrequently, potentially never. Persul should be like an index for large (see above) amounts of URLs. This is similar to web archives which save a lot of data which may or may not be used some time.
Due to that expectation I don't yet have any numbers on the load generated for resolution. To enable load testing, I'll give some arbitrary numbers which may surely be updated once I understand the user case better:

Only 10% of all PURLs are ever resovled. The remaining 90% are created but never resolved.
PURLs which are resolved, are resolved maximum once per day.
Users expect a PURL to resolve within 1 second on average. More may be okay if a PURL is in "cold" storage and has to be warmed up once. The second resolution of the same PURL should be faster_

Let's see how fare these numbers will bring the project.
Load Testing
I'd like to have a test suite which runs the application and then load tests it:

It sould simultaneously create and resolve PURLs according to the given parameters.
Parameters should be configurable (maybe via ENV) to allow for experiments.
A dedicated CI pipeline should should run the load tests to ensure that major changes do not affect performance.

Links
This issue is potentially relevant for:

#7
#26

Subtasks

[X] Add basic load testing #34
[x] Establish / document a baseline performance which should guide future decisions regarding to performance. Similar to SLAs etc.

#39 is where I will continue to define what a production workload seems to be.
This is closed as the first load testing implementation is done.


Fullerite should fail gracefully with unknown collector name

When the conf file has a collector that is unknown by fullerite, we
should not panic, instead we should log an error and gracefully fail.

+1

Can we add a test for the same?

@gnufied we can yes, but this means adding tests for running collectors in general since we don't have these, this might be out of the scope of this. what do you think?

I strongly advised against - adding tests work - out for scope this ticket. It is pretty good idea to cover all bug fixes with some sort of test so as - we don't run into regressions, even if it means spending longer time than necessary for fixing a bug.

:shipit:

+1


[BUG] Delete vmi and vm error at the same time

Describe the bug
When there is a vmi that has not been deleted, an error will be reported if you choose to delete the vm at the same time

To Reproduce
Steps to reproduce the behavior:

creata  vm
delete vm （When it appears that vmi has not been deleted）
create another vm
delete all vm

Expected behavior
Hope that no error is reported, vm can be deleted, but vmi may not be deleted
Log

Environment:

Harvester ISO version:
Installation Mode: ISO/app-mode
Underlying Infrastructure (e.g. Baremetal with Dell PowerEdge R630):

Additional context
Add any other context about the problem here.

Validated on master-head


RangeError in /clan/bei-si-te-q8qyc8yc

Error in ClashLeaders
RangeError in /clan/bei-si-te-q8qyc8yc
Maximum call stack size exceeded
View on Bugsnag
Stacktrace
webpack:///node_modules/vue/dist/vue.esm.js:982 - defineReactive

View full stacktrace
Created automatically via Bugsnag

An error linked to this issue has been marked as fixed in Bugsnag
RangeError in /clan/bei-si-te-q8qyc8yc

An error linked to this issue has been reopened in Bugsnag
RangeError in /clan/castello-del-re-20p9lru9

An error linked to this issue has been marked as fixed in Bugsnag
RangeError in /clan/castello-del-re-20p9lru9


PyTorch-Lightning Incompatibility Issue

Creating the env from the yaml file makes it so that the versions of pytorch and pytorch lightning are incompatible, giving the error: undefined symbol: iJIT_NotifyEvent. I was able to manually edit to switch to pytorch 1.7.1, but that caused issues of its own. Sorry if a solution to this is in the works.
Traceback (most recent call last):
  File "/home/ubuntu/Protein_Redesign/generate.py", line 11, in <module>
    import pytorch_lightning as pl
  File "/home/ubuntu/miniconda3/envs/ProteinReDiff/lib/python3.9/site-packages/pytorch_lightning/__init__.py", line 34, in <module>
    from pytorch_lightning.callbacks import Callback  # noqa: E402
  File "/home/ubuntu/miniconda3/envs/ProteinReDiff/lib/python3.9/site-packages/pytorch_lightning/callbacks/__init__.py", line 14, in <module>
    from pytorch_lightning.callbacks.callback import Callback
  File "/home/ubuntu/miniconda3/envs/ProteinReDiff/lib/python3.9/site-packages/pytorch_lightning/callbacks/callback.py", line 21, in <module>
    from torch import Tensor
  File "/home/ubuntu/miniconda3/envs/ProteinReDiff/lib/python3.9/site-packages/torch/__init__.py", line 202, in <module>
    from torch._C import *  # noqa: F403
ImportError: /home/ubuntu/miniconda3/envs/ProteinReDiff/lib/python3.9/site-packages/torch/lib/libtorch_cpu.so: undefined symbol: iJIT_NotifyEvent

Hey Deniz,
Can you please tell me the versions of the pip dependencies you are using?

Was able to solve this specific error with pytorch=1.12.1, but still broken after the fact

Can you tell me the python version you are using

python used is 3.9, lightning is 1.7.7.
I installed torch via conda. Please check the environment file for versions.


fix jdk detection by detecting javac instead of tools.jar

Turns out Java 9 dropped tools.jar, which is what we were using to detect the JDK. Gradle works fine on Java 9+ but because tools.jar was removed, our MSBuild thinks the JDK isn't installed.
Changed to use the Java Compiler binary itself to detect this.

nit: Maybe change Have to Has


children type NodeComponentType not exposed for consumption

The children prop is typed as NodeComponentProps on TreeProps, however the type is not exported. Only TreeWalker and TreeWalkerValue types get exported from ./Tree as you can see here
In order to properly type my custom tree node component this type should be exposed to the consumer of the library

for anyone wondering or in need of a work around, I believe this is the equivalent type
import { NodePublicState } from 'react-vtree/dist/es/Tree';
import { ListChildComponentProps } from 'react-window';

type ITreeWalkerData = {
  // This is your data model
}

type TreeNodeComponentProps = Omit<ListChildComponentProps<ITreeWalkerData>, 'index'> & NodePublicState<ITreeWalkerData>


Buttons colors

Hi,
Very nice package ! Thanks.
Any ways to set a different color for the different transitions buttons ? (Approve, Reject, etc).

implemented 😎


the work of fix syntax warnings was completed. fix 2 issues - [merged]

In GitLab by @liyanq528 on Jul 22, 2020, 05:08
Merges synax-fix -> dev

In GitLab by @wknet123 on Jul 22, 2020, 05:38
mentioned in commit 03350eaf9dd50218b730c7d461a92f26681f455e

In GitLab by @wknet123 on Jul 22, 2020, 05:38
merged


[RESOLVED] Interface eth0(): High error rate (>2 for 5m)

Problem started at 10:03:29 on 2023.04.26
Problem name: Interface eth0(): High error rate (>2 for 5m)
Host: S100-Primario
Severity: Warning
Operational data: errors in: 2, errors out: 0
Original problem ID: 20001
Event details in Zabbix: http://<IP_ADDRESS>/tr_events.php?triggerid=23483&eventid=20001

Problem has been resolved in 42m 0s at 10:45:29 on 2023.04.26
Problem name: Interface eth0(): High error rate (>2 for 5m)
Host: S100-Primario
Severity: Warning
Original problem ID: 20001


Training time

Hello,
Great work and GitHub repository!
I'm curious about the duration needed to complete training, was it a matter of days or weeks (for the Nvidia Tesla P40 GPUs you used)?
Best!

It takes about 2-3 day to train the HRNet18 IT-M model on COCO+LVIS using two Tesla P40.

Thanks for the response.