Comments: the very first reply to the very first comment always fail and content is lost

It looks like it's related to delayed froala initialization, with tinymce it works fine.
https://user-images.githubusercontent.com/3324866/104830904-70e1ef00-58d7-11eb-927c-14d2780f4e5b.mov

I cannot reproduce the problem neither on my DEV version nor on CI.UNA.IO.
May be it was already fixed with some other issue.


➕ [RESOURCE] - Add free book for web3

Idea Contribution

[X] I have read all the resource request issues.
[X] I'm interested in working on this issue
[X] I'm part of GSSOC organization

Where do you want to add the resource? Specify the category and section.
add a free book resource for web3
Provide the URLs of the resources you are adding
chrome-extension://efaidnbmnnnibpcajpcglclefindmkaj/https://webscience.org/wp-content/uploads/2023/04/Web3-Book-Ben-Hawes-0.4.pdf
Any alternative approaches/features
No response
Additional Context
No response
Code of Conduct

[X] I follow the CONTRIBUTING GUIDELINE of this project.

@jfmartinz sir please assign this issue to me


[chip-test/sival] Optimize csrng_edn_concurrency test and run more seeds in nightlies

This PR contains three more commits to optimize the csrng_edn_concurrency test to focus on the CSRNG and EDN interaction (and reducing wait times for ENTROPY_SRC during the test loop) and it increases the number of seeds we run in the nightlies as proposed #22753 .

The FPGA tests all fail but it looks like an infrastructure issue. This PR touches a file only relevant for one specific test which isn't run in CI. But the test is run in the nightlies and I am merging this now such that the next nightly regression runs the modified test with more seeds. We need this for M4.


Arrow keys do not work

The 4 arrow keys should allow movement left, right, up, and down, but currently do nothing.

They work now as of commit 6201ef4a3882d7f8b3b5637b3dd09002df0c54a3

Actually fixed as of commit 9a0529f


Can't install from conda-forge

I get the following error when trying to install through anaconda. I'm using linux. I also tried building from source, but when I run the example in the docs to load an image the kernel crashes (in jupyter notebook). After restarting the notebook server I get compile errors when ximage is #included. I haven't changed the cmake settings.
(cling)$ conda install xtensor-io -c QuantStack
Fetching package metadata .............
Solving package specifications:

PackageNotFoundError: Packages missing in current channels:

  - xtensor-io -> libsndfile
  - xtensor-io -> openimageio -> libwebp

This seems to work
conda install xtensor-io -c QuantStack -c conda-forge

Do you want to make a PR? Otherwise I'll edit the docs tomorrow to reflect that.

I've added -c conda-forge to the Readme.
Thanks for reporting this issue.


Adding Cypress with a few starter tests

Author Section
Description
Added Cypress for E2E testing. Since I am not sure of all the current features I just added some bases tests. Currently cypress is just setup for local testing. This will probably need a CI configuration if the project has progressed that far.
Also left in the Example tests just for review if others were not familiar with cypress. I was planning to remove before merging.
Screenshot(s) (if applicable)

PR Readiness Checklist

[x] Verified all changes are related to feature described above (no scope creep)
[x] Checked target and base branch (should be feature branch merging INTO main)
[x] Added unit tests to cover modified / additional code
[x] Added assignee

Lgtm, 👍

I guess you didn't want to wait for changes to be pushed up haha 😄

Lgtm, 👍

I guess you didn't want to wait for changes to be pushed up haha 😄

Normally I would, but for the initial commit stuff there was a bunch of tiny little tweaks that would have been annoying to detail, lol
Nice work on the initial test, though. I haven't yet hooked it up to run anywhere, but we can likely use these tests in a GitHub Action and instead of aiming at localhost, we'll aim at staging or something. This is a great first step toward that

Also, now that it's approved - feel free to merge at will. Right now, the only restriction is that at least one Code Owner must review and approve before merge. If you'd like to wait for @VincentLeighton 's review, that's fine as well. =]


Common modulus attack updated

The file is in conformation with the sample attack framework.
A new attack() function has been implemented.
The sample input dictionary format is shown.
To do:
Documentation
Testing
Optimizations (if any)
Error handling

@adithyabhatkajake I've added a few line comments. Please make the necessary changes and push them to the same branch. The PR will update on its own.

Updated.


Hf/restart game - animations

Fixed issue in resourcemanager loading multiple models over several runs

Checked and the fixes do in fact fix the 'restart-the-game' bug.


Prepend (esp-idf) to shell prompt when the idf is entered. (IDFGH-4523)

Added function in export.sh to update the shell prompt such that the
programmer knows that they are in an esp-idf environment. This works
just like when you enter a python virtual environment and the name of
the virtualenv is prepended to your shell PS1 in parens.

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

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

Thanks for your contribution.

Thanks for your contribution.

I was about to make exactly same PR, but found this.
IMO, to make a consistent visual notification is essential feature to have.
Python venv module also has such feature in long time with such many users. I'm pretty sure most user are quite appreciate with it
So could we apply this change ? :smile:

I really think we should apply this change. Haha, I have forgotten about
this PR.
On Sat, Apr 24, 2021 at 2:10 AM Cheongyo Bahk @.***>
wrote:

I was about to make exactly same PR, but found this.
IMO, to make a consistent visual notification is essential feature to have.
Python venv module also has such feature in long time with such many
users. I'm pretty sure most user are quite appreciate with it
So could we apply this change ? 😄
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/espressif/esp-idf/pull/6347#issuecomment-826047998,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ARTZN7JDNED247H7Z3ADZEDTKJVHFANCNFSM4VQR3O4A
.

Shall I close this PR? It seems this has just been ignored?

Thanks for your contribution.
Unfortunately, the altering of PS1 is beyond the scope of the export script.
It's advisable to use direnv to automatically invoke the export script when entering a project folder.
You are, however, free to add the altering of PS1 to the alias you use to invoke the export script:
alias get_idf='. $HOME/esp/esp-idf/export.sh; source ~/.bashrc; export PS1="(esp-idf) ${PS1}"'

Please note that source ~/.bashrc is used to reset PS1 to a clean state when running the alias multiple times to refresh the esp-idf environment. You may need to update it when a different shell than bash.


Spending money keeps the text on the screen

anytime i try to spend money, like for example on the "personal hooker" mod, it comes up with an error and tells me to go to my c drive and into the project folder. i dont have a project folder in my c drive, so it might be something on your end of things :)
This happens on my MP player in SP mode (like before/after i get off duty from my lspdfr shift, try to spend my earned funds and that crashes the whole game out and brings up that C drive error). I can recreate this and provide you with screen shots if you wish.
Have no issues with the rest of the mod, just the wallet! overall you did a great job. thank you for the mod
Originally posted by @Zilyanna75 in https://github.com/justalemon/PlayerCompanion/issues/5#issuecomment-1048289252

Can't repro this. Feel free to open a new issue if this keeps happening.


PixToBitmapConverter.Convert sets wrong resolution.

PixToBitmapConverter.Convert() creates a Bitmap with the default resolution of 96.  The result is an image of giant dimensions.

Merged in to the Tesseract 4 branch, probably should update the test case and also back port it to main dev branch (who know when Tess 4 will be released).


Actionbar in 1.7.1-irssi

Why is there an actionbar in the latest version on HC? The previous option menu was fine and didn't decrease the available screen size. Due to the softkeyboard it is quite limited even on large sceeens.
I know it is FOSS, but I'd rather ask if it is possible to add an option to disable the actionbar?

Can you share some kind of screenshot? Didn't catch the problem from this message...
Option menu dosen't decrease screen size @ My Galaxy Tab 10.1.

Uhm I reverted to the previous version, but generally I am speaking about the actionbar at the top of the screen. It just contains the logo and the option button with stuff like 'Disconnect' for the current connection.
If this doesn't clarify the issue I will add a screenshot later.

 Sorry, wrong button. ;)

Yeah, add screenshot and more information about your device.
Thanks.

Sorry for the delay, was a bit lazy to update and then downgrade for both shots. Should be pretty self-explanatory.
http://i.imgur.com/xtwjW.png
(Moto Xoom/HC 3.1)

I don't see any commits that fix that, so why did you close it?

My bad... Wrong button :D

In new release.

When exactly can I expect that new release? Tired of updating and then to install the backup again. ;)

Released.. couple of days ago ;)

Hm, I don't see any progress there, I still have the actionbar wasting screen space. Do you need any further information?
Motorola Xoom, HC 3.2

Try to look settings at hostlisting

Ah nice, sorry next time I'll read the changelog and thanks for adding that option. :)


TIMIT outside of LDC???

https://github.com/philipperemy/timit

https://www.kaggle.com/mfekadu/darpa-timit-acousticphonetic-continuous-speech


BLU RC Button 4 issue

Hey guys, i can't exactly determine what could be the issue here but i assume someone here would be able to spot the possible issue right away.
I have used Shelly BLU RC Button 4, it was immediately detected with HomeAssistant, everything works well in ~70% of button press cases but other than that, it behaves as if there was no signal sent.
The setup is on RPI4 and RPI5.
I doubt it's signal strength but i'm more prone to think that some inner way of working, how to pick up the packet/signal could be the case.
Any idea how to figure this out? It would be an amazing to have those buttons in use with HA.
Thnx

A first step can be to enable debug logging at debug level in HA for the Bluetooth integration. The Bluetooth integration is responsible for receiving and forwarding incomming BLE messages to e.g. the BTHome integration. In the logs, check is a message is received on every button click. If not, an reception issue is more likely, if yes, please post the messages here, indicating which were correct in HA and which were not correct.

@nardev we have an open issue about it already at https://github.com/home-assistant/core/issues/127336, please join the issue, I am going to check again and post my findings there, Thanks


Added Responsiveness and changed images and some more changes

Please check the site here

@Vishal-raj-1 Please review


As a user, I want to to see data usage on a data dashboard and the impact of specific apps on my relay allowance.

UI is ready, but API for tracking users is still needed.

@memosys requested help on this from @plor

Stuck until we see some end to end use

connected to #72 need to solve prometheus issue


feat: add elixir with bandit

btw; what directory I need to check to see how you are provisioning the infra?

@yordis By the way, your Dockerfile is broken. The final artifact is not executable.
-rw-r--r-- 1 nobody root   72 Dec  7 08:58 server

This is one way to fix it. Add this to the final stage.
RUN chmod +x /app/bin/server

No need to create a PR; I already updated it and will release it with a new video.

the image is cheat :D

the image is cheat :D

What do you mean @snatvb?

the image is cheat :D

What do you mean @snatvb?

just a joke about a picture in pr message :)

@snatvb i thought docker image 😊


@sveltejs/adapter-node generates corrupted server

