gli-version

I had a newer gli-gem installed (2.14.0), but 2.13.2 is expected from reveal-ck. If I uninstall 2.13.2, or have both installed, reveal-ck breaks:
/usr/lib/ruby/2.3.0/rubygems/specification.rb:2287:in `raise_if_conflicts': Unable to activate reveal-ck-3.4.0, because gli-2.14.0 conflicts with gli (= 2.13.2) (Gem::ConflictError)
Is this expected, or is there some reason to require the specific older 2.13.2?

Hey there!
Thanks for taking the time to speak up!
I hope you're liking reveal-ck and it's useful to you.
It's expected (by me) that the versions are locked tightly in that reveal-ck is more like an 'app' than it is a 'library.'
There was a time when I let the versions vary until a major version change, but I encountered bugs from combinations of libraries interacting with each other.
My solution was to lock the versions quite tightly and suggest that people use a Gemfile whenever using reveal-ck.
The Gemfile would include reveal-ck and once you ran a bundle the Gemfile.lock would hold the required version of gli and so when you ran commands with bundle exec reveal-ck you'd get the right version even if you had 10 versions installed.
When I look at my setup, I have two versions of gli installed like you do, but things are working for me:
$ gem list | grep gli
gli (2.14.0, 2.13.2)

If I uninstall gli 2.13.2 then it fails (as you'd expect):
reveal-ck --version
/opt/rubies/2.2.4/lib/ruby/2.2.0/rubygems/dependency.rb:315:in `to_specs': Could not find 'gli' (= 2.13.2) - did find: [gli-2.14.0] (Gem::LoadError)

And when I installed it again things are all good:
$ gem install gli -v 2.13.2
Fetching: gli-2.13.2.gem (100%)
Successfully installed gli-2.13.2
1 gem installed
$ reveal-ck --version
reveal-ck version 3.4.0

gli version 2.13.2 dates back to more than a year and a half ago.
I periodically update all of the libraries to the latest version-- let me take a look at doing that.
If we go that route, I'd open a PR with new library versions and publish a new version of reveal-ck. The new version of reveal-ck would use the latest version of gli.
I'll update this issue if/when that happens.

gli was upgraded to 2.14.0 with the release of reveal-ck v. 3.5.1.
Let me know if you have any further issues.
Thanks!


Xlsx files from gsheets are not parsed in the same way as ones from mac and windows spreadsheets

As comes from the title, we have a strange behavior on the parsing side.
Mac and Windows work great, but gsheet converts to strangely high numbers.

gSheets latest version as of 21/09/2020
Windows 10 with latest excel
Mac with the latest Catalina Numbers

Tell me please if you need more info.
Here are images and files:

Cryotherapy.gsheet.xlsx
Cryotherapy.mac.xlsx
Cryotherapy.windows.xlsx

Checked with Numbers again, I have an auto date conversion :O

gsheets is writing the format code as d.m.  That is technically a bug on Google's side, as it should have been d\.m or d"."m (escaping the period).
If you open the gsheet export in Excel 2019 and save as XLSX, it rewrites the number format to d\.m, which means Excel is actually auto-correcting the format.  SSF should probably do the same


Support extra flags and feature gates in kube manifests

This PR adds support for passing optional extra flags/feature gates to the the kube apiserver, controller-manager and scheduler.

Its fine to fork and add feature gate or alpha flags as needed. In Typhoon, I don't aim to offer every option or field questions about alpha/experimental features.

If there are specific feature gates or options that have matured to the point they can be enabled for everyone, I'd welcome those suggestions.
Thanks for the PR, but as it stands I don't relish maintaining/supporting the extra options.

Cool! Thanks!

Almost submitted a similar PR and wanted to make the case for a narrower version of this. Forks work well for custom behavior but start to hurt once you have dependencies. For most typhoon updates a fork maintainer needs to merge terraform-render-bootkube changes and set the right ref when merging typhoon.
In my case I just want the --oidc-* flags for authentication. I don't think there's a reason to split out feature gates and extra flags or even use the word flags in the variable name. To me this is similar level of advanced customization to merging CL snippets but with lower maintenance costs. It avoids the need to fork for non-invasive, additive changes. Making the feature as generic as possible hopefully minimizes the implied support for anything a user might pass.


HTML Component - remove superfluous views

Stack from ghstack (oldest at bottom):

-> #41

Contents in views folder repeats itself, this diff promotes the content to directory.tsx to save the number of files.

Related to #24


[FEAT] Add a search bar to find snippets

Add a search bar to the header section of the website 1loc.dev. So users can search the snippets they need. I don't know how to do it. The snippets are in MD files. Does anyone know how to add the search functionality to it?

Since you can not search on all snippets on the page directly with this new page format, this is a feature needed !
Please :)


add Root Hook Plugins

