Support Falco running with sandboxed runtimes

Motivation
Falco is great. I want Falco. But I also want to run the workload using a sandboxed runtime like kata containers.
Feature
It'd be awesome to be able to run either the kernel module or eBPF inside the guest kernel and have this available for Falco on the host. From taking a quick look @ https://sysdig.com/blog/understanding-common-library-implementation/, I'm hopeful that this is feasible, and we could have SCAP <-> sinsp communication occur over vsock between the guest/host.
Alternatives
I have to choose either Falco or sandboxed runtime.
Additional context
I haven't spent a lot of time yet looking through Falco yet, but before investing I am interested in high-level feedback like:

"Yes, this is a good idea, very straight-forward"
"no this doesn't make any sense"
something in between.

+1 this - we run a lot of gVisor workloads because they're higher risk, and so getting insights into these would be awesome

I think this is something we should discuss during our community call.
Please join us if you want!

Hi,
I'm also very interested in this feature request.
Any update information?

I'll join a future community call.  Thanks @leogr !

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale

Has there been any discussion or movement on this?

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle rotten

I'm also very interested in seeing it happen. Is there a community call every week?

Indeed there is. :)
Every Wed. More details at https://github.com/falcosecurity/community
On Fri, 23 Apr 2021 at 09:17 Peng Tao @.***> wrote:

I'm also very interested in seeing it happen. Is there a community call
every week?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/falcosecurity/falco/issues/1413#issuecomment-825448178,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAA5J42VFI5EQN2Q6FYO53DTKENJTANCNFSM4RYRVE6A
.

--
L.

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://github.com/falcosecurity/community.
/close

@poiana: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://github.com/falcosecurity/community.
/close

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

/reopen

@lining2020x: You can't reopen an issue/PR unless you authored it or you are a collaborator.

In response to this:

/reopen

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

/remove-lifecycle rotten

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale

/remove-lifecycle stale

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale

/remove-lifecycle stale

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale

/remove-lifecycle stale

cc @LucaGuerra

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale

/remove-lifecycle stale
cc @FedeDP

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale

/remove-lifecycle stale

/help

@leogr:
This request has been marked as needing help from a contributor.
Please ensure the request meets the requirements listed here.
If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

/help

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

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale

/remove-lifecycle stale

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle rotten

/remove-lifecycle stale
/remove-lifecycle rotten

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale

/remove-lifecycle stale

Hi, I wanted to ask if this feature is on the roadmap. I would appreciate any feedback you may have.

Feature

It'd be awesome to be able to run either the kernel module or eBPF inside the guest kernel and have this available for Falco on the host. From taking a quick look @ https://sysdig.com/blog/understanding-common-library-implementation/, I'm hopeful that this is feasible, and we could have SCAP <-> sinsp communication occur over vsock between the guest/host.

Hi, I wanted to ask if this feature is on the roadmap. I would appreciate any feedback you may have.

Hey @roshaaaan at the moment we just support Gvisor, we don't have anything planned in the roadmap about this topic but this is for sure something we are interested in!

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale

/remove-lifecycle stale

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale

/remove-lifecycle stale

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale

/remove-lifecycle stale


Accept user-defined ID input in sm2

The computation of z in sm2/mod.rs assumes some fixed user ID. I believe this is not in accordance to the standard of sm2 and so we need modification.
fn get_z(q: PubKey) -> [u32; 8] {
    let _len: usize = 2 + 14 + 6 * 32;
    let mut s: [u32; 52] = [0; 52];

    s[0] = 0x00D00102;
    s[1] = 0x03040506;
    s[2] = 0x0708090A;
    s[3] = 0x0B0C0D0E;
    ...
}

E.g., in the example shown in the document, ID is ALICE123@YAHOO.COM(in hex 414C 49434531 32334059 41484F4F 2E434F4D).
Reference

sm2 standard

You’re right. Let’s follow the standard.


D3 packages are incompatible with Node projects that use "type": "module"

I hope this is the right place to open this issue, as it's something that affects all d3-* packages as well as d3 itself. Please redirect me if not!
I've created a repo to provide a playground (where you can for example npm link a copy of d3-dsv with the proposed changes to see it working); this issue is a copy of that repo's README.

As of Node 12 (which is to say all maintained Node versions bar 10, which reaches EOL in April), it's possible for a Node project to use native JavaScript modules by adding the following to package.json:
{
  "type": "module"
}

Let's say you're making such a project, and you want to use (say) d3-dsv, and for extra points you're using TypeScript, so that your package.json looks like this...
{
  "devDependencies": {
    "@types/d3-dsv": "^2.0.1",
    "@types/node": "^14.14.28",
    "typescript": "^4.1.5"
  },
  "dependencies": {
    "d3-dsv": "^2.0.0"
  },
  "type": "module"
}

...and your tsconfig.json looks like this:
{
  "compilerOptions": {
    "allowJs": true,
    "moduleResolution": "node",
    "noEmit": true
  }
}

In a JavaScript file, which has // @ts-check at the top to enable typechecking, you import d3-dsv but discover that TypeScript yells at you:

According to @types/d3-dsv, there's no default export — you need to use named imports instead. So we switch to using a * import, and now we get nice autocomplete...

...and typechecking:

But when we run the program, it fails:

That's because Node believes that d3-dsv is a CommonJS package. When CommonJS is imported from ESM, Node treats module.exports as the default export. In other words, @types/d3-dsv disagrees with d3-dsv itself about what it exports.
It's not just TypeScript though — d3-dsv disagrees with itself about its exports. That's because (like all D3 packages) it follows the well-established convention of providing both pkg.main and pkg.module...
{
  "main": "dist/d3-dsv.js",
  "module": "src/index.js"
}

...which means that Node can ingest the CommonJS distributable version, while bundlers like Rollup ingest the modern source code. These bundlers, like TypeScript, expect to find named exports:

In other words, if you're using native JavaScript modules, you have a choice: you can write D3 programs that run in Node, or you can write D3 programs that typecheck and can be bundled. You can't do both.
We can fix this!
Luckily this is easily solved, with one small caveat: we add "type": "module" to the package.json files in each package, alongside "exports" (which is how Node resolves e.g. d3-dsv to node_modules/d3-dsv/src/index.js):
  "main": "dist/d3-dsv.js",
  "unpkg": "dist/d3-dsv.min.js",
  "jsdelivr": "dist/d3-dsv.min.js",
  "module": "src/index.js",