Describe the bug
⚠ Disclaimer
First of all I'm not a native english speaker so please forgive my sometimes bad english! ❤
Second of all I'm not entirely sure if this issue belongs to sveltejs/kit or more to sveltejs/kit/adapter-node but as they both are on the same repository I'm posting this issue here anyway.
🐞 The bug
EDIT: This issue was introduced in 1.0.0-next.79 as my other project with 1.0.0-next.78 works fine.
While testing some stuff out for further information on #5412 I discovered the inability to generate production servers using adapter-node.
When building a production server using @sveltejs/adapter-node the generated server takes forever to respond (running in clientTimeout after 300s). When I switch the handler polka middleware inside build/index.js to a custom handler like so:
const server = polka().use(
	// https://github.com/lukeed/polka/issues/173
	// @ts-ignore - nothing we can do about so just ignore it
	compression$1.exports({ threshold: 0 }),
	(req, res) => res.end('Hello world')
);

and run node build the server instantly responds with Hello world so the issue is somewhere in the sveltekit handler.
🌟A solution
I don't know what exactly causes this problem so I can't give any solution 😥.
But this needs to be fixed somehow as it makes production builds using adapter-node impossible!
Reproduction
Manual reproduction
Repository: https://github.com/UnlimitedBytes/sveltekit-adapter-node-issue

Clone the repository to your local system
Navigate into the repository directory
Install all dependencies using npm install
Build the production server using npm run build
Start the production server using node build
Open your webbrowser and navigate to http://<IP_ADDRESS>:3000

FAST (automatic) reproduction
Execute the following commands
git clone https://github.com/UnlimitedBytes/sveltekit-adapter-node-issue
cd sveltekit-adapter-node-issue
npm install
npm run build
node build

Open your webbrowser and navigate to http://<IP_ADDRESS>:3000
Logs
Console:
> Listening on <IP_ADDRESS>:3000

Browser:
Loading for ever

System Info
System:
  OS: Windows 10 10.0.19044
  CPU: (8) x64 AMD Ryzen™ 7 5800X3D @ 4.50GHz
  Memory: 6.05 GB / 32.00 GB
Binaries:
  Node: 18.4.0 - C:\Program Files\nodejs\node.EXE
  Yarn: 1.22.19 - ~\AppData\Roaming\npm\yarn.CMD
  npm: 8.13.1 - ~\AppData\Roaming\npm\npm.CMD
Browsers:
  Edge: Spartan (44.19041.1266.0), Chromium (103.0.1264.44)
  Internet Explorer: 11.0.19041.1566
npmPackages:
  @sveltejs/adapter-node: ^1.0.0-next.79 => 1.0.0-next.79
  @sveltejs/kit: next => 1.0.0-next.366
  svelte: ^3.44.0 => 3.49.0
  vite: ^2.9.13 => 2.9.14

Severity
EDIT:
blocking an upgrade (as this issue was introduced by .79 as I found out now)
Additional Information
No response

Updated information to reflect this only occures after 1.0.0-next.79

Hmm. It looks like adapter-node works with the Demo project, but is broken with the Skeleton project. I'm not sure what the difference is...

Confirmed - got the same problem!

Ah, the Demo project works because it prerenders the index page while the Skeleton project does not

It works if I pin adapter-node to 1.0.0-next.78. Only change is a TypeScript upgrade from 4.7.2 to 4.7.4. WTF TypeScript

Using 1.0.0-next.79 I can still use npm preview and getting a working site locally, but when I deploy to production it does not work... I don't understand how that is possible!?

@DrDanRyan that's because npm run preview will use the Vite preview server and not the adapted build

I pinned TypeScript to 4.7.2 in @sveltejs/kit, @sveltejs/adapter-node, and sites/kit.svelte.dev and still had the site hang for me with adapter-node. So assuming I did that correctly and didn't screw anything up, now I have no idea what's going on...

Well and plus the adapter-node source is written in JS, so it's not like the TypeScript compiler would even have a chance to screw things up anyway, so that's unlikely to be the cause

but curl works! lol

Fix here: https://github.com/sveltejs/kit/commit/810c52bd2729e9a0996ce7049826678892b61627
I accidentally screwed up and pushed it to master rather than sending a PR. I'll wait for a review from the other maintainers before releasing it

Thanks for the issue, I was trying to figure out what went wrong. Facing the same issue, our production deployment is failing

Does this also effect adapter-auto?

this issue is related to compression package

Does this also effect adapter-auto? Having some issues right after upgrading. Downgrading doesn't help. I'm thinking about blaming the new vite.config.js setup

This happend due to the order of my vite plugins in my vite.config.js. Apparently SvelteKit needed to run AFTER everything else.

Pinning next.77 works for now while the compression PR is being reviewed.
"@sveltejs/adapter-node": "1.0.0-next.77",