(documentation will be in another PR; this depends on #4237)

Adds "root hook plugins", a system to define root hooks via files loaded with --require.
This enables root hooks to work in parallel mode.  Because parallel mode runs files in a non-deterministic order, and files do not share a Mocha instance, it is not possible to share these hooks with other test files.  This change also works well with third-party libraries for Mocha which need the behavior; these can now be trivially consumed by adding --require or require: 'some-library' in Mocha's config file.
The way it works is:

When a file is loaded via --require, we check to see if that file exports a property named mochaHooks (can be multiple files).
If it does, we save a reference to the property.
After Yargs' validation phase, we use async middleware to execute root hook plugin functions--or if they are objects, just collect them--and we flatten all hooks found into four buckets corresponding to the four hook types.
Once Mocha is instantiated, if it is given a rootHooks option, those hooks are applied to the root suite.

This works with parallel tests because we can save a reference to the flattened hooks in each worker process, and a new Mocha instance is created with them for each test file.

Tangential:

Because a root hook plugin can be defined as an async function, I noticed that utils.type() does not return function for async functions; it returns asyncfunction.  I've added a (Node-specific, for now) test for this.
handleRequires is now async, since it will need to be anyway to support ESM and calls to import().
fixed incorrect call to fs.existsSync()

Ref: #4198

Coverage increased (+0.05%) to 93.113% when pulling 50e9a7a27f8c6894b249e10511344dc1996ceacf on boneskull/issue/2839-root-hook-plugins into 6838eaf66b94445e314f087ec407d7e2b5bf1fb5 on master.

Once Mocha is instantiated, if it is given a rootHooks option, those hooks are applied to the root suite.

We have one Mocha instance and one root suite per each child-process, right?
Isn't it possible to use one mocha over all child-processes?

@juergba

Once Mocha is instantiated, if it is given a rootHooks option, those hooks are applied to the root suite.

We have one Mocha instance and one root suite per each child-process, right?

This is correct.

Isn't it possible to use one mocha over all child-processes?

It isn't possible to share a single mocha instance across multiple child processes, no.  There's no way to share an object reference via IPC (afaik).
It's not impossible for a single child process to reuse a Mocha instance.  In fact, PR #4245 could take advantage of @nicojs' PR #4234 to do so.  I haven't looked closely at that PR, so I'm unsure if the root suite would be reset or not.  If we were to use that, root beforeAll and afterAll hooks would only be called once per child process.  In the current state of #4245, these are called for each file.

somehow accidentally closed this

@juergba waiting for response from you in the comments, and also pls @mochajs/core take a look.
I want to make sure

If we add an API like this, we are comfortable living with it for awhile, and
We understand why it should be a thing
We understand the limitations (there's currently no way, when running tests in parallel, to run a root "before all"/"after all" hook once and only once; they happen once per child process)

I guess I'm pretty late to the party 💃, but just wanted to ask anyway. Be sure to throw me out if I'm drunk talking to random women at the bar.
Why do we need a new 'rootHooks' pattern? I think most people are defining their root hooks in setup files which they load with --file . Can't we just make sure to load those files in each child runner?
Since --concurrent will be a new feature, it's not breaking to enforce the best practice of marking root hooks with --file I think.

Why do we need a new 'rootHooks' pattern? I think most people are defining their root hooks in setup files which they load with --file . Can't we just make sure to load those files in each child runner?

Unfortunately, we're not guaranteed this is the case.  --file could be used for anything and can contain tests.
As it stands, --file is not compatible with parallel mode, as it runs tests in a non-deterministic order.  Not only that, but a new Mocha instance is created for each file, which means something loaded via --file would run not just for every child process, but for every file of every child process.  That's fine if it just contains root hooks, but again, it's not guaranteed.
Another approach would be to load files specified with --file in the main process, and check to ensure it doesn't contain tests.  If it doesn't, then we could use it for root hooks. So, if we loaded all of the test files in the main process (but did not run them) we could enable some behavior that doesn't currently work in parallel mode (exclusive tests and a few reporters are incompatible).  I had planned on looking at that later on, if it was needed.
Philosophically, though, I don't want to make --file mean one thing in serial mode and another thing in parallel mode.  Adding yet another file-loading option specific to parallel mode sounded confusing for users to me.
What do you think?

FWIW, you could also define root hooks this way:
// test/index.js

beforeEach(function() {
  // I'm a root hook!
});

require('./test-a.spec.js');
require('./test-b.spec.js');
require('./test-c.spec.js');

// run with `mocha`, no options

😄

Philosophically, though, I don't want to make --file mean one thing in serial mode and another thing in parallel mode. Adding yet another file-loading option specific to parallel mode sounded confusing for users to me.

This is a great argument, thanks.
What about adding a new argument --setup or --setup-file or --global-setup? I guess it's comparable to mochaHooks export, but then more in line with how mocha is currently working. This is also in line with how jest's globalSetup file works.  It would save me some discussions with colleagues that don't put global hooks in --file setup files. Frankly, I've searched for something like --setup for a couple of times on the main mocha site and always ended up concluding that --file was the place to put global hooks.
We could disable describe and it in setup files, to make sure nobody is misusing them. In time, we could also go one step further and log a warning if users declare global hooks in other (regular) files.

What about adding a new argument --setup or --setup-file or --global-setup?

Sounds sensible to me. Could see this adding to the user confusion around whether to use file or require. Hopefully no issues running once per child process + still use rootHooks.
Assuming waiting for more feedback before adding docs, which is fine.

@craigtaub docs are in #4246

re: --setup.  I'm not entirely opposed, but we run the risk of just adding more and more flags if we want to support some other kind of plugin.
this is why I wanted to use --require + a convention.  this would position mocha to define more such conventions in the future to expose more kinds of plugins.
if we use --setup, it can only really be used for this one thing, and if we want to do something else, then the precedent is to create yet another option.
things that could be supported via --require + convention include, but are not limited to:

easier interface definition
easier reporter definition
custom Runners (e.g., a worker-thread based runner)
custom stats collecting
snapshot test hooks
tighter integration with assertion & mocking libraries

Could see this adding to the user confusion around whether to use file or require

If we merged this, I think we would want to be explicit: do not use --file for root-level hooks.  --file is intended to describe a specific order in which test files run, not for root hook definition.

I note that you could do this, with minimal changes:
// .mocharc.js

module.exports = {
  require: [
    'source-map-support',
    'something-else',
    {
      mochaHooks: {
        beforeEach() {
          this.foo()
        }
      }
    }
  ]
};

@nicojs @craigtaub What do you think of my argument above?  Convinced or no?

Sure, that makes sense. Didn't know about other plugins yet. If you need a plugin system, this makes sense.
module.exports = {
  require: [
    'source-map-support',
    'something-else',
    {
      mochaHooks: {
        beforeEach() {
          this.foo()
        }
      }
    }
  ]
};

This would work, except not for --concurrent mode, right?

@nicojs
module.exports = {
  require: [
    'source-map-support',
    'something-else',
    {
      mochaHooks: {
        beforeEach() {
          this.foo()
        }
      }
    }
  ]
};

I'm not sure I understand.  The above would theoretically work as a .mocharc.js with parallel: true or not.  I just need to modify the codebase to know what to do with a require value that isn't a string.

(rather, you're right, I'd need to re-load the config file for each child process, because even if I did serialize and eval the damn thing it'd be missing the enclosing scope)

anyway, not gonna do that right now.  still: a --require foo.js where foo.js exports a mochaHooks prop will work with --parallel or without.

I've created a small serialization library you might want to look at for communicating between child process and main process: https://www.npmjs.com/package/surrial
We're using it in Stryker for the same reason.
Anyway, it won't solve the enclosing scope issue. You cannot simply pick up a function and serialize / deseriaze it and expect every scenario to work.
You could, however, load the config files in child processes for this reason.
That's all totally out of scope for this PR. And off topic.

What do you think of my argument above? Convinced or no?

Yep good point, plugin system sounds useful.

@nicojs Thanks.  There are a lot of serialization libs out there--I just picked one.
You're welcome to try to replace the adhoc serialization stuff with surrial, but we have to be careful about a) performance, b) transmitting exceptions, and b) self-referential objects--e.g., I'm not serializing the entirety of a Suite for performance reasons.

something is weird with github.  the build (on travis anyway) has passed

still waiting on appveyor.

travis passed.


build warning on  cast removes address space '__cache' of expression

Describe the bug
Sparse warning on use of __cache attribute:
https://github.com/thesofproject/sof/actions/runs/8422916305/job/23063323303?pr=8981
/zep_workspace/zephyr/soc/intel/intel_adsp/ace/power.c:46:12: warning: cast removes address space '__cache' of expression
/zep_workspace/zephyr/soc/intel/intel_adsp/ace/power.c:48:9: warning: incorrect type in argument 1 (different address spaces)
Regression in
To Reproduce
https://github.com/thesofproject/sof/actions/runs/8422916305/job/23063323303?pr=8981
Expected behavior
No sparse warnings on __cache attribute usage.
Impact
Build warning
Logs and console output
https://github.com/thesofproject/sof/actions/runs/8422916305/job/23063323303?pr=8981
Environment (please complete the following information):

https://github.com/thesofproject/sof/actions/runs/8422916305/job/23063323303?pr=8981

Additional context
Regression in commit 6b9d01f995c72d1c747a98dbc866d052a0f29cb0  . Seems cache_data_flush_range() does not have cache attributes.

@ceolin  can you please take a look?

@nashif , @ceolin can we add this check to either main/.github or Internal Intel CI? Either would shorten the feedback loop considerably.
The required dependencies are small:
thesofproject/sof@0698fa334ae16b7709f08

I think so ... also we probably need to have our sparse fork. The way it is on Zephyr right now assumes that you can get any sparse (from your distro for example) and it will work

thesofproject/sof@0698fa334ae16b7709f08

I think so ... also we probably need to have our sparse fork.

Compile a reasonably recent version from the sparse main branch: yes. This is trivial, see link above.
"Fork": no, not needed any more. We worked with the sparse maintainer and sparse now works with Zephyr out of the box.

All what's required is at the link above, it's pretty short.


Analyzing can't stop at VSCode

Steps to Reproduce

Use flutter 2.0.4.
Open project flutter using vscode
i want to migrate to null-sefty code from 1.22.5 to 2.0.4, when i changed sdk at pubspect.yaml, and then im restart vscode, and reopen vscode but analyzing loading can't stop, and my CPU it's going to crazy (100%)

Expected results:
analyzing done a few second or minute
Actual results:
analyzing can't stopped

Logs

[✓] Flutter (Channel unknown, 2.0.4, on Mac OS X 10.15.7 19H2 darwin-x64, locale en-ID)
    • Flutter version 2.0.4 at /Users/dafinoer/fvm/versions/2.0.4
    • Framework revision b1395592de (3 days ago), 2021-04-01 14:25:01 -0700
    • Engine revision 2dce47073a
    • Dart version 2.12.2

[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.3)
    • Android SDK at /Users/dafinoer/Library/Android/sdk
    • Platform android-30, build-tools 29.0.3
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_202-release-1483-b49-5587405)
    • All Android licenses accepted.

[!] Xcode - develop for iOS and macOS
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 11.7, Build version 11E801a
    ! Xcode 11.7.0 out of date (12.0.1 is recommended).
      Download the latest version or update via the Mac App Store.
    ! CocoaPods 1.8.4 out of date (1.10.0 is recommended).
        CocoaPods is used to retrieve the iOS and macOS platform side's plugin code that responds to your plugin usage on the Dart side.
        Without CocoaPods, plugins will not work on iOS or macOS.
        For more info, see https://flutter.dev/platform-plugins
      To upgrade see https://guides.cocoapods.org/using/getting-started.html#installation for instructions.

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 3.5)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 44.0.1
    • Dart plugin version 191.8593
    • Java version OpenJDK Runtime Environment (build 1.8.0_202-release-1483-b49-5587405)

[✓] VS Code (version 1.55.0)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.21.0

[✓] Connected device (1 available)
    • Chrome (web) • chrome • web-javascript • Google Chrome 89.0.4389.114

! Doctor found issues in 1 category.

i want to migrate to null-sefty code from 1.22.5 to 2.0.4, when i changed sdk at pubspect.yaml, and then im restart vscode, and reopen vscode but analyzing loading can't stop, and my CPU it's going to crazy (100%)

did you follow the docs?
what is the output of these commands?
I recommend to  branch your project before
dart pub outdated --mode=null-safety
pub upgrade --null-safety
dart pub get

Hi @dafinoer
Along with the above solution, also try to execute the following
flutter pub upgrade
flutter pub get

If the problem persists, Can you please test the app from terminal and execute flutter analyze
Thank you

Without additional information, we are unfortunately not sure how to resolve this issue.
We are therefore reluctantly going to close this bug for now.
Please don't hesitate to comment on the bug if you have any more information for us; we will reopen it right away!
Thanks for your contribution.
Could everyone who still has this problem please file a new issue with the exact description of what happens, logs, and the output of flutter doctor -v.
All system setups can be slightly different, so it's always better to open new issues and reference related issues.


🎏 Missing Translations master tracker

Ticket to track all missing translations
🇮🇹 Italian

[x] ./exampleSite/content/_index.it.md
[x] ./exampleSite/content/authors/_index.it.md
[x] ./exampleSite/content/authors/nunocoracao/_index.it.md
[x] ./exampleSite/content/authors/secondauthor/_index.it.md
[x] ./exampleSite/content/docs/_index.it.md
[ ] ./exampleSite/content/docs/advanced-customisation/index.it.md
[ ] ./exampleSite/content/docs/configuration/index.it.md
[ ] ./exampleSite/content/docs/content-examples/index.it.md
[ ] ./exampleSite/content/docs/firebase-views/index.it.md
[ ] ./exampleSite/content/docs/front-matter/index.it.md
[x] ./exampleSite/content/docs/getting-started/index.it.md
[ ] ./exampleSite/content/docs/homepage-layout/index.it.md
[ ] ./exampleSite/content/docs/hosting-deployment/index.it.md
[x] ./exampleSite/content/docs/installation/index.it.md
[ ] ./exampleSite/content/docs/multi-author/index.it.md
[ ] ./exampleSite/content/docs/partials/index.it.md
[ ] ./exampleSite/content/docs/series/index.it.md
[ ] ./exampleSite/content/docs/shortcodes/index.it.md
[ ] ./exampleSite/content/docs/thumbnails/index.it.md
[x] ./exampleSite/content/docs/welcome/index.it.md
[ ] ./exampleSite/content/examples/_index.it.md
[ ] ./exampleSite/content/guides/_index.it.md
[ ] ./exampleSite/content/guides/template/index.it.md
[x] ./exampleSite/content/samples/_index.it.md
[ ] ./exampleSite/content/samples/charts/index.it.md
[ ] ./exampleSite/content/samples/diagrams-flowcharts/index.it.md
[ ] ./exampleSite/content/samples/emoji/index.it.md
[ ] ./exampleSite/content/samples/external/index.it.md
[ ] ./exampleSite/content/samples/markdown/index.it.md
[ ] ./exampleSite/content/samples/mathematical-notation/index.it.md
[ ] ./exampleSite/content/samples/multiple-authors/index.it.md
[x] ./exampleSite/content/samples/placeholder-text/index.it.md
[ ] ./exampleSite/content/samples/rich-content/index.it.md
[ ] ./exampleSite/content/samples/thumbnail_sample/index.it.md
[x] ./exampleSite/content/tags/_index.it.md
[ ] ./exampleSite/content/tags/advanced/_index.it.md

🇯🇵 Japanese

[x] ./exampleSite/content/authors/nunocoracao/_index.ja.md
[x] ./exampleSite/content/authors/secondauthor/_index.ja.md
[ ] ./exampleSite/content/docs/advanced-customisation/index.ja.md
[ ] ./exampleSite/content/docs/configuration/index.ja.md
[ ] ./exampleSite/content/docs/content-examples/index.ja.md
[ ] ./exampleSite/content/docs/firebase-views/index.ja.md
[ ] ./exampleSite/content/docs/front-matter/index.ja.md
[ ] ./exampleSite/content/docs/getting-started/index.ja.md
[ ] ./exampleSite/content/docs/homepage-layout/index.ja.md
[ ] ./exampleSite/content/docs/hosting-deployment/index.ja.md
[ ] ./exampleSite/content/docs/installation/index.ja.md
[ ] ./exampleSite/content/docs/multi-author/index.ja.md
[ ] ./exampleSite/content/docs/partials/index.ja.md
[ ] ./exampleSite/content/docs/series/index.ja.md
[ ] ./exampleSite/content/docs/shortcodes/index.ja.md
[ ] ./exampleSite/content/docs/thumbnails/index.ja.md
[ ] ./exampleSite/content/docs/welcome/index.ja.md
[x] ./exampleSite/content/samples/_index.ja.md
[x] ./exampleSite/content/samples/charts/index.ja.md
[x] ./exampleSite/content/samples/diagrams-flowcharts/index.ja.md
[x] ./exampleSite/content/samples/emoji/index.ja.md
[x] ./exampleSite/content/samples/external/index.ja.md
[x] ./exampleSite/content/samples/markdown/index.ja.md
[x] ./exampleSite/content/samples/mathematical-notation/index.ja.md
[x] ./exampleSite/content/samples/multiple-authors/index.ja.md
[x] ./exampleSite/content/samples/placeholder-text/index.ja.md
[x] ./exampleSite/content/samples/rich-content/index.ja.md
[x] ./exampleSite/content/samples/thumbnail_sample/index.ja.md

🇨🇳 Chinese

[x] ./exampleSite/content/authors/nunocoracao/_index.zh-cn.md
[x] ./exampleSite/content/authors/secondauthor/_index.zh-cn.md
[x] ./exampleSite/content/guides/_index.zh-cn.md
[x] ./exampleSite/content/guides/template/index.zh-cn.md
[x] ./exampleSite/content/samples/charts/index.zh-cn.md
[x] ./exampleSite/content/samples/diagrams-flowcharts/index.zh-cn.md
[x] ./exampleSite/content/samples/emoji/index.zh-cn.md
[x] ./exampleSite/content/samples/external/index.zh-cn.md
[x] ./exampleSite/content/samples/markdown/index.zh-cn.md
[x] ./exampleSite/content/samples/mathematical-notation/index.zh-cn.md
[x] ./exampleSite/content/samples/multiple-authors/index.zh-cn.md
[x] ./exampleSite/content/samples/placeholder-text/index.zh-cn.md
[x] ./exampleSite/content/samples/rich-content/index.zh-cn.md
[x] ./exampleSite/content/docs/hosting-deployment/index.zh-cn.md
[x] ./exampleSite/content/guides/202310-blowfish-tutorial/index.zh-cn.md
[x] ./exampleSite/content/samples/placeholder-text/index.zh-cn.md

FYI @Weaxs @Lemon73-Computing @BabaRagnarok @Aphcity

🇨🇳 Chinese

[ ] ./exampleSite/content/docs/hosting-deployment/index.zh-cn.md
[ ]  ./exampleSite/content/guides/202310-blowfish-tutorial/index.zh-cn.md
[ ] ./exampleSite/content/samples/placeholder-text/index.zh-cn.md

🇨🇳 Chinese

[ ]  ./exampleSite/content/docs/hosting-deployment/index.zh-cn.md
[ ]   ./exampleSite/content/guides/202310-blowfish-tutorial/index.zh-cn.md
[ ]  ./exampleSite/content/samples/placeholder-text/index.zh-cn.md

already added to the main list thanks @Weaxs

@Weaxs @Lemon73-Computing @BabaRagnarok @Aphcity
Any update to add here?

@Weaxs @Lemon73-Computing @BabaRagnarok @Aphcity Any update to add here?

Is it neccessary to maintain a list of docs which are pending sync if someone modifies them ?
I saw doc for shortcode has updated, I will sync it later.

Hi, sorry but I'm very busy these days and I can't keep up with all the commitments I've made. I'm carrying on with the translation as soon as I have some free time


Update element templates docs to indicate Platform

What should we do?
Element templates are a Camunda Platform only feature. Since we now have Camunda Cloud diagram also editable in the Camunda Modeler, we should make clear that this feature is for Camunda Platform BPMN diagrams only.

[ ] Add a note on top to indicate Camunda Platform only support.

Why should we do it?
Minimize confusion, cf. https://forum.camunda.org/t/element-templates-with-camunda-cloud/29028/2

I believe this is best  done along with a general documentation overhaul. From the looks of it the screenshots would need to be updated to the new UI, too.

This can be closed since we now as we updated the docs to clarify the execution platforms: https://docs.camunda.io/docs/components/modeler/desktop-modeler/element-templates/defining-templates/


Introduce an additional small delay in _enter_raw_repl

I was having trouble when my 'main code' looked like this:
 with adafruit_dotstar.DotStar(APA102_SCK, APA102_MOSI, 1) as pixels:
    for i in range(10):
        pixels[0] = 0x000070
        time.sleep(.2)

[and, maybe relevantly, running CP3.0 from master branch on Trinket M0]
Putting the small delay here fixes it.
I hope that this also fixes adafruit/circuitpython#636

@jerryneedell mind confirming this? Thanks!

I have confirmed this works for me!  I can access my esp8266 with the current master build and executing a continuous main.py. Thanks @jepler !


Potential low performance in the word pattern for Markdown

Issue Type: Bug
VS Code Version: Code - Insiders 1.67.0-insider (6f26fa19db7e4cd2af57f52fd7009e715c3d7aab, 2022-04-25T05:16:37.067Z)
Problem
https://github.com/microsoft/vscode/blob/6f26fa19db7e4cd2af57f52fd7009e715c3d7aab/extensions/markdown-basics/language-configuration.json#L55
/(\p{Alphabetic}|\p{Number}|\p{Nonspacing_Mark})(((\p{Alphabetic}|\p{Number}|\p{Nonspacing_Mark})|[_])?(\p{Alphabetic}|\p{Number}|\p{Nonspacing_Mark}))*/gu

Let's expand it.
(
    \p{Alphabetic}
  | \p{Number}
  | \p{Nonspacing_Mark}
)
(
  (
      (
          \p{Alphabetic}
        | \p{Number}
        | \p{Nonspacing_Mark}
      )
    | [
        _
      ]
  )?
  (
      \p{Alphabetic}
    | \p{Number}
    | \p{Nonspacing_Mark}
  )
)*

Now we can see a vulnerable path.
(\p{Alphabetic}?\p{Alphabetic})*

Suggestion
We can remove unnecessary paths.
[
  \p{Alphabetic}
  \p{Number}
  \p{Nonspacing_Mark}
]
(
  [
    _
  ]?
  [
    \p{Alphabetic}
    \p{Number}
    \p{Nonspacing_Mark}
  ]
)*

/[\p{Alphabetic}\p{Number}\p{Nonspacing_Mark}]([_]?[\p{Alphabetic}\p{Number}\p{Nonspacing_Mark}])*/gu

Want to submit a pr?

My pleasure.
However, apart from the suggestion above:
/[\p{Alphabetic}\p{Number}\p{Nonspacing_Mark}]([_]?[\p{Alphabetic}\p{Number}\p{Nonspacing_Mark}])*/gu

We can further reduce match steps by "unrolling the loop":
/[\p{Alphabetic}\p{Number}\p{Nonspacing_Mark}]+(?:_[\p{Alphabetic}\p{Number}\p{Nonspacing_Mark}]+)*/gu

Which suits VS Code's need better?
stateDiagram-v2

direction LR

C1 : [\p]

state Group {
    direction LR

    S1 : _
    S2 : [\p]

    [*] --> S1
    [*] --> S2 : ?
    S1 --> S2
    S2 --> [*]
}

[*] --> C1
C1 --> Group
C1 --> [*] : *
Group --> Group : *
Group --> [*]

stateDiagram-v2

direction LR

C1 : [\p]

state Group {
    direction LR

    S1 : _
    S2 : [\p]

    [*] --> S1
    S1 --> S2
    S2 --> S2 : +
    S2 --> [*]
}

[*] --> C1
C1 --> C1 : +
C1 --> Group
C1 --> [*] : *
Group --> Group : *
Group --> [*]

We closed this issue because we don't plan to address it in the foreseeable future. If you disagree and feel that this issue is crucial: we are happy to listen and to reconsider.
If you wonder what we are up to, please see our roadmap and issue reporting guidelines.
Thanks for your understanding, and happy coding!


AbortController not working with this library

The following code results in the fetch executing as normal with no termination.
  require('isomorphic-fetch');

  const controller = new AbortController();

  setTimeout(() => {
    controller.abort();
  }, 2000);

  return fetch(url, { signal: controller.signal })
    .then(response => {
      return response;
    })
    .catch(error => {
      throw new Error(error.message);
    });

Using node-fetch instead of this library allowed me to fix this issue with no other implementation changes.

what solutions were found?

@eeeman1 using node-fetch :)