+ "type": "module",
+ "exports": {
+   "./package.json": "./package.json",
+   "import": "./src/index.js",
+   "require": "./dist/d3-dsv.js"
+ },
  "bin": {

A new file, dist/package.json, allows the existing dist/*.js files to continue being treated as CommonJS (i.e. this cancels out the "type": "module":
{
  "type": "commonjs"
}

(In future, it might even be possible to get rid of the dist folder once native modules are universally adopted alongside import maps etc, but I'm not suggesting that any time soon given how D3 is used in the wild.)
The caveat is that this is technically a breaking change requiring a semver major release, since someone might currently be using these packages via import and would expect to be able to continue using the default import. We're talking about fairly extreme early adopters who can probably adapt very easily, and you could argue that the current behaviour is buggy and therefore can be fixed in a patch version. But if it was deemed necessary to support those users, it could be done in a non-breaking way by adding a default export alongside the named exports. For example:
-export {default as dsvFormat} from "./dsv.js";
-export {csvParse, csvParseRows, csvFormat, csvFormatBody, csvFormatRows, csvFormatRow, csvFormatValue} from "./csv.js";
-export {tsvParse, tsvParseRows, tsvFormat, tsvFormatBody, tsvFormatRows, tsvFormatRow, tsvFormatValue} from "./tsv.js";
-export {default as autoType} from "./autoType.js";
+import {default as dsvFormat} from "./dsv.js";
+import {csvParse, csvParseRows, csvFormat, csvFormatBody, csvFormatRows, csvFormatRow, csvFormatValue} from "./csv.js";
+import {tsvParse, tsvParseRows, tsvFormat, tsvFormatBody, tsvFormatRows, tsvFormatRow, tsvFormatValue} from "./tsv.js";
+import {default as autoType} from "./autoType.js";
+
+export {dsvFormat, csvParse, csvParseRows, csvFormat, csvFormatBody, csvFormatRows, csvFormatRow, csvFormatValue, tsvParse, tsvParseRows, tsvFormat, tsvFormatBody, tsvFormatRows, tsvFormatRow, tsvFormatValue, autoType};
+
+export default {dsvFormat, csvParse, csvParseRows, csvFormat, csvFormatBody, csvFormatRows, csvFormatRow, csvFormatValue, tsvParse, tsvParseRows, tsvFormat, tsvFormatBody, tsvFormatRows, tsvFormatRow, tsvFormatValue, autoType};

Thanks for reading this far! Obsessing over details like these is no-one's idea of a good time. However, now that the shift to a native module ecosystem is well and truly underway, more and more people will start to encounter these issues, and steps like these can minimise the frustration they experience.
D3 has shown impressive leadership in this area in the past and played a crucial role in helping to shift the JS ecosystem towards native modules, so this feels like a natural next step. Onward!

the repo link is broken.
https://raw.githubusercontent.com/Rich-Harris/d3-modules
Em ter., 16 de fev. de 2021 às 20:07, Rich Harris<EMAIL_ADDRESS>escreveu:

I hope this is the right place to open this issue, as it's something that
affects all d3-* packages as well as d3 itself. Please redirect me if not!
I've created a repo
https://raw.githubusercontent.com/Rich-Harris/d3-modules to provide a
playground (where you can for example npm link a copy of d3-dsv with the
proposed changes to see it working); this issue is a copy of that repo's
README.
As of Node 12 (which is to say all maintained Node versions bar 10, which
reaches EOL in April), it's possible for a Node project to use native
JavaScript modules by adding the following to package.json:
{
"type": "module"
}
Let's say you're making such a project, and you want to use (say) d3-dsv,
and for extra points you're using TypeScript, so that your package.json
looks like this...
{
"devDependencies": {
"@types/d3-dsv": "^2.0.1",

"@types/node": "^14.14.28",

"typescript": "^4.1.5"

},
"dependencies": {
"d3-dsv": "^2.0.0"

},
"type": "module"
}
...and your tsconfig.json looks like this:
{
"compilerOptions": {
"allowJs": true,

"moduleResolution": "node",

"noEmit": true

}
}
In a JavaScript file, which has // @ts-check at the top to enable
typechecking, you import d3-dsv but discover that TypeScript yells at you:
[image: Code with TypeScript error message]
https://raw.githubusercontent.com/Rich-Harris/d3-modules/main/images/no-default-export.png
According to @types/d3-dsv, there's no default export — you need to use
named imports instead. So we switch to using a * import, and now we get
nice autocomplete...
[image: TypeScript-powered autocomplete]
https://raw.githubusercontent.com/Rich-Harris/d3-modules/main/images/autocomplete.png
...and typechecking:
[image: TypeScript-powered typechecking]
https://raw.githubusercontent.com/Rich-Harris/d3-modules/main/images/typechecking.png
But when we run the program, it fails:
[image: Error message]
https://raw.githubusercontent.com/Rich-Harris/d3-modules/main/images/failure.png
That's because Node believes that d3-dsv is a CommonJS package. When
CommonJS is imported from ESM, Node treats module.exports as the default
export. In other words, @types/d3-dsv disagrees with d3-dsv itself about
what it exports.
It's not just TypeScript though — d3-dsv disagrees with itself about
its exports. That's because (like all D3 packages) it follows the
well-established convention of providing both pkg.main and pkg.module...
{
"main": "dist/d3-dsv.js",
"module": "src/index.js"
}
...which means that Node can ingest the CommonJS distributable version,
while bundlers like Rollup ingest the modern source code. These bundlers,
like TypeScript, expect to find named exports:
[image: Rollup error message]
https://raw.githubusercontent.com/Rich-Harris/d3-modules/main/images/rollup-error.png
In other words, if you're using native JavaScript modules, you have a
choice: you can write D3 programs that run in Node, or you can write D3
programs that typecheck and can be bundled. You can't do both.
We can fix this!
Luckily this is easily solved, with one small caveat: we add "type":
"module" to the package.json files in each package, alongside "exports"
(which is how Node resolves e.g. d3-dsv to
node_modules/d3-dsv/src/index.js):
"main": "dist/d3-dsv.js",
"unpkg": "dist/d3-dsv.min.js",
"jsdelivr": "dist/d3-dsv.min.js",
"module": "src/index.js",

"type": "module",

"exports": {

"import": "./src/index.js",

"require": "./dist/d3-dsv.js"

},
"bin": {

(In future, it might even be possible to get rid of the dist folder once
native modules are universally adopted alongside import maps etc, but I'm
not suggesting that any time soon given how D3 is used in the wild.)
The caveat is that this is technically a breaking change requiring a
semver major release, since someone might currently be using these packages
via import and would expect to be able to continue using the default
import. We're talking about fairly extreme early adopters who can probably
adapt very easily, and you could argue that the current behaviour is buggy
and therefore can be fixed in a patch version. But if it was deemed
necessary to support those users, it could be done in a non-breaking way by
adding a default export alongside the named exports. For example:
-export {default as dsvFormat} from "./dsv.js";
-export {csvParse, csvParseRows, csvFormat, csvFormatBody, csvFormatRows, csvFormatRow, csvFormatValue} from "./csv.js";
-export {tsvParse, tsvParseRows, tsvFormat, tsvFormatBody, tsvFormatRows, tsvFormatRow, tsvFormatValue} from "./tsv.js";
-export {default as autoType} from "./autoType.js";
+import {default as dsvFormat} from "./dsv.js";
+import {csvParse, csvParseRows, csvFormat, csvFormatBody, csvFormatRows, csvFormatRow, csvFormatValue} from "./csv.js";
+import {tsvParse, tsvParseRows, tsvFormat, tsvFormatBody, tsvFormatRows, tsvFormatRow, tsvFormatValue} from "./tsv.js";
+import {default as autoType} from "./autoType.js";
+
+export {dsvFormat, csvParse, csvParseRows, csvFormat, csvFormatBody, csvFormatRows, csvFormatRow, csvFormatValue, tsvParse, tsvParseRows, tsvFormat, tsvFormatBody, tsvFormatRows, tsvFormatRow, tsvFormatValue, autoType};
+
+export default {dsvFormat, csvParse, csvParseRows, csvFormat, csvFormatBody, csvFormatRows, csvFormatRow, csvFormatValue, tsvParse, tsvParseRows, tsvFormat, tsvFormatBody, tsvFormatRows, tsvFormatRow, tsvFormatValue, autoType};

Thanks for reading this far! Obsessing over details like these is no-one's
idea of a good time. However, now that the shift to a native module
ecosystem is well and truly underway
https://blog.sindresorhus.com/get-ready-for-esm-aa53530b3f77, more and
more people will start to encounter these issues, and steps like these can
minimise the frustration they experience.
D3 has shown impressive leadership in this area in the past and played a
crucial role in helping to shift the JS ecosystem towards native modules,
so this feels like a natural next step. Onward!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/d3/d3/issues/3469, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAQVVPN2RUVU53F7Q3R3NTLS7L3CBANCNFSM4XXJORCA
.

@doug3d that's because you're responding via email ;) it was fixed on github.com — https://github.com/Rich-Harris/d3-modules

Thanks for the detailed explanation, @Rich-Harris. I’m fully in support of doing this and indeed have been wanting to do this for some time, only being held back by the knowledge that this will almost certainly cause downstream breakages and complaints due to the wild and wonderful ways that JavaScript is consumed.
That said, all of the documentation clearly indicates that import * as d3 from "d3-foo" is the recommended pattern, so if someone is relying on an undocumented default export, I don’t think that’s worthy of triggering a major version bump.

Quick nit.
The currently suggested package.exports won't work as expected.
You don't need to you "type": "module" to use ESM in node.js, you can simply use the .mjs file extension. What "type": "module" does is change the interpretation of the .js file extension to be ESM rather than CJS... this means that in a "type": "module" package you can't use the .js extension for CJS, you can instead use .cjs, which has the excellent slightly unexpected behavior of "just working" in old versions of Node.js as the runtime treats unknown file extensions as CJS (although you need to be explicit about the file extension in your source text, e.g. no automatic file extension resolution with .cjs). If you don't care about supporting Node.js < 12.20.x you can replicate some of the file extension magic using subpath patterns.
It might be more work than you are looking for but I have an example repo that has everything authored in ESM with the .mjs file extension and uses rollup to transpile a CJS version that is exposed using package.exports. This is a pattern you could explore using to simplify some of this, happy to answer any questions.
https://github.com/mylesborins/node-osc
One thing to keep in mind. If you choose to use package.exports folks will only be able to import files / paths that are defined as subpath exports. Folks mostly get bit by this when they discover they needed to explicitly export their package.json if folks are expecting to be able to import / require it.
Happy to answer any questions

@MylesBorins Ah whoops! Thanks for catching that, I should have written this instead to include package.json...
  "main": "dist/d3-dsv.js",
  "unpkg": "dist/d3-dsv.min.js",
  "jsdelivr": "dist/d3-dsv.min.js",
  "module": "src/index.js",
+ "type": "module",
+ "exports": {
+   "./package.json": "./package.json",
+   "import": "./src/index.js",
+   "require": "./dist/d3-dsv.cjs"
+ },
  "bin": {

...and specified that dist should contain a package.json that looks like this so that dist/d3-dsv.js et al are treated as CommonJS:
{
  "type": "commonjs"
}

I would have suggested .mjs, but there's a showstopper: VSCode doesn't know what to do with those files. Until the most popular editor gives you the same OOTB experience with .mjs as with .js, I don't think it's a realistic option for most people unfortunately.

An alternative would be to drop the CJS module. What’s the advantage for a non-node module to keep CJS when it’s just generated from an ESM file (i.e. it’s only there for pre-ESM bundlers compatibility).

Can confirm that what @MylesBorins suggestion is the easiest to implement and works in all environments. We tried a lot of different approaches over at Preact and found that using export fields with an mjs extension for the import source is the easiest to support without having to add "type": "module".

I would have suggested .mjs, but there's a showstopper: VSCode doesn't know what to do with those files. Until the most popular editor gives you the same OOTB experience with .mjs as with .js, I don't think it's a realistic option for most people unfortunately.

Agree, authoring in .mjs file is a poorer experience. We transpile/generate our dist/ files as usual and just rename the output files to add the .mjs extension via our build process.

@marvinhagemeister just to put in my two cents: I found that using .js for ESM and .cjs for CJS is the best option (due to lack of support from VSCode and others), and is working wonderfully for me, including the occasional need for transpiling to dist/.
What were the problems you found with .js for ESM?
Also, while we're at it, my blog post on the whole ESM in Node.js experience: https://gils-blog.tayar.org/posts/using-jsm-esm-in-nodejs-a-practical-guide-part-1/

@fregante because given the size of D3's userbase it's guaranteed that someone, somewhere, is doing this:
<script src="https://some.npm.cdn/d3"></script>
<script>
  d3.select(...)...
</script>

Removing the UMD dist files would break those apps — acceptable in a major version, but otherwise fraught.
@marvinhagemeister D3 packages don't expose a bundled ESM version, just the src. So the choice is

rename all the src/**/*.js files to src/**/*.mjs (and live with the subpar authoring experience)
start bundling ESM (and live with the increased complexity, and requirement to use sourcemaps etc)
Use "type": "module" at the top level and "type": "commonjs:" inside dist

For me, 3 is an absolute no-brainer, but it's also not my decision.

Ah, do you mean the d3.node.js file, aka pkg.main? (In d3-* packages, pkg.main is the UMD file.) You need to keep that, because otherwise this would fail:
const d3 = require('d3');

One day it'll be possible to remove support for require, but I don't think we're there yet.

In my libraries, I decide to do what Sindre Sorhus is doing in his projects — slowly migrating them to ESM-only with "type": "module", no conditional exports, and dropping the CommonJS entry point completely (requiring Node v12+). UMD build is still generated for legacy uses (script tags etc) but it's not main.

One day it'll be possible to remove support for require, but I don't think we're there yet.

@Rich-Harris I think now is the best time to do so. Node v10 reaches End of Life in a couple of months, and migrating libraries to ESM-only will get us to industry-wide adoption (and happy maintainer life) much faster. People still can do await import('d3') if they really need to use a ES module within a CommonJS one.

@mourner I like the cut of your jib, and if that's the view of the maintainership then I enthusiastically support it. My only hesitation is that the people who can't yet adopt ESM in their own projects (for whatever reason) might blame D3 for the incompatibility. If it were to happen in a major version that's obviously less of a concern.

I like the idea of going all-in on ESM and doing it as a major version bump.

Would that jettison the UMD build, or keep the UMD build?

Keeping the UMD build in dist.

My only hesitation is that the people who can't yet adopt ESM in their own projects (for whatever reason) might blame D3 for the incompatibility. If it were to happen in a major version that's obviously less of a concern.

@Rich-Harris yeah, definitely a valid concern, and such a change is certainly semver-major breaking. I would be worried about upgrading a package extensively used in the Node ecosystem (server-side utilities, infrastructure, etc.), but it seems like it's much less breaking for front-end libraries like d3, where require is usually used in the context of a bundler like Webpack, and is much easier to upgrade. Also, for popular projects, any major changes will cause some people to complain — it's inevitable, but when picking the time to eventually do the change, Node v10 EoL seems like the perfect moment to draw the line.

Definitely a concern. It reminds me of the current consistent stream of D3 "bug reports" people submit due to adoption of ES6.

I believe, but could be wrong, that dropping CJS support would potentially
make it significantly harder for those using browserify which still has
over 1 million downloads a month.
It seems like a UMD module that is included as main should allow
browserify to still work, but would be good to confirm that.
On Fri, Feb 19, 2021 at 1:01 PM Curran Kelleher<EMAIL_ADDRESS>wrote:

Definitely a concern. It reminds me of the current consistent stream of D3
"bug reports" people submit due to adoption of ES6.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/d3/d3/issues/3469#issuecomment-782239704, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AADZYV3TPBSHMJYZP7IBOWLS72RNZANCNFSM4XXJORCA
.

Regarding my earlier comment on D3 "bug reports" people submit due to adoption of ES6 - I just want to clarify, perhaps it could have been way worse, and I'm not saying at all that it was a bad move to start adopting ES6. I just remember seeing so many little issues fly by like "It breaks in IE". Not sure what sort of baseline to expect, but the complaints on this front were definitely nonzero.
I just mean to say that, these are the same sort of issues that we can expect if we do a modernization change like this. If we could map out what changes would cause the most friction and make sure there are workarounds/solutions for each, we'd be golden. I bet most of the issues could be addressed by using all the modern approaches, but then saying "Hey, if it doesn't work for you, here's the UMD bundle that you can still use."
It would be interesting to map/test out the behaviors of various build tools with respect to the proposed changes, like:

Browserify
Webpack
Rollup
Popular project templates/systems like create-react-app, Next.js, Nuxt, Sapper.

@mourner you need d3 cjs if your app is built with browserify (and switching bundlers is no mean feat) and also for serverside SVG rendering. So it's definitely semver-major.

I’ve started work on this with d3-format as a trial run: https://github.com/d3/d3-format/pull/112 I’ll need to rewrite D3’s thousands of tests to use ES modules (switching from Tape to Mocha), which is the most tedious part.

@mbostock I think it would be easier to keep using tape (than switch to Mocha) — the library itself works fine with ESM, it's just the binary runner that's not fixed yet, and there's both an existing workaround and a PR in the works.

Thanks for the tip, @mourner. I’ll look into that. I’ll need to fix the tests anyway (because they currently use require and would need to import), but that would certainly cut down on some of the churn.

If anyone wants to review:

d3-array: https://github.com/d3/d3-array/pull/202  // tests need fixing
d3-axis: https://github.com/d3/d3-axis/pull/78
d3-brush: https://github.com/d3/d3-brush/pull/86
d3-chord: https://github.com/d3/d3-chord/pull/21
d3-color: https://github.com/d3/d3-color/pull/90
d3-contour: https://github.com/d3/d3-contour/pull/54
d3-delaunay: https://github.com/d3/d3-delaunay/pull/120
d3-dispatch: https://github.com/d3/d3-dispatch/pull/27
d3-drag: https://github.com/d3/d3-drag/pull/80
d3-dsv: https://github.com/d3/d3-dsv/pull/81
d3-ease: https://github.com/d3/d3-ease/pull/30
d3-fetch: https://github.com/d3/d3-fetch/pull/43
d3-force: https://github.com/d3/d3-force/pull/192
d3-format: https://github.com/d3/d3-format
d3-geo: https://github.com/d3/d3-geo/pull/238
d3-hierarchy: https://github.com/d3/d3-hierarchy/pull/177
d3-interpolate: https://github.com/d3/d3-interpolate/pull/93
d3-path: https://github.com/d3/d3-path/pull/30
d3-polygon: https://github.com/d3/d3-polygon/pull/31
d3-quadtree: https://github.com/d3/d3-quadtree/pull/40 // tests need fixing
d3-random: https://github.com/d3/d3-random/pull/40
d3-scale: https://github.com/d3/d3-scale/pull/246
d3-scale-chromatic: https://github.com/d3/d3-scale-chromatic/pull/37
d3-selection: https://github.com/d3/d3-selection/pull/276 // tests need fixing
d3-shape: https://github.com/d3/d3-shape/pull/179
d3-time: https://github.com/d3/d3-time/pull/50
d3-time-format: https://github.com/d3/d3-time-format/pull/95
d3-timer: https://github.com/d3/d3-timer/pull/46 // tests need fixing
d3-transition: https://github.com/d3/d3-transition/pull/123 // tests need fixing
d3-zoom: https://github.com/d3/d3-zoom/pull/234 // tests need fixing
d3-geo-projection: https://github.com/d3/d3-geo-projection/pull/208
d3-geo-voronoi: https://github.com/Fil/d3-geo-voronoi/pull/35
d3-geo-polygon: https://github.com/d3/d3-geo-polygon/pull/48

In some cases I couldn't find how to fix the tests that depend on this being global in the new environment.

The main RREADME for d3 still says:
In Node:
const d3 = require("d3");
You can also require individual modules and combine them into a d3 object using Object.assign:
const d3 = Object.assign({}, require("d3-format"), require("d3-geo"), require("d3-geo-projection")); that for node, you can use:
But both usages now seem to be broken.

// async method
(async function() {
  const d3 = Object.assign({}, await import("d3-format"), await import("d3-geo"), await import("d3-geo-projection"));
  console.log(d3);
})();

// needs "type": "module" in package.json
import * as d3Format from "d3-format";
import * as d3Geo from "d3-geo";
import * as d3GeoProjection from "d3-geo-projection";
const d3 = Object.assign({}, d3Format, d3Geo, d3GeoProjection);
console.log(d3);


Dynamic, CGLib and Javassist proxy objects as sources

This PR contains changes to support Dynamic, CGLib and Javassist proxy objects as sources for the MappingFacade.
Possible successor of https://github.com/naharoo/mapstruct-facade-spring-boot-starter/pull/4

Hi Narek,
Thank you so much for your fast turnaround!
This is better than my fast fix. I tested it with Java 17 and SpringBoot 2.6.6 and it works like a charm.

I'm merging this. Thank you @tcolombo08 for your help 👍
Will release this ASAP and ping you in https://github.com/naharoo/mapstruct-facade-spring-boot-starter/pull/4 thread


Some dart_precompiled simarm64 tests started timing out on the buildbots

This started happening between ad3efd871780 and 59525101c287, but I have not been able to reproduce locally on my machine.

Duplicate of #29261


opentelemetry-api-plugin hosting request

Repository URL
https://github.com/cyrille-leclerc/opentelemetry-api-plugin
New Repository Name
opentelemetry-api-plugin
Description
Extract OpenTelemetry APIs jars into a Jenkins API plugins so that all plugins using OpenTelemetry, including the Jenkins OpenTelemetry Plugin and plugins that want to make their code more observable like the Junit SQL Storage Plugin can reference the same version of the API.
GitHub users to have commit permission
@cyrille-leclerc
@kuisathaverat
Jenkins project users to have release permission
@cyrille-leclerc
@kuisathaverat
Issue tracker
GitHub issues

Security audit, information and commands
The security team is auditing all the hosting requests, to ensure a better security by default.
This message informs you that a Jenkins Security Scan was triggered on your repository.
It takes ~10 minutes to complete.
Commands
The bot will parse all comments, and it will check if any line start with a command.
Security team only:

/audit-ok => the audit is complete, the hosting can continue :tada:.
/audit-skip => the audit is not necessary, the hosting can continue :tada:.
/audit-findings => the audit reveals some issues that require corrections :pencil2:.

Anyone:

/request-security-scan => the findings from the Jenkins Security Scan were corrected, this command will re-scan your repository :mag:.
/audit-review => the findings from the audit were corrected, this command will ping the security team to review the findings :eyes:.
	It's only applicable when the previous audit required changes.

Only one command can be requested per comment.

(automatically generated message, version: 1.28.6)

The Jenkins Security Scan did not find anything dangerous with your plugin, congratulations! :tada:

:bulb: The Security team recommends that you are setting up the scan in your repository by following our guide.

I confirm the desire to use <jenkins.version>2.401.3</jenkins.version> to align with the Jenkins OpenTelemetry plugin

/hosting re-check

/hosting host

⛔ Required: The following usernames in 'Jenkins project users to have release permission' need to log into Jira: @kuisathaverat (reports are re-synced hourly, wait to re-check for a bit after logging in)

I confirm that I have a valid Jira user, ifernandezcalvo

/hosting re-check


Switch light / dark easily

Description of the new feature / enhancement
I'd love it if I could switch between dark & light mode by a touch of a button (or two). Think CTRL + WIN + W or something similar.
Scenario when this would be used?
When switching rooms (darker vs bright sun light), or just a timing thing.
Supporting information
I'm using Easy Dark Mode today. But such a feature seems right up the alley of PowerToys.

Yes. Has been requested a million times (including myself) both in Powertoys (see #1331) and in the Feedback Hub: https://aka.ms/AAanro0. Therefore: Fair question. Microsoft needs to wake up and listen!
@Aaron-Junker another #duplicate. Maybe we can pin 1331 to the issues page?

Related: https://github.com/microsoft/PowerToys/issues/1331

Yeah, i thought that too. Difference is that 1331 is more about the time, while the request here is for a hotkey. But still close :-)

I think we should merge 1331 with this, same conceptually.  /dup #1331


Add --auto-agree-with-licenses flag to install

Why is this PR needed?
This is required for non-intercative installation as the default
is to not accept licence, which leads to a failed install
as we cannot override interactively.
#1385
Fixes #1385
Reminder: Add the "fixes bsc#XXXX" to the title of the commit so that it will
appear in the changelog.
What does this PR do?
Add --auto-agree-with-licenses to install commands
Anything else a reviewer needs to know?
Info for QA
Related info
Status BEFORE applying the patch
See Issue
Status AFTER applying the patch
Caasp 4.5 installs properly with licence acceptet
Docs
If docs need to be updated, please add a link to a PR to https://github.com/SUSE/doc-caasp.
At the time of creating the issue, this PR can be work in progress (set its title to [WIP]),
but the documentation needs to be finalized before the PR can be merged.
Merge restrictions
(Please do not edit this)
We are in v4-maintenance phase, so we will restrict what can be merged to prevent unexpected surprises:
What can be merged (merge criteria):
    2 approvals:
        1 developer: code is fine
        1 QA: QA is fine
    there is a PR for updating documentation (or a statement that this is not needed)

If the bug is valid and makes sense, then this implementation is good: we should then merge and backport.

for the record - it can be overwritten in /etc/zypp/zypper.conf .


Minor UI fixes

Takes care of #54 and #55

This looks great to me. I’ll merge into #58. This will generate unique Cloudflare link that you can share with anyone to test it. Once it’s tested, I’ll release. Thank you!!

@emmap3-do - Also next time please make sure you set me as reviewer so I get notification on this.


Silent error on condition palette call to incorrect theme item 🤯

Environment
System:

OS: macOS 10.14
CPU: (12) x64 Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
Memory: 110.11 MB / 16.00 GB
Shell: 3.2.57 - /bin/bash

Binaries:

Node: 8.12.0 - /usr/local/bin/node
Yarn: 1.12.3 - /usr/local/bin/yarn
npm: 6.4.1 - /usr/local/bin/npm

npmPackages:

babel-plugin-styled-components: ^1.8.0 => 1.8.0
styled-components: ^4.0.0 => 4.0.0

Reproduction
not passing a color and giving an undefined palette option will silently error, almost missed this until I checked my project on safari.
the style for background wont even show up in the browser
incorrect palette option
correct palette option
button background
  background: ${(props: IProps) =>
    props.color ? props.color : palette("whitescale", 0)};

default theme
theme.palette = {
  primary: ["#F7901E"],
  secondary: ["#00a3d9"],
  danger: ["#C65251"],
  alert: ["#EB9F00"],
  success: ["#519D33"],
  white: ["#ffffff"],
  grayscale: ["#212121", "#616161", "#9e9e9e", "#bdbdbd", "#e0e0e0", "#ffffff"],
}

Steps to reproduce
create a theme, call a option that does not exist within a prop conditional style
Expected Behavior
warning or error of some sort.
Actual Behavior
silently fails and simply does not include the style for background.

This is expected behaviour, we can't know whether you meant to not interpolate anything and get rid of the whole rule or not!

ok perfect thanks! wasn't sure 👍

I'd recommend you to instead use and place a function on the theme to access your palette :) it doesn't make a big difference access wise but you can validate inputs either programmatically or transform input/output. Type systems help too 🙌

awesome thanks!!! 💯


Report read counts in UTRs

We should add to generate_stats_figs functions to report counts of (A-site assigned) reads in 5'UTRs and 3'UTRs.
Ideally these would be reported as another column alongside the tpms and CDS counts.
We think this should be only a few lines of code to implement.

Hi! When running Riboviz on human data using a GENCODE gtf file, how can we have the reads aligned to the UTRs be preserved (and not filtered out)? Is there a flag that can be set or suggestions for a hacky way to modify the gtf to include the UTRs into the CDS definitions?


Sorting examples in SeedPython

This PR does not need to be merged now, since the code files are not 100% supported by the current state of SeedPython.
I made this PR to show the expected state that we'd like to support a sorting algorithm visualization app. We can use this PR to discuss what we'd like to support and what not to support in SeedLang for building such an app.

@codingpotato I updated this PR to take the current design of V-tags. Although there are still some features that the current SeedPyhton does not support (See the issues I reported: #166, #168, #169), shall we probably merge this PR into the main branch, so that we can improve V-tags based on the sorting algorithms listed in this PR?


impl approx

This implements approx for sparse vectors and matrices. This can be very useful for comparing matrices, as the  PartialEq checks for structural equality, and the approx traits "ignore" the storage type.
Fixes #197

By placing the traits in a module in the toplevel we can squeeze some documentation in. If one clicks the trait implementation AbsDiffEq one gets redirected to sprs::approx::AbsDiffEq, and sprs::approx got the information regarding performance.
Alternatively one can also directly import the traits and add a doc string, but these docs will be above the trait item explanation, which makes it a bit odd...

Maybe we should add some metadata for docs.rs to have all features enabled and visible in the docs?

Yes that's a good idea, I've filed it in #215.


[Minor] Set default executor conf for unit tests, and fix setRepresentativeEdgeId

This commit resolves multiple issues that we've missed because of wrong CI configuration.

Sets default ExecutorJsonPath value for unit tests.
Allow multiple setRepresentativeEdgeId invocation with same edgeId.

Hold on, can we make the CI catch the bits that we have failed to do so in the past?

Good idea. Let me investigate the issue.

@wonook Please see the updates.

This PR should be moved to incubator-nemo.

Will be filed to incubator-nemo. Closing.


Planet Zombie Redirect

We need dosomething.org/zombie to go to https://www.dosomething.org/us/campaigns/planet-zombie (currently unpublished) by Friday.
Thanks so much Matt!

Closed via Fastly config v68.


Ensure that efivarfs is mounted in the container

Especially on ARM, which utilizes UEFI for booting in most cases, it is important that the /sys/firmware/efi/efivars be mounted and populated, otherwise bootc will fail to complete a to-filesystem installation.
This patch attempts a mount as long as the hosts efivars directory has an entry, signifying the system is at least capable of UEFI.
Note that it is sufficient to just attempt to mount efivars. If it's already mounted elsewhere, it triggers the mount to be made at the /sys location.
Fixes #291

/ok-to-test

/ok-to-test

This is OK as is, we can do other fixes as followups. Does this solve the problem in your testing?

So far, yes.
I'll do the cleanups suggested.


Fix sign typo

This probably doesn't deserve a merge commit, so unless you have strong opinions about full preservation of Git history this can get squashed and merged.

Good catch!


Errors on xiaomi device

W/System.err: com.judemanutd.autostarter.AutoStartPermissionHelper.startIntent(AutoStartPermissionHelper.kt:268)
I get 5 more errors when doing AutoStartPermissionHelper.getInstance().getAutoStartPermission(getApplicationContext());
get this on a xiaomi device. help?

Could you post the entire error log please

im trying this on the xiaomi redmi note 7

@ItsKlork  Just tried it out on the redmi note 7 and works fine. Could you post the error log along with the android version and miui version on the phone.
Have you run the example app from the repo, does that work?

2019-12-07 11:28:04.696 21706-21706/com.dev.mapup W/System.err:     at com.judemanutd.autostarter.AutoStartPermissionHelper.startIntent(AutoStartPermissionHelper.kt:268)
2019-12-07 11:28:04.696 21706-21706/com.dev.mapup W/System.err:     at com.judemanutd.autostarter.AutoStartPermissionHelper.autoStartXiaomi(AutoStartPermissionHelper.kt:122)
2019-12-07 11:28:04.697 21706-21706/com.dev.mapup W/System.err:     at com.judemanutd.autostarter.AutoStartPermissionHelper.getAutoStartPermission(AutoStartPermissionHelper.kt:85)
2019-12-07 11:28:04.697 21706-21706/com.dev.mapup W/System.err:     at com.judemanutd.autostarter.AutoStartPermissionHelper.startIntent(AutoStartPermissionHelper.kt:268)
2019-12-07 11:28:04.697 21706-21706/com.dev.mapup W/System.err:     at com.judemanutd.autostarter.AutoStartPermissionHelper.autoStartXiaomi(AutoStartPermissionHelper.kt:122)
2019-12-07 11:28:04.697 21706-21706/com.dev.mapup W/System.err:     at com.judemanutd.autostarter.AutoStartPermissionHelper.getAutoStartPermission(AutoStartPermissionHelper.kt:85)

nothing is happening

@ItsKlork  Which miui version are you on?

MIUI Global 11.0.4

Got the same phone with the same version, works perfectly fine, no clue what's up.

If you could create a separate repo recreating this exact bug I could give this a try else looks like there's something local to your phone that's causing the issue

How should I use the AutoStarter in code (in onCreate)? Just to be sure

Yep that should work fine, it doesn't really depend on any activity lifecycle as such but any lifecycle events after onCreate should be more than safe to use the code in, instead of using the application context try using the activity context instead and see if that works

closing this issue as there is no further action to be taken


Issue on docs

Path: /introduction/overview
The link to Guides in the nav menu just goes to the overview

Hi @mohanchand201,
Thanks for offering to jump in on this issue! I'm currently in the middle of stabilizing the new docs portal and have addressed this particular problem. However, your keen eye would be super helpful in spotting any other potential issues! Feel free to take a look around and suggest fixes where you see fit. Your contributions are very much appreciated!

Hey @gevaperry,
Thanks for pointing this out! It’s been fixed in the latest updates to the docs portal. If you notice anything else that needs tweaking, please don't hesitate to let us know. Your feedback is invaluable to us!

Hi @mohanchand201,
Thanks for offering to jump in on this issue! I'm currently in the middle of stabilizing the new docs portal and have addressed this particular problem. However, your keen eye would be super helpful in spotting any other potential issues! Feel free to take a look around and suggest fixes where you see fit. Your contributions are very much appreciated!

Hey @gevaperry,
Thanks for pointing this out! It’s been fixed in the latest updates to the docs portal. If you notice anything else that needs tweaking, please don't hesitate to let us know. Your feedback is invaluable to us!


Habib/remove old testimoniak

Changes:

...

Type of change

[ ] Bug fix
[ ] New feature
[ ] Update feature
[ ] Refactor code
[ ] Translation to code
[ ] Translation to crowdin
[ ] Script configuration
[ ] Improve performance
[ ] Style only
[ ] Dependency update
[ ] Documentation update
[ ] Release

testimoniak? 👁

testimoniak? 👁

Ah, fixed it in the title :D


Moved JS content to script.js

Description
Moved the JS files into script.js and divided the code into functions for readability and maintainability
Additional Context:
N/A

@sanjay-kv kindly review


update readme

add support for etcher @puntillol59
add build grub iso
remove 32 bios support
most grammer errors fixed

to resolve conflicts remove <<<<<<< master

update on the default typo

add mbr option(beta)

Hexa god

new nav system. worth a look

added pangolin on linux

i added KVM (Kernel-based Virtual Machine) for the people who need it 😉

request a merge. nothing has been looked at in the 10 days it was opend


"Impossible cron expression" thrown on timezones that offsets with minuets

for time zones that have an offset with minuets, an "Impossible cron expression is thrown when calling isDue or getNextRunDate.  It appears to happen because the getNextRun date keeps adding hours and then hits a limit in a for loop.
Steps

use the following expression: 0 */5 * * * *
Set time zone to one that has offset with minuets (Asia/Kabul, or Asia/Calcutta)
Call next getNextRunDate(null, 0, true);

Expected
The next run date for the job is returned
Actual
An Exception is thrown with the message "Impossible cron expression"

Can you explain what you mean by "Set time zone to one that has offset with minuets (Asia/Kabul, or Asia/Calcutta)"? Are these time zones different than other time zones in that they are GMT +XX:YY?

@mtdowling Asia/Kabul has an UTC offset of +04:30.  When getRunDate tries to figure out when the next time to run is going to be. It looses the 30 min and keeps looping then fails.  I have confirmed that this happens with all TZ that have offset with min.

I've encountered this problem too. All timezones with a minute offset (eg: Australia/Adelaide +0930) are looping 1000 times in getRunDate then returning "Impossible CRON expression".

I think the problem is in HoursField.php. Currently it converts to UTC, jumps to the start/end of the hour, then converts back (ending up in the middle of the hour, if the timezone is XX:30).
This code probably needs some more testing, but is working for me:
In HoursField.php, around line 22
FIND
    if ($invert) {
        $date->modify('-1 hour');
        $date->setTime($date->format('H'), 59);
    } else {
        $date->modify('+1 hour');
        $date->setTime($date->format('H'), 0);
    }
    $date->setTimezone($timezone);

REPLACE WITH
   $date->setTimezone(new \DateTimeZone('UTC'));
    if ($invert) {
        $date->modify('-1 hour');
        $date->setTimezone($timezone);
        $date->setTime($date->format('H'), 59);
    } else {
        $date->modify('+1 hour');
        $date->setTimezone($timezone);
        $date->setTime($date->format('H'), 0);
    }

This should now be fixed in v1.1.0.
If not, feel free to re-open this issue.


chore: bump sdk version

Related to https://github.com/meltano/squared/issues/432

@kgpayne @pnadolny13 is this safe to merge?

@kgpayne @pnadolny13 is this safe to merge?

I think so, just clarifying what the throttle paginator changes are doing but if its not changing functionality then it looks good to me!


Fix retrying of bidirectional RPCs and closing the streaming pull manager

Closes #5306

No, I just noticed this myself. Will fix asap.
On Thu, May 31, 2018, 12:43 AM Simon Jagoe<EMAIL_ADDRESS>wrote:

@sjagoe commented on this pull request.
In
pubsub/google/cloud/pubsub_v1/subscriber/_protocol/streaming_pull_manager.py
https://github.com/GoogleCloudPlatform/google-cloud-python/pull/5412#discussion_r192013248
:

@@ -414,11 +415,28 @@ def _should_recover(self, exception):
# If this is in the list of idempotent exceptions, then we want to
# recover.
if isinstance(exception, _RETRYABLE_STREAM_ERRORS):

       logging.info('Observed recoverable stream error %s', exception)

Are these log messages intentionally using the root logger?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/google-cloud-python/pull/5412#pullrequestreview-124699652,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAPUc9JFAxFa-_Qmk3qKsit3v7D42DpSks5t3586gaJpZM4UTqlB
.


Files created with New Query can't be saved on macOS

Azure Data Studio Version: master

Steps to Reproduce:

Create a new script file with the New Query command against a Server node in Object Explorer
Try to save file using "Save" command (not "Save as")

Expected: File saves
Actual: Error occurs

This appears to be fixed in Feb RC build.  I'll move to March milestone since we fixed directly in release/1.15.

This is fixed.


Problem: exists(':keepalt') returns 0

Problem:  exists(':keepalt') returns 0
Solution: use correct length when finding command,
also ignore :{ and :} when expanding
command line items
fixes: #15305

I don't think the length is the problem here. The problem here is that cmdmod_info_tab is sorted by the full string length, but it should be sorted by the part of the string that is actually compared. For :keepmarks it is kee, which should come before :keepalt (keepa) and :keepjumps (keepj).

I don't think the length is the problem here. The problem here is that cmdmod_info_tab is sorted by the full string length, but it should be sorted by the part of the string that is actually compared. For :keepmarks it is kee, which should come before :keepalt (keepa) and :keepjumps (keepj).

Hmm, but changing the sorting doesn't solve the problem :(

@zeertzjq you are right, that is the wrong way to fix it. I think what we need to do is to compare against the max length of both entries, so that we will always get an unambigious entry returned. And then also use strlen(name) for the target length. Otherwise we will go into the binary search with e.g. the entry 'keepalt' but because of the min length of 3 for 'keepmarks', the bsearch() returns the :keepmarks entry and then because of the following logic: https://github.com/vim/vim/blob/2979cfc2627d76a9c09cad46a1647dcd4aa73f5f/src/ex_docmd.c#L4127-L4135
it aborts and returns 0.
So like this:
diff --git a/src/ex_docmd.c b/src/ex_docmd.c
index e6200ed70..1caed8b08 100644
--- a/src/ex_docmd.c
+++ b/src/ex_docmd.c
@@ -4057,7 +4057,7 @@ cmp_cmdmod_info(const void *a, const void *b)
     cmdmod_info_T *cm1 = (cmdmod_info_T *)a;
     cmdmod_info_T *cm2 = (cmdmod_info_T *)b;

-    return STRNCMP(cm1->name, cm2->name, cm2->minlen);
+    return STRNCMP(cm1->name, cm2->name, MAX(cm1->minlen, cm2->minlen));
 }

 /*
@@ -4079,7 +4079,7 @@ modifier_len(char_u *cmd)
        return 0;

     target.name = (char *)p;
-    target.minlen = 0;         // not used, see cmp_cmdmod_info()
+    target.minlen = STRLEN(p);
     target.has_count = FALSE;

     entry = (cmdmod_info_T *)bsearch(&target, &cmdmod_info_tab, ARRAY_LENGTH(cmdmod_info_tab), sizeof(cmdmod_info_tab[0]), cmp_cmdmod_info);
@@ -4119,7 +4119,7 @@ cmd_exists(char_u *name)
        cmdmod_info_T   *entry;

        target.name = (char *)name;
-       target.minlen = 0;              // not used, see cmp_cmdmod_info()
+       target.minlen = STRLEN(name);
        target.has_count = FALSE;

        // Check command modifiers.
@@ -5993,6 +5993,10 @@ get_command_name(expand_T *xp UNUSED, int idx)
 {
     if (idx >= (int)CMD_SIZE)
        return expand_user_command_name(idx);
+    // the following are no real commands
+    if (STRNCMP(cmdnames[idx].cmd_name, "{", 1) == 0 ||
+        STRNCMP(cmdnames[idx].cmd_name, "}", 1) == 0)
+       return (char_u *)"";
     return cmdnames[idx].cmd_name;
 }

hm, still fails on Windows.

I am going to partly revert patch v9.1.0352


Timeout in cluster operation (while executing)

My Environment

ArangoDB Version:       3.3.14
Storage Engine:             RocksDB
Deployment Mode:       Cluster
Deployment Strategy:   Manual Start in Docker
Configuration:               3 agencies, 1 coordinator, 2 DBServers
Infrastructure:               Own
Operating System:        DCOS 1.10.5
Used Package:              Official docker librairy

Component, Query & Data
Affected feature:
I am migrating a large dataset from a single instance to a cluster, and when requesting some collections, I receive the following error:
Query: AQL: could not lock all shards : timeout in cluster operation (while executing)

The coordinator shows the following log:
2018-09-23T17:19:25Z [1] ERROR {cluster} ClusterComm::performRequests: got BACKEND_UNAVAILABLE or TIMEOUT from shard:s14316:/_db/test/_api/document/s14316?waitForSync=false&ignoreRevs=true&isRestore=false&returnNew=true
2018-09-23T17:19:36Z [1] ERROR {cluster} ClusterComm::performRequests: got no answer from shard:s14316:/_db/test_api/document/s14316?waitForSync=false&ignoreRevs=true&isRestore=false&returnNew=true with status timeout

The DBServer where this shard is do not shows anything in it's log.
If I try to remove the locked collection in arangosh, the cli hangs, if I try to reimport it with arangorestore after a ctrl+C, the coordinator process shutdown, and after a restart, navigating to the "shards" section of the coordinator UI fails with:
Cluster: Could not fetch sharding information.

The only way I found to recover this (reproducable) state is to totally wipe out the database and reimport the whole dataset, restarting the whole cluster does not help
Is this a known issue? Is there a way to unlock a collection in this state?

Nevermind, it appears this locking issue disappeared after upgrading to 3.3.15.


Allow links relative to the website root, automatic copyright year in the copyright notice

Verified as working.


Why is img_size default to 64?

Hi was wondering why the img_size parameter for experiments is set to 64 as the celebA dataset images are of much larger size.
I am trying to experiment this on a different dataset that is larger than celebA (512 x 512) and was wondering if I should change img_size to create better reconstructed images. I tried changing it myself but I ran into size mismatch issues even though I don't see in the model file where the size of 64 comes to play.
Any help would be much appreciated

I just chose 64x64 for a quick standard implementation. It also takes fewer epochs to get good results. You can always create a larger network size. I hope you two resolved it among yourselves. Please re-open this issue if you need any further help.


【iOS】The contentOffset property is missing from TextInputView's onScroll callback

Description
I found that in the onScroll callback of textInput, the old schema contained the contentOffset attribute, but the new schema did not, causing a crash!
Steps to reproduce
const onInputScroll = (e) => {
    if (Platform.OS !== "web") {
      const {
        nativeEvent: {
          contentOffset: { x, y },
        },
      } = e;
      console.log('onInputScroll ====', e?.nativeEvent)
    }
  };

<TextInput
        onScroll={onInputScroll}
        ref={inputRef}
        multiline
>

React Native Version
0.73.3
Affected Platforms
Runtime - iOS
Areas
Fabric - The New Renderer
Output of npx react-native info
OS: macOS 14.1
  CPU: (8) arm64 Apple M1 Pro
  Memory: 109.81 MB / 16.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 21.6.1
    path: ~/.nvm/versions/node/v21.6.1/bin/node
  Yarn:
    version: 1.22.19
    path: /opt/homebrew/bin/yarn
  npm:
    version: 10.2.4
    path: ~/.nvm/versions/node/v21.6.1/bin/npm
  Watchman:
    version: 2<IP_ADDRESS>
    path: /opt/homebrew/bin/watchman
Managers:
  CocoaPods:
    version: 1.12.1
    path: /Users/zhuzhiqin/.rvm/gems/ruby-2.7.2/bin/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 23.0
      - iOS 17.0
      - macOS 14.0
      - tvOS 17.0
      - watchOS 10.0
  Android SDK: Not Found
IDEs:
  Android Studio: 2023.1 AI-231.9392.1.2311.11330709
  Xcode:
    version: 15.0.1/15A507
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 17.0.10
    path: /usr/bin/javac
  Ruby:
    version: 2.7.2
    path: /Users/zhuzhiqin/.rvm/rubies/ruby-2.7.2/bin/ruby
npmPackages:
  "@react-native-community/cli": Not Found
  react: Not Found
  react-native:
    installed: 0.73.3
    wanted: 0.73.3
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: Not found
  newArchEnabled: Not found
iOS:
  hermesEnabled: true
  newArchEnabled: true

Stacktrace or Logs
Cannot read x from undefined

Reproducer
https://github.com/rabbitmouse
Screenshots and Videos
The old architecture scroll callback is as shown below

The new architecture scroll callback is as shown below

I confirm that this is still described in the official documentation.

Please fix it as soon as possible!

@rabbitmouse thanks for your report.
Can you provide:

A valid reproducer (you linked your personal GH profile)
The code snippets as code and not as image (for SEO reasons)

And then we could look into it

https://github.com/facebook/react-native/pull/43445
Yes I think this submission is correct, thx


'monthly' or 'yearly' and add email to Slack notifications

What's this PR do?
Changes Slack notifications in two ways:

instead of saying 'recurring' it's now more specific and says either 'monthly' or 'yearly'
the payer's email address is included in the notification

Why are we doing this? How does it help us?
Helps people respond to donors more quickly. Request from Tristan.
How should this be manually tested?

ensure that your env-docker file has SLACK_CHANNEL=#stripe in it
make backing
make interactive
C_FORCE_ROOT=True celery -A app.celery worker --loglevel=INFO &
python3 app.py
Visit these URLs and donate with 4242 4242 4242 4242, any CVC and any future expiration date:

local.texastribune.org/donateform?amount=70
local.texastribune.org/memberform?amount=40&installmentPeriod=monthly
local.texastribune.org/memberform?amount=40&installmentPeriod=yearly

Check Slack to see that the correct information appears there.

Have automated tests been added?
No.
Are there performance implications? If adding JS can it be done async? Do images/CSS/JS have cache headers set?
No.
What are the relevant tickets?
Request from Tristan.
How should this change be communicated to end users?
Tell Tristan that it's done.
Next steps?
N/A

Requested actions all WFM. I then tried some funky unicode in the name and reason forms just to see what would happen, and got this error. But that looks like it could be an already-existing bug outside of the scope of this PR

@x110dc Also worked for me. It let me submit a payment without checking the "agree to fee" box, but that also might be outside the scope of the PR.


Creating a media via REST with the same filename as an existing file overwrites the existing file URI

As described over at https://github.com/mjordan/islandora_workbench/issues/251, and with detailed investigation by @jordandukart in the #decoupled Slack channel, using Islandora's REST interface to create media and files as documented in the "Files and Media" section of https://islandora.github.io/documentation/technical-documentation/rest-create/ will create file URIs without checking whether they already exist. This results in existing file URIs being overwritten.
This happens with all tested Drupal filesystems, e.g. fedora:// and public://.

For context (tl;dring the Slack conversation):
Both REST's and JSON:API's implementation utilizes where as the MediaSourceService uses a naive (stream_copy_to_stream)[https://github.com/Islandora/islandora/blob/8.x-1.x/src/MediaSource/MediaSourceService.php#L187-L195] without ensuring that a URI by that name doesn't already exist.
There is an attempt to unify these services but who knows when that'll land.

For derivative generation, I think this would be the preferred behavior, allowing me to adjust my image settings and replace the existing file with an updated on.

That function gets called even creating a new file unrelated to an object being updated via derivatives.
This scenario is presently really only producible if using the API directly but consider the following:
You create a node and attach a media with a file called "test.jpg", it gets stored in "public://test.jpg".
You go to create another node and attach a media with the same filename also called "test.jpg", it also gets stored in "public://test.jpg" and overwrites the other file that was already there.


cint3c2etest fails

Seems to compile fine, but make test fails on the second test set. Not sure how to make test more verbose, so it's unclear to me what may be wrong. Let me know and I can give more information.
Running tests...
Test project /home/jjgoings/libcint/build
    Start 1: cinttest
1/2 Test #1: cinttest .........................   Passed   95.57 sec
    Start 2: cint3c2etest
2/2 Test #2: cint3c2etest .....................***Failed    0.16 sec

50% tests passed, 1 tests failed out of 2

Total Test time (real) =  95.73 sec

The following tests FAILED:
	  2 - cint3c2etest (Failed)
Errors while running CTest
Makefile:105: recipe for target 'test' failed
make: *** [test] Error 8

You can use make test ARGS=-V to get more verbosity.
Do you have pyscf installed and on your PYTHONPATH? That's my guess why it's failing.

Thanks for the quick reply!
No, actually I have not installed pyscf. I think this is why the test fails, since I see the import error. It might be nice to mention the pyscf requirement in the README. It's also interesting that test 1 shows some failures but finishes with a PASS.
Running tests...
UpdateCTestConfiguration  from :/home/jjgoings/libcint/build/DartConfiguration.tcl
UpdateCTestConfiguration  from :/home/jjgoings/libcint/build/DartConfiguration.tcl
Test project /home/jjgoings/libcint/build
Constructing a list of tests
Done constructing a list of tests
Checking test dependency graph...
Checking test dependency graph end
test 1
    Start 1: cinttest

1: Test command: /usr/bin/python "/home/jjgoings/libcint/testsuite/test_cint.py"
1: Test timeout computed to be: 9.99988e+06
1: pass:  cint1e_ovlp_sph
1: pass:  cint1e_nuc_sph
1: pass:  cint1e_kin_sph
1: pass:  cint1e_ia01p_sph
1: pass:  cint1e_cg_irxp_sph
1: pass:  cint1e_giao_irjxp_sph
1: pass:  cint1e_igkin_sph
1: pass:  cint1e_igovlp_sph
1: pass:  cint1e_ignuc_sph
1: pass:  cint1e_ipovlp_sph
1: pass:  cint1e_ipkin_sph
1: pass:  cint1e_ipnuc_sph
1: pass:  cint1e_iprinv_sph
1: pass:  cint1e_prinvxp_sph
1: pass:  cint1e_z_sph
1: pass:  cint1e_zz_sph
1: pass:  cint1e_r_sph
1: pass:  cint1e_rr_sph
1: pass:  cint1e_r2_sph
1: pass:  cint1e_ovlp
1: pass:  cint1e_nuc
1: pass:  cint1e_gnuc
1: pass:  cint1e_srsr
1: pass:  cint1e_sr
1: pass:  cint1e_srsp
1: pass:  cint1e_spsp
1: pass:  cint1e_sp
1: pass:  cint1e_spspsp
1: pass:  cint1e_spnuc
1: pass:  cint1e_spnucsp
1: pass:  cint1e_srnucsr
1: pass:  cint1e_cg_sa10sa01
1: pass:  cint1e_cg_sa10sp
1: pass:  cint1e_cg_sa10nucsp
1: pass:  cint1e_giao_sa10sa01
1: pass:  cint1e_giao_sa10sp
1: pass:  cint1e_giao_sa10nucsp
1: pass:  cint1e_govlp
1: pass:  cint1e_sa01sp
1: pass:  cint1e_spgsp
1: pass:  cint1e_spgnucsp
1: pass:  cint1e_spgsa01
1: pass:  cint1e_ipovlp
1: pass:  cint1e_ipkin
1: pass:  cint1e_ipnuc
1: pass:  cint1e_iprinv
1: pass:  cint1e_ipspnucsp
1: pass:  cint1e_ipsprinvsp
1: * FAIL:  cint2e_sph . err: 5.255133146420121e-07 / 56243.8832877
1: * FAIL:  cint2e_ig1_sph . err: 3.765482688322663e-06 / 8101.0873344
1: * FAIL:  cint2e_ip1_sph . err: 1.087461714632809e-05 /<PHONE_NUMBER>87
1: * FAIL:  cint2e_p1vxp1_sph . err: 6.967771332710981e-05 / 89014.8816974
1: * FAIL:  cint2e . err: 3.116438165307045e-07 / 37737.1136571
1: * FAIL:  cint2e_spsp1 . err: 0.0001092366874217987 /<PHONE_NUMBER>67
1: * FAIL:  cint2e_spsp1spsp2 . err: 0.006990435300394893 / 1391716.87687
1: * FAIL:  cint2e_srsr1 . err: 4.582744440995157e-05 /<PHONE_NUMBER>31
1: * FAIL:  cint2e_srsr1srsr2 . err: 0.001948476652614772 /<PHONE_NUMBER>27
1: * FAIL:  cint2e_cg_sa10sp1 . err: 7.509652641601861e-05 /<PHONE_NUMBER>65
1: * FAIL:  cint2e_cg_sa10sp1spsp2 . err: 0.004072270588949323 / 1419443.46977
1: * FAIL:  cint2e_giao_sa10sp1 . err: 5.367101402953267e-05 /<PHONE_NUMBER>08
1: * FAIL:  cint2e_giao_sa10sp1spsp2 . err: 0.004195312969386578 /<PHONE_NUMBER>69
1: * FAIL:  cint2e_g1 . err: 1.482840616517933e-06 / 3755.25159189
1: * FAIL:  cint2e_spgsp1 . err: 4.500812065089121e-05 / 16626.9910379
1: * FAIL:  cint2e_g1spsp2 . err: 0.0004120030207559466 / 22186.5665483
1: * FAIL:  cint2e_spgsp1spsp2 . err: 0.003142444431432523 /<PHONE_NUMBER>53
1: * FAIL:  cint2e_ip1 . err: 3.969522367697209e-06 / 34912.8543381
1: * FAIL:  cint2e_ipspsp1 . err: 0.0009000948339235038 /<PHONE_NUMBER>04
1: * FAIL:  cint2e_ip1spsp2 . err: 0.0009450505604036152 /<PHONE_NUMBER>36
1: * FAIL:  cint2e_ipspsp1spsp2 . err: 0.01673972280696034 / 1443972.93656
1: pass:  cint2e_spsp1 / cint2e
1: pass:  cint2e_spsp1spsp2 / cint2e
1: pass:  cint2e_spsp1spsp2 / cint2e_spsp1
1: pass:  cint2e_spgsp1 / cint2e_g1
1: pass:  cint2e_g1spsp2 / cint2e_g1
1: pass:  cint2e_spgsp1spsp2 / cint2e_g1
1: pass:  cint2e_ipspsp1 / cint2e_ip1
1: pass:  cint2e_ip1spsp2 / cint2e_ip1
1: pass:  cint2e_ipspsp1spsp2 / cint2e_ip1
1: * FAIL:  3 3 5.64582721316e-13
1: * FAIL:  7 7 7.53562844163e-14
1/2 Test #1: cinttest .........................   Passed   96.01 sec
test 2
    Start 2: cint3c2etest

2: Test command: /usr/bin/python "/home/jjgoings/libcint/testsuite/test_3c2e.py"
2: Test timeout computed to be: 9.99988e+06
2: * FAIL:  cint3c2e_sph . err: 1.300577423535287e-10 / 1586.35079743
2: * FAIL:  cint3c2e_ip1_sph . err: 6.803020369261503e-10 / 2242.05224927
2: * FAIL:  cint3c2e_ip2_sph . err: 5.302354111336172e-10 / 1970.98248386
2: Traceback (most recent call last):
2:   File "/home/jjgoings/libcint/testsuite/test_3c2e.py", line 300, in <module>
2:     test_int3c2e_spinor(*f)
2:   File "/home/jjgoings/libcint/testsuite/test_3c2e.py", line 244, in test_int3c2e_spinor
2:     zmat = sf2spinor(opref[:,:,:,0], i, j, bas)
2:   File "/home/jjgoings/libcint/testsuite/test_3c2e.py", line 203, in sf2spinor
2:     import pyscf.symm.cg
2: ImportError: No module named pyscf.symm.cg
2/2 Test #2: cint3c2etest .....................***Failed    0.16 sec

50% tests passed, 1 tests failed out of 2

Total Test time (real) =  96.17 sec

The following tests FAILED:
	  2 - cint3c2etest (Failed)
Errors while running CTest
Makefile:105: recipe for target 'test' failed
make: *** [test] Error 8


Automatic scroll does not work while using tab key

Issue Summary
It seems that in a page with the smooth-scrollbar implemented, if try to move the focus between input fields with the tab key the scroll does not set properly in order to show the focused element
Expected Behavior
While moving between focusable elements with the tab key, the focused one should always be visible in the viewport
Current Behavior
The scrollbar does not automatic scroll in order to show the focused element
Steps to Reproduce

Create a long page with some input text field outside the initial viewport
Try to move between them with the tab key

Environment

Browser: Chrome 59.0.3071.115
Version of smooth-scrollbar: 7.3.0

Currently we are not able to detect the change of focus, unless adding listeners to all focusable elements - which is considered inefficient.


Add ShutdownIfIdle call to buildkit

This call shuts down buildkit gracefully, but only if there are no active sessions (builds). This call is also atomic in that it does not allow new sessions to start up once this call is received.

BTW I could easily add a graceful shutdown with timeout call in here, if we need it in the future. (i.e. shutdown gracefully allowing X seconds / minutes for things to drain, and force exit if they did not drain in time).


Update unity-mobile-performance-guide.md

added note on Lightmap resolution

@schmidtec and @vryunji can you plz review Frank's guide?

Reviewed and accepted. Pushing into Main.


'Add new item'

It would be great to have an option to add a new item in the suggestion dropdown. Selecting that option from the dropdown would call a function like (addNew)="someFunction($event)".
There's a good example here in the basic usage demo, try typing something that isn't a state.
Is there a work around currently?

2 options:

Use the directives and create a custom completer
Create a custom data provider that is the add new item

I thought about option 2... I think I'll go with option 1 though.
Is this a feature that would be useful to others? If so I can contribute it...

So far hasn't seen demand for it and would rather not add features that can be achieved by manipulating the existing lib.

Makes sense.


Tensorflow can't detect my GPU

Issue type
Bug
Have you reproduced the bug with TensorFlow Nightly?
Yes
Source
source
TensorFlow version
2.17.0
Custom code
No
OS platform and distribution
Windows 11
Mobile device
No response
Python version
No response
Bazel version
No response
GCC/compiler version
No response
CUDA/cuDNN version
No response
GPU model and memory
No response
Current behavior?
Tensorflow can't detect my gpu.
But Cuda and cuDNN is installed
CUDA version: 12.5
Standalone code to reproduce the issue
Copyright (c) 2005-2024 NVIDIA Corporation
Built on Wed_Apr_17_19:36:51_Pacific_Daylight_Time_2024
Cuda compilation tools, release 12.5, V12.5.40
Build cuda_12.5.r12.5/compiler.34177558_0

+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 555.99                 Driver Version: 555.99         CUDA Version: 12.5     |
|-----------------------------------------+------------------------+----------------------+
| GPU  Name                  Driver-Model | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA GeForce RTX 4050 ...  WDDM  |   00000000:01:00.0 Off |                  N/A |
| N/A   44C    P8              1W /   45W |       0MiB /   6141MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+
+-----------------------------------------------------------------------------------------+
| Processes:                                                                              |
|  GPU   GI   CI        PID   Type   Process name                              GPU Memory |
|        ID   ID                                                               Usage      |
|=========================================================================================|
|  No running processes found                                                             |
+-----------------------------------------------------------------------------------------+
tf.test.gpu_device_name()
# ''
tf.config.list_physical_devices()
# [PhysicalDevice(name='/physical_device:CPU:0', device_type='CPU')]

Relevant log output
No response

Hi @siy415 ,
GPU support on native-Windows is only available for 2.10 or earlier versions, starting in TF 2.11, CUDA build is not supported for Windows. For using TensorFlow GPU on Windows, you will need to build/install TensorFlow in WSL2 or use tensorflow-cpu with TensorFlow-DirectML-Plugin. Here i am giving documentation for reference.
Thank you!


Querier Read Limits

With more streamed fanout (https://github.com/thanos-io/thanos/pull/5296) we are finally able to add more construction series / sample limits to Querier for QoS. This is because we know immediately how many series and samples globally we fetch into Querier instead of learning about that only after we computed most of it.
NOTE: This does not mean we don't need limits on other components like Store (there is already some limit there):

ref
However, we can control a lot from the Querier when it comes to QoS. The main problem comes from the fact that queries are never uniform. Some are ultra-small (samples over last 5 minutes, 10  series), some ultra large, (samples over year, 100 millions series). This why only only "limit" options we have on Querier are not enough:

ref
With query-frontend we can limit this problem to splitting queries to a 1d time window, but this has still some downsides:

The same vertical cardinality problem appears (e.g. millions of series with one sample at the same time)
We can't leverage downsampled data with such approach.

AC:

Short term:

Ability to add query limits so w

Long:

Limits per tenant
Dynamic per query limit, based on available capacity in Querier (other queries).

Initial Ideas:

Start with a simple approach first - add series/sample limit to Qurier.
Find metric that will represent the limiting factor (both mem and latency/CPU) e.g bytes processed or perhaps similar to write DPM

cc @GiedriusS

I am also very interested in this.
Is there already a configurable timeout for queries that will cause work cancellation to be pushed downstream?

Long:

Limits per tenant

So there is some interest in making other parts of Thanos tenant-aware via configuration of a tenant label name?


BUG: Celery logs reporting errors on unregistered task, STG and PRD

Describe the bug
In both the staging and production environments, the ecs/notification-celery/ logs are showing a high number of errors such as
[2022-12-06 20:21:00,086: ERROR/MainProcess] Received unregistered task of type 'switch-current-sms-provider-on-slow-delivery'.
To Reproduce
Steps to reproduce the behavior:

Go to Cloudwatch > Log Groups
Click on either staging-notification-api-log-group or prod-notification-api-log-group
Click the most recent ecs/notification-celery/ log
Search for "ERROR" and scroll until you find a series of logs starting with:
[2022-12-07 12:51:30,417: ERROR/MainProcess] Received unregistered task of type 'switch-current-sms-provider-on-slow-delivery'.
There will a number of line entries for this error. The last log entry should be something like
KeyError: 'switch-current-sms-provider-on-slow-delivery'

Expected behavior
There should be zero log entries complaining about switch-current-sms-provider-on-slow-delivery since we stopped using it.
Screenshots
Screenshot of log sequence

Additional context
Note that our version of celery is pretty far out of date and that we recently removed the switch provider on slow delivery stuff.
A common theme for this error on stackoverflow and other places (see links below) is to restart the workers. That may not be possible for us, as Jesse explains:

The celery workers should redeploy every time the API is deployed as well.  There isn't really a way to "reboot" tasks in Fargate, but you have to deploy them over again... it should have spun up new tasks during whenever the most recent deployment happened.

Celery info on tasks
KeyError could be a red herring and most likely that NotRegistered is the issue (since we don't have that method anymore?)
Stackoverflow about restarting workers and other possibkle solutions
Blog for possible solution
search Google for python celery "Received unregistered task of type" for a whole lot more.

Possibly related....

For some reason we ALWAYS have 5 things sitting in those queues (all envs, didn't grab staging in the screenshot). When they hit retention they somehow magically re-appear

Looked over this. If the old queues are polled we will almost certainly find switch-current-sms-provider-on-slow-delivery defined in the json. This should just be a simple housekeeping ticket to clean it out.

Hey team! Please add your planning poker estimate with Zenhub @cris-oddball @EvanParish @ianperera @jakehova @justaskdavidb2 @k-macmillan @kalbfled @ldraney

Per our group discussion, modifying the queues happens through the AWS SQS console.

Whoever picks this up, please plan on pairing with another engineer (who doesn't know how to do it; e.g., Dave, Baldwin) and show them how to do this.

This appears to have resolved itself. No mention of it in prod in the last week.

Searched staging for a day, had no references to it. Closing this.


.context being deprecated in jQuery 1.10

According to the jQuery doc, the .context property was deprecated in jQuery 1.10, and may be removed without notice in a future version.
Is there any workaround for this ?

This change makes the plugin no longer working

Is there any workaround for jQuery v3? Thanks.

@shawnngtq the workaround is to not use context and rely on a length check to see if the element is present after the dom is ready.
$(document).ready(function(){
  var container = $('.action_name.controller_name');
  if(container.length == 0)return;
  console.log('write script here')
})


Agent: handle socket errors while connecting to the proxy

Passing client socket to the request on error allows it to be handled (vs aborting the process because of the unhandled exception)

I was just checking out socksv5 and met with an uncaught exception, and this has helped. Thank you.
It'd be great If this can be merged, or someone can provide a pointer to another solution.

I agree It should be merged. It works for me too.

I'm not sure this is the right approach. This PR seems to be passing a socket as "valid" whenever an error occurs. Is the point to allow the Agent implementation to be able to clean up the socket immediately after the error occurs? It seems like there may still be the possibility of the Agent to pass the socket out as valid for a short period of time?
Also while on the topic, I'm thinking of ditching the copy of node's internal http.Agent code for the async agent.createConnection() functionality which will arrive in node v6.0.0 and will simplify this code greatly.

seems to be related #19

Not sure if it's the right code to be merged with master, but it's worked for me just fine. I was glad to be able to catch errors instead of application being dead.
Any ideas how to catch "Authentication failed" error using another method?

I also encountered this error and made a change in the library that reemited the error in the request object:
client.on('error', err=>req.emit('error', err));
This way, it allows Authentication Failed and other types of errors to be handled outside of the library.


Provide a simple "slide in" transition example

Blocked by #2, #3.
This transition should be a simple TransitionDirector instance.
Only one plan should be registered: the right view controller "shifting up" during presentation.

[ ] Create an MDMSlideTransitionDirector class.
[ ] Implement the slide transition using the CoreAnimation motion family.

This transition should support any direction of sliding when being presented.

Closed by 36db601f29b9a04900028c8c51d6219470b75d4c


add josuemurhabazi

@josuemurhabazi, I'm quite elated about your pull request. I wanna evolve this project to addresses various problems faced by first-time contributors. I'd love to learn about your journey in open source community, the problems, pain points you had etc.
Could you explain how you felt when you went through the tutorial, made a pull request and learned that I merged it?
We’ve recently added Facebook share and tweet feature to our web app. Could you please go to https://roshanjossey.github.io/first-contributions/#social-share and share your first contribution to open source?
Also, check out projects with easy issues while you’re there.

it was a bit challenging and interesting.
and I would like to know more about github and contribute again.
thank you for the opportunity,
2017-10-31 17:28 GMT+03:00 Roshan Jossey<EMAIL_ADDRESS>
Merged #1562
https://github.com/Roshanjossey/first-contributions/pull/1562.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Roshanjossey/first-contributions/pull/1562#event-1318863235,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Aae0yNISSbsBaTKqsbnkYIaU15Bj1ZVYks5sxy6YgaJpZM4QMyUx
.


More accurate "auction begins" data in auction info VC.

Fix for https://github.com/artsy/auctions/issues/175. Basically we want to show the live start time instead of the auction open time (if it's a live auction).

Looks good!


Add p-values in 1D LLR scans when comparing 0 and 1

The use-case is for LLR scans as a function of mu (individual mus, or combined ones) so that one could immediately gauge the significance.
The result would be similar to what is shown in the insets of the Bs mumu measurement:

This is now stored (in quantilExpected)


Backend API: add 'unlink' call

Symmetric of 'link' : when deleting a link, unlink it from source and target resources

Related to https://github.com/erocci/erocci/issues/79


License not available

Can you please let me know under which license this code is released? Is it permissible to use for commercial purposes?

Hi @tarunsk1998 , I am sorry for being not quite experienced in this topic, especially considering the paper is just a preprint and not published yet.
I am perfectly ok for people use this code for commercial purposes. But regarding the technical details for the licensing, I may need to consult my advisor. For now I suggest to use the code in anyways to your convenience and I will get back to this issue in a week.

I would like to know about the license too. Waiting for the update

Hi @tarunsk1998  @glad4enkonm, I have set the LICENSE to be MIT after discussion with my advisor. Hope it works for you.


LSP server crashes when using custom json schema with vscode extension v0.19.0 (taplo/lsp v0.6.0)

Hey, thanks for your work on this extension / toolset particularly the LSP.
I've been trying to get the LSP to work with monaco in a browser and got some panics inside the LSP. At first I thought it was me because I wasn't getting them in vscode, however I then realized I was using v0.14.2 of the extension which uses an earlier version of the LSP and toolset etc. So then I installed v0.19.0 of the vscode extension and found I could reproduce the LSP crashes inside vscode. So must be something more fundamental.
The LSP crash manifests in vscode as vscode trying to restart the LSP, but getting stuck in a crash loop and then eventually it shows a little pop up.
The Even Better TOML LSP server crashed 5 times in the last 3 minutes. The server will not be restarted. See the output for more information.

But the real thing I'm interested in is why the LSP crashed in the first instance, although it raises the side question of why the LSP server fails to restart .
I can get the LSP to crash rather easily when using a custom json schema. Here's a test schema:
{
   "$ref": "#/definitions/TestSchema",
   "definitions": {
     "TestSchema": {
       "type": "object",
       "required": [
         "statements"
       ],
       "properties": {
         "statements": {
           "title": "stataments",
           "description": "statements description",
           "type": "array",
           "items": [
             {
               "title": "Create",
               "type": "object",
               "properties": {
                 "create": {
                   "description": "description for create object",
                   "title": "create",
                   "type": "object",
                   "properties": {
                     "a": {
                       "description": "description for property a",
                       "type": "string"
                     }
                   },
                   "required": [
                     "a"
                   ],
                   "additionalProperties": false
                 }
               },
               "required": [
                 "create"
               ],
               "additionalProperties": false
             }
           ]
         }
       }
     }
   }
 }

I can get the lsp to crash under these conditions:

Request an auto completion (e.g. ctrl space shortcut) at the end of line 2

#:schema ./testSchema.json
[]

gets this error in extension logs
panicked at 'called `Option::unwrap()` on a `None` value', /home/runner/work/taplo/taplo/crates/taplo/src/util/mod.rs:169:10

Stack:

Error
    at AA.w.wbg.__wbg_new_693216e109162396 (/home/***/.vscode/extensions/tamasfe.even-better-toml-0.19.0/dist/server.js:2:5792)
    at wasm://wasm/00f689f6:wasm-function[5286]:0x320b3a
    at wasm://wasm/00f689f6:wasm-function[2552]:0x2dd09e
    at wasm://wasm/00f689f6:wasm-function[4322]:0x3163e4
    at wasm://wasm/00f689f6:wasm-function[4122]:0x312ad9
    at wasm://wasm/00f689f6:wasm-function[501]:0x1c9b5c
    at wasm://wasm/00f689f6:wasm-function[61]:0x103f3
    at wasm://wasm/00f689f6:wasm-function[102]:0x9c0a7
    at wasm://wasm/00f689f6:wasm-function[3144]:0x2f9465
    at wasm://wasm/00f689f6:wasm-function[74]:0x518ee

