Release: 2.5.1

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

Is anything blocking the update?


Maintenance Page CSS and IMG fixes

Changing the CSS and Img tag ref's to static instead of relative.  Due to the way S3 and Cloudfront handle routing the original URL does not change when Cloudfront returns a redirect.  For example /en/login does not exist on S3/Cloudfront so it returns the default en.htm page however the url remains /en/login.  This breaks all of the relative paths in the htm file file.  By changing to static it will ensure that the CSS and Img's always render no matter what non-existant URL is passed in.
If there is a better solution I'm all ears!!  👂

This means we'll have to change the relative links on the production site, eh?

This means we'll have to change the relative links on the production site, eh?

Yes unfortunately, we'll have to changes the links for the Production specific URL as well.


Remove "deleted widget" notification when changing column on animated layers

When you change the column, a message appear saying that we deleted your widget. This is actually true because we remove it from the UI but I'd rather not show that notification due you're not removing anything.

+1

Fixed in https://github.com/CartoDB/cartodb/pull/9239/commits/9d537faa2969cf62e369aa4a471d6942438e4a6b


allow optionally specifying users by their user id

added mini-feature: allow specifying users by their gitlab user-id
disclaimer: never coded anything in go...

@wischhof I have included your idea to #26
With #26 it is not necessary to prefix the GitLab User ID with id:. If the user specification is an int, it will be used as User ID. Could you please try it.

I am closing this one. Thanks for your work and the idea!

@wischhof I have included your idea to #26
With #26 it is not necessary to prefix the GitLab User ID with id:. If the user specification is an int, it will be used as User ID. Could you please try it.

Works perfectly! 👍


[PAGE ISSUE] Mint with NFT.storage and Polygon HardhatError: HH110: Invalid JSON-RPC response received: error code: 1020

Hello guys, thank you for your guide on how to mint nfts on polygon. Till deploying the smart cotnract everything works fine but when I do npx hardhat run scripts/deploy-contract.mjs --network PolygonMumbai
the following error occurs:
HardhatError: HH110: Invalid JSON-RPC response received: error code: 1020
Do you know what to do? That would be amazing!

@itsPiyushMaheshwari would you mind looking into this?

Please try with dedicated rpc like Alchemy, infura etc.
On Fri, 13 May, 2022, 22:24 Pancy, @.***> wrote:

@itsPiyushMaheshwari https://github.com/itsPiyushMaheshwari would you
mind looking into this?
—
Reply to this email directly, view it on GitHub
https://github.com/protocol/nft-website/issues/243#issuecomment-1126257041,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQXDLMHWOH6UN7REH3A6TM3VJ2CKXANCNFSM5VLUIFMA
.
You are receiving this because you were mentioned.Message ID:
@.***>


Stricter build settings

Caught during an internal sync where we have mismatched return types enabled. There might be other build settings that we are missing. Any ideas?

Mismatched return types
Unused parameters

explicit case for each enum in switch statements (found in #196)


Add more details to docs

In order to be able to merge #1343 with the restructuring that was already done, here's a record of the things we still want to add:

pointer shenanigans for Duplicated(x, dx) with typeof(x) != typeof(dx) => https://github.com/EnzymeAD/Enzyme.jl/pull/1343#discussion_r1532933852
discussion on sparse and structured arrays => https://github.com/EnzymeAD/Enzyme.jl/pull/1343#issuecomment-2013169530
GPU and friends => https://github.com/EnzymeAD/Enzyme.jl/pull/1343#discussion_r1532937548

Closing as PR's have landed


Missing File Recommended by Governance

This repo is missing: Repo Admins Accept Content Reports
This document is Recommended per OSC Governance. https://intersect.gitbook.io/open-source-committee/policies/governance

There is not any current requirement or push to include this. Closing issue.


Docker support

Are there any plans of having an official Hubot docker image?

I suspect it will come. In the while you can check #1271 there are some examples of existing Dockerfiles.

As a user, what would you expect from a hubot docker image?
To me, the benefit of hubot is being super customized to your usage, so I am having a hard time thinking of a super generic image. It could be possible to make a base image (that is mostly just the nodejs environment) that knows how to run hubot in general, and you inherit from that to include your specific bot's dependencies and scripts.

Yes I think that's what makes sense. Like a raw freshly made hubot-generator containerized and that can be customized or inherited.

One interesting scenario would be to publish each Hubot script with a Dockerfile declaring the services it depends on (and various parts of Hubot being broken into services where it makes sense). This isn't a 1:1 example, but @probot was designed to allow plugins to run stand-alone, or grouped together in the same instance.
I haven't fully through through how all this would work, so it might be nonsense.

I haven't done much with docker, so maybe this is naive, but this is what I am thinking for docker support:

base hubot image:

include node environment (ie inherit from an existing one)
know's how to launch hubot, ie bin/hubot

templated

npm install's local package.json to get dependencies (either for script packages or local script's dependencies)
includes the scripts (and other?)  in the working directory

There is also the issue of where to host the Dockerfile. There are typically two strategies:

Within the project's source code (at the root of the project). In this case, the docker build would use the current project as the context for the image.
In a separate repo. In this case, the Dockerfile would need to download specific releases depending on the image tag to have a one-to-one match with the github release versions (git tags) and the docker images.

Option 1. is typically the easiest to setup and maintain, however, there are some use cases where you would need 2..

@rqc thanks for the info!

however, there are some use cases where you would need 2..

Can you think of any general cases for that? Or specific projects that have needed to do it that way?

@technicalpickles I have seen this mostly on repositories for official docker images. These are docker images for projects that have been somewhat curated or gone through a special process between the project owners and Docker, Inc. Here are some examples:

docker images for node
redis

One particularity, is that instead of using git tags to version the images, the Dockerfiles are namespaced in folders (e.g. v3.0/Dockerfile).
I've also seen this used mostly in projects in which the build process yields a binary executable (e.g. *.jar, *.war, etc) and the source code is not necessary to run the program. This is not the case with hubot since we need the source code to be included in the docker image.

I learned some docker things 😅  However, I am still thinking about this:

To me, the benefit of hubot is being super customized to your usage, so I am having a hard time thinking of a super generic image. It could be possible to make a base image (that is mostly just the nodejs environment) that knows how to run hubot in general, and you inherit from that to include your specific bot's dependencies and scripts.

On docker hub, there are a few hubot images, which generate a bot (via yo) as part of their processing:

https://hub.docker.com/r/rplan/hubot/
https://hub.docker.com/r/rewardle/hubot/
https://hub.docker.com/r/cataska/hubot-slack/

With these, you could plausibly mount a volume to the scripts directory to have user-defined scripts. You would not be able to install dependencies for them though.
Plausibly you could inherit from these images to populate the scripts yourself, and have a package.json specifically for them that is npm installed as part of image building. That starts to seem a little weird from a node-load-path perspective, but might be doable. That also wouldn't account for script packages though.
Maybe an inheriting image could just replace the package.json with their own, and re-install? Would that take away some of the usefulness of a hubot image?
Also for reference, I made a Dockerfile for a recently created hubot, and it was super straightforward:
FROM node:4.8.4

WORKDIR /app

COPY package.json package.json
RUN npm install

COPY . .

EXPOSE 8080
CMD ["npm", "start", "-s"]

@technicalpickles
-COPY . . will copy the package.json as well, so the COPY package.json package.json might be redundant.

Docker build will create a new image layer for each statement in the Dockerfile and this adds to the size of the image. So, it is important to consolidate statements as much as possible.
Clean the npm cache after running npm install in the same RUN statement.
Add a .dockerignore file which follows the same conventions as a gitignore to reduce the context that is sent to the docker API during build.
I would recommend using alpine based images which are smaller than debian based images.

I would also consider the use case of extending an image from the base hubot image that will point hubot to read from a local integration using HUBOT_SCRIPTS env var. This is useful for integrations that are not open source and not published through github/ npm.org.

COPY . . will copy the package.json as well, so the COPY package.json package.json might be redundant.
Docker build will create a new image layer for each statement in the Dockerfile and this adds to the size of the image. So, it is important to consolidate statements as much as possible.

The reason for splitting out package.json is to build the layer that requires a potentially slower npm install (plus a cache clear as you suggested) separate from copying everything else. If you are actively developing a bot, you wouldn't want every change to a script to cause this part to be rebuilt.

Clean the npm cache after running npm install in the same RUN statement.

That makes sense, and I've seen that pattern. I just threw this one together in like 20 minutes 😅

I would recommend using alpine based images which are smaller than debian based images.

It seems that most docker images have both a debian-based and an alpine based image. I think there's value in still having a debian based image, because most instructions you see for getting packages running are more likely to have debian-based instructions than alpine ones.


Invalid only_if check in client.rb recipe for add org validator key

Hi,
I'm trying to configure a Chef server configuration to run as a client of hosted chef. I've uploaded my data bags and configured the recipe. All goes well until I hit this block:
execute 'add org validator key' do
command "chef-server-ctl add-client-key #{client} #{client}-validator #{key_file} --key-name populator"
only_if pub_key
not_if "chef-server-ctl list-client-keys #{client} #{client}-validator | grep '^key_name: populator$'"
end
The problem appears to be that chef tries to execute a command with the same name as the value of the pub_key attribute, so I'm thinking this check needs changing. This is the error (with the public key changed to <pub_key string> for brevity:
[2015-04-22T23:42:36+00:00] INFO: Processing execute[Guard resource] action run (dynamically defined)
================================================================================
Error executing action `run` on resource 'execute[add org validator key]'
================================================================================

Errno::ENOENT
-------------
execute[Guard resource] (dynamically defined) had an error: Errno::ENOENT: No such file or directory - <pub_key string>

Resource Declaration:
---------------------
# In /var/chef/cache/cookbooks/chef-server-populator/recipes/client.rb

 79:           execute 'add org validator key' do
 80:             command "chef-server-ctl add-client-key #{client} #{client}-validator #{key_file} --key-name populator"
 81:             only_if pub_key
 82:             not_if "chef-server-ctl list-client-keys #{client} #{client}-validator | grep '^key_name: populator$'"
 83:           end
 84:           execute 'remove org default validator key' do

