Don't use blue-green deployment strategy for clock/web containers

Context
When a deployment of a new version is underway, the jobs on the worker app are still running.
The worker container might still run a job on the old schema while the version is being updated and causing the job to error.
Changes proposed in this pull request
Use standard deployment strategy, so the worker container is updated and restarted.
Things to check

[x] This code does not rely on migrations in the same Pull Request
[x] If this code includes a migration adding or changing columns, it also backfills existing records for consistency
[x] API release notes have been updated if necessary
[x] This code does not rely on the addition/removal of Azure config environment variables in the same Pull Request
[x] New environment variables have been added to the Azure config

Interesting! Does the standard deployment stop all old instances first, and then start up the new ones once they've stopped?
Is there a chance we get errors because the containers aren't available?

Interesting! Does the standard deployment stop all old instances first, and then start up the new ones once they've stopped?
Is there a chance we get errors because the containers aren't available?

@benswannack I the standard strategy just restarts the app container with the new docker image.
we do this only for the worker containers to check if it prevents errors during deployment, because blue-green might run an instance of the app which might run against an out of date db schema


feat: Algebra.Homology.ShortComplex.Basic

This PR introduces the category of short complexes X₁ ⟶ X₂ ⟶ X₃ in a category with zero morphisms.

This is the first PR in a series which intends to develop the homology of these short complexes, and redefining the homology in mathlib4. The whole code (which also includes the construction of derived categories) appear at #4197

Looks great, just the remaining minor comments.
bors d+

Thanks very much @kbuzzard & @semorrison for these reviews!
bors r+


inflorescence development (+more)

Hi,
Here is more on inflorescence related terms.
# [p] biological_process (GO:0008150)
-----[i] development (GO:0007275)
---------[i] morphogenesis (GO:0009653)
------------[i] shoot morphogenesis (GO:0010016)
--------------[p] inflorescence morphogenesis (GO:NEW)
; synonym:inflorescence development
----------------[p] flower development (GO:0009908)
-------------------[p] petal development (NEW)
-------------------[p] sepal development (NEW)
-------------------[p] stamen development (NEW)
---------------------[p] anther development (NEW)
-------------------[p] gynoecium development (NEW)
---------------------[i] ovary development (NEW)
----------------[p] spikelet development (sensu
Poaceae) (GO:NEW)
-------------------[p] glume development (sensu
Poaceae) (GO:NEW)
-------------------[p] floret development (sensu
Poaceae) (GO:NEW)
----------------------[p] stamen development (NEW)
-------------------------[p] anther development (NEW)
----------------------[p] gynoecium development (NEW)
-------------------------[p] ovary development (NEW)
----------------------[p] lemma development (NEW)
----------------------[p] palea development (NEW)
--------------[p] flower development (GO:0009908)
----------------[p] petal development (NEW)
----------------[i] sepal development (NEW)
----------------[p] stamen development (NEW)
------------------[p] anther development (NEW)
----------------[p] gynoecium development (NEW)
------------------[p] ovary development (NEW)
------------[i] organogenesis (GO:0009887)
--------------[i] floral organ development (NEW)
----------------[i] petal development (NEW)
----------------[i] sepal development (NEW)
----------------[i] stamen development (NEW)
------------------[p] anther development (NEW)
----------------[i] gynoecium development (NEW)
------------------[p] ovary development (NEW)
--------------[i] bract development (sensu Magnoliophyta)
----------------[i] floral bract development (NEW)
------------------[i] lemma development (NEW)
------------------[i] palea development (NEW)
----------------[i] inflorescence bract development (NEW)
------------------[i] glume development (sensu Poaceae)
(GO:NEW)
--------------[i] nectary development (sensu Magnoliophyta)
Reported by: jaiswalp
Original Ticket: "geneontology/ontology-requests/1465":https://sourceforge.net/p/geneontology/ontology-requests/1465

thanks www.movied.org


Auto-switch status to "need review" when attaching a patch

Spin-off from 754190 Auto-switch status to "need work" when pasting a patch review