Request an auto completion at the start of line 4

#:schema ./testSchema.json
[[statements]]
[statements.create]

gets error
panicked at 'called `Option::unwrap()` on a `None` value', /home/runner/work/taplo/taplo/crates/taplo-lsp/src/query.rs:259:37

Stack:

Error
    at AA.w.wbg.__wbg_new_693216e109162396 (/home/***/.vscode/extensions/tamasfe.even-better-toml-0.19.0/dist/server.js:2:5792)
    at wasm://wasm/00f689f6:wasm-function[5286]:0x320b3a
    at wasm://wasm/00f689f6:wasm-function[2552]:0x2dd09e
    at wasm://wasm/00f689f6:wasm-function[4322]:0x3163e4
    at wasm://wasm/00f689f6:wasm-function[4122]:0x312ad9
    at wasm://wasm/00f689f6:wasm-function[406]:0x1a3b59
    at wasm://wasm/00f689f6:wasm-function[61]:0x145f3
    at wasm://wasm/00f689f6:wasm-function[102]:0x9c0a7
    at wasm://wasm/00f689f6:wasm-function[3144]:0x2f9465
    at wasm://wasm/00f689f6:wasm-function[74]:0x518ee

I also noticed that in v0.14.2 I would have descriptions from the json schema show on hover, but this doesn't happen in v0.19.0.
My feeling is that the position of the cursor is getting out of sync with the state of the DOM, but that's just a guess. In my monaco troubleshooting I tried calling the textDocument/semanticTokens/full method on the LSP to get a look into the parsed representation, but it always returns an empty array regardless of the text of the editor which surprised me. I don't know if this is significant or not, I'm not familiar with LSP so I don't know what would be expected.