I created @atuttle/smart-fetch which adds AbortController into the mix, among other things.

I believe this will be coming in the next version of this package.


Support for UTF-8 characters

With this change the lib is able to send messages to SQS with UTF-8 characters

Thanks for the fix.


Use Docker containers in the RTW

Description

Our strategy for the recipe test workflow is to use containers, in order to maximise consistency of environment. This PR will implement use of containers on Jasmin, taking latest container from dockerhub and running with singularity.

Closes #3246
Link to documentation: TBA

Before you get started

[ ] ☝ Create an issue to discuss what you are going to do

Checklist
It is the responsibility of the author to make sure the pull request is ready to review. The icons indicate whether the item will be subject to the 🛠 Technical or 🧪 Scientific review.

[ ] 🛠 This pull request has a descriptive title
[ ] 🛠 Code is written according to the code quality guidelines
[ ] 🛠 Documentation is available
[ ] 🛠 Tests run successfully
[ ] 🛠 The list of authors is up to date
[ ] 🛠 Any changed dependencies have been added or removed correctly
[ ] 🛠 All checks below this pull request were successful

Other success criteria

[ ] Don't break clone_latest_esmvaltool, so that RTW works on platforms that don't support container
[ ] All esmvaltool tasks run from container, without needing to clone the repo

To help with the number of pull requests:

🙏 We kindly ask you to review two other open pull requests in this repository

@esmvalbot Please run examples/recipe_python.yml

@esmvalbot Please run examples/recipe_python.yml

@esmvalbot Please run examples/recipe_python.yml

my apologies @alistairsellar - I was testing, and eventually brought the Bot back to life, and your PR was unlucky enough to be the first one in the list, so I hijacked it - one :beer: for you!

No worries @valeriupredoi , I just assumed that you were stalking my (draft) PR :o)

Hi @alistairsellar
It is our strategy as well. Things work well so far except for Julia. See my issue here #3410
R

nobody cares about Julia, mate 🤣 That said, I'll have a look at fixing her tomorrow 👍

Thanks 😁😉

Thanks for your help with this one @ehogan. It's all now working and tests passing. Successfully completes on both Met Office and Jasmin. Please can you review?

The RTW also completed successfully on JASMIN :) However, the get_esmval task took 28 minutes! 😮 Did I do something wrong? 🤔

Hrrrm, that's very slow. I had observed that it was often slower on LOTUS than running interactively on sci3 (the latter takes about 5 mins). I believe that there are LOTUS performance problems at present, and indeed many of the other tasks are taking longer or timing out for me today (singularity build on sci3 still takes 5 mins today). When the LOTUS problems are resolved I'll test again and open a new issue if significantly longer than 5 mins.

Thanks for the review @ehogan! I believe I've addressed all the comments. The latest code runs for me on both Jasmin and Met Office sites. Are you happy with the new changes?

Thanks @ehogan! Very good final tweaks. Many thanks for all your help with this one!


[BUG] [Rooting] False-positives for certain devices

Bug description
I'm seeing false positive results with some of my users for rooting checks.
I have a small dataset for now,  but something is not right at this point for sure.
The following devices are 100% confirmed to be false-positives:

Android One 11, Xiaomi Mi A3, dev opts unknown
Redmi note 8 pro, miui 11, dev options enabled, adb debugging ON, SafetyNet checks pass out of the box
Redmi Note 8 Pro, Android 11, dev opts enabled

But I've seen some strange results on the backend. Some devices previously shown as non-rooted, ended up being rooted anyways after some time (I run checks periodically in the background). I'm investigating into this as this may be an issue on my side. My hypothesis for now is that there's something intermittent that may affect the testing results.
Here's the KevlarRooting configuration:
KevlarRooting {
    targets {
        root()
        magisk()
        busybox()
        toybox()
        xposed()
    }

    status {
        emulator()
        testKeys()
        selinux {
            flagPermissive()
        }
    }

    allowRootCheck()
}

