Working impl of HK2 dependency injection

Description
As discussed in the mailing list, this change proposes using the HK2 framework to support CDI-compliant dependency injection using the existing Dropwizard application structure and yaml configuration. This change does not make a logic changes or signature changes except to remove some of the injection-oriented interfaces (e.g., ConfigurationStoreAware) and updates constructors to accept dependencies via @Inject annotations.
The PolarisApplicationConfig is configured to be managed by HK2, but populated by the Jackson during the typical Dropwizard configuration parsing. Because the PolarisApplicationConfig is managed by HK2, it can invoke a @PostConstruct method that registers configured beans with the serviceLocator using the config class's own getter methods as Factory implementations. Because the other beans are not managed by HK2 (they can't be, since they declare dependencies on other beans that may not yet be instantiated by Jackson), the factory manually calls inject on each bean before returning.
Jersey has its own serviceLocator instance under the hood, so all of the beans bound to the PolarisApplicationConfig instance are registered again with the Jersey serviceLocator so that they can be found by the jersey components at runtime (I tried using the HK2 bridge that supposedly allows connecting two serviceLocators, but it didn't seem to work and also the licensing on that package suggests possible GPL violation).
This also introduces a @RealmScope that declares certain dependencies to be created and managed per-realm, rather than per-application or per-request. Some of the instances, such as the PolarisMetaStoreManager and the EntityCache are intended to be reused across requests, but of course, cannot be reused across realms, as some entities (such as root principal and service_admin principal role) have the same name across realms.
One additional test class is added to ensure that the @RealmScoped EntityCache is reused across requests, but is not reused across different realms.
Fixes # (issue)
Type of change
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] Documentation update
[X] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[ ] PolarisRealmEntityCacheTest

Test Configuration:

Hardware:
Toolchain:
SDK:

Checklist:
Please delete options that are not relevant.

[X] I have performed a self-review of my code
[X] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] If adding new functionality, I have discussed my implementation with the community using the linked GitHub issue

Hm, looking into the hk2 github repo it looks like its rather unmaintained (minus version bumps and rather tiny changes).

I'd also be willing to work on extracting services (generated API code + impl. classes) into a dedicated gradle module (to be pulled into DW runtime), unless you want to work on this from your side @collado-mike :)

I'd also be willing to work on extracting services (generated API code + impl. classes) into a dedicated gradle module (to be pulled into DW runtime), unless you want to work on this from your side @collado-mike :)

That sounds good to me! I have other things to work on :)

I agree that @Named has some shortcomings.
One of them is that the name is application-wide, so you cannot have two beans named @Named("default").

@adutra I haven't seen this behavior during testing. E.g., the DefaultOAuth2ApiService and the DefaultContextResolver are both named "default", but the application doesn't seem to have any problem starting up both instances. Could it be that we never use @Named as a qualifier at the injection point? From the article you shared, it seems like the issue is one of ambiguity at injection time if the qualifiers aren't specific. But the goal of the @Named annotation in this PR is to allow named instances to be specified in the configuration. We never use the @Named qualifier at the injection points (and I don't think we should, as it defeats the purpose of the user configuration).

@adutra I haven't seen this behavior during testing. E.g., the DefaultOAuth2ApiService and the DefaultContextResolver are both named "default", but the application doesn't seem to have any problem starting up both instances.

I suspect HK2 might not be fully compliant with the spec. From CDI spec 4.0:

An ambiguous name exists when a name resolves to multiple beans. When an ambiguous name exists, the container attempts to resolve the ambiguity.

So in our case, if both DefaultOAuth2ApiService and DefaultContextResolver are named default, and are both eligible for injection, then that should result in an unresolvable ambiguous bean situation.
For example with Quarkus, if I declare the following beans:
@Singleton @Named("foo")
public class Foo1 {}

@Singleton @Named("foo")
public class Foo2 {}

I get a deployment error when the app starts (even if the beans aren't injected anywhere):
java.lang.RuntimeException: io.quarkus.builder.BuildException: Build failure: Build failed due to errors
	[error]: Build step io.quarkus.arc.deployment.ArcProcessor#generateResources threw an exception: jakarta.enterprise.inject.spi.DeploymentException: Unresolvable ambiguous bean name detected: foo
Beans:
CLASS bean [types=[org.apache.polaris.service.catalog.Foo1, java.lang.Object], qualifiers=[@Default, @Any, @Named("foo")], target=org.apache.polaris.service.catalog.Foo1]
CLASS bean [types=[org.apache.polaris.service.catalog.Foo2, java.lang.Object], qualifiers=[@Default, @Any, @Named("foo")], target=org.apache.polaris.service.catalog.Foo2]

To get past this issue, I would suggest that we copy SmallRye's @Identifier into our code base.

To get past this issue, I would suggest that we copy SmallRye's @Identifier into our code base – if it's possible for HK2 to process custom qualifiers.

Yeah, it's possible to use the custom qualifiers. I think it's fine to switch the annotations - but copying the @Identifier code will make the classes that use it incompatible with the Quarkus work, right? I think it would be fine to just add a dependency on the SmallRye library for the annotation, as that moves the codebase into a more compatible state. WDYT?

Yeah, it's possible to use the custom qualifiers. I think it's fine to switch the annotations - but copying the @Identifier code will make the classes that use it incompatible with the Quarkus work, right? I think it would be fine to just add a dependency on the SmallRye library for the annotation, as that moves the codebase into a more compatible state. WDYT?

Copying wouldn't break Quarkus afaict, it's just a matter of telling it which identifier we intend use. That said, if you are OK adding the dependency, that's even better 👍

@adutra , I think I've addressed all of your comments. The one outstanding concern is the support for the @RealmScoped annotation. I think we should discuss the feasibility of supporting that in Quarkus in the Quarkus PR. Its use and the context to support it are framework-dependent anyway, so I think we can evaluate the feasibility of it specifically in Quarkus separately from this PR.
In the meantime, however, I think the basic CDI support is blocking work on several other tasks (e.g., the authentication/authorization PRs Dmitri and I have open, fixing the bootstrapping, table metadata logging). With this PR, I think we can work on better/more complete CDI support (e.g., through Quarkus) without any significant changes to the work done here and it can also accommodate the other work that's ongoing.

@adutra , I'll need another approval because I had to merge from main to resolve conflicts 🙄


disabling KDE Wallet (via KDE Settings) causes Chromium/Electron Apps to freeze/crash

Describe the bug
after a recent system update, I've noticed vscode and discord freezing for several seconds on startup (and even crashing when clicking on the frozen window)
my config for reference: https://github.com/GsakuL/mynix
Steps To Reproduce
Steps to reproduce the behavior:

enable KDE5 (wayland(?))
install vscode/vscodium, discord, chromium,...
go to KDE Settings (systemsettings5)  -> "KDE Wallet" -> "Wallet Preferences" Tab -> untick/disable "Enable the KDE wallet subsystem"
reboot/restart session
try to open vscode, discord....

Expected behavior
apps not freezing
Screenshots

Additional context
discord.log
code.log
code.log is very verbose!
what told me that it was kde wallet are these lines:
[154886:0612/191803.045185:ERROR:object_proxy.cc(577)] Failed to call method: org.kde.KWallet.isEnabled: object_path= /modules/kwalletd5: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
[154886:0612/191803.045201:ERROR:kwallet_dbus.cc(112)] Error contacting kwalletd5 (isEnabled)
[154886:0612/191803.047964:ERROR:object_proxy.cc(577)] Failed to call method: org.kde.KLauncher.start_service_by_desktop_name: object_path= /KLauncher: org.freedesktop.DBus.Error.ServiceUnknown: The name org.kde.klauncher was not provided by any .service files
[154886:0612/191803.047976:ERROR:kwallet_dbus.cc(81)] Error contacting klauncher to start kwalletd5
[154886:0612/191828.073207:ERROR:object_proxy.cc(577)] Failed to call method: org.kde.KWallet.close: object_path= /modules/kwalletd5: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
[154886:0612/191828.073228:ERROR:kwallet_dbus.cc(503)] Error contacting kwalletd5 (close)

"As a user", since I'm not using kwallet, I wouldn't even install it, but since it's in the list of requiredPackages, it will be installed. And since it would open popups on every app start, I disabled it.
I have found a workaround using --password-store=basic as a chromium argument in an overlay wrapper, but this seems more of a hack than a clean solution.
Also I don't want to enable an empty wallet, just to ""fix"" this. (yes I know, setting the same password on the wallet auto-opens it), since after all "don't need => disable"
I'm unsure if this is a upstream issue. However the logs "indicate" that kwallet is "registered but not running" (to express it in my layman's terms), which could be a "service configuration issue".
not sure if relevant, but ~/.config/kwalletrc
[Wallet]
Close When Idle=true
Close on Screensaver=true
Enabled=false
First Use=false
Idle Timeout=1
Launch Manager=false
Leave Manager Open=false
Leave Open=false
Prompt on Open=false
Use One Wallet=true

[org.freedesktop.secrets]
apiEnabled=false

Notify maintainers
(no maintainers listed)
@K900 because creating/touching https://github.com/NixOS/nixpkgs/blob/master/pkgs/kde/frameworks/kwallet/default.nix
@SuperSandro2000 because touching https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/x11/desktop-managers/plasma5.nix
Metadata
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.6.32, NixOS, 24.11 (Vicuña), 24.11.20240607.051f920`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.2`
 - nixpkgs: `/nix/store/3dr5pyja36lvvrszhzffww1jwyrx6i09-source`

Add a :+1: reaction to issues you find important.

Is this still an issue with Plasma 6?

i removed my wrappers, and swapped from services.xserver.desktopManager.plasma5.enable = true; to services.desktopManager.plasma6.enable = true;. rebuild boot, and rebooted into the new Config "just to be sure".
Apparently vscode, discord and (ungoogled-)chromium do not freeze under Plasma 6. log still shows the errors, but it did not freeze like before (and if it did, it was "non-noticeable")
discord.log
code3.log
At the end, I don't care if that gets logged but is this considered "ok"/"intended behavior" (still showing error)?

I could think that Electron just assumes that kwallet is enabled and waits for it. Not sure if electron has some arguments to disable it. I think Chromium has some, to enable support.
The easiest fix would be to just keep it enabled.
Plasma 5 is kinda on our EOL list and doesn't get so much love anymore.


