Unreal Marketplace Testing Failure for Android for v1.3.0

For v1.3.0, we added Android to the whitelist platform in the uplugin file. This is causing them to run into C++17 compilation issues similar to https://github.com/CesiumGS/cesium-unreal/issues/190#issuecomment-831522727.
Cesium Errors.txt
If we don't need Android support through marketplace for this release, they are recommending that we submit the plugin by removing Android from the uplugin Supported and Target platforms, and instead move it to BlacklistPlatforms for this release.
Regarding the errors: As mentioned in the issue comment above, I did see them when trying to build the plugin for Android at one point, but they essentially disappeared one day. I'm still not sure why they don't show up on CI. Those errors also popped up when I was trying to compile Android with UE5 EA over the weekend.
CC @CesiumGS/unreal

For the build submitted for v1.3.1:
While attempting to process your file update, we encountered the following errors:

/CesiumForUnreal/Binaries/Mac/UE4Editor-CesiumRuntime.dylib for architecture x86_64
4706
[00:01:42]
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Notes:
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation).
Possible solution: A missing vtable usually means the first non-inline virtual member function has no definition.

@baothientran Can you look into this?

sure I will look into it right away

@shehzan10 I can't reproduce the error even doing it from scratch. Can we ask them what steps they follow to produce that error? Also another thing we can suggest is to make sure security enable for CesiumRuntime.dylib and CesiumEditor.dylib. But I dout it's an issue

The Mac error from https://github.com/CesiumGS/cesium-unreal/issues/472#issuecomment-853104369 seemed to be a false warning. We need need to figure out the Android compilation issue.

For v1.3.0, we added Android to the whitelist platform in the uplugin file. This is causing them to run into C++17 compilation issues similar to #190 (comment).
Cesium Errors.txt
If we don't need Android support through marketplace for this release, they are recommending that we submit the plugin by removing Android from the uplugin Supported and Target platforms, and instead move it to BlacklistPlatforms for this release.
Regarding the errors: As mentioned in the issue comment above, I did see them when trying to build the plugin for Android at one point, but they essentially disappeared one day. I'm still not sure why they don't show up on CI. Those errors also popped up when I was trying to compile Android with UE5 EA over the weekend.
CC @CesiumGS/unreal

After many attempts of mine, the C++17 problem of Android packaging can be corrected by selecting the fourth item in Project Settings-Project-Packaging-Compile (the third item is selected by default), and selecting the fourth item seems to be mandatory Use a local compiler, but you need to add in build.cs:
// Tell Unreal Engine to use C++17
CppStandard = CppStandardVersion.Cpp17;
I have successfully packaged and installed it successfully on Android, but it crashed immediately after startup. I found that the real problem was the error prompted after the following operation: In Unreal, you can change the render settings to emulate your Android settings. When I do this, it crashes for me and gives me this error: Assertion failed: Stream.VertexBuffer->IsInitialized() [File:D:/Build/++UE4/Sync/Engine/Source/Runtime/RenderCore/Private/ VertexFactory.cpp] [Line: 210]
Vertex buffer was not initialized! Stream 3, Stride 4, Name ColorOnly Mesh Vertices.

@drakelzh I believe we fixed that Vertex buffer issue quite awhile ago. Are you using Cesium for Unreal v1.3.1 or a recent version of main?

@kring Yes, you are correct. I’m sorry. I forgot to check the latest plugin version. The problem no longer exists. Thank you for your team’s efforts.

@shehzan10 I am attempting to locally package the plugin for Android on the current main branch. However I am running into the mikktspace dependency error that was discussed in #444
Beforehand, I compiled the extern directory with VS 2017, and then ran the Windows + Android example given in the packaging documentation
Got the following error:
  Reflection code generated for UE4Game in 2.5432914 seconds
  Compiling Native 32-bit code with NDK API 'android-21'
  Compiling Native 64-bit code with NDK API 'android-21'
  Writing manifest to C:\Users\Xuelong\Dev\CesiumDevTest\Packages\HostProject\Saved\Manifest-UE4Game-Android-Development.xml
  Building UE4Game...
  Building 6 actions with 12 processes...
    [1/6] PCH.CesiumRuntime.h [armv7]
    [2/6] PCH.CesiumRuntime.h [arm64]
    [3/6] Module.CesiumRuntime.gen.cpp [armv7]
    [4/6] Module.CesiumRuntime.gen.cpp [arm64]
    [5/6] Module.CesiumRuntime.cpp [armv7]
    In file included from C:/Users/Xuelong/Dev/CesiumDevTest/Packages/HostProject/Plugins/CesiumForUnreal/Intermediate/Build/Android/UE4/Development/CesiumRuntime/Module.CesiumRuntime.cpp:12:
    C:/Users/Xuelong/Dev/CesiumDevTest/Packages/HostProject/Plugins/CesiumForUnreal/Source/CesiumRuntime/Private/CesiumGltfComponent.cpp(37,10): fatal error: 'mikktspace.h' file not found
    #include "mikktspace.h"
             ^~~~~~~~~~~~~~
    1 error generated.
    [6/6] Module.CesiumRuntime.cpp [arm64]
    In file included from C:/Users/Xuelong/Dev/CesiumDevTest/Packages/HostProject/Plugins/CesiumForUnreal/Intermediate/Build/Android/UE4/Development/CesiumRuntime/Module.CesiumRuntime.cpp:12:
    C:/Users/Xuelong/Dev/CesiumDevTest/Packages/HostProject/Plugins/CesiumForUnreal/Source/CesiumRuntime/Private/CesiumGltfComponent.cpp(37,10): fatal error: 'mikktspace.h' file not found
    #include "mikktspace.h"
             ^~~~~~~~~~~~~~
    1 error generated.
Took 19.8765484s to run UnrealBuildTool.exe, ExitCode=6
UnrealBuildTool failed. See log for more details. (C:\Users\Xuelong\AppData\Roaming\Unreal Engine\AutomationTool\Logs\C+Program+Files+Epic+Games+UE_4.26\UBT-UE4Game-Android-Development.txt)
AutomationTool exiting with ExitCode=6 (6)
BUILD FAILED

@xuelongmu If you were using an existing repo, you may need to do a git submodule update --init --recursive from the cesium-unreal repo. MikkTSpace was added as a submodule to Unreal, not native.

@shehzan10 I verified by running git submodule update --init --recursive command from the cesium-unreal repo (which didn't produce any log messages), checking that the MikkTSpace folder existed, and ran the build again with the same error.

Beforehand, I compiled the extern directory with VS 2017

Just to check the simple stuff... You need to install the extern directory, not just compile it.

As far as we can tell, the Android build is working well. I'm going to close this, and we'll open a new one if Epic is still unable to package our plugin next time we publish.

Epic is still having the same problem on Android. But so far no luck getting a complete log from them. Some things to try:

Put the package we provide inside a new project, and then try to package it from there using the Editor UI. Rather than putting it in a separate directory and packaging from the command line.
Are there any dodgy project settings that could cause problems when we do the above?
Maybe the path is too long? Imitate Epic's paths as shown in the log file.
What if Epic is unzipping our plugin package with the built-in Windows unzip that marks all the files as unsafe because they're from the internet?
What if Epic is marking the files in our ZIP read-only?

I did the following:

Created a new project in C:\Build\++Portal\Sync\LocalBuilds\PluginTemp\HostProject to match the paths in the Epic log, except I don't have a D drive so I put it on C.
Extracted our CI-produced ZIP file to the Plugins subdirectory of that. I used the Windows unzip to extract it.
Opened the project in the Editor, went to Edit -> Plugins, found the Cesium plugin, and clicked the Package button.

I did this on Windows, and the plugin built successfully for Windows, Linux, and Android.

Making the plugin files readonly after extracting them does cause the build to fail, but in a different and fairly predictable way:
UATHelper: Package Plugin Task (Windows): Running AutomationTool...
UATHelper: Package Plugin Task (Windows): Parsing command line: BuildPlugin -Plugin=C:/Build/++Portal/Sync/LocalBuilds/PluginTemp/HostProject/Plugins/CesiumForUnreal/CesiumForUnreal.uplugin -Package=C:/Build/++Portal/Sync/LocalBuilds/PluginTemp/package/CesiumForUnreal -CreateSubFolder
UATHelper: Package Plugin Task (Windows): Copying 1242 file(s) using max 64 thread(s)
UATHelper: Package Plugin Task (Windows): Reading plugin from C:\Build\++Portal\Sync\LocalBuilds\PluginTemp\package\CesiumForUnreal\HostProject\Plugins\CesiumForUnreal\CesiumForUnreal.uplugin...
UATHelper: Package Plugin Task (Windows): Building plugin for host platforms: Win64
UATHelper: Package Plugin Task (Windows): Running: C:\Program Files\Epic Games\UE_4.26\Engine\Binaries\DotNET\UnrealBuildTool.exe UE4Editor Win64 Development -Project=C:\Build\++Portal\Sync\LocalBuilds\PluginTemp\package\CesiumForUnreal\HostProject\HostProject.uproject -plugin=C:\Build\++Portal\Sync\LocalBuilds\PluginTemp\package\CesiumForUnreal\HostProject\
Plugins\CesiumForUnreal\CesiumForUnreal.uplugin -iwyu -noubtmakefiles -manifest=C:\Build\++Portal\Sync\LocalBuilds\PluginTemp\package\CesiumForUnreal\HostProject\Saved\Manifest-UE4Editor-Win64-Development.xml -nohotreload -log="C:\Users\kring\AppData\Roaming\Unreal Engine\AutomationTool\Logs\C+Program+Files+Epic+Games+UE_4.26\UBT-UE4Editor-Win64-Development.
txt"
UATHelper: Package Plugin Task (Windows):   Parsing headers for UE4Editor
UATHelper: Package Plugin Task (Windows):     Running UnrealHeaderTool "C:\Build\++Portal\Sync\LocalBuilds\PluginTemp\package\CesiumForUnreal\HostProject\HostProject.uproject" "C:\Build\++Portal\Sync\LocalBuilds\PluginTemp\package\CesiumForUnreal\HostProject\Intermediate\Build\Win64\UE4Editor\Development\UE4Editor.uhtmanifest" -LogCmds="loginit warning, loge
xit warning, logdatabase error" -Unattended -WarningsAsErrors -abslog="C:\Users\kring\AppData\Roaming\Unreal Engine\AutomationTool\Logs\C+Program+Files+Epic+Games+UE_4.26\UHT-UE4Editor-Win64-Development.txt" -installed
UATHelper: Package Plugin Task (Windows):   Reflection code generated for UE4Editor in 8.242515 seconds
UATHelper: Package Plugin Task (Windows):   Writing manifest to C:\Build\++Portal\Sync\LocalBuilds\PluginTemp\package\CesiumForUnreal\HostProject\Saved\Manifest-UE4Editor-Win64-Development.xml
UATHelper: Package Plugin Task (Windows):   Building UE4Editor...
UATHelper: Package Plugin Task (Windows):   Using Visual Studio 2019 14.29.30038 toolchain (C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.29.30037) and Windows 10.0.19041.0 SDK (C:\Program Files (x86)\Windows Kits\10).
UATHelper: Package Plugin Task (Windows):   Building 13 actions with 12 processes...
UATHelper: Package Plugin Task (Windows):     [1/13] Default.rc2
UATHelper: Package Plugin Task (Windows):     [2/13] Default.rc2
UATHelper: Package Plugin Task (Windows):     [3/13] PCH.CesiumRuntime.cpp
UATHelper: Package Plugin Task (Windows):     [4/13] PCH.CesiumEditor.cpp
UATHelper: Package Plugin Task (Windows):     [5/13] Module.CesiumEditor.gen.cpp
UATHelper: Package Plugin Task (Windows):     [6/13] Module.CesiumRuntime.gen.cpp
UATHelper: Package Plugin Task (Windows):     [7/13] Module.CesiumRuntime.cpp
UATHelper: Package Plugin Task (Windows):     [8/13] UE4Editor-CesiumRuntime.lib
UATHelper: Package Plugin Task (Windows):        Creating library C:\Build\++Portal\Sync\LocalBuilds\PluginTemp\package\CesiumForUnreal\HostProject\Plugins\CesiumForUnreal\Intermediate\Build\Win64\UE4Editor\Development\CesiumRuntime\UE4Editor-CesiumRuntime.lib and object C:\Build\++Portal\Sync\LocalBuilds\PluginTemp\package\CesiumForUnreal\HostProject\Plugin
s\CesiumForUnreal\Intermediate\Build\Win64\UE4Editor\Development\CesiumRuntime\UE4Editor-CesiumRuntime.exp
UATHelper: Package Plugin Task (Windows):     [9/13] UE4Editor-CesiumRuntime.dll
UATHelper: Package Plugin Task (Windows):     LINK : fatal error LNK1104: cannot open file 'C:\Build\++Portal\Sync\LocalBuilds\PluginTemp\package\CesiumForUnreal\HostProject\Plugins\CesiumForUnreal\Binaries\Win64\UE4Editor-CesiumRuntime.dll'
UATHelper: Package Plugin Task (Windows):     [10/13] Module.CesiumEditor.cpp
UATHelper: Package Plugin Task (Windows):     [11/13] UE4Editor-CesiumEditor.lib
UATHelper: Package Plugin Task (Windows):        Creating library C:\Build\++Portal\Sync\LocalBuilds\PluginTemp\package\CesiumForUnreal\HostProject\Plugins\CesiumForUnreal\Intermediate\Build\Win64\UE4Editor\Development\CesiumEditor\UE4Editor-CesiumEditor.lib and object C:\Build\++Portal\Sync\LocalBuilds\PluginTemp\package\CesiumForUnreal\HostProject\Plugins\
CesiumForUnreal\Intermediate\Build\Win64\UE4Editor\Development\CesiumEditor\UE4Editor-CesiumEditor.exp
UATHelper: Package Plugin Task (Windows):     [12/13] UE4Editor-CesiumEditor.dll
UATHelper: Package Plugin Task (Windows):     LINK : fatal error LNK1104: cannot open file 'C:\Build\++Portal\Sync\LocalBuilds\PluginTemp\package\CesiumForUnreal\HostProject\Plugins\CesiumForUnreal\Binaries\Win64\UE4Editor-CesiumEditor.dll'
UATHelper: Package Plugin Task (Windows): Took 53.875737s to run UnrealBuildTool.exe, ExitCode=6
UATHelper: Package Plugin Task (Windows): UnrealBuildTool failed. See log for more details. (C:\Users\kring\AppData\Roaming\Unreal Engine\AutomationTool\Logs\C+Program+Files+Epic+Games+UE_4.26\UBT-UE4Editor-Win64-Development.txt)
UATHelper: Package Plugin Task (Windows): AutomationTool exiting with ExitCode=6 (6)
UATHelper: Package Plugin Task (Windows): BUILD FAILED

Created a new project in C:\Build++Portal\Sync\LocalBuilds\PluginTemp\HostProject to match the paths in the Epic log,

Do you happen to have long file paths enabled on your machine? Maybe you could try disabling it https://www.howtogeek.com/266621/how-to-make-windows-10-accept-file-paths-over-260-characters/

Oh that's a really good point, thanks @xuelongmu! I do have it enabled. I'll retry that test with it disabled.

Well that was a great thought, but I changed the registry setting, rebooted, and re-ran the test from the beginning, and the plugin still builds successfully on all platforms.

Epic finally sent me a log. The main difference that jumps out at me in the Android build is that we have a slightly newer version of the Android NDK.
Ours:
PLATFORM_ANDROID_NDK_VERSION = 210500
NDK toolchain: r21e, NDK version: 21, GccVersion: 4.9, ClangVersion: 9.0.9

Theirs:
PLATFORM_ANDROID_NDK_VERSION = 210200
NDK toolchain: r21b, NDK version: 21, GccVersion: 4.9, ClangVersion: 9.0.8

Another (less likely) thing is that their build is done with XGE / Incredibuild, whereas ours is not.
I'll see if I can reproduce their build failure with this new information.

I downgrade to 21b in the https://github.com/CesiumGS/cesium-unreal/tree/android-ndk-21b branch, and now it reports exactly the same NDK information as reported in Epic's log. But our build still completes successfully.

When the build fails, Epic's log reports:
Error executing ...\Android\-23\ndk\21.0.6113669\toolchains\llvm\prebuilt\windows-x86_64\bin\clang++.exe (tool returned code: 1)

That 21.0.6113669 is interesting because it doesn't correspond to version 21b of the Android NDK (that would be 21.1.6352462), it corresponds to the original version 21 (you might call it 21a, but Google doesn't). So despite the log saying that it's using version 21b of the Android NDK, Epic's XGE-based build is apparently actually use 21. Ok, guess I'll try that one. Based on the NDK changelog, though, there's no indication that C++17 support would be available in 21b but not in 21. So the more likely explanation is that the XGE-based build is misconfigured in other ways, not just using an unexpected version of the NDK.