Out of all those, the selinux permissive flag looks the most suspicious. I think that some devices may have selinux permissive set to true. But the emulator() flag is my second best guess. My app doesn't have the QUERY_ALL_PACKAGES permission so the magisk/busybox/toybox/xposed checks may be useless.
Reproduction steps
Unable to reproduce as all of my devices are rooted and/or emulators
I will update this issue as I get more data. I expect no more than the average amount of users to be rooted which is 7.6% according to Kaspersky lab research data for 2017. (adding some probability margins here and there)
UPD1: I just learned that bootloader is unlocked out of the box on Redmi Note 8 Pro, but the user says they don't have magisk installed.
Running getenforce on the target device yields command not found

More information about one of the target devices:
Manufacturer: Xiaomi
Device: Begonia
Hardware: mt6785
Fingerprint: Redmi/begonia:9/PPR1.180610.011/V<IP_ADDRESS>PGGMIXM:user/release-keys
API 28
MIUI 9 - V11
Bootloader: unknown (??)
No root management apps on device
Selinux: unable to determine

su in the terminal fails

The emulator check returns a DetectableSystemStatus.EMULATOR, but that doesn't mean your device is rooted. That would be if you received a DetectableSystemTarget.ROOT.
Which DetectableSystemStatus / DetectableSystemTarget entries are you getting back in your failed StatusRootingAttestation / TargetRootingAttestation?
If they are not rooted, and you get back a DetectableSystemStatus.ROOT then we might have a problem, but I doubt that's the case.
From how it was built, the idea of Kevlar was reducing false positives as low as possible.
Thus, if something is detected to make kevlar think that the device is rooted, it is more than likely that there is a su binary responding to the probes, since the checks are additive. The issue is always that we may catch less that what there might be, but never more. That's the difference between approximate and unreliable.
Try to remove allowRootCheck() and see if anything changes. It would be helpful to know if those devices have the su binary installed, if so where and its details, as it is what kevlar checks for.
The QUERY_ALL_PACKAGES is for the antipiracy module, not for the rooting. There are no root-managing app checks, as those are often inconclusive. It's like testing for symptoms rather that the disease.
Also, I see you added everything possible in your configuration, but in theory you should only add what you care about.
If you don't mind the selinux status of the device, then it's better to leave it off, so that the data that you do get back is what should make you alert.

The emulator check returns a DetectableSystemStatus.EMULATOR, but that doesn't mean your device is rooted.

Usually, emulators are indeed rooted, easily rootable or otherwise compromised.
Indeed, I actually just fail the check on emulator detection, but your comment made me reconsider my approach.

Which DetectableSystemStatus / DetectableSystemTarget entries are you getting back in your failed StatusRootingAttestation / TargetRootingAttestation?

Providing logs to you or knowing which statuses are failing is proving difficult as I don't have access to logs on user devices in production and do not store such granular information on my app's servers.

Thus, if something is detected to make kevlar think that the device is rooted, it is more than likely that there is a su binary responding to the probes, since the checks are additive.

Like I said, I asked a user to run su in a terminal and the response was command not found. However I don't think only the binary dumper checks may be at fault here. I assume checks failed when any of the attestation conditions are unmet.
I will try to fix the problem by removing selinux permissive flag.
I suspect some oems/rom maintainers mess around with selinux, I used to mess too, and although it's a serious security risk, for purposes of my application this isn't a critical issue.

The QUERY_ALL_PACKAGES is for the antipiracy module, not for the rooting.

Sorry, my mistake, I confused how these two modules work. Just thought you also detekt exposed by its respective companion app. However I think that root-managing apps should be checked. Magisk is gonna be hard indeed, but for people that use magisk, they sometimes also use Riru, Exposed companion, GravityBox, TitaniumBackup or some other app that requires root. I would like to be able to check for these too, but in my opinion we should only add here apps that are definitively root-only (i.e. no non-root functionality users might have used that caused the check to fail).

Providing logs to you or knowing which statuses are failing is proving difficult as I don't have access to logs on user devices in production and do not store such granular information on my app's servers.

Makes sense, the idea indeed is to compute data locally and act basing on the conditions you can / can not accept your app to run in.

I assume checks failed when any of the attestation conditions are unmet.
I will try to fix the problem by removing selinux permissive flag.

The binary dumper output maps only to DetectableSystemTarget.ROOT. Therefore, if running su in the terminal does not produce any notable result, then the binary dumper is probably not at fault.
For instance, Xposed checks will return a DetectableSystemTarget.XPOSED in the attestation.
It is your job to understand what went wrong in a failed attestation, and act accordingly (in compliance with your security environment requirements).
In this case maybe you are assuming that the check fails if any of the attestation component has failed, which is a bit strict.
I should do a better job at explaining this in the docs, will work on it.

I suspect some oems/rom maintainers mess around with selinux, I used to mess too, and although it's a serious security risk, for purposes of my application this isn't a critical issue.

Yes, indeed the selinux() flag is often at fault, since many devices do not have a fully compliant SELinux configuration. But it usually doesn't affect your application like some other elements (namely root access) may: it is only for very dedicated uses.
Furthermore, enabling flagPermissive() will further restrict the set of allowed configurations, as even permissive selinux status will not be tolerated.

I would like to be able to check for these too, but in my opinion we should only add here apps that are definitively root-only (i.e. no non-root functionality users might have used that caused the check to fail).

Exactly! That is actually a hard thing to do, since we don't want faithful/genuine users to fail checks meant to catch root users.
Plus, detecting piracy is more or less ok since it is something aimed exactly at adversarial apps, but targeting third-party apps only as a means to infer root access is questionable at best.
It would be quite straightforward to implement (just like in antipiracy), but it looks like something a financial application would want to implement themselves.


Remove .vs folder with applicationhost.config from repo

Currently it is already marked as ignored file, but it is currently tracked - so we need to remove it.

I think we actually have it in the repo intentionally, but I forgot the particular reason why.
@skofman1 @xavierdecoster

If I remember correctly, the reason we have it is for the localtest.me bindings. It is ignored afterwards, to avoid changes because of people checking out the sources in a different place on disk.

Mh... mh... I noticed the localtest me stuff in applicationhost. I just noticed the file because everytime I open the NuGetGallery solution this file is marked as changed.

Yeah it's pretty annoying to have to unmark applicationhost.config with every single commit. I'm not sure if there's a better solution.

Everytime you launch VS locally, it wants to replace relative paths with absolute paths and these often end up pushed to the remote.
However, there is a way to tell git to ignore changes to an already committed file, so it no longer appears in your pending changes or commits:
git update-index --assume-unchanged .vs/config/applicationhost.config

Source: http://git-scm.com/docs/git-update-index/

For the history books:
The actual useful content of the applicationhost.config that makes it work with the localtest.me binding is this:
        <site name="NuGet Gallery (nuget.localtest.me)" id="2">
            <application path="/">
                <virtualDirectory path="/" physicalPath="D:\Code\GitHub\NuGetGallery\src\NuGetGallery" />
            </application>
            <bindings>
                <binding protocol="http" bindingInformation="*:80:nuget.localtest.me" />
                <binding protocol="https" bindingInformation="*:443:nuget.localtest.me" />
            </bindings>
        </site>

Unfortunately vs is creating this monster xml and without this setting nothing works.
The current solution is not ideal, but the only other way would be to enhance EnableLocalTestMe.ps1 to create the applicationhost.config with the correct binding - but this is also not very elegant.
Maybe the git update-index command could be added to the readme as number 8 in the "Build and Run the Gallery in (arbitrary number) easy steps"?
(I would also vote to add the web.config to this --assume-unchanged - at least I often change the Gallery.ConfirmEmailAddresses" setting to false.)
Another enhancement would be to add a short comment in the gitignore file why this file is untracked, but the same time already committed.
What do you think?

I agree with you @robertmuehsig. Unless or until someone has a better idea, my vote is on adding this to the readme, as it is not a requirement although useful for convenience. Willing to send a PR for that? :)
Perhaps also add instructions on how to undo this --assume-unchanged action (using --no-assume-unchanged) for when someone does want to commit a change e.g. to the web.config file.

Sure - will create a new PR tomorrow - will close this one.

Thanks @robertmuehsig !


Git - viewlet doesn't update after a git init

In a fresh workspace:

git init
git add .

The changes do not do not show up in the SCM viewlet and I have to reload the window.

Fixed in 163267821cf7d2b6b8b556778ceace1ea742ed0b

Does not work for me:

empty folder
add 1 file
open SCM viewlet
open integrated terminal
git init & git add .

=> nothing happens
Btw in the console I also see this:


Partial Fix For Source Generated Queries

Source generated queries are unusable if multiple worlds are being used. This is because the cached Query object will be used with the wrong World, leading to bad query results. See #54
This fixes that by storing which world the cache is relevant for.
This is only a partial fix. If multiple worlds are being used with multithreading then the cache may be made invalid by another thread while it's in use.

Some discussion on this issue (including another potential fix) in discord, starting here: https://discord.com/channels/1099813114876284928/1100418566706171974/1179232143830945842


fix: fail if jwt keys not provided

:tada: This PR is included in version 5.0.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Controllers Tests

Closes Nan
What's Changed

Added testing.
Added --parallel-workers arg to invoke unittest

The ControllerDeviceGroup model needs @extras_features("statuses")

Tests are fixed now @glennmatthews , will continue with other PR.
The reason for failing bulk tests was that in one case there were instances instead of PKs returned, TreeModel is fine.
Not sure, why this case was not checked in other tests but started to fail in the ControllerDeviceGroup.

Comments has been addressed @glennmatthews


All exercises should require a homogeneous structure to be exported

Take a look at exercism/exercism.io issue #2304. It talks about requiring the user to export a homogeneous structure for all exercises.
Some require the user to export a constructor function:
var Bob = function() {};
Bob.prototype.hey = function(input) { ... }
module.exports = Bob;

Some require to export an object:
var Hamming = {
    compute: function(A, B) { ... }
}
module.exports = Hamming;

Some require to export different things.
Could we first agree on what structure should exercises require to export?

I agree there should be more consistency, although I think it's worth
pointing out that wrestling with the output formats did help me sharpen my
understanding of modules.
On Thu, Nov 12, 2015 at 11:32 AM, Rubén Chavarría<EMAIL_ADDRESS>wrote:

Take a look at exercism/exercism.io issue #2304
https://github.com/exercism/exercism.io/issues/2304. It talks about
requiring the user to export a homogeneous structure for all exercises.
Some require the user to export a constructor function:
var Bob = function() {};
Bob.prototype.hey = function(input) { ... }
module.exports = Bob;
Some require to export an object:
var Hamming = {
compute: function(A, B) { ... }
}
module.exports = Hamming;
Some require to export different things.
Could we first agree on what structure should exercises require to export?
—
Reply to this email directly or view it on GitHub
https://github.com/exercism/xjavascript/issues/128.

--
Matt Morgan
Director of Technology
Dulcet Software LLC
(734) 926-8142

How about making the format consistent for the first 10 or 12 exercises, and then letting things be more inconsistent after people have gotten a few successes?

That sounds good.  That way they'll have some confidence in the internals
of their solution.
On Thu, Nov 12, 2015 at 5:21 PM, Katrina Owen<EMAIL_ADDRESS>wrote:

How about making the format consistent for the first 10 or 12 exercises,
and then letting things be more inconsistent after people have gotten a few
successes?
—
Reply to this email directly or view it on GitHub
https://github.com/exercism/xjavascript/issues/128#issuecomment-156255014
.