Compiled Resource:
------------------
# Declared in /var/chef/cache/cookbooks/chef-server-populator/recipes/client.rb:79:in `block in from_file'

execute("add org validator key") do
  action "run"
  retries 0
  retry_delay 2
  default_guard_interpreter :execute
  command "chef-server-ctl add-client-key indochino indochino-validator /var/chef/cache/indochino.pub --key-name populator"
  backup 5
  returns 0
  declared_type :execute
  cookbook_name "chef-server-populator"
  recipe_name "client"
  not_if "chef-server-ctl list-client-keys indochino indochino-validator | grep '^key_name: populator$'"
  only_if "<pub_key string>"
end

[2015-04-22T23:42:36+00:00] INFO: Running queued delayed notifications before re-raising exception
[2015-04-22T23:42:36+00:00] INFO: execute[nxensite default] sending reload action to service[nginx] (delayed)
Recipe: nginx::default

service[nginx] action reload[2015-04-22T23:42:36+00:00] INFO: Processing service[nginx] action reload (nginx::default line 24)
[2015-04-22T23:42:37+00:00] INFO: service[nginx] reloaded

reload service service[nginx]

Running handlers:
[2015-04-22T23:42:37+00:00] ERROR: Running exception handlers
Running handlers complete
[2015-04-22T23:42:37+00:00] ERROR: Exception handlers complete
[2015-04-22T23:42:37+00:00] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
Chef Client failed. 8 resources updated in 92.805395909 seconds
[2015-04-22T23:42:37+00:00] INFO: Sending resource update report (run-id: c3796f02-9907-43ad-930b-2fd50ce398d9)
[2015-04-22T23:42:37+00:00] ERROR: execute[add org validator key] (chef-server-populator::client line 79) had an error: Errno::ENOENT: execute[Guard resource] (dynamically defined) had an error: Errno::ENOENT: No such file or directory - <pub_key string>
Chef client version is 12.2.1

Looks like guards that run ruby need to be enclosed in {}

Oooh snap wrong repo, sorry >.<


Matrix service integration with Data Browser

This needs to be scoped but users would expect integration

@briandoconnor status on this?

Update from 8/27 meeting with @mckinsel, @brianraymor and @NoopDog:

Marcus has pull request for mock API out for review (https://github.com/HumanCellAtlas/matrix-service/pull/28)
"Version 0" (targeted for demo in Oct) will not require any user-specified inputs; output file will be concatenated matrices only (very useful for SmartSeq2 one cell/bundle inputs)
MatrixRequest "post" json will contain bundle fqids as input
MatrixFormat ("zarr", "parquet", "loom", "anndata", "singlecellexperiment") will use default value for Version 0
MatrixRequest API reply will return a "request ID" and "key" (eventually will be a link url to results)
Matrix "get" API to poll for completion status by providing "request ID"
need secondary analysis bundles generated by green box to test with (currently not present in prod)
TBD: call Matrix service APIs directly from browser or via azul webservice?

@brianraymor said "Hi Brian - Wanted to call your attention to the outcome of the Matrix-Portal discussion yesterday which eliminates handoff - https://app.zenhub.com/workspace/o/humancellatlas/data-browser/issues/9 - since you had a number of related comments in the Matrix Service charter."
Does this mean this ticket is no longer on the roadmap?
I understand if this can't be done via the Data Browser since it's async.  Until there's a user login and state saved for a user that could associate their account with matrix service jobs running.  But is a temp workaround having a manifest file from the Orange Box Data Browser be used by the HCA command line to generate a matrix?  Could the portal at least generate a URL for the running matrix job and hand that back to the user?

@NoopDog Please review Marcus' PR for the Matrix API.

Skin complete - API TBC

Use .zarray file type in links.json metadata in bundle to indicate presence of matrix-able data.
Select matrix files in Data Browser to enable "Matrix Service".
Request manifest returns url in response that can be passed to Matrix Service.


[Bug] Link goes to a protected google document

Describe the bug
In this file: https://github.com/project-chip/certification-tool/blob/main/docs/Matter_User_Guide/Matter_User_Guide.md
There is a link to this document: https://docs.google.com/document/d/1bYDjmGrj6dPnu0KHoVRaDF7YhsFzGslw/edit#heading=h.wkkktfl30jjn

Closing!


Graphic walker visualization color schema custom change

I have a data set with coordinates and signal level values for each coordinates. When I display it in geographic view, I assign to color for each specific group. However I cannot select the color individually, I need to select a color schema. Even I select the the color schema it does not assign the same colors, it sorts the values based on counts then assigns the colors based on this sorting. How can I assign specific color to each individual range? I need quick help to guide me through that project, any help appreciated.

Hi @barbarosyabaci
I'm not sure if this answers your question.

Thanks for answer but I want to adjust colors individually like that:
def categorize_colors(value):
match value:
case value if value >= 25:
return [0, 0, 255]    # Blue
case value if value >= 20:
return [75, 0, 130]   # Indigo
case value if value >= 15:
return [138, 43, 226] # BlueViolet
case value if value >= 10:
return [218, 112, 214] # Orchid
case value if value >= 5:
return [255, 105, 180] # HotPink
case value if value >= 0:
return [255, 69, 0]    # OrangeRed
case value if value >= -2:
return [255, 0, 0]    # Red
case _:
return [128, 0, 0]    # Maroon


Dynamic codelists not working in repeatable groups.

Description
Initially i wanted to have a dynamic codelist on a checkbox-component based on data selected in a radiobutton. Both of these components is inside a nested repeatable group. I tried to do this like this:
"optionsId": "injuries",
"mapping": {
  "Victims{0}.Injuries{1}.BodyPart": "bodypart"
}

But it seems like this is not supported.
While i was experimenting with this i noticed that this still don´t work even if i used data that was not nested as input to the OptionsProvider, like this:
"optionsId": "injuries",
"mapping": {
  "Remarks": "bodypart"
}

I´m not sure if i should have reported this as a feature request instead as it seems like dynamic codelists in nested repeatable groups is not supported. That is what we initially want to do..
To Reproduce

Set up a layout where there are components with dynamic codelists in repeatable groups:

{
  "$schema": "https://altinncdn.no/schemas/json/layout/layout.schema.v1.json",
  "data": {
    "layout": [
      {
        "id": "test",
        "type": "RadioButtons",
        "textResourceBindings": {
          "title": "TEST (Damaged bodypart)"
        },
        "dataModelBindings": {
          "simpleBinding": "Remarks"
        },
        "optionsId": "bodyParts",
        "required": true
      },
      {
        "id": "test-checkbox",
        "type": "Checkboxes",
        "textResourceBindings": {
          "title": "Test checkbox"
        },
        "dataModelBindings": {
          "simpleBinding": "Submitter.Firstname"
        },
        "required": true,
        "optionsId": "injuries",
        "mapping": {
          "Remarks": "bodypart"
        }
      },
      {
        "id": "victimGroup",
        "type": "Group",
        "dataModelBindings": {
          "group": "Victims"
        },
        "maxCount": 20,
        "children": [
          "test-checkbox-in-group",
          "injuryGroup"
        ],
        "textResourceBindings": {
          "add_button": "addNewPerson"
        }
      },
      {
        "id": "test-checkbox-in-group",
        "type": "Checkboxes",
        "textResourceBindings": {
          "title": "Test checkbox in group"
        },
        "dataModelBindings": {
          "simpleBinding": "Submitter.FirstName"
        },
        "required": true,
        "optionsId": "injuries",
        "mapping": {
          "Remarks": "bodypart"
        }
      },
      {
        "id": "injuryGroup",
        "type": "Group",
        "children": [
          "test-checkbox-in-group-in-group"
        ],
        "maxCount": 10,
        "dataModelBindings": {
          "group": "Victims.Injuries"
        }
      },
      {
        "id": "test-checkbox-in-group-in-group",
        "type": "Checkboxes",
        "textResourceBindings": {
          "title": "Test checkbox in nested group"
        },
        "dataModelBindings": {
          "simpleBinding": "Submitter.Firstname"
        },
        "required": true,
        "optionsId": "injuries",
        "mapping": {
          "Remarks": "bodypart"
        }
      },
      {
        "id": "73a3192c-16d2-4e4a-834a-08a29ec1cfef",
        "type": "NavigationButtons",
        "textResourceBindings": {
          "next": "next",
          "back": "back"
        },
        "dataModelBindings": {},
        "showBackButton": true
      }
    ]
  }
}

Change the data used as input for the OptionsProvider.

Expected behavior
All checkbox components should change codelists based on the input.
Screenshots

Additional Info

Relevant slack discussion
Link to app where we want to implement dynamic codelist based on input from radiobuttin in the same nested group.(on the last commit when this is published)
We want the behavior of the "Test checkbox" in the GIF above in the nested group demonstrated below ↓

Tested ok for demo app and implementation in own test-app 🥇


Enrollment total is off

Many classes can end up having negative or much smaller than actual enrollment totals

should be fixed by #11


Added links between pages

Created links between each respective tutorial page to streamline the installation process a bit more.

Not sure I did this right. @jhsu802701 You reading this?

Create a .gitignore file and add .DS_Store to it.  (At the moment, your pull request adds this file.)
In chapter 2, add a link to chapter 3.
In chapter 4, add a link to chapter 5.
In chapter 5, add a link to chapter 6.
In chapter 6, add a link to chapter 7.
In chapter 7, add a link to chapter 8.

All of this was done in the initial pull request.
Need anything else?


toAst and fromAst are not identity operation

Bug Report 🐛
toAst and fromAst are not identity operation.
Expected Behavior
Ideally, toAst and fromAst should be identity operation.
Current Behavior
They result in a model with contents as undefined

The culprit here is that while fromAst populates the manager with model files, it doesn't provide definitions. However getModels relies on definitions being there.
Otherwise fromAst and getAst operations are identity.

I'm not sure this is a bug. In your REPL, the first time you run you are creating an AST from CTO, so the CTO text is also added to the ModelManager. In your second run you just add the AST to the ModelManager and the CTO is not present.
The CTO text is not used by the ModelManager, it is preserved purely for debugging, if added. Hence the definitions is optional in the ModelFile constructor.

@mttrbrts perhaps we should drop support for addModel / addCTOModel take a CTO string in ModelManager for v4? This would make concerto-core independent of CTO parser (saving memory and module size).

I agree with that.
Perhaps the confusion stems from getModels returning the CML content? What should the behaviour be if a ModelManager doesn't know about the CML? To only list the namespaces, perhaps?


Would be nice to know what violations are found.

Currently this action only says "you got something wrong" and it leaves it up to you to figure out what. It would nice if it would report what part of the spec it's complaining about.
Like if the PR title is disable a flaky test it would be nice if the action somewhere listed that it's in violation because it's missing the <type>: prefix instead of leaving it up to the user to guess about what's not right.

The way the check is structured, in general, is to see if the title matches at least one template out of the many specified (via regex and/or prefixes). A failing test indicates that the current title does not match any valid template. I don't see how we could give a suggestion here? I do like the idea but the only feedback I can think of is listing out all valid templates and then say that the current one does not match any of them.

Folks, I was wondering if a custom message in the output would do the job. e.g.

"Please check the docs at http://mydocs.com/pr-title-conventions"
"Here are some valid titles: 123-abcd-xyz, [123] abcd-xyz"

Not enough magical as it demands some glue work, but perhaps that's all that's needed 🤷♂


fix: link to repo on npm

:tada: This PR is included in version 1.2.2 :tada:
The release is available on:

GitHub release
npm package (@latest dist-tag)

Your semantic-release bot :package::rocket:


MongoDB problem

Description
I using MongoDB as permissions storage and after any re-importing of database all permissions are not working. I even can't connect server. If I removing MondoDB LuckPerms database and LuckPerms plugin creating it's database by itself and I configuring permissions again (from scratch), all working fine again. So I can't migrate my database and I required to recreate it from scratch again.
Reproduction Steps

Export MongoDB database to .js file dump.
Remove database
Import dump from step 1 again to MongoDB. All tables are fine. But Permissions are broken and LuckPerms plugin should create it's database by itself

Expected Behaviour
All should work fine
Server Details
Velocity 3.2 and latest Paper
LuckPerms Version
v5.4.102
Logs and Configs
No response
Extra Details
No response

You'll need to be more descriptive as to what "permissions are broken" means. Additionally, please provide full console logs.
While it shouldn't matter in this case, "latest" is not a version. If asked for a version of something, please provide an actual version number.


Potential macro expansion ambiguity in the recursion engine

It seems that the recursion engine relies on one ambiguity in the standard (the issue is about C++ but the C preprocessor is essentially the same):
https://github.com/hirrolot/metalang99/blob/695a9d8dbc3507447ba28d312da229730d20c6fc/include/metalang99/eval/rec.h#L12
Here, ML99_PRIV_REC_NEXT can expand to ML99_PRIV_REC_<level>, which is then invoked by a caller of ML99_PRIV_REC_NEXT, thus resulting in the ML99_PRIV_REC_NEXT token once again.
However, I haven't noticed any problems with various compilers yet as they seem to treat this ambiguity in the same way. Please, let me know if your compiler doesn't work because of it; to make sure, run tests/eval/rec.c.

I haven't noticed any differences in behaviour across different compilers since I created this issue. I'm closing it as resolved. Feel free to comment if you have a counterexample.


Popup focus fixes

What does the pull request do?
After some digging around a little, I finally (hopefully) figured out why Textboxes don't play nice with focus when placed in a popup.
In FocusManager
public void Focus(
            IInputElement control,
            NavigationMethod method = NavigationMethod.Unspecified,
            KeyModifiers keyModifiers = KeyModifiers.None)
        {
            if (control != null)
            {
                var scope = GetFocusScopeAncestors(control)
                    .FirstOrDefault();

                if (scope != null)
                {
                    Scope = scope;
                    SetFocusedElement(scope, control, method, keyModifiers);
                }
            }
...

scope is null because PopupRoot doesn't implement IFocusScope so attempting to set focus on any control within a popup through Control.Focus() or FocusManager.Instance.Focus() failed. This also meant that Tab navigation would have to be handled on the host control/PlacementTarget of the popup to work properly.
I checked with WPF's source and if no FocusScope is found, they still allow focus to be placed on the control and just make it an implicit FocusScope: (line 414)
https://referencesource.microsoft.com/#PresentationCore/Core/CSharp/System/Windows/Input/FocusManager.cs,970b54bfb95832d9,references
This PR just marks PopupRoot as IFocusScope which seems to work as expect compared with WPF, and AFAIK doesn't disrupt behavior of existing popup navigation logic (i.e. context menus, menus), so it shouldn't break anything.
TextBox can now be focused, and using the Tab key will keep focus contained within the popup instead of directing it back to the main window. I didn't want to mess with FocusManager and the implicit focus scope idea of WPF to not break anything
Checklist

[x] Added unit tests (if possible)?
[ ] Added XML documentation to any related classes?
[ ] Consider submitting a PR to https://github.com/AvaloniaUI/Avaloniaui.net with user documentation

Breaking changes

Fixed issues
Fixes #3639

@danwalmsley Unless I wrote something in the test that doesn't play nice with the CI, I don't know why its failing. It's another of the "it works locally, but fails here." I can skip the test as I know the fix does work.

@grokys any ideas about this test that works locally but fails on CI?

It doesn't seem to be that test that's failing - seems to be something in LeakTests, most likely unrelated. Lets see if it passes now.

@grokys @danwalmsley
I finally got the test to fail on my end, not sure why it wasn't before? Anyway, digging into this a little more, it seems the test is using an OverlayPopupHost instead of a PopupRoot which also makes the test pointless since it's not using PopupRoot, however, it did make me think maybe the implementing of IFocusScope shouldn't just be on PopupRoot but maybe on IPopupHost that way it applies to both overlay and regular popups (so the behavior is the same). But I found another issue that I think is behind the test failing...
It seems OverlayPopupHost doesn't set its visual children, as none of the controls placed in the popup have their VisualRoot set (it's null) and a GetVisualDescendents() call on the popup host returns no visual children. This prevents the focus manager from working properly cause it uses the VisualRoot of the control requesting focus to find the focus scope and the test fails.

@grokys  @danwalmsley
I think I've managed to figure this out. I moved implementing IFocusScope to IPopupHost so it works for both PopupRoot and OverlayPopupHost. I think the issue was I didn't realize the test ran twice, once using a popuproot and again using the overlayhost and when I got it to pass locally I think I was running only the popuproot version. Also didn't know you have to call Measure and Arrange on an OverlayPopupHost to get the visual tree to realize (my last comment).
Anyway, everything seems to work now and hopefully this can be merged now

Thanks @amwx - glad you figured it out. Seems like the failing test actually pointed you in the right direction in the end :)