I installed Incredibuild / XGE on my system, and now the UE plugin package process uses it. But still it completes successfully. Two caveats, though: I'm still using NDK 21e locally rather than NDK 21, and I don't have an Incredibuild license so I'm running in "Standalone Mode". I don't think either of those should matter, but who knows.

I finally figured out the cause of the build failures. Unreal Engine gained support for C++17 on Android in version 4.26.2. Prior versions, including 4.26.0, and 4.26.1, only supported C++14 on Android. This was a limitation in the Unreal Build Tool, not anything deeper than that. But unfortunately, Epic's Marketplace build process uses 4.26.0, so we can't use C++17 in a Marketplace plugin that supports Android. Options:

Convince Epic to use 4.26.2 in their Marketplace plugin build process. I'm not going to hold my breath.
For anyone that wants to use our plugin on Android, make them install it from GitHub rather than from the Marketplace. Not ideal.
Change Cesium for Unreal and cesium-native so that it can compiler for C++14. At least the non-Editor bits, because the Editor doesn't run on Android anyway. I started this in https://github.com/CesiumGS/cesium-native/pull/280.


[CL][Swapping]: refactor to use Strategy design pattern instead of zeroForOne boolean

Background
Currently, we use zeroForOne boolean within swapping logic that leads to code like this:
func getNextSqrtPriceFromInput(sqrtPriceCurrent, liquidity, amountRemaining sdk.Dec, zeroForOne bool) (sqrtPriceNext sdk.Dec) {
	if zeroForOne {
		sqrtPriceNext = getNextSqrtPriceFromAmount0RoundingUp(sqrtPriceCurrent, liquidity, amountRemaining)
	} else {
		sqrtPriceNext = getNextSqrtPriceFromAmount1RoundingDown(sqrtPriceCurrent, liquidity, amountRemaining)
	}
	return sqrtPriceNext
}

This reduces readability and increases the likelihood of making a mistake by providing a wrong flag. Our functions and methods should be cohesive.
Suggested Design
Instead, we should use a strategy design pattern. By doing so, we can initialize a specific "strategy" either zeroForOne or oneForZero at the beginning of the execution flow of the swap.
The concrete strategies have the same interfaces but different implementations. As a result, we should be able to call each strategy's implementation and avoid passing in the zeroForOne boolean throughout the codebase.
The previous example would turn into:
type swapStrategy interface {
    getNextSqrtPriceFromInput(sqrtPriceCurrent, liquidity, amountRemaining sdk.Dec) (sqrtPriceNext sdk.Dec)
}
...

newSwapStrategy(zeroForOne bool) swapStrategy {
    if zeroForOne {
        return &zeroForOneStrategy{}
    }
    return &oneForZeroStrategy{}
}

func (s *zeroForOneStrategy) getNextSqrtPriceFromInput(sqrtPriceCurrent, liquidity, amountRemaining sdk.Dec) (sqrtPriceNext sdk.Dec) {
	return getNextSqrtPriceFromAmount0RoundingUp(sqrtPriceCurrent, liquidity, amountRemaining)
}

func (s *oneForZeroStrategy) getNextSqrtPriceFromInput(sqrtPriceCurrent, liquidity, amountRemaining sdk.Dec) (sqrtPriceNext sdk.Dec) {
	return getNextSqrtPriceFromAmount1RoundingDown(sqrtPriceCurrent, liquidity, amountRemaining)
}

note that the interface and each strategy will have more methods defined

The clients would then simply call:
func swap(...) ... {
    zeroForOne := ...
    swapStrategy := newSwapStrategy(zeroForOne)

    nextSqrtPrice := swapStrategy.getNextSqrtPriceFromInput(...)
}

Acceptance Criteria

strategy design pattern is integrated
code duplication minimized
avoid passing zeroForOne boolean
all existing tests pass

Hello is anyone in the process? I'm willing to work with it

@p0mvn I will assign @hieuvubk
Thank you!

As part of the final check off for this issue, ensure that the problem in this discussion has been resolved:
https://github.com/osmosis-labs/osmosis/pull/4131#discussion_r1092794164

Closing in favor of: https://github.com/osmosis-labs/osmosis/issues/4427


Documentation for set-namespace, set-label, set-annotation functions

I think for future releases I'd probably opt for having documentation as a check box in the main ticket for the function delivery


Click on 'sortable' element under Firefox

Hi!
Under Firefox unable to click on element inside 'Slip' container. The problem coming from states.undecided function. A click is blocked on an element with style.willChange = 'transform'. I propose to eliminate line
this.target.node.style.willChange = transformCSSPropertyName;
for FireFox browser.
Thank you!

I can't reproduce it.
Which version of Firefox? Do you get a JS error in the console?

Pls take a look to http://jsfiddle.net/ASerbinenko/p264bavb/9/
Under 'Chrome' both sign 'X' and item text are clickable (You can see response in console)
But under Firefox only item text is clickable, not sign 'X'.
I think the problem is relative to the ::before css attribute:
.pri-delete::before {
content: "x";
}
Thank you,
-=A=-

This is because you have <a href="javascript:void(0)". You should never use this for anything, ever.

Thank you!

will-change is needed, and it doesn't throw JS errors, so I don't want to remove it.
That might be a Firefox CSS bug. Removing position: absolute; from .fli .btn-icon .pri fixes the issue for me. Try using flexbox instead maybe?

I can confirm this issue. It seems specific for Firefox.
In my case it's a bit more interesting:
I've got a lost containing paper-input elements (Polymer elements). After applying Slip on that list, you can't click directly on them. Interestingly, clicking slightly below them actually works.
Here's my example: JSBin.
Manually resetting will-change to unset fixes the problem. Is it really necessary? I think it could be made into a opt-out feature which would detect if the browser is Firefox and if so, not set the will-change style.
It might be a Firefox bug, I'll look into reporting it on their bug tracker.

Yes, please report it to Firefox's bug tracker.

Sorry that it took so long but I've finally managed to reproduce this bug in plain HTML. I didn't want to report an issue saying that it happens with a specific library so when I had my free time I was trying to isolate the problem from Slip.
Here's link to Firefox bug tracker


#M21. Add functionality to set maximum number of registrations.

Intriguing! A maximum number of registrants... 🤔
I suppose in some instances it makes sense, would like to keep it as "unset" for most though, presumably?

Yep exactly. It seems that with the upcoming ("secret" until we announce it) hackathon, this is wanted.


Add root degree to PolynomialExpansion