--
Matt Morgan
Director of Technology
Dulcet Software LLC
(734) 926-8142

It seems a much more affordable work to make only the first 12 exercises consistent than make all of them.
I wouldn't like to turn this into a discussion about using classes Vs not using them, but we should decide a estructure to export.
My proposition is the following. From the point of view of tests (the only code users see at the beginning), I would like to have them this way, using the new keyword:
// ...
var Bob = require('./bob');
// ...
it('some test', function () {
  var bob = new Bob();
});
// ...

There are two approaches that could make this test code to work: a classy one, and a no-classy:
// classy approach
function Bob() {}
Bob.prototype.hey = function () { ... };
module.exports = Bob;

// no classy approach
function Bob () {
  function hey() { ... }
  return {
    hey: hey
  };
}
module.export = Bob;

I like that two approaches will pass the tests with that approach.

@rchavarria 'classy' vs 'no classy' approach -- en broma, no?  Is that the right phrase?
This seems like a good tack to me too.  I think one of the challenges of learning a new language is getting a handle on the environment and the tools, plus how much time is spent adapting to legacy code or integrating with APIs you didn't write?

@matthewmorgan yep, it was more or less a joke, and yes en broma is the right phrase. You know I would favor a classy approach, but I'm slowly appreciating other approaches, to avoid using this and learning a more JavaScript-way of doing things.


e2e: wait for all workers to enable cpumanager before starting

What this PR does / why we need it:
Saw flakes on the migration lane because only 1 node has cpumanager ready.
This PR should fix that.
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Checklist
This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

[ ] Design: A design document was considered and is present (link) or not required
[ ] PR: The PR description is expressive enough and will help future contributors
[ ] Code: Write code that humans can understand and Keep it simple
[ ] Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
[ ] Upgrade: Impact of this change on upgrade flows was considered and addressed if required
[ ] Testing: New code requires new unit tests. New features and bug fixes require at least on e2e test
[ ] Documentation: A user-guide update was considered and is present (link) or not required. You want a user-guide update if it's a user facing feature / API change.
[ ] Community: Announcement to kubevirt-dev was considered

Release note:

NONE

/test pull-kubevirt-e2e-k8s-1.29-sig-compute-migrations
/test pull-kubevirt-check-tests-for-flakes

/approve
Nice catch

/lgtm


WMArchive Grafana Monitoring Down / No Data

Impact of the bug
WMArchive is an essential dashboard utilized by P&R for day-to-day operations, to investigate failing workflows and issues with sites. This monitoring being down severely affects P&R operations.

Describe the bug
The WMArchive Grafana Dashboard dashboard is missing data since 27th March as reported by Jen on 27th March on mattermost.
As I understand the Failed Workflow Job reports are ingested to the /wmarchive/data/ endpoint by the ArchiveDataPoller.