Dreditor is being decommissioned due to the lack of availability of current maintainers and the fact that Drupal.org is becoming more feature rich at a much faster rate than Dreditor itself now.
This decision was also partially made due to the amount of work (complete rewrite) it would take to create an "official" Firefox extension (#256).
If you already have the extension installed, it should continue working for a while until, inevitably,  the markup on Drupal.org changes. It will no longer be updated.
We understand that many of you love this extension, as do we. This isn't the end, in fact, it's a much brighter beginning. All the things we love about Dreditor can, and should, be moved into Drupal.org natively.
For more information, please follow: https://www.drupal.org/node/2779729

This issue was moved to dreditor/dreditor#43


build v4.5.3 (with dynamic libraries)

I cleaned up conda-forge/staged-recipes#682 which builds shared SuiteSparse libraries compatible with the  open scikit-umfpack PR.  Sstatic libraries actually get built as well, but make install doesn't install them.
I am now using SuiteSparse_config.mk as in master, but it no longer seems necessary to have separate files for linux and OS X.
I changed the license info in meta.yaml slightly.  I moved LGPL v2 first as that is what the majority of the code seems to be licensed under (I only found one library with a BSD 3-clause license).  In the v4.5.3 source the licenses are more clearly stated in the separate /Doc/License.txt within each library's subfolder.
Adding cmake to the build dependencies was needed for building the included Metis v5.1.0.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

Is there some reason not to install both static and dynamic libraries?

I am now using SuiteSparse_config.mk as in master, but it no longer seems necessary to have separate files for linux and OS X.

Yeah, I started to make them pretty similar at the end. For the most part, started using a bunch of ?= instead of = allowed most of the configuration to happen in build.sh, which seemed preferable anyways. I emailed Tim Davis making this exact suggestion though I don't know if he will go for it.

I changed the license info in meta.yaml slightly. I moved LGPL v2 first as that is what the majority of the code seems to be licensed under (I only found one library with a BSD 3-clause license). In the v4.5.3 source the licenses are more clearly stated in the separate /Doc/License.txt within each library's subfolder.

Yeah, that seems reasonable to me. Licensing here is a bit of a pain unfortunately. Appreciate that you added Apache 2.0 for METIS.

Adding cmake to the build dependencies was needed for building the included Metis v5.1.0.

👍

As far as the static libraries, they do also get built, but I didn't see a way to get make install to install them.
After the make completes, I can see static libraries in various subfolders, e.g. for CHOLMOD the static lib is at ${SRC_DIR}/CHOLMOD/Lib/libcholmod.a.  Obviously we could manually cp them, but maybe there is a way to do it from the Makefile that I overlooked?

CI is now passing. will try removing the patch and adding install for the static libs

Seems there is an issue copying the static libs over. Here is part of the CircleCI log.
cp: cannot stat `/feedstock_root/build_artefacts/work/SuiteSparse/CHOLAMD/Lib/libcholamd.a': No such file or directory
Command failed: /bin/bash -x -e /recipe_root/build.sh

I see there is a PR at staged-recipes for a METIS package as well.  How do we make sure the METIS compiled here doesn't end up conflicting with that one?
Apparently the SPQR_TBB.patch wasn't needed (not sure why I needed it to build successfully on my local linux system).

I see there is a PR at staged-recipes for a METIS package as well. How do we make sure the METIS compiled here doesn't end up conflicting with that one?

I'm not sure how much we should push that one. My concern is the licensing with it is totally opaque. Also, we will want to move to SuiteSpare 4.5.x eventually, which includes a copy/version of METIS that has clear licensing. In any event, let's cross that bridge when we get there.

Apparently the SPQR_TBB.patch wasn't needed (not sure why I needed it to build successfully on my local linux system).

Interesting. It does seem to be working. What version of Linux were you using?

Basically, this is looking really good. Thanks for doing this @grlee77. I'll try to find some time tomorrow or Friday to give it a closer look.

I just noticed that the linux case is still passing -fopenmp.  I can fix that.

Interesting. It does seem to be working. What version of Linux were you using?

Ubuntu 14.04.  I didn't look into it much, but the errors reported were:
spqr_parallel.o: In function `spqr_zippy<std::complex<double> >::~spqr_zippy()':
spqr_parallel.cpp:(.text._ZN10spqr_zippyISt7complexIdEED2Ev[_ZN10spqr_zippyISt7complexIdEED5Ev]+0x3): undefined reference to `vtable for tbb::task'
spqr_parallel.o: In function `spqr_zippy<double>::~spqr_zippy()':
spqr_parallel.cpp:(.text._ZN10spqr_zippyIdED2Ev[_ZN10spqr_zippyIdED5Ev]+0x3): undefined reference to `vtable for tbb::task'
spqr_parallel.o: In function `spqr_zippy<std::complex<double> >::~spqr_zippy()':
spqr_parallel.cpp:(.text._ZN10spqr_zippyISt7complexIdEED0Ev[_ZN10spqr_zippyISt7complexIdEED0Ev]+0x3): undefined reference to `vtable for tbb::task'
spqr_parallel.o: In function `spqr_zippy<double>::~spqr_zippy()':
spqr_parallel.cpp:(.text._ZN10spqr_zippyIdED0Ev[_ZN10spqr_zippyIdED0Ev]+0x3): undefined reference to `vtable for tbb::task'
spqr_parallel.o: In function `spqr_zippy<std::complex<double> >::execute()':
spqr_parallel.cpp:(.text._ZN10spqr_zippyISt7complexIdEE7executeEv[_ZN10spqr_zippyISt7complexIdEE7executeEv]+0x7e): undefined reference to `tbb::internal::allocate_child_proxy::allocate(unsigned long) const'
spqr_parallel.cpp:(.text._ZN10spqr_zippyISt7complexIdEE7executeEv[_ZN10spqr_zippyISt7complexIdEE7executeEv]+0xca): undefined reference to `tbb::task::spawn_and_wait_for_all(tbb::task_list&)'
spqr_parallel.o: In function `spqr_zippy<double>::execute()':
spqr_parallel.cpp:(.text._ZN10spqr_zippyIdE7executeEv[_ZN10spqr_zippyIdE7executeEv]+0x7e): undefined reference to `tbb::internal::allocate_child_proxy::allocate(unsigned long) const'
spqr_parallel.cpp:(.text._ZN10spqr_zippyIdE7executeEv[_ZN10spqr_zippyIdE7executeEv]+0xca): undefined reference to `tbb::task::spawn_and_wait_for_all(tbb::task_list&)'
spqr_parallel.o: In function `void spqr_parallel<double>(long, int, spqr_blob<double>*)':
spqr_parallel.cpp:(.text._Z13spqr_parallelIdEvliP9spqr_blobIT_E[_Z13spqr_parallelIdEvliP9spqr_blobIT_E]+0x2e): undefined reference to `tbb::task_scheduler_init::initialize(int, unsigned long)'
spqr_parallel.cpp:(.text._Z13spqr_parallelIdEvliP9spqr_blobIT_E[_Z13spqr_parallelIdEvliP9spqr_blobIT_E]+0x38): undefined reference to `tbb::internal::allocate_root_proxy::allocate(unsigned long)'
spqr_parallel.cpp:(.text._Z13spqr_parallelIdEvliP9spqr_blobIT_E[_Z13spqr_parallelIdEvliP9spqr_blobIT_E]+0x77): undefined reference to `tbb::task_scheduler_init::terminate()'
spqr_parallel.cpp:(.text._Z13spqr_parallelIdEvliP9spqr_blobIT_E[_Z13spqr_parallelIdEvliP9spqr_blobIT_E]+0x92): undefined reference to `tbb::task_scheduler_init::terminate()'
spqr_parallel.o: In function `void spqr_parallel<std::complex<double> >(long, int, spqr_blob<std::complex<double> >*)':
spqr_parallel.cpp:(.text._Z13spqr_parallelISt7complexIdEEvliP9spqr_blobIT_E[_Z13spqr_parallelISt7complexIdEEvliP9spqr_blobIT_E]+0x2e): undefined reference to `tbb::task_scheduler_init::initialize(int, unsigned long)'
spqr_parallel.cpp:(.text._Z13spqr_parallelISt7complexIdEEvliP9spqr_blobIT_E[_Z13spqr_parallelISt7complexIdEEvliP9spqr_blobIT_E]+0x38): undefined reference to `tbb::internal::allocate_root_proxy::allocate(unsigned long)'
spqr_parallel.cpp:(.text._Z13spqr_parallelISt7complexIdEEvliP9spqr_blobIT_E[_Z13spqr_parallelISt7complexIdEEvliP9spqr_blobIT_E]+0x77): undefined reference to `tbb::task_scheduler_init::terminate()'
spqr_parallel.cpp:(.text._Z13spqr_parallelISt7complexIdEEvliP9spqr_blobIT_E[_Z13spqr_parallelISt7complexIdEEvliP9spqr_blobIT_E]+0x92): undefined reference to `tbb::task_scheduler_init::terminate()'
spqr_parallel.o:(.data.rel.ro._ZTI10spqr_zippyIdE[_ZTI10spqr_zippyIdE]+0x10): undefined reference to `typeinfo for tbb::task'
spqr_parallel.o:(.data.rel.ro._ZTI10spqr_zippyISt7complexIdEE[_ZTI10spqr_zippyISt7complexIdEE]+0x10): undefined reference to `typeinfo for tbb::task'
spqr_parallel.o:(.data.rel.ro._ZTV10spqr_zippyIdE[_ZTV10spqr_zippyIdE]+0x28): undefined reference to `tbb::task::note_affinity(unsigned short)'
spqr_parallel.o:(.data.rel.ro._ZTV10spqr_zippyISt7complexIdEE[_ZTV10spqr_zippyISt7complexIdEE]+0x28): undefined reference to `tbb::task::note_affinity(unsigned short)'
collect2: error: ld returned 1 exit status

Looks like the OpenMP fix is working.
Is it possible the wrong compiler was getting picked up on Ubuntu 14.04? There are complaints like undefined reference to vtable, which look a bit strange.

I think the last two commits have addressed the remaining comments.

I see that you already pinned cvxopt to use v4.4.* so merging this shouldn't break anything.  Then we can test the scikit-umfpack PR over at staged-recipes.

LGTM. Thanks @grlee77. Let's put it through its paces. 🏇


Website down?

I haven't been able to load the website in the last 2 days; it times out, So I can't load any files with which to work.
Is the site down atm?

The website is back up for me.


Better support for user ID strings (-u) when signing

When using pivit -sign -u <ID>, we currently support specifying either an email address, or a lowercase hex string prefixed with 0x.
We should also support uppercase hex strings, and not necessarily prefixed with 0x.

Completed in PR #14


Fury FAQ

Apache Fury
Apache Fury  ── A blazing-fast cross-language serialization framework powered by just-in-time compilation and zero-copy !

FAQ

You can write about some problems you encounter during use here or create issues .
Create issues：https://github.com/apache/fury/issues
Road Map:#1017
Users: #1766

If uses have some issues, they should create it in https://github.com/apache/fury/issues instead of here. Do we really need this issue?

If uses have some issues, they should create it in https://github.com/apache/fury/issues instead of here. Do we really need this issue?

I'm not sure about this, but it seems that almost all communities have FAQ links. Maybe we can shrink the font size of the navigation bar a bit and leave room for the “Team” and “Users” pages.I think it is more important to fill in the content now. At present, the home page is empty and needs to be filled with more introductions and content.

Maybe it should be a page like https://arrow.apache.org/faq/ rather an issue?

Maybe it should be a page like https://arrow.apache.org/faq/ rather than an issue?

This is a much better choice.

I will close this issue, we can open a new issue to add a new FAQ page. But more importantly, we need to decide what should be included here


Quick fix to prioritize bigint to avoid bigint being mapped to Int32

Quick hot patch without having to refactor the whole function logic.

Reordering it has fixed this specific issue, tested at my local env. But I understand if you want to make a more bulletproof solution.


Only 3 speeds

Hi
Ive just installed the esp home version.  I noticed that there are only 3 fan speeds, exclusing automatic. Wilst the original has 4 and automatic. Is it possible to ad the 4th fan speeds?

Your image looks different from mine:

I can send 5 different speeds from the remote, and from HA / ESPHome climate (2,3,4,5,6)
You might have an updated yaml file where the 5th value is not yet mapped to quiet in the esphome climate class.
I don't think we can send more than 5 speed settings to the unit using the current reverse-engineering of the protocol. if you have information on how to do this otherwise, we can patch the core files to do so :)


[Docs] Update "create docs issue" hyperlink to use square brackets in PR title, not colon

Description
The issue template here uses a colon to categorize issues (like all of the issue templates do).
This PR updates the "create docs issue" hyperlink in the docs to use square brackets, not a colon as a category-to-PR title separator.
Checklist

[x] Signed commits signed.
[x] PR includes [<name of area>]

Fixes #932


Reduce emit overhead to ~50% of prior, by caching class-name of java-script module/interface.

Made modification to react-native code that reduces the communication channel overhead to ~50% of prior, in some cases, by caching the class-name of the java-script module/interface.
For me it reduced the run-time of the RCTDeviceEventEmitter.emit function from 1438ms to 715ms, over a period of 8 seconds in my Android app. My project requires many emit calls, as I'm transferring real-time EEG data from a Muse headband to my react-native UI to be graphed, so this optimization was very helpful in my case.

Nice, thanks for measuring the optimization. Just some small nit and this looks good to me.
cc @astreet

How To test the performance? Is there any docs?

@leeight I don't know of an automated way, but I did it by just starting my app, enabling the eeg data transfer in my app from Java to JS, starting the profiler included in "Android Device Monitor", waiting for 8 seconds, then stopping it and examining the profiler data to see how many milliseconds were spent inside the RCTDeviceEventEmitter.emit function.
The run-time was changed dramatically enough (1438ms to 715ms) that I didn't need a more precise approach in this case. (and I had done two earlier profiles just before the reference one, and the times were very similar, so I know it was from my change and not just fluctuation)

@Venryx This is missing the import for Nullable. Tests are failing with
/home/ubuntu/react-native/ReactAndroid/src/main/java/com/facebook/react/bridge/JavaScriptModuleRegistration.java:29: error: cannot find symbol
  private @Nullable String mName;
           ^
  symbol:   class Nullable
  location: class com.facebook.react.bridge.JavaScriptModuleRegistration
/home/ubuntu/react-native/ReactAndroid/src/main/java/com/facebook/react/bridge/GuardedAsyncTask.java:-1: note: Some input files use unchecked or unsafe operations.

@facebook-github-bot shipit


Latest rustup update version breaks compilation

Describe the bug
Running a fresh rustup install nightly && cargo build fails, the core message being:
note: Could not start dynamically linked executable: /home/[xxx]/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin/gcc-ld/ld.lld
          NixOS cannot run dynamically linked executables intended for generic
          linux environments out of the box. For more information, see:
          https://nix.dev/permalink/stub-ld
          collect2: error: ld returned 127 exit status

Steps To Reproduce
Steps to reproduce the behavior:

have a rust project
rustup install nightly (or rustup update if you already have one)
cargo build

Expected behavior
Either the rustup gcc/ld to be patched for NixOS use, or rust to use the system gcc/ld.
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.1.90, NixOS, 24.05 (Uakari), 24.05pre625274.205781405197`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.2`
 - channels(root): `"nixos-23.11, nixpkgs-23.11"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Actually, it looks like this is an issue specifically appearing with nightly-2024-05-18-x86_64-unknown-linux-gnu; so I'll try to pass the message upstream.

Very specifically, this is the commit introducing the issue, when it has been decided to switch from the system linker to ldd.
I suppose the new [toolchain]/lib/rustlib/x86_64-unknown-linux-gnu/bin/gcc-ld/ binaries should also be elf-patched?

Patching those binaries will make them execute, but they also need the ld-wrapper applied so that the binaries they build will also get patched automatically.


Jest leaks memory from required modules with closures over imports

🐛 Bug Report
We are running into a issue in Jest 23.4.2 where Jest leaks and runs out of memory when running a moderately hefty test suite (~500 to 1000 test files). I believe I have isolated this to the require system in Jest and it is not the fault of other packages. Even with the most minimal recreation it leaks around 2-6MB per test.
This is very similar to https://github.com/facebook/jest/issues/6399 but I opted to make a new issue as I think it's not specific to packages or the node environment. I think it's the also the source or related to the following issues as well but didn't want to sidetrack potentially different issues and conversations.
https://github.com/facebook/jest/issues/6738
https://github.com/facebook/jest/issues/6751
https://github.com/facebook/jest/issues/5837
https://github.com/facebook/jest/issues/2179
This is my first time digging into memory issues, so please forgive me if I am focusing on the wrong things!
Link to repl or repo
I have created a very minimal reproduction here: https://github.com/pk-nb/jest-memory-leak-repro. You should be able to run and see heap grow and also debug it with the chrome node devtools. With the reproduction, we can see this happens in both JSDOM and node environments in Jest.

To Reproduce
Simply run a test suite with tests that require in a file that creates a closure over an imported variable:
// sourceThatLeaks.js

const https = require('https');

let originalHttpsRequest = https.request;

https.request = (options, cb) => {
  return originalHttpsRequest.call(https, options, cb);
};

// If this is uncommented, the leak goes away!
// originalHttpsRequest = null;

// 1.test.js, 2.test.js, ...

require("./sourceThatLeaks");

it("leaks memory", () => {});

While every worker leaks memory and will eventually run out, it is easiest to see with --runInBand.
Note that we are not doing anything with require to force a reimport—this is a vanilla require in each test.
When run with jasmine, we can see the issue go away as there is no custom require implementation for mocking code. We also see the issue disappear if we release the variable reference for GC by setting to null.
I believe the closure is capturing the entire test context (which also includes other imports like jest-snapshots) which quickly adds up.
Expected behavior
Hoping to fix so there is no leak. This unfortunately is preventing us from moving to Jest as we cannot run the suite on our memory bound CI (even with multiple workers to try to spread the leak).
I'm hoping the reproduction is useful—I spent some time trying to fix with some basic guesses at closures but ultimately am in over my head with the codebase.
You can see the huge closure in the memory analysis so I'm inclined to think it's some closure capture over the require implementation and/or the jasmine async function (promise).

Some leak suspects:

Closures (section 4)

Wondering if this or other similar code in here is a closure capture that V8 can't break https://github.com/facebook/jest/blob/master/packages/jest-runtime/src/index.js#L589-L591

Promises (async generator) leaking

Wondering if the promise / asyncToGenerator babel is capturing scope with the next, preventing it from releasing? https://github.com/facebook/jest/blob/master/packages/jest-runner/src/run_test.js#L218-L220

Global data (section 1)

Capturing too much with the global console? https://github.com/facebook/jest/blob/master/packages/jest-runner/src/run_test.js#L108

All of the above?

These are educated guesses, but there are quite a few closures within the runtime / runner / jasmine packages though so it's very difficult (as least for me being new to the codebase) to pinpoint where the capture lies. I'm hoping that there's a specific point and that each closure in the runtime would not present the same issue.
Our suite
I have ensured the issue stems from Jest and not our suite—I ran the old suite (mocha) and saw a healthy sawtooth usage of heap.
Run npx envinfo --preset jest
▲ npx envinfo --preset jest
npx: installed 1 in 2.206s

  System:
    OS: macOS High Sierra 10.13.6
    CPU: x64 Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz
  Binaries:
    Node: 8.11.3 - ~/.nodenv/versions/8.11.3/bin/node
    Yarn: 1.9.4 - ~/.nodenv/versions/8.11.3/bin/yarn
    npm: 5.6.0 - ~/.nodenv/versions/8.11.3/bin/npm
  npmPackages:
    jest: ^23.4.2 => 23.4.2

Please let me know if I can help in any way! I'd really love to get our company on Jest and am happy to help where I can. Thanks @lev-kazakov for the original isolation repro.

Wow, that's an awesome report, @pk-nb! @aaronabramov can we use --detectLeaks against Jest and bisect to the commit?

I'm not sure I follow this repro. You're doing this:
// sourceThatLeaks.js

const https = require('https');

let originalHttpsRequest = https.request;

https.request = (options, cb) => {
  return originalHttpsRequest.call(https, options, cb);
};

// If this is uncommented, the leak goes away!
// originalHttpsRequest = null;

It seems expected to have a leak, since you patch https.request, but never reset it. When I look from within Jest, the https module returned seems to be the actual one, not a mock, so each time this code is executed, the previous patch is repatched, causing the memory to grow more and more, the patches never getting released.
When I look with Jasmine, the memory does go up too, just much slower for two reasons:

First, the sourceThatLeaks.js file is only executed once. I guess it's because Jasmine caches its export, meaning that the https patching only ever occurs once. You need to copy the file content into each file in order to have the same behavior than on Jest.

The http patch itself doesn't seem to require a lot of memory. To see the leak, you can allocate a huge buffer (such as a 100MiB buffer), use it inside the closure, and monitor external instead of heapUsed. You'll notice that in this case, the memory keeps growing. This is expected, since you never remove the hooks you setup on http.

I also tried your code on 23.0.0, and it seems to also reproduce the behavior, suggesting it always worked this way. Am I missing something?

Hi @arcanis —thanks for taking the time to look at this.
I will certainly admit the example given is not great code, but is an example of dependencies found in the wild that aim to mock or extend, including graceful-fs, node-agent, and supertest. I assume there are quite a few packages in the wild. We are just porting to Jest now and not comparing this to previous versions of Jest—I'm not sure what version @aaronabramov is updating from.
What's interesting is that I could not repro with the buffer suggestion you posted. Even though it is in the closure, it is being released in a sawtooth.
const https = require('https');

let buffer = Buffer.alloc(1000000000)

https.request = (options, cb) => {
  console.log(buffer.byteOffset, nodeBuffer.length);
  return cb(buffer.byteOffset);
};

I updated suite 01 and 03 in this repro branch if you want to check. https://github.com/pk-nb/jest-memory-leak-repro/tree/external-buffer. I'm not sure why this would happen—maybe v8 can be more intelligent with optimizing out the call or something.
With respect, I think the Jest require system should aim to support all of the node require ecosystem, including these "singleton" packages that assume a require cache. I imaging this is tricky with the separate Jest environments but hopefully could be supported by cleaning / flushing the requires in Jest. Otherwise the above node packages end up unusable in Jest.

Thanks for the context @mjesun, didn't realize this had been attempted before. For anyone checking on the issue, here's the revert PR https://github.com/facebook/jest/pull/5009.
Maybe a poor idea, but could we simply replace the core module objects following each test to release any global modifications?
Something like:
coreModules.forEach(() => delete require.cache[key])

Not sure if the core modules have special handling that makes the cache invalidation not work.

What's interesting is that I could not repro with the buffer suggestion you posted. Even though it is in the closure, it is being released in a sawtooth.

Because in this new code you're always replacing the previous hook:
https.request = (options, cb) => {
  console.log(buffer.byteOffset, nodeBuffer.length);
  return cb(buffer.byteOffset);
};

Since you overwrite https.request, the previous function gets garbage collected, and since the previous function gets garbage collected, the buffer it used gets released. To validate my theory I used a code similar to this:
let originalHttpsRequest = https.request;
let buffer = new Buffer(1024 ** 3);

https.request = (... args) => {
  return originalHttpsRequest.call(... args, buffer);
};

Thank you for taking care of the problem. Here's my repo on bug #6738 , I hope it helps to recreate the problem.

Wanted to leave an update—we found our accidental capture of http from the nock library. We accidentally were only calling cleanAll, which does not release the http modifications like nock.restore does. Calling this allowed our test suite to release the full set of requires in each suite (a lot of memory each suite).
I can close this if you'd like as this was a user issue (I hope this is a good google reference for others who made the same mistake we did). It's still a bummer that libraries that don't release there modifications will be a blocker for others. I'm not sure what is actionable by Jest outside of moving to a environment reset per test suite (maybe by resetting / reimporting all built in modules?) or running in separate threads so that leaks can't continue.

We have the same issue with graceful-fs not releasing fs. It would indeed be awesome tom somehow force drop or at least flag it when stuff like this happens

@pk-nb do u have a workaround for that?

@thymikee Thank you for the quick answer. Sadly it appears to not fix the issue. After ~1000 tests I start maxing out my remaining RAM which is about 10 - 12 GB. The trend of ever-increasing memory-usage is strictly linear which should be further proof that this is not a memory leak on the tests end.

I'm pretty sure jest itself doesn't leak.  Or are you able to put together a reproduction?

It is an Angular project, so in most of the test files I use the TestBed to configure my testing module. Other than that we don't use any setup/teardown. Am I potentially not respecting any special rules for Angular unit tests with Jest?
`
describe('TestComponent', () => {
let component: TestComponent;
let fixture: ComponentFixture;
beforeEach(() => {
const testHandlerStub = {};
TestBed.configureTestingModule({
imports: [TestingModule, StoreModule.forRoot(store)],
declarations: [TestComponent],
schemas: [NO_ERRORS_SCHEMA],
providers: [{ provide: TestHandler, useValue: testHandlerStub }],
});
fixture = TestBed.createComponent(TestComponent);
component = fixture.componentInstance;
});
it('can load instance', () => {
expect(component).toBeDefined();
expect(component).toBeTruthy();
});
describe('ngOnInit()', () => {
it('triggers initializing', () => {
const spy: any = spyOn(component.handler, 'init');
component.ngOnInit();
  expect(spy).toHaveBeenCalled();
});

});
});
`
Most (70%) of our tests look somewhat like this.

@markonyango any non-native node module which decorates a native module will leak in jest.
see https://github.com/facebook/jest/issues/6399#issuecomment-415083479 for details.
graceful-fs and agent-base are 2 common libraries that do such things.
i've created jest-leak-fixer some while ago in order to mitigate this issue. it is a hack. it patches graceful-fs and agent-base so not to leak.
since graceful-fs have introduced a hack of their own you can fork jest-leak-fixer (or PR), remove the code that handles graceful-fs, and try running your test suite again.
if this does not help, you can help us mapping other leaking modules by running jest-leak-fixer tests against your dependencies graph, one dependency at a time.

@lev-kazakov Sadly, implementing the jest-leak-fixer according to your README did not solve the problem. I would help you running your tests against our dependencies graph if you could instruct me how to do it. If you could send me a message with instructions, I could help you there.

Possibly related to this: https://github.com/nock/nock/issues/1448

any updates? We still face memory leaks from time to time, especially in a memory-constrained CI environment (leaks add up and crash at some point)

@mjesun can you help finding someone relevant to review https://github.com/facebook/jest/pull/8331?
it's a kind of a hack that allows mitigating these kind of memory leaks, till we come up of something smarter to do.

For anyone else getting hit by this: I used @B4nan's pre test script ahead of running my tests and this seemed to stop the memory leak https://github.com/mikro-orm/mikro-orm/commit/5e848473cffafb5ae981344cbe1868b987b4871a

this issue has also been surfacing in GitHub Actions in this project here: https://github.com/lifeiscontent/realworld/pull/229/checks?check_run_id=826716910

In my team we have the same issue, causing our tests failing with a 'out or memory' error.
After investigations it seems lib aws-xray-sdk to be the cause, comment any references to it fix the issue.

We run our tests using plain old unix tools to avoid running into these memory leak issues. In case it helps someone:
It's a combination of find, sort and xargs. It finds all test files, sort them randomly, then runs 4 instances of jest in parallel, each will test chunks of 5 files.
find ./tests -type f \( -name \*.test.ts -o -name \*.test.tsx \) | sort -R | xargs -L 5 -P 4 jest --runInBand --logHeapUsage

TLDR: using a NodeEnvironment was the problem.
My two cents on this, I was using a NodeEnvironment for my tests:
https://jestjs.io/docs/en/configuration#testenvironment-string
In here I was setting up the database, dropping it etc. before each of my tests ran.
In the end I ditched this in favour of having a helper class which I just instantiate in the set up of each of my test files. This instance is gets garbage collected without any issues.
Realise this probably isn't the most explicit comment but can't post any code sadly.

Ok so got a work around which I hope may be useful to others.
You can use this solution to run your tests in batches, one jest process per batch. The processes are run sequentially so should keep the memory usage down. Not ideal but functional and I needed a quick fix as this was issue was preventing us merging any PRs.
// run-tests-ci.ts
import {execSync} from "child_process";
import glob from "glob";

const shell = (cmd) => execSync(cmd, {stdio: "inherit"});

const run = async () => {
  logger.info(
    "Running tests in batches to avoid memory leak issue... this means you will see jest start up multiple times.",
  );

  const files = await glob.sync("./test/**/*.test.ts");

  const batchSize = 20;
  let batch: string[] = [];
  const runBatch = () => {
    if (batch.length) {
      shell(`jest ${batch.join(" ")}`);
      batch = [];
    }
  };

  for (const file of files) {
    batch.push(file);
    if (batch.length === batchSize) {
      runBatch();
    }
  }

  runBatch();
};

run().catch((err) => {
  logger.error(err);
  process.exit(1);
});

package.json
{
  "scripts": {
    "test-ci": "ts-node test/run-tests-ci.ts",
  },
// etc.
}

then run with npm run test-ci

@stuart-clark-45 how do you combine the output from mulitiple --coverage's?

I think as mentioned a few times, this is not a bug in Jest per say, but the way Jest works (its own module cache, different globals per test file etc.) can sometimes violate assumptions made by libraries when they patch/override/add to globals (either core modules or globalThis). Not sure what we can do in Jest to detect this and warn, instead of just leak. One thing is #8331 for modules and potentially trying to add a Proxy around the global inside the scripts, but I'm not sure it's a particularly good idea. Much (probably by far most) modifications are perfectly safe to make, so there'd be a lot of false positives.

@SimenB If it's innate to the implementation of Jest that a lot of larger code bases might run into these problems then I think it would be very helpful to actually have more details in the docs on why this would happen and common ways of debugging it (beyond the existing CLI args).
As it currently stands there's not a lot of detail on how the module loading works in the docs. And that's understandable in the sense that users "shouldn't have to know how it works". However if it is the case that having somewhat of an understanding of at least the general working of Jest can help users write more performant tests and understand why memory leaks can easy become an issue, then it's perhaps worth reconsidering.

This issue is stale because it has been open for 1 year with no activity. Remove stale label or comment or this will be closed in 30 days.

Oh no, you don't.

for the agent-base, I'm using jest.mock to mock the patch-core module. It's safer than replacing content since the original file may not be replaced back.
// package.json
    "setupFilesAfterEnv": [
      "./test/setup-after-env.ts"
    ],

// test/setup-after-env.ts
jest.mock('agent-base/patch-core', () => ({}));


JustifyContent changes behaviour of minWidth

Report

[x] I have searched existing issues and this is not a duplicate

Issues and Steps to Reproduce

Set up a view with flexDirection: row and a minWidth (can be px or percentage value)
Add two or more children (styling is not too important here - they can have zero width)
Set different values of justifyContent the parent view

Expected Behavior
The width of the parent should not change when changing the value of justifyContent
Actual Behavior

Setting justifyContent: space-around grows the parent for 1+ children
Setting justifyContent: space-between grows the parent for 2+ children

Link to Code
https://codesandbox.io/s/yoga-layout-min-width-bug-bjhz4

Just a note if this helps at all, in our code we have a horizontal scrollview the full width of the device, and set a horizontal padding on the content container, and then a horizontal margin on each of the child nodes
Normally you'd set minWidth: 100%, but here, that's equivalent to Dimensions.get('window').width
The fudge factor below seems to work across all values of preferredMargin and minimumMargin. Not sure if this will be of any use for debugging
const preferredMargin = 20 // 0-2 items
const minimumMargin = 10 // >3 items

const fudgeFactor = (preferredMargin - minimumMargin) / 2

const styles = StyleSheet.create({
  rowContentContainer: {
    minWidth: Dimensions.get('window').width - fudgeFactor,
    paddingHorizontal: preferredMargin - minimumMargin / 2
  },
  tileContainer: {
    marginHorizontal: minimumMargin / 2,
    width: (Dimensions.get('window').width - preferredMargin * 3) / 2
  }
})

Can you help me reproducing this issue on Yoga Playground ?
I am not able to follow what do you mean by

Setting justifyContent: space-around grows the parent for 1+ children
Setting justifyContent: space-between grows the parent for 2+ children

Sure! Here you go
To see the bug, select root > 1. It no width set, but does have min width set. Change justifyContent to space around, space between, and any other value. See that the size of the selected view changes
Here's a video demonstrating this

I think we fixed this one: https://www.yogalayout.dev/blog/announcing-yoga-3.0#correct-main-axis-size-calculation-for-indefinite-containers-using-justify-content

Fantastic work on yarn 3 🎉


Default network choice ... wonky?

The default network choice to display seems wonky for me, my main interface (wlan) is en0 (Mac user here), but instead en5 is chosen for display, which has no ipv4 and only a very small part of the traffic going through it.
Not quite sure why that is and what the best way to choose a default interface with psutil would be, but right now this is a bit strange.
Also good enough as a workaround would be the ability to change the network interface from inside the app without having to restart it (and loose history that way).

Yeah, tiptop isn't really made for dynamically choosing a network interface yet. I improved autoselection a bit (https://github.com/nschloe/tiptop/pull/83) so you get en0 by default. If that doesn't work, you can always use the --net argument on the command line.

Well, this sorta works. I now get the widget awdl0 chosen by default. I still think the real fix would be to choose the interface with most traffic as default. I guess that is something to look into how btop and others do this.

Sure! Pull requests welcome.


Clarification of SLA section please

Hi team - the SLA paragraph is quite confusing. Can you please update this and provide a crisp view on what SLAs exist and whether it is end-user to MSFT or carrier to MSFT.
Cheers!

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

ID: 2d8093af-ed47-d030-f8e9-c4442161bdda
Version Independent ID: 6b2109f1-29f2-8ec7-f200-202836051862
Content: Peering Service - FAQ - Azure
Content Source: articles/internet-peering/service-faqs.md
Service: internet-peering
GitHub Login: @prmitiki
Microsoft Alias: prmitiki

@PeteHaigh-MSFT Thanks for your feedback. Assigning to content author @prmitiki for review.

Docs will be refreshed with clarification on SLA. Pending update this quarter.
#please-close


Upgrade to terraform 0.9.8

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.


Set correct return type for SimpleXMLElement::__get()

If SimpleXMLElement is extended, it's children are also instances of the extending class.

@AJenbo Unfortunately, I can't accept your request since there is a bug in PhpStorm: https://youtrack.jetbrains.com/issue/WI-56660 which will completely break type inference on the dynamic properties of SimpleXML.
I will reopen and merge your request as soon as it's fixed.


ShaderMaterial params change all scenes that use it. Local to Scene not working

Godot version
4.0 beta 13
System information
Windows 10
Issue description
Two different meshes with two different materials, each one has a next pass ShaderMaterial. If you modify the values of the ShaderMaterial of one mesh, the others receive those changes too and I already set Local to Scene to true and tried different combinations, same exact result.
Steps to reproduce
Press play, the script will change the params of cube1 but cube2 will be changed too.
Minimal reproduction project
shader-params.zip

Did you make the ShaderMaterial unique? local to scene just means that it will not share with other instances of the scene, it does not mean that the resource will not be shared between instances within the same scene

I made it unique then the blue cube didn't turn white, but if I add another yellow cube this happens

I ran the MRP. I can see that you are indeed using the materials within scenes, so local_to_scene is the correct approach.
However, what you were missing was actually setting local to scene on the first material. You need to set local_to_scene on the parent resources as well.
Here is the heirarchy that you have in the MRP
Mesh (local to scene)
  |->  Material (not local to scene)
         |-> Next pass (local to scene)

Setting the material to local_to_scene makes it work as expected

Is this the correct way to achieve this if there are multiple instances, considering performance?

Yes


Add Azure Digital Twins stable (GA) REST API

This PR adds a new stable (GA) version of the Azure Digital Twins REST API.
Contribution checklist:

[x] I commit to follow the Breaking Change Policy of “no breaking changes
[x] I have reviewed the documentation for the workflow.
[x] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.


Refactor tests

This has been bothering me for a long while... Fix it by refactoring all the tests (but not WarnetTestFramework, yet) to give them more homogenous structure.
There are a few "tidy-ups" in here too, sorry, but it's but mainly just breaking things down into a function-per-test, much like the bitcoin core functional test suite.
Makes it easier to add new tests, and re-use parts of other tests.
Also improve test logging using logging module where possible.

fpush to re-add some erroneously-dropped comments,

A problem I had with the ln_test was that as part of it's setup it called a scenario (ln_init) but there's no way to check if the scenario failed or not. Perhaps the list of running scenarios should keep a list of failed ones?

A problem I had with the ln_test was that as part of it's setup it called a scenario (ln_init) but there's no way to check if the scenario failed or not. Perhaps the list of running scenarios should keep a list of failed ones?

They are marked as active with a bool, no? Can we check that?

They are marked as active with a bool, no? Can we check that?

Oh maybe, I didn't understand what not active meant.

LGTM. Ship it!


feat: added missing readme.md file with contribution instruction

No problem, I missed an image path and I didn't expect you to merge this so fast, just created another PR with the fix
I would like to add https://www.conventionalcommits.org/en/v1.0.0/ to this so you can automatically generate a changelog of your changes just by following the convention feat: ... for new features fix: ... for bug fixes and feat!: ... / fix!: ... for new features/fixes that requires additional steps on the player (starting a new campaign?)
to do that this repository will require the node/npm stack (I can take care of adding it and creating the script for you to easly publish the changelog)
should I go ahead and do it or is it something you are not interested in?
Also, if you can share some documentation/tutorial I would love to star contribuiting on features in this but I have literally no idea how to start on unity modding and even less on this repository per se...
Any link you can share to help me start out?

@cabarius

I just realized you already had https://github.com/cabarius/ToyBox/tree/master/ToyBox which is a mix of changelog and readme in a txt file
I took the liberty of adding the instructions and reference on how to contribuite to the readme in my other PR


[REQ] FFmpeg v7.1 builds

Any chance of getting FFmpeg v7.1 builds?

An issue fixed in 7.x is not back ported to 6.1, which causes build failure in 6.x variants with latest script (which updated mingw version) and prevents the release.
Posted this issue to FFMpeg tracker but IDK how long it will take to get it fixed.


Token tracker being non-functional in LLM

The token usage stats are not retrieved from LLM. Noticed some changes in the response structure in the LLM as well.
Usual response structure:
[llm/end] [1:chain:ConversationChain > 2:llm:ChatOpenAI] [3.54s] Exiting LLM run with output: {
  "generations": [
    [
      {
        "text": "ChatGPT is a language model developed by OpenAI. It is designed to generate human-like responses in a conversational manner. It is trained on a large amount of text data from the internet and is capable of understanding and generating text across a wide range of topics. ChatGPT uses deep learning techniques, specifically a method called the transformer architecture, to process and generate high-quality text responses. Its purpose is to assist users in various conversational tasks, provide information, and engage in interactive conversations.",
        "message": {
          "lc": 1,
          "type": "constructor",
          "id": [
            "langchain",
            "schema",
            "AIMessage"
          ],
          "kwargs": {
            "content": "ChatGPT is a language model developed by OpenAI. It is designed to generate human-like responses in a conversational manner. It is trained on a large amount of text data from the internet and is capable of understanding and generating text across a wide range of topics. ChatGPT uses deep learning techniques, specifically a method called the transformer architecture, to process and generate high-quality text responses. Its purpose is to assist users in various conversational tasks, provide information, and engage in interactive conversations.",
            "additional_kwargs": {}
          }
        }
      }
    ]
  ],
  "llmOutput": {
    "tokenUsage": {
      "completionTokens": 100,
      "promptTokens": 69,
      "totalTokens": 169
    }
  }
}

Current response structure:
[llm/end] [1:chain:ConversationChain > 2:llm:ChatOpenAI] [3.54s] Exiting LLM run with output: {
  "generations": [
    [
      {
        "text": "ChatGPT is a language model developed by OpenAI. It is designed to generate human-like responses in a conversational manner. It is trained on a large amount of text data from the internet and is capable of understanding and generating text across a wide range of topics. ChatGPT uses deep learning techniques, specifically a method called the transformer architecture, to process and generate high-quality text responses. Its purpose is to assist users in various conversational tasks, provide information, and engage in interactive conversations.",
        "message": {
          "lc": 1,
          "type": "constructor",
          "id": [
            "langchain",
            "schema",
            "AIMessage"
          ],
          "kwargs": {
            "content": "ChatGPT is a language model developed by OpenAI. It is designed to generate human-like responses in a conversational manner. It is trained on a large amount of text data from the internet and is capable of understanding and generating text across a wide range of topics. ChatGPT uses deep learning techniques, specifically a method called the transformer architecture, to process and generate high-quality text responses. Its purpose is to assist users in various conversational tasks, provide information, and engage in interactive conversations.",
            "additional_kwargs": {}
          }
        }
      }
    ]
  ]
}

The llmOutput object in response of the API call is undefined which holds the token statistics.
Steps to reproduce:

create a new sequential chain
Call the sequential chain
token stats missing in the response

version:
Node: v18
Langchain: 0.0.171

Got the same issue.

Can you share your code or a repro case?


Change High/Low to be 4am to 4am

I noticed in the docs that the daily high/low variables say that they are calculated between 6am and 6am when in reality it's calculated between 4am and 4am.
The documentation has been updated to reflect that they are calculated between 4am and 4am.

I can't remember but at one point were the daily high/low data points 6am to 6am or was it always 4am to 4am? I thought I remember seeing somewhere that it was 6am to 6am which is what I put in the documentation at the time.

This is a surprisingly tricky thing!
I had to do a bit of searching, but the 6 am/pm thing came from the overnight high/ low temperatures. I think ideally it would be sunset to sunrise, but I picked 6 pm as the start over night as a close enough approximation. the 4 am/pm is for the summaries and icons, from the original Dark Sky specifications.
This leaves two questions:

How should the rest of the daily parameters be calculated? Midnight to midnight (how it's working now)? Or 4 am/pm to match the icons and summaries. The issue with 4 am/pm is that (for example), the temperatureMaxTime could be on a different day, which feels confusing.
What should "daytime" and "overnight" mean (for temperatureLow/ temperatureHigh? 6 am/pm? Sunrise/sunset?

Are the summary and temperature High/Low currently 6am to 6am or are they 4am to 4am? I thought they were 6am to 6am but the other day I noticed that the temperature at 6am was lower than the daily temperatureLow so I thought it wasn't 6am to 6am.
This is how Dark Sky defines the temperature variables in their documentation:

temperatureHigh optional, only on daily
The daytime high temperature.

temperatureLow optional, only on daily
The overnight low temperature.

temperatureMax optional, only on daily
The maximum temperature during a given date.

temperatureMin optional, only on daily
The minimum temperature during a given date.

It seems to me like max and min are 12am to 12am and high low use 4am to 4am. From what I'm aware most providers use 6am to 6am for their daily high and low temperatures. I'm not entirely sure if everything is 6am to 6am or just the high/low and their day and night summaries. My preference is that the high, low and summaries all use the same start and end times be it 4am to 4am or 6am to 6am.

Would it make sense to have the precipitation be the same time range as the summaries be it 4am to 4am or 6am to 6am? Would better align the precipitation to the summaries so that overnight rain doesn't affect the next day summery/icon. (It shouldn't anyway but it seems like it does when I found the location with the "none" icon in #236)

Yea, great questions here, and really shows where the "art" of a weather API comes in. If there's a bunch of rain at 2 am, would I saw it rained that day, or the previous day? Agree that we should only have two different times (it's surprisingly computationally expensive to do these calcs, so each one adds time to requests), and I think sticking to 12-12 for most things makes sense, since otherwise the Max/Min times would start to get wonky.
Along these lines, I'm thinking we switch to 6 am/pm for everything. 4am/pm doesn't really make sense for daytime/ nighttime high/ low (if it's going to be 20 C at 5:00 pm, I'd call that during the day). It means that the icons/summaries will be slightly different than what Dark Sky did, but I guess we wait and see if anyone complains....
How does this sort of approach look?

Summary/ Icon: 6am to 6am. This uses

Modal precipitation type
Max probability
Cumulative accumulation
Mean visibility
Mean wind
Mean cloud cover

temperatureHigh: 6pm to 6am
temperatureLow: 6am to 6pm
Everything else: 12am to 12am

Coding this up and starting to second guess it- what I'm worried about is there being accumulation between 12am and 6am. which would mean the data returned showed precipitation for that day, but the icon (and summary) might not show show anything (since they would start at 6am)? This kinds of suggests going with the 4am/pm definition, since that makes these sorts of discrepancies less likely

Yeah, this kinda stuff is a bit tricky to figure out. The issue with using 4am to 4am for daily high/low temperatures is that you may miss the highest or lowest temperature of the day if they occur say at 5pm or 6am. Maybe that's why they use 6am to 6am for their daily high/low temperatures?
I'm not fully sure what other APIs do for precipitation but maybe they also consider it between 6am to 6am (or 6am to 6pm and 6pm to 6am for those with day and night forecasts)?

This has turned into more of a discussion and the PR no longer applies. Created a discussion to continue the conversation here https://github.com/Pirate-Weather/pirateweather/discussions/239


show how to update EF global tools

Fixes #8545

@Rick-Anderson Running this install command is all that's needed to get the latest stable version. Running update immediately after that has no effect. Here's an example to demonstrate what I mean.
Output from dotnet tool install -g dotnet-ef:
You can invoke the tool using the following command: dotnet-ef
Tool 'dotnet-ef' (version '3.1.7') was successfully installed.

Output from dotnet tool update -g dotnet-ef:
Tool 'dotnet-ef' was reinstalled with the latest stable version (version '3.1.7').

Notice that the version numbers are identical.

@bricelam  when is it necessary to run dotnet tool update --global dotnet-ef ? Is that just to update when you've already got it installed, in lieu of  dotnet tool install -g dotnet-ef ?

Yes, just to update to a new version when it's already installed.


fix: entity switch result when there is no default case

Hey, I just made a Pull Request!
this happens when there is only cases with if defined but no default case
:heavy_check_mark: Checklist

[x] A changeset describing the change and affected packages. (more info)
[ ] Added or updated documentation
[x] Tests for new functionality and regression tests for bug fixes
[ ] Screenshots attached (for UI changes)
[x] All your commits have a Signed-off-by line in the message. (more info)

Thanks @awanlin , just added some more info to the original changeset of this feature, please re-review :)


Option not selected in select with data-ng-options, unless binding or $watch is added

I have a SELECT element bound to a model and with options from the scope. See the following fiddle:
http://jsfiddle.net/provegard/Xetdr/6/
In Chrome and Firefox, when I select "Team 2" I get "Team 2". In IE9, I instead get "Team 1".
After having made the initial selection in IE9, I can select Team 2.
I have found two workarounds:

Bind to the model using {{}} in the HTML - not really feasible.
Watch the model using a $watch - my current choice.

This works in >= 1.3.16 and >= 1.4.0


Create few python functions in file_manager.py

Write following functions in file_manager.py
Note : Make sure not to push these to main branch, create a new branch.
All of these functions must have proper docstrings (refer to the docstrings of already existing functions).

is_file(file_name) - checks whether the file exists or not.
is_folder(folder_name) - checks whether the folder exists.
list_files(address) - lists all the file in the given address (not folders)
list_folders(address) - list all the folders at given address (not files)
list_all(address) - list both files and folders at given address
delete_file(file_name) - This function deletes the file.
copy_to(file_name, destination_folder) - Copies the file to the destination folder.
copy_file(file_name, new_file_name) - Copies the file to a new file at given location.

How to test the module?
The testing procedure involves using a file named test.py, which is explicitly excluded from version control via the .gitignore configuration. Consequently, any files generated within the test folder will also be excluded from version control and, thus, will not be pushed to the repository.

Can you assign this to me ?

Sure


+ is a common pattern

Another type of failure I see is looks like this: 10.1086/591526+10.1088/0004-637X/706/1/L203
I'm not sure how we'd be able to tell that a "+" is not part of the DOI.
When I search for this exact string, I found this listing: http://arxiv.org/abs/0805.4758  It seems that both DOIs are associated with the same paper.  One of the paper itself and another is an errata for the paper!
I'm thinking that we might get high fitness by having a special rule in the parser for splitting characters like "+&?".  If we see them right before some whitespace or a new DOI_START, then stop reading the DOI.

I'm also seeing DOIs like this: "10.1002/ajp.22007/abstract;jsessionid=397B42DDD36E4F654BAB381E3104ABB3.d02t04"  So we should include semi-colon in the list of splitting characters.


Coverity issue seen with CID: 178233

Static code scan issues seen in File: /samples/net/echo_client/src/tcp.c
Category: Null pointer dereferences
Function: compare_tcp_data
Component: Samples
Please fix or provide comments to square it off in coverity in the link: https://scan9.coverity.com/reports.htm#v32951/p12996

False positive


How fix this  shit

Need more information

game version
mod version
errorlog

Alright dude all that you need to do is just go to \LonaRpg\ModScripts_Mods\Cheat-Menu-Framework\Framework\scripts
Delete all code that he had and paste
I trough that will help to you
##---------------------------------------------------------------------------
## CheatUtils Module
##---------------------------------------------------------------------------
module CheatUtils
  #Check if a game is loaded
  def self.ingame?
    return (!SceneManager.scene_is?(Scene_MapTitle) and !SceneManager.scene_is?(Scene_AdultContentWarning) and !SceneManager.scene_is?(Scene_Title) and !SceneManager.scene_is?(Scene_TitleOptions) and !SceneManager.scene_is?(Scene_TitleOptInputMenu) and !SceneManager.scene_is?(Scene_ACHlistMenu) and !SceneManager.scene_is?(Scene_Credits) and !SceneManager.scene_is?(Scene_Load) and $loading_screen.disposed?)
  end
end

Alright dude all that you need to do is just go to \LonaRpg\ModScripts_Mods\Cheat-Menu-Framework\Framework\scripts Delete all code that he had and paste
I trough that will help to you
##---------------------------------------------------------------------------
## CheatUtils Module
##---------------------------------------------------------------------------
module CheatUtils
  #Check if a game is loaded
  def self.ingame?
    return (!SceneManager.scene_is?(Scene_MapTitle) and !SceneManager.scene_is?(Scene_AdultContentWarning) and !SceneManager.scene_is?(Scene_Title) and !SceneManager.scene_is?(Scene_TitleOptions) and !SceneManager.scene_is?(Scene_TitleOptInputMenu) and !SceneManager.scene_is?(Scene_ACHlistMenu) and !SceneManager.scene_is?(Scene_Credits) and !SceneManager.scene_is?(Scene_Load) and $loading_screen.disposed?)
  end
end

That's wrong. That would allow the menu to work during the first time setup which is a really bad idea as the language has not been set yet.
Also, I would hope that path is not how you have the mod installed because even with UMM it would not work. The mod should NEVER be installed by cloning the repo into a local repo in the _Mods folder as the file/folder structure is for feature separation during development (and no longer has the translations in this repo)
Only use the downloads attached to the releases.
The correct code change for older game versions is on the F95 post for the mod in the compatibility section.


Add TimeInput component

Select a day first and then see it in action!
Checklist:

[x] Test added / Snapshots updated
[x] Documentation added / updated

Wonderful stuff....
I guess it would be a feature request to use the
<input type="time" step="1500" /> <!-- 15 minutes -->
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/time on mobile / android only? :)