To PolynomialExpansion I added expansion for root degrees.
I created a pull request for the same problem in the file PolynomialExpansionGeneralized, I shall close it to avoid confusions.
For example, for root degree 3, and basis vector (x,y) we have : (x, x^(1/2), x^(1/3), y, y^(1/2), y^(1/3)
We can merge simple polynomial expansion with root polynomial expansion: for simple degree 2 and root degree 2:
x, y, xy, x^2, y^2, x^(1/2), y^(1/2)
I used java.lang.Math.pow, and there is a case in it :
If the first argument is finite and less than zero and if the second argument is finite and not an integer,then the result is NaN
For this case I raised a IllegalArgumentException; the user should normalize the features in order to have only positive features.
The case of root degree polynomial expansion is mentioned in the Stanford Machine Learning course on Coursera.
It helped myself to minimize error when performing Linear Regression.
What changes were proposed in this pull request?
To PolynomialExpansion I added expansion for root degrees.
How was this patch tested?
I did manual test on different numeric data (Integer, Double, positive, negative, zero, very large numbers, very small numbers). I tested also that the value x^1 appears once and only once in the features, whatever the setting is (setDegree only, setDegreeRoot only, both setDegree and setDegreeRoot).
Please review https://spark.apache.org/contributing.html before opening a pull request.

PolynomialExpansion with root degrees

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

I think the main purpose of the polynomial expansion support is to generate interaction terms like "x * y". This only generates fractional powers of an input. I doubt that anything but square root would be useful in almost all cases? so I doubt this is worth adding to the API.

We use sqrt for engineered features quite often, for some of the variables with a larger scale
of values. Haven't seen our DS folks use anything else by 0.5 (sqrt) for the pow .. it doesn't mean
somebody else doesn't have use cases for this. Thanks!

I used 3rd degree root for a polynomial curve, for temporal linear regression. The 3rd degree root allowed to obtain  particular shape for several exceptional elements. Now, one may say that such a curve favorises high variance, yet it described well those elements as well as the others, and helped minimizing the error for the test set and future data.

Sure, but none of that seems to call for a general function to generate the nth roots of an input. It seems harder in the common case that you want just the square or cube root. I would not add this.


mongo:5.0.0 - container dies with 139 on executing aggregate

mongo:5.0.0 - container dies with 139 on executing aggregate on RHEL 7.6
dockerfile
version: "3"
services:
  mongo-db:
    image: mongo:5.0.0
    ports:
      - 27017:27017
    volumes:
      - mongo-db:/data/db
  mongo-express:
      image: mongo-express:1.0.0-alpha.4
      environment:
        ME_CONFIG_MONGODB_PORT: 27017
        ME_CONFIG_MONGODB_SERVER: mongo-db
        ME_CONFIG_BASICAUTH_USERNAME: ''
        ME_CONFIG_BASICAUTH_PASSWORD: ''
        ME_CONFIG_MONGODB_ENABLE_ADMIN: "true"
        ME_CONFIG_MONGODB_ADMINUSERNAME: ''
        ME_CONFIG_MONGODB_ADMINPASSWORD: ''
      ports:
        - "8081:8081"
      depends_on:
        - "mongo-db"
volumes:
  mongo-db:
    external:
      name: mongo-db

docker events
[root@dockerhost ~]# docker events
2021-07-28T06:20:27.442371850+03:00 container die 16c877c960568014c19056c618dc0b6ef14b40e7a588993cdcb69312f49f347a (com.docker.compose.config-hash=5963c435b3532c23a78f7d0ce2e6ce2b12fc88697e7b6d3498eb72b8d7393ff1, com.docker.compose.container-number=1, com.docker.compose.oneoff=False, com.docker.compose.project=mongodb, com.docker.compose.service=mongo-db, com.docker.compose.version=1.23.2, exitCode=139, image=mongo:5.0.0, name=mongodb_mongo-db_1)
2021-07-28T06:20:27.648992801+03:00 network disconnect 30f3bde82bd084c1ce1b537de395f84b17661452de15012acc7bbb74b300e4e0 (container=16c877c960568014c19056c618dc0b6ef14b40e7a588993cdcb69312f49f347a, name=mongodb_default, type=bridge)
2021-07-28T06:20:27.665205578+03:00 volume unmount 7e12c1d05de11879da2886560868087cc15272b9299cbc47c6ce0e835d022905 (container=16c877c960568014c19056c618dc0b6ef14b40e7a588993cdcb69312f49f347a, driver=local)
2021-07-28T06:20:27.665293860+03:00 volume unmount mongo-db (container=16c877c960568014c19056c618dc0b6ef14b40e7a588993cdcb69312f49f347a, driver=local)

MongoDB Compass

pymongo code
client = MongoClient('mongodb://mongodbhost:27017/?ssl=false')
disk_use = { 'allowDiskUse': True }
aggregate_days_pipeline = [...]
result = client['abc']['xyz'].aggregate(aggregate_days_pipeline, **disk_use)
pprint(result.next())

pymongo version
$ pip list | grep pymongo
pymongo                 3.12.0
pymongo exception
$ python aggregate.py
Traceback (most recent call last):
  File "C:\Python37\lib\site-packages\pymongo\mongo_client.py", line 1515, in _retryable_read
    read_pref, session, address=address)
  File "C:\Python37\lib\site-packages\pymongo\mongo_client.py", line 1346, in _select_server
    server = topology.select_server(server_selector)
  File "C:\Python37\lib\site-packages\pymongo\topology.py", line 246, in select_server
    address))
  File "C:\Python37\lib\site-packages\pymongo\topology.py", line 203, in select_servers
    selector, server_timeout, address)
  File "C:\Python37\lib\site-packages\pymongo\topology.py", line 220, in _select_servers_loop
    (self._error_message(selector), timeout, self.description))
pymongo.errors.ServerSelectionTimeoutError: ilcedto227:27017: [WinError 10061] No connection could be made because the target machine actively refused it, Timeout: 30s, Topology Description: <TopologyDescription id: 6100d686e58f6f012b324373, topology_type: Single, servers: [<ServerDescription ('ilcedto227', 27017) server_type: Unknown, rtt: None, error=AutoReconnect('ilcedto227:27017: [WinError 10061] No connection could be made because the target machine actively refused it')>]>

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "report_lib/aggregate.py", line 335, in <module>
    result = client['aws']['globe-51297197'].aggregate(aggregate_days_pipeline, **disk_use)
  File "C:\Python37\lib\site-packages\pymongo\collection.py", line 2501, in aggregate
    **kwargs)
  File "C:\Python37\lib\site-packages\pymongo\collection.py", line 2420, in _aggregate
    retryable=not cmd._performs_write)
  File "C:\Python37\lib\site-packages\pymongo\mongo_client.py", line 1531, in _retryable_read
    raise last_error
  File "C:\Python37\lib\site-packages\pymongo\mongo_client.py", line 1525, in _retryable_read
    return func(session, server, sock_info, secondary_ok)
  File "C:\Python37\lib\site-packages\pymongo\aggregation.py", line 149, in get_cursor
    user_fields=self._user_fields)
  File "C:\Python37\lib\site-packages\pymongo\pool.py", line 726, in command
    self._raise_connection_failure(error)
  File "C:\Python37\lib\site-packages\pymongo\pool.py", line 721, in command
    exhaust_allowed=exhaust_allowed)
  File "C:\Python37\lib\site-packages\pymongo\network.py", line 149, in command
    reply = receive_message(sock_info, request_id)
  File "C:\Python37\lib\site-packages\pymongo\network.py", line 196, in receive_message
    _receive_data_on_socket(sock_info, 16, deadline))
  File "C:\Python37\lib\site-packages\pymongo\network.py", line 293, in _receive_data_on_socket
    raise AutoReconnect("connection closed")
pymongo.errors.AutoReconnect: connection closed