I'm seeing this as well while setting files in a starship.toml file. They recommend starting the file with:
# Get editor completions based on the config schema
"$schema" = 'https://starship.rs/config-schema.json'

0.19.0 works fine for my Codium, but 0.19.1 keeps crashing after selecting a schema

This looks like a duplicate of #434 which has been fixed by #462 and waiting #473 to get released.


Bug: unwanted addition of classical bits via measure_all

Where does the issue happen?
https://qiskit.org/textbook/ch-appendix/qiskit.html
What is the content issue?
Environment

qiskit.version: 0.22.0
Python version: 3.8.0
Operating system: Ubuntu 18.04

What is happening?
In the notebook qiskit.ipynb the measure_all api call creates a register even if the qc already has a classical register of size 5. This is due to the default behavior of measure_all which always insert a new register if not explicitly mentioned otherwise.
Screenshots
How can we reproduce the issue?
Run the cell with the following code:
qc = QuantumCircuit(5,5)
qc.x(0)
for q in range(4):
    qc.cx(0,q+1)
qc.measure_all()
qc.draw()

Output:
        ┌───┐                     ░ ┌─┐
   q_0: ┤ X ├──■────■────■────■───░─┤M├────────────
        └───┘┌─┴─┐  │    │    │   ░ └╥┘┌─┐
   q_1: ─────┤ X ├──┼────┼────┼───░──╫─┤M├─────────
             └───┘┌─┴─┐  │    │   ░  ║ └╥┘┌─┐
   q_2: ──────────┤ X ├──┼────┼───░──╫──╫─┤M├──────
                  └───┘┌─┴─┐  │   ░  ║  ║ └╥┘┌─┐
   q_3: ───────────────┤ X ├──┼───░──╫──╫──╫─┤M├───
                       └───┘┌─┴─┐ ░  ║  ║  ║ └╥┘┌─┐
   q_4: ────────────────────┤ X ├─░──╫──╫──╫──╫─┤M├
                            └───┘ ░  ║  ║  ║  ║ └╥┘
   c: 5/═════════════════════════════╬══╬══╬══╬══╬═
                                     ║  ║  ║  ║  ║