@fivenp I started trying to use <input type="time" /> on mobile iOS but this introduces more problems which would take some time to solve. So I would suggest moving on with it and try to improve after we've merged it.

...introduces more problems

absolutely true... stepping + max + min is not even supported.... :(


[html] Allow to ignoring base href [feature request]

VSCode Version: Code 1.16.1 (27492b6bf3acb0775d82d2f87b25a93490673c6d, 2017-09-14T16:24:39.530Z)
OS Version: Darwin x64 16.7.0

I'd like to disable the integration for <base href="/some-path/">.
Right now the editor 'thinks' it should 'link' paths and prepend it with the base href, but this is only applicable when the application is deployed, since then it's running on a sub-directory.
How to reproduce:

Create two files: index.html and script.js in the same directory
Add ` to the index.html
Add ` to the index.html
Try to cmd + click or ctrl + click on the script.js

Expected
Navigate to ./script.js
Actual
Navigation blocked:
Unable to open 'script.js': File not found (/Users/....../some-path/script.js).

Tricky problem, as it's a general problem that the file structure while development and deployment can differ, especially with scripts.


Add support for node_selector input

Summary
Customer has K8s clusters with mixed nodes (Linux, Windows). When they deploy the daemonset, it is constantly attempting to deploy the agent to the Windows nodes. They need the ability to specify which nodes to deploy the DaemonSet agent to (at least until the Windows agent can be deployed to K8s). Using the node_selector input, the customer can specify which nodes to deploy to based on the labels on the node.
How did you test this change?
Using an EKS cluster with two nodes of different instance types (t3.medium and t3.large), I was able to deploy the Daemonset to only the node I wanted using the node_selector input for the module. Tests run:

First test was to the t3.medium node: node_selector = {"node.kubernetes.io/instance-type":"t3.medium"}. Confirmed the agent was only deployed to the t3.medium node.
Second test was to the t3.large node: node_selector = {"node.kubernetes.io/instance-type":"t3.large"}. Confirmed the agent was only deployed to the t3.large node.
Third test was to deploy to all nodes by removing node_selector input. Confirmed the agent was deployed to both nodes.

Issue
https://lacework.atlassian.net/browse/ALLY-1063

make it so

make it so


feat(tracer): expose bind method from scope manager

As discussed in #161, we need the tracer to expose the bind method from the scope manager to allow plugins to use it.
see https://github.com/open-telemetry/opentelemetry-js/pull/161#discussion_r311027170
I've also updated getCurrentSpan on the basic tracer to actually return a NoopSpan when no span is set in the current scope (otherwise we will have some crash if the context is loss).

Codecov Report

Merging #201 into master will decrease coverage by 1.01%.
The diff coverage is 70.58%.

@@            Coverage Diff             @@
##           master     #201      +/-   ##
==========================================
- Coverage   94.07%   93.06%   -1.02%
==========================================
  Files          47       47
  Lines        1603     1513      -90
  Branches      100      101       +1
==========================================
- Hits         1508     1408     -100
- Misses         95      105      +10

Impacted Files
Coverage Δ

...entelemetry-core/test/trace/TracerDelegate.test.ts
100% <ø> (ø)
:arrow_up:

.../opentelemetry-node-tracer/test/NodeTracer.test.ts
0% <0%> (ø)
:arrow_up:

...s/opentelemetry-core/test/trace/NoopTracer.test.ts
100% <100%> (ø)
:arrow_up:

...pentelemetry-basic-tracer/test/BasicTracer.test.ts
100% <100%> (ø)
:arrow_up:

...ges/opentelemetry-core/src/trace/TracerDelegate.ts
100% <100%> (ø)
:arrow_up:

...ackages/opentelemetry-core/src/trace/NoopTracer.ts
100% <100%> (ø)
:arrow_up:

...ages/opentelemetry-basic-tracer/src/BasicTracer.ts
94.23% <83.33%> (-1.52%)
:arrow_down:

...kages/opentelemetry-basic-tracer/test/Span.test.ts
100% <0%> (ø)
:arrow_up:

...pe-async-hooks/test/AsyncHooksScopeManager.test.ts
100% <0%> (ø)
:arrow_up:

The loss in coverage is normal, the BasicTracer should handle the fact that the scope manager can return null and return NoopSpan in this case.
It's only using the AsyncHooksScopeManager that we can cover the other branch where the span returned is not null.
However i wonder if returning an invalid span is a good idea here. Valid span can be created from an invalid one i think, which i pretty sure is a bad idea.

Following discussion in today SIG (14/08/2019), getCurrentSpan should return null to avoid confusiong between NoopSpan (if no span is found in context) or a real Span. Updating my PR to reflect this behavior.


Visibility of the generated "Value" and "Partial" class ?

Hi,
Is there a way to change the visibility of the generated class (Value and Partial), via the annotations or something else?
Thanks,
Regards

Not currently. What is the use case?

Hi @chrisalice,
I would like to use it in Android DialogFragment (support package version).
When running it, I got kind of this error:
java.lang.IllegalStateException: MyClass.Value must be a public static class to be properly recreated from instance state.
An example of error + stacktrace can be found here (not me, not with FreeBuilder, but the problem is the same): https://stackoverflow.com/questions/39295458/fragment-must-be-a-public-static-class-to-be-properly-recreated-from-instance-st

Are you sure just making the class public would be sufficient? I suspect the Builder-accepting constructor would be problematic too.
Suggestions:

Copy the java file generated by FreeBuilder to your sources and try changing the visibility by hand, to see if that actually fixes the issue. You may find it just uncovers other problems.
Are you annotating your DialogFragment subclass with FreeBuilder? If so, does it work if you move your getters into a stand-alone data class, and store that in your DialogFragment?

Hi @chrisalice,
Sorry for the delay; in the meantime I managed my problem without FreeBuilder.

I will test it and come back to you (I think it might work)
Yes, my subclass was annotated with @FreeBuilder; I got kind of error linked previously. But I will try what you suggest too.

Regards

Closing since I've not heard back from you @Gounlaf, please do reopen if you have any updates


Adding ability to allow for data to be locally persisted.

Note that source is imported in PipelineRunner and LocalGitRunner.
This allows us to specify a filename with a source (e.g. LocalGitRunner-Blink-journal.js) without explicitly setting the filename for each class that is instantiated in the pipeline.
If no source is present, then the name simply becomes <classname>-journal.js (useful for DiffRunner since there is no specific source the journal belongs to)

Codecov Report

Merging #85 into master will increase coverage by 0.03%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master      #85      +/-   ##
==========================================
+ Coverage   95.12%   95.15%   +0.03%
==========================================
  Files         101      102       +1
  Lines         902      909       +7
==========================================
+ Hits          858      865       +7
  Misses         44       44

Impacted Files
Coverage Δ

config/files.js
100% <ø> (ø)
:arrow_up:

lib/org/chromium/webidl/PipelineRunner.js
92.3% <100%> (+0.64%)
:arrow_up:

lib/org/chromium/webidl/JournalingContainer.js
100% <100%> (ø)

lib/org/chromium/webidl/LocalGitRunner.js
77.19% <100%> (+0.4%)
:arrow_up:

Continue to review full report at Codecov.

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


Improve coin selection

According to this issue, I'm thinking of breaking down current coin selection into these steps:
Select Native Assets

Regarding the total output amount, sort the UTxOs deterministically. The priority order in the CIP issue does not look good to me. The sets 1/2/3 should be able to be quantified. And the euclidean distance described in this issue seems better.
Transaction builder takes the first N UTxOs out to satisfy the assets amount needed by outputs. These UTxOs should be fixed.

Random Improvement

Subtract the total ADA of outputs from total inputs. If the inputs are enough, ignore the following steps.
Randomly improves the left ADA with the left UTxOs only holds ADA. If all of the remaining UTxOs contains assets, ignore.
Optionally, if random improvement failed, fallback to Largest First.

The sorting and sampling logic can be implemented out of transaction builder, or maybe a separate crate if it can be shared with other projects. Builder can optionally implement a method to take the first N UTxOs to match the native assets of outputs and a method to check if a UTxO can improve. The sorting logic can be implemented by Typescript on the user side as well.
After #57 is merged I can work on this.

Note that the idea is not finalized.

Sometimes I wonder why a random algorithm is needed if there can be a sorting algorithm can work properly. The transaction just need to fetch the UTxOs from the start until the inputs can cover the total output. It is not only easier to implement but also easier to test.

I extract the selection logic which could be used across different UTxO cryptocurrencies into a crate. I just need to implement Select trait in this package. https://github.com/siegfried/utxo/blob/master/src/lib.rs
As @rooooooooob said you want to separate the libraries into a pure Rust one and a WASM one, so I think this is the right direction.

Or I could implement the selection in a different package for WASM.

I ended up moving UTxO selection out of TransactionBuilder. https://github.com/siegfried/utxo

The simulation plan is to send NFTs and FTs and Ada in an out of a wallet for a large number of transactions -> say 100 000 tx. Those inputs and outputs should be statistically generated to include all kinds of transactions. Then, after 100 000 tx, you measure the state of the wallet by looking into its UTxO distribution.
Do you have super large UTxOs with 20+, or 50+ tokens?
Do you have 1000s of Dust transactions?
Do you have a good balance between large Ada amounts and smaller Ada amounts (to allow for big payment AND independent transactions)?
etc.

In a nutshell : selecting randomly from those has aggregation properties that will naturally clean up your dust (very small Ada tx). Largest first prevents that random tidying up of small txs.

Then it is no longer necessary because:

Dust cannot be produced due to coinsPerUTxOWord;
There is no good reason to force the users spending real dust which costs more than its value. Even if there is, those can be added to a result of Largest First algorithm deliberately and optionally.


Only one server, "https://webdir1e.online.lync.com/" is correctly responding to oAuth flows.

Hi,
I have no problems getting into oAuth flow authentication regarding Skype SignIn when my home pool server is "https://webdir1e.online.lync.com/". All others - https://webdir2e.online.lync.com/, https://webdir0e.online.lync.com/, https://webdir0e.online.lync.com/, etc... - are returning 403 with "reason="Service does not allow a cross domain request from this origin."
The interactive web sdk page suffers from the same problem:
https://ucwa.skype.com/websdk
After choosing "Azure AD" authentication and filling my "Cliend ID" and including "https://ucwa.skype.com/websdk" in my App's Reply Url's, the demo only loads correctly if the home pool server is "https://webdir1e.online.lync.com/". For others, it keeps waiting forever.
This was working last week, any clue to what is happening?
Thanks in advance,
Nuno

Can confirm, having the exact same issue.

Can anyone help? @ajkher ? This is really starting to affect us...

This is also affecting us. Can we please have some indication as to when the problem might be resolved.

I debugged on Office 365 site and found a new URL to Auth: https://webpoolme1au103.infra.lync.com/Autodiscover/AutodiscoverService.svc/root
u replace this url to "origins" param when signin to skype:
  testForConfigAndSignIn({                 "client_id": "xxxxx-xxxx-xxxx-xxx-xxxx",                 "origins": ["https://webdir0f.online.lync.com/Autodiscover/AutodiscoverService.svc/root"],                 "cors": true,                 "version": 'myapp/1.0.0'             });

I'm on Skype Online, so if i substitute the normal "https://webdir.online.lync.com/autodiscover/autodiscoverservice.svc/root" by the only server that's working "https://webdir1e.online.lync.com/Autodiscover/AutodiscoverService.svc/root" then it works. This "origins" parameter shouldn't be messed with in what concerns Skype Online:
This is quoted from "https://msdn.microsoft.com/en-us/skype/websdk/docs/developwebsdkappsforsfbonline":
The following example shows the parameters that are required when signing in to Skype for Business Online.
Set the client_id parameter to the one that was auto generated for you in your Azure AD application.
Do not change the origins parameter.
cors must be set to true. Without this being true you will encounter 403 errors like service does not allow cross domain requests from this origin when trying to perform auto discovery.
The redirect_uri parameter value in this sample is the URL of an empty html page in a folder below the web app folder. You can use any name for the folder and the file.
Provide an applicationame and version for your application.
app.signInManager.signIn({
"client_id": "...",  // GUID obtained from Azure app registration.
"origins": [ "https://webdir.online.lync.com/autodiscover/autodiscoverservice.svc/root" ],
"cors": true,
"redirect_uri": '/an/empty/page.html',
"version": '/<IP_ADDRESS>'
});
But i guess i'll stick with it for the moment.

Behavior is a little erratic though, sometimes the SDK enters in a loop trying to get, in my case, "https://webpooldb41e03.infra.lync.com/ucwa/oauth/v1/applications" saying "Application not found", several times, but not always. The service seems definitely unstable.

For me it is not working in https://webdir.online.lync.com/autodiscover/autodiscoverservice.svc/root either.

That's weird.  We tend to usually be webdir1b.online.lync.com, and haven't had any issues for the last couple of weeks.


'dialog' selector

Hello again,
I'm wondering if this is using the '.dialog' selector for the aem components.
I had an issue after installing SP1/SP2 in my AEM 6.1 servers. The React components disappears after editing (to be exact, their content disappears).  This issue happen on the TouchUI edit window (editor.html). BTW, we're using aem-react-0.4.0.
For example, I have a React text component. During editing, the editor calls the resource again with the '.dialog' selector to rerender the content. In plain AEM 6.1 server, there is no 'dialog' selector being included, which works fine.
Sample url being called after edit is
http://localhost:4502/content/test/home/jcr:content/structure/par/text_component.html?forceeditcontext=true&_=1489148319496 and
http://localhost:4502/content/test/home/jcr:content/structure/par/text_component.dialog.html?forceeditcontext=true&_=1489148319496

Rendered properly with .dialog selector

Sample text.

<textarea id="/content/test/home/jcr:content/structure/par/text_component" style="display:none;">{"cache":... other contents...}</textarea>
<cq data-path="/content/test/home/jcr:content/structure/par/text_component" data-config="{...}"></cq>

This is the source output with the 'dialog' selector

<cq data-path="/content/test/home/jcr:content/structure/par/text_component" data-config="{....}"></cq>

Which version of aem-react are you using? Can you seems them if you append ?wcmmode=disabled to the url? To debug the situation in the browser add the following parameters ?wcmmode=disabled& serverRendering=disabled.
Need more info.

@stemey updated the info now. with some code snippets. this issue has been bugging me after I updated to the SP1/2 packages.

The react components issue the .dialog call. But in the authorMode they should not even be instantiated in the client. So that seems to be the problem.  The check which prevents instantiation is here:
https://github.com/sinnerschrader/aem-react-js/blob/master/ComponentManager.tsx#L44
Try to debug this and see why it is not working as expected, please.

My last assessment was probably not correct. the dialog call was issued by AEM javascript as far as I understand. I don't know why, though. Is it a coincidence that aem-react uses that selector for rendering the wrapper element? Or is it a result? I don't know. Is this dialog selector also being used for normal sightly components when updating them? If so then it is a coincidence and we need to use a more specific selector or make it configurable.

Hmmm.. At first I thought it was AEM calling it, but it seems unlikely. I tested my other applications (both JSP and sightly components) on SP1/SP2, and the 'dialog' selector isn't being included.

I currently at a loss why this is happening. The dialog selector is used in the server to get the wrapper element of a react component. The client does not use it.
Can you try an xhr break point to pin down the code that issues the call?
Also post the rendered html of the component. It might be something special about the extra elements generated by AEM to provide the author mode ui.

Stuck here. Can you point where does the <cq data-config="{...}"> gets generated? It has different contents after SP1 update. One thing is that with SP1/2, it contains an additional property called slingPath (this contains the url with 'dialog' selector). This might lead to a clue.

I understand the problem now. I will look into a fix. Here are the two pieces of code that need to be changed:
https://github.com/sinnerschrader/aem-react/blob/master/core/src/main/java/com/sinnerschrader/aem/react/ReactScriptEngine.java#L90
https://github.com/sinnerschrader/aem-react/blob/master/core/src/main/java/com/sinnerschrader/aem/react/api/Sling.java#L263
I will look into a different mechanism to render the wrapper element only.

please if the pull request fixes your problem.

Thanks! the fix works.

to get the wrapper element from AEM a request is dispatched to the component. In this request only the wrapper is rendered and the ReactScriptEngine renders nothing. To distinguish these two cases we used a dialog selector before and now we just set a request attribute. The request attribute is set to its old value in the above code snippet. That's it.


Randomize colour of hearts for Valentines reactions

Description
I'd like to propose that the heart emoticon currently used for Valentines be expanded to include the many other colourful hearts available.
Reasoning
Fun and a thrilling sense of risk; never knowing which heart will be used.
Proposed Implementation
It looks like the random selection of an emoticon is already implemented in the logic. This change would include simply adding the additional choices to the list.
https://github.com/python-discord/sir-lancebot/blob/1b09322f8be46530e01ffb6f5a80c14e786c5411/bot/exts/holidays/holidayreact.py#L31-L34
heart_emoticons = (
    "\ud83d\udc9c",  # purple_heart
    "\ud83d\udc9f",  # heart_decoration
    "\u2665\ufe0f",  # hearts
    "\ud83d\udda4",  # black_heart
    "\ud83d\udc99",  # blue_heart
    "\ud83e\udd0e",  # brown_heart
    "\ud83d\udc9d",  # gift_heart
    "\ud83d\udc9a",  # green_heart
    "\ud83e\ude76",  # grey_heart
    "\ud83e\ude75",  # light_blue_heart
    "\ud83e\udde1",  # orange_heart
    "\ud83e\ude77",  # yellow_heart
    "\ud83d\udc9e",  # revolving_hearts
    "\ud83d\udc96",  # sparkling_heart
    "\ud83e\udd0d",  # white_heart
    "\ud83d\udc9b",  # yellow_heart
    "\u2764\ufe0f",  # heart
    "\ud83d\udc97",  # heartpulse
)

Additional Details
Given the standard Discord client has two primary themes, dark and light, it should be considered if any exclusions are needed. This is a visual of the hearts on the two primary themes. I did a brief preview of Nitro themes which do not appear to change the contrast dramatically on comparison to the base themes.

Would you like to implement this yourself?

[x] I'd like to implement this feature myself
[ ] Anyone can implement this feature

Sounds good to me!


01-prepare-data-with-power-query-in-power-bi-desktop.md

English:
In the File Name box, enter Sales Analysis.
Current Translation:
在 [檔案名稱] 方塊中，輸入銷售分析
Suggested Translation:
在 [檔案名稱] 方塊中，輸入 Sales Analysis
Description:
It is file name and should keep English

Hello contributor,
Thank you for your contribution! We are processing your suggestions and we will update you shortly.
Kind regards,
Microsoft Worldwide Learning Team

Run bugfix tool and waiting for result.


Support WordPress 6.5

WordPress 6.5 released and rectorphp 1.0 released.

Hi @palpalani I've just tagged 0.3.0 which should includes support for WordPress 6.5 and Rector 1.0.


fix issue #82

The push includes:
/dlpy/applications.py: Change YoloV2_MultiSize model name to Yolov2_MultiSize.  Previously the model name conficted with YoloV2's.
/dlpy/tests/datasources/dlpy_obj_det_test/ : data files that test issue #82
/dlpy/tests/test_utils.py: modifed the two testcases to cover #82
/dlpy/utils.py: correct the way to find filename without extension.
All test are passed on Windows and Linux client.

@wenyushi Thanks. I think this push also fixes #83 , right?

Yes.