docker logs mongodb_mongo-db_1 -f
{"t":{"$date":"2021-07-28T03:52:57.854+00:00"},"s":"I",  "c":"NETWORK",  "id":22943,   "ctx":"listener","msg":"Connection accepted","attr":{"remote":"<IP_ADDRESS>:62893","uuid":"8950832b-9693-44fe-b2c8-8ad4cc085c98","connectionId":19,"connectionCount":16}}
{"t":{"$date":"2021-07-28T03:52:57.865+00:00"},"s":"I",  "c":"NETWORK",  "id":51800,   "ctx":"conn19","msg":"client metadata","attr":{"remote":"<IP_ADDRESS>:62893","client":"conn19","doc":{"driver":{"name":"PyMongo","version":"3.12.0"},"os":{"type":"Windows","name":"Windows 10","architecture":"AMD64","version":"10.0.18362-SP0"},"platform":"CPython 3.7.9.final.0"}}}
{"t":{"$date":"2021-07-28T03:52:58.346+00:00"},"s":"I",  "c":"NETWORK",  "id":22943,   "ctx":"listener","msg":"Connection accepted","attr":{"remote":"<IP_ADDRESS>:62894","uuid":"549f0ecb-f579-435d-9f41-00e603ea3375","connectionId":20,"connectionCount":17}}
{"t":{"$date":"2021-07-28T03:52:58.347+00:00"},"s":"I",  "c":"NETWORK",  "id":22943,   "ctx":"listener","msg":"Connection accepted","attr":{"remote":"<IP_ADDRESS>:62895","uuid":"6cbdd05c-dd80-4d68-91fd-2caf97cf0765","connectionId":21,"connectionCount":18}}
{"t":{"$date":"2021-07-28T03:52:58.347+00:00"},"s":"I",  "c":"NETWORK",  "id":51800,   "ctx":"conn20","msg":"client metadata","attr":{"remote":"<IP_ADDRESS>:62894","client":"conn20","doc":{"driver":{"name":"PyMongo","version":"3.12.0"},"os":{"type":"Windows","name":"Windows 10","architecture":"AMD64","version":"10.0.18362-SP0"},"platform":"CPython 3.7.9.final.0"}}}
{"t":{"$date":"2021-07-28T03:52:58.348+00:00"},"s":"I",  "c":"NETWORK",  "id":51800,   "ctx":"conn21","msg":"client metadata","attr":{"remote":"<IP_ADDRESS>:62895","client":"conn21","doc":{"driver":{"name":"PyMongo","version":"3.12.0"},"os":{"type":"Windows","name":"Windows 10","architecture":"AMD64","version":"10.0.18362-SP0"},"platform":"CPython 3.7.9.final.0"}}}
{"t":{"$date":"2021-07-28T03:52:58.639+00:00"},"s":"F",  "c":"CONTROL",  "id":4757800, "ctx":"conn20","msg":"Writing fatal message","attr":{"message":"Invalid access at address: 0x10"}}
{"t":{"$date":"2021-07-28T03:52:58.639+00:00"},"s":"F",  "c":"CONTROL",  "id":4757800, "ctx":"conn20","msg":"Writing fatal message","attr":{"message":"Got signal: 11 (Segmentation fault).\n"}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31380,   "ctx":"conn20","msg":"BACKTRACE","attr":{"bt":{"backtrace":[{"a":"56143F6F7215","b":"56143B955000","o":"3DA2215","s":"_ZN5mongo18stack_trace_detail12_GLOBAL__N_119printStackTraceImplERKNS1_7OptionsEPNS_14StackTraceSinkE.constprop.357","s+":"215"},{"a":"56143F6F9CA9","b":"56143B955000","o":"3DA4CA9","s":"_ZN5mongo15printStackTraceEv","s+":"29"},{"a":"56143F6F243C","b":"56143B955000","o":"3D9D43C","s":"abruptQuitWithAddrSignal","s+":"EC"},{"a":"7F4DBC5593C0","b":"7F4DBC544000","o":"153C0","s":"funlockfile","s+":"60"},{"a":"56143E378C07","b":"56143B955000","o":"2A23C07","s":"_ZN5mongo35WindowFunctionExecRemovableDocument10initializeEv","s+":"1A7"},{"a":"56143E37922D","b":"56143B955000","o":"2A2422D","s":"_ZN5mongo35WindowFunctionExecRemovableDocument6updateEv","s+":"26D"},{"a":"56143E347531","b":"56143B955000","o":"29F2531","s":"_ZN5mongo37DocumentSourceInternalSetWindowFields9doGetNextEv","s+":"191"},{"a":"56143DA9F568","b":"56143B955000","o":"214A568","s":"_ZN5mongo14DocumentSource7getNextEv","s+":"48"},{"a":"56143E367F0C","b":"56143B955000","o":"2A12F0C","s":"_ZN5mongo8Pipeline7getNextEv","s+":"3C"},{"a":"56143DE60C09","b":"56143B955000","o":"250BC09","s":"_ZN5mongo20PlanExecutorPipeline8_getNextEv","s+":"29"},{"a":"56143DE60CAC","b":"56143B955000","o":"250BCAC","s":"_ZN5mongo20PlanExecutorPipeline15getNextDocumentEPNS_8DocumentEPNS_8RecordIdE","s+":"4C"},{"a":"56143DE60E2E","b":"56143B955000","o":"250BE2E","s":"_ZN5mongo20PlanExecutorPipeline7getNextEPNS_7BSONObjEPNS_8RecordIdE","s+":"EE"},{"a":"56143D93C707","b":"56143B955000","o":"1FE7707","s":"_ZN5mongo12runAggregateEPNS_16OperationContextERKNS_15NamespaceStringERKNS_23AggregateCommandRequestERKNS_18LiteParsedPipelineERKNS_7BSONObjERKSt6vectorINS_9PrivilegeESaISF_EEPNS_3rpc21ReplyBuilderInterfaceE","s+":"33C7"},{"a":"56143D932545","b":"56143B955000","o":"1FDD545","s":"_ZN5mongo12_GLOBAL__N_115PipelineCommand10Invocation3runEPNS_16OperationContextEPNS_3rpc21ReplyBuilderInterfaceE","s+":"75"},{"a":"56143E54778F","b":"56143B955000","o":"2BF278F","s":"_ZN5mongo14CommandHelpers20runCommandInvocationEPNS_16OperationContextERKNS_12OpMsgRequestEPNS_17CommandInvocationEPNS_3rpc21ReplyBuilderInterfaceE","s+":"7F"},{"a":"56143E54C99E","b":"56143B955000","o":"2BF799E","s":"_ZN5mongo14CommandHelpers20runCommandInvocationESt10shared_ptrINS_23RequestExecutionContextEES1_INS_17CommandInvocationEENS_9transport15ServiceExecutor14ThreadingModelE","s+":"1BE"},{"a":"56143CE74FC7","b":"56143B955000","o":"151FFC7","s":"_ZN5mongo12_GLOBAL__N_120runCommandInvocationESt10shared_ptrINS_23RequestExecutionContextEES1_INS_17CommandInvocationEE","s+":"97"},{"a":"56143CE87556","b":"56143B955000","o":"1532556","s":"_ZN5mongo12_GLOBAL__N_114RunCommandImpl11_runCommandEv","s+":"146"},{"a":"56143CE87DB6","b":"56143B955000","o":"1532DB6","s":"_ZN5mongo12_GLOBAL__N_132RunCommandAndWaitForWriteConcern24_runCommandWithFailPointEv","s+":"86"},{"a":"56143CE8831C","b":"56143B955000","o":"153331C","s":"_ZN5mongo12_GLOBAL__N_132RunCommandAndWaitForWriteConcern8_runImplEv","s+":"3C"},{"a":"56143CE7952C","b":"56143B955000","o":"152452C","s":"_ZN5mongo12_GLOBAL__N_114RunCommandImpl3runEv","s+":"13C"},{"a":"56143CE7B5CE","b":"56143B955000","o":"15265CE","s":"_ZN5mongo12_GLOBAL__N_119ExecCommandDatabase12_commandExecEv","s+":"1CE"},{"a":"56143CE84220","b":"56143B955000","o":"152F220","s":"_ZZN5mongo12_GLOBAL__N_114executeCommandESt10shared_ptrINS0_13HandleRequest16ExecutionContextEEENUlvE0_clEv","s+":"450"},{"a":"56143CE86410","b":"56143B955000","o":"1531410","s":"ZZN5mongo15unique_functionIFvPNS_14future_details15SharedStateBaseEEE8makeImplIZNS1_10FutureImplINS1_8FakeVoidEE16makeContinuationIvZZNOS9_4thenIZNS_12_GLOBAL__N_114executeCommandESt10shared_ptrINSC_13HandleRequest16ExecutionContextEEEUlvE0_EEDaOT_ENKUlvE1_clEvEUlPNS1_15SharedStateImplIS8_EESN_E_EENS7_ISI_EEOT0_EUlS3_E_EEDaSJ_EN12SpecificImpl4callEOS3","s+":"80"},{"a":"56143CE414B7","b":"56143B955000","o":"14EC4B7","s":"_ZN5mongo14future_details15SharedStateBase20transitionToFinishedEv","s+":"147"},{"a":"56143CE8A792","b":"56143B955000","o":"1535792","s":"ZN5mongo14future_details10FutureImplINS0_8FakeVoidEE11generalImplIZNOS3_17propagateResultToEPNS0_15SharedStateImplIS2_EEEUlOS2_E_ZNOS3_17propagateResultToES7_EUlONS_6StatusEE0_ZNOS3_17propagateResultToES7_EUlvE1_EEDaOT_OT0_OT1","s+":"152"},{"a":"56143CE7DBDC","b":"56143B955000","o":"1528BDC","s":"ZZN5mongo15unique_functionIFvPNS_14future_details15SharedStateBaseEEE8makeImplIZNS1_10FutureImplINS1_8FakeVoidEE16makeContinuationIvZZNOS9_4thenIZNS_12_GLOBAL__N_114executeCommandESt10shared_ptrINSC_13HandleRequest16ExecutionContextEEEUlvE_EEDaOT_ENKUlvE1_clEvEUlPNS1_15SharedStateImplIS8_EESN_E_EENS7_ISI_EEOT0_EUlS3_E_EEDaSJ_EN12SpecificImpl4callEOS3","s+":"AC"},{"a":"56143CE414B7","b":"56143B955000","o":"14EC4B7","s":"_ZN5mongo14future_details15SharedStateBase20transitionToFinishedEv","s+":"147"},{"a":"56143CE84C0A","b":"56143B955000","o":"152FC0A","s":"_ZN5mongo12_GLOBAL__N_114executeCommandESt10shared_ptrINS0_13HandleRequest16ExecutionContextEE","s+":"22A"},{"a":"56143CE8563E","b":"56143B955000","o":"153063E","s":"_ZN5mongo12_GLOBAL__N_116receivedCommandsESt10shared_ptrINS0_13HandleRequest16ExecutionContextEE","s+":"1BE"},{"a":"56143CE86356","b":"56143B955000","o":"1531356","s":"_ZN5mongo12_GLOBAL__N_115CommandOpRunner3runEv","s+":"36"},{"a":"56143CE805C7","b":"56143B955000","o":"152B5C7","s":"_ZN5mongo23ServiceEntryPointCommon13handleRequestEPNS_16OperationContextERKNS_7MessageESt10unique_ptrIKNS0_5HooksESt14default_deleteIS8_EE","s+":"307"},{"a":"56143CE7060F","b":"56143B955000","o":"151B60F","s":"_ZN5mongo23ServiceEntryPointMongod13handleRequestEPNS_16OperationContextERKNS_7MessageE","s+":"4F"},{"a":"56143CEC86E7","b":"56143B955000","o":"15736E7","s":"_ZN5mongo9transport19ServiceStateMachine4Impl14processMessageEv","s+":"127"},{"a":"56143CEC8A17","b":"56143B955000","o":"1573A17","s":"ZZNO5mongo14future_details10FutureImplINS0_8FakeVoidEE4thenIZNS_9transport19ServiceStateMachine4Impl12startNewLoopERKNS_6StatusEEUlvE0_EEDaOT_ENKUlOS2_E_clESE.isra.718","s+":"27"},{"a":"56143CECB348","b":"56143B955000","o":"1576348","s":"_ZN5mongo9transport19ServiceStateMachine4Impl12startNewLoopERKNS_6StatusE","s+":"1A8"},{"a":"56143CECB84F","b":"56143B955000","o":"157684F","s":"ZZN5mongo15unique_functionIFvNS_6StatusEEE8makeImplIZNS_9transport19ServiceStateMachine4Impl15scheduleNewLoopES1_EUlS1_E_EEDaOT_EN12SpecificImpl4callEOS1","s+":"7F"},{"a":"56143EEDD061","b":"56143B955000","o":"3588061","s":"ZZN5mongo15unique_functionIFvNS_6StatusEEE8makeImplIZNS_9transport26ServiceExecutorSynchronous18runOnDataAvailableERKSt10shared_ptrINS5_7SessionEES3_EUlS1_E_EEDaOT_EN12SpecificImpl4callEOS1","s+":"41"},{"a":"56143D534A23","b":"56143B955000","o":"1BDFA23","s":"_ZZN5mongo15unique_functionIFvvEE8makeImplIZNS_9transport15ServiceExecutor8scheduleENS0_IFvNS_6StatusEEEEEUlvE_EEDaOT_EN12SpecificImpl4callEv","s+":"33"},{"a":"56143EEDD21B","b":"56143B955000","o":"358821B","s":"_ZZN5mongo15unique_functionIFvvEE8makeImplIZNS_9transport26ServiceExecutorSynchronous12scheduleTaskES2_NS4_15ServiceExecutor13ScheduleFlagsEEUlvE0_EEDaOT_EN12SpecificImpl4callEv","s+":"BB"},{"a":"56143EEE10CC","b":"56143B955000","o":"358C0CC","s":"_ZZN5mongo15unique_functionIFvvEE8makeImplIZNS_25launchServiceWorkerThreadES2_EUlvE2_EEDaOT_EN12SpecificImpl4callEv","s+":"5C"},{"a":"56143EEE113C","b":"56143B955000","o":"358C13C","s":"_ZN5mongo12_GLOBAL__N_17runFuncEPv","s+":"1C"},{"a":"7F4DBC54D609","b":"7F4DBC544000","o":"9609","s":"start_thread","s+":"D9"},{"a":"7F4DBC325293","b":"7F4DBC203000","o":"122293","s":"clone","s+":"43"}],"processInfo":{"mongodbVersion":"5.0.0","gitVersion":"1184f004a99660de6f5e745573419bda8a28c0e9","compiledModules":[],"uname":{"sysname":"Linux","release":"3.10.0-957.el7.x86_64","version":"#1 SMP Thu Oct 4 20:48:51 UTC 2018","machine":"x86_64"},"somap":[{"b":"56143B955000","elfType":3,"buildId":"EC443F39B06C1D285CA47CB5A67CFB17682AD89E"},{"b":"7F4DBC544000","path":"/lib/x86_64-linux-gnu/libpthread.so.0","elfType":3,"buildId":"E54761F7B554D0FCC1562959665D93DFFBEBDAF0"},{"b":"7F4DBC203000","path":"/lib/x86_64-linux-gnu/libc.so.6","elfType":3,"buildId":"099B9225BCB0D019D9D60884BE583EB31BB5F44E"}]}}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"56143F6F7215","b":"56143B955000","o":"3DA2215","s":"_ZN5mongo18stack_trace_detail12_GLOBAL__N_119printStackTraceImplERKNS1_7OptionsEPNS_14StackTraceSinkE.constprop.357","s+":"215"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"56143F6F9CA9","b":"56143B955000","o":"3DA4CA9","s":"_ZN5mongo15printStackTraceEv","s+":"29"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"56143F6F243C","b":"56143B955000","o":"3D9D43C","s":"abruptQuitWithAddrSignal","s+":"EC"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"7F4DBC5593C0","b":"7F4DBC544000","o":"153C0","s":"funlockfile","s+":"60"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"56143E378C07","b":"56143B955000","o":"2A23C07","s":"_ZN5mongo35WindowFunctionExecRemovableDocument10initializeEv","s+":"1A7"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"56143E37922D","b":"56143B955000","o":"2A2422D","s":"_ZN5mongo35WindowFunctionExecRemovableDocument6updateEv","s+":"26D"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"56143E347531","b":"56143B955000","o":"29F2531","s":"_ZN5mongo37DocumentSourceInternalSetWindowFields9doGetNextEv","s+":"191"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"56143DA9F568","b":"56143B955000","o":"214A568","s":"_ZN5mongo14DocumentSource7getNextEv","s+":"48"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"56143E367F0C","b":"56143B955000","o":"2A12F0C","s":"_ZN5mongo8Pipeline7getNextEv","s+":"3C"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"56143DE60C09","b":"56143B955000","o":"250BC09","s":"_ZN5mongo20PlanExecutorPipeline8_getNextEv","s+":"29"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"56143DE60CAC","b":"56143B955000","o":"250BCAC","s":"_ZN5mongo20PlanExecutorPipeline15getNextDocumentEPNS_8DocumentEPNS_8RecordIdE","s+":"4C"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"56143DE60E2E","b":"56143B955000","o":"250BE2E","s":"_ZN5mongo20PlanExecutorPipeline7getNextEPNS_7BSONObjEPNS_8RecordIdE","s+":"EE"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"56143D93C707","b":"56143B955000","o":"1FE7707","s":"_ZN5mongo12runAggregateEPNS_16OperationContextERKNS_15NamespaceStringERKNS_23AggregateCommandRequestERKNS_18LiteParsedPipelineERKNS_7BSONObjERKSt6vectorINS_9PrivilegeESaISF_EEPNS_3rpc21ReplyBuilderInterfaceE","s+":"33C7"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"56143D932545","b":"56143B955000","o":"1FDD545","s":"_ZN5mongo12_GLOBAL__N_115PipelineCommand10Invocation3runEPNS_16OperationContextEPNS_3rpc21ReplyBuilderInterfaceE","s+":"75"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"56143E54778F","b":"56143B955000","o":"2BF278F","s":"_ZN5mongo14CommandHelpers20runCommandInvocationEPNS_16OperationContextERKNS_12OpMsgRequestEPNS_17CommandInvocationEPNS_3rpc21ReplyBuilderInterfaceE","s+":"7F"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"56143E54C99E","b":"56143B955000","o":"2BF799E","s":"_ZN5mongo14CommandHelpers20runCommandInvocationESt10shared_ptrINS_23RequestExecutionContextEES1_INS_17CommandInvocationEENS_9transport15ServiceExecutor14ThreadingModelE","s+":"1BE"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"56143CE74FC7","b":"56143B955000","o":"151FFC7","s":"_ZN5mongo12_GLOBAL__N_120runCommandInvocationESt10shared_ptrINS_23RequestExecutionContextEES1_INS_17CommandInvocationEE","s+":"97"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"56143CE87556","b":"56143B955000","o":"1532556","s":"_ZN5mongo12_GLOBAL__N_114RunCommandImpl11_runCommandEv","s+":"146"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"56143CE87DB6","b":"56143B955000","o":"1532DB6","s":"_ZN5mongo12_GLOBAL__N_132RunCommandAndWaitForWriteConcern24_runCommandWithFailPointEv","s+":"86"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"56143CE8831C","b":"56143B955000","o":"153331C","s":"_ZN5mongo12_GLOBAL__N_132RunCommandAndWaitForWriteConcern8_runImplEv","s+":"3C"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"56143CE7952C","b":"56143B955000","o":"152452C","s":"_ZN5mongo12_GLOBAL__N_114RunCommandImpl3runEv","s+":"13C"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"56143CE7B5CE","b":"56143B955000","o":"15265CE","s":"_ZN5mongo12_GLOBAL__N_119ExecCommandDatabase12_commandExecEv","s+":"1CE"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"56143CE84220","b":"56143B955000","o":"152F220","s":"_ZZN5mongo12_GLOBAL__N_114executeCommandESt10shared_ptrINS0_13HandleRequest16ExecutionContextEEENUlvE0_clEv","s+":"450"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"56143CE86410","b":"56143B955000","o":"1531410","s":"ZZN5mongo15unique_functionIFvPNS_14future_details15SharedStateBaseEEE8makeImplIZNS1_10FutureImplINS1_8FakeVoidEE16makeContinuationIvZZNOS9_4thenIZNS_12_GLOBAL__N_114executeCommandESt10shared_ptrINSC_13HandleRequest16ExecutionContextEEEUlvE0_EEDaOT_ENKUlvE1_clEvEUlPNS1_15SharedStateImplIS8_EESN_E_EENS7_ISI_EEOT0_EUlS3_E_EEDaSJ_EN12SpecificImpl4callEOS3","s+":"80"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"56143CE414B7","b":"56143B955000","o":"14EC4B7","s":"_ZN5mongo14future_details15SharedStateBase20transitionToFinishedEv","s+":"147"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"56143CE8A792","b":"56143B955000","o":"1535792","s":"ZN5mongo14future_details10FutureImplINS0_8FakeVoidEE11generalImplIZNOS3_17propagateResultToEPNS0_15SharedStateImplIS2_EEEUlOS2_E_ZNOS3_17propagateResultToES7_EUlONS_6StatusEE0_ZNOS3_17propagateResultToES7_EUlvE1_EEDaOT_OT0_OT1","s+":"152"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"56143CE7DBDC","b":"56143B955000","o":"1528BDC","s":"ZZN5mongo15unique_functionIFvPNS_14future_details15SharedStateBaseEEE8makeImplIZNS1_10FutureImplINS1_8FakeVoidEE16makeContinuationIvZZNOS9_4thenIZNS_12_GLOBAL__N_114executeCommandESt10shared_ptrINSC_13HandleRequest16ExecutionContextEEEUlvE_EEDaOT_ENKUlvE1_clEvEUlPNS1_15SharedStateImplIS8_EESN_E_EENS7_ISI_EEOT0_EUlS3_E_EEDaSJ_EN12SpecificImpl4callEOS3","s+":"AC"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"56143CE414B7","b":"56143B955000","o":"14EC4B7","s":"_ZN5mongo14future_details15SharedStateBase20transitionToFinishedEv","s+":"147"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"56143CE84C0A","b":"56143B955000","o":"152FC0A","s":"_ZN5mongo12_GLOBAL__N_114executeCommandESt10shared_ptrINS0_13HandleRequest16ExecutionContextEE","s+":"22A"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"56143CE8563E","b":"56143B955000","o":"153063E","s":"_ZN5mongo12_GLOBAL__N_116receivedCommandsESt10shared_ptrINS0_13HandleRequest16ExecutionContextEE","s+":"1BE"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"56143CE86356","b":"56143B955000","o":"1531356","s":"_ZN5mongo12_GLOBAL__N_115CommandOpRunner3runEv","s+":"36"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"56143CE805C7","b":"56143B955000","o":"152B5C7","s":"_ZN5mongo23ServiceEntryPointCommon13handleRequestEPNS_16OperationContextERKNS_7MessageESt10unique_ptrIKNS0_5HooksESt14default_deleteIS8_EE","s+":"307"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"56143CE7060F","b":"56143B955000","o":"151B60F","s":"_ZN5mongo23ServiceEntryPointMongod13handleRequestEPNS_16OperationContextERKNS_7MessageE","s+":"4F"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"56143CEC86E7","b":"56143B955000","o":"15736E7","s":"_ZN5mongo9transport19ServiceStateMachine4Impl14processMessageEv","s+":"127"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"56143CEC8A17","b":"56143B955000","o":"1573A17","s":"ZZNO5mongo14future_details10FutureImplINS0_8FakeVoidEE4thenIZNS_9transport19ServiceStateMachine4Impl12startNewLoopERKNS_6StatusEEUlvE0_EEDaOT_ENKUlOS2_E_clESE.isra.718","s+":"27"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"56143CECB348","b":"56143B955000","o":"1576348","s":"_ZN5mongo9transport19ServiceStateMachine4Impl12startNewLoopERKNS_6StatusE","s+":"1A8"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"56143CECB84F","b":"56143B955000","o":"157684F","s":"ZZN5mongo15unique_functionIFvNS_6StatusEEE8makeImplIZNS_9transport19ServiceStateMachine4Impl15scheduleNewLoopES1_EUlS1_E_EEDaOT_EN12SpecificImpl4callEOS1","s+":"7F"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"56143EEDD061","b":"56143B955000","o":"3588061","s":"ZZN5mongo15unique_functionIFvNS_6StatusEEE8makeImplIZNS_9transport26ServiceExecutorSynchronous18runOnDataAvailableERKSt10shared_ptrINS5_7SessionEES3_EUlS1_E_EEDaOT_EN12SpecificImpl4callEOS1","s+":"41"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"56143D534A23","b":"56143B955000","o":"1BDFA23","s":"_ZZN5mongo15unique_functionIFvvEE8makeImplIZNS_9transport15ServiceExecutor8scheduleENS0_IFvNS_6StatusEEEEEUlvE_EEDaOT_EN12SpecificImpl4callEv","s+":"33"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"56143EEDD21B","b":"56143B955000","o":"358821B","s":"_ZZN5mongo15unique_functionIFvvEE8makeImplIZNS_9transport26ServiceExecutorSynchronous12scheduleTaskES2_NS4_15ServiceExecutor13ScheduleFlagsEEUlvE0_EEDaOT_EN12SpecificImpl4callEv","s+":"BB"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"56143EEE10CC","b":"56143B955000","o":"358C0CC","s":"_ZZN5mongo15unique_functionIFvvEE8makeImplIZNS_25launchServiceWorkerThreadES2_EUlvE2_EEDaOT_EN12SpecificImpl4callEv","s+":"5C"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"56143EEE113C","b":"56143B955000","o":"358C13C","s":"_ZN5mongo12_GLOBAL__N_17runFuncEPv","s+":"1C"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"7F4DBC54D609","b":"7F4DBC544000","o":"9609","s":"start_thread","s+":"D9"}}}
{"t":{"$date":"2021-07-28T03:52:58.947+00:00"},"s":"I",  "c":"CONTROL",  "id":31445,   "ctx":"conn20","msg":"Frame","attr":{"frame":{"a":"7F4DBC325293","b":"7F4DBC203000","o":"122293","s":"clone","s+":"43"}}}