meas: 5/═════════════════════════════╩══╩══╩══╩══╩═
                                     0  1  2  3  4

Where two circuits are present: c and meas. The first one is the one we created, the second one is the one created by measure_all.
What should happen?
I would expect the existing classical register to be used instead to avoid waste of space.
Additional information
Any suggestions?
Following the documentation of the measure_all method, it is possible to measure the qubits directly, without adding an extra register. The code should be changed to:
qc.measure_all(add_bits=False)

I can handle this, should be a quick fix

@MattePalte Can you link the corresponding page on the new textbook, or move this issue over to the old textbook repository https://github.com/qiskit-community/qiskit-textbook

If you mean the link to the actual file, you can find it by clicking the filename qiskit.ipynb in my issue or here.
If I misunderstood, please let me know which specific link you need.
Thanks in advance

just for clarification
in regards to the legacy textbook:
the notebook for this page: https://qiskit.org/textbook/ch-appendix/qiskit.html
is located here: https://github.com/qiskit-community/qiskit-textbook/blob/main/content/ch-appendix/qiskit.ipynb
for the (newer) textbook beta:
this notebook: https://github.com/Qiskit/platypus/blob/main/notebooks/ch-appendix/qiskit.ipynb
is for this page: https://learn.qiskit.org/course/ch-appendix/basic-qiskit-syntax
issues for the legacy textbook should be added to the repo: https://github.com/qiskit-community/qiskit-textbook
and issue for the newer textbook should be added in this repo