Can't install safety for python2 and python3 properly.

safety version: 0.2.2
Python version: 2.7.12 and 3.5.1
Operating System: Fedora 24

Description
Installing safety not in a venv, but on the system for both python2 and python3 results in the /usr/bin/safety file to be overwritten
What I did
pip install safety
pip3 install safety

The hashbang contains the python version for which safety was last installed.

I don't know if there's a way around this. Do you have any information about what /usr/bin/safety does in fedora?

I've just installed safety in a fresh Fedora 24 VM and couldn't reproduce the problem.

I wasn't able to reproduce this.


can i use different limits and requests in mysql cluster?

I have a MySQL cluster, but I would not like to allocate all the resources that could be used at some point, I would like to place a request of approximately 25% of the CPU and RAM usage limit.
I know from the UI that it does not exist. Would it be possible to edit a manifest or configuration to manually set the requests?
Thank you

Hi @gitbarnabedikartola, as you correctly identified we set the same value for the resources' limits and requests. This was a deliberate decision to ensure the stability of the DB deployments.
Currently, you can't change it. If you try to edit the manifests directly the everest operator will reconcile it and overwrite the values you set.
We could expose both values in our API but users would need to be very careful in setting these values as it could lead to random DB nodes being terminated.

Hi @recharte, yes I tried changing the values in many places, the operator always reconciles.
As a Linux developer, I understand that this is the best choice to ensure stability for users with less knowledge, one idea would be to have an advanced field with a warning that the change may cause instability and/or crash.
Is there any way to change these values manually after the CRD has been created?
Thanks.

Is there any way to change these values manually after the CRD has been created?

Unfortunately, no. As long as the everest operator is running, it will consider any such change as a drift from the intended spec and it will reconcile everything back to the initial state (request = limits).
We can add this feature request to our roadmap (cc. @PeterSzcz). However, I think that this won't be considered a high priority feature at this moment so it can take us a few months to get it released.

It would be great to know where to change this I also have this problem @recharte


Add DaemonSet e2e test

Ⅰ. Description
Add DaemonSet e2e tests including 3 cases:

Normal rollout update:
"DaemonSet V1->V2: 1,100% Succeeded"

v1 -> v2(interrupt) -> v3
"V1->V2: Percentage, 1, 2 and continuous release v3"

delete rollout during the process
"V1->V2: 1,100%, but delete rollout crd"

Ⅱ. Test Process

Set up basic environment according to this md:
https://github.com/openkruise/rollouts/blob/master/docs/contributing/debug.md

run kubectl apply -f rollout_canary_daemonset_base.yaml, and rollout_canary_daemonset_base.yaml is under the path:
test/e2e/test_data/rollout/rollout_canary_daemonset_base.yaml

run kubectl apply -f rollout_canary_daemonset_interrupt.yaml, and rollout_canary_daemonset_interrupt.yaml is under the path:
test/e2e/test_data/rollout/rollout_canary_daemonset_interrupt.yaml

run ginkgo -timeout 60m -v --focus="DaemonSet canary rollout" test/e2e under rollouts package.

Ⅲ. Test Result
All three cases passed
1)

2)

3)

/lgtm

/approve


Fixes/1953/chained method continuation

Description
Add ChainMethodContinuation(chain-method-continuation) rule
This rule ensures chain operators(. or ?.) aligns with next call
When there is } in the new line this also ensures that the chain operators align with } along with the next call method
This partially fixes https://github.com/pinterest/ktlint/issues/1953
Checklist

[x] PR description added
[x] tests are added
[x] KtLint has been applied on source code itself and violations are fixed
[x] documentation is updated
[x] CHANGELOG.md is updated

In case of adding a new rule:

[x] Rule is added to rules documentation

Formatting code below:
val bar =
    listOf(1, 2, 3). // xxx
        map {
            it * it
        }

results in code which can not be compiled:
val bar =
    listOf(1, 2, 3)
        .// xxxmap {
            it * it
        }

Formatting code below:
val bar =
    listOf(1, 2, 3). // xxx
        map {
            it * it
        }

results in code which can not be compiled:
val bar =
    listOf(1, 2, 3)
        .// xxxmap {
            it * it
        }


Support for DPCF

Good question about the material version. I think old materials should work as long as the new feature is not used. Right?


I FORGOT THIS EXPANDED THIS PULL REQUEST TOO

Alright, so long as this is working in your copy, approved.


flake: use makeWrapper to add cardano-cli/-node to PATH

The need to manually ensure that the proper cardano-cli and cardano-node executables are available in the PATH variable is not a very nixy approach. Threfore I've introduced makeWrapper to ensure that the proper executables are in the environment.
I did that for local-cluster and plutip-tests both run successfully now. Please let me know what other executables require to have cardano-cli and cardano-node in the PATH
Editing this flake I also found it very difficult to edit the cabalProject function parameters like modules. Wrapping cabalProject inside another function is a huge anti-pattern in my opinion. As soon as there are more options required you will basically find yourself writing an additional parameter for nix/haskell.nix just to propagate it to cabalProject

Well the readme says that you need to make sure that cardano-node and  cardano-cli are present in the environment.
see readme
Moreover when I run the following (master branch)
nix run .#"plutip:exe:local-cluster"

using the code from master i get
This processes should be available in the environment:
 ["cardano-node","cardano-cli"]
 but only these were found:
 []
local-cluster: ExitFailure 1

And to be honest there is a lot that can go wrong when requiring a user to take care of having the proper executable versions in the environment.

Tested, works. Please fix the PR (remove makeWrapper for plutip-tests if not needed) and update readme.

@brainrake I've reverted the usage of makeWrapper for plutip-tests. And I've updated the wording. Users of plutip will still need to make sure that cardano-cli and cardano-node are present if they are depending on the library for their own tests.
Please tell me if that wording is ok.

LGTM on my side. Thank you again for your contribution, as well as updates!
@mikekeke please merge

@marijanp
Thank you a lot for contribution!


[TASK] Ctrl + S saves the app state

Description
Add shortcut while in edit mode to save the app state.

Throw warning to user letting them to know to check there work before saving

Existing
N/A
Reference
N/A
Tasks

[x] Add shortcut to save app state
[ ] After save show notification to user of checking work

flow goes

ctrl +s **saves app
Notify user "You just saved your app, please ensure that the recent changes you made are accurate"

flow goes @SPRCoreDump

ctrl +s **saves app
Notify user "You just saved your app, please ensure that the recent changes you made are accurate", does not have to be word for word, just notify user that they should check their work.

Is there a specific style of notification that's preferred here? I'm assuming a toast or something at the top right with an X is ok since I've seen it elsewhere in the app

@SPRCoreDump if you look in the code, we have a hook that handles this for us.


Chgill-msft-udpate-best-practices-with-readme

Add README guidance to package authoring best practices.

Docs Build status updates of commit 426ec97:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/create-packages/Package-authoring-best-practices.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit 95f997d:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/create-packages/Package-authoring-best-practices.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Mesoscale Simulations in Library

This PR adds idealized mesoscale resolving zonally re-entrant channels to the library. The first stage is to define a function whose input is a few control parameters and whose output can be used for informing parameterization development. There are two main classes of simulations being added: flat bottom and hilly

Tentative to-do list

Surface Buoyancy Relaxation
Quadratic Drag
Check output in simple case

Do you mind if I commit to this PR?
TODO:

[ ] put eddying_channel_simulation into IdealizedExperiments, get rid of IdealizedMesoscaleExperiments
[ ] run the cases and report results in this PR
[ ] add a simple example analogous to https://github.com/CliMA/LESbrary.jl/blob/805c473b11f517a53e43f40b8c32d94988ecb73e/examples/run_three_layer_constant_fluxes.jl where we demonstrate how to use the function eddying_channel_simulation

A few results. I added biharmonic dissipation and removed the Laplacian diffusion, which wasn't having any effect (dissipation was dominated by WENO I guess). With a coefficient Δx^4 / 15days, we get smooth solutions after 1 year of simulation:

Constrast this with

a bit noisier.
With a biharmonic coefficient Δx^4 / 30days we suppress the growth rate of the baroclinic instability, so that after a year we are just about to go unstable:

Ok, I've also implemented an initial buoyancy distribution that matches the relaxation profile. Here's what we get after a year with Δx^4 / 15days

The simulations also complete faster because we don't get large vertical velocities early on, perhaps because the initial turbulent motions are a bit larger scale?

Note: we'll have to implement some tracer forcing (if we want to use it for training in the equilibrated solution. Something for the future.


Update example_pb.md

server ->> service

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

service 参数后面会下掉，使用 server_name 代替，可以升级到最新版 @ZKjaz


Add face ov

Docs Build status updates of commit e9b2b3b:
:x: Validation status: errors
Please follow instructions here which may help to resolve issue.

File
Status
Preview URL
Details

:x:Error

Details

[Error-PullRequestMergeConflict] Cannot sync git repo to specified state. Please make sure the pull request is mergeable.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit cf44cce:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs-ref-mapping/reference-unified.yml
:white_check_mark:Succeeded

docs-ref-mapping/reference-unified.yml.orig
:white_check_mark:Succeeded

docs-ref-services/cognitiveservices/face-readme.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

@danieljurek Please review this PR and merge if ready

Docs Build status updates of commit 3c4620b:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs-ref-mapping/reference-unified.yml
:white_check_mark:Succeeded

docs-ref-services/cognitiveservices/face-readme.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Thank you! Merging.


Refresh results when selecting a new sorting option

Thank you for your help :heart:
What is this project?
DAV (Decentralized Autonomous Vehicles) is a new non-profit foundation working to build an open-source infrastructure for autonomous vehicles (cars, drones, trucks, robots, and all the service providers around them) to communicate and transact with each other over blockchain.
As an organization that believes in building a large community of open-source contributors, we often create issues like this one to help people take their first few steps into the world of open source.
Missions
The DAV project you are looking at is Missions. Missions is the client facing side of the marketplace connecting DAV users looking to ship packages, with autonomous vehicles such as drones.
How you can help
The Issue
We recently upgraded the 'Bid Selection' screen (that appears when ordering a pickup) and added a feature that allows users to sort the results by price, time of arrival etc.
The problem is that when users select a new sorting option, since sometimes the results stay in the same order (which can happen and is ok), it may seem to the users that the sorting failed.