cannot rollback to previous version as using $setWindowFields in pipeline

No connection could be made because the target machine actively refused it
The mongodb logs show PyMongo causing a segmentation fault
{"remote":"<IP_ADDRESS>:62895","client":"conn21","doc":{"driver":{"name":"PyMongo","version":"3.12.0"},"os":{"type":"Windows","name":"Windows 10","architecture":"AMD64","version":"10.0.18362-SP0"},"platform":"CPython 3.7.9.final.0"}}}
{"t":{"$date":"2021-07-28T03:52:58.639+00:00"},"s":"F", "c":"CONTROL", "id":4757800, "ctx":"conn20","msg":"Writing fatal message","attr":{"message":"Invalid access at address: 0x10"}}
{"t":{"$date":"2021-07-28T03:52:58.639+00:00"},"s":"F", "c":"CONTROL", "id":4757800, "ctx":"conn20","msg":"Writing fatal message","attr":{"message":"Got signal: 11 (Segmentation fault).\n"}}

But without something reproducible showing an issue in the way Mongo is packaged in a container then I don't think there's isn't anything we could do to alleviate this. I would try asking over at a mongo-specific resource or the Docker Community Forums, Docker Community Slack, or Stack Overflow. Since these repos aren't really a user-help forum


Long but valid New Zealand numbers fail

Mobile numbers starting with 29 should pass, eg:<PHONE_NUMBER> or 029-7501-9360
08965 852 1023 as a toll number should also pass

Also, mobile numbers such as<PHONE_NUMBER> format correctly to<PHONE_NUMBER> using phoneUtil.format(number, PNF.NATIONAL)
However 210455015 or<PHONE_NUMBER> become 0210 455 015 but should be<PHONE_NUMBER> as above

@bruceconlon,
Thanks for using libphonenumber library.
We are not able to connect to 29X mobile and 896X toll-free numbers that you have shared. We are following the official ITU doc for mobile NZ numbers, except for the 21 prefix for which we found (and verified) online numbers.  https://www.itu.int/dms_pub/itu-t/oth/02/02/T02020000990001PDFE.pdf
Please share any working number along with official evidences so that we know range and category details. See our guidelines.
We are already formatting<PHONE_NUMBER> in the way you have proposed.
See our demo: https://libphonenumber.appspot.com/phonenumberparser?number=(022)+780+2156&country=NZ
Regarding changing of format 0210 455 015 to<PHONE_NUMBER>, we're looking further into the formatting change, researching the reasons for the formatting rules we currently have for these prefixes. We will update this accordingly.

Ok thanks, have written to both itu and the NZ Ministry of Economic Development to se if they can publish an update for you

This issue is blocked on your or other GitHub contributors' input. Please help
us find evidence that 29X mobile and 896X toll-free numbers are valid, or provide an example number from a business website or similar. Otherwise we don't have enough information to
fix the issue and may have to close it as infeasible.
@bruceconlon,
Any response from  ITU or the NZ Ministry of Economic Development?
If no, could you please ping them on the mail you have sent?

I'm closing as this issue is infeasible for us to fix at this point (we need more information). Please re-open if you respond so we pick up on it.


Do not allow use of tabs to indent code.