This repository is no longer maintained. It has been superseded by IBM Quantum Learning.


diff view for large files scroll to wrong position when click on diff map panel

VSCode Version: Code 1.6.0 (e52fb0bc87e6f5c8f144e172639891d8d8c9aa55, 2016-10-10T18:37:40.189Z)
OS Version: Windows_NT ia32 10.0.14393
Extensions: donjayamanne.githistory-0.1.0, formulahendry.code-runner-0.3.4, slevesque.vscode-hexdump-1.0.0, waderyan.gitblame-1.3.0

Steps to Reproduce:

edit any large text file (15000+ lines)
Git / open diff view for modified file
click on any place of diff map panel (where we can see red/green bars)

Expected: New scroll position = position of bottom part highlighted zone of diff panel.
Actual: New scroll position = position of bottom part of scroll bar. Visually it looks like I click on scrollbar of "diff map panel", but scroll work like I click on real scrollbar, which is on nearest but another panel.

For huge files, I agree it is a bit difficult to jump to the change using the diff overview ruler. But that is why we have the two actions to jump to next/prev change...


README

README
User Story
As a boot camp student,
I want the prework notes to be structured on a webpage,
So that I can easily find and read the information.
Acceptance Criteria
GIVEN the prework project repository,
WHEN I view the README for the repository,
THEN I can see a professional README that provides information on the project and how to use it

