cache clearing is not working as described

OS: Windows 10, v1703
App: 4.3.0
In settings, there is a button labeled 'REFRESH LIBRARY' which is described as "Clear local cache and refresh all song and playlist information."
Upon clicking I would expect that cache directory would be cleared. It is not the case.

Can you confirm it does something in Chrome? That's a GPM setting, so more than likely it clears out some sort of local storage cache information. Nothing we can really do about this either way honestly.

This is more than likely what it clears out, but it will be added again on the next refresh anyway, so rather pointless other than if there is stale data there.

I tried it under Chrome, but my chrome folder is around 1.3gb so hard to observe.
Also I didnt use chrome for google play recently, so it didnt have a chance to cache much data.
What about different approach: would you consider then adding such AppData\Roaming\Google Play Music Desktop Player\Cache" clearing to the 'Desktop Setting's ?

Not working for me either.
In chrome it works fine - you can tell because when you click the "Refresh Library" button, Google Play Music reloads.
In the desktop app, it doesn't - unless I click the button like 10-20 times in a row (it eventually 'registers' and refreshes - reloading the entire interface, but it sometimes doesn't work at all and sometimes requires a lot of clicks).


chore: add new example for json-schema-draft4-from-object (#852)

Description

Added new example for json-schema-draft4-from-object as mentioned in #852

Related issue(s)
Fixes #852

@jonaslagoni i have modified snapshots. can you check once?

sure @jonaslagoni

I am gonna fix the CI problem later, lets merge it 👍

@all-contributors please add @nitintejuja for example

@jonaslagoni and @Samridhi-98 thanks for guiding me. this project is very interesting to me.


'j abc' gives 'command not found'

The docs say:
j abc            =>     cd /hell/of/a/awkward/path/to/get/to/abcdef

However, the default configuration uses z rather than j. This is a little confusing.

Yeah, this tripped me up, too. Either the README should remove that line, or the j alias should be added to the default setup for fasd --init (to accommodate autojump converts).
You can add this to your .bashrc or your ~/.bash_aliases to get it back:
alias j='fasd_cd -d'

+1

This is something that I was looking for to get rid of autojump, which stopped working on my systems running recent versions of bash.


Could not find expected browser (chrome) locally. Run npm install to download the correct Chromium revision (938248).[BUG]

Could not find expected browser (chrome) locally. Run npm install to download the correct Chromium revision (938248). When using serverless-esbuild plugin with puppeteer.

I have the same error.
{
  "errorType": "Error",
  "errorMessage": "Error in handler:  Could not find expected browser (chrome) locally. Run `npm install` to download the correct Chromium revision (961656).",
  "trace": [
    "Error: Error in handler:  Could not find expected browser (chrome) locally. Run `npm install` to download the correct Chromium revision (961656).",
    "    at Runtime.module.exports.hello [as handler] (/var/task/handler.js:42:11)"
  ]
}

Same error for me too:
Error: Could not find expected browser (chrome) locally. Run npm install to download the correct Chromium revision (901912)
"chrome-aws-lambda": "^10.1.0"
"puppeteer-core": "^10.1.0"

node node_modules/puppeteer/install.js

node node_modules/puppeteer/install.js

i think this answer is right

node node_modules/puppeteer/install.js

Worked for me as well.

node node_modules/puppeteer/install.js

but how to use this?

node node_modules/puppeteer/install.js

but how to use this?

You execute the js file. Just copy paste the command into your console.

Give this a try. This is one of the latest maintained repositories: https://www.npmjs.com/package/@sparticuz/chromium.
Working well with node 18 and AWS Lambda.

Give this a try. This is one of the latest maintained repositories: https://www.npmjs.com/package/@sparticuz/chromium. Working well with node 18 and AWS Lambda.

 ~/WebstormProjects/map-ts-gen/ [main+*] serverless invoke local --function mapgen -p data.json

Running "serverless" from node_modules
Compiling with Typescript...
Using local tsconfig.json - tsconfig.json
Typescript compiled.
{
    "errorMessage": "spawn Unknown system error -8",
    "errorType": "Error",
    "stackTrace": [
        "Error: spawn Unknown system error -8",
        "    at ChildProcess.spawn (node:internal/child_process:413:11)",
        "    at Object.spawn (node:child_process:757:9)",
        "    at childProcess.spawn (/Users/leonardoviada/WebstormProjects/map-ts-gen/node_modules/cli-progress-footer/lib/private/cli-progress-footer/disable-props.js:73:50)",
        "    at new Process (/Users/leonardoviada/WebstormProjects/map-ts-gen/node_modules/@puppeteer/browsers/lib/cjs/launch.js:143:87)",
        "    at launch (/Users/leonardoviada/WebstormProjects/map-ts-gen/node_modules/@puppeteer/browsers/lib/cjs/launch.js:80:12)",
        "    at ChromeLauncher.launch (/Users/leonardoviada/WebstormProjects/map-ts-gen/node_modules/puppeteer-core/lib/cjs/puppeteer/node/ProductLauncher.js:90:54)",
        "    at async mapgen (/Users/leonardoviada/WebstormProjects/map-ts-gen/.build/handler.js:47:21)"
    ]
}

I'm getting this error after switching to @sparticuz/chromium

So I run this command on the aws lambda instance? When I run this locally this seems to be a version tailored to my OS, which is different to the one that runs on aws lambda. Note that I do not use this locally but on a lambda instance (as the name of the package suggests). Thanks for any help

Give this a try. This is one of the latest maintained repositories: https://www.npmjs.com/package/@sparticuz/chromium. Working well with node 18 and AWS Lambda.

 ~/WebstormProjects/map-ts-gen/ [main+*] serverless invoke local --function mapgen -p data.json

Running "serverless" from node_modules
Compiling with Typescript...
Using local tsconfig.json - tsconfig.json
Typescript compiled.
{
    "errorMessage": "spawn Unknown system error -8",
    "errorType": "Error",
    "stackTrace": [
        "Error: spawn Unknown system error -8",
        "    at ChildProcess.spawn (node:internal/child_process:413:11)",
        "    at Object.spawn (node:child_process:757:9)",
        "    at childProcess.spawn (/Users/leonardoviada/WebstormProjects/map-ts-gen/node_modules/cli-progress-footer/lib/private/cli-progress-footer/disable-props.js:73:50)",
        "    at new Process (/Users/leonardoviada/WebstormProjects/map-ts-gen/node_modules/@puppeteer/browsers/lib/cjs/launch.js:143:87)",
        "    at launch (/Users/leonardoviada/WebstormProjects/map-ts-gen/node_modules/@puppeteer/browsers/lib/cjs/launch.js:80:12)",
        "    at ChromeLauncher.launch (/Users/leonardoviada/WebstormProjects/map-ts-gen/node_modules/puppeteer-core/lib/cjs/puppeteer/node/ProductLauncher.js:90:54)",
        "    at async mapgen (/Users/leonardoviada/WebstormProjects/map-ts-gen/.build/handler.js:47:21)"
    ]
}

This is the instantiation code
const browser = await puppeteer.launch({
        args: chromium.args,
        defaultViewport: chromium.defaultViewport,
        executablePath: await chromium.executablePath(),
        headless: chromium.headless,
    });

I'm getting this error after switching to @sparticuz/chromium

Did you ever solve this? I'm been trying to solve this for 3+ hours and haven't had any success

node node_modules/puppeteer/install.js

but how to use this?

You execute the js file. Just copy paste the command into your console.

That works locally (telling me the browser is already installed):
➜ git:(main) node node_modules/puppeteer/install.js

Chromium is already in [...]/node_modules/puppeteer/.local-chromium/mac-901912; skipping download.

Still, the error remains on AWS lambda. I can't run that command there, or can I?

@kurtsys found any solution ?

node node_modules/puppeteer/install.js

but how to use this?

You execute the js file. Just copy paste the command into your console.

That works locally (telling me the browser is already installed):
➜ git:(main) node node_modules/puppeteer/install.js

Chromium is already in [...]/node_modules/puppeteer/.local-chromium/mac-901912; skipping download.

Still, the error remains on AWS lambda. I can't run that command there, or can I?

did you solve this?

node node_modules/puppeteer/install.js

but how to use this?

You execute the js file. Just copy paste the command into your console.

That works locally (telling me the browser is already installed):
➜ git:(main) node node_modules/puppeteer/install.js

Chromium is already in [...]/node_modules/puppeteer/.local-chromium/mac-901912; skipping download.

Still, the error remains on AWS lambda. I can't run that command there, or can I?

did you solve this?

node node_modules/puppeteer/install.js
Chromium is already in [...]/node_modules/puppeteer-core/.local-chromium/mac-1045629; skipping download.
I am getting same error. This happened after I installed chai in my project.

It works for me. Thank you.

node node_modules/puppeteer/install.js

It also may be useful using: > > node node_modules/puppeteer/install.mjs

I have been wokring with Puppeteer, now I change to 'html_pdf_node' still I'm getting ""Could not find expected browser (chrome) locally. Run npm install to download the correct Chromium revision (901912)."" this response from my server, when I try to install, "node node_modules/puppeteer/install.mjs" and "node node_modules/puppeteer/install.js" I get error in console, "node:internal/modules/cjs/loader:1148
throw err;
^
Error: Cannot find module 'D:\hapvider-portal\node_modules\puppeteer\install.js'
at Module._resolveFilename (node:internal/modules/cjs/loader:1145:15)
at Module._load (node:internal/modules/cjs/loader:986:27)
at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:174:12)
at node:internal/main/run_main_module:28:49 {
code: 'MODULE_NOT_FOUND',
requireStack: []
}" my node version is "16.20.2".


wit: why are there both regular comments and doc comments

This was basically me taking a leaf out of Rust's book with // comments and /// doc-comments. In retrospect though WIT isn't a programming language so almost all comments are going to be documentation-related, so it might make sense to remove this paradigm and simply consider all comments preceding an item documentation comments. From a tooling perspective though that also feels a bit odd because then there's no way to have a comment that doesn't show up in documentation, so I could sort of go either way on this.
Changing this though wouldn't be too hard, it'd be to remove any mention of doc comments and parsing all comments as doc comments. For rending we'd probably strip all leading / characters so /// wouldn't render as a bunch of /-prefixed strings.

I agree that since wit isn't a programming language, all comments are documentation :) I think we should change the spec to just // comments and let our implementation strip the third / out for now, and maybe warn that the old syntax will go away at some point?

I think it's extremely valuable to have both doc comments and normal ones, even in an IDL: same as in Real Programs, it's useful to document decisions about the structure of the interface, or note aspects of the layout/ordering of things, etc, without those showing up in (interface-)user-facing documentation.

We could invert the usual relationship and make e.g. //# line / /*# block */ comments "ignored comments".

What would we gain by that? I would hope that everyone is using editors that just prefix the next line with the right token when pressing enter in a comment block?

It would just make doc-comments the syntactic default so that authors don't accidentally use non-doc comments where doc comments are intended.

I'd be hesitant to draw too much of a conclusion from the original state of wasi-http's //-commented source in the sense what WIT is still quite "early days" and while confusion warrants consideration it doesn't necessarily require changing. Mostly in that I consider it a significant data point, but not the sole determining factor.
For example in my experience it's relatively rare to read docs (about WIT syntax in this case) and instead code is copied and/or modified from elsewhere. By the point we have folks doing this in the future I'd expect that there'd be a good number of WASI WITs to model from such that the precise choice of syntax won't really matter all that much as everyone will copy something else and editors, as Till mentions, will take care of the rest.
I personally lean towards camp "useful to have two forms", but not strongly so, myself.

FWIW I'm fine with the status quo too; just giving another option in the context of this issue.

I would be in favor for doc comments. As it has been done in other IDLs (e.g. Smithy).

Relatedly: https://github.com/WebAssembly/component-model/issues/256