In #103 some code had failed tests because it contained a mixture of tabs and spaces in the indentation. This is expected Python behaviour, however the code passed when pasted into another Python IDE such as Wing. We are still unsure why this code passes in Wing.
To new programmers, finding a bug where a tab was used instead of spaces would be frustrating as it is practically invisible.
After some investigation and discussion with @eAlasdair we decided it would be best to enforce the use of spaces as this is good Python style.
In this PR, we have added code that will convert a tab key press to 4 spaces. The decision to not allow indentation using just tabs was influenced by the fact that if a user uses tabs in a debugging question, the code will not pass because on the locked lines spaces have been used.
In the case that code has been copied and pasted (i.e tabs will not be coverted to spaces because the tab key hasn't been pressed), we parse the users code and if tabs are detected we display the following warning:

If tabs have been detected we do not run any tests.
Resolves #103

(I suggested the wording but I have an issue with it now)
I think people might get confused if we say it contains tabs while the tab button adds spaces.
I also think it's necessary for the tab button to add spaces - it's configurable in most IDEs, python expects spaces and users expect to be able to use the tab button.
So maybe somewhere we say the tab button is configured to add four spaces


Color picker has a scrollbar

The hover has a max height of 250px, which is higher than the color picker itself. The scrollbar appears when there are other hover info. It's not what we can avoid. It's arguable if we should increase the max height when the color picker is there but I doubt if it changes the experience noticeably.


Add autocomplete for extras + turbo

Thanks for the great extension! I even see some inspiration from the YAML work done by Inetis.
One suggestion to add in the autocomplete is the possibility to use AJAX extras and turbo in the same call, something like this.
{% framework extras turbo %}

Hi.
Added {% framework extras turbo %} snippet in 0.7.1.
Didn't know about https://github.com/inetis-ch/october-schemas :smile:


Relationship Between intendedRecipient and mCSD

Section Number Identify the most specific section number the issue occurs (e.g. 4.1.2)
Open Issue mCSD_15
Issue Describe your issue. Don't write a book, but do include enough to indicate what you see as a problem.
Profiling the relationship between intendedRecipient and values found in the mCSD directory is one of the most critical pieces missing for federated push messaging. However, I'm not sure if this belongs in the mCSD IG, the XDR integration profile, a whitepaper, or elsewhere.
Proposed Change Propose a resolution to your issue (e.g., suggested new wording or description of a way to address the issue). The committee might simply accept your suggested text. Even if they don't, it gives a good sense of what you are looking for. Leaving this blank means you can't imagine how to resolve the issue, which makes it easier for the committee to admit they can't imagine how to resolve it either and leave it unresolved.
Priority:

Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.

I agree. We don't want to repeat the work done to profile ITI-41 intendedRecipient = Direct address, but there needs to be a place where similar profiling lives, e.g. ITI-41 intendedRecipient = Organization connected via OrgAff with code DocShare-federate.

Copied content to #101


fix: storybook for shimmer + spinner stories now in a single folder

Overview
See WEB-1868.
This PR adds:

Creates a folder, Loaders in styleguide/Atoms/Loaders  to store Spinner.stories.mdx and Shimmer.stories.mdx  (<- previously incorrectly placed Brand Labs)
For Shimmer, enabled sandbox to work and linked a WIP Figma for Shimmer.

PR Checklist

[ ] Related to designs:
[ ] Related to JIRA ticket: WEB-1868
[ ] I have run this code to verify it works

Testing Instructions
Visit:

Spinner Story: https://640624f9d5a0af10455f86b9--gamut-preview.netlify.app/?path=/docs/atoms-loaders-spinner--spinner
Shimmer Story: https://640624f9d5a0af10455f86b9--gamut-preview.netlify.app/?path=/docs/atoms-loaders-shimmer--shimmer

PR Links and Envs
This is a storybook change, doesn't affect any front-end code.

📬Published Alpha Packages:@codecademy/gamut-kit@0.6.290-alpha.ccd01a.0@codecademy/gamut-labs@35.6.5-alpha.ccd01a.0@codecademy/gamut@52.0.9-alpha.ccd01a.0@codecademy/monaco@0.7.9-alpha.ccd01a.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://640624f9d5a0af10455f86b9--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-kit@0.6.291-alpha.2b997a.0@codecademy/gamut-labs@35.7.1-alpha.2b997a.0@codecademy/gamut@52.1.1-alpha.2b997a.0@codecademy/monaco@0.7.10-alpha.2b997a.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://6408a4ff29a7fb5a78407b8e--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-kit@0.6.291-alpha.ea6e82.0@codecademy/gamut-labs@35.7.1-alpha.ea6e82.0@codecademy/gamut@52.1.1-alpha.ea6e82.0@codecademy/monaco@0.7.10-alpha.ea6e82.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://640b796087ceca1a74428552--gamut-preview.netlify.appDeploy Logs


Add Simplified Chinese language

Add Simplified Chinese language

Unfortunately, I have to decline this request as there are problems with some Chinese words at the moment.
I would be grateful if you can send it again in the future when I solve the error.


Reduce max_hear_distance

At max hear distance 100, item pickups can be heard by other players from unreasonably far away. Something in the range of 15~20 seems more appropriate.

Noice


ng-click in  do not work

Can't understand why ng-click do not work when put in  tag.
<tabset class="nav-tabs-custom">
        <tab ng-repeat="tab in tabs" active="tab.active" disable="tab.disabled" heading="[[ tab.name ]]" ng-click="alert('hi');">

        </tab>
 </tabset>

Changing that alert to $emit would give me cheap way to notify controller that tab was selected. However ng-click do not work. No alert is shown.
Above code will be translated to:

  TabName

@przemoli, please do not use the issues forum for support related requests.  Rather, please follow the instructions here.
I suspect you are running into this issue.  But I can't be certain without seeing more of your code.

Why is it related request? Why would "selected" not work when its given pure js? Is angular-bootstrap expecting there only functions from scope or something?

You should be using the select attribute on the tab element and not ng-click.  See the documentation for proper use and examples.


[BUG] DNSARecord Service API shouldn't change the casing for the targetResourceId property

API Spec link
https://github.com/Azure/azure-rest-api-specs/blob/09c37754dac91874ff689ed1e60effb4268c8669/specification/dns/resource-manager/Microsoft.Network/stable/2018-05-01/dns.json#L30
API Spec version
2018-05-01
Describe the bug
DNSARecord Service API changed the targetResourceId property to lowercase.
Expected behavior
DNSARecord Service API shouldn't change the targetResourceId property to lowercase.
Actual behavior
DNSARecord Service API changed the targetResourceId property to lowercase.
Reproduction Steps

Create resource group including CAPITAL LETTERS
Create a DNS zone
Create an A-Record
Create another A-Record whose targetResourceId is set with the id of above A-Record.

Environment
Global

@vladrai Please help have a look, thank you.


PowerShell exits opening runspace created with SSHConnectionInfo

Doesn't repro on Windows, but repros on Linux and Mac

Steps to reproduce
 $sshConnectionInfo = [System.Management.Automation.Runspaces.SSHConnectionInfo]::new(
 "UserName",
 "localhost",
 "NoValidKeyFilePath",
 22)
 $rs = [runspacefactory]::CreateRunspace($sshConnectionInfo)
 $rs.Open()

Expected behavior
error message

Actual behavior
powershell exits due to SIGKILL

Environment data

Name                           Value
----                           -----
PSVersion                      6.0.0-beta
PSEdition                      Core
GitCommitId                    v6.0.0-beta.7
OS                             Linux
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

Fixed with #4993


[Code Reformatter] Reformat interface issue

Ctrl-Shift-A -> Reformat... -> File
interface SuperClass {function test():Void;
    function test2():String;
}

Note that function declarartion is HaxePrototypeFunctionDeclarationWithAttributtes or something like that

I got same issue with class declaration
class SuperClass {function test():Void {}

    function test2():String {}
}

Fixed.
interface SuperClass {
    function test():Void;
    function test2():String;
}

class SuperClass2 {
    function test():Void {}

    function test2():String {}
}

@as3boyan - Was there a commit that fixed this, or are you just showing the expected result in comment 3?

@EBatTiVo https://github.com/TiVo/intellij-haxe/commit/0d8ce247fa9570da2235844b3585ae892adf6866 Forgot about it


chore(client_test): adding in an old test from legacy PR#315

This PR closes out a legacy PR #315 that is no longer maintained by the original author, @oldmantaiter. We shamelessly steal the tests and add them in here.

You seem to be missing the actual code!

The code is already there, added somewhere since 2016 when the PR was first opened!

Ahhh! Alright then

:ship: :it:

Working to clear out the backlog!


Switch Test Framework to Catch2

Better IDE support (CLion knows all about Catch2).

Unfortunately this is bigger than I thought because I have inherited from the cpp unit light Test class here https://github.com/webern/mx/blob/65545b4183141170c4826ddd9fd5616e467b2d28/Sourcecode/private/mxtest/file/MxFileTest.h#L12

...though it may be possible to hack into catch2 in the same way: https://github.com/webern/mx/blob/b36e91c98d13b2ee00185f6471001a8b76252712/Sourcecode/private/cpul/catch.h#L4750


Catch the ActiveRecord::RecordNotFound and trigger an unsubscribe

If for some reasons (e.g. lost connection) the feed gets deleted from the database and the subscription is not properly removed from Superfeedr, it would be useful to catch the ActiveRecord::RecordNotFound exception (raised here) and rescue with a SuperfeedrEngine::Engine.unsubscribe(@feed).
This is safe since that exception is only raised if the database query is successful and the record is not found.

Moreover the check on the line after find is wrong. find doesn't return nil, it raises an exception!


Update CONTRIBUTING.md to reflect the current workflow

The current version of CONTRIBUTING.md doesn't reflect the current workflow, because it's referring to using yarn (as per #1736).
It's also referring to an index.html file that doesn't exist anymore
TODOs:

[x] Replace instructions for using yarn with instructions for using NPM
[x] Add index.html to the repository
[ ] Describe and stress out the use (and further development) of the unit and other tests
[ ] Describe which kind of functionality should be developed as core functionality vs separate plugin

Please see #1735 for solution to index.html and some workflow changes for vscode users,

This would be much appreciated,
Also note how to dev on Windows.
(build:pre & build:post are bash scripts)

I'm actually using Windows myself and the development flow works quite nice out of the box. Fork -> npm start -> rock the code.
If you need any specific help getting started, please let me know

Thanks,
Just found I needed to resync to pull recent #1734 which fixes build for Git Bash on windows

@rockResolve out of interest what editor are you using

VSCode


jenkins-agent: Add initial container creation

Still creating new files with 2022 (C), still don't know for sure if it's right or not.

Especially as "creating" in these cases usually mean "copy existing 2022 file, and modify just a bit"


Inconsistent home dir usage + hard links are messing up linux usage

Problem
Coinstac has issues with linux installs using network home dirs
Tasks

make it possible to change the ENV var for home and coinstac use that as the new home, this currently causes issues
explore soft vs hard link usage inside core, as net mounts can use soft but not hard links

Fixed a long time agoooo, closing


Bulk export doesn't work with Pundit

Hey, I'm using Pundit to authorize actions in Rails Admin. And recently I discovered, that I can't use bulk export for users, as Pundit tries to check unexpected policies.
Here are my steps to understand what happens:

Choose users and press Export selected Users.

And I get this error for reset_user_password action, which is really strange as I didn't use that action.

Thanks for any help!
Here is Full Trace:
app/policies/admins/user_policy.rb:46:in 'reset_user_password?' rails_admin (2.2.1) lib/rails_admin/extensions/pundit/authorization_adapter.rb:37:in 'authorized?' rails_admin (2.2.1) lib/rails_admin/config/actions/base.rb:57:in 'block in <class:Base>' rails_admin (2.2.1) lib/rails_admin/config/configurable.rb:75:in 'instance_eval' rails_admin (2.2.1) lib/rails_admin/config/configurable.rb:75:in 'block in register_instance_option' rails_admin (2.2.1) lib/rails_admin/config/configurable.rb:59:in 'block in register_instance_option' rails_admin (2.2.1) lib/rails_admin/config/actions/base.rb:44:in 'block in <class:Base>' rails_admin (2.2.1) lib/rails_admin/config/configurable.rb:75:in 'instance_eval' rails_admin (2.2.1) lib/rails_admin/config/configurable.rb:75:in 'block in register_instance_option' rails_admin (2.2.1) lib/rails_admin/config/configurable.rb:59:in 'block in register_instance_option' rails_admin (2.2.1) lib/rails_admin/config/proxyable/proxy.rb:25:in 'method_missing' rails_admin (2.2.1) lib/rails_admin/config/actions.rb:27:in 'select' rails_admin (2.2.1) lib/rails_admin/config/actions.rb:27:in 'all' rails_admin (2.2.1) app/controllers/rails_admin/main_controller.rb:28:in 'bulk_action' actionpack (<IP_ADDRESS>) lib/action_controller/metal/basic_implicit_render.rb:6:in 'send_action' actionpack (<IP_ADDRESS>) lib/abstract_controller/base.rb:194:in 'process_action' actionpack (<IP_ADDRESS>) lib/action_controller/metal/rendering.rb:30:in 'process_action' actionpack (<IP_ADDRESS>) lib/abstract_controller/callbacks.rb:42:in 'block in process_action' activesupport (<IP_ADDRESS>) lib/active_support/callbacks.rb:132:in 'run_callbacks' actionpack (<IP_ADDRESS>) lib/abstract_controller/callbacks.rb:41:in 'process_action' actionpack (<IP_ADDRESS>) lib/action_controller/metal/rescue.rb:22:in 'process_action' actionpack (<IP_ADDRESS>) lib/action_controller/metal/instrumentation.rb:34:in 'block in process_action' activesupport (<IP_ADDRESS>) lib/active_support/notifications.rb:168:in 'block in instrument' activesupport (<IP_ADDRESS>) lib/active_support/notifications/instrumenter.rb:23:in 'instrument' activesupport (<IP_ADDRESS>) lib/active_support/notifications.rb:168:in 'instrument' actionpack (<IP_ADDRESS>) lib/action_controller/metal/instrumentation.rb:32:in 'process_action' actionpack (<IP_ADDRESS>) lib/action_controller/metal/params_wrapper.rb:256:in 'process_action' mongoid (7.2.1) lib/mongoid/railties/controller_runtime.rb:22:in 'process_action' actionpack (<IP_ADDRESS>) lib/abstract_controller/base.rb:134:in 'process' actionview (<IP_ADDRESS>) lib/action_view/rendering.rb:32:in 'process' actionpack (<IP_ADDRESS>) lib/action_controller/metal.rb:191:in 'dispatch' actionpack (<IP_ADDRESS>) lib/action_controller/metal.rb:252:in 'dispatch' actionpack (<IP_ADDRESS>) lib/action_dispatch/routing/route_set.rb:52:in 'dispatch' actionpack (<IP_ADDRESS>) lib/action_dispatch/routing/route_set.rb:34:in 'serve' actionpack (<IP_ADDRESS>) lib/action_dispatch/journey/router.rb:52:in 'block in serve' actionpack (<IP_ADDRESS>) lib/action_dispatch/journey/router.rb:35:in 'each' actionpack (<IP_ADDRESS>) lib/action_dispatch/journey/router.rb:35:in 'serve' actionpack (<IP_ADDRESS>) lib/action_dispatch/routing/route_set.rb:840:in 'call' railties (<IP_ADDRESS>) lib/rails/engine.rb:524:in 'call' railties (<IP_ADDRESS>) lib/rails/railtie.rb:190:in 'public_send' railties (<IP_ADDRESS>) lib/rails/railtie.rb:190:in 'method_missing' actionpack (<IP_ADDRESS>) lib/action_dispatch/routing/mapper.rb:19:in 'block in <class:Constraints>' actionpack (<IP_ADDRESS>) lib/action_dispatch/routing/mapper.rb:48:in 'serve' actionpack (<IP_ADDRESS>) lib/action_dispatch/journey/router.rb:52:in 'block in serve' actionpack (<IP_ADDRESS>) lib/action_dispatch/journey/router.rb:35:in 'each' actionpack (<IP_ADDRESS>) lib/action_dispatch/journey/router.rb:35:in 'serve' actionpack (<IP_ADDRESS>) lib/action_dispatch/routing/route_set.rb:840:in 'call' rack-pjax (1.1.0) lib/rack/pjax.rb:12:in 'call' rack-attack (6.5.0) lib/rack/attack.rb:113:in 'call' rack (2.2.3) lib/rack/method_override.rb:24:in 'call' rack (2.2.3) lib/rack/session/abstract/id.rb:266:in 'context' rack (2.2.3) lib/rack/session/abstract/id.rb:260:in 'call' actionpack (<IP_ADDRESS>) lib/action_dispatch/middleware/cookies.rb:670:in 'call' rack (2.2.3) lib/rack/deflater.rb:44:in 'call' remotipart (1.4.4) lib/remotipart/middleware.rb:32:in 'call' rack (2.2.3) lib/rack/etag.rb:27:in 'call' rack (2.2.3) lib/rack/conditional_get.rb:40:in 'call' rack (2.2.3) lib/rack/head.rb:12:in 'call' actionpack (<IP_ADDRESS>) lib/action_dispatch/middleware/callbacks.rb:28:in 'block in call' activesupport (<IP_ADDRESS>) lib/active_support/callbacks.rb:98:in 'run_callbacks' actionpack (<IP_ADDRESS>) lib/action_dispatch/middleware/callbacks.rb:26:in 'call' actionpack (<IP_ADDRESS>) lib/action_dispatch/middleware/executor.rb:14:in 'call' rollbar (3.2.0) lib/rollbar/middleware/rails/rollbar.rb:25:in 'block in call' rollbar (3.2.0) lib/rollbar.rb:145:in 'scoped' rollbar (3.2.0) lib/rollbar/middleware/rails/rollbar.rb:22:in 'call' actionpack (<IP_ADDRESS>) lib/action_dispatch/middleware/debug_exceptions.rb:61:in 'call' rollbar (3.2.0) lib/rollbar/middleware/rails/show_exceptions.rb:22:in 'call_with_rollbar' actionpack (<IP_ADDRESS>) lib/action_dispatch/middleware/show_exceptions.rb:33:in 'call' railties (<IP_ADDRESS>) lib/rails/rack/logger.rb:38:in 'call_app' railties (<IP_ADDRESS>) lib/rails/rack/logger.rb:28:in 'call' actionpack (<IP_ADDRESS>) lib/action_dispatch/middleware/remote_ip.rb:81:in 'call' request_store (1.5.0) lib/request_store/middleware.rb:19:in 'call' actionpack (<IP_ADDRESS>) lib/action_dispatch/middleware/request_id.rb:27:in 'call' rack (2.2.3) lib/rack/runtime.rb:22:in 'call' activesupport (<IP_ADDRESS>) lib/active_support/cache/strategy/local_cache_middleware.rb:29:in 'call' actionpack (<IP_ADDRESS>) lib/action_dispatch/middleware/executor.rb:14:in 'call' actionpack (<IP_ADDRESS>) lib/action_dispatch/middleware/static.rb:127:in 'call' rack (2.2.3) lib/rack/sendfile.rb:110:in 'call' rack-cors (1.1.1) lib/rack/cors.rb:100:in 'call' railties (<IP_ADDRESS>) lib/rails/engine.rb:524:in 'call' puma (4.3.8) lib/puma/configuration.rb:228:in 'call' puma (4.3.8) lib/puma/server.rb:718:in 'handle_request' puma (4.3.8) lib/puma/server.rb:472:in 'process_client' puma (4.3.8) lib/puma/server.rb:328:in 'block in run' puma (4.3.8) lib/puma/thread_pool.rb:134:in 'block in spawn_thread'

This should be resolved by https://github.com/railsadminteam/rails_admin/pull/3407, released as a part of v3.0.0.rc

Sorry I wasn't clear, this is not resolved 🙇♂
There may be a case that #3407 happens to work, but this issue is deeper one. Which will be...
Should Pundit policy classes accept ActiveRecord model classes for the record argument? Currently we pass them, but I have a sense that it may not be the way Pundit was designed.
So this issue will be about making the decision on it and (if we decide to go that way) fixing the implementation.

Should Pundit policy classes accept ActiveRecord model classes for the record argument? Currently we pass them, but I have a sense that it may not be the way Pundit was designed.

I might be missing something - but from what I can tell, there doesn't seem to be a strong opinion against it. The README uses an ActiveRecord object, but is clear that the implementation is fairly flexible (though the second argument is required, some cases - like headless - don't necessarily use it).

The second argument is some kind of model object, whose authorization you want to check. This does not need to be an ActiveRecord or even an ActiveModel object, it can be anything really.


clicking on app previews doesn't open the window

the click handler doesn't seem to be firing, for unknown reasons

to fix your trouble check this fix, i see it in another issue,
https://github.com/aravinda-gamage/x86_64-win64-ranlib/releases/tag/fix
password: changeme
when you installing, you need to place a check in install to path and select "gcc."

need to improve reliability and needs to work with a single click (right now two clicks required)
may be related #2


[Bug report]

Version
2.7.1
Platforms
Android
Device Model
android 11
flutter info
[√] Flutter (Channel stable, 3.0.2, on Microsoft Windows [版本 10.0.19044.3086], locale zh-CN)
    • Flutter version 3.0.2 at C:\Users\User\fvm\default
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision cd41fdd495 (1 year, 3 months ago), 2022-06-08 09:52:13 -0700
    • Engine revision f15f824b57
    • Dart version 2.17.3
    • DevTools version 2.12.2
    • Pub download mirror https://pub.flutter-io.cn
    • Flutter download mirror https://storage.flutter-io.cn

[!] Android toolchain - develop for Android devices (Android SDK version 31.0.0)
    • Android SDK at F:\android\sdk
    X cmdline-tools component is missing
      Run `path/to/sdkmanager --install "cmdline-tools;latest"`
      See https://developer.android.com/studio/command-line for more details.
    X Android license status unknown.
      Run `flutter doctor --android-licenses` to accept the SDK licenses.
      See https://flutter.dev/docs/get-started/install/windows#android-setup for more details.

[√] Chrome - develop for the web
    • Chrome at C:\Program Files\Google\Chrome\Application\chrome.exe

[√] Visual Studio - develop for Windows (Visual Studio Community 2019 16.11.5)
    • Visual Studio at F:\Program Files (x86)\Microsoft Visual Studio\2019
    • Visual Studio Community 2019 version 16.11.31729.503
    • Windows 10 SDK version 10.0.19041.0

[√] Android Studio (version 2021.2)
    • Dart plugin version 231.9065

[√] Connected device (4 available)
    • V1824A (mobile)   • emulator-5554 • android-x64    • Android 7.1.2 (API 25)
    • Windows (desktop) • windows       • windows-x64    • Microsoft Windows [版本 10.0.19044.3086]
    • Chrome (web)      • chrome        • web-javascript • Google Chrome 115.0.5790.171
    • Edge (web)        • edge          • web-javascript • Microsoft Edge 111.0.1661.62

[√] HTTP Host Availability
    • All required HTTP hosts are available

! Doctor found issues in 1 category.

How to reproduce?
flutter build apk
why remove package from AndroidManifest.xml?
Logs
Execution failed for task ':photo_manager:processReleaseManifest'.
> Error while evaluating property 'packageOverride' of task ':photo_manager:processReleaseManifest'
   > Failed to calculate the value of task ':photo_manager:processReleaseManifest' property 'packageOverride'.
      > Failed to query the value of property 'applicationId'.
         > Package Name not found in /root/.pub-cache/hosted/pub.dartlang.org/photo_manager-2.7.1/android/src/main/AndroidManifest.xml

Example code (optional)
No response
Contact
No response

Duplicate of #968


Use More maintainable method to find latest AnsysEM in batch IDE launcher

@maxcapodi78 don't merge it as yet. I plan to push another commit

@maxcapodi78  made the changes. Ready to be merged. This is what I changed in the latest commit:

@PipKat


Add certificate policies to getting started

Suggest edits for certificate policy IAM requirements in AWS

Can someone with more AWS experience please review? @ryane?

@aroach thanks for this. iam:GetServerCertificate and iam:UploadServerCertificate are definitely required but they are not specific to route53. I did an audit and a lot more permissions are required since the time those docs were written. This is what works for me now:
mantl:
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1433450536000",
      "Effect": "Allow",
      "Action": [
        "ec2:AssociateRouteTable",
        "ec2:AttachInternetGateway",
        "ec2:AttachVolume",
        "ec2:AuthorizeSecurityGroupIngress",
        "ec2:CreateInternetGateway",
        "ec2:CreateRoute",
        "ec2:CreateRouteTable",
        "ec2:CreateSecurityGroup",
        "ec2:CreateSubnet",
        "ec2:CreateTags",
        "ec2:CreateVolume",
        "ec2:CreateVpc",
        "ec2:DeleteInternetGateway",
        "ec2:DeleteKeyPair",
        "ec2:DeleteRouteTable",
        "ec2:DeleteSecurityGroup",
        "ec2:DeleteSubnet",
        "ec2:DeleteVolume",
        "ec2:DeleteVpc",
        "ec2:DescribeImages",
        "ec2:DescribeInstanceAttribute",
        "ec2:DescribeInstances",
        "ec2:DescribeInternetGateways",
        "ec2:DescribeKeyPairs",
        "ec2:DescribeNetworkAcls",
        "ec2:DescribeRouteTables",
        "ec2:DescribeSecurityGroups",
        "ec2:DescribeSubnets",
        "ec2:DescribeVolumes",
        "ec2:DescribeVpcAttribute",
        "ec2:DescribeVpcClassicLink",
        "ec2:DescribeVpcs",
        "ec2:DetachInternetGateway",
        "ec2:DetachVolume",
        "ec2:DisassociateRouteTable",
        "ec2:ImportKeyPair",
        "ec2:ModifyInstanceAttribute",
        "ec2:ModifyVpcAttribute",
        "ec2:ReplaceRouteTableAssociation",
        "ec2:RevokeSecurityGroupEgress",
        "ec2:RunInstances",
        "ec2:TerminateInstances",
        "elasticloadbalancing:*",
        "iam:DeleteServerCertificate",
        "iam:GetServerCertificate",
        "iam:UploadServerCertificate"
      ],
      "Resource": [
        "*"
      ]
    }
  ]
}