README file written and available in the repo.


Error 500 when trying to join space with github login

When I try to join a space, all I see is an error. A toast in VS Code shows:
Command 'Live Share Spaces: Join Space' resulted in an error (Request failed with status code 500)

And the VS Code window log shows:
[2020-07-29 10:09:28.545] [renderer1] [error] Request failed with status code 500: Error: Request failed with status code 500
	at e.exports (c:\Users\Edward Browncross\.vscode\extensions\vsls-contrib.spaces-0.1.2\out\extension.js:1:50450)
	at e.exports (c:\Users\Edward Browncross\.vscode\extensions\vsls-contrib.spaces-0.1.2\out\extension.js:1:110355)
	at IncomingMessage.<anonymous> (c:\Users\Edward Browncross\.vscode\extensions\vsls-contrib.spaces-0.1.2\out\extension.js:8:5340)
	at IncomingMessage.emit (events.js:208:15)
	at endReadableNT (_stream_readable.js:1168:12)
	at processTicksAndRejections (internal/process/task_queues.js:77:11)

To investigate further, I started a local instance of the service, which gave this error:

Hey @edwardbrowncross , pardon for the trouble, I'll investigate the issue shortly. AFAIR LiveShare requires an email on the profile to properly work, so at this point, it is not clear if that the issue on the Spaces side or not. Are you able to use LiveShare with this account?