Can't close channel

Trying to close channel in beta results in this screen on infinite wait.

Here logs
bitkit_ldk_logs_1718782536830.zip

30 errors logged from LDK saying:
ERROR (LDK): Got non-closing error:
Got a message for a channel from the wrong node!
No such channel for the passed counterparty_node_id
0296b2db342fcf87ea94d981757fdf4d3e545bd5cef4919f58b5d38dfdd73bf5c9
(lightning::ln::channelmanager 8839)

Could this be a channel originally opened with the stable app, attempting to be closed with the beta app?
I'm expecting this not to work currently, would need @Jasonvdb to confirm eventually.
@JeanlChristophe Do we even want to do an effort to make it work?


RFC: stats: univariate distribution infrastructure

The existing univariate distribution infrastructure is an extremely valuable feature of SciPy, and it offers two main ways of interacting with distributions.

stats.norm.pdf(2, loc=0, scale=1) calls the pdf method of the norm object that is instantiated at import time.
stats.norm(loc=0, scale=1).pdf(2) uses the __call__ method of the norm object to create a "frozen" instance of the distribution, then calls that object's pdf method.

There are two major advantages of approach 1 (and, to be fair, I'll be happy to add others as they come up in the comments below).

It is a bit more natural than approach 2 for very simple invocations. For example, it may be more natural to think of the standard normal PDF as a function and call stats.norm.pdf(2) rather than thinking of (and instantiating) a standard normal object and invoking its pdf method (stats.norm().pdf(2)).
It is the more common approach in existing code.

However, there are several important disadvantages.

All ~125 distributions are instantiated upon import, increasing import time.
Generating complete, distribution-specific documentation is impractical (gh-10328)
Parameters are processed every time a method is called, increasing overhead (gh-17620)
gh-13986

These could easily be avoided if norm were simply a class (rather than an instance of the norm_gen class) and the user were required to instantiate that class (e.g. norm()) before invoking methods. This has been noted before; for example, see gh-12133 for an earlier discussion of the history and pros/cons of the two approaches.
There are also several issues that have been reported over the years that may not indicate inherent disadvantages of the existing infrastructure, but do suggest that some upgrades are desired. There are several features and limitations of the existing infrasture (inflexibility w.r.t. adding/removing method arguments) that suggest that it may be easier to start fresh, reimagining the infrastructure with these enhancements in mind rather than adding patches to the existing framework.

gh-2509 - currently, distribution contributors need to write custom code if they want to exploit symmetry, a formula for the median, or other information about their distribution to improve speed or accuracy. I'd suggest building mechanisms for this into the infrastructure to make it easier for contributors to exploit such information and simpler for maintainers to review.
gh-3758 - Discrete distributions should not be limited to integral support.
gh-4538 - Every so often, we get a new question or request that indicates the demand for alternative parameterizations of distributions (e.g. gh-12134, gh-18984). I don't think it's possible to offer alternate parameterizations within the existing infrastructure without creating an entirely separate distribution class/object. We should embrace the need to offer multiple parameterizations as we design the new infrastructure.
gh-5362 - The existing interface for fixing and providing guesses of parameters has confused users and maintainers and would be worth reimagining. On a related note, contributors should not need to entirely redefine the fit method to override it. The fit method needs a nan_policy/inf_policy.
gh-6038 - We have a few circular distributions, but there is no infrastructure for them. This causes several problems, such as unwrapped random variates and incorrect behavior of the scale parameter. The new infrastructure should offer proper support for circular distributions. I think these would have the same name as their unwrapped counterparts, but would be selected by providing optional arguments (e.g. domain). I think it would also be reasonable to look into the computational feasibility of generic code for wrapping arbitrary distributions.
gh-7311 - Users want complex distributions with complex support. The new distribution interface should allow for that.
gh-8053 - The new infrastructure will remember the random state it is assigned.
gh-9321 - The new distribution interface should allow access to the information it knows about itself. There should also be mechanisms for modifying this information.
gh-9439 - Because contributors cannot easily override the loc/scale parameterization, it is essentially impossible for users to fit truncated distributions with fixed truncation bounds. The new distribution interface should fix this.
gh-10106 - The new distribution interface should make it easy to take advantage of the features of stats.sampling to generate random variates rather than always using inverse transform sampling (even when ppf is implemented numerically).
gh-11026 - The choice of ppf(0) = -1 and the definition of interval for discrete distributions should be reconsidered when planning the new interface.
gh-11465 - Users occasionally report interest in distributions in extreme tails. The new distribution interface should offer better support for this (e.g. provide inverse of logcdf).
gh-12000 - The Poisson binomial distribution is a univariate discrete distribution that does not fit well in the existing infrastructure. The new infrastructure should make it easier to implement more exotic parameterizations without needing to abandon the distribution infrastructure.
gh-13666 - There is a lot of custom code for treating special cases of distributions (e.g. when a more general distribution simplifies to another standard distribution for special values of the shape parameters). There should be a standard mechanism for this in the new interface.
gh-14895 - See title. Also, we should consider methods suggested in comments in _distn_infrastructure.py - e.g. hazard function, probability sparsity function.
gh-15974 - We should consider implementing relative_entropy and cross_entropy in the new interface.
gh-16877 - The use of statements like (a == a) to detect NaNs is confusing and should be avoided.
gh-16998 - pickled/unpickled instances should behave exactly like the originals. See also gh-19524.
gh-17307 - distributions can be frozen with invalid parameters, but rvs raises an error while others return NaNs
gh-17891 - distributions accept floats for integral shape parameters, but can produce confusing or unexpected error messages (e.g. ValueError: Integers to negative integer powers are not allowed.) when they are used.
gh-17973 - distribution methods are extremely slow because of all the exceptional case handling of the existing infrastructure. The exceptional case handling should be improved, and the exceptional case handling should be optional. See also gh-18519.
gh-18265 - distributions should support object arrays with number-like dtypes
gh-18564 - discrete distributions should be able to be unbounded below and above
gh-18782, gh-20692 - the distribution infrastructure should take care of converting parameters to the appropriate data type to avoid these sorts of gotchas
gh-19554 - the infrastructure should produce random variates correctly with low precision shape parameters

Starting fresh, we would also ensure that everything is designed with vectorization in mind, as we still occasionally discover issues like gh-13504, gh-13581, gh-12192, gh-11746, https://github.com/scipy/scipy/issues/18093#issuecomment-1468552568, gh-18919.
This enhancement proposal is for a new univariate distribution infrastructure. To be clear, I don't mean that we'd discard the old infrastructure. A lot of the existing algorithmic code would likely be retained (perhaps modernized), and the new infrastructure/distributions would generally need to pass the old tests (with updated syntax). Hopefully, the transition would be easy for users - code involving frozen distributions (approach 2 above) would need minimal changes, and the rest just needs to add some parentheses and pass arguments into the distribution initializer instead of the method itself. But we would probably rewrite parts that define methods by executing strings, for instance. (I understand it was needed at the time, but we could avoid with a new structure.)
Of course, we'd want to discuss and study other possibilities to make sure we get things right, but it might look something like this.

Distribution families are represented by classes. The names are typically the same as existing distribution objects except in CamelCase (norm -> Norm or Normal, loguniform -> LogUniform).
Distributions are instantiated before using methods. The distribution class documentation describes distribution shape parameters, which are passed as keyword-only arguments to the class __init__ method (only). Naturally, this makes alternative parameterizations easy to support. Default support for loc and scale is provided, but distributions can disable them as needed. (Contrast against gh-15889.)
For the most part, public methods include those that are currently available with minor changes (e.g. the name of nnlf is corrected to nllf).
The shape parameters used to initialize the distribution can be used as guesses for the fit method, which modifies the shape parameters of the distribution. Methods are available to extract the shape parameters (e.g. see gh-9321).
There are new methods for calculating the mode, partial derivatives of the PDF (useful for random variate generation and fitting parameters to data), and generating the distributions of order statistics.
As in the existing infrastructure, public methods are rarely overridden by subclasses; instead, subclasses almost exclusively override private methods. However, the new infrastructure is more strict about this distinction (e.g. there is a new _fit method so that fit overrides do not have to repeat boilerplate code) and there are different versions of private methods that can be overridden depending on (for example) whether the developer is able to vectorize with respect to shape parameters or would prefer to rely on a default loop.
Methods have parameters that enable the user to control tradeoffs between precision/reliability and speed. For example, the user can opt out of expensive data validation checks. The user can opt out of special accuracy improvements (e.g. gh-2509) by specifying the desired absolute and/or relative tolerances, which can be passed into the quadrature, minimization, and root finding routines used by the generic implementations of distribution functions. The user can access accuracy estimates.
The quadrature, minimization, and root finding routines are natively vectorized rather than requiring looping in Python.
The infrastructure supports non-NumPy arrays (e.g. CuPy) and NumPy arrays that support nonstandard numerical types (e.g. mpmath).
The infrastructure provides a standard mechanism for switching to special case implementations (e.g. t distribution to normal distribution for df=inf) rather than requiring developers to use np.where/np.lazywhere.
Distributions "know" more about their parameters (e.g. like _shape_info, which was recently added to the existing infrastructure). Based on this information, parameter documentation and input validation are generated automatically.
Formulae used in overridden methods are documented.
The infrastructure is documented (e.g. how to create new distributions, gh-12133).
The infrastructure natively supports truncated support, wrapped domains, folded distributions, and complex inputs (e.g. gh-17592).
The infrastructure favors Pythonic techniques for introspection and avoids self-modification (e.g. adding methods with exec).
Distribution-specific tests (gh-17807 ) assure us that the distribution object represents the distribution it is intended to represent, property-based tests (e.g. see https://github.com/scipy/scipy/pull/12197#issuecomment-881100965) ensure that the methods are consistent with one another and the standards for SciPy distributions, and benchmarks track the speed and accuracy (especially for numerically challenging arguments).
The infrastructure includes a standard framework for investigating the accuracy of each method of the distribution by comparing itself with an mpmath backend. See notes below.
The documentation specifies the accuracy the user can expect when using methods within a specified range of inputs (e.g. accurate to X digits for 99.Y% of parameter combinations within hypercube Z).

The new infrastructure and distributions would be widely advertised, and documentation and existing code would transition to the new infrastructure. Existing infrastructure/distributions would be supported without deprecation warnings until two releases before SciPy 2.0, at which point they would be moved to a new package that is released once (without planned maintenance).
@tupui @ev-br @tirthasheshpatel @chrisb83
Notes on framework for investigating accuracy:
The infrastructure will accept as arguments arrays containing mpmath.mpf objects. Following the approach of gh-19023, special functions will dispatch to mparray versions where possible. This will allow for end-to-end calculation with arbitrary precision arithmetic and, therefore, automatic generation of reference values. By comparing numerical results computed using floating point arithmetic against these reference values, we can identify shortcomings in the implementation (e.g. ranges of parameter values where catastrophic cancellation causes loss of precision).
We cannot hope to test the accuracy for all possible floating point inputs, so we resort to random or quasi-random sampling from possible floating point inputs. From one perspective, it would be ideal if the distribution of floating point inputs tested would be representative of the distribution of floating point inputs used by users. This way, we focus limited resources on parameter ranges experienced in practice. However, this distribution is not known, so we should not make assumptions about it. Instead, I would suggest sampling parameter values uniformly from the set of all valid floating point inputs:

import numpy as np
import matplotlib.pyplot as plt
rng = np.random.default_rng(2184358452652)

types = {np.float16: np.int16, np.float32: np.int32, np.float64: np.int64,
         np.int16: np.float16, np.int32: np.float32, np.int64: np.float64}

def float2int(xf):
    """Convert the ith floating point number from zero to integer i"""
    # Adapted from numpy.testing._private.utils.integer_repr
    xf = np.asarray(xf)
    itype = types[xf.dtype.type]
    xi = xf.view(itype).copy()
    comp = np.asarray(np.iinfo(itype).min, dtype=itype)[()]
    xi[xi < 0] = comp - xi[xi < 0]
    return xi

def int2float(xi):
    """Convert integer i to the ith floating point number from zero"""
    # Adapted from numpy.testing._private.utils.integer_repr
    xi = np.asarray(xi).copy()
    comp = np.asarray(np.iinfo(xi.dtype).min, dtype=xi.dtype)[()]
    xi[xi < 0] = comp - xi[xi < 0]
    ftype = types[xi.dtype.type]
    xf = xi.view(ftype).copy()
    return xf

def sample(a, b, size, rng):
    """Sample uniformly from the set of floating point numbers between a and b"""
    int_range = float2int(np.asarray([a, b]))
    ints = rng.integers(*int_range, size=size)
    return int2float(ints)

a, b = 1e-2, 1e2
floats = sample(a, b, size=10000, rng=rng)
plt.hist(np.log10(floats))
plt.show()

As we might expect, the floating point numbers between positive a and b are approximately log-uniformly spaced. However, the log-uniform distribution is only defined over positive support, whereas the domain of a and b above includes negative reals.

I am +100 on this proposal. There are too many issues with the current infrastructure and it's very hard to maintain. Starting of with a clean slate will definitely be a good thing.

Thanks for writing this clear proposal. I will take a closer look at the issue 12133 to learn more about the background of this topic. Overall it makes a lot of sense to me.
At this point, I have just one comment:

There are new methods for calculating the mode and partial derivatives of the PDF (useful for random variate generation and fitting parameters to data).

Maybe dlogpdf (derivative of logpdf) could be considered, too: potentially it is useful to express nllf and I think some of UNU.RAN methods use it (I need to check in more detail). So not very important at this stage, but let's keep it in mind.

I jsut saw this
This will be difficult.
Many of the problems are orthogonal to class versus instance, e.g. vectorizing when support depends on parameters is never trivial.
Main design issue: stateless classes and instances versus (some) fixed parameters (fixed attributes of a class defined in __init__.
Both are convenient and very useful for different cases and distributions.
Allowing both in a generic way looks to me very difficult.

@josef-pkt to

Allowing both in a generic way looks to me very difficult.

One of the main point of this proposal is to remove the concept of frozen distributions. There would be only one way to play with distributions: which is using a class instance. (Or a factory, something else. We need to take some time to play with different APIs' architecture and investigate that with various distributions.) The current duality is too problematic/buggy and complicate the user API (and maintenance). We want to have a single point of entry for shape parameters, the init of the class and then you just do what you want with the distribution.
The point is that we only provide a single Pythonic and clean way to do things user side. For users using the class-based approach, it should not deviate much more. But in the background things would be extremely different with a more manageable infrastructure which can be evolved (e.g. right now adding a QMC sampler would be a pain), documented properly, etc.

I too am +1 for overhauling the frozen distribution infrastructure. To minimize breaking code, it would be good to keep all the distributions in the stats module as-is and declare them legacy.

Main design issue: stateless classes and instances versus (some) fixed parameters (fixed attributes of a class defined in __init__.

@josef-pkt I think simply initializing a new class for different parameters to achieve the stateless class behavior isn't too bad. We can also add static methods in the new distribution classes that offer the stateless classes syntax. But not having it at all also doesn't seem like an unreasonable trade-off.

@josef-pkt I think simply initializing a new class for different parameters to achieve the stateless class behavior isn't too bad. We can also add static methods in the new distribution classes that offer the stateless classes syntax. But not having it at all also doesn't seem like an unreasonable trade-off.

Just to be clear. The goal is to start with a clean slate, meaning the API can break things. We should only consider adding things if they make sense in terms of architecture. Not to comply with old behaviours. I would not add any mechanism to have a stateless distribution.

Instantiating a new class for different parameters sounds like a large overhead.
What's the overhead of creating  a new instance each time when I simply want to call norm.pdf(loc, scale), or calling logpdf inside fit?
On the other hand, there are some distributions that would benefit from precomputing some constants for method calls with the same distribution parameters.
(In statsmodels we use the equivalent of stateless, semi-frozen (some parameters fixed in __init__) and frozen distributions.)

I will see it when you have a prototype
tupui didn't like it when I moved most parameters to the methods in copulas so we can use it as a semi-frozen or unfrozen distribution. But that looks the better design to me for building models on top of the distributions.
In statsmodels, all (almost all) parameters that are estimated in models are arguments in model methods. In some cases it gets messy when we need to change additional model attributes that are not method arguments.
(But our models are a lot more complicated than a scipy distribution.)
One pattern that I use is to allow both, set some parameters in __init__ as attributes, and allow method arguments to override them. However, this is fragile if there are extra model attributes that are computed from the changed attributes.

just one more usecase that I remembered
finite difference derivative approximations need to compute the logpdf at different distribution parameters in one function.
extreme case:
A model in statsmodels that uses directly the scipy distribution for logpdf (in most cases we have our own functions for that, but not for all)
Uing a newton optimizer, requires logpdf and first and second derivatives (score and hessian). If they are not available in explicit form, then score and hessian are computed using numerical derivatives (finite difference or complex step).
So, each iteration of the optimizer will call the logpdf/loglike many times with different parameter values.
On the other hand, when we have estimated the model, then we have a get_distribution method that transforms the estimated parameters into the parameterization of the scipy distribution and returns a frozen distribution to the user, which then can be used to compute pdf, cdf, rvs based on the estimated model and parameters.

Following your example. You could write a small wrapper that would re-use a given class instance and just vary attributes (shape parameters). It might even be faster than instantiating a frozen distribution every time you want to update some parameters.
I don't see any issues there.

tupui didn't like it when I moved most parameters to the methods in copulas

What I did not like at the time was the use of *args, **kwargs which IMO is not a good design as it prevents easy inspection of method options/params, documentation etc. Seems like the situation improved a bit-from my perspective-with more descriptive args.

You could write a small wrapper that would re-use a given class instance and just vary attributes (shape parameters). It might even be faster than instantiating a frozen distribution every time you want to update some parameters.

But that's not needed right now because the scipy.stats distributions have stateless methods, i.e. we don't need to create a new instance when changing parameters, we always use the same instance.
If we loose that, then we cannot use any scipy distribution without fully wrapping it for the estimation models, and carry around our own case specific instances.
And users that want to use our GenericLikelihoodModel will also need to have a wrapper for the scipy distributions.

I don't believe that having to modify the shape parameters of a distribution is the common use of distributions. I am not saying this is not useful, but that it does not represent the majority of usages. I do not think we should maintain such mechanism as it's quite straightforward to do on user/downstream side.
dist = toto(a, b)

for ai, bi in ... :
    dist.a, dist.b = ai, bi
    dist.pdf(x)

    # instead of
    toto.pdf(x, a, b)

dist.a, dist.b = ai, bi
dist.pdf(x)

If you allow that, then you don't gain anything at all in the current implementation.
If it is allowed, then the distributions still need to be stateless except for the distribution args, i.e. no precomputed attribures, or you have to wip and update them each time.
For users, this is pain without gain.

I don't believe that having to modify the shape parameters of a distribution is the common use of distributions.

Shape parameters, but also loc and scale.
It's one of the main usecases in statsmodels.
other examples
confidence intervals for parameters that sometimes need rootfinding, similarly profile likelihood (confint)
power and sample size computation where scale or shape parameters change. (generic sample size computation again requires rootfinding for different parameters. In statsmodels those functions directly use scipy distributions, mainly norm, t, f, chi2 and their non-central versions, but also beta, binomial, poisson, gamma, ... for countmodels)
statsmodels uses frozen distributions only as user convenience. Users don't have to carry around the distribution args when providing or receiving a distribution instance.
Bayesian or Monte Carlo applications require mixture distributions where parameters change. Very often those cannot be fully vectorized and we cannot avoid many calls to distribution methods with different parameters (shape, loc, scale).

This is an excellent proposal.  Some thoughts:
If you're redesigning anyway, you may want to take a look at my efax library, which was designed with machine learning in mind.  In particular,

It stores vectorized parameters and all operations are vectorized.  This is much more efficient when working with multiple parameter values.
It has a pair of parametrizations for all exponential families: the natural and expectation parametrization.  These are useful in machine learning.
It can be queried about the natural of the parameters: their support, their shape (whether they are scalar, vector, or matrix parameters), and other invariants (are they symmetric or Hermitian matrices), etc.

There needs to be support for integer, real, and complex parameter types.  I discuss many practical redesign ideas in #7311.
The design of distributions with bounded support is suboptimal due to making all distributions in scipy location-scale families.  They should not be location scale families.  I discuss this in #6038.

Thank you @NeilGirdhar for the information. We will have a look. Note that we would not be able to use any Jax code as we don't want to add another dependency.

we would not be able to use any Jax code as we don't want to add another dependency.

Of course!  I only show it as illustration of an alternative design from which you may be able to take some ideas (parameter inspection, vectorization, multiple parametrizations, etc.)

I don't believe that having to modify the shape parameters of a distribution is the common use of distributions. I am not saying this is not useful, but that it does not represent the majority of usages. I do not think we should maintain such mechanism as it's quite straightforward to do on user/downstream side.

I agree with you @tupui.  At least with machine learning, the number of instantiations is very small provided that you support vectorization in all distributions (which you don't yet).
I agree that this form toto.pdf(x, ai, bi) is overcomplicated to my eyes.

I expect this overhaul would fix thing like this which I am still working around, so a big +1 in general.

What is the process for this redesign?  Is there somewhere the interface is being discussed?  I'd like to follow along the discussion if possible.
I'm not sure what the usual process is, but it might be illustrative to design the interface for a single distribution (say MultivariateNormal) as an archetype.  That way the many people watching this issue can ensure that all of the linked problems have been eliminated.

Thank you for asking @NeilGirdhar. We did not formally start yet as this would be part of a grant project. We will let everyone know when/if we have the funding and how we can proceed. In any case, everything will be public and we will seek everyones' input 😃

To clarify, this issue is about univariate distributions. Multivariate normal is a multivariate distribution. Multivariate distributions could use more of an infrastructure than they have make them more consistent, but I think it would be more challenging than it's worth to share innards with the univariate distributions. For those, please continue the discussion in gh-16278.

I think it would be more challenging than it's worth to share innards with the univariate distributions.

I agree with you about the innards.
Still, if you're going to clean up the interface, it might be nice from a user point of view to provide the same pretty interface for multivariate distributions--even if the innards are different.

Is there a place to see the current progress of this branch of development?

I was just reminded of this issue when I saw the recent release of scipy that now supports the Array API.  As soon as Jax supports the Array API, I will port my distribution library efax to the Array API.  Efax was designed with many of the above shortcomings in mind.  It supports:

automatic broadcasting on all parameters,
multiple parametrizations for each distribution (in particular, the natural and expectation parametrizations of exponential families),
introspection for all parameters, and
complex parameter support.

It's also significantly simpler to add distributions using efax's framework that scipy's framework.
I realize it would be a lot of work, but what are people's thoughts on merging all of the functionality from scipy's distribution functions with the efax's framework?

Hi @NeilGirdhar @fancidev 👋
We are making good progress. The active stats maintainers are involved.
We have a functional draft which is almost feature complete and addresses all issues we wanted to cover. Including Array API support 😃 (I worked on the I infrastructure to allow that to happen on SciPy in the first place).
At that time though we are not ready for receiving external comments nor review of our design and implementation.
Jax is not considered at the moment. Jax itself is not Array API compatible and my understanding is that the philosophy from their team is different. I can have look at your package to see if there is something we are missing.

Awesome, looking forward to seeing the new design!

I can have look at your package to see if there is something we are missing.

Cool, sounds good!
(I only mentioned Jax to say that my timeline will follow theirs.)

Thanks for the update @tupui.
A small suggestion for the rv_continuous.fit method for your consideration in the new framework: the method parameter should have default value None,  with the below semantics: If method is None, a suitable consistent estimator is used, with MLE preferred.
This (breaking) change allows alternative methods to be used when MLE is known to be inconsistent, such as when estimating the location of a gamma distribution with shape less than one. It also allows for example an unbiased estimator of the normal variance, which is probably more commonly used than the biased MLE.

Another really small (but breaking) suggestion: the first parameter of ppf and isf of rv_continuous should read p not q, because it’s a probability rather than a quantile. (This change is breaking unless the parameter is made position-only, which unfortunately is also breaking.)

Thank you for the suggestion @fancidev.
To be clear for everyone following this work: first of all, thank you 😃 we really appreciate that, do read and take into consideration what users tell us. Our ultimate goal is to provide something useful for the community.
Now, the outcome of this work has never been to upgrade the current infrastructure but instead to start from a clean slate. Meaning that we are rewriting a whole new infra from the ground-up, learning from all past pain points and addressing our wish lists.
I cannot share more than that for now as we are still evaluating all options (including eventual upgrade or compatibility options). I hope everyone sees this as a good thing in the sense that we are doing our best to give all ideas their best shot and don't constrain ourselves to pre-existing practices. One of the main goal of this project was to challenge how we go about univariate distributions and this is precisely what we are doing.
What I can share though is that we will very open up a formal RFC (request for comments) period in the near future.

What I can share though is that we will open a formal RFC (request for comments) period in the near future.

That's really great to hear and very considerate to users.  Thank you!
(I think some people's comments were motivated by a fear that there wouldn't be such a period, which might make any oversights difficult to change.)
We are all eagerly looking forward to playing with the new design.

Thanks for sharing! Looking forward to the RFC!

@tupui @mdhaber I just want to say congratulations on an absolutely beautiful design!  This write-up with the links to the relevant is really great.
As I said when we spoke on Monday, there's a lot of things I love about this design and I wanted to voice my support for your design choices.  In particular:

Absolutely love the "transformers" (wrapping, truncation, mixtures, doubling, etc.)   Beautiful!
Love how there's exactly one way to do things (e.g., evaluating a pdf is done by constructing the object, then calling a method; there is no second pathway).
Having worked on distribution changes in the past, I love the simplicity with which a new distribution can be updated.

I have a few questions and comments (and I may add more here as I think of them so as not to flood the thread).

Have you considered making the distribution naming a little bit more consistent with the Array API library and in particular your other proposed extension.  In that proposal, I really liked the use of underscores that make code easier to read.  After all, code is read many more times than it's written.
For this proposal, it might make sense to use some slightly longer names: log_pdf, log_entropy, inverse_cdf, complementary_cdf.  These are longer, but they can save on explanatory comments.

Which methods use the RNG?  Right now, there's only sample?  Would it make sense to just pass in the RNG into those methods?  Storing RNGs may end up being very weird in Jax.

I love the inheritance hierarchy.  Have you considered adding a base Distribution class above ContinuousDistribution and DiscreteDistribution?  This could just have support.

I think we talked a bit about parameter introspection, and you said it was more of a future plan, which makes sense.

Anyway, I'm really excited about the new design!

The proposed refactoring looks really cool!
Skimming through the notebook and documentation, I only have some “polishing” type of comments which is not important for initial release. Good stuff!

A few comments about the design:

Would it make sense to make a distribution object immutable? This should simplify reasoning. For example, that fit mutates the object feels weird to me.
Would it be appropriate to detach tol, cache, and rng from the object? It helps to make the object lean. tol and rng are probably better specified at the call site. cache could be implemented by a CachedDistribution wrapper (which I don’t expect many to use?)
Does the infrastructure allow the potential to support mixed continuous and discrete distribution?

For this proposal, it might make sense to use some slightly longer names: log_pdf, log_entropy, inverse_cdf, complementary_cdf. These are longer, but they can save on explanatory comments.

+1 on this one. I'd personally prefer inv_ to inverse_ and sf to ccdf, but the more verbose versions are definitely easier to draw attention than the subtle iccdf :)

Also, I suggest moving the fit function out of the distribution and making it a free function. After all, it doesn't seem to rely on private members, so by OO principles, it should be a free function. You can provide a more efficient fit mechanism for exponential families.

+1 on having the free fit function. scipy.stats already has one (that fits to data), so just need to find a way to extend its functionality. I still find it useful to allow individual distributions to provide specialised fitting functions, e.g. via something like _fit_formula. The benefit is efficiency, accuracy, robustness, etc.

I love the inheritance hierarchy. Have you considered adding a base Distribution class above ContinuousDistribution and DiscreteDistribution?
+1, though it can always be added later without affecting the existing interface. As a proof of concept, I'd also like to insert InteriorContinuousDistribution class (gh-19946) in between Distribution and ContinuousDistribution to support continuous distributions with a probability mass at boundary, such as compound Poisson Gamma (Tweedie).

Anyway, I'm really excited about the new design!
Me too!

Thanks all, I am adding a quick note here just to say that we are reading. We just want to let people have a look first before answering to hopefully not bias too much the conversations 😃
After a week or so, I will sum up the discussions and make a reply to address the suggestions.

I'd add:

Add cumulant support, since going between them and moments is sometimes useful generally and is essentially required to compute moments in closed form for sum distributions
Mixed continuous and discrete distributions are rare but do exist https://en.wikipedia.org/wiki/Tweedie_distribution . It'd make more sense to me for the distribution infrastructure to be as support-independent as possible, even down to being generic over it.
Type annotations, it's confusing to tell what function params actually mean when implementing them

Thanks everyone who worked on this behind the scenes and to those who've provided  comments. My 2 cents
On moments:

Add cumulant support, since going between them and moments is sometimes useful generally and is essentially required to compute moments in closed form for sum distributions

Cumulants and moments (eg mapping between the two) is useful for both continuous and discrete distributions in applications. Cornish Fisher comes to mind, as does Saddlepoint expansions which are sometimes formulated this way.
For discrete distributions (and maybe sometimes continuous) it is often easiest to write a distributions moments by working in the factorial basis and converting to raw
moments.
Two methods which could do this would use the Stirling numbers of first and second kinds:
$$ x^n = \sum_{k=1}^{n}{n \brace k} (x)_k  $$
and
$$(x)_{n}=\sum_1^n {n \brack k} x^{k}$$.
(for whatever reason the github latex isn't rendering the latter change of basis correctly and the way I was able to get it to render was by removing the k= in the \sum)
so converting back and forth is a change of basis (but can make computations easier).
If we can leverage these change of basis it might be a nice use case.
I have WIP CR for First kind Stirling and Second kind Stirling was merged a release or so ago. These codes are in scipy.special and support broadcasting.
Example common distributions where this is handy (Poisson, Binomial, Negative Binomial), all three have simpler arbitrary positive integer moment representations that are much cleaner than the raw moments.

Mixed continuous and discrete distributions are rare but do exist https://en.wikipedia.org/wiki/Tweedie_distribution . It'd make more sense to me for the distribution infrastructure to be as support-independent as possible, even down to being generic over it.

IIUC @mdhaber has noted this is planned, at least I'm assuming that's what is meant by mixture distributions (and not variance scale-mixture families which is a wholely different class of distributions).

Type annotations, it's confusing to tell what function params actually mean when implementing them

+1 these would be nice to have.
One thing I haven't noticed mentioned (possible I missed it though) is which methods are required and which aren't? (when implemented a new distribution)
There are some distributions which have inverse CDFs easily represented but not CDFs and some which have nice algorithms for Sampling but not other things like easy CDFs (example is the Dickman or Goncharov distribution-this one has some nice CFTP sampling approaches).  Tweedie is maybe another one in this domain for certain values of p parameter and Polya-Gamma is another.
These are maybe less important to the generalist scipy user but for infrastructure we might consider them, if nothing else at least to determine and document whether they or distributions like them would or would not be implementable using planned infrastructure.
(apologies in advance if the 'public' interface aspect is noted somewhere in thread above and I missed)

Thanks everyone for your comments and support, we really appreciate you taking the time.
I am trying in the following to address the comments. Feel free to add more comments if I forgot anything.
Based on the overall positive response, thank you again, @mdhaber is going to open a PR. I will post another message on the forum for it too.

Have you considered making the distribution naming a little bit more consistent

We did consider alternative naming schemes (we did a poll between us too) and the API we have now is the solution we came up with. Being slightly more descriptive with complementary_cdf would be nice, but then for consistency we would need inverse_log_complementary_cdf which seems too long for us. We also try to avoid adding small things like inv or comp as we had issues in the past with acronyms becoming slurs. Just a precaution here.

Which methods use the RNG? Right now, there's only sample? Would it make sense to just pass in the RNG into those methods?

We had quite some back and forth there too and are still discussing this point. Some of us thing we should not allow passing a RNG in methods and just allow having it at the init. Right now it does both. This is still a point open for discussions, we will have a second look.

Also, I suggest moving the fit function out of the distribution and making it a free function. After all, it doesn't seem to rely on private members, so by OO principles, it should be a free function.

Yes and no. Things like staticmethod for instance are here to group methods under a given "name space" to have a logical grouping. We will think this once more.
But yes, after discussing this. We are going to remove the fit method from the initial API. And we will think about how to follow up.

Have you considered adding a base Distribution class ... It would serve as a type annotation for generic functions that accept distributions

Typing is not going to be part of this first iteration. But it's definitely something that we are going to look into in follow ups. (I am myself very much interested into typing. There are just a lot of initiatives right now happening on that front and waiting a little bit more might help us get there.)

distribution object immutable

In the previous design, there was 2 ways to create a distribution: a classical class instance, and a frozen one. This design lead to a lot of confusion in the community and this is precisely one of the pain point this new design addresses.
We want to allow class mutability to be able to change parameters (in a controlled manner with proper checks). This will be important for some downstream libraries.

detach tol, cache, and rng from the object

See above for RNG, otherwise we think it's a better API that way.

support mixed continuous and discrete distribution

Mixed and Discrete distribution are definitely on the table and will be a follow up.

The notebook example suggests that a distribution object may be instantiated with vector parameter. But the documentation gives no clue of this

More documentation will come. Now we are focusing on the basics.

Normal._pdf_formula ... remove self and make the method a classmethod or staticmethod, or remove the distribution parameters and only access them via self

Thanks, we will have another look and consider it.

sf to ccdf

We had some discussions here when we added features around survival analysis and this naming is less common for non experts than the complementary of the CDF.

as compound Poisson Gamma (Tweedie).

A general note about distributions. We don't want to go back to the current status where we have more tham 100 distributions. Instead, we want to make an API which allows anyone to add their custom distributions.
We are actually thinking about making a dedicated library to host user defined distributions. We don't need to bloat the library itself and most importantly add to the maintenance pile more than we have to.

I'd also want a way to select the distribution's sampling strategy. It may be useful to force inverse-transform, or ziggurat, or Box-Muller for the Normal distribution in particular.

There is a method parameter to do a basic method selection. But we are going to work on this more. The end goal will be to use methods which are Array API compatible so that sampling can be fast and library independent.
Something else we will look into is to see how we can integrate the work done in stats.sampling.FastGeneratorInversion with UNURAN. We just need to see how, here as well, it will fit with Array API support.

cumulant support,

We can consider that in a follow up.

One thing I haven't noticed mentioned (possible I missed it though) is which methods are required and which aren't? (when implemented a new distribution)

We have a diagram for all the logic but we need to do some small polishing. But yes, it will be in the doc.

I think dropping the fit method is not a good idea:
It's the main usecase where we need to call methods with different parameters, and you need it for the design decisions.
Current distributions have many distribution specific fit methods, that are useful and took a long time to add and improve.
It's very difficult to fit some of those distributions that are not well behaved at boundaries or because of changing support.

Moving the fit method out for now does not mean that (i) it will not be added back, (ii) we cannot use any specialisation. We are considering all of that, don't worry.

I gave up worrying and just hope for a loooong deprecation period

+1 for immutable.
+1 for implementing fit as a class method, where the method generates a new instance of the class.

immutable without args in the methods kills it for any fitting applications, or we have to create a new instance each time during fitting.
(Models in statsmodels are supposed to be immutable (by user), but not having some extra args in the methods makes that very annoying in some use cases. We have some backdoor mutating in internal applications, but it looks dirty.
I just created a set of classes that have set_params method, but I also don't feel comfortable with it. It's too easy to mutate the wrong instance.
)

Yes immutability is off the table. As I said, we want to support changing parameters for things like fitting.

Before doing more meta-discussions around that. Please also have a look at the timings Matt put above as well. You really need to look at this with fresh eyes.

Would it be possible to clarify why fitting needs mutable distributions?

The main reason is overhead of instance creation, and convenience of calling a method if it has a parameter argument.

The main reason is overhead of instance creation,

Would you happen to have a program that illustrates why this overhead might be problematic?  The reason I ask is twofold.  First, with the broadcasting interface, if you're doing a lot of fitting in parallel, then you can fit them all at once, and only one instance is created for all of the random variables.  And second, nowadays, there are plenty of mathematical JITs that would erase all of the overhead.  So, if you could show an example, we could explore if a JIT would solve your problem.

and convenience of calling a method if it has a parameter argument.

I'm not sure why calling a method is any nicer than instantiating and calling a method on the instance?  I find the Python principle of there being "1 way to do things" to be more motivating, personally.

Please also have a look at the timings Matt put above as well. You really need to look at this with fresh eyes.

I read (and loved) Matt's comment when I hearted it.  I see that you're referring to the timings.  I just don't see how creating instances is problematic in practice, but maybe my applications are different than other people's.

I read (and loved) Matt's comment when I hearted it. I see that you're referring to the timings. I just don't see how creating instances is problematic in practice, but maybe my applications are different than other people's.

Oh I was saying that for everyone here. Plus we had a talk with you so I know you have more context from us.
What I am saying here is that if we really want to have a meaningful discussion then everyone needs to be on the same page by pulling Matt's branch locally and playing with it. Otherwise it's easy to think that it works in certain ways though it does something else entirely. Talking about overhead and such without trying it out does not make sense to me otherwise. The new API is very different from the previous one.

For brainstorming purpose, Java and C# address the mutable/immutable dilemma (for String) by keeping String immutable but having a separate, mutable StringBuilder class. Do whatever you like on StringBuilder, and once you’re happy with the result, create a String from it for later use.
I feel this model may be an overkill for Python, so I don’t intend to propose it as a solution. Just for your info.

Actually, it's difficult to find an example in statsmodels that uses scipy distribution in fit with variable parameters.
For most distributions we have explicit formulas for the loglike and its derivatives.
For loc-scale distributions without shape parameter we can just use the standard distribution on the transformed data.
The only example I currently find:
For the t distribution model with estimated df, the loglikelihood uses
llike  = - stats.t._logpdf(errorsest/scale, df) + np_log(scale)
which is then used with scipy.optimize.
(Models with other distributions that have shape parameters, e.g. for failure time and extreme values, are still missing in statsmodels, Numfocus thought they are not important)
So, maybe I don't need to care.
The only other time consuming loops that I remember right now are rootfinding for power and sample size computation which in many cases have to solve a cdf constraint for a shape parameter.
Most other application of scipy distribution in statsmodels are one time calls where overhead would be unimportant most of the time.
(I have a recent case with distribution.expect numerical integration inside rootfinding. But that is so slow that it's not usable for users anyway. :)
You can also time the fit method in scipy to see whether creating instances has a non-negligible overhead.

@NeilGirdhar
Switching backend or supporting backends other than numpy/scipy/pandas is currently not planned for statsmodels.
The priority is still on adding statistics and econometrics that is currently not available in Python, with reasonable performance given current tools and not on finding the fastest implementation.
(There are several other Python packages that have parts of statsmodels' functionality but oriented on speed and performance.)

We don't want to go back to the current status where we have more tham 100 distributions.

Is there a record of these policy decisions somewhere? I don't recall this being a part of the roadmap when the work got started.

@josef-pkt I understand.  The reason I wanted to illustrate the Jax solution is to support my argument that I don't think that speed should be a significant consideration when making design decisions.  Whether you need to construct objects or not is totally irrelevant if you care about speed because if you care about speed, you should just use a JIT.
And just so that we're clear: I'm not sure if you meant "array library" when you said "backend"?  Because the Jax solution is a different array library, but it's the same backend (CPU).
In short, my personal preference is for design decisions to be focused on ergonomics over efficiency since JITs provided by Array API libraries should solve the efficiency problem.

We don't want to go back to the current status where we have more tham 100 distributions.

Is there a record of these policy decisions somewhere? I don't recall this being a part of the roadmap when the work got started.

We did not make a public official announcement specific to that yet no.
While we iterated on this RFC with the other SciPy stats maintainers, it became clear for us that we did not want to leave the door open anymore to anything. The maintenance cost is just too high and none of us want to review nor maintain more than what we must.
We feel that a community effort around that would be a more sustainable solution. The new API will make it simpler to add any distributions and this does not need to live in SciPy. Hence we will push for another repository proposing a collection of distribution. I plan to quick start this repository later this year, but in the end, I and other SciPy stats maintainers will not provide any guarantee on that repo.

And just so that we're clear: I'm not sure if you meant "array library" when you said "backend"? Because the Jax solution is a different array library, but it's the same backend (CPU).
In short, my personal preference is for design decisions to be focused on ergonomics over efficiency since JITs provided by Array API libraries should solve the efficiency problem.

Support for Array API will be added right after. The team has been quite busy adding support to stats and preparing the ground to enable a full support with the new distribution infrastructure.

While we iterated on this RFC with the other SciPy stats maintainers, it became clear for us that we did not want to leave the door open anymore to anything. The maintenance cost is just too high and none of us want to review nor maintain more than what we must.

Where did this discussion take place? Not on the mailing list or the Discourse.

Is there a record of these policy decisions somewhere? I don't recall this being a part of the roadmap when the work got started.

We did not make a public official announcement specific to that yet no.
While we iterated on this RFC with the other SciPy stats maintainers, it became clear for us that we did not want to leave the door open anymore to anything. The maintenance cost is just too high and none of us want to review nor maintain more than what we must. [...]

That's kinda not how this works. Decisions get made in public, with clear rationales. I suggest to focus on getting the new infrastructure merged without making such definitive statements on what can and cannot be contributed in the future. Deprecations/removals of existing API surface is the same. It can be mixed in one huge discussion, but I'd advise keeping it separate. It's not at all clear to me what the best way forward is for the old (very widely used infra).
The new framework seems to be really good. Let's get that completed, used, and then worry about the rest.

That's kinda not how this works. Decisions get made in public, with clear rationales. I suggest to focus on getting the new infrastructure merged without making such definitive statements on what can and cannot be contributed in the future.

To be clear, this is not a done deal in the sense that this RFC is not about that. This is just me saying that some of the current stats folks (@mdhaber, @steppi, @tirthasheshpatel, @ev-br, @chrisb83, @dschmitz89 and myself) had 6 meetings together and we felt that we did not want to go back to this state and spend our time on this in the future.

We feel that a community effort around that would be a more sustainable solution. The new API will make it simpler to add any distributions and this does not need to live in SciPy. Hence we will push for another repository proposing a collection of distribution. I plan to quick start this repository later this year, but in the end, I and other SciPy stats maintainers will not provide any guarantee on that repo.

I like this idea. I’m impressed by the large, comprehensive set of distributions in SciPy. There’s some room left for improvement as some distributions are less polished than others. A community effort could help in this regard.

For those who are following this issue but may have missed the discourse post, see gh-21050 for a first PR for the new infra.

Mixed continuous and discrete distributions are rare but do exist https://en.wikipedia.org/wiki/Tweedie_distribution . It'd make more sense to me for the distribution infrastructure to be as support-independent as possible, even down to being generic over it.

IIUC @mdhaber has noted this is planned, at least I'm assuming that's what is meant by mixture distributions (and not variance scale-mixture families which is a wholely different class of distributions).

Could this be confirmed? It is important for me to know if the new infrastructure could, in the future, support such distributions with point masses such that gh-11291 could be revisited.

Yes. For example, a zero-inflated distribution could be represented as a mixture between a discrete and continuous distribution. It would be a separate class, but with a similar interface, some shared input validation code, and it would take advantage of the ContinuousDistribution methods for the continuous components of the mixture. You may know that methods like those for CDF, moments, and random sampling can be expressed pretty simply in terms of the CDF, moments, and random sampling methods of the underlying components (e.g. see gh-19413). That part is roughly independent of how the continuous and discrete components are implemented - although because of how ContinuousDistribution is implemented, a mixture of these and upcoming DiscreteDistributuons can be more efficient than if it were composed from instances of rv_continuous/rv_discrete. I can prototype a mixture of ContinuousDistributions now if it would help.

@mdhaber THX. Sometimes it helps to prototype a bit to have a better view if things work out as planned. But I can’t get involved too much right now.

Hi,
I am working a lot with Scipy and just spent the weekend understanding why it is so difficult to change the parametrization convention of existing distributions. There are even quite well-adopted packages like paramnormal which try doing that, but they do not seem to integrate well with the scipy.stats infrastructure. The approach described below would require only implementing two functions (_parse_args and _unparse_args) in a class derived from the standard Scipy version of the distribution to translate to and from the standard SciPy convention. I thought it might be good to align first before investing further work. My Scipy version is 2.1.2.
Problem description
The terms “location” and “scale” do not really appear to be standard terms in statistical literature – terms like “mu” and “sigma” are equivalent for the normal distribution, but have completely different meaning in other distributions (starting even with log normal). For more complex distributions, it is unlikely to find one agreed way of parametrization (Wikipedia often lists two or three, often parameters in one convention the negative or inverse of the other). Converting conventions in application code is error-prone and hard to maintain, hence a more built-in solution may be easier to maintain.
Solution Context
All member functions of rv_distribution apparently can be classified into
•	Functions which take distribution parameters plus function parameters and produce some numbers like the CDF, PDF or a set of random numbers
•	Fit functions which take data, a starting point and the values of fixed parameters and return parameters of a distribution.
In principle, changing parameters should be rather trivial. In fact, there is a set of functions (_parse_args, parse_args_rvs, _parse_args_stats. _unpack_loc_scale) which read the parameter set and return the unpacked parameters. In fact, there seems to be a need for only one of these functions, as the distribution parameters are always the same.
However, it is impossible to simply specify a distribution “adopted_lognormal()” with parameters mu and sigma by overloading these _parse_args functions, as they are generated at runtime from a “parse_arg_template” and “dynamically attached” to the class instance. It is unclear which result this achieves which could not be achieved with appropriate use of *args and **kwargs; however, the disadvantage is obvious, as it blocks the standard OO mechanism of function overloading.
On top of this, the parse_args_rvs() template even calls self._argcheck_rvs(), which is a naming completely inconsistent with the other _argcheck function, as it does not check parameters, but unpacks them into the format required by the following steps. In fact, the rvs() function subsequently calls _arg_check() to actually change the distribution parameters.
Solution approach
A better approach (without major changes to the infrastructure) might be
•	Have one function which parses the distribution parameters and transforms them into the parametrization expected by the scipy.stats function
•	Have one function to translate this parametrization back into the “external” format.
The flow in all functions would be
•	Take parameters, pass them to _parse_arg() to get the standard parametrization
•	Apply _argcheck() to this parameter set
•	Rescale, call normalized function (like _pdf)
•	Rescale and return result
Fit would require additional functionality to map back, and to translate fixed parameters.
Code example
(restore_class_params just undoes the dynamic binding; instead of three parse functions only one would be required with minor changes in the code base.)
import scipy.stats as st
import types

def restore_class_params(obj, params):
    if isinstance(params, str):
        params = params.split(',')
    for p in params:
        setattr(obj, p, types.MethodType(getattr(obj.__class__, p), obj))

class norm_mu_sigma_gen(st._continuous_distns.norm_gen):

    def __init__(self, name=None, *args, **kwargs):
        if name is None:
            name = 'norm_mu_sigma'
        shapes = 'mu sigma'
        super().__init__(name=name, shapes=shapes, *args, **kwargs)
        restore_class_params(self, '_parse_args,_parse_args_stats,_parse_args_rvs')

    def _parse_args(self, mu, sigma, *args, loc=0, scale=1):
        return ((), loc+mu*scale, sigma*scale)

    def _parse_args_stats(self, mu, sigma, loc=0, scale=1, moments='mv'):
        return ((), loc+mu*scale, sigma*scale, moments)

    def _parse_args_rvs(self, mu, sigma, loc=0, scale=1, size=None):
        return self._argcheck_rvs(loc+mu*scale, sigma*scale, size=size)

if __name__ == '__main__':
    norm_mu_sigma = norm_mu_sigma_gen()
    print(norm_mu_sigma.stats(mu=1, sigma=2, moments='mv'))
    print(norm_mu_sigma.pdf(0, mu=1, sigma=2))
    print(norm_mu_sigma.cdf(0, mu=1, sigma=2))
    print(norm_mu_sigma.sf(0, mu=1, sigma=2))
    print(norm_mu_sigma.ppf(0.5, mu=1, sigma=2))
    print(norm_mu_sigma.isf(0.5, mu=1, sigma=2))
    print(norm_mu_sigma.moment(2, mu=1, sigma=2))
    data = norm_mu_sigma.rvs(mu=1, sigma=2, size=1000)
    print(norm_mu_sigma.fit(data))


Build Error (UglifyWriter)

Build Error (UglifyWriter)

Unexpected token: name (SUCCESS_HANDLERS)

I did some investigation and found that it could be this<EMAIL_ADDRESS>I believe this version is still using uglifyjs where it doesn't recognize ES6 syntax.
ember-cli-uglify has migrated to using terserjs, where it's a fork of uglifyjs that can recognize new ES6 syntax.
Please consider upgrading to the latest 2.2.0

I'm also seeing this issue. I have to downgrade to 0.6.12 to get things working.


[usbdev] Clarify/tidy alerts

Keep alerts even when stubbed, since registers persist. All alerts considered fatal; only one at present.
Comment: tidying up TODO; I think this is the intended behavior?

Rerunning failed jobs because the failure was a time out.


unable to install commandline tool

78297 warn optional Skipping failed optional dependency /chokidar/fsevents:
78298 warn notsup Not compatible with your operating system or architecture<EMAIL_ADDRESS>78299 verbose stack Error<EMAIL_ADDRESS>install: `node install.js`
78299 verbose stack spawn ENOENT
78299 verbose stack     at ChildProcess.<anonymous> (/usr/share/npm/lib/utils/spawn.js:17:16)
78299 verbose stack     at emitTwo (events.js:87:13)
78299 verbose stack     at ChildProcess.emit (events.js:172:7)
78299 verbose stack     at maybeClose (internal/child_process.js:821:16)
78299 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:211:5)
78300 verbose pkgid<EMAIL_ADDRESS>78301 verbose cwd /opt/api-spec-converter
78302 error Linux 4.15.0-36-generic
78303 error argv "/usr/bin/nodejs" "/usr/bin/npm" "install"
78304 error node v4.2.6
78305 error npm  v3.5.2
78306 error file sh
78307 error code ELIFECYCLE
78308 error errno ENOENT
78309 error syscall spawn
78310 error<EMAIL_ADDRESS>install: `node install.js`
78310 error spawn ENOENT
78311 error Failed at the<EMAIL_ADDRESS>install script 'node install.js'.
78311 error Make sure you have the latest version of node.js and npm installed.
78311 error If you do, this is most likely a problem with the puppeteer package,
78311 error not with npm itself.
78311 error Tell the author that this fails on your system:
78311 error     node install.js
78311 error You can get information on how to open an issue for this project with:
78311 error     npm bugs puppeteer
78311 error Or if that isn't available, you can get their info via:
78311 error     npm owner ls puppeteer
78311 error There is likely additional logging output above.
78312 verbose exit [ 1, true ]

Any help on how to resolve this issue. I installed latest npm, nodejs.

Was able to solve the issue after installing nodejs-legacy.


Update Yugabyte wait strategy

Update wait strategy by using a temporal table instead of select statement.
Also, make it compatible with version 2.18.

@HarshDaryani896 can you please take a look why test are failing? Thanks

@eddumelendez We are working on figuring out the reason of the failure. Meanwhile I figured that if we create a normal table instead of a temp table as part of the YSQL waitStrategy we will not get this failure.
I have attached a patch to create and drop a table, instead of creating a temp table in the YSQL waitStrategy. This should resolve the failure we are seeing.
RemoveTempTable.patch

Hey @eddumelendez I have created a new branch which has all the required changes including the above patch. Please let me know if you want me to create a new PR or if we can update the current PR. Thanks

@HarshDaryani896 feel free to raise a PR. I'm planning to include it for the next release. Thanks in advance

Hey @eddumelendez Thank you for the response.
I have created a new PR #7784 for this which has the above patch applied. We can close this one and go ahead and merge that PR.
Would it be possible for you to share ETA of the next release? Thanks.

Superseded by https://github.com/testcontainers/testcontainers-java/pull/7784


Biome Color Key Refactor

Update colors.yml

Have similar biomes / variants same colors
Make colors properly represent said biome

Done in c78f8d0