I too am fine with the status quo, but don't care too much about the actual style.  I think the ability to add both doc comments (critical for those using generated code from the interface) and normal comments to add context for those working on defining the interface is most important to me

Given the discussion at yesterday's component model meeting and this issue I'm going to close this as the general sentiment is to keep the split between doc/not comments for now. There's still bits to discuss like https://github.com/WebAssembly/component-model/issues/256 so I'll close this largely in favor of that.


Add some more missing pieces

some constants for mman
WIFCONTINUED() for NetBSD & OpenBSD

@bors: r+

:pushpin: Commit 70975a2 has been approved by alexcrichton

:hourglass: Testing commit 70975a231a0f2e064b210d52285a90f56d7adadc with merge 68463056e5a787dc0ad6bacbfa4cb671c785a3d7...

:sunny: Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 68463056e5a787dc0ad6bacbfa4cb671c785a3d7 to master...


Compile error 'CS8078' when a single class has many export properties

When a class has many export properties, generate the expression new JSClassBuilder (...).AddProperty(...). AddProperty(...)  ... ...  It will be very large, causing compilation error  CS8078

I guess if we don't generate a single line chain expression, but instead split it into multiple statements, we should be able to avoid errors (I'm not sure)


https://coreos.com/docs/launching-containers/launching/getting-started-with-systemd/ hello.service's pull

Upon https://coreos.com/docs/launching-containers/launching/getting-started-with-systemd/ you have a hello.service that has something like ExecStartPre=/usr/bin/docker pull abiosoft/caddy:php in my example. However when this fails everything seems to fail.
 Jan 07 07:57:38 as.dl.webconverger.com docker[727]: Error while pulling image: Get https://index.docker.io/v1/repositories/abiosoft/caddy/images: dial tcp: lookup index.docker.io: Temporary failure in name resolution

Full log: http://s.natalian.org/2016-01-07/caddy-journal.txt
So my workaround has been to comment out that line or fix it to allow it to fail?
ExecStartPre=-/usr/bin/docker pull busybox

I am testing upon CoreOS 899.1.0 (alpha).

example provided on the https://coreos.com/docs/launching-containers/launching/getting-started-with-systemd/ page has an unobvious exception (I mean systemct enable unit) - cloud-providers. we can use "systemctl enable unit" only when we are absolutely sure what we are doing. for the common usage we have to use Cloud-Config: https://coreos.com/os/docs/latest/cloud-config.html#units. because cloud-config takes care of network configuration for cloud providers. and when you use systemd's autostart feature ("systemct enable") - that could case an issue like your one. when you use cloud-config to run your units - cloud-config will run them after the network configuration and you'll avoid such problems.
I've added a note in this doc: https://github.com/coreos/docs/pull/723