The following ArchiveDataPoller log was pasted by @todor-ivanov in the Mattermost thread.
2024-03-29 17:32:21,876:140698532333312:INFO:ArchiveDataPoller:Found 1000 not archived documents from FWRJ db to upload to WMArchive.
2024-03-29 17:32:22,174:140698532333312:ERROR:ArchiveDataPoller:Error occurred, will retry later:
2024-03-29 17:32:22,174:140698532333312:ERROR:ArchiveDataPoller:url=https://cmsweb.cern.ch:8443/wmarchive/data/, code=413, reason=Request Entity Too Large, headers={'Date': 'Fri, 29 Mar 2024 16:32:22 GMT', 'Server': 'Apache', 'Content-Type': 'text/html', 'Content-Length': '176', 'CMS-Server-Time': 'D=32921 t=1711729942140346', 'Connection': 'close'}, result=b'\r\n<title>413 Request Entity Too Large</title>\r\n\r\n
413 Request Entity Too Large
\r\n
nginx\r\n\r\n\r\n'
2024-03-29 17:32:22,174:140698532333312:ERROR:ArchiveDataPoller:Trace back:
Traceback (most recent call last):
  File "/data/srv/wmagent/v<IP_ADDRESS>/sw/slc7_amd64_gcc630/cms/wmagentpy3/<IP_ADDRESS>/lib/python3.8/site-packages/WMComponent/ArchiveDataReporter/ArchiveDataPoller.py", line 57, in algorithm
    response = self.wmarchiver.archiveData(archiveDocs)
  File "/data/srv/wmagent/v<IP_ADDRESS>/sw/slc7_amd64_gcc630/cms/wmagentpy3/<IP_ADDRESS>/lib/python3.8/site-packages/WMCore/Services/WMArchive/WMArchive.py", line 33, in archiveData
    return self["requests"].post('', {'data': data})[0]['result']
  File "/data/srv/wmagent/v<IP_ADDRESS>/sw/slc7_amd64_gcc630/cms/wmagentpy3/<IP_ADDRESS>/lib/python3.8/site-packages/WMCore/Services/Requests.py", line 154, in post
    return self.makeRequest(uri, data, 'POST', incoming_headers,
  File "/data/srv/wmagent/v<IP_ADDRESS>/sw/slc7_amd64_gcc630/cms/wmagentpy3/<IP_ADDRESS>/lib/python3.8/site-packages/WMCore/Services/Requests.py", line 185, in makeRequest
    result, response = self.makeRequest_pycurl(uri, data, verb, headers)
  File "/data/srv/wmagent/v<IP_ADDRESS>/sw/slc7_amd64_gcc630/cms/wmagentpy3/<IP_ADDRESS>/lib/python3.8/site-packages/WMCore/Services/Requests.py", line 202, in makeRequest_pycurl
    response, result = self.reqmgr.request(uri, data, headers, verb=verb,
  File "/data/srv/wmagent/v<IP_ADDRESS>/sw/slc7_amd64_gcc630/cms/wmagentpy3/<IP_ADDRESS>/lib/python3.8/site-packages/Utils/PortForward.py", line 66, in portMangle
    return callFunc(callObj, newUrl, *args, **kwargs)
  File "/data/srv/wmagent/v<IP_ADDRESS>/sw/slc7_amd64_gcc630/cms/wmagentpy3/<IP_ADDRESS>/lib/python3.8/site-packages/WMCore/Services/pycurl_manager.py", line 353, in request
    raise exc
http.client.HTTPException: url=https://cmsweb.cern.ch:8443/wmarchive/data/, code=413, reason=Request Entity Too Large, headers={'Date': 'Fri, 29 Mar 2024 16:32:22 GMT', 'Server': 'Apache', 'Content-Type': 'text/html', 'Content-Length': '176', 'CMS-Server-Time': 'D=32921 t=1711729942140346', 'Connection': 'close'}, result=b'\r\n<title>413 Request Entity Too Large</title>\r\n\r\n
413 Request Entity Too Large
\r\n
nginx\r\n\r\n\r\n'

2024-03-29 17:32:22,174:140698532333312:INFO:BaseWorkerThread:ArchiveDataPoller took 0.734 secs to execute

How to reproduce it
Steps to reproduce the behavior:
Submit a "large" FWJR to the /wmarchive/data/ endpoint.
Not sure whats the actual size of the payload that will qualify as being "large" and make the endpoint return the 413 Request Entity Too Large.
Expected behavior
The /wmarchive/data/ endpoint to be able to handle "large" FWJRs and the WMArchive dashboard be working as usual

Some of the logs can also be seen on the nginx controller on the Kubernetes:
~ $ k logs pod/cern-magnum-ingress-nginx-controller-5b8j8 -n kube-system | grep -i large
2024/04/11 07:13:05 [error] 36#36: *2223712 client intended to send too large body: 15734904 bytes, client: <IP_ADDRESS>, server: cmsweb-k8s-prodsrv2.cern.ch, request: "POST /wmarchive/data/ HTTP/1.1", host: "cmsweb-k8s-prodsrv2.cern.ch"
2024/04/11 07:55:35 [error] 36#36: *2317077 client intended to send too large body: 23517605 bytes, client: <IP_ADDRESS>, server: cmsweb-k8s-prodsrv2.cern.ch, request: "POST /wmarchive/data/ HTTP/1.1", host: "cmsweb-k8s-prodsrv2.cern.ch"
2024/04/11 07:59:51 [error] 34#34: *2328673 client intended to send too large body: 17649066 bytes, client: <IP_ADDRESS>, server: cmsweb-k8s-prodsrv2.cern.ch, request: "POST /wmarchive/data/ HTTP/1.1", host: "cmsweb-k8s-prodsrv2.cern.ch"
2024/04/11 08:03:52 [error] 39#39: *2341664 client intended to send too large body: 15734904 bytes, client: <IP_ADDRESS>, server: cmsweb-k8s-prodsrv2.cern.ch, request: "POST /wmarchive/data/ HTTP/1.1", host: "cmsweb-k8s-prodsrv2.cern.ch"
2024/04/11 08:08:56 [error] 39#39: *2359348 client intended to send too large body: 15734904 bytes, client: <IP_ADDRESS>, server: cmsweb-k8s-prodsrv2.cern.ch, request: "POST /wmarchive/data/ HTTP/1.1", host: "cmsweb-k8s-prodsrv2.cern.ch"
2024/04/11 08:10:20 [error] 36#36: *2364292 client intended to send too large body: 19739784 bytes, client: <IP_ADDRESS>, server: cmsweb-k8s-prodsrv2.cern.ch, request: "POST /wmarchive/data/ HTTP/1.1", host: "cmsweb-k8s-prodsrv2.cern.ch"

Although @arooshap has just raised the nginx limit from 1MB to 8MB, but these sizes are around 20MB, so docs like these are still failing.

raising threshold may be a temporary solution since we never really know the size of payload. I rather prefer to see how it can be constrained in WM system which knows by definition the size when it construct the HTTP request. Now we know the nginx threshold and WM system should acknowledge it.

@vkuznet we changed nginx limit to accommodate data of any size. This setting was also being applied in the older cluster, but it was not mentioned in the upgrade procedure, so it was skipped. I am letting you know in case you did not see the discussion on mattermost!

@arooshap , does it mean that there is no limit now on nginx? If this is the case we'll get problem on MONIT site since it also has internal constrain, I hope @leggerf or @brij01 or @nikodemas can remind us what is a current limit on MONIT size for JSON documents we send, if I recall from the past it was around 20-30MB. In other words increasing or removing limits on nginx does not solve the entire problem of creating big WMArchive docs since they content should not that big for monitoring purposes and we still must identify what are those documents and how to fix them before sending to MONIT. I just fear that by removing nginx limit we delegate problem from CMSWEB to MONIT and sooner or later the MONIT team will complain about such large documents.

@vkuznet yes, that is exactly that. Apparently, it was decided to use these parameters after a careful consideration a few years ago. I proposed that we can have a discussion among the teams to decide a concrete value for these limits(as you and @belforte mentioned that it is not good to have no limits as we are working under the assumption that it might break things in the future) . Maybe I can open a ticket to discuss this, what do you think?

as Alan already sugested, we can start by looking at past statitics and start with a limit which envelopes what we do, while protecting against new problems. Then we can look at cost of keeping it vs. cost of reducing and adapting applications.

@vkuznet yes, that is exactly that. Apparently, it was decided to use these parameters after a careful consideration a few years ago. I proposed that we can have a discussion among the teams to decide a concrete value for these limits(as you and @belforte mentioned that it is not good to have no limits as we are working under the assumption that it might break things in the future) . Maybe I can open a ticket to discuss this, what do you think?

Aroosha, we may face now few problems:

By removing the nginx limit you may open CMSWEB infrastructure to potential impact of large docs. We don't know their total size, neither their rate or impact on nginx performance, and if new documents will start flooding nginx it can slow down entire CMSWEB throughput.
We don't know impact on MONIT either since now these docs will flow from client to WMArchive to MONIT and MONIT team can start complaining
We don't know impact of memory footprint of WMArchive either which may hickup, or at least have memory spikes due to large document size from upstream client.

I suggest that for item 1 you may use hey tool and performance performance studies how it may impact CMSWEB ngins/FE if you'll pass around 20-50MB JSON in payload to it. This can also help to identify impacton WMArchive, item 3. But for item 2 we need input from CMSMonitoring team to tell us the exact limit from MONIT infrastructure and I would suggest to bound nginx within this limit at least because we don't have access to MONIT infrastructure which is bigger then CMSWEB and MONIT/IT team will complain since CMS docs may impact performance of kafka, etc. Bottom line, simply removing the limit may hit us back. I would rather keep some limit, at least driven by threshold from MONIT.

IIUC there was  no limit in nginx until two weeks ago. A limit is good, but it is not a disaster to start with same configuration as we had in last years.
FWIW, if one puts their hands in WMArchive I suggest to critically review the need for it. It dates from the times that we did not have HDFS etc. Do we really need al lthat info ? IIUC the only user now is P&R operations (Jen) who finds some useful plots in Grafana of OK/fail vs. campaing/worflow/agent which could also be filled with information already collected by the HTCondor spider.

If this is the case we'll get problem on MONIT site since it also has internal constrain, I hope @leggerf or @brij01 or @nikodemas can remind us what is a current limit on MONIT size for JSON documents we send, if I recall from the past it was around 20-30MB.

MONIT is accepting the documents up to 30MB and they are kind of recommending to stay under this limit.

I have monitoring!  I can see what is going on for the last 24 hrs.  Thank you!

do we really need all that data in MONIT ? In a single document ?

A reasonable/standard document should not be greater than 1 or 2MB.
Yes Nikodemas, we want to review the data structure of these documents and truncate - or delete - data that is not really relevant for WMArchive monitoring. I fear though that we will only be able to get to this mid May, as we are fully focused on WMAgent containerization these weeks.

@amaltaro ok, thanks for the information!

This operational issue has likely been fixed from different angles:

CMSWEB lifting the limit in NGinx
fix to WMAgent codebase when reporting job errors https://github.com/dmwm/WMCore/pull/11933

Given that WMArchive monitoring is functional for a couple of months and the immediate issue has been resolved, I think we should close this issue out and work on planned developments. Here is a new ticket to be considered in the coming quarters: https://github.com/dmwm/WMCore/issues/12043
Closing this one out, thank you everyone who contributed to this resolution!


Cookie authentication bug #525

PR Checklist:

[x] Link to related issues: #number
[x] Add changelog entry linking to issue, describe API changes
[ ] Add tests (optional)
[ ] (If new feature) add to description / readme

Looks good! I've deployed this version on atomicdata.dev, let's hope this also fixes #527


Linker: Not relinking when linker options are changed

Self-explanatory. Should this mechanism be made generic s.t. all classes can easily implement this feature?

This is done by nature since #50. And frugal_flags() is what makes this concept generic.


Add nightly testing instructions for reviewers

We need somewhere to record instructions/advice for modifying/running/retriggering nightly tests at cylc8. This will apply to UM, Jules, lfric_apps.


DEBUG: Show function arguments

Show function arguments.
Command info args.
Current numba-dppy gdb output:
(gdb) info args
No arguments.

Numba does not support the command info args.

Related issue in numba:
https://github.com/numba/numba/issues/7414


fix(robot-server): do not save calibration offsets if an error occurs

Overview
A fix for the behavior where pipette offsets get saved even if an error occurs during the calibration flow.
Test Plan
Follow steps in this ticket to reproduce.
Changelog

Save the offset inside the robot server function rather than the pipette function
Ensure that we're raising on edge detection failed errors as well

Review requests
Please test on a robot, let me know if anything seems off.
Risk assessment
Low. Should be fixing a small bug.

Do you think we'll need to fix the gripper offset saving mechanism as well? I don't see why this behavior would only be happening to the pipettes and not the gripper as well? What am i missing?

Do you think we'll need to fix the gripper offset saving mechanism as well? I don't see why this behavior would only be happening to the pipettes and not the gripper as well? What am i missing?

@ahiuchingau the gripper already does the mechanism above. Previously, the pipette was saving calibration inside the try/except of the ot3_calibration.py function.


Dart:html should use lowerCamelCase for constants in Dart 2.0.

The Dart style guide recommends lowerCamelCase for constants. Dart platform libraries used to use SCREAMING_CAPS.
The platform libraries are changing to the recommended style for Dart 2.0, and dart:html and other web-facing libraries should do that too.

I am under the impression that this is unlikely. @terrylucas ?

Terry and I discussed it a while back and I think the conclusion was that this one is staying (and probably should in the name of consistency with the JS names).    @terrylucas if I'm remembering wrong feel free to re-open.

@lrhn Please excuse a more general remark here, as I wasn't able to find another place where this is being discussed.
Even when considering the remarks in the docs, I still think moving from SCREAMING_CAPS to lowerCamelCase is a bad design decision. The former allows for easy identification of constants against class and local variables while skimming through code (especially when it's not your own), and I'd argue this is a decade long practice for a reason in languages like Java or ActionScript (don't laugh):
_variableName //private
variableName //local (or public, while explicit getters/setters are preferred, e.g. think of breakpoints)
VARIABLE_NAME //constant

But I guess I'm like 4 years late to the party to have the conventions and APIs changed back :-)
What is super unfortunate though, is the case (sic!) of the number Pi, which dart:math introduces as a top level constant. After running the dart2_fix tool on my projects, I now have occurences of pi instead of PI everywhere, which looks like local variables one would introduce when midnight coding at a hackathon. sigh

Not entirely related, but I think renaming JSON to json is unfortunate, too.
Consider this exampe:

var json = JSON.decode(...);
var something = json["something"];
//BTW, dart2_fix will break this.

Now developers are being forced to come up with a new name for their var, e.g.

var jsonGoddammitDartTeam = json.decode(...);
var something = jsonGoddammitDartTeam["something"];

Also, isn't this change against acronym style convetions?

this is a decade long practice

Isn't Dart about dropping such stuff that doesn't really carry its weight anymore?

var json = JSON.decode(...);

I'd say var json is the actual problem here. That's a poor name for the variable.
It's similar with pi. pi for the constant looks only bad if the rest of the code is poor quality like in code from

when midnight coding at a hackathon. sigh

Didn't mean to start an argument, sorry if I sounded like that. As with most things in life, it depends on the point of view. I fully understand where you're coming from.
Where I'm coming from (digital advertising), we had a lot of freelancers coming in to create rich media experiences in no-time, and with frontend code to be thrown away after some weeks of airtime. We couldn't care less about poor quality, so we created an environment to allow for this and still run smoothly. I semi-automatically ported all of it (>40kLOC) to Dart some time ago (keeping SCREAMING_CONSTANTS, hehe):
https://github.com/block-forest/rockdot-framework
(Background story here)
That's my personal use case.
Others might be the millions of coders who have yet to switch to Dart, especially those coming from Java (Android). And maybe people who will not switch to the language, exclusively (f.ex. I'll never forget how awesome Rails was for my use cases back then, but I had to re-learn the syntax every time I revisited the language, ultimately dropping it due to it). And who knows how many coders are out there who simply cannot (by skill or management) write good code.
Sorry for the wall of text and whataboutism. I guess I wanna stress that conventions are a balancing act with many valid viewpoints, familiarity and mediocrity being two of them ...
Thanks for your POV, thanks for a great language, and don't worry, I'll stick to Dart – just don't become Ruby/Rails ;-)

As mentioned there was quite some discussions about this and many argued for screaming caps but the Dart team decided long ago after consideration of all arguments against using screaming caps.
The recent changes were only to make older code follow the established style guides.

Not entirely related, but I think renaming JSON to json is unfortunate, too.
Consider this exampe:
var json = JSON.decode(...);
var something = json["something"];
//BTW, dart2_fix will break this.

Note that we added the jsonDecode helper to help with this scenario.

@leafpetersen Thanks! Maybe the dart2_fix tool should use it when replacing references to JSON.decode. Will file an enhancement request.
@zoechi look what I found in dart2_fix's code:
Map json = jsonDecode(jsonData); ;-)

Oops, didn't notice this issue.  Leaf your recollection is correct.  I've discussed this with a number of folks and the conclusion was that all JS documentation and general browser knowledge is SCREAMING_CONSTANTS.  We changed some properties (along time ago) like innerHTML to innerHtml and it confused people.  I guess with IDEs it easier but we want to be agnostics with frameworks we don't control.


fix: run! errors if output is a standalone file

Right now the run! function errors on the README instructions.
The idea here is to add an if to check it the dirname of the joinpath(pwd(), output) is a dir instead of throwing error straight away.

Replaced by #5, thanks @storopoli.


There is a problem with the terminal display

VSCode Version: Code 1.17.0 (be377c0faf7574a59f84940f593a6849f12e4de7, 2017-10-04T23:45:46.804Z)
OS Version: Windows_NT x64 6.1.7601
Extensions:

Extension
Author (truncated)
Version

vscode-eclipse-keybindings
alp
0.9.6

cocos-creator
Chu
0.0.1

cocos-debug
Chu
0.0.1

vscode-eslint
dba
1.3.2

tslint
eg2
1.0.9

vscode-npm-script
eg2
0.2.1

Angular2
joh
2.7.0

Angular-BeastCode
Mik
5.0.6

debugger-for-chrome
msj
3.3.1

Steps to Reproduce:

Reproduces without extensions: Yes/No

Duplicate #35660 and had been fixed in September Recovery 2017

Duplicate https://github.com/Microsoft/vscode/issues/35660


Overloading leftmeta, KDE Plasma, what am I doing wrong?

Disabled meta as the menu launcher in systemsettings,  then
# Doesn't work:
## HELD/TAPPED
leftmeta = overload(macro(leftalt+f1),macro(leftmeta+0))

# So tried each of the below individually and both work:
leftmeta = macro(leftalt+f1)
leftmeta = macro(leftmeta+0)

Thanks

overload takes a layer for holding and a key for tapping; that is, a key is considered 'held' if it overlaps with a subsequent keypress. If your understanding of 'holding' is time-based, you are probably looking for timeout(A-f1, 300, M-0) or similar.
See https://github.com/rvaiya/keyd/issues/713#issuecomment-2044532113 for explanation

Thanks, makes sense,  was looking at it from the wrong perspective (and being a bit dim!).


Inference result

Hello, I use the esrgan_orig_2S2 pretrained model to infer grid, and I copy one low resolution image

I got the high resolution image:

I have two questions: 1 Can color differences between different image grids be eliminated?
2 Why are there so many mosaics?
I hope to receive your answer! Thank you!

Hi there, thank you for your issue.
It looks like a bug where the pixel values aren't being clamped between 0-1 before being converted to an image and saved - I have pushed a fix here.  Let me know if this is fixes the weird color artifacts.
As far as differences between the grid cells, we have tried some blending techniques but haven't found any methods that work well. Most of them over-average and cause a blurriness at the borders. We'll keep working on this.
Also, are you using L1C or L2A Sentinel-2 images? The pretrained weights all used L1C imagery.

Thanks, The clamp operation is useful!
And I wonder how much the number of the input imgs effects the result？

I found that increasing the number of input images has a large effect in performance until you get to ~8-10 images, and after that the benefit is not as large.

Can you share where the link or path of the pre-trained weights? I want to use it for a similar case.


Add new test to change task and adjusted solution

There is a missing case when the amount could be changed by the coins with small value and couldn't be changed by coins with higher value.
Since solutions of most people just return :error is this case, i decided to add a testcase and adjust the solution. Here is a case:
iex(2)> Change.generate(102, [3, 100])
{:ok, %{3 => 34, 100 => 0}}

Sweet! Thanks so much! 🎉


Broken link

https://github.com/NHSDigital/rap-community-of-practice/blob/main/python/project-structure-and-packaging.md#generic-package-template
There is a broken link to the generic package template in the section above

Guide checks out, no broken links or at least, not anymore (?). Issue closed.


About the usage of the loss function

Hi, authors. Thanks for open sourcing such great work. Here I have a question about the usage of the loss function. In the readme https://github.com/mk-minchul/AdaFace#usage, you take the embedding before normalization as input for the adaface loss. But in your implementation, https://github.com/mk-minchul/AdaFace/blob/c4052220c51167a18c35ce15a450044180cbb281/train_val.py#L54 you take the embedding after normalization as input for the adaface loss. I am confused about that.  In addition, since you use the norm of the embedding feature as a metric of the image quality, do you think the normalization operation before generating the embedding feature will damage the efficiency of adaface loss. For example, CNN backbone->(1)L2 normalization->pooling->FC->embedding->(2)L2 normalization, will the first L2 normalization operation downgrade the efficiency of adaface loss?

Dear Barry-Liang. Thanks for pointing it out the error. I have updated the readme to correctly reflect the usage.
The input should be normalized to make it a cosine theta when it is multiplied with the normalized embedding.
As for the second question, my guess would be that if individual feature norm gets to be removed from the penultimate L2 norm layer, the subsequent FC layer might not be able to recover it sufficiently. Therefore, if normalization is needed, I would suggest using BatchNorm in (1) instead.

Thanks for your quick response. It makes sense.  I will close this issue.


test: unixise some paths in diagnostics tests (NFCI)

This simplifies the test pattern.

Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.

Resolves SR-NNNN.

@swift-ci please test

Build failed
Swift Test OS X Platform
Git Sha - 34cbb3000c7c4d7cf7924370beba90d478c1cab9

@swift-ci please test macOS platform


Templates generated by custom Android build can't be used without a custom build

Godot version:
3.2.2 Mono
OS/device including version:
MXLinux 19
Issue description:
The new plugin system slows down app deployment and runs graddle even if you never change anything in the custom build, It would be better if you could use the templates generated, but when I use the files generated at android/build/build/outputs/apk as custom templates I can't access the plugin.
Tested with https://github.com/Shin-NiL/Godot-Android-Admob-Plugin
Steps to reproduce:
Use the apk templates generated by a custom build with a plugin as custom templates

Please read this issue. We don't know if there is an easier or cleaner way to do, but it works as a workaround at least.

@MightyPrinny That's the intended behavior. The plugins require additional parameters which is passed to the gradle build process at export time. As such they can't be used with a (default or generated) template.
We're still in the process of improving the build and export flow, so we'll take the feedback into consideration.
Thanks!


[BitFinex] Summary Section: ____ doesn't get converted to USD equivalent

Every currency shows on the left the values in that currency and on the right the conversion to USD. In the case of Dash it doesn't show the section of USD.

With the current version I get only BTC show into USD equivalent, all other coins are blank now.

Wait, now it showed for every coin excep ZEC... I guess it needs to load the value at some point?

It's a bug in the Bitfinex api. Conversion rate is not showed when 100% of amount is lended.
I will correct it.

Thank you!


Too many objects due to non-compiled Regex usage

I'm doing some internal memory allocation benchmark on our C# code, and I noticed that a large portion of our object graph is due the usage of the RecognizersText library - there are over 3000 Regex objects created when using the English DateTimeRecognizer alone, which results in over 730k RegexNode objects, 175k RegexNode[] and 175k List objects. All in all about 40% of our object count is due the usage of the library - which seems quite excessive...

This traces down to the static constructors of the models, like for example:  EnglishTimeExtractorConfiguration
Would it be possible to add a global / local flag to use compiled Regex instead?

Another interesting issue is the fact that all languages are being loaded in memory, despite the fact that only one language is being used - seems to be related to this method.


Pass arguments to build_custom flow script

Details
New behavior
Change the run-docker.sh script to accept any number of arguments for the build_custom option, so that these arguments can be passed along to the build script.
Motivation
If the build python script is supposed to take arguments (for example to switch which steps to execute, target fps, etc.) and the interactive docker session is not an option, the only possibility right now to do this would be to either create different build scripts depending on which behaviour is wanted (but this gets unwieldy quickly) or to for example pass those args as an environment variable, but this more of a workaround, and since the arguments after $3 are not used right now, it would be nice to pass them directly.
Parts of FINN affected
run-docker.sh

This was added in https://github.com/Xilinx/finn/pull/1217

Thanks @alexhornburg-xlnx for adding this feature! I am closing the issue for now, but @bwintermann feel free to reopen or create a new issue if this doesn't solve it for you.


Add :accepted_ts_and_cs_at to Candidate

Context
For the sign-in with unknown email flow, we are planning to create candidates in the database, send them emails redirecting them to the sign-up form as before and make sure nobody can log in unless they have accepted T&Cs.
This is an initial commit with just the db migration, as requested by Theo.
Changes proposed in this pull request
This PR adds the field as a datetime, so that we are able to ask people to accept new T&Cs if they are revised in the future using date comparisons.
Guidance to review
Should be straightforward, you either agree with the approach or you don't!
Link to Trello card
633 - Add :accepted_ts_and_cs_at to Candidate and change sign_in_without_account_email flow
Env vars
No new env vars

Closing for now. May re-open when we do this.


HTTPS

Hi,
My program works fine without HTTPS, but i run into issues, the minute i add 'schemes': ['https'], can someone pls advise, how to enable https using hapi-swagger.
{
register: require('hapi-swagger'),
info: {
'title': 'Test API Documentation',
'version': '5.1.0',
},
'schemes': ['https']
}

If you get the v6.0.0 from NPM and remove schemes from your options you should now find that it works fine on either http or https. Not defining a schemes is a valid option in swagger. I tested on one of my sites this morning. I have taken the default out of the plugins config, which was forcing us to define this option for https.
I need to look into this issue in more depth, but for now not suppling the schemes should fix things. I believe the issue is most likely one of pathing in the swagger UI.
Please get back to me if this does not work for you.


Is polling the only way to capture frames?

Hi,
I am working on an application that grabs frames and saves them to file.  I am new with this device, but so far the only way I can grab frames is through polling. I am a bit concerned that my application might drop some frames if the time between polling is too long. I would prefer to use a callback if available. Is there a way to grab frames using a callback function?
Thanks

No there isn't.
Maybe you could work with threads though so that the polling thread isn't busy with processing the frames.

First off, the SDK includes a Recorder which saves the frames, so I hope you aren't writing that code yourself. The guide to use it is at https://docs.microsoft.com/en-us/azure/kinect-dk/record-sensor-streams-file and with more detail at https://docs.microsoft.com/en-us/azure/kinect-dk/azure-kinect-recorder. I don't remember if that Recorder code is an open part of the SDK, but if so it's worth looking for and using it as much as possible rather than writing your own code from scratch.
If you have a SSD then there shouldn't be a problem saving frames, and most HDDs should be able to handle it too - I've saved the full color and depth datasets from the sensors onto my computer for 30-second periods, and they are about 3 GB. So, the data rate is about 100MB per second. You can economize slightly by ignoring the audio and gyroscope data, or even more by getting only the RGB or only the depth images if you only want one. And you can specify both the resolution and framerates of the image frames, so that can be used to reduce the data amount by a lot.
Also, each frame includes a timestamp, and that can give a good indication if any frames are dropped. The intervals are not exactly perfect of course, but they will make it clear if a frame is missing.

@RoseFlunder  and @Chris45215 , thank you for your quick responses. I took a look at the recorder, and it almost meets my needs. I would also like to visualize the frames (and maybe process) them as I am recording. The idea is that this will give me some feedback on what area of space I should be recording and how fast I should be moving the camera. Ideally, I would want to combine something like kinectfusion with recording. Do you have any suggestions for this? Alternatively, I can run the recording application and also write some code to grab frames and visualize them in a different program, but I doubt this will go well.

For visualizing the frames, without recording, I use the bundled Azure
Kinect Viewer app and see how things look in real time, though I don't
think its code is in the samples (and it will claim exclusive use of the
sensor when it is running). The Azure Kinect Samples / Body Tracking
Samples folder does have a lot of samples that visualize the depth data,
and you can remove the body-tracking-specific code from those. That will
only show the image the camera is currently seeing, and you can add your
own code to save the frames or do whatever processing is needed.
I hope I'm understanding your request correctly.
On Mon, Nov 16, 2020 at 6:19 PM oafolabi<EMAIL_ADDRESS>wrote:

@RoseFlunder https://github.com/RoseFlunder and @Chris45215
https://github.com/Chris45215 , thank you for your quick responses. I
took a look at the recorder, and it almost meets my needs. I would also
like to visualize the frames (and maybe process) them as I am recording.
The idea is that this will give me some feedback on what area of space I
should be recording and how fast I should be moving the camera. Ideally, I
would want to combine something like kinectfusion
https://github.com/microsoft/Azure-Kinect-Samples/blob/master/opencv-kinfu-samples/README.md
with recording. Do you have any suggestions for this? Alternatively, I can
run the recording application and also write some code to grab frames and
visualize them in a different program, but I doubt this will go well.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/Azure-Kinect-Sensor-SDK/issues/1418#issuecomment-728388569,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACAXNVBVW6JJJXW4PZH4MBDSQGXQTANCNFSM4TWB6C6A
.

@Chris45215 , thanks. I'll take a look at the body tracking code. Do you know if the Recorder also claims exclusive use of the sensor?

I'm not certain, but it probably does - in my applications, only one
program can pull data from the sensor at a time (I think that's true for
all USB-connected cameras in general). But there's nothing preventing you
from writing one application that uses it in multiple ways within that
program. And you can always have one program output the sensor's info to
other programs.
On Tue, Nov 17, 2020 at 4:44 PM oafolabi<EMAIL_ADDRESS>wrote:

@Chris45215 https://github.com/Chris45215 , thanks. I'll take a look at
the body tracking code. Do you know if the Recorder also claims exclusive
use of the sensor?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/Azure-Kinect-Sensor-SDK/issues/1418#issuecomment-729232367,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACAXNVDI6DK2TYYAE45CFODSQLVEPANCNFSM4TWB6C6A
.

I see, thanks. This has been very helpful. I will close this issue for now.


Added IES Mutxamel from Mutxamel (Alicante, Spain)

Added file to add my school to jetbrains

@dalcaraziesmtx Pull request merged. Thank you!


Scripts aways added to header

Need to investigate adding script nodes directly into the body content.

Corrected, script tags are now added as child nodes within the document


Would it be possible to remove the static requirement on callbacks for AVIOContextCustom::alloc_context

It makes it very difficult to code inside larger frameworks

I apologize I can't really think of a reason to add this upon further thought because you have to share an object among the different callbacks anyway which requires wrapping in Arc. Unless that function is changed to take an struct that actually implements Read and/or Write and or Seek


PostgreSQL : Autocompletion with schema

Hi,
With version 6.2.0, I have to add the schema name in front of the table name for the completion to work.
However, the default schema is well selected.
I wasn't supposed to do it with version 6.0.0.
Thank you in advance for your help.

isn't reproducible anymore. ticket closed


Webhook failure: certificate signed by unknown authority

Describe the bug:
Certificates are failing to be created.  The webhook is reporting errors:
E0528 15:38:38.430676       1 authentication.go:65] Unable to authenticate the request due to an error: [x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "front-proxy-ca"), x509: certificate signed by unknown authority]
E0528 15:38:40.352428       1 authentication.go:65] Unable to authenticate the request due to an error: [x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "front-proxy-ca"), x509: certificate signed by unknown authority]
E0528 15:38:41.048166       1 authentication.go:65] Unable to authenticate the request due to an error: [x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "front-proxy-ca"), x509: certificate signed by unknown authority]