To avoid that, we want to always refresh the results - even in cases where results should stay in the same order. Refresh means clearing the results page and loading them again (or at least make it seem like that). Similar to when the results are being loaded for the first time.
Contributing to Missions

[ ] Make sure this issue is labeled up-for-grabs and not labeled claimed, to verify no one else is working on it.
[ ] Comment in this issue that you would like to do it.
[ ] Open the Missions GitHub page and click the ★ Star and then ⑂ Fork buttons.
[ ] Clone a copy to your local machine with $ git clone git@github.com:YOUR-GITHUB-USER-NAME/missions.git
[ ] Make changes in the LICENSE file
[ ] Once you've made sure all your changes work correctly and committed all your changes, push your local changes back to github with $ git push -u origin master
[ ] Visit your fork on GitHub.com (https://github.com/YOUR-USER-NAME/missions) and create a pull request for your changes.
[ ] Make sure your pull request describes exactly what you changed and references this issue (include the issue number in the title like this: #5)
[ ] Please do not fix more than one issue at a time. Your pull request should only fix what is described in this issue.

Asking for help
We appreciate your effort in taking the time to work on this issue and help out the open source community and the foundation. If you need any help, feel free to ask below or in our gitter channel. We are always happy to help 😄

I would like to try this!

Thank you @tjmabey 👍
Go for it.

Hi @tjmabey  - any estimation as to when you can get this issue fixed?

hey @srfrnk apologies for the delay. I want to have it done by this weekend. if not, then it can be reassigned. thanks!

Thanks @tjmabey - waiting for update!

this issue is marked as claimed. so can also contribute in this. i am a beginner searching where i can contribute.

I am closing this old issue for now.
If you're looking for other opportunities to contribute, we have many other open issues here: https://github.com/issues?utf8=✓&q=is%3Aopen+is%3Aissue+archived%3Afalse+label%3A"good+first+issue"+user%3ADAVFoundation+


Intent 6 analysis

Developer intents: Provisioning intents

Intent 6
5SED
5MEE
EXRA
EXRC
EXCA
EXSM
GMEC

6. "I can ask the operator to inform me if the optimal MEC for my application and a specific terminal changes, taking into account mobility events, connectivity, shortest network path, cost, network load, MEC platform load etc."
No
No
?
?
?
?
?

5MEE
Details
Comments

(to complete)
(to complete)
(to complete)

EXRC
Details
Comments

(to complete)
(to complete)
(to complete)

(to add EXRA, EXCA,  EXSM,  GMEC as appropriate)

Our platform does have a mechanism to exactly cater for that intent (Edge Events - see https://developers.edgexr.org/sdks/edge-events-overview/ for reference) but that is built as streaming API not as a REST API (and it's between app and operator platform, not between developer and operator platform) thus we haven't considered this yet for CAMARA. Therefore it will be a "No" for the EdgeXR contributions.

the version of the API spec contributed does not support user subscriptions and notifications but 5GFF has an updated API spec which supports this and the plan is to contribute it to CAMARA as a generic module which can be use across multiple APIs

Currently the Application management API submitted does not provide the capabilities to provide change of optimal MEC notifications to applications considering the various events in context of the UE e.g. mobility events, QoS deterioration, network congestion etc


Known limitation: Document the p99 service latency graph spikes on individual nodes due to backups

https://cockroachdb.zendesk.com/agent/tickets/7910
https://cockroachdb.zendesk.com/agent/tickets/7849
https://cockroachlabs.atlassian.net/browse/CC-3830
https://github.com/cockroachdb/cockroach/issues/42174
can we document this as a known issue in CC? or at least under backups in FAQ https://www.cockroachlabs.com/docs/cockroachcloud/frequently-asked-questions.html
cc: @dbist

Eng issue: https://github.com/cockroachdb/cockroach/issues/42174

We should add this to our overall known limitations page, but we need to look at the eng issue to get the framing right. See Ben's comment in there. It's about more than bulk io, though backups probably do need to be called out. @lnhsingh, I defer to you on whether you want to route this to bulk io or observability. In any case, we generally document all newly identified limitations a little closer to GA; it's part of our GA checklist: https://cockroachlabs.atlassian.net/wiki/spaces/PROD/pages/402718726/GA+Release+Checklist

We find prospects and customers comparing apples and oranges with this metric that don’t favor Cockroach sometimes.  We should unpack in our docs what’s included in the metric as it includes backup and GC activity which can show huge spikes here.  With a customer evaluation a few weeks ago, they were comparing this metric to their select, insert, delete and update p99 statements only from Postgres and we obviously didn’t look good until we up leveled it to the metrics produced at their app layer for comparison.  My real worry is on the prospects we’re not talking too.   We also had to remind them they’re paying a small latency up front for better HA/resilience which was another key reminder of why they were looking at Cockroach in the first place.

I think I'm going to kick this issue over to Observability (@taroface). Will update the Jira ticket too

The root issue here is resolved in https://github.com/cockroachdb/cockroach/commit/559f20545e3c7a9ebaead4e873c3f03f868de118. I believe we can close this docs issue.


[R5] Move/refactor Create Shopcarts API into ShopcartResource class

As a developer
I need to move/refactor Create Shopcarts API into ShopcartResource class
So that Create Shopcarts API swagger doc would be available on the /apidocs page
Details and Assumptions

https://github.com/nyu-devops/lab-flask-restplus-swagger/blob/master/service/routes.py#L129

Acceptance Criteria
TBA
Given [some context]
When [action taken]
Then [outcome observed]

Hey team! Please add your planning poker estimate with Zenhub @emhao @LillisLuo @nijya @wl2484


Node esm support

Description of the Change

This PR adds support for Node.js's native ESM (ES modules) support.
Specifically, up till now, Mocha could only load test files that were CommonJS,
and this PR enables it to load test files that are ES modules,
and thus enable the test files to import stuff from other ES modules
(not to mention other goodies coming up the line, like enabling top-level await, which is an ESM only JS feature).
Note that this support is for Node.js only, and has no connection to browser ESM support.
Also, prior to Node v12, there was no or quirky support for ESM, so this support is only for Node v12 and above.
Alternate Designs

This is not a trivial change. The main problem is that loading an ESM is an async operation, and yet
the call path to Mocha.prototype.loadFiles is a sync one. Changing the call path would necessitate a
semver-major change, which I'm not sure I have the ability to push, so I decided on a design
that keeps the signatures of all the functions as they are, unless there is an ESM test file to load, by which
time they morph to async functions. So their return type in the signature looks
something like Runnner|Promise<Runner>, where Runner is for cases where there are no ESM test files,
and Promise<Runner> is for the case there are
This is not a good solution, but it enables us to push this change without it being semver-major, and once
there is a decision to change to semver-major, the signature change and code change that does this is trivial.
If y'all decide that this PR can change the major version of Mocha, I can fix it so that the signatures
change and the weirdness goes away.
Another not insignificant change was the error path. In some cases, errors found by Mocha were synchronous, i.e.
they occur during the yargs.parse phase, which throws the error. But, because the call path to loadFiles could
be asynchronous, I changed the command handler (in lib/cli/run.js) to be async (i.e to return a Promise).
This means that errors (such as bad tap versions) are no more synchronous, and will always arrive at the
fail yargs handler (in lib/cli.js). To make them look like the old errors, I changed the code
there. No tests fail now, so it seems OK, but please check this in the review.
Why should this be in core?

I'm assuming this is obvious: it has to change Mocha.prototype.loadFiles to be async. There is the esm module that simulates ESM in userland, but native support has to be async. And native support is crucial if the developer's code is running using Node's native ESM support.
Benefits

Developers starting to write Node.js code in ES modules will benefit by being able to write their tests using
ESM too, and not have to dynamically import their ES modules using dynamic import (aka await import), which is a hassle and a kludge.
Possible Drawbacks

This may impact code using Mocha's API, as we are changing the signature (even if not in the short run,
definitely in the long run). Also, error handling has subtly changed, and this may impact error handling reporting
in ways I cannot know.
Applicable issues

This is currently an enhancement (minor release), that should be turned in the future into a semver-major,
as described in the "Alternate Designs" section.
Limitations

"Watch" mode does not currently work with ESM, as there is currently no way to remove an ESM module from Node.js' module cache. We would have to either wait for it to be implemented in Node (slim chance, IMHO), or refactor watch mode to use subprocesses every time a change is detected.
Module-level mocks via libs like proxyquire or rewiremock or rewire cannot work.  If you are using these libs or similar, hold off on using ESM for your test files.. This is not inherently a limitation in Mocha, but rather a limitation in Node's ESM support, which will probably be rectified sometime in Node v13.
ESM is not supported for custom reporters, nor is it supported for custom interfaces.

Coverage increased (+0.2%) to 92.936% when pulling 4945685e89215391271b22a9c6ffc3930a27e374 on giltayar:node-esm-support into 5f8df0848aa52bb0f7a0844bcd3715012a6ecfd6 on mochajs:master.

I fixed the bug in Windows (it was actually a bug in the code, but it only manifested itself in Windows).
Unfortunately, there is a bug in Windows support for ESM. The third ESM test I wrote fails in Windows in Node v12.6.0 (the version Appveyor runs), but passes in Node v12.11.1 (the latest Node version I downloaded today).
I'm not sure how to upgrade the Node version in Appveyor, so I can disable this test for Node versions < 12.11.1?

It seems the bug in Node ESM implementation is not just in Windows, but also in Linux, so I disabled ESM support in Mocha for Node <v12.11.0.

This is not a good solution, but it enables us to push this change without it being semver-major, and once there is a decision to change to semver-major, [...]

We should make this decision at first place. Why should we try to avoid semver-major?
The user - while using Mocha programmatically - would have to load the files manually, right?
var mocha = new Mocha();
mocha.addFile();
mocha.loadFiles();
mocha.run();

Would the user be affected in any other breaking way by a semver-major?
There is even an issue proposing to turn loadFiles() into a public function, to ease live of plugin creators.
I strongly tend to vote for semver-major in order to avoid the changes Mocha.prototype.run().
PS: Could you please edit your description above and add the require.cache / watch restrictions?

@juergba today loadFiles is internal and part of run. To understand what will change, let's look at your code (modified to remove loadFiles):
var mocha = new Mocha();
mocha.addFile();
mocha.run();
console.log('Done!)

If we broke the interface, it would have to look something like this:
var mocha = new Mocha();
mocha.addFile();
mocha.run().then(() => console.log('done'));

Because Mocha.run will now return a Promise<Runner>, and not a Runner. That means that if this code is in a function, that function, instead of being sync, and returning whatever, it will have to be async and return Promise<whatever>. That's not a small change for everyone that uses us. It's pretty big.
But, because ESM is async, this is a change that has to be done. What I did was this: if you have tests using ESM in Node, you can still have your old sync code. But! If you have tests that are ESM, Mocha.run will be async and will return a promise.
I am fully aboard with breaking compatibility, and in the long run it had to be done, but I did want to give y'all the option of having it both ways. I can easily patch it to break compatibility and be "correct".

In addition, if we expose loadFiles, which would have to be async if we break compatibility,
the code would be
mocha.addFile(...)
mocha.loadFiles().then(() => mocha.run()).then(() => console.log('Done')

@giltayar thank you.
If we exposed loadFiles, there would be no need to change Mocha#run. It could remain sync, always returning a Runner, right?
mocha.addFile(...)
mocha.loadFiles().then(() => mocha.run(() => console.log('Done')))

exports.singleRun = (mocha, {exit}, fileCollectParams) => {
  const files = collectFiles(fileCollectParams);
  debug('running tests with files', files);
  mocha.files = files;
  return mocha.run(exit ? exitMocha : exitMochaLater);
};

Couldn't we implement it here, even as semver-minor?

experimental-module: true: we load our files asyncly outside of mocha.run(), mark the files somehow as loaded, then call mocha.run(). Files are already loaded, so we don't load them again inside mocha.run().
experimental-module: false: files are loaded synchly inside mocha.run(), as current state.

mocha.run would always return a Runner, no Promise.
watch-run: does not work with ems anyway (require.cache), so no changes here.

@juergba yes, if we take out loadFiles, then run could be sync. But taking out loadFiles is anyway a breaking change.
Any in any case, singleRun couldn't be sync, as it has to have loadFiles in it. And that changes the interface anyway, right? So we still can't avoid it.
As for your idea of loadFiles being called outside, and we check whether it was already called or not, and if it was called, OK, and if not, load synchronously: it's still an awkward interface. Not clean and full of ifs and buts.
I say this: the correct solution is to make loadFiles and singleRun async, and that's a breaking change, whether or not loadFiles is inside run or not. So either go and break compatibility and be semver-major in a clean way, or we implement a weird solution, which could either be my solution, or yours. And I prefer my solution not because it's better (it's not!), but because people who are not native-node-ESM aware need not care about it at all. And, today, frankly, that's 99.9% of the people.

I prefer the clean way, semver-major yes/no can't really be a main criteria.
singleRun is a private function, turning it into async would not be a breaking change (?).
@demurgos @maxnordlund I need some help with this one and would highly appreciate your input.

@juergba I will submit to the decision of my elders. 😀
Once you decide, I'll do the switch. It'll probably take no more than an hour or two.
Note that there are two decisions to make:

Do we enable singleRun and others be async and thus breaking compat?
If we do, do we separate Mocha.prototype.loadFiles from Mocha.prototype.run and have only it be async?

I know I'm probably blocking this, but I expect I can get to review it in about 10 days.

THANK YOU @giltayar  !! This is most definitely not just a 'nice to have' feature... can't believe that was added as a tag.
@boneskull Any update? Cheers!

(back when the issue was created, we added the tag because it wasn’t clear when the feature would leave “experimental” status; so nice-to-have before that. now, it’s needed, obviously)
I’ll try to review this asap

@giltayar IMO, zalgo is bad.
A third option would be to leave Mocha#run as-is and create a new method (e.g., runAsync) to implement the new behavior.  We can call that function from the CLI, and we can continue to support Mocha#run until it's clear we don't want to support it any longer.  I'd prefer not to break 3rd-party code relying on it (at least for the immediate future), even if we no longer use the API internally.
runAsync, then, would always return a Promise.
So... Promises. Because Mocha doesn't use any Promises internally (prior to this PR), we'll need to ensure Mocha's behavior on unhandled rejection is sane. Mocha has well-defined behavior around how it traps and handles uncaught exceptions.  Rejection handling doesn't need to be the same as this, because it might not make sense, but if it's different, that behavior should be defined and documented.
If you're interested in this change, feel free to implement, but I can also run with this PR and get it over the finish line if you don't have time.  Also what does @juergba think of this "new method" idea?

Regarding "major" or "minor", I don't really care either way, but I still would rather not introduce a breaking API change lacking any clear necessity.  If we can side-step the existing API for programmatic users, then IMO that's the best solution.

@boneskull - I like the idea of leaving #run alone, for backward compatibility with code that uses it (and that cannot use ESM), and implementing a new (clean) #runAsync function that is Promise-driven and supports ESM, and which is called from the CLI. This also resolves the major/minor conundrum: we can leave it minor, as we're not breaking backward compatibily.
Definitely better than my version. I can do it tomorrow (it's midnight now here in Israel), but feel free to implement it yourself if you feel like it. I'm OK.
Let's do it! Let's make Mocha the first testing tool to support native Node ESM!

@boneskull I didn't think about unhandled rejections. Good point.
Handling them like unhandled exceptions (I'm guessing Mocha exits with an error?) is problematic, as I've seen code in the wild that ignores unhandled rejections (bad idea, but it happens because sometimes it's basically impossible to catch unhandled rejections in third party libraries), and which wouldn't want Mocha to fail the test because of it.
This is currently a moot issue anyway for now, as I'm guessing Mocha handles unhandled rejections when running the test, but you're talking about unhandled rejections when loading the test files? In this case, and those won't happen till Top-Level Await happens and introduces real asynchrony when loading the test files.

This is currently a moot issue anyway for now, as I'm guessing Mocha handles unhandled rejections when running the test, but you're talking about unhandled rejections when loading the test files?

That would be an incorrect guess.  😝   There's no global unhandledRejection listener added by Mocha.  Yeah, I suppose we can punt on this for now, but will have to deal with it soon with top-level await.  Pretty much not happy with how Node.js deals w/ unhandled rejections, but at least there's --unhandled-rejections=mode now.

Let's do it! Let's make Mocha the first testing tool to support native Node ESM!

I'm pretty sure tap or tape beat us to it. But thanks for picking it up again, and sorry for the delay--I've been too busy with other stuff the past 6mo or so.
Also:

[ ] We need to add v13 to the test matrix.
[ ] We need an integration test to run unflagged in v13.2.0

Also what does @juergba think of this "new method" idea?

It's a good idea.
We also have a --require option, which should be able to load ESM modules, I guess.

I can do it tomorrow (it's midnight now here in Israel), but feel free to implement it yourself if you feel like it. I'm OK.

You should find an agreement on this, who is going to do what. I think it would be fair to leave the implementation to @giltayar, if he wants so.

Just started working on it. Shouldn't be too difficult—the code is there, I just need to massage it a little.

I'm assuming I should also have a parallel Mocha#runAsync that supports ESM? I'm assuming I do.

@juergba - I have a problem with --require because it is called in the yarg .check callback, which is sync, and cannot be turned to async. It also says this:
// load requires first, because it can impact "plugin" validation (run.js)

There is another problem with watch mode: watch mode unloads the test files before rerunning. This is impossible to do (currently) with ES modules (they don't share the same cache, and the cache is currently private to Node).
Because module keys are URLS and not file paths, we can use cache buster so that each time we load a different file. But that means that watch mode will currently load and load and load the same files, without unloading the previous ones. VERY easy to implement, but I am not sure this is a good idea.

@juergba - I have a problem with --require because it is called in the yarg.check callback, which is sync, and cannot be turned to async.

Maybe yarg.check is the wrong place for our --require handling. Yargs has a middleware() method which possibly could help. We could also split this topic into a separate PR, if it gets to complex.
re watch mode: do we have a new problem, or the one we have already known for weeks? I thought we had agreed on not supporting watch with esm?
PS: I will send my feedback bit by bit and don't expect immediate action. I don't feel comfortable with this topic, yet. Anyway IMO we should not publish this PR with v7.0.0, but with next minor v7.1.0.

Because the global mocha is essentially monkeypatched in the browser (see browser-entry.js) we can remove runAsync (maybe it's just delete mocha.runAsync) from its interface. We can try to make it work later

Regarding supporting "watch" mode: the Modules working group are reluctant to add an "unload ESM" function to ESM support in Node. Understandably so, given the complexity of the edge cases: https://github.com/nodejs/modules/issues/307
What they suggested instead, is going the "subprocess" route, whereby in Watch mode, we run the tests in a subprocess, and whenever the thing changes, we rerun the subprocess, with a new cache and no problems.
This seems like a cleaner solution than unloading, and I believe you're doing something like that in the CLI today, no?

re "watch" mode: no, we are not spawning new child-processes, we manually delete require.cache. The same with our new implementation with chokidar, going to be published with v7.0.0. Nodemon uses child-processes, I think, but its said to be slow.
We only spawn a child-process when the user passes Node options via Mocha.
I propose to forget about watch mode for now. But you should add this caveat (no watch with esm) to our docu.

@juergba - will add the documentation.

We added Node v13 to our CI test matrix, please rebase.

Besides loading of test files and the already mentioned --require option, we additionally have --ui and --reporter options which use require(). We should take a decision wether we handle these options now or in a separate PR.

that can be a separate PR

@juergba and anyone else interested: discussion in https://github.com/nodejs/modules/issues/307

You should probably add .mjs and .cjs to the list of supported config extensions, too. Should a codebase have "type": "module" in its package.json, Node v13.2+ will interpret .mocharc.js as an ESM module instead of CommonJS.
One can always modify their .mocharc.js file to use export default instead of module.exports =, but obviously that'll cause problems when running tests against older versions of Node.

@boneskull - I'll work on adding your notes to the documentation. I believe this necessitates a separate "ESM" section in the documentation? I'll assume yes.
@Alhadis - good catch! I'll make the change in this PR.

I have implemented all the above review comments, except for supporting mocharc.mjs (the PR does enable supporting mocharc.cjs) - @Alhadis, FYI.
The reason I excluded mocharc.mjs support is because that would have made loadConfig an async function, which would have made more of the code async. I will add a separate commit for that, and you can choose whether to accept this or decide to move it to a separate PR.

It turns out that adding ESM .mocharc.mjs to Mocha was not trivial! I separated it into a separate commit (the last one) for you to go over and decide whether you want to include it or not.

It turns out that adding ESM .mocharc.mjs to Mocha was not trivial! I separated it into a separate commit (the last one) for you to go over and decide whether you want to include it or not.

I don't think this is good idea to squash .mocharc.mjs into this PR. We already decided to split
--require/--ui/--reporter into a separate PR. So I don't understand why you want to do this.
I guess it would also turn this PR into major again. The option parsing is a public API.

@juergba I actually looked and ensured that any of the functions I touched were not in the public API, but I may have missed it...?
And if it is semver-major, better to combine it with the other semver-major changes this PR is going to do?
But I can take them out and put them in another PR once this is merged. But if the changes are semver-major, I would definitely add them to this PR.

loadOptions is a public function.
What are the reasons you want this in?

And if it is semver-major, better to combine it with the other semver-major changes this PR is going to do?

I thought this PR is minor?

@juergba - actually, you're right. We're adding to the public api, not changing it. (I got confused)
OK, I'll revert the commits and create another PR after this is merged.
Unless we want to semver-major it along with v7...? I'm all for it! Good PR (as in Public Relations) for v7.
Your call—I won't have too much time tomorrow, but I'll try and do it Friday.

Wouldn't it be easier to add an --esm switch to opt-into the problematic behaviours, rather than drop a breaking release? That way, users have time to prepare and migrate their codebases, and the caveats @boneskull described earlier can be outlined in the switch's documentation.
I haven't read through this thread in its entirety, so forgive me if a similar stopgap was already suggested before.

What if I left loadOptions, and added loadOptionsAsync, which will be the one used by the CLI? It'll be just like we did with run and runAsync. Then we can keep the minor version.

@Alhadis - the problem is not in the CLI: the CLI is totally backward compatible. The problem is the backward compatibility of the API. But as I said above, we can use @boneskull's method of keeping the API, and adding a new async call that it is used by the CLI.

Hello everyone, I've been following this thread now for a while and I just wanted to pop in to say that I'm willing to do some beta testing if desired.
I have a personal project which I was planning to migrate completely to ESM once node unflagged it. The only thing keeping me from doing this now is that mocha needs to support it as well.
So, if desired, I can try to do it with a beta version and provide some feedback.

@juergba - I pushed the code that returns backward compatibility by "splitting" loadOptions into loadOptions and loadOptionsAsync and calling loadOptionsAsync from the CLI.
If this passes tests, I will squash all the code for mjs rc file into one commit and you can decide whether to split it into its own PR or have it inside this PR (which I prefer).

@giltayar I went ahead and installed your fork as my global mocha command using
npm i -g giltayar/mocha#node-esm-support

so I could play a bit with it. One thing I noticed though is that the cli doesn't recognize .mjs test files. For example, if I have a test folder containing 1 file called esm-test.mjs and i run mocha . from this folder, then mocha tells me Error: No test files found. When I run mocha esm-test.mjs everything works fine. The same is true for .cjs files.
Is this intentional, or did you accidentally forget this? In my opinion mocha should load those files as well when running a directory of test files.

Pushed a squashed version of ESM support for mocharc so we can decide whether we want to keep it (my preference, especially now that it's semver-minor) or split it into its own PR.

@sebamarynissen - not intentional! I'll fix it now...

Ok, so I've started to migrate my project. I'll be working from top-down, so first of all I'll migrate all my test files. I'm using the following migration strategy:

Change the extension of each test file one by one from .js to .mjs and then replace all requires with imports. After each file, run all tests in the folder by mocha . and ensure they all pass.
Once all test files have been migrated and renamed to .mjs, change back the extension of all files to .js and add a package.json in the test folder that contains

{
  "type": "module"
}

Note that strictly speaking I could've just added a package.json from the beginning and fix all test files at once. As such I wouldn't need to change the extensions back and forth, but I wanted to verify that everything works with the .mjs extensions as well as with .js combined with package.json.
All tests are passing fine after I did this, but when running the tests with the package.json file I receive a warning from node:
(node:21944) Warning: require() of ES modules is not supported.
require() of path/to/test-file.js from AppData/Roaming/npm/node_modules/mocha/lib/esm-utils.js is an ES module file as it is a .js file whose nearest parent package.json contains "type": "module" which defines all .js files in that package scope as ES modules.
Instead rename test-file.js to end in .cjs, change the requiring code to use import(), or remove "type": "module" from path/to/test/folder/package.json.

It seems that somehow node thinks that esm-utils.js is an ESM file - which it isn't. I have no clue why. Could this be something in mocha, or is it a bug in node?

@sebamarynissen - you're right, it's because of the way we import/require. You can silence it by adding --no-warning to Mocha.
But it's definitely a problem that we'll have to solve, either by figuring out the type of the file, or by always import-ing. Something to think about...
Thank you for beta-testing this!

Just a general thought, perhaps we could add a flag that always uses dynamic import for .js files, something like --always-import. As such people can quickly test if there are still bugs with node importing CJS modules. Even without any migration of test files, you'd be able to check if node can properly import all existing CJS test files.
The could could look something like this:
async function doImport(file) {
  return (await import(url.pathToFileURL(file))).default;
}

exports.requireOrImport = async file => {

  if (path.extname(file) === '.cjs') {
    return require(file);
  } else if (path.extname(file) === '.mjs' || alwaysImport) {
    return doImport(file);
  }

  // This way of figuring out whether a test file is CJS or ESM is currently the only known
  // way of figuring out whether a file is CJS or ESM.
  // If Node.js or the community establish a better procedure for that, we can fix this code.
  // Another option here would be to always use `import()`, as this also supports CJS, but I would be
  // wary of using it for _all_ existing test files, till ESM is fully stable.
  try {
    return require(file);
  } catch (err) {
    if (err.code === 'ERR_REQUIRE_ESM') {
      return doImport(file);
    } else {
      throw err;
    }
  }
};

ugh. if a warning is thrown just use import(). everyone will complain.

Report, an error about import spawned with mocha from giltayar:node-esm-support
node version: 13.5.0
package.json
{
  "scripts": {
    "test": "mocha -r esm"
  }
}

test/test.js
import { expect } from 'chai'
import toTest from '../lib/to-test'

describe('xxx', function () {
  it('xxx', async function () {
    // ...
  })
});

> npm run test
TypeError [ERR_VM_DYNAMIC_IMPORT_CALLBACK_MISSING]: A dynamic import callback was not specified.

@giltayar I've pulled this branch into a project with:
npm install --save-dev giltayar/mocha#node-esm-support

And I'm running a test file without problems with in my case:
node_modules/.bin/mocha --ui tdd test/main.mjs

However, using --watch seems to break it:
$ node_modules/.bin/mocha --watch --ui tdd test/main.mjs

Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: /home/kuno/code/lud-cue/test/main.mjs
    at Module.load (internal/modules/cjs/loader.js:986:11)
    at Function.Module._load (internal/modules/cjs/loader.js:896:14)
    at Module.require (internal/modules/cjs/loader.js:1028:19)
    at require (internal/modules/cjs/helpers.js:72:18)
    at /home/kuno/code/lud-cue/node_modules/mocha/lib/mocha.js:311:36
    at Array.forEach (<anonymous>)
    at Mocha.loadFiles (/home/kuno/code/lud-cue/node_modules/mocha/lib/mocha.js:308:14)
    at Mocha.run (/home/kuno/code/lud-cue/node_modules/mocha/lib/mocha.js:890:10)
    at Object.run (/home/kuno/code/lud-cue/node_modules/mocha/lib/cli/watch-run.js:87:22)
    at FSWatcher.<anonymous> (/home/kuno/code/lud-cue/node_modules/mocha/lib/cli/watch-run.js:49:14)
    at FSWatcher.emit (events.js:305:20)
    at /home/kuno/code/lud-cue/node_modules/chokidar/index.js:364:35
    at processTicksAndRejections (internal/process/task_queues.js:79:11)

PS. thanks for your work on this!

@warpr - yup. --watch doesn't work with ESM modules. It was a conscious decision given that we have no way of deleting modules from the ESM cache (not implemented and probably will not be implemented in Node). Doing it in the "recommended" way (by creating a subprocess for every file change is a lot of work, and it was decided to release it without watch mode.
We should add an error when trying to load an ESM module in watch mode. I'll look into it.

@tommyZZM - I would have been surprised if it had worked with the esm module! esm is a userland implementation of ESM that transpiles all imports to require. Not sure exactly why it's not working, but it makes sense that it doesn't.
You should remove the -r esm and try it. The whole point of native ESM is that you should not need such a module anymore. Note, however, that there are incompatibilities in how the esm package views modules and how native ESM does.

Not sure exactly why it's not working, but it makes sense that it doesn't.

Probably because the esm module tinkers with Node internals, things which are volatile and subject to change across releases. Undoubtedly there was furniture moved around with Node v13.2, so-to-speak.
@giltayar Just a note I've been running your fork without problems locally, and haven't had any issues (even with very contrived scenarios like atom-mocha). 👍 and :shipit: from me.

@giltayar this PR hasn't got any more comments by maintainers. So I have taken some decisions and propose:

I would like to publish this PR with an experimental release as eg. v7.0.0-esm-01 or whatever. This can be done within days, probably.
please rebase with master
I prefer not to include mocharc at this time, please remove. It has no priority and I would like to grow slowly into esm. I'm not going to review this part, but keep it for later.
we have errors to fix (esm package, watch mode) and warnings to avoid.

I hope you are still on board. Thank you.

@juergba Definitely still on board, and will rebase tonight! I will also revert the mocharc code. It's definitely a lot of code changes (from sync to async), so maybe a separate PR is a good idea (will also do that once ESM is in).

@juergba - rebased (without the mocharc change) and passed tests.

@giltayar thank you! I will review until tomorrow.

To suppress the warning, you could temporarily override the function process.emitWarning before loading the files, and set it back to its original value after loading.

@juergba Won't that be a problem if you require a test file that somehow calls process.emitWarning? By overriding it this would cause the warning to not be emitted. Unless of course you only filter out somehow the (node:21944) Warning: require() of ES modules is not supported. and let the other warnings come through.

IMO no, if we override just for loading the files, eg in loadFilesAsync(). Running the test files - which possibly emit warnings - comes afterwards.
The order is: loading the test files, then parsing the test runner tree, then running the tests.

That's true, but I think it's still possible if you have something like this
// my-test.js
require('./test-setup.js');
describe('...', function() {});

// test-setup.js
process.emitWarning('Some important warning');

Personally, I prefer just using import() for everything - as @boneskull proposed - rather than overriding process.emitWarning which feels quite hacky.

The goal of this PR is to be merged into master after having proven stable. We can't publish code with experimental state in our productive release. import() still has experimental stability.

@juergba @sebamarynissen - I'll try and override process.emitWarning locally (only for that specific warning) during the require.

@sebamarynissen are you sure this still happens. I just used Node.js v13.6.0, with a test.js file inside a folder with a package.json with type: module. The only warning I got was (node:39080) ExperimentalWarning: The ESM module loader is experimental.
Could it be that they removed the warning you saw? Or maybe I didn't understand the scenario?

@juergba - rebased again. It is now rebased against the latest commit.

@sebamarynissen are you sure this still happens. I just used Node.js v13.6.0, with a test.js file inside a folder with a package.json with type: module. The only warning I got was (node:39080) ExperimentalWarning: The ESM module loader is experimental.
Could it be that they removed the warning you saw? Or maybe I didn't understand the scenario?

@giltayar I'm using node 13.3 (on Windows 10, but shouldn't matter) and I still get there error:
(node:3452) Warning: require() of ES modules is not supported.
require() of C:\test.js from C:\...\npm\node_modules\mocha\lib\esm-utils.js is an ES module file as it is a .js file whose nearest parent package.json contains "type": "module" which defines all .js files in that package scope as ES modules.
Instead rename test.js to end in .cjs, change the requiring code to use import(), or remove "type": "module" from C:\package.json.

My test setup:

a package.json that only contains {"type": "module"}
a an empty test file with .js extension: test.js.

If I run mocha test.js I get the error above.

@sebamarynissen - I just tried it using 13.3 (using NVM) and got your warning. Then retried with 1.3.6, and didn't get the warning! Tried 13.4, and didn't get the warning.
@juergba - if it's OK with you, I believe we shouldn't do anything to deal with this problem, given that it happens only if you use ESM (with type: module), and only when you use some specific versions of Node.js.

@giltayar Ok, we leave the warning problem as is.
Could you have a look at the changelog in branch release/v7.0.0.-esm1, please?

@juergba - changelog LGTM.

We published yesterday an experimental release: npm i<EMAIL_ADDRESS>@giltayar thank you!

I have tried the experimental release using Node v12.14.0 and v13.1.0 and it works as expected, thank you!

It works great with simple import (import THREE from 'three'), but fails with a partial one (import { assert } from 'chai'). If I import only chai, no problem again (import chai from 'chai').

@Amund That's because Node doesn't support named exports from CJS. There are ways around this, but it requires the package to support it.
I have filed two PRs for this: one for chai and one for three.js which show how it can be done.

@amund this is because Node.js itself doesn't support named imports from commonjs

@giltayar @sebamarynissen Thanks for the quick response !

Is there a timeline for when this may be released in a proper (pre-) release of mocha?

@jkrems no, no timeline yet.
IMO it's to early to do so. I would also have expected more user feedback, so the demand seems to be moderate at the moment.

I would also have expected more user feedback

What sort of feedback? If it's working perfectly fine for everybody, would you expect an influx of "works great, thanks!"-type replies...?
This was even featured on the ES.next mailing list some time ago, so I don't believe it's a trivial improvement whatsoever.

Just every kind of constructive feedback.
Especially by consumers using Mocha programmatically, there you can always find some weird edge cases.

@giltayar we should coordinate our next steps.

release or pre-release?
date? - you should have some time left for fire fighting
some last changes, mainly JSDoc nits, I think
test coverage was declining, do we need more tests?
rebase, conflicts, squash
release note
update PR description
update Wiki Using-Mocha-programmatically
Mocha browser: what to do with mocha.runAsync?

Do you have anything to add to the list?

@juergba Nope. Looks good.

release or pre-release?
I would go with release... I seriously don't think there is anyway we can otherwise test it.

date? - you should have some time left for fire fighting
Should be after the 15th, as I am travelling in the US these two weeks, and wouldn't have time to fix issues. But after the 15th should be OK.

some last changes, mainly JSDoc nits, I think
Whatever you need.

test coverage was declining, do we need more tests?
It's very strange. Sometimes it went down some tenth of a percent, sometimes not.

rebase, conflicts, squash
Yup. Not sure what the specific procedure is.

release note
Yup. Not sure what the specific procedure is.

update PR description
Yup. Not sure what the specific procedure is.

update Wiki Using-Mocha-programmatically
Yup. Not sure what the specific procedure is.

Mocha browser: what to do with mocha.runAsync?
Theoretically, it shouldn't be able to run in the browser.

I would also have expected more user feedback

FWIW: My testing says "looks like it's working".  And without big test suites that actually use ESM, it's hard to get strong feedback for the new feature. So :+1: to @giltayar's comment above:

I would go with release... I seriously don't think there is anyway we can otherwise test it.

@jkrems Your point of view is incomplete. Your statement "My testing says "looks like it's working" is just one side of the mountain, the plain one.
I have to be sure that there are no regressions with the existent Mocha. If the ESM loading works, but I have unexpected regressions in existent features, this would be a bad bargain. Not one test would have to be rewritten to test this part, to prove that the existent features keep working.

@giltayar it's your turn for (after 15th, when you are home):

rebase and resolve conflicts, please don't squash yet. We updated ESLint, there may wait some surprises for you.
update PR description: doesn't reflect your implementation anymore. It has low priority.

My turn: last review

@giltayar using Mocha programmatically:
mocha.run(failures => process.exitCode = failures ? 1 : 0)
  .on('suite end', suite =>console.dir(suite));

There is no way to register event listeners on the runner instance when using Mocha@runAsync(), right?

@giltayar I did some testing on the copy-esm branch.

I removed mocha.runAsync()
call loadFilesAsync in singleRun and label files as loaded
mocha.run:  don't load a second time

mocha.addFile('../test.js');

mocha.loadFilesAsync().then(
  mocha.run().on('suite end', function(suite) {
    console.dir(suite);
  })
);

mocha.loadFilesAsync would have to be public in this case.

I tried out this prerelease and ran into some problems/complexity.
Story
I'm interested in switching to mocha from jest because it supports native modules and I'm using an electron/React/sqlite stack for the productivity app I'm building. I'm already using type: "module" because I wanted a consistent import-style across my code and React convention is ESM.
Technical background

I'm using babel (jsx, class properties, not for import-to-require) for React electron renderer-code and no transpilation for electron main code
"scripts": { "mocha": "NODE_ENV=development node --experimental-specifier-resolution node --experimental-loader ./src/lib/mocha/transpiler.js -- node_modules/mocha/bin/_mocha --config ./config/mocha.config.cjs" }
Using the still-unstable esm_transpiler_loader node API

to run babel on electron-renderer (React, jsx, etc) files
to skip electron css/asset imports

Problem
Node doesn't throw ERR_REQUIRE_ESM for .jsx files, instead throws SyntaxError: Cannot use import statement outside a module
https://github.com/mochajs/mocha/blob/v7.0.0-esm1/lib/esm-utils.js#L21
https://github.com/nodejs/node/blob/v13.8.0/lib/internal/modules/cjs/loader.js#L1161
Solution
// MAINTAIN(mocha-version): Hack: mocha wants an exception thrown on load to switch to ESM: https://github.com/mochajs/mocha/blob/v7.0.0-esm1/lib/esm-utils.js#L21
require.extensions['.jsx'] = function (module, filename) {
  // Emulate https://github.com/nodejs/node/blob/v13.8.0/lib/internal/modules/cjs/loader.js#L1167
  throw { code: 'ERR_REQUIRE_ESM' }
}

Aside: Many modules don't support named imports properly despite their documentation
Documentation suggests things like import React, {Component} from 'react' which are not compatible with type: "module". with the way those modules are written

@giltayar I rebased and resolved conflicts.

@giltayar I removed Mocha#runAsync and moved Mocha#loadFilesAsync up into singleRun.
yargs.handler (sync => async)
> runMocha (sync => async)

>> singleRun (sync => async)                      >> watchRun
>>> collectFiles                                  >>> collectFiles
>>> loadFilesAsync (new, async, public)

>>> mocha.run (remains sync, returns runner instance)
>>>> loadFiles (remains sync, evtl. skipped)
>>>> runner.run

@giltayar I pushed some changes due to code review and make-happy coveralls.

@juergba - I saw what you did with removing Mocha#runAsync (by separating loading via Mocha#loadAsync and running via Mocha#run). I like it. Simpler.
All in all, I went over the changes you did, and they make sense. Thanks for the comprehensive review and changes!

@giltayar re Mocha#runAsync: I did this change because this method does not return Promise<Runner>. The possibility to register events to the runner is a must-have requirement when using Mocha programmatically.
Can I squash my commits into yours? You remain the owner this way, otherwise I will merge two separate commits.

@juergba - you can squash, thanks. And, yes, semver-minor makes sense.


Reset password

Added ability to reset password

updated deprecated jest config variable it was complaining about

This looks good and congrats on your first PR for JAC.

Congrats on your first pull request!


Modified TCK test to use junit and commented out test for calendars t…

…hat are not julian or gregorian

Merged in https://github.com/google/j2objc/commit/dba649a98af9e72c0a5e15dbeff7457601e35817

I don't think https://github.com/google/j2objc/pull/1289/commits/1ff538044c186e53f2800ac0919423f41f4ae19a was included in PR #1289 so was not merged in dba649a


Create getting-started-with-visual-studio-for-mac.md

Getting Started with Visual Studio for Mac
Summary
Adds a getting started with Visual Studio for Mac
Details
Alt-Enter brings up Voiceover instead of F# Interactive on my Mac, and I didn't want to swerve off to address changing the key bindings for Voiceover.  Let me know if you think that was a mistake.  I tried to reuse as much of the VS for Windows article as I could.  Let me know if I need to make any changes.
Suggested Reviewers
@cartermp

@mizzle-mo,
Thanks for your contribution.
To ensure that the project team has proper rights to use your work, please complete the Contribution License Agreement at https://cla2.dotnetfoundation.org.
It will cover your contributions to all .NET Foundation-managed open source projects.
Thanks,
.NET Foundation Pull Request Bot

@mizzle-mo, thanks for signing the contribution license agreement. We will now validate the agreement and then the pull request.
Thanks, .NET Foundation Pull Request Bot

@mizzle-mo, thanks for signing the contribution license agreement. We will now validate the agreement and then the pull request.
Thanks, .NET Foundation Pull Request Bot


metric: several struct sizes in lock manager

What is changed and how it works?

Issue Number: ref #17394

What's Changed:
Add some metrics for lock manager for diagnosing memory usage.

The size of detect table is not included in this PR, because calculating it in-real-time can be costly. A more efficient approach would be to perform full recalculations at 15-second intervals, rather than implementing incremental updates on each update.
Example:

Related changes

[ ] PR to update pingcap/docs/pingcap/docs-cn:
[ ] Need to cherry-pick to the release branch

Check List
Tests

[ ] Unit test
[ ] Integration test
[ ] Manual test (add detailed scripts or steps below)
[ ] No code

Side effects

[ ] Performance regression: Consumes more CPU
[ ] Performance regression: Consumes more Memory
[ ] Breaking backward compatibility

Release note

Add some metrics for lock manager for diagnosing memory usage.

/release

BTW, is it necessary to add some metrics for the deadlock service (eg. handle dur histograms for each detect type)?

The metrics of service are just scheduling tasks.
Detect tasks are already tracked by DETECT_DURATION_HISTOGRAM. clean_up_wait_for and clean_up seem lightweight and thus not worth 2 metrics to me.

/retest

/retest

/release

Could you add metric graphs in the description especially for the test scenario of #17394, so we could know how these metrics help us to explain the source of memory consuption increase. /cc @MyonKeminta

Updated in the description.


Support for @trpc/server/adapters/fetch

Hello,
How to use trpc-openapi with fetchRequestHandler (@trpc/server/adapters/fetch)?
This is how I define serverless trpc handler without trpc-openapi:
const trpcHandler = async (ctx: RequestContext) => {
  if (ctx.url.pathname.startsWith("/_trpc")) {
    const trpcHandler = await fetchRequestHandler({
      endpoint: "/_trpc",
      req: ctx.request,
      router: trpcAppRouter,
      // @ts-ignore
      createContext: createContext,
    });

    if (trpcHandler) {
      return new Response(trpcHandler.body, {
        status: trpcHandler.status,
        headers: {
          "Content-Type":
            trpcHandler.headers.get("Content-Type") || "application/json",
        },
      });
    }
  }
};

WIP I'm trying to do by myself with ChatGPT help:
This is a high-level transformation from the original Express-like (Node HTTP) to Hattip and Fetch-like handling. Some parts of your original logic might need more specific changes, especially where you deal with sending responses or handling errors. I suggest you to look into the specific needs of your application logic and adjust the above code accordingly.
import { AnyProcedure, TRPCError } from '@trpc/server';
import { FetchHandlerOptions, fetchRequestHandler, FetchCreateContextFn } from '@trpc/server/adapters/fetch';
import cloneDeep from 'lodash.clonedeep';
import { ZodError, z } from 'zod';

import { generateOpenApiDocument } from '../../generator';
import {
  OpenApiErrorResponse,
  OpenApiMethod,
  OpenApiRouter,
  OpenApiSuccessResponse,
} from '../../types';
import { acceptsRequestBody } from '../../utils/method';
import { normalizePath } from '../../utils/path';
import { getInputOutputParsers } from '../../utils/procedure';
import {
  instanceofZodTypeCoercible,
  instanceofZodTypeLikeVoid,
  instanceofZodTypeObject,
  unwrapZodType,
  zodSupportsCoerce,
} from '../../utils/zod';
import { TRPC_ERROR_CODE_HTTP_STATUS, getErrorFromUnknown } from './errors';
import { getBody, getQuery } from './input';
import { createProcedureCache } from './procedures';

export type CreateOpenApiFetchHandlerOptions<
  TRouter extends OpenApiRouter,
> = Pick<
  FetchHandlerOptions<TRouter>,
  'router' | 'createContext' | 'responseMeta' | 'onError' | 'maxBodySize'
>;

export const createOpenApiFetchHandler = <
  TRouter extends OpenApiRouter,
>(
  opts: CreateOpenApiFetchHandlerOptions<TRouter>,
) => {
  const router = cloneDeep(opts.router);

  // Validate router
  if (process.env.NODE_ENV !== 'production') {
    generateOpenApiDocument(router, { title: '', version: '', baseUrl: '' });
  }

  const { createContext, responseMeta, onError, maxBodySize } = opts;
  const getProcedure = createProcedureCache(router);

  return fetchRequestHandler({
    createContext: createContext as FetchCreateContextFn,
    router: router,
    async onRequest: async (ctx: RequestContext) => {
      const method = ctx.method as OpenApiMethod & 'HEAD';
      const url = ctx.url;
      const path = normalizePath(url.pathname);
      const { procedure, pathInput } = getProcedure(method, path) ?? {};

      // continue with your previous logic, replacing req and res with ctx
      // Use ctx.next() where you would have used res.json(), res.send() or similar in Express
      // Use ctx.handleError(error) where you would have used next(error) in Express
      // Note: You might need to modify ctx.next() or ctx.handleError() calls based on your specific needs

      // ...

    },
  });
};

I think this is a duplicate of #188


Gradle 8.0 fails Scala build with isBlank not found in String class error

Steps to reproduce:

Build the attached project with gradle build

Expected Result:
It should build successfully.
Actual Result:
Fails with this error:
[Error] .../scala-example/src/main/scala/scala/example/App.scala:6:15: value isBlank is not a member of String
one error found

This project builds fine with Gradle 7.6, and no deprecations are reported either.
scala-example.tar.gz

@ljacomet I found this interesting, I tend to look at reported scala issues and since we didn't find problems on our side, I downloaded the sample and took a look.
Assuming you want to use JDK11+ which is where isBlank was added afaik
The scala compiler is indeed instructed to run for 11 as target:
2023-02-15T18:17:32.621-0800 [DEBUG] [org.gradle.api.internal.tasks.scala.NormalizingScalaCompiler] Java compiler arguments: -source 11 -target 11 -d /Users/rperezalcolea/Downloads/scala-example/scala-example/build/classes/scala/main -g -sourcepath  -proc:none -s /Users/rperezalcolea/Downloads/scala-example/scala-example/build/generated/sources/annotationProcessor/scala/main -XDuseUnsharedTable=true -classpath /Users/rperezalcolea/.gradle/caches/modules-2/files-2.1/org.scala-lang/scala-library/2.13.9/48bad4bee84f503be847be81ae96d32f6e78d658/scala-library-2.13.9.jar:/Users/rperezalcolea/Downloads/scala-example/scala-example/build/classes

However, the cached incremental compiler is using release flag for 8
2023-02-15T18:17:33.924-0800 [DEBUG] [org.gradle.api.internal.tasks.scala.ZincScalaCompilerFactory] [zinc] Running cached compiler 7e43e9b2 for Scala compiler version 2.13.9
2023-02-15T18:17:33.925-0800 [DEBUG] [org.gradle.api.internal.tasks.scala.ZincScalaCompilerFactory] [zinc] The Scala compiler is invoked with:
        -deprecation
        -unchecked
        -release:8
        -bootclasspath

Using toolchains definitely works
2023-02-15T18:20:42.615-0800 [DEBUG] [org.gradle.api.internal.tasks.scala.ZincScalaCompilerFactory] [zinc] Running cached compiler 4b7c6058 for Scala compiler version 2.13.9
2023-02-15T18:20:42.616-0800 [DEBUG] [org.gradle.api.internal.tasks.scala.ZincScalaCompilerFactory] [zinc] The Scala compiler is invoked with:
        -deprecation
        -unchecked
        -release:11
        -bootclasspath
        /Users/rperezalcolea/.gradle/caches/modules-2/files-2.1/org.scala-lang/scala-library/2.13.9/48bad4bee84f503be847be81ae96d32f6e78d658/scala-library-2.13.9.j

Fixed by #23926


[Meta]: Add CodeQL scanning

Adding security scanning.
Not sure how this will work, so creating a PR to allow the workflow to run.

Neat! This actually found something! I will push a commit to clean up the 1 issue it found in ETP


Attempting to clear a P2 collision callback with P2.Body.createGroupCallback fails

There is a minor typo in P2.Body.createGroupCallback which attempts to find a member "_groupCallbacksContext", whereas the actual member is "_groupCallbackContext", so a runtime error occurs when not passing a callback into the function.

Fixed in dev.


quest-sidenoder does not work in windows 11

it does not connect with the oculus, permissions have already been given
Screenshots

Desktop (please complete the following information):

OS: [e.g. Windows/
Version  0.31

TRY READING THE FIRST LINE OF THE README IN THIS REPO .


Possible to use formControlName instead of ng-model? How to detect changes then?

Hi!
Is it possible to use formControlName instead of ng-model? How to detect changes then?
Thanks!

It should support reactive forms as well.  Reactive controls have a valueChanges property which is an observable of the property changes.


Server client communication should be 1-1

Once you gain access to the server from your client, the handshake should be unique. No other client should have access to the builds.


Fixed the workload/pod field

https://github.com/rancher/longhorn/issues/461

[ ] In the overview page, it's unclear to users, that workload/pod entry can be clicked and get more details. Users may think it would click to the volume page. It's better if we can add a tooltip for the entry. If the entry is historical, said: Last time used: xxx. Click for details; if not, just say Click for details. Add a 0.5 second delay to the tooltip as well.
[ ] In the detail page, there is a group for workload status, but it's a bit hard to observe. Maybe make it slightly more obvious?


specify local font name

otherwise chrome chooses a random font on windows

Thank you! It seems that I've missed that when generated the font-family styles from the google-webfonts-helper (see also https://github.com/majodev/google-webfonts-helper/issues/124).
The same issue is present in the Admin UI. I'll consider with the next release to either specify a local name or remove it entirely.


cargo test fails

``
Build failed, waiting for other jobs to finish...
failed to run custom build command for libgit2-sys v0.4.2 (file:///home/srinivas/workspace/github/git2-rs)
Process didn't exit successfully: /home/srinivas/workspace/github/git2-rs/target/debug/build/libgit2-sys-9cd41cc7ed63ed3b/build-script-build (exit code: 101)
--- stdout
running: "cmake" "/home/srinivas/workspace/github/git2-rs/libgit2-sys/libgit2" "-DBUILD_SHARED_LIBS=OFF" "-DBUILD_CLAR=OFF" "-DCURL=OFF" "-DCMAKE_INSTALL_PREFIX=/home/srinivas/workspace/github/git2-rs/target/debug/build/libgit2-sys-9cd41cc7ed63ed3b/out" "-DCMAKE_C_FLAGS= -O0 -ffunction-sections -fdata-sections -m32" "-DCMAKE_C_COMPILER=/usr/bin/cc" "-DCMAKE_CXX_FLAGS= -O0 -ffunction-sections -fdata-sections -m32" "-DCMAKE_CXX_COMPILER=/usr/bin/c++" "-DCMAKE_BUILD_TYPE=Debug"
--- stderr
CMake Error: The source directory "/home/srinivas/workspace/github/git2-rs/libgit2-sys/libgit2" does not appear to contain CMakeLists.txt.
Specify --help for usage, or press the help button on the CMake GUI.
thread '' panicked at '
command did not execute successfully, got: exit code: 1
build script failed, must exit now', /home/srinivas/.cargo/registry/src/github.com-48ad6e4054423464/cmake-0.1.16/src/lib.rs:448
``

metadata
rustc 1.6.0 (c30b771ad 2016-01-19)
cargo 0.7.0-nightly (1af03be 2015-12-08)

Ah looks like you just need to update the submodule via git submodule update --init, after that it should work ok!


Try Now button is coming out of the Auto Write Text Card on Landing Page

Describe the bug
Upon visiting the Landing Page the Auto Write Text card's Try Now button is coming out of the card
To Reproduce
Steps to reproduce the behavior:

Go to website
Scroll down to Auto Write Text Card
See error

Expected behavior
The Try Now button should be present inside the card border like other cards
Screenshots
Actual Behavior

Expected Behavior

Desktop (please complete the following information):

OS: Windows 10
Browser: Microsoft Edge
Version: 98.0.1108.62 (Official build) (64-bit)

Steps Followed✅
Check the box with [x] If you followed all the steps.

[x] Describe the bug
[x] To Reproduce
[x] Expected behavior
[x] Screenshots

Code of Conduct✅

[x] I agree to follow this project's Code of Conduct.
[x] I checked the current issues for duplicate problems.
[x] I have gone through project README.

Describe the bug Upon visiting the Landing Page the Auto Write Text card's Try Now button is coming out of the card
To Reproduce Steps to reproduce the behavior:

Go to website
Scroll down to Auto Write Text Card
See error

Expected behavior The Try Now button should be present inside the card border like other cards
Screenshots Actual Behavior
Expected Behavior
Desktop (please complete the following information):

OS: Windows 10
Browser: Microsoft Edge
Version: 98.0.1108.62 (Official build) (64-bit)

Steps Followed✅
Check the box with [x] If you followed all the steps.

[x]  Describe the bug
[x]  To Reproduce
[x]  Expected behavior
[x]  Screenshots

Code of Conduct✅

[x]  I agree to follow this project's Code of Conduct.
[x]  I checked the current issues for duplicate problems.
[x]  I have gone through project README.

Kindly assign me this issue @Amitesh

Solved in #250


Support changing address plans

This adds support to change the address plans in standard address space
by introducing another status field to track the previously applied plan
of an address.
Fixes #1136

Closing due to inactivity.


singularize('flour') = 'flmy'

All the words that has 'our' in it, is changed to 'my'.
singularize('flour')
output: 'flmy'
singularize('your')
output: 'ymy'

Tried to replicate this:
>>> from inflection import singularize
>>> singularize("flour")
'flour'
>>> singularize("Your")
'Your'
>>> singularize("our")
'our'

Any additional information you can give?


Error in DebugDraw.DrawAABBInteranl (:1876)

GetDiagonalVectors must take box.End instead of box.Size as argument at :1879.
And DrawAABBInteranl is likely a typo too ('interanl' -> 'internal') btw.

GetDiagonalVectors must take box.End instead of box.Size as argument at :1879.

hmm, that makes sense, but I don't see any visual changes.

And DrawAABBInteranl is likely a typo too ('interanl' -> 'internal') btw.

there are many more 'interanl's' here :-)

but I don't see any visual changes.

I checked it wrong. Now everything is fixed.
Thanks!


Feature request: Add Blockscout API support

I'd like to propose adding support for the Blockscout API to improve our contract data coverage. The plan is to create a BlockscoutABILoader that would fetch contract and ABI information from Blockscout's endpoints.
Blockscout API Documentation:

https://docs.blockscout.com/devs/apis/rest
https://eth.blockscout.com/api-docs

If this looks good, I'll follow up with a PR.

Sounds great, yes please!


Abstract Database Calls

All database calls should be abstracted in a different module that should allow easier switching to MongoDB in the future

After discussions with @Helithumper, I disagree that going from one NoSQL walled garden to another is a good idea. Ideally, an ORM like SQLAlchemy should be used, which gives you options between different database types, and could even help ease the migration between different DB backends.
You should also find one that supports data type migrations. The migration from int to str for Discord snowflakes was a mess that you can see in the code right now. This should be purged from the earth if possible, and in the future, a DB migration would help clean this up.
However, here be dragons: the Kennelish code for pre-populating fields in forms + saving them to the database is very easy to mess up and is known to consist of risky code that must be heavily vetted. Peyton and I advise somehow limiting what can be pushed through this logic by using an allow-list of values scraped from either the Pydantic schema for the database or the sum of all database keys defined in the forms (those JSON files in forms).
I fully expect to have to do some consulting for this. You know where to find me.
Also for your enjoyment: https://sqlmodel.tiangolo.com. That should help you all a lot in this migration.


Pushing to remote failed

[I'm supposed to describe steps to replicate my issue here and if I don't do that, I understand that my issue will be probably ignored.]

Brackets 1.3.0-16022 (win), Git 1.9.5.msysgit.1 & Brackets-Git 0.14.27
Pushing to remote failed
Error: cmd-spawn-timeout: C:\Program Files (x86)\Git\cmd\git.exe push --porcelain --progress GitHub-MapMe master

call: git push --porcelain --progress GitHub-MapMe master
Error: cmd-spawn-timeout: C:\Program Files (x86)\Git\cmd\git.exe push --porcelain --progress GitHub-MapMe master
    at timeoutPromise (file:///C:/Users/Ken/AppData/Roaming/Brackets/extensions/user/zaggino.brackets-git/src/Cli.js:219:27)
    at file:///C:/Users/Ken/AppData/Roaming/Brackets/extensions/user/zaggino.brackets-git/src/Cli.js:262:33

#1031


Quickfix to prevent guava cache from persisting on disk after shutdown

Notice
It is not allowed to submit your PR to the master branch directly, please submit your PR to the master-pre-merge branch.
Description
As discussed in Issue #698, there is a persistence-related bug with the Guava cache, which is used by the Web3 API. This quickfix destroys all caches on shutdown of the API, which mitigates the issue for now.
Type of change
Insert x into the following checkboxes to confirm (eg. [x]):

[ ] Bug fix.
[ ] New feature.
[x] Enhancement.
[ ] Unit test.
[ ] Breaking change (a fix or feature that causes existing functionality to not work as expected).
[ ] Requires documentation update.

Testing
All existing tests pass
Verification
Insert x into the following checkboxes to confirm (eg. [x]):

[x] I have self-reviewed my own code and conformed to the style guidelines of this project.
[x] New and existing tests pass locally with my changes.
[ ] I have added tests for my fix or feature.
[x] I have made appropriate changes to the corresponding documentation.
[x] My code generates no new warnings.
[x] Any dependent changes have been made.

in my test, the cache folder persisted with all entries even after shutdown


Improve goto_issue & on_cursor_hold

Describe what this PR does / why we need it
I noticed both goto_issue and on_cursor_hold do not work with the latter issue when multi issues on one line.
# With such line below, `#12` can work, but no with `#13`.
See #12, #13

This PR solves this and slight bugs below.

4e68143 Now it can work with short issue style on the begging of the line.

It did not work with #12 on the begging.

e1b9417 It had a mistake to calculate columns.

Does this pull request fix one issue?

Describe how you did it
Describe how to verify it
Run goto_issue and on_cursor_hold for each line and each issue/PR.
Short issue pattern: #393, #394, #395
Long issue pattern: pwntester/octo.nvim#393, pwntester/octo.nvim#394, pwntester/octo.nvim#395
URL issue pattern: https://github.com/pwntester/octo.nvim/pull/393, https://github.com/pwntester/octo.nvim/pull/394, https://github.com/pwntester/octo.nvim/pull/395
Special notes for reviews

I noticed the logic cannot ignore the latter issue combining the former one, such as #123#234. I arrange such cases in a table.

I noticed the logic cannot ignore the latter issue combining the former one, such as #123#234. I arrange such cases GitHub can detect in a table.

line
can detect #234?

#123, #234
can

#123,#234
can

#123#234
cannot

#123_#234
cannot

#123 and#234
cannot

So it seems GitHub detects issues with a regex [^%w%d]+#(\d+). I fixed up the logic with such strategy: 01fa6e0.

Thanks for the contributions!