Created the PR to fix this: https://github.com/vsls-contrib/spaces/pull/125 Please confirm that it solves your issue.

Thanks for looking at this so quickly! Yes I am able to use LiveShare. My colleagues, who all have had the same experience as me, can also use it. We all have (null) as our email address though as this screenshot shows:

In case it helps, my LiveShare user profile data looks like this:
{
    "initialProvider": "github",
    "status": "accepted",
    "registrationData": {},
    "providers": {
        "github": {
            "id": "35063432",
            "profileUrl": "https://github.com/edwardbrowncross",
            "displayName": "Edward Browncross",
            "username": "edwardbrowncross",
            "initials": "EB",
            "provider": "github",
            "photos": [
                {
                    "value": "https://avatars2.githubusercontent.com/u/35063432?v=4"
                }
            ],
            "emails": []
        }
    },
    "signupTime":<PHONE_NUMBER>571,
    "telemetryId": "1b50d591-8e7b-49cf-bdb3-31521f063035",
    "id": "acaddbe1-d891-4548-ab43-28e7f138c568",
    "workspaces": []
}

Thanks, AFAIR LiveShare was dependent on the emails to be present at some point and looks like that have changed recently. Unfortunately, the LS Spaces client expects the email to be present in many places and that will need to be refactored. From my smoke testing, the PR above makes LS Spaces usable, but of course, I could not do the comprehensive testing tonight. cc @lostintangent