There is nothing inherently wrong with enabling a service. In fact, that will be the preferred approach in a post-cloudinit world. The underlying issue is 1) the service doesn't properly depend on network.target and 2) the service doesn't retry if there is a network failure (maybe the network isn't moving packets yet or maybe someone tripped in the datacenter). Now, coming back to cloud-init: I suggest people avoid using enable and ensuring runtime is set in an effort to make every boot similar. Otherwise, your first boot is going to be very different from subsequent boots (because services are now enabled). This mistake in design is one of the big reasons we are building Ignition.

Closing due to inactivity.


Bug in Node.js <= 14. No sourceMap for CSS.

Hey,
I'm using extractCss which is working so far, but I couldn't figure out how to enable the source map creation with this.
I have added sourceMap: true to css- postcss- and sass-loader, but it's not creating one.
How do I enable source map with pug plugin?

Hallo @Sir-Will,
the pug-plugin extract css and sourceMap from result  of the css-loader.
The example of webpack.config.js from the test case:
const path = require('path');
const PugPlugin = require('../../../');

// if is FALSE then will be generated the sourceMap
const isProduction = process.env.NODE_ENV === 'production';

module.exports = {
  mode: isProduction ? 'production' : 'development', // <-- only in mode  'development' is generated sourceMap
  devtool: isProduction ? false : 'source-map',  // <-- if devtool is not false then is generated sourceMap

  output: {
    path: path.join(__dirname, 'public/'),
    publicPath: '/',
  },

  entry: {
    styles: './src/assets/main.scss',
    index: './src/index.pug',
  },

  plugins: [
    new PugPlugin({
      modules: [
        PugPlugin.extractCss({
          filename: isProduction ? '[name].[contenthash:8].css' : '[name].css',
        }),
      ],
    }),
  ],

  module: {
    rules: [
      {
        test: /\.(pug)$/,
        loader: PugPlugin.loader,
      },
      {
        test: /\.(css|sass|scss)$/,
        use: ['css-loader', 'sass-loader'],
      },
    ],
  },
};

If the isProduction is false then the sourceMap is  generated as embedded data in self css-file, like following:
h1 {
  color: darkred;
}
/*# sourceURL=webpack://./src/assets/main.scss */
/*# sourceMappingURL=data:application/json;charset=utf-8;base64,eyJ2ZXJzaW9uIjozLCJzb3VyY2VzIjpbIndlYnBhY2s6Ly8uL3NyYy9hc3NldHMvbWFpbi5zY3NzIl0sIm5hbWVzIjpbXSwibWFwcGluZ3MiOiJBQUNBO0VBQ0UsY0FGTTtBQUVSIiwic291cmNlc0NvbnRlbnQiOlsiJGNvbG9yOiBkYXJrcmVkO1xuaDEge1xuICBjb2xvcjogJGNvbG9yO1xufSJdLCJzb3VyY2VSb290IjoiIn0= */

It's legal, supported by all browsers. Additional *.css.map files are no longer generated. It's very practical. Instead of two files, only one is loaded in the browser. The mapping to source of scss works fine in all browser. The mapping is only relevant for development. In Production will be generate pure css w/o sourceMap.

Ah, I liked to have the source map enabled for production, as the file only loads with dev tools active, as far as I know.
Unfortunately, I don't see the inline sourceMap at the end of the .css file, like in your example.
This is my config:
let webpackConfig = {
    entry: {
        app: './scss/app.scss',
    },
    mode: 'development',
    devtool: 'source-map',
    output: {
        publicPath: paths.dest.css
    },
    module: {
        rules: [
            {
                test: /\.scss$/,
                exclude: /node_modules/,
                use: [          // Extract and save the final CSS.
                    // Load the CSS, set url = false to prevent following urls to fonts and images.
                    { loader: "css-loader", options: { url: false, importLoaders: 1,  sourceMap: true } },
                    // Add browser prefixes and minify CSS.
                    { loader: 'postcss-loader', options: { postcssOptions: { plugins: [autoprefixer(), cssnano()] }, sourceMap: true } },
                    // Load the SCSS/SASS
                    { loader: 'sass-loader', options: { sourceMap: true } },
                ]
            }
        ],
    },
    plugins: [
        // Extract css to .css file
        new PugPlugin({
            modules: [
                PugPlugin.extractCss({
                    filename: '[name].[contenthash:8].bundle.min.css',
                    sourceMap: true
                }),
            ],
        }),
    ]
};

Note: the PugPlugin.extractCss() has not the option sourceMap, because the css-loader generate it.
P.S.: Maybe later I can implement the feature to save the sourceMap in a separate file.

Hm, I tried your example locally under Windows and on an Ubuntu 20.04.1 LTS server.
On Windows it does have the source map at the end of the file but not on Ubuntu.
So I checked the NodeJS version and the server had v14.18.3 while locally I have v16.13.2 installed.
After updating the server to v16.13.2 it was creating the source map there too.
Weird that there was no error being thrown.
Note: With the mini-css-extract-plugin it was creating the source map with NodeJS v14
Grüße zurück, aus der Augsburg/München Umgebung.

Oh, and the sourceMap: true options for the loaders don't seem to be needed.

Thank you for the investigation! It is very important bug repport.
I will to fix it for Node.js 12, 14.

Hallo @Sir-Will,
in new version 1.3.0 is fixed the issue for node <=14.
Now the source map is saved in separate file.
Do you can please try new version and if OK close the ticket?
Thank you!

I no longer have NodeJS 14 installed to test it.
Does it respect the webpack devtool option for inline-source-map and source-map?

The new version does not depend on the node version.
All tests passed for node 12.x, 14x, 16.x, see GitHab workflow.
Webpack option devtool is relevant for css-loader, the pug-plugin extract all what generates the css-loader.
Yes, the options source-map, inline-source-map, etc. works. I have tested both source-map and inline-source-map, it will be generate same .css.map file.

the problem is solved

Hm, I just tested the source-map and when using devtool: inline-source-map it creates the .map file, shouldn't it inline the map if it's set to inline-source-map?
I thought pug-plugin is going to either create the .map file or inline the map like it was in version 1.2.4 depending on the devtool setting. Like webpack does for the javascript files.

Hallo @Sir-Will,
thank you for feedback.
Inline source map is fixed In the version 1.4.3. Now the option devtool: inline-source-map works.

I updated to 1.4.3 and it's still not inlining it for me with devtool: inline-source-map

@Sir-Will
can you please see the test case devtool-inline-source-map.
webpack.config.js
module.exports = {
  devtool: 'inline-source-map',
  ...
}

expected css with inline (embedded source map)
body{color:red}
/*# sourceURL=webpack://./src/assets/main.scss */
/*# sourceMappingURL=data:application/json;charset=utf-8;base64,eyJ2ZXJzaW9uIjoz... */

What is your usage case?
Try please test local:
clone https://github.com/webdiscus/pug-plugin.git
cd pug-plugin
npm i
npm run test

Oh, I just realized that I changed the devtool setting for my JavaScript task and not the CSS task, sorry, my bad. It's working.


MemoryError due to large matrices allocation in test suite on Windows conda-forge CI

During the latest conda-forge release (1.5.1) some tests failed randomly but only under Windows. The "random part" seems to be due to memory errors. The relevant PR is here: https://github.com/conda-forge/tofu-feedstock/pull/22.
These errors all seem to be in tofu\tests\tests06_mesh\test_01_checks.py (see log).
A sample error is:

numpy.core._exceptions._ArrayMemoryError: Unable to allocate 199. MiB for an array with shape (26118378,) and data type float64

A possible solution would be to scale down the size of the problem that gets tested.
The full log is attached. log_pr_tofu_azure_build.txt

Thanks !


2.9.0 Pre-Release

Hi,
is it possible to have the MSI of version 2.9.0? Maybe it could be issued a Pre-Release in Github?
Thanks

Hi, Myrtille 2.9.0 normally goes out of beta this month

Ok, I can wait

2.9.0 is released


rule(Write below etc): allow snapd to write its unit files

What type of PR is this?
/kind feature
/kind rule-update
Any specific area of the project related to this PR?
/area rules
What this PR does / why we need it:
In an AWS environment, snap can be used to install the SSM agent, which will write unit files under etc. This is the expected behaviour from snap.
See the AWS docs for more information.
Which issue(s) this PR fixes:
None
Special notes for your reviewer:
None
Does this PR introduce a user-facing change?:
rule(Write below etc): allow snapd to write its unit files

Thanks for your pull request. Before we can look at it, you'll need to add a 'DCO signoff' to your commits.
:memo: Please follow instructions in the contributing guide to update your commits with the DCO
Full details of the Developer Certificate of Origin can be found at developercertificate.org.
The list of commits missing DCO signoff:

9b7484b rule(Write below etc): allow snapd to write its unit files

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign mstemm
You can assign the PR to them by writing /assign @mstemm in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

rules/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign kaizhe
You can assign the PR to them by writing /assign @kaizhe in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

rules/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: Kaizhe
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

rules/OWNERS [Kaizhe]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

LGTM label has been added.  Git tree hash: 3739d7d3dd93c0729646ead774d28beefb94be70

/lgtm

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: Kaizhe
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

rules/OWNERS [Kaizhe]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: Kaizhe, leodido
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

rules/OWNERS [Kaizhe,leodido]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/milestone 0.24.0


⚠ Cioos National CKAN Sitemap has degraded performance

In 215540f, Cioos National CKAN Sitemap (https://catalogue.cioos.ca/sitemap/sitemap-1.xml) experienced degraded performance:

HTTP code: 200
Response time: 9720 ms

Resolved: Cioos National CKAN Sitemap performance has improved in e34cea6 after 4 minutes.


Hotfix: address unzip issue

Ticket
PLAT-XXXX
Related tickets:
Related PRs:
Type of PR

[x] Bugfix
[ ] New feature
[ ] Minor changes

Changes introduced
The previous unzip library was using unmaintained fstream  underneath causing large files like yarn.lock to be corrupted.
Instead of forcing users to upgrade their node version, opted to just replace the library for now.
Test and review

node index.js demo --source develop
check the demo app generated
check if the yarn.lock file has the correct header start

If this is a hotfix we should target main directly?

If this is a hotfix we should target main directly?

Well, not really a hot fix. It's more like a follow-up fix from develop work. Since it isn't released yet, should be ok


Chore/upgrade dependencies

Try one of community packages mentioned at https://github.com/amaroteam/react-credit-cards/issues/115


VerifySignedMessage should let you override the typ

Currently VerifySignedMessage checks that signed JWS has the typ set to "osm" in the JWS protected header. This presents a limitation in circumstances where you want sign something with a different typ.
We should check VerifySignedMessage to support overriding the typ check
From
func (p *PKToken) VerifySignedMessage(osm []byte) ([]byte, error)

to
func (p *PKToken) VerifySignedMessage(osm []byte, options ...Options) ([]byte, error) {

The motivating example is OpenPubkey support in SSH3 as SSH3 uses JWTs and we need to sign and verify these JWTs with OpenPubkey, but SSH3 sets the typ to "JWT".

Assigned to @sarkarbikram90

working on it


Clarify role of csrf in Resource Server

I decided to go with CSRF off by default (still), but also add SessionCreationPolicy.STATELESS so that there are no sessions at all on OAuth2 resources by default (i.e. not much change from 2.0.5). See also #360.

That's our settings in all our resource servers. No session and CSRF disabled.

I want to enable csrf in resource server
what to do. Changing
security.enable-csrf: true
in resource server application.properties did not help

@paskos can you help me to enable CSRF in resource server?


How to set the file path, and dataset path?

Sorry, I got some very basic questions here. It's about the configration of this project. I read the readme, but still got these quetions.
In the config file, the MOT path is   "MOTS_segtrack_data_dir":"/globalwork/krause/data/MOTS_challenge/train/".
The downloaded dataset is MOT17. Should I just put the train and test folder into MOTS_challenge?
And where should I put the trackrcnn_init folder into?  If I use the MOT dataset, where should I put the following data into?
Images (hosted on original MOTChallenge webpage)
Annotations in png format
Annotations in txt format
TrackR-CNN detections

Here is what I do to run the code to test:
①In configs/sconv3d_sep2 file, change the value of key task, train_no_val with forward_tracking.
Change the value of key dataset, KITTI_segtrack with MOTS_segtrack_feed(Cause I use MOT data)
②In  configs/sconv3d_sep2 add the key:value,  "video_tags_to_load" : ["MOT17-01-DPM"]
③In configs/conv3d_seq2, change the value of key MOTS_segtrack_data_dir to "./data/MOTS_challenge/test/"(Because I put the data in the test)
④Put these three model files conv3d_sep2-00000005.data-00000-of-00001， conv3d_sep2-00000005.index，
conv3d_sep2-00000005.meta in to models/conv3d_sep2
⑤ Put the test data.The data path is /TrackR-CNN-master/data/MOTS_challenge/test/MOT17-01-DPM
⑥ In MOTS_segtrack_feed.py file, in function def get_filenames_for_video_idx(self, idx), change the  path of return value.
"return sorted(glob.glob(self.data_dir + self._video_tags[idx] + "/img1/" + "/*.jpg")) "
⑦ in the command line, run python main.py configs/conv3d_sep2

Excuse, me! I am troubled by the train mode.how to train mot17 data using this model? What is the file tree? Thank you!!!

.../MOTS_challenge/train/
images/
instances/
instances_txt/
where you only need one of instances and instances_txt
Images for example:
.../MOTS_challenge/train/images/0005/*.jpg
instances for example
.../MOTS_challenge/train/instances/0005/*.png
instances_txt:
.../MOTS_challenge/train/instances_txt/0005.txt

Excuse, me! I am troubled by the train mode.how to train mot17 data using this model?
You cannot train TrackR-CNN on MOT17, because it lacks segmentation mask annotations. However, you can train on MOTS Challenge, see the project page

Please reopen in case of more questions.


fix comment

Motivation:
Explain the context, and why you're making that change.
To make others understand what is the problem you're trying to solve.
Modification:
Describe the idea and modifications you've done.
Result:
Fixes #.
If there is no issue then describe the changes introduced by this PR.

@kswapd Thank you for your PR, pls sign the CLA: http://www.clahub.com/agreements/alipay/sofa-rpc


Failed to sort imports: Error: Cannot find module 'import-sort-parser-babylon'

The plugin silently fails when triggered by file save and displays the following notification when triggered with Ctrl + Alt + o

Hi @mayacifelli
Thanks for reporting this bug! I just published a new version and the bug should be gone. Let me know if you still have problems.


Beyblade Game Enhanced : Added many features, Nav Bar, a note on How to Play and many more.

PR Description 📜
Please include summary related to the issue you have fixed and describe your PR in brief over here by specifying the issue number on which you were working below :

I added Nav Bar in which I added logo of Beyblade Burst and changed background too.
I added a button on "How to Play?" the game as it was confusing earlier.
I added "Play Button" to start the game.
I added pictures of beyblades and Bladers.
I created a 3D model of Beyblade Stadium.
I added animations of running beyblades and spinning too.

Fixes #4080

Mark the task you have completed ✅

[✅ ] I follow CONTRIBUTING GUIDELINE & CODE OF CONDUCT of this project.
[✅ ] I have performed a self-review of my own code or work.
[✅ ] I have commented my code, particularly in hard-to-understand areas.
[✅ ] My changes generates no new warnings.
[✅ ] I have followed proper naming convention showed in CONTRIBUTING GUIDELINE
[✅ ] I have added screenshot for website preview in assets/images
[✅ ] I have added entries for my game in main README.md
[✅ ] I have added README.md in my folder
[✅ ] I have added working video of the game in README.md (optional)
[✅ ] I have specified the respective issue number for which I have requested the new game.

Add your screenshots(Optional) 📸

Thank you soo much for contributing to our repository 💗

Thank you @KomalMaurya ,for creating the PR and contributing to our GameZone 💗
Review team will review the PR and will reach out to you soon! 😇
Make sure that you have marked all the tasks that you are done with ✅.
Thank you for your patience! 😀

Thank you  @KomalMaurya , for your valuable time and contribution in our GameZone 💗.
It’s our GameZone, so Let’s build this GameZone altogether !!🤝
Hoping to see you soon with another PR again 😇
Wishing you all the best for your journey into Open Source🚀


RISC-V assembly syntax vs 694-1985 - IEEE Standard for Microprocessor Assembly Language

It would be useful to consider the old attempt to standardize the assembler.
Many different assembler syntaxes from different corporations show that the standard was never been used in practice :-)
From the 694-1985 - IEEE Standard for Microprocessor Assembly Language DOI: 10.1145/800088.802820, ISBN: 978-0-89791-024-8, Google-Books-ID: dh5IxAEACAAJ:

4.1.1 Instruction names. The naming of instructions shell be in accordance with the following rule:
Instruction names shell begin with an action verb.

4.1.2 Instruction mnemonics. The selection of mnemonics fo instructions not contained in this standard shell be in accordance with the following rules (exceptions are noted herein):
a) The first character of the mnemonic shall be the first letter of the action verb.
b) Addressing modes shall not be embedded in the mnemonic.
c) Operand designations shell not be embedded in the mnemonic.
d) Conditions shell be embedded in the mnemonic.
e) Operand type may be indicated, where appropriate, by the last character of the mnemonic, as shown below (the default operand type is word):

From the point of view of above standard (incomplete list, for illustration only):

add  vd,vs1,vs2 instead vadd vd,vs1,vs2 (vd/vs1/vs2 are vector registers)
mask is a condition, not a dummy operand - include it to mnemonic

add.m  vd,vs1,vs2 instead vadd vd,vs1,vs2,v0.t

vl[bhwe]u? unit-stride/strided/indexed are not the different instructions but addressing modes only

lb.m   vd, (rs1)     is the vlb.v  vd, (rs1), v0.t (b + mask condition is the suffix, vd is the vector register)
lbu   vd, (rs1), rs2 is the vlsbu.v  vd, (rs1), rs2 (vd is vector register, rs2 - is the x-register stride)
lbu   vd, (rs1), vs2 is the vlxbu.v vd, (rs1), vs2 (vd is vector register, vs2 - is the RVV-register offsets)

vector-vector/vector-scalar/vector-immediate are not the different instructions but addressing modes only (note: The traditional order of the operands is used instead of the partially inverse order).

op[.m] vd, vs1, vs2 instead of vop.vv  vd, vs2, vs1,vm (all operands are vectors)
op[.m] vd, vs1, rs2 instead of vop.vx  vd, vs2, rs1, vm (rs2 is x or FPU register)
op[.m] vd, vs1, imm instead of vop.vi  vd, vs2, imm, vm (imm is numeric literal but not register)
opf[.m] vd, vs1, vs2 instead of vfop.vv  vd, vs2, vs1, vm (all operands are vectors, f.m is mnemonic suffix)
op[.m] vd, vs1, fs2 instead of vfop.vv  vd, vs2, vs1, vm (fs2 is the FPU register, .m is mnemonic suffix)

sub vd, rs1, vs2 instead of vrsub.vx vd, vs2, rs1
sub  vd, vs1, rs2 instead of vsub.vx vd, vs2, rs1

Of course, to distinguish the names of registers from other identifiers it would be good to use, for example, the prefix "%" before register name.

Why is this useful?  The standard itself was withdrawn.  How many assemblers followed the standard when it was active?
Mask is not just a dummy operand but will be a full register in longer encoding.


Uncaught ReferenceError: resource is not defined

Trouble using:
var resource = this.$resource('api/tasks/{id}');
When not used within method directly.
Vue.component('tasks', {
	template: '#tasks-template',

	data: function() {
		return {
			list: []
		}
	},

	ready: function() {
		var resource = this.$resource('api/tasks/{id}');

		this.fetchTaskList();
	},

	methods: {

		deleteTask: function(task) {
			this.list.$remove(task);
		},

		fetchTaskList: function() {
			resource.get().then(function(tasks) {
				this.$set('list', tasks.data)
			});
		}

	}

});

new Vue({
	el: 'body',
});
returns error of : Uncaught ReferenceError: resource is not defined

ready and fetchTaskList are 2 different methods. fetchTaskList has no idea about resource variable, until you define it in fetchTaskList.

Ahhhh I see, using a similar formula above how could I make var resource global, so I don't have define it in every method that requires it?

just assign it in the top of the file, outside of any function..

But if I do that then $resource will not be defined?

var resource = Vue.resource('api/tasks/{id}');

Amaze.


Fix translation in es.json, translation wasn´t work in mail subcopy

This translation didn't work after updating to Laravel 7.0.*

Gracias


Make sniproxy obsolete

Describe the issue you are having
Having to run two separate containers for HTTP and HTTPS traffic: monolithic and sniproxy.
Solution
By using the Nginx stream_ssl_preread module you can add the following configuration to nginx.conf file:
stream {
    server {
        resolver UPSTREAM_DNS;
        listen      443;
        proxy_pass  $ssl_preread_server_name:443;
        ssl_preread on;
    }
}
...
http { ... }

and have the sniproxy functionally inside the main game cache container.

This functionality was added in #107 you can now choose to run sniproxy or ssi embedded into generic/monolithic.
Thanks for the suggestion

This functionality was added in #107 you can now choose to run sniproxy or ssi embedded into generic/monolithic.
Thanks for the suggestion


BLE scan response is empty (IDFGH-6150)

Environment

Development Kit:      none
Module or chip used:  ESP32-D0WD-V3 (revision 3)
IDF version (run git describe --tags to find it): v4.3.1
Build System:         idf.py
Compiler version (run xtensa-esp32-elf-gcc --version to find it): xtensa-esp32-elf-gcc.exe (crosstool-NG esp-2021r1) 8.4.0
Operating System:     Windows
(Windows only) environment type: PowerShell
Using an IDE?: No
Power Supply:         USB

Problem Description
In our application we are using scan response and it seems to work only once after a reboot.
See attached file (scan-rsp.txt) for logging code and output.
Compare logs for "First time after esp_ble_gap_start_scanning" and "Second time after esp_ble_gap_start_scanning"
The second log shows no scan reponse data when scanning.
scan-rsp.txt

Hi @twomas
The Bluetooth bottom layer of ESP will report the received broadcast packet once in a while, so you need to do additional processing in your application layer.
For example, the broadcast packet + scan reply packet may be received in the first period of time, and maybe only the broadcast packet may be scanned in the second period.

Hi @zztiger123
I just noticed that if I do a "esp_ble_gap_set_scan_params" just before every "esp_ble_gap_start_scanning" it works

Hi @twomas
May I know your specific application requirements?
We don’t need to distinguish too much whether the received packet is adv_data or scan rsp data. Both have a maximum of 31 bytes, and the structure inside is exactly the same. When the packet is received, adv data and scan rsp data can be processed in the same way. .
For example, if there is only adv data, only adv data will be processed, and only scan rsp data will only process scan rsp data. If both are available, they will be processed separately and processed twice, first processing adv data, then scan rsp data

@twomas
Adv data and scan data are reported sometimes together and sometimes separately, because active scanning does not guarantee that each packet can be sent a Scan_REQ.
The application layer does not necessarily require simultaneous reporting because the two pieces of data are independent of each other.

The question I have if it is needed to do esp_ble_gap_set_scan_params every time before esp_ble_gap_start_scanning?
Without this fix scan responses are not seen.

Have you resolved your issue?
esp_ble_gap_set_scan_params only needs to be called once.

Thanks for reporting, feel free to reopen.


add workflow ci to project for lint code

add workflow ci to project for lint code

We use drone, not github actions.


Added Email Automation

Pull Request for Email Automation System 💡
Issue Title : Email Automation Added

Info about the related issue (Aim of the project) :
This project aims to automate the process of sending various types of emails such as welcome emails, password recovery, and notifications. It helps streamline email communication, reduce manual effort, and enhance user engagement through timely notifications.

Name: Charul Chim

GitHub ID: Charul00

Email ID<EMAIL_ADDRESS>

Identify yourself: gssoc-ext participant

Closes: #192
Describe the add-ons or changes you've made 📃

Implemented email automation for sending welcome emails, password recovery emails, and notifications.
Integrated SMTP with smtplib for email sending.
Added email validation using email-validator.
Created functions for sending plain text and HTML emails.

Type of change ☑
What sort of change have you made:

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

How Has This Been Tested? ⚙

The email automation has been tested by sending emails to multiple recipients using different functions (welcome, password recovery, notifications).
The email validation feature was tested by passing valid and invalid email addresses to ensure accurate validation.

Checklist: ☑

[x] My code follows the guidelines of this project.
[x] I have performed a self-review of my own code.
[x] I have commented my code, particularly wherever it was hard to understand.
[x] I have made corresponding changes to the documentation.
[x] My changes generate no new warnings.
[x] I have added things that prove my fix is effective or that my feature works.
[x] Any dependent changes have been merged and published in downstream modules.

@UTSAVS26 review and merge it


Remove tnozicka and add soltysh to OWNERS

/assign @mfojtik

/lgtm
/approve

Adding valid-label tag since this is OWNERS change and not code change.


Source of words

I was wondering where you have the words from, and which license do they have ?

Yeah, I would like to know too.


v0.9.9 on Ubuntu 18.04. Segmentation fault. Malloc error. Signal 11.

I have been running carla_release_0.9.5 on Ubuntu 18.04 (with cuda 10.0) without having any trouble. I just downloaded the latest Carla binary (carla_release_0.9.9).
Now DISPLAY= ./CarlaUE4.sh  gives the following error.

4.24.3-0+++UE4+Release-4.24 518 0
Disabling core dumps.
Signal 11 caught.
Malloc Size=65538 LargeMemoryPoolOffset=65554
CommonUnixCrashHandler: Signal=11
Malloc Size=65535 LargeMemoryPoolOffset=131119
Malloc Size=112464 LargeMemoryPoolOffset=243600
Engine crash handling finished; re-raising signal 11 for the default handler. Good bye.
Segmentation fault (core dumped)

Running DISPLAY= ./CarlaUE4.sh -opengl  shows nothing after printing the first two lines:

4.24.3-0+++UE4+Release-4.24 518 0
Disabling core dumps.

It looks like the GPU is trying to run something.

@RansML could it be that your driver doesn't support vulkan or that you haven't installed the vulkan dependencies? It seems that it is working perfectly using opengl (yes, that is what those 2 lines mean...everything is working fine). Could you check your driver, dependencies, etc?

Just to summarize,

Carla v.0.9.5 (Ubuntu binaries) works when I run DISPLAY= ./CarlaUE4.sh.
Carla v.0.9.9 (Ubuntu binaries) does not work when I run DISPLAY= ./CarlaUE4.sh or DISPLAY= ./CarlaUE4.sh -opengl.
I have a NVIDIA GTX1060 GPU on a Razer Blade.

I also tried on a different laptop on Ubuntu 20.04. I get exactly the same error.

Hi @RansML,
Using the DISPLAY= ... is intended to disable rendering (no window will appear) and it only works with the -opengl option. After running DISPLAY= ./CarlaUE4.sh -opengl have you tried to connect to the server? Try running the test_connection.py script in the PythonAPI/util folder.

@Axel1092 When I remove DISPLAY= it loads the CarlaUE4 window and I can interact with it using my mouse. However, nothing shows on the CLI after,

4.24.3-0+++UE4+Release-4.24 518 0
Disabling core dumps.

test_connection.py fails with the message

Failed to connect to <IP_ADDRESS>:2000.

When I run v.0.9.5, lots of print messages are typically displayed on the CLI before I can actually connect successfully.

Using DISPLAY= ./CarlaUE4.sh -quality-level=Low -opengl worked for me.
GPU: GeForce MX130 (2GB)
Cheers

Currently facing the same problem on ASUS FX705DT (Ryzen 3550H, GTX 1650 TI, 16 GB RAM). Ubuntu 20.04, using CARLA package (/opt/carla-simulator) and I almost always have exactly the same error, while trying to run CARLA. However, sometimes i have a success and CARLA launches normally. More specifically, I use BARK CARLA interface, it's open project, you can find it on github. But they use the usual Python API and launch simulator also from opt folder. I barely can see the difference in situations between my successfull launches and errors, my idea is that I have lack of GPU memory. Hope that I'm wrong and there will be some solution to that!


options.index in add event sometimes exceeds the collection length

When adding models to a collection {at: } an index that is greater than the collection length, the models are added at the end. As the test case below shows, the index provided in the corresponding add events reflects the requested indices, not the actual insertion indices.
Not sure if this qualifies as a bug, but for tracking the exact changes to a collection, it would be great if the options.index provided in the add event would reliably reflect the actual insertion index.
Some background: we need this to back native CollectionViews in our mobile framework with Backbone Collections.
describe('Collection', function() {

  var collection, events;

  beforeEach(function() {
    events = [];
    collection = new Backbone.Collection();
    collection.add([{name: 'A'}, {name: 'B'}]);
    collection.on('add', function(model, collection, options) {
      events.push('add ' + model.get('name') + ' @' + options.index);
    });
  });

  it('set provides correct indices in add events', function() {
    // before: A B
    collection.add([{name: 'C'}, {name: 'D'}], {at: 5});
    // after: A B C D
    expect(names(collection)).toBe('A B C D');

    // Backbone incorrectly returns indices 5 and 6 instead of the actual incices 2 and 3
    expect(events).toEqual(['add C @2', 'add D @3']);
  });

  function names(collection) {
    return collection.toArray().map(function(model) {
      return model.get('name');
    }).join(' ');
  }

});

The fix for this should be to move the Math.min logic up to where we figure out the at. Or guard this line. @jridgewell thoughts?
In the future, can you open a runnable JSFiddle / CodePen to assist in debugging? (And minor code golf, your names function could be written as collection.pluck('name'))

The fix for this should be to move the Math.min logic up to where we figure out the at. Or guard this line. @jridgewell thoughts?

Yup.

Take a look at b0161947eb731f936cb986b1cf669af9370adbc9, should solve this for you.

Reopening due to https://github.com/jashkenas/backbone/commit/b0161947eb731f936cb986b1cf669af9370adbc9#commitcomment-15896632.

Whooops.


fix: correctly check if the proxy setting evaluates to false

Type:
bug
The following has been addressed in the PR:

The property check was checking for a boolean but the typings expect a string.

Description:
See https://github.com/verdaccio/verdaccio/blob/5a8d92f5f93c16f505f51dddecd1c2d520771971/src/lib/up-storage.js#L53

Ok, if both methods pass the test then we have something wrong there, I will check it when I am back.

I saw the failing flow checks when I was upgrading flow-bin. Seems previous versions do not correctly check this.

Yes, Flow always fails in upgrade due new features they add. Make sense to me upgrade.

Ok, if both methods pass the test then we have something wrong there, I will check it when I am back.

Not sure what you mean but "" and false both evaluate to false when using !.
https://repl.it/repls/AccomplishedObviousDatamart

Thanks @DanielRuf


corrected permission requirement

@markingmyname
Can you review the proposed changes?
Important: When the changes are ready for publication, adding a #sign-off comment is the best way to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

Replaced by internal PR.


[Shadowrun5thA] catch weird behaviour with missing armor attributes HOTFIX

Changes / Comments
Roll20 Requests
Comments are very helpful for reviewing the code changes. Please answer the relevant questions below in your comment.

[x] Does the pull request title have the sheet name(s)? Include each sheet name.
[x] Is this a bug fix?
[ ] Does this add functional enhancements (new features or extending existing features) ?
[ ] Does this add or change functional aesthetics (such as layout or color scheme) ?
[ ] If changing or removing attributes, what steps have you taken, if any, to preserve player data ?
[ ] If this is a new sheet, did you follow Building Character Sheets standards ?

If you do not know English. Please leave a comment in your native language.

Character Sheet Info Roll20 Internal Use only.

@mperes @nmbradley please deploy this hotfix as fast as possible


error when parsing input: unexpected end of JSON input

I'm trying to fire it from CICD where I install version 0.2.2 (and tried 0.2.5 with same effect).
I took the one for linux_amd64 release build, but it fail to kind of run:
Plan: 0 to add, 5 to change, 0 to destroy.
─────────────────────────────────────────────────────────────────────────────
Saved the plan to: tf.plan
To perform exactly these actions, run the following command to apply:
    terraform apply "tf.plan"
$ tf-summarize tf.plan
error when parsing input: unexpected end of JSON input
Cleaning up project directory and file based variables
ERROR: Job failed: exit code 1

but that is very legit tf.plan file.
If I run it locally (when tf-summarize is installed by macos brew it works well), so it has to be something with a release thing.
Any suggestions?

May I know which CICD you use ? Also, how terraform is installed ?
Reason for asking:
For Github actions,
If you are using hashicorp/setup-terraform github action to setup terraform, ensure terraform_wrapper is set to false. Because without it, each terraform output will some extra lines. Example
Check if there is similar thing happen in your CICD setup.

@dineshba
it's a just a installation of latest terraform into the amazonlinux official docker image.
It's something like
FROM amazonlinux2
RUN wget terraform_zip, unzip and copy to /usr/bin/
nothing there about wrapper.
I run in GitLab CI.

https://docs.gitlab.com/runner/shells/
echo 'find . -type f -name "tfplan.json" -exec tf-summarize -tree {} \;' | /bin/bash

Glad that we have a workaround.
I will try to reproduce this issue and understand the reason behind it. This will help me to fix this issue.

Hi @kayman-mk. Thanks for confirming the issue.
For the non-existing file, I am getting below error
$ tf-summarize invalid.json
error reading from input: error when opening file invalid.json: open invalid.json: no such file or directory

and I am in 0.2.6 version (latest version). Could you please confirm the version once ?

@dineshba I am seeing a similar error using the latest version tag v0.3.2 installed via go.

@dineshba Not sure if this is related bug but if I rename any working/valid tfplan to have .json extension and try to pass to tf-summarize I get following error:
error when parsing input: invalid character 'P' looking for beginning of value
Ex.
(venv) poliva@PhilipOlivasMBP % /Users/poliva/go/bin/tf-summarize -md tfjson

CHANGE
RESOURCE

update
module.client_infrastructure.module.api_zone_record[0].aws_route53_record.record

module.client_infrastructure.module.ecs_autoscaling_target_web[0].aws_appautoscaling_target.appautoscaling_target

module.client_infrastructure.module.ecs_autoscaling_target_worker[0].aws_appautoscaling_target.appautoscaling_target

module.client_infrastructure.module.ecs_task_service_beat[0].aws_ecs_service.ecs_service

module.client_infrastructure.module.ecs_task_service_web[0].aws_ecs_service.ecs_service

module.client_infrastructure.module.ecs_task_service_worker[0].aws_ecs_service.ecs_service

recreate
module.client_infrastructure.module.batch_database_restore_job_definition[0].aws_batch_job_definition.batch_job_definition

CHANGE
OUTPUT

(venv) poliva@PhilipOlivasMBP % mv tfjson tf.json
(venv) poliva@PhilipOlivasMBP % /Users/poliva/go/bin/tf-summarize -md tf.json
error when parsing input: invalid character 'P' looking for beginning of value

yes, still same with 0.3.2, however point above workaround works pretty well. So you output a json plan from terraform then pipe it to tf-summarize, e.g.:
cat tfplan.json | tf-summarize -tree'

@GregoryOrciuch Yeah workaround is now working for me now. I was doing something wrong with terraform show step.

Got the same error with error when parsing input: unexpected end of JSON input  when running in GitLab CI.
When i download the exact plan file from the pipeline and run it locally using the same tf-summarize version, it works though.
Seems to be either about the CI Environment or the .deb installation method.

I'm seeing this same issue on a GitHub actions runner, I've fixed it with jq '.' "${json_file_path}" | tf-summarize.

I will try to reproduce this issue and understand the reason behind it. This will help me to fix this issue.

As a data point, I am unable to reproduce this locally on Mac OS using tf-summarize v0.3.6:
$ make summarize WORKSPACE=default
terraform show \
                -json \
                default.plan > default-plan.json
tf-summarize -v
Version: 0.3.6
tf-summarize \
                -out default-summary.md \
                -md \
                default-plan.json

Written plan summary to default-summary.md

However, the same command(s) and plan result in the following error when run from GitHub Actions's Ubuntu runner:
make summarize WORKSPACE=default
terraform show \
	-json \
	default.plan > default-plan.json
tf-summarize -v
Version: 0.3.6
tf-summarize \
	-out default-summary.md \
	-md \
	default-plan.json
error when parsing input: unexpected end of JSON input

However, passing raw JSON via STDIN works as expected both locally on Mac OS and in GitHub Actions's Ubuntu runner:
make summarize WORKSPACE=default
terraform show \
	-json \
	default.plan > default-plan.json
tf-summarize -v
Version: 0.3.6
jq '.' "default-plan.json" | tf-summarize \
	-md > default-summary.md

This suggests to me the possibility of an OS-specific bug/inconsistently related to how tf-summarize reads the plan JSON file if/when it's passed a plan JSON file (as opposed to when it's passed raw JSON via STDIN). Or am I barking up the wrong tree?

👋 @dineshba I've created a quick fix for this bug via PR #64.
I've also managed to create a reproducible demo for you over in https://github.com/dineshba/tf-summarize/pull/63, whose GitHub Actions runs encounter the error when parsing input: unexpected end of JSON input error: https://github.com/dineshba/tf-summarize/actions/runs/7514179482/job/20456763616#step:9:6

@dineshba This issue was addressed in PR #64 (now merged), but never included in a tf-summarize GitHub release (tf-summarize 0.3.7 is currently the latest release). Would you be willing to publish a 0.3.8 release that includes the PR #64 fix to this issue, then closing this issue? Thanks!

let me release it tomorrow with another PR merged https://github.com/dineshba/tf-summarize/pull/70

let me release it tomorrow with another PR merged https://github.com/dineshba/tf-summarize/pull/70

@dineshba 👋 😄 Gentle nudge: A 0.3.8 release including PR #64 and #70 would be great!

Created the new release v0.3.8 @mdb. Thanks for ur PRs. Really appreciated.


test: add tests for fork networks

What I did
Support fork networks.
I need this to assist in other work
How I did it
-fork str work
How to verify it
Get an account transaction using a forked network
Checklist

[ ] Passes all linting checks (pre-commit and CI jobs)
[ ] New test cases have been added and are passing
[ ] Documentation has been updated
[ ] PR title follows Conventional Commit standard (will be automatically included in the changelog)

Was there things missed here? #20

Sorry, I wasn't caught up with main and didn't notice this. Nobody had reviewed that PR!
Yes, tests were missing. They are part of this PR.

wow, weird segfault

wow, weird segfault

Ikr. It isn't happening locally for me. I have some things to try yet..

OK I figured out the issue.
The ropsten-fork network was used in a test and that network does not work in eth-ape==0.2.2; it is unreleased.
Thus, it was segfaulting, which is a little odd.
I was able to get it locally by installing eth-ape 0.2.2 and python completely crashes.


Allow to use existing bitcoin folder

I have an HDD with a recently synced bitcoin blochchain. Not Mynode or Umrel, it was synced using just core on rapsiOS. Unfortunately Raspiblitz currently suggest two options (FRESHSETUP and FROMBACKUP) both requiring formatting HDD. Is there a possibility to just point it to the bitcoin folder?

At the moment that would be too much work for an edge case and there night be more changes in the future soon that make that even harder (introducing system boot partition, etc).


Resource icons are displayed incorrectly

If I enable "Show Resource Icons" option in "Map Options", the icons are incorrectly displayed.
See image here: http://imgur.com/a/DjaEg
Game Resolution is set to 1600x900 as I am playing it in my laptop.
CQUI v0.6

v0.6 is not working with the last couple of patches, as stated on the release page:

As of the fall patch, v0.6 is incompatible with the latest Civ release from the Winter Patch 2016. Worry not! You can still enjoy CQUI with the latest civ release using the nightly

See issue #180 #184 #192 #267 and #268 for further information concerning your issue


[ZEPPELIN-1658] Big download button and display package size

What is this PR for?
Make big download button for bin package to make choices easy.
What type of PR is it?
Improvement
Todos

[x] - Big button and display package size

What is the Jira issue?
https://issues.apache.org/jira/browse/ZEPPELIN-1658
How should this be tested?
Run gh-pages branch locally
Screenshots (if appropriate)

Questions:

Does the licenses files need update? no
Is there breaking changes for older versions? no
Does this needs documentation? no

LGTM! 👍

Thanks @tae-jun for review.
Merge to gh-pages if there're no more comments.


Bump lib to add support for macOS 12

v0.0.23 has support for macOS 12 (Monterey) : https://github.com/openpnp/openpnp-capture/pull/55
on v0.0.22 camera settings are greyed out:

If approved and merged will create a PR to bump openpnp-capture-java in openpnp
v0.0.23 has been tested locally on macOS 12 and works as expected:

@vonnieda This one has bitten another user:
https://groups.google.com/g/openpnp/c/3tajMbNLZFA
You approved the PR into openpnp-capture itself. I'm not sure if you need to approve this PR or it's something Mark can do perhaps?
We also need to update the pom in openpnp.

Working on this now, thanks for the bump.


Adapt the plugin for Firefox

Cypress doesn't support Firefox yet
https://github.com/cypress-io/cypress/issues/1096
https://bugzilla.mozilla.org/show_bug.cgi?id=1605512

Blocked by #6

So the priority for use in Firefox is low? As in, not a high priority? Just wanting some clarification on this topic as I have no intention to be forced to use Chrome for any project or tool.

@weo3dev As noted by @ArtemDerevnjuk above comment this is currently blocked by Firefox capabilities, as you can read in https://github.com/NeuraLegion/cypress-har-generator/issues/6#issuecomment-566682943 we are indeed working with their team on this.
The "low" priority is that this task cannot progress until fixed somewhere else.
As a user of Firefox and a lover of opensource I promise you we will do our best to allow Firefox support when it's technically possible.
We will keep this issue updated with our progress, be sure to subscribe to it if you want to get notification when this happens.

Thank you so very much for the quickest response ever! I was reading #6 and I guess I was confused in my brain so now it makes sense the order in which development has to proceed.
Definitely subscribed to a PR tracker and an issue tracker so I can stay up to date.
Thank you again, keep up the good work!!

@derevnjuk What are your thoughts on making the plugin no-op in the Firefox browser (and any other unsupported browsers) instead of throwing an error: https://github.com/NeuraLegion/cypress-har-generator/blob/41a41f33b77cb634bafa9776efde2595e1ab1ae7/src/Plugin.ts#L60-L64
For example, could we do something like this instead:
diff --git a/src/Plugin.ts b/src/Plugin.ts
index 4a4a4e7..5947a6e 100644
--- a/src/Plugin.ts
+++ b/src/Plugin.ts
@@ -44,6 +44,7 @@ export class Plugin {
   private networkObservable?: Observer<NetworkRequest>;
   private addr?: Addr;
   private _connection?: Connection;
+  private browser?: Cypress.Browser;

   constructor(
     private readonly logger: Logger,
@@ -57,9 +58,10 @@ export class Plugin {
     browser: Cypress.Browser,
     args: string[]
   ): string[] {
+    this.browser = browser;
     if (!this.isSupportedBrowser(browser)) {
-      throw new Error(
-        `An unsupported browser family was used: ${browser.name}`
+      this.logger.warn(
+        `HAR recording is not supported in this browser: ${browser.name}`
       );
     }

@@ -77,6 +79,10 @@ export class Plugin {
   }

   public async recordHar(options: RecordOptions): Promise<void> {
+    if (this.browser && !this.isSupportedBrowser(this.browser)) {
+      return;
+    }
+
     await this.closeConnection();

     if (!this.addr) {
@@ -99,6 +105,10 @@ export class Plugin {
   }

   public async saveHar(options: SaveOptions): Promise<void> {
+    if (this.browser && !this.isSupportedBrowser(this.browser)) {
+      return;
+    }
+
     const filePath = join(options.outDir, options.fileName);

     if (!this._connection) {
@@ -130,6 +140,10 @@ export class Plugin {
   }

   public async disposeOfHar(): Promise<void> {
+    if (this.browser && !this.isSupportedBrowser(this.browser)) {
+      return;
+    }
+
     await this.networkObservable?.unsubscribe();
     delete this.networkObservable;

where the plugin does nothing except warn that HAR recording is not supported when running in those browsers?
That way plugin consumers who run their cypress tests in both supported and unsupported browsers (and are
fine with only having HAR recording in supported browsers) wouldn't have to add hacks in setupNodeEvents to conditionally enable the plugin nor manually check the browser before calling recordHar/saveHar.

@derevnjuk If you support that change, I'd be happy to open a PR with it

@rmacklin thank you for the suggestion. Please feel free to open PR

Okay! I've opened a PR here:

https://github.com/NeuraLegion/cypress-har-generator/pull/460

Since our announcement of official Firefox support for Puppeteer via WebDriver BiDi, we’ve been actively collaborating with various stakeholders to encourage the transition from CDP to BiDi, given its status as a standardized protocol.
Would there be interest in exploring WebDriver BiDi for your codebase? One key benefit is that it works across multiple browsers—currently including Chrome, Edge, and Firefox—with more to follow in the future. While we may still have some missing features you need, we’d love to hear your feedback on what’s required so we can prioritize additions to the specification and implementation.
As part of this effort, we’ve already worked on a HAR export package using WebDriver BiDi. The details can be found here: https://github.com/firefox-devtools/bidi-har-export/. We hope this might help with integrating WebDriver BiDi into this Cypress focused HAR generator.
Looking forward to hearing your thoughts!
Also please note that we are going to remove the CDP support in Firefox in the near future.


Cannot install the CPU version of torch

I tried to install the CPU version of torch but could not.
uv pip install torch==2.1.0+cpu --find-links https://download.pytorch.org/whl/torch_stable.html
# and next command gives the same result.
uv pip install torch==2.1.0 --index-url https://download.pytorch.org/whl/cpu

  × No solution found when resolving dependencies:
  ╰─▶ Because there is no version of torch==2.1.0+cpu and you require torch==2.1.0+cpu, we can conclude that the requirements are unsatisfiable.

uv version: v0.1.2
Python 3.11.7
Ubuntu 20.4
X86_64 Architecture

By the way, the install of the GPU version of torch is successful.
uv pip install torch==2.1.0
# success

Thanks! Will take a look.

Here's verbose output on my machine
❯ echo "torch==2.1.0+cpu" | uv pip compile --find-links https://download.pytorch.org/whl/torch_stable.html -
  × No solution found when resolving dependencies:
  ╰─▶ Because there is no version of torch==2.1.0+cpu and you require torch==2.1.0+cpu, we can conclude that the requirements are unsatisfiable.
❯ echo "torch==2.1.0+cpu" | uv pip compile --find-links https://download.pytorch.org/whl/torch_stable.html - -v
    0.000491s DEBUG uv_interpreter::virtual_env Found a virtualenv through VIRTUAL_ENV at: /Users/mz/eng/src/astral-sh/uv/.venv
    0.000781s DEBUG uv_interpreter::interpreter Using cached markers for: /Users/mz/eng/src/astral-sh/uv/.venv/bin/python
    0.000791s DEBUG uv::commands::pip_compile Using Python 3.9.6 interpreter at /Users/mz/eng/src/astral-sh/uv/.venv/bin/python for builds
 uv_client::cached_client::get_serde
   uv_client::cached_client::get_cacheable
     uv_client::cached_client::read_and_parse_cache file=/Users/mz/Library/Caches/uv/flat-index-v0/html/76f6661a0037bb05.msgpack
        0.010378s   0ms  WARN uv_client::cached_client Broken cache entry at /Users/mz/Library/Caches/uv/flat-index-v0/html/76f6661a0037bb05.msgpack, removing: failed to open file `/Users/mz/Library/Caches/uv/flat-index-v0/html/76f6661a0037bb05.msgpack`
        0.010766s   0ms DEBUG uv_client::cached_client No cache entry for: https://download.pytorch.org/whl/torch_stable.html
     uv_client::cached_client::fresh_request url="https://download.pytorch.org/whl/torch_stable.html"
     uv_client::cached_client::new_cache file=/Users/mz/Library/Caches/uv/flat-index-v0/html/76f6661a0037bb05.msgpack
     uv_client::flat_index::parse_flat_index_html url=https://download.pytorch.org/whl/torch_stable.html
       uv_client::html::parse url=Url { scheme: "https", cannot_be_a_base: false, username: "", password: None, host: Some(Domain("download.pytorch.org")), port: None, path: "/whl/torch_stable.html", query: None, fragment: None }
    0.318613s DEBUG uv_client::flat_index Found 2243 packages in `--find-links` entry: https://download.pytorch.org/whl/torch_stable.html
 uv_client::flat_index::from_entries
 uv_resolver::resolver::solve
      0.322186s   1ms DEBUG uv_resolver::resolver Solving with target Python version 3.9.6
   uv_resolver::resolver::choose_version package=root
   uv_resolver::resolver::get_dependencies package=root, version=0a0.dev0
        0.322468s   0ms DEBUG uv_resolver::resolver Adding direct dependency: torch==2.1.0+cpu
   uv_resolver::resolver::choose_version package=torch
     uv_resolver::resolver::package_wait package_name=torch
 uv_resolver::resolver::process_request request=Versions torch
   uv_client::registry_client::simple_api package=torch
     uv_client::cached_client::get_cacheable
       uv_client::cached_client::read_and_parse_cache file=/Users/mz/Library/Caches/uv/simple-v0/pypi/torch.rkyv
 uv_resolver::resolver::process_request request=Prefetch torch ==2.1.0+cpu
          0.323335s   0ms DEBUG uv_client::cached_client Found fresh response for: https://pypi.org/simple/torch
 uv_resolver::version_map::from_metadata
        0.324165s   1ms DEBUG uv_resolver::resolver Searching for a compatible version of torch (==2.1.0+cpu)
      0.324187s   3ms DEBUG uv_resolver::resolver No compatible version found for: torch
  × No solution found when resolving dependencies:
  ╰─▶ Because there is no version of torch==2.1.0+cpu and you require torch==2.1.0+cpu, we can conclude that the requirements are unsatisfiable.

 I use the following environment.

Ubuntu 20.4
X86_64 Architecture

There is a way to install torch by typing the URL directly. I tried that too, but it failed.
$ uv pip install torch@https://download.pytorch.org/whl/cpu/torch-2.1.0%2Bcpu-cp311-cp311-linux_x86_64.whl#sha256=5954924ce74bc7e6a6c811e3fa4bdda9936d9889f6369fd068420c444bfd1cae

error: The wheel filename "torch-2.1.0%2Bcpu-cp311-cp311-linux_x86_64.whl" has an invalid version part: after parsing 2.1.0, found "%2Bcpu" after it, which is not part of a valid version

Converting the string "%2Bcpu" to "+cpu" and executing it produces another error.
$ uv pip install torch@https://download.pytorch.org/whl/cpu/torch-2.1.0+cpu-cp311-cp311-linux_x86_64.whl#sha256=5954924ce74bc7e6a6c811e3fa4bdda9936d9889f6369fd068420c444bfd1cae

error: Failed to download: torch @ https://download.pytorch.org/whl/cpu/torch-2.1.0+cpu-cp311-cp311-linux_x86_64.whl#sha256=5954924ce74bc7e6a6c811e3fa4bdda9936d9889f6369fd068420c444bfd1cae
  Caused by: HTTP status client error (403 Forbidden) for url (https://download.pytorch.org/whl/cpu/torch-2.1.0+cpu-cp311-cp311-linux_x86_64.whl#sha256=5954924ce74bc7e6a6c811e3fa4bdda9936d9889f6369fd068420c444bfd1cae)

I think part of the problem here is solved by https://github.com/astral-sh/uv/pull/1544 (but perhaps not entirely). Do you mind trying again once that's out later today?

Thank you for working on the problem!

I think part of the problem here is solved by https://github.com/astral-sh/uv/pull/1544 (but perhaps not all of it). Do you mind trying again once that's out later today?

I'm actually going on a two-day trip starting today. So I won't be able to check it until after that. Sorry about that. If anyone is tracking this issue, I would be grateful if you could check on my behalf.

I'm actually going on a two-day trip starting today. So I won't be able to check it until after that. Sorry about that. If anyone is tracking this issue, I would be grateful if you could check on my behalf.

I got you fam 👌

Do you mind giving this at try (at your convenience) with v0.1.3?

Just using the bare uv binary on my Linux machine is working now, but I'm still having a heck of a time making thing work in Docker containers. Keeps trying to install six from the PyTorch index, which of course fails because there is no such package there. I did try to explicitly set the version of torch as well, no luck.

I have tried three different INSTALL methods and have confirmed that they all work 👏
uv version: v0.1.4
$ uv pip install torch@https://download.pytorch.org/whl/cpu/torch-2.1.0%2Bcpu-cp311-cp311-linux_x86_64.whl#sha256=5954924ce74bc7e6a6c811e3fa4bdda9936d9889f6369fd068420c444bfd1cae

Resolved 9 packages in 4.46s
Downloaded 1 package in 4.10s
Installed 9 packages in 149ms
 + filelock==3.13.1
 + fsspec==2024.2.0
 + jinja2==3.1.3
 + markupsafe==2.1.5
 + mpmath==1.3.0
 + networkx==3.2.1
 + sympy==1.12
 + torch==2.1.0+cpu (from https://download.pytorch.org/whl/cpu/torch-2.1.0%2Bcpu-cp311-cp311-linux_x86_64.whl#sha256=5954924ce74bc7e6a6c811e3fa4bdda9936d9889f6369fd068420c444bfd1cae)
 + typing-extensions==4.9.0

The next two methods worked in the same way 👍
$ uv pip install torch==2.1.0+cpu --index-url https://download.pytorch.org/whl/cpu
$ uv pip install torch==2.1.0 --index-url https://download.pytorch.org/whl/cpu

Great project and a big thank you to the maintainers!

Verbose log: https://pastebin.com/SQh4cLQS

I tried to check this log on my end, but also failed. I tried explicitly specifying the version and cpu, but no luck.
$ uv pip install torchvision==0.16.1+cpu torchaudio==2.1.1+cpu torch==2.1.1+cpu --index-url https://download.pytorch.org/whl/cpu

  x No solution found when resolving dependencies:
  `-> Because torchvision==0.16.1+cpu depends on torch==2.1.1 and you require torch==2.1.1+cpu, we can conclude that root==0a0.dev0 and torchvision==0.16.1+cpu are incompatible.
      And because you require torchvision==0.16.1+cpu, we can conclude that the requirements are unsatisfiable.

I have a similar problem when trying to use uv pip compile:

In pyproject.toml I have the +cpu dependencies specifed, and they are available on our internal Artifactory (installation works without an issue), but the compilation fails for some reason...

So.

uv pip install torch==2.1.1+cpu => works 🟢
uv pip install -e . (where the local project has torch==2.1.1+cpu as a dependency) => fails. 🔴
uv pip compile -o requirements.txt pyproject.toml (where the local project has torch==2.1.1+cpu as a dependency) => fails. 🔴

Error message (eviaea-api is my project):

Ok, found a workaround(?), using the --override option:
I created the overrides.txt file with the following content
# overrides.txt
torch==2.1.1+cpu
torchvision==0.16.1+cpu

Then called:
uv pip compile pyproject.toml -o requirements.txt --override overrides.txt
and
uv pip install -e . --override overrides.txt
For now I can live with this.

OK, so I'm looking into this (and still catching up conceptually with how #1855 ties into this) and thought it might be helpful to just start sharing what I'm seeing. At least initially, I suspect I'm not sharing anything that @charliermarsh doesn't already know. :)
So what I did here was to try and isolate where the problem is coming from. I was able to get one of the commands shared above failing for me (I'm on Linux x86-64):
$ uv pip install torch==2.1.1 --index-url https://download.pytorch.org/whl/cpu
  x No solution found when resolving dependencies:
  `-> Because torch==2.1.1 is unusable because no wheels are available with a matching platform and you require torch==2.1.1, we can conclude that the requirements are unsatisfiable.

And specifically, pip install with the same command works fine:
$ pip install torch==2.1.1 --index-url https://download.pytorch.org/whl/cpu
Looking in indexes: https://download.pytorch.org/whl/cpu
Collecting torch==2.1.1
  Using cached https://download.pytorch.org/whl/cpu/torch-2.1.1%2Bcpu-cp311-cp311-linux_x86_64.whl (184.9 MB)
Collecting filelock (from torch==2.1.1)
  Using cached https://download.pytorch.org/whl/filelock-3.9.0-py3-none-any.whl (9.7 kB)
Collecting typing-extensions (from torch==2.1.1)
  Using cached https://download.pytorch.org/whl/typing_extensions-4.8.0-py3-none-any.whl (31 kB)
Collecting sympy (from torch==2.1.1)
  Using cached https://download.pytorch.org/whl/sympy-1.12-py3-none-any.whl (5.7 MB)
Collecting networkx (from torch==2.1.1)
  Using cached https://download.pytorch.org/whl/networkx-3.2.1-py3-none-any.whl (1.6 MB)
Collecting jinja2 (from torch==2.1.1)
  Using cached https://download.pytorch.org/whl/Jinja2-3.1.2-py3-none-any.whl (133 kB)
Collecting fsspec (from torch==2.1.1)
  Using cached https://download.pytorch.org/whl/fsspec-2023.4.0-py3-none-any.whl (153 kB)
Collecting MarkupSafe>=2.0 (from jinja2->torch==2.1.1)
  Using cached https://download.pytorch.org/whl/MarkupSafe-2.1.3-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (28 kB)
Collecting mpmath>=0.19 (from sympy->torch==2.1.1)
  Using cached https://download.pytorch.org/whl/mpmath-1.3.0-py3-none-any.whl (536 kB)
Installing collected packages: mpmath, typing-extensions, sympy, networkx, MarkupSafe, fsspec, filelock, jinja2, torch
Successfully installed MarkupSafe-2.1.3 filelock-3.9.0 fsspec-2023.4.0 jinja2-3.1.2 mpmath-1.3.0 networkx-3.2.1 sympy-1.12 torch-2.1.1+cpu typing-extensions-4.8.0

[notice] A new release of pip is available: 23.2.1 -> 24.0
[notice] To update, run: pip install --upgrade pip

So I started taking a look at why uv doesn't see torch 2.1.1. To start with, I wanted to see with what our VersionMap was being populated with. So I printed out debug info for wheels with versions that contain 2.1.1 in them.  They're all either macOS (either x86-64 or aarch64) or Linux (only aarch64). But in the 2.1.1+cpu case, there are wheels that match my platform.
So the next thing I wanted to do was check to see whether the 2.1.1+cpu version was ever being requested, and if so, whether any of its wheels were found to be compatible:
lazy init for: "2.1.1"
/whl/cpu/torch-2.1.1-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl#sha256=84fefd63356416c0cd20578637ccdbb82164993400ed17b57c951dd6376dcee8 :: Incompatible(Tag(Abi))
/whl/cpu/torch-2.1.1-cp310-none-macosx_10_9_x86_64.whl#sha256=1e1e5faddd43a8f2c0e0e22beacd1e235a2e447794d807483c94a9e31b54a758 :: Incompatible(Tag(Abi))
/whl/cpu/torch-2.1.1-cp310-none-macosx_11_0_arm64.whl#sha256=e76bf3c5c354874f1da465c852a2fb60ee6cbce306e935337885760f080f9baa :: Incompatible(Tag(Abi))
/whl/cpu/torch-2.1.1-cp311-cp311-manylinux_2_17_aarch64.manylinux2014_aarch64.whl#sha256=61b51b33c61737c287058b0c3061e6a9d3c363863e4a094f804bc486888a188a :: Incompatible(Tag(Platform))
/whl/cpu/torch-2.1.1-cp311-none-macosx_10_9_x86_64.whl#sha256=a70593806f1d7e6b53657d96810518da0f88ef2608c98a402955765b8c79d52c :: Incompatible(Tag(Platform))
/whl/cpu/torch-2.1.1-cp311-none-macosx_11_0_arm64.whl#sha256=e312f7e82e49565f7667b0bbf9559ab0c597063d93044740781c02acd5a87978 :: Incompatible(Tag(Platform))
/whl/cpu/torch-2.1.1-cp38-cp38-manylinux_2_17_aarch64.manylinux2014_aarch64.whl#sha256=9ca0fcbf3d5ba644d6a8572c83a9abbdf5f7ff575bc38529ef6c185a3a71bde9 :: Incompatible(Tag(Abi))
/whl/cpu/torch-2.1.1-cp38-none-macosx_10_9_x86_64.whl#sha256=d56b032176458e2af4709627bbd2c20fe2917eff8cd087a7fe313acccf5ce2f1 :: Incompatible(Tag(Abi))
/whl/cpu/torch-2.1.1-cp38-none-macosx_11_0_arm64.whl#sha256=29e3b90a8c281f6660804a939d1f4218604c80162e521e1e6d8c8557325902a0 :: Incompatible(Tag(Abi))
/whl/cpu/torch-2.1.1-cp39-cp39-manylinux_2_17_aarch64.manylinux2014_aarch64.whl#sha256=b31230bd058424e56dba7f899280dbc6ac8b9948e43902e0c84a44666b1ec151 :: Incompatible(Tag(Abi))
/whl/cpu/torch-2.1.1-cp39-none-macosx_10_9_x86_64.whl#sha256=715b50d8c1de5da5524a68287eb000f73e026e74d5f6b12bc450ef6995fcf5f9 :: Incompatible(Tag(Abi))
/whl/cpu/torch-2.1.1-cp39-none-macosx_11_0_arm64.whl#sha256=db67e8725c76f4c7f4f02e7551bb16e81ba1a1912867bc35d7bb96d2be8c78b4 :: Incompatible(Tag(Abi))

So 2.1.1 is requested (by the resolver), and as expected, none of its wheels are considered compatible. But crucially, 2.1.1+cpu is never even requested in the first place.

@Nishikoh I've noticed that while uv-main pip install 'torch==2.1.1' --index-url https://download.pytorch.org/whl/cpu fails for me, uv-main pip install 'torch==2.1.1+cpu' --index-url https://download.pytorch.org/whl/cpu succeeds. Can you confirm for me that the latter still fails for you?
Does it fail for anyone else?

@BurntSushi
I ran the two commands and confirmed that the latter was successful.
root@bad8609641ae:/# uv pip install 'torch==2.1.1' --index-url https://download.pytorch.org/whl/cpu
  × No solution found when resolving dependencies:
  ╰─▶ Because torch==2.1.1 is unusable because no wheels are available with a matching platform and you require torch==2.1.1, we can
      conclude that the requirements are unsatisfiable.

root@bad8609641ae:/# uv pip install 'torch==2.1.1+cpu' --index-url https://download.pytorch.org/whl/cpu
Resolved 9 packages in 3.59s
Downloaded 9 packages in 9.92s
Installed 9 packages in 211ms
 + filelock==3.9.0
 + fsspec==2023.4.0
 + jinja2==3.1.2
 + markupsafe==2.1.3
 + mpmath==1.3.0
 + networkx==3.2.1
 + sympy==1.12
 + torch==2.1.1+cpu
 + typing-extensions==4.8.0

My past comments may have been wrong and confused you.
https://github.com/astral-sh/uv/issues/1497#issuecomment-1951600402

This should work as of the latest release:
uv pip install torch==2.1.0+cpu --find-links https://download.pytorch.org/whl/torch_stable.html

This should work as of the latest release:

uv pip install torch==2.1.0 --index-url https://download.pytorch.org/whl/cpu

This works for me! py3.10 and latest uv 0.1.35.

This should work as of the latest release:
uv pip install torch==2.1.0+cpu --find-links https://download.pytorch.org/whl/torch_stable.html

On the other hand, this raises:
uv pip install torch==2.1.0+cpu --find-links https://download.pytorch.org/whl/torch_stable.html
× No solution found when resolving dependencies:
╰─▶ Because torch==2.1.0+cpu is unusable because no wheels are available with a matching Python implementation and you require torch==2.1.0+cpu, we can conclude that the requirements are unsatisfiable.

Can you confirm that the environment you're in is using Python 3.10, and that you're on x86 Linux or Windows?

Can you confirm that the environment you're in is using Python 3.10, and that you're on x86 Linux or Windows?

Ops, sorry, I am on ARM macOS. You are right.

Perhaps it's due to a lack of supported variants that they omitted the local identifier there? (here upstream PyTorch states they don't intend to publish aarch64 variants with GPU accel)
# Torch 2.3.0 + Python 3.12 Linux x86_64/aarch64 wheels

# +cpu
# https://download.pytorch.org/whl/cpu/torch/
torch-2.3.0+cpu-cp312-cp312-linux_x86_64.whl
# No local identifier for arm64:
torch-2.3.0-cp312-cp312-manylinux_2_17_aarch64.manylinux2014_aarch64.whl

# +cu121
# https://download.pytorch.org/whl/cu121/torch/
torch-2.3.0+cu121-cp312-cp312-linux_x86_64.whl

Reference
Using Docker from an AMD64 machine to test ARM64 environment:
# Base environment:
$ arch
x86_64
$ docker run --rm -it --platform linux/arm64 --workdir /tmp fedora:40 bash
$ arch
aarch64

# Install uv:
$ curl -LsSf https://astral.sh/uv/install.sh | sh && source $HOME/.cargo/env
# Create and enter venv:
$ uv venv && source .venv/bin/activate

# Install:
$ uv pip install \
    --extra-index-url https://download.pytorch.org/whl/cpu \
    torch torchvision torchaudio

Resolved 13 packages in 20.18s
Downloaded 13 packages in 12.26s
Installed 13 packages in 486ms
 + filelock==3.13.1
 + fsspec==2024.2.0
 + jinja2==3.1.3
 + markupsafe==2.1.5
 + mpmath==1.3.0
 + networkx==3.2.1
 + numpy==1.26.3
 + pillow==10.2.0
 + sympy==1.12
 + torch==2.3.0
 + torchaudio==2.3.0
 + torchvision==0.18.0
 + typing-extensions==4.9.0

You can kind of see why PyTorch has local identifier variants when comparing to PyPi?:
# ARM64 (PyPi instead of PyTorch)
# Slightly newer versions of the packages but otherwise equivalent
$ uv pip install torch torchvision torchaudio

Resolved 13 packages in 1.08s
Downloaded 13 packages in 23.73s
Installed 13 packages in 425ms
 + filelock==3.14.0
 + fsspec==2024.3.1
 + jinja2==3.1.4
 + markupsafe==2.1.5
 + mpmath==1.3.0
 + networkx==3.3
 + numpy==1.26.4
 + pillow==10.3.0
 + sympy==1.12
 + torch==2.3.0
 + torchaudio==2.3.0
 + torchvision==0.18.0
 + typing-extensions==4.11.0

# AMD64 (PyPi instead of PyTorch)
# Defaults to latest cuda variant (+cu121)
# Same nvidia specific deps as PyTorch +cu121, except for nvidia-nvjitlink-cu12 (Cuda 12.4 here instead of 12.1)
$ uv pip install torch torchvision torchaudio

Resolved 25 packages in 558ms
Downloaded 25 packages in 53.62s
Installed 25 packages in 189ms
 + filelock==3.14.0
 + fsspec==2024.3.1
 + jinja2==3.1.4
 + markupsafe==2.1.5
 + mpmath==1.3.0
 + networkx==3.3
 + numpy==1.26.4
 + nvidia-cublas-cu12==<IP_ADDRESS>
 + nvidia-cuda-cupti-cu12==12.1.105
 + nvidia-cuda-nvrtc-cu12==12.1.105
 + nvidia-cuda-runtime-cu12==12.1.105
 + nvidia-cudnn-cu12==<IP_ADDRESS>
 + nvidia-cufft-cu12==<IP_ADDRESS>
 + nvidia-curand-cu12==<IP_ADDRESS>
 + nvidia-cusolver-cu12==<IP_ADDRESS>
 + nvidia-cusparse-cu12==<IP_ADDRESS>
 + nvidia-nccl-cu12==2.20.5
 + nvidia-nvjitlink-cu12==12.4.127
 + nvidia-nvtx-cu12==12.1.105
 + pillow==10.3.0
 + sympy==1.12
 + torch==2.3.0
 + torchaudio==2.3.0
 + torchvision==0.18.0
 + typing-extensions==4.11.0

Resolve platform packaging inconsistency upstream
Maybe open an issue about it upstream since it seems to be more of a packaging concern unrelated to uv?:
https://github.com/pytorch/pytorch/issues/110791#issuecomment-1753334468

please do not hesitate to open a new issue (or a PR) if you want to propose dropping +cpu suffix for Linux and Windows wheels, as nobody seems to be relying on the old installation method anyway.

Which makes sense that CPU should be the default, with local identifiers only used for actual variants (eg: different cuda version support). Might introduce some friction to any existing CI perhaps, but you can see similar with nvidia's own Docker images they publish where the naming convention isn't always consistent 😅 (at least it broke a PyTorch docker build CI task recently)

do you have any plans to add support for the most common case?
uv pip install torch==2.1.0 --index-url https://download.pytorch.org/whl/cpu

It seems to me there is a workaround by appending .* to the public version:
uv pip install torch==2.3.1.* --extra-index-url https://download.pytorch.org/whl/cpu
Resolved 9 packages in 295ms
Installed 9 packages in 336ms
 + filelock==3.13.1
 + fsspec==2024.2.0
 + jinja2==3.1.3
 + markupsafe==2.1.5
 + mpmath==1.3.0
 + networkx==3.2.1
 + sympy==1.12
 + torch==2.3.1+cpu
 + typing-extensions==4.9.0

According to PEP 440, .* means the prefix matching.

It seems to me there is a workaround by appending .* to the public version:

That's not very reliable. Try to bring in other torch packages for example:
$ uv pip install 'torch==2.3.1.*' torchvision torchaudio --index-url https://download.pytorch.org/whl/cpu
  × No solution found when resolving dependencies:
  ╰─▶ Because torch==2.3.1 has no wheels are available with a matching Python ABI and torchaudio==2.3.1+cpu depends on torch==2.3.1, we can conclude that torchaudio==2.3.1+cpu cannot be used. (1)

...

      And because torchaudio==2.2.2+cpu depends on torch==2.2.2 and torchaudio==2.3.0 has no wheels are available with a matching Python ABI, we can conclude that torchaudio<2.3.0+cpu depends on one of:
          torch==2.2.0
          torch==2.2.1
          torch==2.2.2

      And because torchaudio==2.3.0+cpu depends on torch==2.3.0 and torchaudio==2.3.1 has no wheels are available with a matching Python ABI, we can conclude that torchaudio<2.3.1+cpu depends on one of:
          torch==2.2.0
          torch==2.2.1
          torch==2.2.2
          torch==2.3.0

      And because we know from (1) that torchaudio==2.3.1+cpu cannot be used, we can conclude that all versions of torchaudio depend on one of:
          torch==2.2.0
          torch==2.2.1
          torch==2.2.2
          torch==2.3.0

      And because you require torch>=2.3.1.dev0 and torchaudio, we can conclude that the requirements are unsatisfiable.

$ uv pip install 'torch==2.3.1.*' 'torchvision==2.3.1.*' 'torchaudio==0.18.1.*' --index-url https://download.pytorch.org/whl/cpu

  × No solution found when resolving dependencies:
  ╰─▶ Because only the following versions of torchvision are available:
          torchvision<2.3.1.dev0
          torchvision>=2.3.2.dev0
      and you require torchvision>=2.3.1.dev0,<2.3.2.dev0, we can conclude that the requirements are unsatisfiable.

      hint: torchvision was requested with a pre-release marker (e.g., torchvision>=2.3.1.dev0,<2.3.2.dev0), but pre-releases weren't enabled (try: `--prerelease=allow`)

While separately, it resolves the desired package instead of 2.3.1.dev0:
$ uv pip install 'torch==2.3.1.*' --index-url https://download.pytorch.org/whl/cpu

Resolved 9 packages in 3.64s
Downloaded 9 packages in 7.97s
Installed 9 packages in 307ms
 + filelock==3.13.1
 + fsspec==2024.2.0
 + jinja2==3.1.3
 + markupsafe==2.1.5
 + mpmath==1.3.0
 + networkx==3.2.1
 + sympy==1.12
 + torch==2.3.1+cpu
 + typing-extensions==4.9.0

I encountered a version of this issue today, installing torchaudio cpuonly as per pytorch instructions.  Pip without uv succeeds:
pip install torch torchaudio --index-url https://download.pytorch.org/whl/cpu

but
uv pip install torch torchaudio --index-url https://download.pytorch.org/whl/cpu

Fails (error log attached).
Versions:

Python 3.11.9 (main, Jul 12 2024, 14:48:03) [GCC 11.4.0] on linux
uv-0.4.30-py3-none-manylinux_2_17_x86_64.manylinux2014_x86_64.whl

out.log


Added thumb to supported platforms conditions

Include thumb in arch switch for thumb*- triples, so that on Linux/arm
it is possible to generate Thumb/Thumb-2 code.

cc/ @tienex

Is it possible to write a test?

Yah, I think that shouldn't be hard.  It may make sense to test it by adding some checks to existing tests, would that work for you?

Sure!

@gribozavr I added a test for this change, and it passes for me.

@swift-ci Please test

Thanks, Ted!


fix: wrong color application

it's just an obvious mistake

@wheeOs Thanks for catching this and sending a fix!  I think at least one legitimate test is failing, though maybe due to an incorrect expectation?
01:07 +1039 ~1 -1: /b/s/w/ir/x/w/flutter/packages/flutter/test/material/text_theme_test.dart: TextTheme apply [E]
  Expected: Color:<Color(0x00000001)>
    Actual: Color:<Color(0x00000002)>

  package:test_api                                    expect
  package:flutter_test/src/widget_tester.dart 460:16  expect
  test/material/text_theme_test.dart 112:5            main.<fn>

Can you take a look?  This PR also needs to be tested, but maybe fixing that test would work.  Or you could probably write a test for TextTheme.apply and check to see that the correct value gets set for bodySmall color.

I'm going to close this due to inactivity.


Add support for getting built-in style assets

SDK has 3 built-in vector styles and allows to use them via some built-in classes by referring to style enum. The style assets should be also available as BinaryData, which allows to use them in more complex/custom scenarios.

Implemented now - VectorTileLayer has a static method createTileDecoder that returns decoder corresponding to style enum


skeleton

@rultor release, tag is 0.0.1

@rultor release, tag is 0.0.1

@yegor256 OK, I will release it now. Please check the progress here

@rultor release, tag is 0.0.1

@yegor256 Oops, I failed. You can see the full log here (spent 11s)
+ set -e
+ set -o pipefail
++ dirname ./run.sh
+ cd .
+ echo 2487483
+ echo '2.0-SNAPSHOT BUILD'
2.0-SNAPSHOT BUILD
+ date
Mon 05 Dec 2022 04:35:41 PM CET
+ uptime
 16:35:41 up 11 days, 22:13,  0 users,  load average: 6.03, 6.05, 6.24
+ cat
.rultor.yml in yegor256/home doesn't allow objectionary/xax to use its assets (there are 121 friends), see http://doc.rultor.com/reference.html#assets
+ exit -1
'cid' file is absent, most probably the Docker container wasn't started correctly

@rultor release, tag is 0.0.1

@rultor release, tag is 0.0.1

@yegor256 OK, I will release it now. Please check the progress here

@rultor release, tag is 0.0.1

@yegor256 Done! FYI, the full log is here (took me 5min)


Deleting Scene if root node is changed

Godot version:

3.1 Beta 8
Issue description:

I changed the root scene and made it the child, however when i closed the scene the root was emptied.
and i`m not sure if i saved or not
Steps to reproduce:
Create a Scene, put multiple nodes in it, change the root node to be one o the childs.

Potential duplicate of #24484.
Can you retest on beta 10? It might have been potentially fixed.
A video of the reproduction would be welcome :smiley:.

Potential duplicate of #24484.
Can you retest on beta 10? It might have been potentially fixed.
A video of the reproduction would be welcome 😃.

Beta 10 seems working thanks 👍


refactor(linter/only-used-in-recursion): improve implementation to remove using SymbolFlags::Export

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#7413  👈 (View in Graphite)
#7412
#7410
#7388
main

This stack of pull requests is managed by Graphite. Learn more about stacking.


Add list headers to inactive user emails

We're getting a ton of auto replies to<EMAIL_ADDRESS>as a result of the "We still need your help..." emails.
Please can we add a List-Id header to the emails to stop that?
(Still to figure out: Why do these emails trigger auto responses but talk notifications don't when neither have list headers?)

Also we can add the unsubscribe link, etc. in the headers. Example from Mailman:
Precedence: list
List-Id: <bash-the-bug.lists.zooniverse.org>
List-Unsubscribe: <https://lists.zooniverse.org/cgi-bin/mailman/options/bash-the-bug>,
 <mailto:bash-the-bug-request@lists.zooniverse.org?subject=unsubscribe>
List-Archive: <http://lists.zooniverse.org/pipermail/bash-the-bug/>
List-Help: <mailto:bash-the-bug-request@lists.zooniverse.org?subject=help>
List-Subscribe: <https://lists.zooniverse.org/cgi-bin/mailman/listinfo/bash-the-bug>,
 <mailto:bash-the-bug-request@lists.zooniverse.org?subject=subscribe>


Lack of node failure detection and automatic recovery functions

If a node dies, it is necessary to properly start up a new node and recover the storage.

#6 Close


Add FLEATO: Fleato coin

[x ] I understand that token listing is not required to use the Polygon Wallet with a token.

Please provide the following information for your token.
Token Name: Fleato coin
Token Symbol: FLEATO
Decimals: 18
Polygon Address: 0x6804b07d883d0169c05233332ccf17aa956424c5
Ethereum Address: 0xAF4dE4076095A20A37E4E885B255C58f9917366e
Logo URI: https://www.fleato.com/images/flea120.png
Project Name: Fleato Marketplace
Project Summary: Fleato is the defi marketplace of physical goods and services. Buy, sell any physical good or service, and get paid in crypto. Turn your clutter into crypto. Earn up to 9% fleato rewards while doing so. Hodl, swap, trade, redeem, or stake your fleato coins. Read our whitepaper at https://docs.google.com/document/d/1fVNSPS3k6sr0JjqwV6XBn4I5tHaPO82Asm_XW-fQbL4/edit?usp=sharing
Project Contact<EMAIL_ADDRESS>Project Website: www.fleato.com
Mainnet/Testnet: Polygon / Mumbai
Additonal Notes: Fleato marketplace issues pre-minted fleato tokens to buyers and sellers on the marketplace upon proof of delivery. Staked fleato on products of your choice earns you a share of profits for every sale. Join the platform today. Download the mobile app at https://apps.apple.com/us/app/fleato/id1571515220 and https://play.google.com/store/apps/details?id=com.fleato.marketplace

Included in AllTokens v1.2.0.