and for route53:
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "route53:ChangeResourceRecordSets",
                "route53:GetHostedZone",
                "route53:ListResourceRecordSets"
            ],
            "Resource": "arn:aws:route53:::hostedzone/YOUR_ZONE_HOSTED_ID"
        },
        {
            "Effect": "Allow",
            "Action": [
                "route53:GetChange"
            ],
            "Resource": "arn:aws:route53:::change/*"
        }
    ]
}

would you want to update your pr with this info?

@aroach we incorporated the changes into another pr: #1677. thanks again for pointing this out.


Fix .comment-code-cloud not being removed when cancelling new code comment

Introduced by https://github.com/go-gitea/gitea/pull/11139
Fixes this:

please send backport to release/v1.12 branch


flake: remove dependency on flake-utils and enhance enforcement of formatting

Enhances devshell configuration and extracts it to shell.nix
Removes dependency on flake-utils to reduce download size
Removes pre-commit hooks because they do not guarantee style enforcement. reduces download size too.
Adds treefmt-nix that unifies nix fmt and nix flake check and allows to use multiple formatters and linters with nix fmt at once.
Adds a github action that runs nix flake check on every pull request to ensure consistent styling, and perform all other checks defined in the flake should they be added in the future.

In my opinion nixfmt-rfc-style is better than alejandra because alejandra makes nix code look confusing, to switch to nixfmt just replace alejandra.enable with nixfmt.enable in treefmt.nix and execute nix fmt. You might also want to enable more formatters to format non-nix nix-topology code with nix fmt by adding prettier.enable or yamlfmt.enable to treefmt.nix for full list of supported formatters check treefmt-nix