Expected behaviour:
Certificates should be created and the webhook should be function without error.
Steps to reproduce the bug:
$ kubectl apply \
    -f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.8/deploy/manifests/00-crds.yaml
$ kubectl create namespace cert-manager
$ kubectl label namespace cert-manager certmanager.k8s.io/disable-validation="true"
$ helm install --name cert-manager --namespace cert-manager jetstack/cert-manager --version 0.8.0 -f values.yaml

Anything else we need to know?:
Our values.yaml:
# Default values for cert-manager.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.
global:
  ## Reference to one or more secrets to be used when pulling images
  ## ref: https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/
  ##
  imagePullSecrets: []
  isOpenshift: false
  # - name: "image-pull-secret"

  # Optional priority class to be used for the cert-manager pods
  priorityClassName: ""
  rbac:
    create: true

  logLevel: 2

  leaderElection:
    # Override the namespace used to store the ConfigMap for leader election
    namespace: ""

replicaCount: 1

strategy: {}
  # type: RollingUpdate
  # rollingUpdate:
  #   maxSurge: 0
  #   maxUnavailable: 1

image:
  repository: quay.io/jetstack/cert-manager-controller
  # Override the image tag to deploy by setting this variable.
  # If no value is set, the chart's appVersion will be used.
  # tag: canary
  pullPolicy: IfNotPresent