@coryvirok Pinning to earlier versions (I've tried 78, and 77) hasn't worked for me.  The page remains blank.  @SeaniaTwix  Curl works for mine, too.
Request Method: GET
Status Code: 200
Remote Address: <IP_ADDRESS>:443
Referrer Policy: strict-origin-when-cross-origin
content-encoding: gzip
content-type: text/html
date: Mon, 11 Jul 2022 23:40:45 GMT
etag: "wx1tjj"
server: nginx/1.18.0 (Ubuntu)
vary: Accept-Encoding
:authority: antoine.patraldo.com
:method: GET
:path: /
:scheme: https
accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.9,es-US;q=0.8,es;q=0.7,fr-CA;q=0.6,fr;q=0.5,ca;q=0.4
cache-control: max-age=0
dnt: 1
sec-ch-ua: ".Not/A)Brand";v="99", "Google Chrome";v="103", "Chromium";v="103"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Chrome OS"
sec-fetch-dest: document
sec-fetch-mode: navigate
sec-fetch-site: none
sec-fetch-user: ?1
upgrade-insecure-requests: 1
user-agent: Mozilla/5.0 (X11; CrOS x86_64 14816.82.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36

@xpat @SeaniaTwix the reason it works on curl is bc you are not sending the Accept-Encoding: gzip  header on the request

@benmccann can we have an environment var to toggle the compression middleware? this could work as workaround for this issue
// packages/adapter-node/src/env.js

/* global ENV_PREFIX */

const expected = new Set([
	'SOCKET_PATH',
	'HOST',
	'PORT',
	'ORIGIN',
	'XFF_DEPTH',
	'ADDRESS_HEADER',
	'PROTOCOL_HEADER',
	'HOST_HEADER',
	'COMPRESSION_ENABLED'
]);

if (ENV_PREFIX) {
	for (const name in process.env) {
		if (name.startsWith(ENV_PREFIX)) {
			const unprefixed = name.slice(ENV_PREFIX.length);
			if (!expected.has(unprefixed)) {
				throw new Error(
					`You should change envPrefix (${ENV_PREFIX}) to avoid conflicts with existing environment variables — unexpectedly saw ${name}`
				);
			}
		}
	}
}

/**
 * @param {string} name
 * @param {any} fallback
 */
export function env(name, fallback) {
	const prefixed = ENV_PREFIX + name;
	return prefixed in process.env ? process.env[prefixed] : fallback;
}

// packages/adapter-node/src/index.js
import { handler } from './handler.js';
import { env } from './env.js';
import compression from 'compression';
import polka from 'polka';

export const path = env('SOCKET_PATH', false);
export const host = env('HOST', '<IP_ADDRESS>');
export const port = env('PORT', !path && '3000');
export const compression_enabled = env('COMPRESSION_ENABLED', 'true') === 'true';

const compression_middleware = compression_enabled ? compression({ threshold: 0 }) : undefined;

const middlewares = [compression_middleware, handler].filter(Boolean);

// https://github.com/lukeed/polka/issues/173
// @ts-ignore - nothing we can do about so just ignore it
const server = polka().use(...middlewares);

server.listen({ path, host, port }, () => {
	console.log(`Listening on ${path ? path : host + ':' + port}`);
});

export { server };

Pinning next.77 works for now while the compression PR is being reviewed.
"@sveltejs/adapter-node": "1.0.0-next.77",

Which sveltekit version are you using meanwhile?

Pinning next.77 works for now while the compression PR is being reviewed.
"@sveltejs/adapter-node": "1.0.0-next.77",

Which sveltekit version are you using meanwhile? @coryvirok

Nvm it doesn't matter... I forgot to npm ci after I changed the adapter-node version to 77

Hi there. Downgrading to node adapter v77 not working for me. Tried with sveltekit v370, v366
Still seeing blank page

Hi there. Downgrading to node adapter v77 not working for me. Tried with sveltekit v370, v366
Still seeing blank page

Delete package-lock.json and do npm ci then it should work

comment build/index.js compress will make it work
sed -i 's|compression$1.exports({ threshold: 0 })|//compression$1.exports({ threshold: 0 })|g' build/index.js

@shynome  That worked.  Nice.

comment build/index.js compress will make it work sed -i 's|compression$1.exports({ threshold: 0 })|//compression$1.exports({ threshold: 0 })|g' build/index.js

This worked for me!!!

will be fixed in the next version of adapter-node which removes compression at least until the bug is fixed

It wasn't released yet. Try @sveltejs/adapter-node version 1.0.0-next.81

Oh, ha - that would do it! I just saw a new version and connected the dots to make a whole different picture 😀


Performance of vespa

I haven't seen a full performance test and it's not clear exactly how the vespa performs. I noticed that manticoresearch claims it performs dozens of times faster than elasticsearch, so how about vespa? Also, I've noticed that both vespa, and elasticsearch, use DaaT for their searches, obtaining a document per iteration and scoring it, which is what the vast majority of search engines do. However, I noticed that manticoresearch is fetching documents one batch at a time in an iteration, about 32 of them, so doc id and term frequency are unpacked a batch at a time, I'm not sure if this improves performance significantly, does vespa have a plan to do this?

If you are interested in performance I suggest reading https://docs.vespa.ai/en/performance/practical-search-performance-guide.html - it's a too big topic to cover here.
Some other comments:

DaaT enables ranking functions which are non-linear over the query items, is often necessary to produce the desired relevance/behavior.
For text fields searched with multiple terms specifically, Vespa by default uses a WAND operator, which does its own early dropping based on item-internal linear ranking (same with Elastic). The whole DaaT/TaaT distinction on the word level really became obsolete with the invention of WAND imo.
For general, cases where early dropping of documents for performance is more important than non-linear ranking across fields, Vespa provides match-phase.

For text fields searched with multiple terms specifically, Vespa by default uses a WAND operator, which does its own early dropping based on item-internal linear ranking (same with Elastic). The whole DaaT/TaaT distinction on the word level really became obsolete with the invention of WAND imo.

It seems vespa has implemented WAND instead of BlockMax WAND according to the code?   Since BlockMax WAND has been a default in elasticsearch since 2019, while BlockMax WAND is several times faster than WAND but requires the index posting to store some extra impact score at a block level. As a result, have you evaluate the performance of WAND compared with that from other alternatives?

We could likely get some small boost from that, but once you get the early drop from WAND this just isn't a large part of the total resource usage of queries in real applications. Most of those find that Vespa is faster for other reasons such as moving away from the multi-segment approach to approach realtime indexing a decade ago.


Update gpu_advanced.md

Updating "thThis" "This" as per #53775

In the future, can you try to fix multiple typos at once, please? It doesn't make sense to run all of these hours of CI for just 1-2 letters changes.

@Saduf2019  Can you please check @mihaimaruseac's comments and resolve conflicts?. Thanks!

6eb4c6bc38c81b54b93b063bee41dbe530b4174f


[ERR_REQUIRE_ESM]: Must use import to load ES Module

Hi,
Apologies in advance if this is a node issue and not a geolib issue, I'm not familiar with this error message.
Up to and including node v12.10.0 we have had no issue loading this library using the syntax:
const geolib = require('geolib');

since nodejs version v12.11.0 we are getting the following error:
internal/modules/cjs/loader.js:958
      throw new ERR_REQUIRE_ESM(filename);
      ^
Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: /home/travis/build/pelias/api/node_modules/geolib/lib/index.js
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:958:13)
    at Module.load (internal/modules/cjs/loader.js:798:32)
    at Function.Module._load (internal/modules/cjs/loader.js:711:12)
    at Module.require (internal/modules/cjs/loader.js:838:19)
    at require (internal/modules/cjs/helpers.js:74:18)
    at Object.<anonymous> (/home/travis/build/pelias/api/controller/placeholder.js:4:16)
    at Module._compile (internal/modules/cjs/loader.js:945:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:962:10)
    at Module.load (internal/modules/cjs/loader.js:798:32)
    at Function.Module._load (internal/modules/cjs/loader.js:711:12)

Oh that's an interesting one. Will check that.

I have the same issue.

I just test it with node 12.11.1 and works fine. It was a problem with node 12.11.0:
This release fixes a regression that prevented from building Node.js using the official source tarball (Richard Lau)
https://nodejs.org/en/blog/release/v12.11.1/

#209 solved the issue for me

Have similar issue on node 13.
08:49:12.610 error: (node:6) Warning: require() of ES modules is not supported.
require() of /app/node_modules/geolib/lib/index.js from /app/src/index.js is an ES module file as it is a .js file whose nearest parent package.json contains "type": "module" which defines all .js files in that package scope as ES modules.
Instead rename index.js to end in .cjs, change the requiring code to use import(), or remove "type": "module" from /app/node_modules/geolib/package.json.

Heya OP here, the orignially reported issue was resolved in v12.11.1, sorry I should have closed it before that last comment came through...

The same here, tested with node 13.1.0:
(node:10520) Warning: require() of ES modules is not supported.
require() of C:\nodejs\ebm-one\node_modules\geolib\lib\index.js from C:\nodejs\ebm-one\services\activities.js is an ES module file as it is a .js file whose nearest parent package.json contains "type": "module" which defines all .js files in that package scope as ES modules.
Instead rename index.js to end in .cjs, change the requiring code to use import(), or remove "type": "module" from C:\nodejs\ebm-one\node_modules\geolib\package.json.

Quite blocked by this one on Node v12.11.0.
Seems like "type": "module" is just causing a hassle...

@ptboyer did you read the thread above? this is a known issue with v12.11.0 which was resolved in v12.11.1

Yeah. Try upgrading your Node to v12.11.0. That should fix it!

@missinglink @manuelbieh Ah sorry lads! I read it wrong.
Upgraded to v12.11.1 fixed it. Cheers!

Anyway the problem in node 13 is still there, I have solved it by renaming geolib/lib/index.js to geolib/lib/index.cjs and changing the reference {"main": "lib/index.cjs"} in package.json

Anyway the problem in node 13 is still there

Indeed. I have the same issue in the Node.js current release: 13.2.0.

Same issue with Node.js release: 12.13.1 (LTS)
https://github.com/nodejs/node/pull/29909

Same issue.
Please note https://www.npmjs.com/package/geolib has common features and there is no issue.

Can we try to consolidate which versions of Node are affected here?
Working:

12.11.1

Broken:

12.11.0
12.13.1
13.2.0

That looks really broken … 12.11.0 does not work, 12.11.1 and 12.12.0 do, 12.13.1 is broken again.

broken in node 13.3.0

I just published 3.2.0. Can anyone of you please test it in your environment and tell me if it's fixed? All I did was to remove the "type": "module" flag in package.json.

Tested with Node 13.1.0 successfully.

Happy to hear that! 🙂

Tested with Node 12.13.1 (LTS) successfully. Thanks!

Alright, thanks. I think this can be considered done then. I'm currently investigating how this whole new ES Module loading mechanism in Node and modern browsers works (or not works). I have a rough high level idea but really not more than that. If you wanna follow me, I'm documenting everything here:
https://github.com/manuelbieh/authoring-modules-in-node

I'm using the last version 3.2.0 of this module with Node Express and a React app, and works fine. Thanks!

Looks like the same issue got introduced in 12.16.0.

We're running node v13.6.0 with the follwoing gulpfile.js:
import { src, dest, series, parallel, watch } from 'gulp'
import nodemon from 'gulp-nodemon' // normal nodemon does not display an error on app crash
import env from 'gulp-env'
import browser from 'browser-sync'
import sass from 'gulp-sass'
// Tasks
export default {
    cssTranspile: cssTranspile,
    jsTranspile: jsTranspile,
    server: series(startNodemon, startBrowserSync),
    default: series(
        parallel(
            cssTranspile,
            jsTranspile
        ),
        startNodemon,
        startBrowserSync,
        function () {
            watch('public/scss/*.scss', cssTranspile)
        }
    )
}

The error reported is:
internal/modules/cjs/loader.js:1160
      throw new ERR_REQUIRE_ESM(filename, parentPath, packageJsonPath);
      ^

Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: T:\Node\ICP\gulpfile.js
require() of ES modules is not supported.

I must be doing something wrong as this seems to be fixed for others. Anyone an idea on what it might be?

The flag "type": "module", is set in package.json as described in the note docs.

It is no longer in 3.2.0. Upgrade your dependency please, that might fix your issue.

Thank you for the feedback @manuelbieh but they are the latest and greatest. See docs here for the flag.

I mean upgrade your geolib dependency to 3.2.x. The "type": "module" flag has been removed from 3.1.x -> 3.2.x

As I don't have the geolib package as dependency I guess I should open an issue with gulp. I'm sorry, I probably came to the wrong page.

This worked for me:
//I kept getting an ES6 script error when running through Postman, haven't solved, moving on
import { MongoClient } from 'mongodb';
^^^^^^^^^^^
SyntaxError: The requested module 'mongodb' does not provide an export named 'MongoClient'
Solution:
//change your start in package.json
"start": "npx nodemon --exec npx babel-node --experimental-modules src/server.js",
//this version of Node works with ES6 extensions, others do not
npm install<EMAIL_ADDRESS>npm i esm // install ES6 bridging lib
node -r esm server.js //from file dir

I think this is a node issue, I can't even run npx create-react-app.
I am using node 12.16.2.
It's fine in 12.11.1

@armanrozika is this something which has happened in the last few hours?
I can't run npx create-react-app either right now despite being able to do it this morning

Me neither, I cant run npx create-react-app

@aicayzer Yup, It happened like an hour ago, it is not working suddenly

I am not able to run npx create-react-app hello-world
It says below error
Must use import to load ES Module: /usr/local/lib/node_modules/create-react-app/node_modules/is-promise/index.js
require() of ES modules is not supported.
require() of /usr/local/lib/node_modules/create-react-app/node_modules/is-promise/index.js from /usr/local/lib/node_modules/create-react-app/node_modules/run-async/index.js is an ES module file as it is a .js file whose nearest parent package.json contains "type": "module" which defines all .js files in that package scope as ES modules.
Instead rename /usr/local/lib/node_modules/create-react-app/node_modules/is-promise/index.js to end in .cjs, change the requiring code to use import(), or remove "type": "module" from /usr/local/lib/node_modules/create-react-app/node_modules/is-promise/package.json.
I am using node 12.16.2 which I downloaded today

same issue here guys...but it worked for me earlier...

Same here node v12.16.0

same issue here

Try uninstalling your present NodeJS version and installing
https://nodejs.org/download/release/v12.12.0/node-v12.12.0-x64.msi
Worked for me!

checkout this issue for more help https://github.com/facebook/create-react-app/issues/8896

Try downgrading Node. This works for me (https://github.com/facebook/create-react-app/issues/8896#issuecomment-619412921)

It's working now guys, they have fixed it, I tested it in v12.16.2
this is the link to the issue: https://github.com/then/is-promise/pull/15

I have this problem in json-serve
This error happens when I leave the
 var lodash = require ('lodash');
var isPromise = require ('is-promise');
main.js file with require syntax
`C:\Users\cl4sh\OneDrive\Área de Trabalho\meat-app-starter-master>json-server db.json
internal/modules/cjs/loader.js:1174
throw new ERR_REQUIRE_ESM(filename, parentPath, packageJsonPath);
^
Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: C:\Users\cl4sh\AppData\Roaming\npm\node_modules\json-server\node_modules\is-promise\index.js
require() of ES modules is not supported.
require() of C:\Users\cl4sh\AppData\Roaming\npm\node_modules\json-server\node_modules\is-promise\index.js from C:\Users\cl4sh\AppData\Roaming\npm\node_modules\json-server\node_modules\lowdb\lib\main.js is an ES module file as it is a .js file whose nearest parent package.json contains "type": "module" which defines all .js files in that package scope as ES modules.
Instead rename index.js to end in .cjs, change the requiring code to use import(), or remove "type": "module" from C:\Users\cl4sh\AppData\Roaming\npm\node_modules\json-server\node_modules\is-promise\package.json.
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1174:13)
at Module.load (internal/modules/cjs/loader.js:1002:32)
at Function.Module._load (internal/modules/cjs/loader.js:901:14)
at Module.require (internal/modules/cjs/loader.js:1044:19)
at require (internal/modules/cjs/helpers.js:77:18)
at Object.<anonymous> (C:\Users\cl4sh\AppData\Roaming\npm\node_modules\json-server\node_modules\lowdb\lib\main.js:4:17)
at Module._compile (internal/modules/cjs/loader.js:1158:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1178:10)
at Module.load (internal/modules/cjs/loader.js:1002:32)
at Function.Module._load (internal/modules/cjs/loader.js:901:14) {

code: 'ERR_REQUIRE_ESM'
}`
when I change the require to import this error disappears and this other error enters.
`C:\Users\cl4sh\OneDrive\Área de Trabalho\meat-app-starter-master>json-server db.json
{^_^}/ hi!
Loading db.json
TypeError: lodash.runInContext is not a function
at module.exports (C:\Users\cl4sh\AppData\Roaming\npm\node_modules\json-server\node_modules\lowdb\lib\main.js:12:18)
at C:\Users\cl4sh\AppData\Roaming\npm\node_modules\json-server\lib\cli\utils\load.js:45:15
at new Promise ()
at module.exports (C:\Users\cl4sh\AppData\Roaming\npm\node_modules\json-server\lib\cli\utils\load.js:36:10)
at start (C:\Users\cl4sh\AppData\Roaming\npm\node_modules\json-server\lib\cli\run.js:112:12)
at module.exports (C:\Users\cl4sh\AppData\Roaming\npm\node_modules\json-server\lib\cli\run.js:149:3)
at module.exports (C:\Users\cl4sh\AppData\Roaming\npm\node_modules\json-server\lib\cli\index.js:86:3)
at Object. (C:\Users\cl4sh\AppData\Roaming\npm\node_modules\json-server\lib\cli\bin.js:6:14)
at Module._compile (internal/modules/cjs/loader.js:1158:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1178:10)`
I've tried everything and nothing resolves ...

Heya OP here, the originally reported issue was resolved in v12.11.1, sorry I should have closed it before that last comment came through...

it works for me thank you

just tried reinstalling create-react-app and it resolved the issue with create-react-app on node version 12.16.2

Well, the best solution is to rename the index.js to index.cjs and change the reference in package.json to   "main": "index.cjs",

Fixed for me on node v14.0.0

Downgrade @babel/runtime to 7.7.2 fixed it for me.
https://github.com/standard-things/esm/issues/868#issuecomment-587151825

Upgrading geolib from 3.0.x to 3.2.x fixed it for me.

Im currently having this problem, but with a simple express server and three.js. My version of node is 12.16.3 LTS. Does anyone else still have the "Must use import to load ES Module" Error?

Im currently having this problem, but with a simple express server and three.js. My version of node is 12.16.3 LTS. Does anyone else still have the "Must use import to load ES Module" Error?

Aha! Newbie mistake. Of course my node LTS version only includses nodejs as a experimental module. This thread helped me figure that out anyway . Thanks.

Anyway the problem in node 13 is still there, I have solved it by renaming geolib/lib/index.js to geolib/lib/index.cjs and changing the reference {"main": "lib/index.cjs"} in package.json

after some time researching, it was the solution for me, thanks!

Still broken in v14.4.0. I will try the solution above and check if it works for this version of node.

hi, im following this thread as a sanity check. is it just me or is every last aspect of the ecosystem in some way broken or off these days? no matter which import/require, fs/os/path/__dirname you try, it's bound to crash every other build tool/transpiler you have. ive seen 10 blogs about getting around __dirname when that's not available. there's threads like this everywhere.
is node just a pile of trash at this point with 8 different footguns for the most basic i/o?

I just published 3.2.0. Can anyone of you please test it in your environment and tell me if it's fixed? All I did was to remove the "type": "module" flag in package.json.

this fixed the issue for me with node v15.1.0

no success on various node versions , removing "type": "module" didn't do anything.

the same problem with v12.16.1

When removing "type": "module" from package.json,
import _ from "lodash";
^^^^^^
SyntaxError: Cannot use import statement outside a module
appears.

When removing "type": "module" from package.json,
import _ from "lodash";
^^^^^^
SyntaxError: Cannot use import statement outside a module
appears.

same problem win7 node 13.6.0

Yeah... some problem with v12.16.1 ubuntu

same problem occurs with node version v14.16.0

Same with Node v15.10.0

Getting the same on Node v15.13.0

Node v14.16.1 same problem.

Same for me Node v14.15.0

I have a same issue like this
Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: C:\Users\Prasath\swagger-api\node_modules\swagger-jsdoc\index.js
require() of ES modules is not supported.

I'm using Node.js v14.16.1 and getting this error. I tried everything as described below to remove this issue but still error is there. Help from you is highly appreciated.
internal/modules/cjs/loader.js:1080
throw new ERR_REQUIRE_ESM(filename, parentPath, packageJsonPath);
^
Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: /Users/Desktop/Node js project/COINDEX-CLI/node_modules/configstore/index.js
require() of ES modules is not supported.
require() of /Users/Desktop/Node js project/COINDEX-CLI/node_modules/configstore/index.js from /Users/Desktop/Node js project/COINDEX-CLI/lib/KeyManager.js is an ES module file as it is a .js file whose nearest parent package.json contains "type": "module" which defines all .js files in that package scope as ES modules.
Instead rename index.js to end in .cjs, change the requiring code to use import(), or remove "type": "module" from /Users/Desktop/Node js project/COINDEX-CLI/node_modules/configstore/package.json.
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1080:13)
at Module.load (internal/modules/cjs/loader.js:928:32)
at Function.Module._load (internal/modules/cjs/loader.js:769:14)
at Module.require (internal/modules/cjs/loader.js:952:19)
at require (internal/modules/cjs/helpers.js:88:18)
at Object.<anonymous> (/Users/Desktop/Node js project/COINDEX-CLI/lib/KeyManager.js:1:21)
at Module._compile (internal/modules/cjs/loader.js:1063:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1092:10)
at Module.load (internal/modules/cjs/loader.js:928:32)
at Function.Module._load (internal/modules/cjs/loader.js:769:14) {

code: 'ERR_REQUIRE_ESM'
}

Fixed it for me after upgrading node 12.16.3 -> 14.17.0

thank you😊

I'm getting this as well when I do a next build (node 15.0.1). Any updates?

I have the exact same problem. Using Node 16.3.0

same problem. Using node v16.5.0

same problem with node version 14.17.5
plz help

same problem, any updates ?

I am using v18.5.0 still getting same issue.

Using node 21.5.0, same issue for me :((


HTTPError: INTERNAL SERVER ERROR when importing custom trained model [BUG]

I have created my own model using the GUI (cpmalte2) and now want to batch analyse images using the following code:
from cellpose import models
from cellpose.io import imread
import glob
from cellpose import io
import os

pathStem = 'C:/Users/mstelzer/Desktop/MalteforCellpose/Images/'

####
pathFolder = 'P0-P10/29190-1/red'

pathDir = pathStem + pathFolder
**model = models.Cellpose(model_type='cpmalte2')**
channels = [[0,0]]
os.chdir(pathDir)

Files = glob.glob("*.tif")

for f in Files:
    imgs = [imread(f) for f in Files]
    masks, flows, styles, diams = model.eval(imgs, diameter=107, channels=channels)
    io.masks_flows_to_seg(imgs, masks, flows, diams, Files, channels)

But it seems that cellpose cannot recruit my model and I receive this error:
runfile('Q:/Personal/Malte/Code/BatchPro_red.py', wdir='Q:/Personal/Malte/Code')
Traceback (most recent call last):

  File Q:\Personal\Malte\Code\BatchPro_red.py:22
    model = models.Cellpose(model_type='cpmalte2')

  File ~\AppData\Local\anaconda3\envs\cellpose\lib\site-packages\cellpose\models.py:100 in __init__
    self.pretrained_size = size_model_path(model_type, self.torch)

  File ~\AppData\Local\anaconda3\envs\cellpose\lib\site-packages\cellpose\models.py:35 in size_model_path
    return cache_model_path(basename)

  File ~\AppData\Local\anaconda3\envs\cellpose\lib\site-packages\cellpose\models.py:43 in cache_model_path
    utils.download_url_to_file(url, cached_file, progress=True)

  File ~\AppData\Local\anaconda3\envs\cellpose\lib\site-packages\cellpose\utils.py:65 in download_url_to_file
    u = urlopen(url)

  File ~\AppData\Local\anaconda3\envs\cellpose\lib\urllib\request.py:222 in urlopen
    return opener.open(url, data, timeout)

  File ~\AppData\Local\anaconda3\envs\cellpose\lib\urllib\request.py:531 in open
    response = meth(req, response)

  File ~\AppData\Local\anaconda3\envs\cellpose\lib\urllib\request.py:640 in http_response
    response = self.parent.error(

  File ~\AppData\Local\anaconda3\envs\cellpose\lib\urllib\request.py:569 in error
    return self._call_chain(*args)

  File ~\AppData\Local\anaconda3\envs\cellpose\lib\urllib\request.py:502 in _call_chain
    result = func(*args)

**File ~\AppData\Local\anaconda3\envs\cellpose\lib\urllib\request.py:649 in http_error_default
    raise HTTPError(req.full_url, code, msg, hdrs, fp)

HTTPError: INTERNAL SERVER ERROR**

How can I make cellpose use my trained model?
Any help is much appreciated!

The http error is because cellpose is attempting to download a model called 'cpmalte2' from the cellpose server, which doesn't exist. You need to use the CellposeModel object instead of the Cellpose object to access the GUI models. Use the keyword-argument pair model_type='name_in_gui'or pretrained_model='/full/path/to/model'. Note that the latter is the fully resolved path (not relative).
See the docs for more info.


issue 913修复

新增bug修复以及对应测试类。修复集合不可变时反序列化出错的问题。
https://github.com/alibaba/fastjson2/issues/913

Codecov Report
Base: 70.08% // Head: 71.71% // Increases project coverage by +1.63% :tada:

Coverage data is based on head (4165b43) compared to base (8767345).
Patch coverage: 23.07% of modified lines in pull request are covered.

Additional details and impacted files
@@             Coverage Diff              @@
##               main     #917      +/-   ##
============================================
+ Coverage     70.08%   71.71%   +1.63%
- Complexity    14990    15376     +386
============================================
  Files           664      664
  Lines         67155    67677     +522
  Branches      14063    14194     +131
============================================
+ Hits          47063    48535    +1472
+ Misses        14408    13418     -990
- Partials       5684     5724      +40

Impacted Files
Coverage Δ

...on2/reader/FieldReaderCollectionFieldReadOnly.java
80.76% <0.00%> (-6.74%)
:arrow_down:

...n2/reader/FieldReaderCollectionMethodReadOnly.java
71.69% <0.00%> (-2.82%)
:arrow_down:

...ain/java/com/alibaba/fastjson2/util/TypeUtils.java
87.51% <42.85%> (-0.43%)
:arrow_down:

...tible/src/main/java/com/alibaba/fastjson/JSON.java
64.03% <0.00%> (-7.12%)
:arrow_down:

.../src/main/java/com/alibaba/fastjson/JSONArray.java
82.24% <0.00%> (-1.52%)
:arrow_down:

...n/java/com/alibaba/fastjson2/JSONWriterPretty.java
93.07% <0.00%> (-0.73%)
:arrow_down:

...in/java/com/alibaba/fastjson2/JSONWriterUTF16.java
79.91% <0.00%> (-0.71%)
:arrow_down:

...alibaba/fastjson2/reader/ObjectReaderProvider.java
75.76% <0.00%> (-0.43%)
:arrow_down:

...m/alibaba/fastjson2/internal/asm/MethodWriter.java
89.39% <0.00%> (-0.18%)
:arrow_down:

...m/alibaba/fastjson2/benchmark/LargeFile2MTest.java
0.00% <0.00%> (ø)

... and 46 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


i18n: Internationalization

packages/artalk/src/i18n/

thank you for working so late. Good night, sweet dreams! 😉


code . spams console and listens to Ctrl-C

Issue Type: Bug

Run code . on command prompt

Expected: No logs appear on the command prompt, and pressing Ctrl-C on the command prompt does not close VSCode.
Actual: The command prompt gets spammed with logs (see below), and pressing Ctrl-C on the command prompt closes VSCode. Note that this does not occur when running code . > nul.
[main 2022-04-27T09:15:23.110Z] window#load: attempt to load window (id: 1)
[main 2022-04-27T09:15:23.192Z] update#setState idle
[main 2022-04-27T09:15:23.370Z] ExtensionHostStarterWorker created
[main 2022-04-27T09:15:25.157Z] window#load: window reported ready (id: 1)
[main 2022-04-27T09:15:25.421Z] Starting extension host with pid 1696 (fork() took 49 ms).
[main 2022-04-27T09:15:25.422Z] ExtensionHostStarterWorker.start() took 53 ms.

Video:
https://user-images.githubusercontent.com/33279053/165490272-eabe6bbc-84d8-400f-9aff-6c978e876a06.mp4
(While this is not displayed, VSCode opened in the background but closed when I pressed Ctrl-C at 0:10)
VS Code version: Code 1.66.2 (dfd34e8260c270da74b5c2d86d61aee4b6d56977, 2022-04-11T07:46:01.618Z)
OS version: Windows_NT ia32 10.0.19044
Restricted Mode: No

System Info

Item
Value

CPUs
Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz (4 x 2195)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onoop_rasterization: enabledopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_renderer: enabled_onvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabled

Load (avg)
undefined

Memory (System)
7.89GB (2.64GB free)

Process Argv
.

Screen Reader
no

VM
0%

Extensions (10)

Extension
Author (truncated)
Version

vscode-eslint
dba
2.2.2

EditorConfig
Edi
0.16.4

python
ms-
2022.4.1

vscode-pylance
ms-
2022.4.2

jupyter
ms-
2022.3.1000901801

jupyter-keymap
ms-
1.0.0

jupyter-renderers
ms-
1.0.6

atom-keybindings
ms-
3.0.9

js-atom-grammar
ms-
0.1.14

datapack-language-server
SPG
3.3.29

(1 theme extensions excluded)

Merging to https://github.com/microsoft/vscode/issues/66750


Added tailwind dependencies.

Just going through https://tailwindcss.com/docs/guides/remix and setting up the tailwind config for styles

Sounds good. Go for it.


align_double_arrows and UTF8 characters

I have an array containing UTF8 encoded characters
	protected $inflect_male = array(
		'aitė\b' => 'as',
		'ytė\b'  => 'is',
		'iūtė\b' => 'ius',
		'utė\b'  => 'us',
	);

The align_double_arrows fixer converts this to
	protected $inflect_male = array(
		'aitė\b'  => 'as',
		'ytė\b'   => 'is',
		'iūtė\b' => 'ius',
		'utė\b'   => 'us',
	);

It would appear that the fixer is counting bytes, rather than characters.
$ php-cs-fixer
PHP CS Fixer version 1.9.1 by Fabien Potencier (f2c2c55)

Well... I think we would need mbstring extension here. Any ideas how to fix it without that extension ?

We could just use the mb_string function if it's available.

Maybe we should just require the extension in 2.0?

Well... I think we would need mbstring extension here. Any ideas how to fix it without that extension ?

You don't want to go there ;) on version 1.x we could add mb_string as suggestion to install in composer.json and do checks during runtime to see if it is installed;

Maybe we should just require the extension in 2.0?

:+1:

It is non-default extension and I woudn't want to require it.
If we want to use that ext in this method then it would be great to only suggest the extension and test it's presence in that one fixer in supports or somewhere like that.
What do you think ?

Any ideas how to fix it without that extension ?

A "quick and dirty" answer is to ignore characters that match (binary) 10xxxxxx.
These are the "continuation bytes" in UTF8 encoding.

Or strlen(utf8_decode()).
But I'm not sure how reliable it is.

Does http://php.net/manual/pl/intro.xml.php extension is always enabled ?

Yeah, it is :D
http://php.net/manual/en/xml.installation.php

Fixed in #1313

Closing due to merge of #1313


Mask type does not work correctly on Android

Bug
Unexpected behavior
objects don't appear on Android when inside a mask which should show them. iOS shows them as expected.
code
/* eslint-disable i18next/no-literal-string */
import * as React from "react";
import Svg, { G, Mask, Path, SvgProps } from "react-native-svg";

export const SVGWithMask = (props: SvgProps): JSX.Element => (
  <Svg
    xmlns="http://www.w3.org/2000/svg"
    width={304}
    height={271}
    fill="none"
    {...props}
  >
    <Mask
      id="e"
      width={28}
      height={28}
      x={240}
      y={108}
    >
      <Path fill="#fff" d="M267.568 108.903h-26.867v26.867h26.867v-26.867Z" />
    </Mask>
    <G mask="url(#e)"> // <---- removing this, makes the element appear as expected
      <Path
        fill="#2D3142"
        d="M250.321 116.318c2.337 1.713 4.455 5.751 5.502 6.48 1.041.722 7.913 3.053 7.913 3.053s3.309 1.021 3.477 1.321c.168.299-.187.51-.187.51l-10.86-2.729a10.21 10.21 0 0 0-.075.879.68.68 0 0 1-.137.461.648.648 0 0 1-.399.262s1.221 1.788 1.408 2.043c.181.256.106 1.166.106 1.166l-3.956-2.916-.897.442-1.976 3.894c.424 0 .835.025 1.259.075.611.068.287.324.33.542.038.218-.648-.106-.648-.106s-.685-.075-1.227-.075c0 .156-.019.318-.038.474 0 0 .904-.038 1.44-.112a1.106 1.106 0 0 1 1.084.548c.181.293-.686-.106-.686-.106s-.317.15-.392.293c-.075.149-.904.218-1.115.181-.218-.038-.979 0-1.259 0-.511.149-1.016.33-1.514.548-.287.075-1.221.037-1.184-.112.037-.15.897-.287.897-.287l-.791-.181-1.146.038s-.256-.218-.219-.324c.038-.106 1.153-.075 1.153-.075l.791-.075s.106-.143.219-.068c.461.118.947.106 1.401-.038.462-.187.505-.479.505-.479a8.47 8.47 0 0 0-.791.037c-.611.025-1.221.012-1.832-.037a.805.805 0 0 1-.573-.362c-.038-.106-.287-.037-.611-.324a1.583 1.583 0 0 1 1.115.144c.387.074.792.074 1.184 0 .262-.019.524-.094.754-.219a19.388 19.388 0 0 0 2.449-3.638c-8.2.511-9.384-5.639-9.558-7.602-.175-1.963.872-4.037.872-4.037s.324-1.097-.106-1.564c-.43-.468-1.308-.549-1.258-.692.043-.149.972-.33 1.302-.368 0 0 .866-2.436 2.879-2.199 2.006.237 3.669.903 5.427 5.352h-.013l-.019-.018Z"
      />
    </G>
  </Svg>
);

Environment info
expo 48

Library version: 13.4.0
Steps To Reproduce
Describe what you expected to happen:

copy the above code
view on android and ios. you'll see a bird appear on ios but not on android
remove the G tag and both platforms show the same content.

Hello @MorganDavid,
I tried to reproduce that issue, but couldn't.

Android
IOS

Let me know if you still have that issue. Try to update react-native-svg library.
Thank you


Please add output for finished metadata processing

When I use the appropriate option from the command palette I see in the output pane:

Starting to process metadata from workspace folders (on demand)

... and then nothing more. therefore I'm not sure there's actually anything done. Is it?
Can you please:

output the current folder (if that information is reasonably available) that is processed
add a final "workspace processed in xyz seconds"

In case there is something like this in 6.6.40 - how can I debug why this doesn't happen?

Fyi - If the overall time is >0.5secs the message is displayed, otherwise it is not.

Good to know. I still suggest to add a "metadata processing finished in n secs" in any case, this way a user knows that something did happen.

Thanks, despite the "extra" directories it shows (see #194) I can now see every folder is parsed as expected and get a final output of "Completed scanning all COBOL files in workspace              (3755.00ms)"
Works!

Rechecked with 6.7.0, the output is still there, but it only gets shown all at once (at least with vscode 1.48.0), so I've stared it twice (the first time needed 114574ms [non-cached file access], the additional ones take ~5 seconds).
Previously (I think it was 6.4.3) I've seen "starting to process"... directly, then have seen the folders being printed one by one and then the completion message.
@spgennard Can you please inspect why the printing is now not seen directly?

@GitMensch - It appears to be because I am using async/await, if I remove this the output appears quicker but blocks (as expected)

yay...
First: Thank you for the explanation. second: is there something like an explicit flush we may can use in the async thread?
If not: can the "controller" (that does the wait) do the output for the "worker", then await() again?

I've not found any way of flushing the output to see if this is the reason.
I am going to look and see if I use a different mechanism to show that something is happening in the background.


Beam Enrich: extract into separate repo (closes #4282)

[x] Needed for backporting framework version updates: https://github.com/snowplow/beam-enrich/issues/3
[x] Description on gitflow branching: https://github.com/snowplow-incubator/engineering-resources/pull/15

Part of https://github.com/snowplow-incubator/engineering-resources/issues/8 effort.

Cool! Scheduling for R119!


go specification in go mod requires 1.22.0 syntax now

from 1.22 to 1.22.0 - code scanning (CodeQL) says
"As of Go 1.21, toolchain versions must use the 1.N.P syntax.
1.22 in go.mod does not match this syntax and there is no additional toolchain directive, which may cause some go commands to fail."

Yeah, we know, and we disagree. Using a three-numbered toolchain version makes builds fail locally if you run even a single dot release different. It's ridiculous. We will reevalulate with 1.23 which will reportedly fix some of this mess.


Themes option added to the menu

The theme option with default and dark theme was added to the Airviewer2 menu.  The colors still need to be implemented.

Is there code for the theme options? Because it just shows your commit message and not any code for the options if there was any.

@anitaoranusi There is fxml code for the theme option.  If you click on the title of my commit it should show you.

Is it possible to see before and after screen shot.

Is it possible to see before and after screen shot.

I am not sure if there is a way to do that.

@pabitraale I am not sure if there is a way to do that.

@pabitraale So, the green part is what he added to the file. Everything else that's not green (the white) is what was left unchanged. If he had deleted something, whatever he deleted would be in red

@anitaoranusi There is fxml code for the theme option. If you click on the title of my commit it should show you.

Ah ok, that's my bad. It looks pretty good to me. The code explains itself and doesn't look overly complicated


first iteration on adding an API docs site

start of fix for issue #235
for now, the site is manually generated using grunt docs task and uses
default YUIdoc styles
future iteration should be similar to jekyll site used for EAK - see
https://github.com/stefanpenner/ember-app-kit/tree/gh-pages
future iterations should also include styles that match other Ember
sites

I have the domain rsvpjs.com and would love to get it transferred if someone else would like to take it over. Otherwise right now it is setup for gh-pages. Just add the CNAME file with rsvpjs.com. Thanks!

@williamsbdev sorry, i keep meaning to give you the info to transfer it. What would be easiest?

No worries! I've honestly never transferred a domain before so I'm assuming I just need to know where to transfer it. I'll work with Hover to get that done.

https://rsvpjs.com now points to this repo's GH pages. thanks to @williamsbdev
one step closer

what ever happened to this? The https://rsvpjs.com URL seems to be down. I had a question about race which I was able to figure by myself but it appeared that this documentation might have answered this. :)

There is no SSL. it is simply http://rsvpjs.com. Since there is no index.html, GH pages does not have anything to supply for this domain. If we were to submit a PR with an index.html, that would get this repo going.

I think this may have become less relevant since the API docs are also part of the Ember API docs: http://emberjs.com/api/classes/RSVP.html
But I think there's merit in getting proper docs up, as the Ember site doesn't cover most of the modules within rsvp/*. I had to delve into the source to get documentation recently.

I would think the primary function of having docs on the rsvpjs.com site is to help nodejs users rather than Ember developers. Regardless, a single source seems a good idea and maybe we could:

abandon the separate RSVP website
update the README to point to Ember's docs
update Ember docs to give full RSVP coverage
possibly also have a section that just mentions nodejs/backend use cases

Just chiming in to see if people would like me to renew the domain. I got an email about the automatic renewal in a couple months. If we think just adding to the Ember docs is a viable option, I will not renew the http://rsvpjs.com domain.


Ensure correct Addressing and Memory model set for WebGPU

Adding validation that the addressing declared by OpMemoryModel is
Logical and the memory model declared is VulkanKHR.
Fixes #2060

Failing smoke tests are not related to my PR/known bad.


[Create news page] 'Publish' button is enabled when no tag is selected while creating a news item #505

#505
Steps to reproduce:

Go to 'Eco news' page ( https://ita-social-projects.github.io/GreenCityClient/#/news).
Click on 'Create news' button.
Enter valid data into the 'Title' field (no more than 170 characters: capital and lower case letters/ numbers/ special characters) (e. g.: "Be eco! Be cool!").
Enter valid data into the 'Content' field (no less than 20 characters: capital and lower case letters/ numbers/ special characters) (e. g.: "It's so healthy, fun and cool to bring eco habits in everyday life").

Actual result:
'Publish' button is enabled.
Expected result:
'Publish' button should be disabled.

Verified


Release 2.3

Just updated to 2.2.4, but the balance transaction mocking isn't included in the release. Looks like potentially 2.2.4 was cut before the merge based on the tag being 2 commits behind master (https://github.com/rebelidealist/stripe-ruby-mock/releases/tag/v2.2.4)? Should we release 2.3 here since this isn't a patch release?

look at this https://github.com/rebelidealist/stripe-ruby-mock#versioning-system
As I understand your changes should be in 2.2.x. But Stripe updates #335 2.3.0. Sorry, your PR wasn't included to 2.2.4 what if we include it in 2.2.5 ?

@alexmamonchik ah, okay, I was thinking of semantic versioning for the gem itself. this is pretty different style. in this case, 2.2.5 release would make sense for the BalanceTransaction API addition.


Question : SignedJar::verify_result

Hello,
After having spent a bit of time hunting for a bug due to mis-decoding on my side I wonder why the SignedJar::_verify method is not exposed publicly ?
It would have saved me a bit of time with its comprehensive error message.
It's absolutely not a critic though, I was just wondering.

In general we want to avoid leaking any kind of information when performing sensitive cryptographic operations. The danger here would be that a consumer of the verify() API would make decisions based on the error value and, in doing so, leak more information than they intend. Said another way, we want to restrict consumers to making decisions based on a single bit of information, success or failure, and nothing beyond that.
I'm not sure what your familiarity is with cryptographic operations, so I apologize if you're already aware of the above. Irrespective, this is a conservative approach to security.

After having spent a bit of time hunting for a bug due to mis-decoding on my side

What error did you make on your side? Is there something we could have done to more aptly prevent the error in the first place?

I totally can hear that. And my little adventure of yesterday shows me that I should not overestimate my own knowledge 😄.

What error did you make on your side? Is there something we could have done to more aptly prevent the error in the first place?

Did not realize that my cookie was percent-encoded. But I am mostly using libs that expose wrappers around yours (axum_extra and reqwest).
I am using cookie-rs in tests to perform some validations and setup tasks.
To be fully honest, I am not sure what kind of bad decisions you would expect some dev to make with that error, but I guess us developers are quite creative in messing things up!


ML 8.17 : Lines (Hough) and Edge Detection (Filters) (A)

Description
📌  Issues for Week 8
Welcome to 'ML' Team, good to see you here
:arrow_forward: This issue will helps readers in acquiring all the knowledge that one needs to know about ----
Lines (Hough) and Edge Detection (Filters).
:red_circle: To get assigned to this issue, add your Batch Numbers mentioned in the spreadsheet of "Machine Learning", the approach one would follow and choice you prefer (Documentation, Audio, Video). You can go with all three or any number of options you're interested to work on.
✔ Domain : Machine Learning
:red_circle::yellow_circle: Points to Note :

The issues will be assigned on a first come first serve basis, 1 Issue == 1 PR.

"Issue Title" and "PR Title should be the same. Include issue number along with it.

Changes should be made inside the Machine Learning/Machine_Learning/ML_for_Seqential_Data_&_Visual_Data Branch.

Follow Contributing Guidelines & Code of Conduct before start Contributing.

This issue is only for 'GWOC' contributors of 'Machine Learning' domain.

:white_check_mark: To be Mentioned while taking the issue :

Full name
Batch Number
GitHub Profile Link
Which type of Contribution you want to make :

[ ] Audio

Happy Contributing 🚀
All the best. Enjoy your open source journey ahead. 😎
Domain
Machine Learning
Type of Contribution
Audio
Code of Conduct

[X] I follow Contributing Guidelines & Code of conduct of this project.

I would like to work on this issue
Name- Nayanika Mishra
Batch Number- 3
GitHub Profile Link- https://github.com/Nay907
Type of Contribution: Audio

What's the progress here @Nay907

I will complete it today!

Make sure you make the PR by EOD @Nay907


Add nanmedian_along_seq to BatchedTensorSeq

Codecov Report
Patch coverage: 100.00% and no project coverage change.

Comparison is base (8c00246) 100.00% compared to head (139bf09) 100.00%.

Additional details and impacted files
@@            Coverage Diff            @@
##              main      #223   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            6         6
  Lines          911       913    +2
  Branches        81        81
=========================================
+ Hits           911       913    +2

Impacted Files
Coverage Δ

src/redcat/tensor.py
100.00% <ø> (ø)

src/redcat/tensorseq.py
100.00% <100.00%> (ø)

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


objstore: Provide the correct underlying size in more cases

[ ] I added CHANGELOG entry for this change.
[x ] Change is not relevant to the end user.

Changes

Uploads of the shipper (and thanos tool bucket replicate) showed that the filesize could not be guessed. Look into the timing and tracing wrappers and optionally look into the S3 object as well to get the underlying size.
Verification

Minimal checking with replicate and looking at the uploaded chunks.

Have you seen https://github.com/thanos-io/thanos/pull/3866? (:

Have you seen #3866? (:

Nice. This will avoid having to know minio at the objstore package level. :)


SAML and SAML2 new model validation: Token Replay

SAML and SAML2 new model validation: Token Replay

Adjusted token replay validation in the new validation model to match existing behaviour.
Added comparison tests to ensure the new validation model behaves like the original.

Part of #2711

Looks like the tests are failing? is that expected?

Looks like the tests are failing? is that expected?

Probably not 😄. Apparently when I merged the signature validation code, I mistakenly left the signature validation after the issuer signing key one.
This failure was then hidden by the issue we had with the Abstractions assemblies signature that was failing all builds.
It is fixed now.


Add AWS_SESSION_TOKEN for SQS access

Is your feature request related to a problem? Please describe.
When using AWS SQS with Multi-factor authentication, a AWS_SESSION_TOKEN is needed.

Pull Requests:

https://github.com/Senzing/docker-compose-demo/pull/119


Wrong license in package.json

The license field of package.json is MIT, but Apache-2.0 is defined in the LICENSE file.
Now this usually wouldn't matter, since the licenses are similar (for the most part). But tools like pnpm-licenses partially misinterpret the license to be MIT.
I don't know how much of a legal issue this is, since I've found packages like through that use both. But it just seems like sloppy to me.
Example:

Create a new npm project
Install pnpm
Run pnpm i @pkgjs/parseargs
Run npx pnpm-licenses list -o ./licenses.json
View the licenses.json file.

Result:
[
    {
        "name": "@pkgjs/parseargs",
        "license": "MIT", // Incorrect
        "author": "",
        "homepage": "https://github.com/pkgjs/parseargs#readme",
        "description": "Polyfill of future proposal for `util.parseArgs()`",
        "version": "0.11.0",
        "licenseText": "Apache License\n Version 2.0, January 2004... You get the idea" // Correct
    }
]

That looks like an error in the initial commits. I looked at some other packages under https://github.com/pkgjs and they have Apache license file and "license": "Apache-2.0".
https://github.com/pkgjs/wiby/blob/a777be1032aa829969d8df4e4f696dfbe73616d5/package.json#L26
https://github.com/pkgjs/dependents/blob/c2e17122cfa574a6e20b3df751cf23def8ab9ccc/package.json#L12


operators [CI] community-windows-machine-config-operator (5.0.0)

Signed-off-by: Alina Ryan<EMAIL_ADDRESS>Thanks submitting your Operator. Please check below list before you create your Pull Request.
New Submissions

[ ] Are you familiar with our contribution guidelines?
[ ] Have you packaged and deployed your Operator for Operator Framework?

[ ] Have you tested your Operator in all supported installation modes?
[ ] Have you considered whether you want use semantic versioning order?
[ ] Is your submission signed?
[ ] Is operator icon set?

Updates to existing Operators

[ ] Did you create a ci.yaml file according to the update instructions?
[ ] Is your new CSV pointing to the previous version with the replaces property if you chose replaces-mode via the updateGraph property in ci.yaml?
[ ] Is your new CSV referenced in the appropriate channel defined in the package.yaml or annotations.yaml ?
[ ] Have you tested an update to your Operator when deployed via OLM?
[ ] Is your submission signed?

Your submission should not

[ ] Modify more than one operator
[ ] Modify an Operator you don't own
[ ] Rename an operator - please remove and add with a different name instead
[ ] Modify any files outside the above mentioned folders
[ ] Contain more than one commit. Please squash your commits.

Operator Description must contain (in order)

[ ] Description about the managed Application and where to find more information
[ ] Features and capabilities of your Operator and how to use it
[ ] Any manual steps about potential pre-requisites for using your Operator

Operator Metadata should contain

[ ] Human readable name and 1-liner description about your Operator
[ ] Valid category name1
[ ] One of the pre-defined capability levels2
[ ] Links to the maintainer, source code and documentation
[ ] Example templates for all Custom Resource Definitions intended to be used
[ ] A quadratic logo

Remember that you can preview your CSV here.
--
1 If you feel your Operator does not fit any of the pre-defined categories, file an issue against this repo and explain your need
2 For more information see here

@openshift/openshift-team-windows-containers PTAL

/hold

/cc @openshift/openshift-team-windows-containers

/hold cancel

/merge possible

/hold
to investigate new CI issues

/unhold

/retest-required

/merge possible

/retest-required

/test all

/retest-required VPC limit exceeded on prior tests

DPTP team had temporary issues

@alinaryan, pipeline was not able to install the operator on OCP v4.10. Please test it locally.

/test all

/retest-required VPC limit exceeded on prior tests

DPTP team or aws admins have some issues with their services

pipeline was not able to install the operator on OCP v4.10. Please test it locally.

@J0zi I have tested locally. OCP v4.10 will not pass CI since our operator requires a cluster with hybrid-ovn networking for it to start up properly. This is by design. Will need a manual override for this to merge

/merge possible


Include the b2sum for the original data in the generated PDF file.

This aids in verification:

after creation, that a PDF was created which can be successfully
restored --> see new paperbackup-verify.sh script which in this role
automates the diff step from the README.
after restoration, by manually running b2sum on the restored data
and comparing to the printout, that the restoration has indeed produced
the exact same data as had been in the original file. This step could be
automated as well in the future if we get a "metadata chunk".

Dependencies for paperbackup-verify.sh besides bash: coreutils, pdftotext (from poppler-utils), grep, diff

Thanks for clarifying the need for the additional checksum in the discussion of Pull request #3.
Why do you use b2sum (BLAKE)? We just need the checksumming properties here, no crypto strength. I'd favor the much more common MD5 for that. MD5 has been around for a long time now and stable implementations are available on every platform. So even if blake is well standardized etc., I think md5sum has better availibility and will stick around in the future. CentOS/RHEL 7 for example does not have b2sum. I think the bit-length of md5 is good enough to protect the rather short paperbackup data against clashes.
So I'd prefer if we use md5 instead.
I'd also strip the "which()" and pathfinding code - I think when the user is able to call paperbackup.py in the first place, he should also be able to add ./ or the proper path to a call to paperbackup-verify.sh.
So I'd just output:
Please now verify that the output can be restored by calling:
paperbackup-verify.sh {}.pdf

Why do you use b2sum (BLAKE)?

By using a cryptographically strong hash we empower the user to copy it to a different backup location (which does only need to store that hash securely and not hold a full copy of the backup) and improve the tamper resistance of the backup scheme.

CentOS/RHEL 7 for example does not have b2sum.

AFAICT python v3.6.0rc2 is the minimum required for blake2b and python36-3.6.3 is available via EPEL 7?
I've included a crude --b2sum option into paperbackup.py (until we switch to argparse to clean things up?) and use it instead of the b2sum call in paperbackup-verify.sh now.
Or am I missing the point?

I'd also strip the "which()" and pathfinding code - I think when the user is able to call paperbackup.py in the first place, he should also be able to add ./ or the proper path to a call to paperbackup-verify.sh.

agreed

So I'd prefer if we use md5 instead.

How would you feel to output both md5 and blake2b?

By using a cryptographically strong hash we empower the user to copy it to a different
backup location (which does only need to store that hash securely and not hold a full copy
of the backup) and improve the tamper resistance of the backup scheme.

The objects which paperbackup was initially designed for - crypto keys and chiphertext - are usually already fully integrity protected by the crypto program, e.g. GnuPG, PKCS#8 or PKCS #12.
But if you store other kinds of data with paperbackup a cryptographically secure hash could help.

How would you feel to output both md5 and blake2b?

How about SHA2-256 then? That is also well standardized, considered cryptographically secure and tools like sha256sum are widely available. The hex output still fits into one line on the pdf output.
BLAKE isn't part of the SHA family, so it's adoption and availbility could drop significantly in the future. Remember the history of e.g. Blowfish. It is still considered secure, but AES won the popularity vote by far. I recently saw the first programs removing support for Blowfish.

Done :)

thank you for persevering


Add to this repo's topics: git-server

Perhaps the topics for this repo ought to include git-server (used by 53 repos). (instructions)
Some other topics that may fit:

gitserver (used by 15 repos)
git-gui (used by 25 repos)
git-ui (used by 12 repos)
git-server-docker (used by 7 repos)
git-collaboration (used by 4 repos)

Dubious:

docker-git (used by 3 repos)
git-frontend (used by 1 repos)
git-front-end (not in use)
git-collaboration (used by 4 repos)
github-clone (used by 27 repos)
github-frontend-clone (used by 1 repos)
private-repository (used by 88 repos)
git-manager (used by 4 repos)
git-management (used by 8 repos)
git-remote (used by 14 repos)
git-repo (used by 27 repos)

For future reference, the topics currently associated with this repo are:

github
git
go
golang
devops
gitlab
gogs
gitea
hacktoberfest

Looks like the only people who can change the topics are @go-gitea/technical-oversight-committee…

I added git-server, git-gui, github-clone.

We have stuff GitHub doesn't but yeah

We have stuff GitHub doesn't but yeah

I think it's just a marketing word, there is no too much meaning. :) Gitea have many features GitHub does not have and will have more in future.


Releasing models in torch format

Thanks again for releasing the pre-trained model!
Do you also have a plan to release them in the format loadable from Pytorch (current .bin files are serialized to be read from C)?

Hi, thanks for the issue. I will upload the correct model formats that can be loaded into pytorch in the next day or two, sorry for the incorrect formats before.

The new link in the readme should now point to weights loadable in pytorch.


Remove overallocation in faiss query path

Description
Removes overallocation of 2 c++ vectors in faiss querying functionality.
Performance results can be viewed in 497.
In general, this change could provide a small improvement in memory
footprint during search workloads.
Issues Resolved
#497
Check List

[X] Commits are signed as per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #501 (90ce5df) into main (641614d) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##               main     #501   +/-   ##
=========================================
  Coverage     84.04%   84.04%
  Complexity     1019     1019
=========================================
  Files           146      146
  Lines          4188     4188
  Branches        373      373
=========================================
  Hits           3520     3520
  Misses          492      492
  Partials        176      176

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Remove .nodemonignore file.

Adding configuration files for every tool used will clutter up the repository, especially for a configuration as simple as this.

LGTM!


DUMMY PR DO NOT MERGE ME!

/cc @chenopis @zacharysarah

This change is

seems to be working https://github.com/kubernetes/kubernetes.github.io/pull/4698#event-1198225462


Update layers/meta-balena digest to ead4a8f

This PR contains the following updates:

Package
Update
Change

layers/meta-balena
digest
0e8423f -> ead4a8f

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

Can one of the admins verify this patch?


Palm Check/Touch Pad Insulator

Description of the new feature / enhancement
Disable the touch pad while typing. The Windows option to lower sensitivity of the touch pad does not work well. And, now that laptop touch pads are gigantic, my palms cannot avoid touching the touch pad. Each time my palm inadvertently touches the touch pad, my cursor moves and the text I'm typing appears in a different place than intended. Worse yet, sometimes both palms touch and I accidentally highlight and type over several sentences at a time. It's a nightmare to draft and edit long letters and emails. Disabling the touch pad while typing would be a great addition.
Scenario when this would be used?
This tool will be used primarily on laptops with touch pads to prevent inadvertent touches of the touch pad from moving the cursor while typing.
Supporting information
No response

I also desperately need this new feature. My laptop doesn't have a shortcut key to temporarily disable the touchpad set by the OEM manufacturer, and it's very easy to accidentally touch it when typing. Although there is an option in Windows settings to "disable touchpad when mouse is connected", it is not always convenient for me to use the mouse. Adding disabling or lowering the touchpad sensitivity while typing solves the problem. Or a shortcut can be set to manually enable/disable the touchpad

This would be best part of PT


Sign transactions not fitting the wallet policy approach

A number of issues were opened to request signing in cases that don't fit the wallet policy model:

#153
#197
#205

This issue tries to generalize the problem. How do we safely sign transactions outside of the model of wallet policies?
Wallet policies
Wallet policies build on top of Output Script Descriptors to model in a sound way what software wallets typically call an account.
Whether single-sig, multisig, musig, miniscript, etc, for most software wallets, an account is exactly: a list of receiving addresses, plus a list of change addresses.
Wallet policies in hardware signers
Wallet policies are a first class citizen in the Ledger bitcoin app (and similar specs have now been implemented in the BitBox02, and in Blockstream Jade via the Wally library).
The signing API is currently similar to sign(psbt, wallet_policy) (plus the wallet_policy_hmac, not relevant for this discussion), which means that the "wallet policy" is additional information on top of just the transaction being signed, represented in the psbt. (in principle, the wallet policy itself could be added to the psbt; however, there is no standard for it).
Having precise knowledge of "what account" you are receiving to, or spending from, allows to strengthen the security model quite substantially, as malware in the in the software wallet can't tamper with that information. In practice, the expectation is that people will have multiple accounts, and many of them will involve multiple keys (other co-signers). Wallet policies allow you to know exactly from which account you're spending. That's important: if you have a 2-of-2 with your wife, and another 2-of-2 with your colleague at work, it's not enough to know that you're "spending 0.1 btc and sending it to bc1pxxx..", you want to know that you're "spending 0.1 from your work account and sending it to bc1pxxx". Without that, if your co-worker gets access to your computer, it's trivial for them to install malware to trick you to spend your wife's money when you think you're using the company account. Of course, this inherently requires full knowledge of the script on the hardware signer's end, including all of the cosigner's xpuOne would also have to think abs.
With wallet policies, the device can inform you that you're spending from the account named Cold storage (for example):

The hardware signer can use the information in the psbt, plus the knowledge of the wallet policy, to:

make sure that the change output is going to the right place [*];
inform what account you're receving to / spending from;
possibly, simplify the UX for known outputs. For example, if you know that you're sending to another of your accounts (or even some known external account), its descriptive name could be shown along – or instead – of the output address); this is not currently implemented.

In other words: wallet policies allow strict account segregation: the hardware device can guarantee that you're not touching any other account (as long as you take care to register different policies under different names, of course).

[*] In principle, before taproot, this doesn't strictly require wallet policies, as the descriptor could be "decompiled" from the witnessScript; this is no longer true in taproot trees, however, as the [PSBT](https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki) does not contain enough information (knowledge of how to generate the entire taptree, for any address index, is necessary).

Safe signing outside of wallet policies
While wallet policies themselves could possibly be generalized to cover some use cases that are not currently represented by the BIP proposal, it's clear that there are other situations that just don't fit in this model of signing for an account: not all UTXOs are meaningfully part of an account as it can be represented in wallet policies.
UX considerations
Allowing signing behaviors that go outside the model of wallet policies would likely break the strong account segregation guarantee above.
That might be fine, as long as it doesn't happen seamlessly: the user must know that they are stepping somewhat outside of the safe zone. Possible options:

a prominent warning with explicit user confirmation required
signing for such transaction must be explicitly enabled in the settings of the app (1 time action where the user can properly be warned).

Another option that could be worth investigating is to attach the "unsafe signing behavior" to specific keys. That is, one could register a special kind of "wallet policy" (to be defined) that means "for these internal xpubs, allow unsafe signing". That would allow to keep the strong account segregation guarantees for any other xpubs, as long as the user is diligent in not reusing xpubs for different purposes. The downside is, of course, that software walltes would need to be aware and explicitly opt-in to this approach, which makes integrations somewhat harder.
What's safe to sign, if you don't have wallet policies?
This is to be defined, and knowing the desired use cases would help. (Note that this is about finding general approached to signing that work for many use cases; nothing works for all use cases, and for specific applications, a separated customized app would be a better approach)
For transactions signed with SIGHASH_ALL, one case that would generally be safe (apart from not having the strong account segregation property mentioned above) is if:

there is no change output (all outputs are shown to and verified by the user)
all inputs are assumed to be internal.

@bigspider first of all, thanks for this issue, really waiting for this possibility to be opened
Regarding taproot trees - won’t it be possible to pass the whole taproot tree construction with normal public keys (not xpubs)? What is the disadvantage of this approach in comparison to other methods like unsafe confirmations and so on?

@bigspider first of all, thanks for this issue, really waiting for this possibility to be opened Regarding taproot trees - won’t it be possible to pass the whole taproot tree construction with normal public keys (not xpubs)?

In wallet policies, the restriction of having ranged xpubs (with distinct derivations) is explicitly kept even across leaves.
While it might not seem as bad as in segwit scripts (where it messes with miniscript non-malleability guarantees, for example), the key reuse problem is still there: if you receive on multiple addresses of the same wallet account, and then you want to spend these different UTXOs using a leaf that contains a fixed pubkey, you will reveal the pubkey, allowing an external observer to trivially correlate all those spends.
Generating pubkeys is cheap, so an external co-signer that is able to provide a fixed pubkey can easily be generalized to instead provide an xpub, which solves the key-reuse problem.
Of course, this is not an issue if instead of a "wallet account" (that can receive/send many transactions), you have a single UTXO, that you will spend entirely without a change address; but that's not the scope of wallet policies.

What is the disadvantage of this approach in comparison to other methods like unsafe confirmations and so on?

Not sure I understand what you mean by "other methods like unsafe confirmations".

@bigspider thanks a lot for your reply, now it's clear
One question in this case appears
We're using taproot leaf scripts (told above), but not using an internal public key at all. Instead of an internal public key, we generate a MuSig public key with all owners merged, which makes it even harder for us to provide xpubs even if we convince all other wallet developers to provide it on connection, which is at least possible.
What is the best way to handle it with the current Ledger wallet policy? Thank you again

@bigspider thanks a lot for your reply, now it's clear One question in this case appears We're using taproot leaf scripts (told above), but not using an internal public key at all. The internal public key is still important for the whole taptree construction. Instead of an internal public key, we generate a MuSig public key with all owners merged, which makes it even harder for us to provide xpubs even if we convince all other wallet developers to provide it on connection, which is at least possible. What is the best way to handle it with the current Ledger wallet policy? Thank you again
P.s. in this case we don't care about revealing this Internal pubkey to anyone since it is not being used, but we really bother about not having a real internal public key which could've spent everything from the multisig wallet.

In theory, using the syntax for the musig() key expressions drafted here, it would be possible to take a descriptor like
tr(musig(xpub1, xpub2,xpub3)/<0;1>/*, taptree)

and replace it with:
tr(aggr_xpub/<0;1>/*, taptree)

where aggr_xpub is musig(xpub1, xpub2,xpub3). The Ledger app is of course not able to participate to the musig signing as of yet.
Instead, if you want the public key path to really be unspendable, it is not difficult to produce an xpub such that there is (provably) no private key. Then you can use tr(unspendable_xpub/<0;1>/*, taptree).
Of course, the Ledger app doesn't know that this xpub is unspendable, and will therefore show it among the other xpubs during registration; that's not great in terms of UX, but it works.
This has security implications, though: the fact the the aggregate/unspendable xpub is produced in a certain way is not verifiable from the device, so additional measures should be in place in the software wallet to guarantee that the xpub is not replaced with some attacker's xpub (for example, by malware on the user's machine).
The appropriate fix would be to define a key expression for the descriptor language that describes an unspendable key. Then you could do something like:
tr(unspendable(something), taptree)
Once such a standard exists, the UX could be simplified somewhat, as the fact that the key generated by unspendable(something) is indeed unspendable can be verified by the device.

@bigspider another point to consider
currently, all extension wallets (at least extensions) use the same account xpub to generate all public keys and addresses, and in this case, users won't likely want to reveal this xpub to applications considering the same privacy concerns, which is even more severe than linking public keys on signatures, since every single address will be revealed.
What is your opinion on that? Except for changing the overall wallet address deriving flow, which is unlikely ever gonna work for already established wallets

@fess-v could you describe the kind of descriptors and/or signing flow that such extension wallets are using? I'm not familiar so it's hard to give an informed reply.

Not sure I understand; if you're not willing to reveal the descriptor, likewise you're not willing to reveal the wallet policy.
If the limitation is because some systems are designed around address reuse, unfortunately wallet policies specifically want to not allow that, or at least not incentivize it.

@bigspider when we develop a wallet, we encounter an issue that we could only got psbt from other app, but it seems it is impossible to get enough info from psbt to generate related wallet policy which will cause ledger device could not sign psbt. I think a interface that could blind sign taproot transaction is needed.

Thank you for raising this important issue. We strongly agree that there's a pressing need to expand Ledger's signing capabilities beyond the current wallet policy model, particularly to support the growing Bitcoin DeFi ecosystem.
While the wallet policy model provides robust security for standard transactions, it creates significant limitations for more complex operations like multi-signature setups, which are fundamental to many DeFi protocols. This restriction effectively creates a divide between Ledger users and those using hot wallets, hindering the growth of a unified, permissionless DeFi ecosystem on Bitcoin.
We appreciate the security considerations you've outlined, especially regarding account segregation and user awareness. Your suggestions for handling transactions outside the wallet policy model, such as prominent warnings or opt-in settings, are valuable starting points.
However, we believe a more comprehensive solution is needed. Perhaps a system similar to Ethereum's signing plugins could be implemented, allowing for greater flexibility while maintaining user awareness and security. This approach could potentially bridge the gap between Ledger's security model and the needs of complex DeFi applications.
We'd like to emphasize that addressing this issue is crucial not just for individual use cases, but for the broader adoption and development of Bitcoin-based DeFi. A solution that allows Ledger users to participate fully in these protocols while maintaining strong security would significantly contribute to the growth of the ecosystem.
We're eager to collaborate on finding a solution that balances security with the flexibility required for advanced Bitcoin applications. This could potentially involve developing new standards for representing complex transactions or exploring ways to extend the wallet policy model to encompass a wider range of use cases.


fix(sysfs,udev): add additional verbose logs in udev probe

Signed-off-by: Akhil Mohan<EMAIL_ADDRESS>Why is this PR required? What issue does it fix?:
To add more verbose information into NDM daemon logs.
What this PR does?:

add more verbose logs in udev probe
log errors from sysfs package

Does this PR require any upgrade changes?:
No
If the changes in this PR are manually verified, list down the scenarios covered::
Any additional information for your reviewer? :
Mention if this PR is part of any design or a continuation of previous PRs
This PR can be treated as a continuation of #489
Checklist:

[ ] Fixes #
[x] PR Title follows the convention of  <type>(<scope>): <subject>
[ ] Has the change log section been updated?
[ ] Commit has unit tests
[ ] Commit has integration tests
[ ] (Optional) Are upgrade changes included in this PR? If not, mention the issue/PR to track:
[ ] (Optional) If documentation changes are required, which issue on https://github.com/openebs/openebs-docs is used to track them:

Codecov Report

Merging #498 into master will increase coverage by 0.17%.
The diff coverage is 86.20%.

@@            Coverage Diff             @@
##           master     #498      +/-   ##
==========================================
+ Coverage   47.10%   47.28%   +0.17%
==========================================
  Files          73       73
  Lines        3235     3255      +20
==========================================
+ Hits         1524     1539      +15
- Misses       1560     1563       +3
- Partials      151      153       +2

Impacted Files
Coverage Δ

api-service/node/services/listBlockDevice.go
4.46% <0.00%> (ø)

pkg/udevevent/event.go
86.11% <0.00%> (ø)

cmd/ndm_daemonset/probe/udevprobe.go
60.49% <90.90%> (+4.15%)
:arrow_up:

pkg/sysfs/syspath.go
82.78% <100.00%> (ø)

cmd/ndm_daemonset/probe/eventhandler.go
37.77% <0.00%> (-6.67%)
:arrow_down:

Continue to review full report at Codecov.

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


github-annotations-with-api

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (a5350b1) 83.54% compared to head (43acde6) 83.54%.
 Consider uploading reports for the commit aef3e99 to get more accurate results

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #452      +/-   ##
==========================================
- Coverage   83.54%   83.54%   -0.01%
==========================================
  Files         217      217
  Lines       12536    12534       -2
==========================================
- Hits        10473    10471       -2
  Misses       1688     1688
  Partials      375      375

Flag
Coverage Δ

unittests
83.54% <100.00%> (-0.01%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


How can I use in wechat small program?

Can you give me a guide?

@daejong123 This is a web app, so if wechat small program supports javascript it should work. Feel free to fork and play around it to learn more.


Adds performance annotations using the new Hatchet annotation interface

This PR adds performance measurement annotations to Thicket using the APIs added to Hatchet in LLNL/hatchet#142.

Thanks for taking a look @michaelmckinsey1. That timing info is very interesting. I definitely agree that the annotations need to be paired down given the timing.


Ensure normalization doesn't happen for all-zero pulse height channels

What is the purpose of this PR?
Closes #307. When the pulse heights for a particular mass are all zero, normalization will fail, specifically during the outlier calculations. We'll need to be careful about how we handle all-zero masses further down the pipeline as well, because we need to account for divisions by zero.
How did you implement your changes
Four changes were made in normalize.py:

create_fitted_pulse_heights_file: if we detect that all mph_vals for a particular mass is zero, we display a warning to the user and skip fit_mass_mph_curve. This also means we won't have a _norm_func.json file for this particular mass, which leads to...
create_fitted_mass_mph_vals: if a particular mass doesn't have a corresponding _norm_func.json file, we set pulse_height_df.loc[mass_idx, 'pulse_height_fit'] to 0. and move on.
normalize_image_data: prior to passing pulse_height_fov['pulse_height_fit'].values into norm_func, we have to suppress warnings with the following:

with warnings.catch_warnings():
    warnings.simplefilter("ignore")

because passing a pulse_height_fit of 0. into a log function will throw a numpy warning that we don't want to get displayed several times to the user. Later, we do correct for any np.inf, -np.inf, and np.nanvalues that get spit out bynorm_func`, defaulting them to 0.

normalize_fov: to prevent divisions from 0 causing np.inf, we explicitly use the following:

normalized_images = np.divide(
    img_data, norm_vals.reshape((1, 1, 1, len(norm_vals))), out=np.zeros_like(img_data, dtype=img_data.dtype), where=norm_div != 0
)

Remaining issues
We'll need to get @dtebaykin to test this out, since he was the one who originally opened this issue.

@ngreenwald as mentioned, I'll be asking Dmitry to test out this PR as well.

Dmitry has tested this out and given the green light.