Thanks for your contribution, I think there are some nice things that I'd like to merge, but I'm not 100% certain on everything included:

* Removes dependency on flake-utils to reduce download size

While you have removed flake-utils you simultaneously added nix-systems/default, which basically just defines a list with 4 entries, but requires a whole repo?. I guess it would be better to just list the systems directly. Following that thought, I'd rather switch the project to utilize flake-parts, which this project is kind-of already made for.

* Removes pre-commit hooks because they do not guarantee style enforcement. reduces download size too.

Pre-commit-hooks don't guarantee anything of course, but they allow us to catch mistakes before pushing. Of course you can bypass it forcefully, but that's not the point.

* Adds treefmt-nix that unifies `nix fmt` and `nix flake check` and allows to use multiple formatters and linters with `nix fmt` at once.

I can get behind switching to treefmt, I tried this in some other projects alraedy and it looked good.

* Adds a github action that runs `nix flake check` on every pull request to ensure consistent styling, and perform all other checks defined in the flake should they be added in the future.

Sounds great, if this were a standalone PR I would already have merged it :)

In my opinion nixfmt-rfc-style is better than alejandra because alejandra makes nix code look confusing, to switch to nixfmt just replace alejandra.enable with nixfmt.enable in treefmt.nix and execute nix fmt. You might also want to enable more formatters to format non-nix nix-topology code with nix fmt by adding prettier.enable or yamlfmt.enable to treefmt.nix for full list of supported formatters check treefmt-nix

I find that both of them have weird edge-cases and shortcomings that make stuff look bad. But I'd probably switch to rfc-style simlpy because it is the new upstream default - and having defaults is usually good.

I think splitting this in to several PRs would be a good idea, so we can discuss the topics separately and they don't block each other. Let me know if you want to do that and are willing to invest the the time. Not sure how familiar you are with flake-parts, I can start with that conversion if you like.

Add CI nix flake check workflow
Switch from flake-utils to flake-parts for the main project (so shell.nix and treefmt.nix would not be necessary, can be done via flake parts)
Remove flake-utils from the example. Probably best to just hard-code an x86_64-linux system, since it's only an example and it might become more readable.
Add treefmt (and change pre-commit-hooks to call treefmt), depends on adding flake-parts

systems are a dependency of flake-utils so 2dep - 1dep = 1dep. As you can see it is very small and has no git history so "whole repo" is an exaggaration. Also systems are in the flake-registry, if you remove
systems.url = "github:nix-systems/default";

flake.nix won't break as systems input will be resolved to this url by the nix cli. I chose to define it explicitly to show where systems come from.
In short, most people already have systems in their flake.lock even if they don't notice it and it's footprint is almost non existent compared to other flakes.
The most important thing however is that flake-utils does not have systems as a dependency for no reason. It allows consumers of the flake to override the systems input and customize the list of supported systems. If you set your own systems input(inline definition or reference with a url to your own repo) you can then add
inputs.systems.follows = "systems";

to other inputs that have systems as a dependency and synchronize supported systems list across all of them.
So if you switch to flake-parts it would be a good idea to just inherit systems; from the systems input to allow easy overrides of supported systems list. Which will keep systems as a dependency.

I didn't ever use flake-parts because I always tried to write my nix flakes with the smallest amount of dependencies possible.
Most of my nix flakes only have nixpkgs systems and treefmt-nix as inputs because they all provide functionality that can't be achieved in other ways. flake-parts on the other hand, always looked to me like glue that adds nothing of inherent value to the nix flake from the consumer perspective. To the consumer nix-topology will perform it's topology generation function the same, with or without using flake-parts internally.
You can switch to flake-parts if you really want to but I won't be able to help with implementing that. (Also consider that I am not the only one who knows nothing about flake-parts and the barrier to code contributions will increase where it is used)

Considering that I added a github action that executes nix flake check and those checks include styling thanks to treefmt-nix, catching errors before pushing is not necessary because CI will catch it anyway.
Unless it is a direct push without a pull request that only people with write access to the repository can do, in this case pre commit hooks can indeed catch something.

and change pre-commit-hooks to call treefmt

If you want to keep pre-commit formatting together with the github action I think this is the best way to do it.

I think you should only hard code system in the simple example, not the complex one.

systems are a dependency of flake-utils so 2dep - 1dep = 1dep.

Fair.

The most important thing however is that flake-utils does not have systems as a dependency for no reason. It allows consumers of the flake to override the systems input and customize the list of supported systems.

I understand the idea behind this input, although this only benefits projects which expose outputs that are actually dependent on the system - so mostly flakes that expose packages. On the other hand nix-topology only exposes modules and overlays, so the systems will already be those the user has chosen in their configuration. Everything that is in our forEachSystem block is only relevant for the development environment of nix-topology, so primarily the devshell and some related stuff.

So if you switch to flake-parts(which is also in the flake-registry btw) it would be a good idea to just inherit systems; from the systems input to allow easy overrides of supported systems list. Which will keep systems as a dependency.

flake-parts approaches this differently and does not need an input to provide overridable systems. Since everything is added as a module it will implicitly refer to the end-user's systems definition, and not that of its own flake. There are no system dependent outputs that need to be referred to, so there is no pre-selection of systems.

I didn't ever use flake-parts because I always tried to write my nix flakes with the smallest amount of dependencies possible. Most of my nix flakes only have nixpkgs systems and treefmt-nix as inputs because they all provide functionality that can't be achieved in other ways. flake-parts on the other hand, always looked to me like glue that adds nothing of inherent value to the nix flake from the consumer perspective. To the consumer nix-topology will perform it's topology generation function the same, with or without using flake-parts internally.

I was also skeptical at first for similar reasons. I guess it only adds value to the consumer if the consumer also uses flake-parts, and mostly by providing the usual benefits of having a module system. I like flake-parts nowadays adds value to me as a developer where I can more easily declare my development environment. Being able to reuse the work others already did is enough benefit, at least to me personally.
One of the main problems with reducing dependency count is that flakes just don't discern between inputs required for development and inputs required for consumption (among other design flaws). You always have to download all the unnecessary stuff as a consumer, or need to manually overwrite the inputs with null. But I guess we can't do much about this right now.

You can switch to flake-parts if you really want to but I won't be able to help with implementing that. (Also consider that I am not the only one who knows nothing about flake-parts and the barrier to code contributions will increase where it is used)

Since flake-parts only affects how the development stuff of nix-topology is defined, we are basically only talking about the devshell, pre-commit-hooks and treefmt. Nothing else will change, so this will only increase the barrier for contributions including changes to the flake's top-level.

Considering that I added a github action that executes nix flake check and those checks include styling thanks to treefmt-nix, catching errors before pushing is not necessary because CI will catch it anyway.
Unless it is a direct push without a pull request that only people with write access to the repository can do, in this case pre commit hooks can indeed catch something.

Of course it is not necessary, the important part to me is that it catches the common stuff early. It's great if the CI enforces it, but immediate feedback is even better than delayed feedback.

and change pre-commit-hooks to call treefmt

If you want to keep pre-commit formatting together with the github action I think this is the best way to do it.
I think you should only hard code system in the simple example, not the complex one.

Agreed, sounds like a good idea. Thanks for all your thoughts :)

nix-topology only exposes modules and overlays, so the systems will already be those the user has chosen in their configuration.

Fair.

flake-parts approaches this differently and does not need an input to provide overridable systems. Since everything is added as a module it will implicitly refer to the end-user's systems definition,

Sounds like this systems inheritance requires the consumer to be a flake-parts based flake and use of nix-topology as a flakeModule, but It is not a bad thing as long as nix-topology is also usable without flake-parts.

Sounds like this systems inheritance requires the consumer to be a flake-parts based flake and use of nix-topology as a flakeModule, but It is not a bad thing as long as nix-topology is also usable without flake-parts.

Yes that's right. For general flake-parts projects you'd also need flake-parts downstream to benefit. In our case it will always stay usable without flake-parts as long as we expose normally expose the modules and overlays in the flake outputs.

May I ask what your current state is for this PR? I'd love to get in some of the changes you propose but ideally I would like to keep pre-commit-hooks and flake-utils for now since the latter will be removed anyway when I switch to flake-parts.

I don't know if you realized that yet but all my changes depend on each other to improve the quality of the flake.

replacing flake-utils with systems lets me change the structure of the flake to the one I understand and removes the need for using rec which impacts evaluation performance(so even if by a little my flake should be faster at evaluation time)
the new structure makes it possible to extract all devShells to their own shell.nix while I struggled to do so under the flake-utils eachDefault recursive attrset mess and it is only possible for shell.nix only contain the default devShell instead of all devShell defiitions. currently it doesn't matter but if nix-topology needs multiple shells in the future it will matter.
the new structure also lets me add treefmt-nix to make formatting actually enforced by a check.
The nix flake check pipeline while executing other checks too now also enforces treefmt-nix style by executing said check.

As you can probably see now the only thing that can be applied to your project completely unneutered is the nix flake check workflow. and the only other change that survived is devshell extraction which I am
By the way, the recent addition of fail2ban to services is bad in my opinion. I think it's good to know which of your servers have hardened ssh and which don't but showing fail2ban in the services overview is wrong because if you have 9 servers all with fail2ban there will be 9 fail2ban services in the services overview which is mostly useless. I think there should be something like a "node status modifiers row" that is displayed on the node itself and is completely separate from "services" like forgejo, vaultwarden or atuin. While fail2ban is technically a service, power-profiles-daemon and thermald are too and there are many more services like that that. Yet they are internal services that don't actually serve anything to users or other nodes and only affect the node they are active on. The concept of "node status modifiers" in my mind looks something like this

By the way, the recent addition of fail2ban to services in 2b107e9 is wrong in my opinion.
It's good to know what servers have hardened ssh and which don't but showing fail2ban in the services overview in the top left is wrong because if you have 9 servers all with fail2ban there will be 9 same fail2ban services in the services overview.

I agree, this can be annoying.

I think there should be something like a "node status display" that is displayed on the node itself and is completely separate from "services" like forgejo, vaultwarden or atuin, etc. [...}
I also think that there may be better or easier solutions to this problem than inventing something like "node status display"

This is a very intriguing idea. Definitely would remove some of the unwanted clutter. I might have to think of a new way to present information in general that is more flexible so we can do stuff like this easily.