# Override the namespace used to store DNS provider credentials etc. for ClusterIssuer
# resources. By default, the same namespace as cert-manager is deployed within is
# used. This namespace will not be automatically created by the Helm chart.
clusterResourceNamespace: ""

serviceAccount:
  # Specifies whether a service account should be created
  create: true
  # The name of the service account to use.
  # If not set and create is true, a name is generated using the fullname template
  name:

# Optional additional arguments
extraArgs: []
  # Use this flag to set a namespace that cert-manager will use to store
  # supporting resources required for each ClusterIssuer (default is kube-system)
  # - --cluster-resource-namespace=kube-system

extraEnv: []
# - name: SOME_VAR
#   value: 'some value'

resources: {}
  # requests:
  #   cpu: 10m
  #   memory: 32Mi

# Pod Security Context
# ref: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
securityContext:
  enabled: false
  fsGroup: 1001
  runAsUser: 1001

podAnnotations: {}

podLabels: {}
# Optional DNS settings, useful if you have a public and private DNS zone for
# the same domain on Route 53. What follows is an example of ensuring
# cert-manager can access an ingress or DNS TXT records at all times.
# NOTE: This requires Kubernetes 1.10 or `CustomPodDNS` feature gate enabled for
# the cluster to work.
# podDnsPolicy: "None"
# podDnsConfig:
#   nameservers:
#     - "<IP_ADDRESS>"
#     - "<IP_ADDRESS>"

nodeSelector: {}

ingressShim:
  defaultIssuerName: "letsencrypt-staging"
  defaultIssuerKind: "ClusterIssuer"
  # defaultACMEChallengeType: ""
  # defaultACMEDNS01ChallengeProvider: ""

webhook:
  enabled: true

cainjector:
  enabled: true

# Use these variables to configure the HTTP_PROXY environment variables
# http_proxy: "http://proxy:8080"
# http_proxy: "http://proxy:8080"
# no_proxy: <IP_ADDRESS>,localhost

# expects input structure as per specification https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.11/#affinity-v1-core
# for example:
#   affinity:
#     nodeAffinity:
#      requiredDuringSchedulingIgnoredDuringExecution:
#        nodeSelectorTerms:
#        - matchExpressions:
#          - key: foo.bar.com/role
#            operator: In
#            values:
#            - master
affinity: {}

# expects input structure as per specification https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.11/#toleration-v1-core
# for example:
#   tolerations:
#   - key: foo.bar.com/role
#     operator: Equal
#     value: master
#     effect: NoSchedule
tolerations: []

ClusterIssuer:
apiVersion: certmanager.k8s.io/v1alpha1
kind: ClusterIssuer
metadata:
  name: letsencrypt-staging
spec:
  acme:
    # You must replace this email address with your own.
    # Let's Encrypt will use this to contact you about expiring
    # certificates, and issues related to your account.
    email<EMAIL_ADDRESS>    server: https://acme-staging-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      # Secret resource used to store the account's private key.
      name: example-issuer-account-key
    # Add a single challenge solver, DNS01
    solvers:
    - dns01:
      route53:
        region: us-west-2
        # optional if ambient credentials are available; see ambient credentials documentation
        accessKeyID: XXXXXXXXXXXXXXXX
        secretAccessKeySecretRef:
          name: prod-route53-credentials-secret
          key: acme-route53-secret-access-key

Environment details::

Kubernetes version (e.g. v1.10.2): 1.14.0
Cloud-provider/provisioner (e.g. GKE, kops AWS, etc):  kubeadm / bare metal
cert-manager version (e.g. v0.4.0): 0.8.0
Install method (e.g. helm or static manifests):  helm chart

/kind bug

This is a Kubernetes configuration bug or error.
This cluster was installed by https://github.com/puppetlabs/puppetlabs-kubernetes which uses kubeadm internally.  While the setup of puppetlabs-kubernetes creates the CA and etcd certs, it does not create the front-proxy-ca and certs.
This can be corrected on misconfigured clusters by copying the front-proxy-ca and cert from one master to the other masters and restarting (one at a time for safety) the updated master.

I got the same error with one Kind with k8s 1.18.2 when deploying webhook.
Error from server (InternalError): error when creating "config/samples/juno_paypal.yaml": Internal error occurred: failed calling webhook "mjuno.kb.io": Post https://k8sbot-webhook-service.k8sbot-system.svc:443/mutate-app-pass-paypal-com-v1-juno?timeout=30s: x509: certificate signed by unknown authority

@lenhattan86 please see https://github.com/jetstack/cert-manager/issues/2920#issuecomment-653434889

Check this comment https://github.com/cert-manager/cert-manager/issues/3495#issuecomment-1247395252


[VL] Remove some legacy code in a CMakeLists.txt

What changes were proposed in this pull request?
(Please fill in changes proposed in this fix)
(Fixes: #ISSUE-ID)
How was this patch tested?
(Please explain how this patch was tested. E.g. unit tests, integration tests, manual tests)
(If this patch involves UI changes, please attach a screenshot; otherwise, remove this)

@rui-mo

===== Performance report for TPCH SF2000 with Velox backend, for reference only ====

query
log/native_4577_time.csv
log/native_master_01_29_2024_f040fe8d6_time.csv
difference
percentage

q1
32.28
33.80
1.529
104.74%

q2
24.12
25.67
1.557
106.46%

q3
38.28
38.07
-0.206
99.46%

q4
37.80
40.59
2.783
107.36%

q5
70.55
69.30
-1.250
98.23%

q6
6.71
7.04
0.330
104.92%

q7
84.49
85.84
1.344
101.59%

q8
85.80
86.69
0.889
101.04%

q9
122.67
121.85
-0.820
99.33%

q10
43.46
43.51
0.055
100.13%

q11
20.37
19.98
-0.393
98.07%

q12
26.85
29.14
2.284
108.50%

q13
45.41
45.40
-0.007
99.98%

q14
16.72
15.65
-1.066
93.62%

q15
27.83
29.66
1.829
106.57%

q16
14.72
14.28
-0.437
97.03%

q17
101.37
102.13
0.754
100.74%

q18
152.52
149.99
-2.530
98.34%

q19
12.54
13.92
1.380
111.00%

q20
26.42
26.90
0.481
101.82%

q21
225.31
225.67
0.358
100.16%

q22
13.69
13.48
-0.208
98.48%

total
1229.91
1238.57
8.656
100.70%


Added T2 Systems as a user

Adding T2 Systems as an Airflow user.

Company names must be in alphanumeric order in this file. Also, please add a JIRA for this change. Though a trivial change, we would like community members to get familiar with our processes : c.f. https://cwiki.apache.org/confluence/display/AIRFLOW/Contributors'+Guide
Furthermore, please alter your commit message to 1) start with [AIRFLOW-XXX] (the JIRA id) and 2) to conform to active speech (e.g.  Add T2 Systems as an Airflow user).

@UnclaimedPants Any updates?

Closing this PR for lack of movement. Please see comments above.


Fix QQMusic url format.

Please follow the guide below

You will be asked some questions, please read them carefully and answer honestly
Put an x into all the boxes [ ] relevant to your pull request (like that [x])
Use Preview tab to see how your pull request will actually look like

Before submitting a pull request make sure you have:

[x] At least skimmed through adding new extractor tutorial and youtube-dl coding conventions sections
[ ] Searched the bugtracker for similar pull requests

In order to be accepted and merged into youtube-dl each piece of code must be in public domain or released under Unlicense. Check one of the following options:

[x] I am the original author of this code and I am willing to release it under Unlicense
[ ] I am not the original author of this code but it is in public domain or released under Unlicense (provide reliable evidence)

What is the purpose of your pull request?

[x] Bug fix
[ ] Improvement
[ ] New extractor
[ ] New feature

Description of your pull request and other information
Fix errors like this "ERROR: Unsupported URL: https://y.qq.com/n/yqq/playlist/1374105607.html"

Superseded by #13805


Sites keep making me do two-factor authentication (2FA)

I posted this in Mac branch but I think it probably applies here as well.
Certain sites I use like my healthcare portal (uhc.com) keep asking me to do 2FA to log in even though I check the box "remember me on this device." It works as expected on Chrome.
Anyone else has this problem? Is there some settings I need to enable/disable? I've turned OFF "Block all 3rd party cookies" and "send do not track" to no avail.
Thanks

@thataboy Are you using the portable version?