KNN Mahalanobis distance error

Hi,
When I use the Mahalanobis metric for KNN I always get the error "Must provide either V or VI for Mahalanobis distance" even when I provide V with metric_params. The same request works with sklearn.neighbors.

from pyod.models.knn import KNN
from pyod.utils.data import generate_data
from sklearn.neighbors import NearestNeighbors
import numpy as np

contamination = 0.1
n_train = 200
n_test = 100

X_train, y_train, X_test, y_test = generate_data(n_train=n_train, n_test=n_test, contamination=contamination)

#Doesn't work (Must provide either V or VI for Mahalanobis distance)
clf = KNN(algorithm='brute', metric='mahalanobis', metric_params={'V': np.cov(X_train)})
clf.fit(X_train)

#Works
nn = NearestNeighbors(algorithm='brute', metric='mahalanobis', metric_params={'V': np.cov(X_train)})
nn.fit(X_train)

Thanks for reporting this. It is due to the problem of passing parameters into KDTree.
Specifically, it is caused by the difference between the parameters of NearestNeighbors and KDTree...KDTree has a distinct way of using customized distance metrics.
I will fix it in this next few days and update you here.

Sorry for being late on this. I was exploring several options but get stuck by passing in customized metric to sklearn KD_tree. In PyOD, KNN detector uses a KD-tree internally.
I tried one solution to pass in mahalanobis distance:

metric = DistanceMetric.get_metric('mahalanobis', V=np.cov(X_test))
#Doesn't work (Must provide either V or VI for Mahalanobis distance)
clf = KNN(algorithm='brute', metric=metric.pairwise)
clf.fit(X_train)
#https://github.com/scikit-learn/scikit-learn/issues/8890

The reason is that I built a KD-tree and also a NearestNeighbors for KNN, which should be combined into one. Will provide an update later...
As an alternative, I will recommend you to check out MCD model in PyOD that uses Mahalanobis:

First fit a minimum covariance determinant model and then compute the
Mahalanobis distance as the outlier degree of the data

Hi can I ask if there will be a solution for the bug? Thanks

Hello @evanmiller29, hello @yzhao062,
any news on this issue? Am evaluating pyod and stumbled over this issue. Some update here would be great.
Thanks for your efforts and work.
All the best

@sdoering I am back to fix this one. Someone brought this into my attention yesterday (https://stackoverflow.com/q/55728669/4168429?sem=2). I will aim to provide a solution this week (doing some experiments now). Stay tuned :)

The bug is fixed by commit https://github.com/yzhao062/pyod/commit/db41e8e03e3901782eb68ff77ab95fc89e82bd92
The next release V0.7.0 will include this commit. See https://github.com/yzhao062/pyod/blob/development/examples/knn_mahalanobis_example.py for example.
Before the new version is officially released, you could overwrite the PyOD source file knn.py by https://github.com/yzhao062/pyod/blob/development/pyod/models/knn.py .
The latest commit is not yet pushed to master branch but development branch only (https://github.com/yzhao062/pyod/tree/development)

Closed by #84. Available in the latest version (v0.7.0).

When your using the function np.cov, you need to set the parameter rowvar to False like that :
np.cov(X_train, rowvar =False)

@lachhebo Yeah I think so. See the example provided here: https://github.com/yzhao062/pyod/blob/development/examples/knn_mahalanobis_example.py


Cannot composer create project anymore

A few weeks ago I could composer create project zendframework/zend-expressive-skeleton, but now I get Could not find package project with stability stable.
Also, when specifying  composer sees that as a version number.

Ok, so I messed up the command, it should read composer create-project (with the dash -)

What is the resolution here?
On 15 Jun 2017 3:59 p.m., "Bart McLeod"<EMAIL_ADDRESS>wrote:

Closed #162
https://github.com/zendframework/zend-expressive-skeleton/issues/162.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/zendframework/zend-expressive-skeleton/issues/162#event-1125149973,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJakIvBSCXixffaSRhGYyGZmllBy9Bpks5sETjBgaJpZM4N7QB4
.

@Ocramius it's a non-issue; just typo in running the command.

@Ocramius What @asgrim says.

Sorry, got the mails in a messed up order :-)


Printed line doesn't overwrite colon when pressing Enter in Ex mode

Problem:  Printed line no longer overwrites colon when pressing Enter in
Ex mode (after 9.1.0573).
Solution: Restore the behavior of pressing Enter in Ex mode.

thanks!


uv.lock source registry when using --extra-index-url and HTTP redirects

Summary
I used uv add with an extra-index-url to add a package that is not present in the extra-index-url registry.
I expected uv to list the URL of the registry where the package actually lives as the "source".
However, in case the registry returns HTTP 303 responses, uv lists the extra-index-url (and not the default index = PyPI) as the "source".
Is there some reasoning to listing the extra-index-url as "source" when it actually isn't?
Details
I have an internal index/registry (e.g. registry.loc/simple) at work (running pypiserver), which contains just a few internal packages. It does not contain any packages that are available from PyPI.
In order for those internal packages to be uv add-able, I have extra-index-url on my uv.toml config.
However, to my surprise uv.lock lists all the dependencies on my projects as coming from this internal registry. That is, the source registry has the following for packages that were actually fetched from PyPI:
source = { registry = "http://registry.loc/simple" }

Doing some digging, I found out that the registry returns an HTTP 303 response (which is the default behavior of pypiserver),
But uv doesn't list the redirected URL registry as the "source". My expectation is that for dependencies/sub-depdendencies fetched from PyPI after a redirect would list PyPI as the "source":
source = { registry = "https://pypi.org/simple" }

Workarounds

Remove extra-index-url from uv.toml and use it only when adding an internal package (e.g. my-lib)

This is not ideal as any PyPI-only dependencies of my-lib would still have the "wrong" source.

Add the --disable-fallback flag to pypiserver so an HTTP 404 response is returned instead.

Results in my expected behavior, but requires control over the registry (which may not be realistic for many uv users)

Environment
> uv --version
uv 0.4.6 (84f25e8cf 2024-09-05)

For full disclosure, here's a MRE.
Note that pydantic is not available from http://registry.loc/simple
uv init
uv add pydantic --extra-index-url http://registry.loc/simple

pyproject.toml
[project]
name = "uv-test"
version = "0.1.0"
description = "Add your description here"
readme = "README.md"
requires-python = ">=3.12"
dependencies = [
    "pydantic>=2.9.0",
]

uv.lock

When `registry.loc/simple` redirects (303)
version = 1
requires-python = ">=3.12"
resolution-markers = [
    "python_full_version < '3.13'",
    "python_full_version >= '3.13'",
]

[[package]]
name = "annotated-types"
version = "0.7.0"
source = { registry = "http://registry.loc/simple" }
sdist = { url = "https://files.pythonhosted.org/packages/ee/67/531ea369ba64dcff5ec9c3402f9f51bf748cec26dde048a2f973a4eea7f5/annotated_types-0.7.0.tar.gz", hash = "sha256:aff07c09a53a08bc8cfccb9c85b05f1aa9a2a6f23728d790723543408344ce89", size = 16081 }
wheels = [
    { url = "https://files.pythonhosted.org/packages/78/b6/6307fbef88d9b5ee7421e68d78a9f162e0da4900bc5f5793f6d3d0e34fb8/annotated_types-0.7.0-py3-none-any.whl", hash = "sha256:1f02e8b43a8fbbc3f3e0d4f0f4bfc8131bcb4eebe8849b8e5c773f3a1c582a53", size = 13643 },
]

[[package]]
name = "pydantic"
version = "2.9.0"
source = { registry = "http://registry.loc/simple" }
dependencies = [
    { name = "annotated-types" },
    { name = "pydantic-core" },
    { name = "typing-extensions" },
    { name = "tzdata" },
]
sdist = { url = "https://files.pythonhosted.org/packages/f6/8f/3b9f7a38caa3fa0bcb3cea7ee9958e89a9a6efc0e6f51fd6096f24cac140/pydantic-2.9.0.tar.gz", hash = "sha256:c7a8a9fdf7d100afa49647eae340e2d23efa382466a8d177efcd1381e9be5598", size = 768298 }
wheels = [
    { url = "https://files.pythonhosted.org/packages/54/38/95bdb5dfcebad2c11c88f7aa2d635fe53a0b7405ef39a6850c8bced455d4/pydantic-2.9.0-py3-none-any.whl", hash = "sha256:f66a7073abd93214a20c5f7b32d56843137a7a2e70d02111f3be287035c45370", size = 434325 },
]

[[package]]
name = "pydantic-core"
version = "2.23.2"
source = { registry = "http://registry.loc/simple" }
dependencies = [
    { name = "typing-extensions" },
]
sdist = { url = "https://files.pythonhosted.org/packages/5f/03/54e4961dfaed4804fea0ad73e94d337f4ef88a635e73990d6e150b469594/pydantic_core-2.23.2.tar.gz", hash = "sha256:95d6bf449a1ac81de562d65d180af5d8c19672793c81877a2eda8fde5d08f2fd", size = 401901 }
wheels = [
    { url = "https://files.pythonhosted.org/packages/8f/54/9c202171aca4a9f6596e1e2a6572ff7d707e2383a40605533c61487714a2/pydantic_core-2.23.2-cp312-cp312-macosx_10_12_x86_64.whl", hash = "sha256:4c83c64d05ffbbe12d4e8498ab72bdb05bcc1026340a4a597dc647a13c1605ec", size = 1845364 },
    { url = "https://files.pythonhosted.org/packages/9e/e3/5c29d8fa6dfabd7809fe623fd17959e1b672410681a8c3811eefa42b8051/pydantic_core-2.23.2-cp312-cp312-macosx_11_0_arm64.whl", hash = "sha256:6294907eaaccf71c076abdd1c7954e272efa39bb043161b4b8aa1cd76a16ce43", size = 1784382 },
    { url = "https://files.pythonhosted.org/packages/79/c3/4b003c9ed0f5f5e559823802ee7a3921de8aa50892bf179535d7695b2e76/pydantic_core-2.23.2-cp312-cp312-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:4a801c5e1e13272e0909c520708122496647d1279d252c9e6e07dac216accc41", size = 1791189 },
    { url = "https://files.pythonhosted.org/packages/3f/3b/0c0377c5833093a1758e711387bbe5a5e30511fe9d4afe225be185527aa1/pydantic_core-2.23.2-cp312-cp312-manylinux_2_17_armv7l.manylinux2014_armv7l.whl", hash = "sha256:cc0c316fba3ce72ac3ab7902a888b9dc4979162d320823679da270c2d9ad0cad", size = 1780431 },
    { url = "https://files.pythonhosted.org/packages/4a/88/18a541e2f9cbcef4b44b90a2ba98d85e109d91bc7f3b2210d271f66e6d8f/pydantic_core-2.23.2-cp312-cp312-manylinux_2_17_ppc64le.manylinux2014_ppc64le.whl", hash = "sha256:6b06c5d4e8701ac2ba99a2ef835e4e1b187d41095a9c619c5b185c9068ed2a49", size = 1976902 },
    { url = "https://files.pythonhosted.org/packages/e3/bd/6c98ca605130ee51438d812133d04ddb403fb1a8a93490f9a1a7e269a4a7/pydantic_core-2.23.2-cp312-cp312-manylinux_2_17_s390x.manylinux2014_s390x.whl", hash = "sha256:82764c0bd697159fe9947ad59b6db6d7329e88505c8f98990eb07e84cc0a5d81", size = 2638882 },
    { url = "https://files.pythonhosted.org/packages/ad/fc/6b4f95c64bbeadaa6f84cffb51f469f6fdd61215d97b4ec8d89d027e574b/pydantic_core-2.23.2-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:2b1a195efd347ede8bcf723e932300292eb13a9d2a3c1f84eb8f37cbbc905b7f", size = 2111180 },
    { url = "https://files.pythonhosted.org/packages/95/4c/d4a355237ffa3dae28c2224bea9e09d4af69f346bf7611ebb66d8e930574/pydantic_core-2.23.2-cp312-cp312-manylinux_2_5_i686.manylinux1_i686.whl", hash = "sha256:b7efb12e5071ad8d5b547487bdad489fbd4a5a35a0fc36a1941517a6ad7f23e0", size = 1904338 },
    { url = "https://files.pythonhosted.org/packages/83/d6/9f41db9ab2727a050fdac5e56a9e792260aa29e29affa98b4df8a06fd588/pydantic_core-2.23.2-cp312-cp312-musllinux_1_1_aarch64.whl", hash = "sha256:5dd0ec5f514ed40e49bf961d49cf1bc2c72e9b50f29a163b2cc9030c6742aa73", size = 1968729 },
    { url = "https://files.pythonhosted.org/packages/f8/bd/0e795ea5eaf26a96d9691faae43603e00de3dbec6339e3710652f5feae12/pydantic_core-2.23.2-cp312-cp312-musllinux_1_1_x86_64.whl", hash = "sha256:820f6ee5c06bc868335e3b6e42d7ef41f50dfb3ea32fbd523ab679d10d8741c0", size = 2120748 },
    { url = "https://files.pythonhosted.org/packages/be/7d/48ddf9f084b5de1d47c6bcccfeafe80900ceac975ebdf1fe374fd18654e5/pydantic_core-2.23.2-cp312-none-win32.whl", hash = "sha256:3713dc093d5048bfaedbba7a8dbc53e74c44a140d45ede020dc347dda18daf3f", size = 1725557 },
    { url = "https://files.pythonhosted.org/packages/e1/d7/ef3558714427b385f84e22a224c4641b4869f9031f733e83cea6f0eb0154/pydantic_core-2.23.2-cp312-none-win_amd64.whl", hash = "sha256:e1895e949f8849bc2757c0dbac28422a04be031204df46a56ab34bcf98507342", size = 1914466 },
    { url = "https://files.pythonhosted.org/packages/91/42/085e27e5c32220531bbd966c2888c74a595ac35cd7e52a71d3302d041b71/pydantic_core-2.23.2-cp313-cp313-macosx_10_12_x86_64.whl", hash = "sha256:da43cbe593e3c87d07108d0ebd73771dc414488f1f91ed2e204b0370b94b37ac", size = 1845030 },
    { url = "https://files.pythonhosted.org/packages/05/ac/3faf5fd29b221bb7c0aa4bc3fe1a763fb2d38b08d7b5961daeee96f13a8e/pydantic_core-2.23.2-cp313-cp313-macosx_11_0_arm64.whl", hash = "sha256:64d094ea1aa97c6ded4748d40886076a931a8bf6f61b6e43e4a1041769c39dd2", size = 1784493 },
    { url = "https://files.pythonhosted.org/packages/83/52/cc692fc65098904a6bdb13cc502b590d0597718069a8ffa8bfdea680657c/pydantic_core-2.23.2-cp313-cp313-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:084414ffe9a85a52940b49631321d636dadf3576c30259607b75516d131fecd0", size = 1791193 },
    { url = "https://files.pythonhosted.org/packages/53/a9/d7be95020bf6a57ada1d5d18172369ad92e9779dccf9a497b22863d77dd8/pydantic_core-2.23.2-cp313-cp313-manylinux_2_17_armv7l.manylinux2014_armv7l.whl", hash = "sha256:043ef8469f72609c4c3a5e06a07a1f713d53df4d53112c6d49207c0bd3c3bd9b", size = 1780169 },
    { url = "https://files.pythonhosted.org/packages/10/42/16bee4df87a315a8ae3962e5c2251612bced849e624f850e811a2e6097da/pydantic_core-2.23.2-cp313-cp313-manylinux_2_17_ppc64le.manylinux2014_ppc64le.whl", hash = "sha256:3649bd3ae6a8ebea7dc381afb7f3c6db237fc7cebd05c8ac36ca8a4187b03b30", size = 1976946 },
    { url = "https://files.pythonhosted.org/packages/f8/04/8be7280cf309c256bd9fa124fbe15f730b9659ee87d89a40b7da14c6818f/pydantic_core-2.23.2-cp313-cp313-manylinux_2_17_s390x.manylinux2014_s390x.whl", hash = "sha256:6db09153d8438425e98cdc9a289c5fade04a5d2128faff8f227c459da21b9703", size = 2638776 },
    { url = "https://files.pythonhosted.org/packages/24/7b/e102b2073b08b36f78d7336859fe8d09e7483eded849cf12bd3db66f441d/pydantic_core-2.23.2-cp313-cp313-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:5668b3173bb0b2e65020b60d83f5910a7224027232c9f5dc05a71a1deac9f960", size = 2110994 },
    { url = "https://files.pythonhosted.org/packages/90/29/ba00e3e262597203ae95c5eb81d02ce96afcda26b6960484b376a1e5ac59/pydantic_core-2.23.2-cp313-cp313-manylinux_2_5_i686.manylinux1_i686.whl", hash = "sha256:1c7b81beaf7c7ebde978377dc53679c6cba0e946426fc7ade54251dfe24a7604", size = 1904219 },
    { url = "https://files.pythonhosted.org/packages/4b/ef/3899865e9f2e30b79c1ed9498a71898f33b1ca2a08f3b1619eaee754aa85/pydantic_core-2.23.2-cp313-cp313-musllinux_1_1_aarch64.whl", hash = "sha256:ae579143826c6f05a361d9546446c432a165ecf1c0b720bbfd81152645cb897d", size = 1968804 },
    { url = "https://files.pythonhosted.org/packages/19/e9/69742d9c71d08251184584c2b99d436490c78f7487840e588394b1ce97a9/pydantic_core-2.23.2-cp313-cp313-musllinux_1_1_x86_64.whl", hash = "sha256:19f1352fe4b248cae22a89268720fc74e83f008057a652894f08fa931e77dced", size = 2120574 },
    { url = "https://files.pythonhosted.org/packages/5c/fc/7f89094bf3a645fb5b312b6ae907f3b04b6e0d1e37f6eb4c057276d80703/pydantic_core-2.23.2-cp313-none-win32.whl", hash = "sha256:e1a79ad49f346aa1a2921f31e8dbbab4d64484823e813a002679eaa46cba39e1", size = 1725472 },
    { url = "https://files.pythonhosted.org/packages/43/13/39f4b60884174a95c69e3dd196c77a1757c3857841f2567d240bcbd1cf0f/pydantic_core-2.23.2-cp313-none-win_amd64.whl", hash = "sha256:582871902e1902b3c8e9b2c347f32a792a07094110c1bca6c2ea89b90150caac", size = 1914614 },
]

[[package]]
name = "typing-extensions"
version = "4.12.2"
source = { registry = "http://registry.loc/simple" }
sdist = { url = "https://files.pythonhosted.org/packages/df/db/f35a00659bc03fec321ba8bce9420de607a1d37f8342eee1863174c69557/typing_extensions-4.12.2.tar.gz", hash = "sha256:1a7ead55c7e559dd4dee8856e3a88b41225abfe1ce8df57b7c13915fe121ffb8", size = 85321 }
wheels = [
    { url = "https://files.pythonhosted.org/packages/26/9f/ad63fc0248c5379346306f8668cda6e2e2e9c95e01216d2b8ffd9ff037d0/typing_extensions-4.12.2-py3-none-any.whl", hash = "sha256:04e5ca0351e0f3f85c6853954072df659d0d13fac324d0072316b67d7794700d", size = 37438 },
]

[[package]]
name = "tzdata"
version = "2024.1"
source = { registry = "http://registry.loc/simple" }
sdist = { url = "https://files.pythonhosted.org/packages/74/5b/e025d02cb3b66b7b76093404392d4b44343c69101cc85f4d180dd5784717/tzdata-2024.1.tar.gz", hash = "sha256:2674120f8d891909751c38abcdfd386ac0a5a1127954fbc332af6b5ceae07efd", size = 190559 }
wheels = [
    { url = "https://files.pythonhosted.org/packages/65/58/f9c9e6be752e9fcb8b6a0ee9fb87e6e7a1f6bcab2cdc73f02bb7ba91ada0/tzdata-2024.1-py2.py3-none-any.whl", hash = "sha256:9068bc196136463f5245e51efda838afa15aaeca9903f49050dfa2679db4d252", size = 345370 },
]

[[package]]
name = "uv-test"
version = "0.1.0"
source = { virtual = "." }
dependencies = [
    { name = "pydantic" },
]

[package.metadata]
requires-dist = [{ name = "pydantic", specifier = ">=2.9.0" }]

When `registry.loc/simple` does not redirect (404)
version = 1
requires-python = ">=3.12"
resolution-markers = [
    "python_full_version < '3.13'",
    "python_full_version >= '3.13'",
]

[[package]]
name = "annotated-types"
version = "0.7.0"
source = { registry = "https://pypi.org/simple" }
sdist = { url = "https://files.pythonhosted.org/packages/ee/67/531ea369ba64dcff5ec9c3402f9f51bf748cec26dde048a2f973a4eea7f5/annotated_types-0.7.0.tar.gz", hash = "sha256:aff07c09a53a08bc8cfccb9c85b05f1aa9a2a6f23728d790723543408344ce89", size = 16081 }
wheels = [
    { url = "https://files.pythonhosted.org/packages/78/b6/6307fbef88d9b5ee7421e68d78a9f162e0da4900bc5f5793f6d3d0e34fb8/annotated_types-0.7.0-py3-none-any.whl", hash = "sha256:1f02e8b43a8fbbc3f3e0d4f0f4bfc8131bcb4eebe8849b8e5c773f3a1c582a53", size = 13643 },
]

[[package]]
name = "pydantic"
version = "2.9.0"
source = { registry = "https://pypi.org/simple" }
dependencies = [
    { name = "annotated-types" },
    { name = "pydantic-core" },
    { name = "typing-extensions" },
    { name = "tzdata" },
]
sdist = { url = "https://files.pythonhosted.org/packages/f6/8f/3b9f7a38caa3fa0bcb3cea7ee9958e89a9a6efc0e6f51fd6096f24cac140/pydantic-2.9.0.tar.gz", hash = "sha256:c7a8a9fdf7d100afa49647eae340e2d23efa382466a8d177efcd1381e9be5598", size = 768298 }
wheels = [
    { url = "https://files.pythonhosted.org/packages/54/38/95bdb5dfcebad2c11c88f7aa2d635fe53a0b7405ef39a6850c8bced455d4/pydantic-2.9.0-py3-none-any.whl", hash = "sha256:f66a7073abd93214a20c5f7b32d56843137a7a2e70d02111f3be287035c45370", size = 434325 },
]

[[package]]
name = "pydantic-core"
version = "2.23.2"
source = { registry = "https://pypi.org/simple" }
dependencies = [
    { name = "typing-extensions" },
]
sdist = { url = "https://files.pythonhosted.org/packages/5f/03/54e4961dfaed4804fea0ad73e94d337f4ef88a635e73990d6e150b469594/pydantic_core-2.23.2.tar.gz", hash = "sha256:95d6bf449a1ac81de562d65d180af5d8c19672793c81877a2eda8fde5d08f2fd", size = 401901 }
wheels = [
    { url = "https://files.pythonhosted.org/packages/8f/54/9c202171aca4a9f6596e1e2a6572ff7d707e2383a40605533c61487714a2/pydantic_core-2.23.2-cp312-cp312-macosx_10_12_x86_64.whl", hash = "sha256:4c83c64d05ffbbe12d4e8498ab72bdb05bcc1026340a4a597dc647a13c1605ec", size = 1845364 },
    { url = "https://files.pythonhosted.org/packages/9e/e3/5c29d8fa6dfabd7809fe623fd17959e1b672410681a8c3811eefa42b8051/pydantic_core-2.23.2-cp312-cp312-macosx_11_0_arm64.whl", hash = "sha256:6294907eaaccf71c076abdd1c7954e272efa39bb043161b4b8aa1cd76a16ce43", size = 1784382 },
    { url = "https://files.pythonhosted.org/packages/79/c3/4b003c9ed0f5f5e559823802ee7a3921de8aa50892bf179535d7695b2e76/pydantic_core-2.23.2-cp312-cp312-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:4a801c5e1e13272e0909c520708122496647d1279d252c9e6e07dac216accc41", size = 1791189 },
    { url = "https://files.pythonhosted.org/packages/3f/3b/0c0377c5833093a1758e711387bbe5a5e30511fe9d4afe225be185527aa1/pydantic_core-2.23.2-cp312-cp312-manylinux_2_17_armv7l.manylinux2014_armv7l.whl", hash = "sha256:cc0c316fba3ce72ac3ab7902a888b9dc4979162d320823679da270c2d9ad0cad", size = 1780431 },
    { url = "https://files.pythonhosted.org/packages/4a/88/18a541e2f9cbcef4b44b90a2ba98d85e109d91bc7f3b2210d271f66e6d8f/pydantic_core-2.23.2-cp312-cp312-manylinux_2_17_ppc64le.manylinux2014_ppc64le.whl", hash = "sha256:6b06c5d4e8701ac2ba99a2ef835e4e1b187d41095a9c619c5b185c9068ed2a49", size = 1976902 },
    { url = "https://files.pythonhosted.org/packages/e3/bd/6c98ca605130ee51438d812133d04ddb403fb1a8a93490f9a1a7e269a4a7/pydantic_core-2.23.2-cp312-cp312-manylinux_2_17_s390x.manylinux2014_s390x.whl", hash = "sha256:82764c0bd697159fe9947ad59b6db6d7329e88505c8f98990eb07e84cc0a5d81", size = 2638882 },
    { url = "https://files.pythonhosted.org/packages/ad/fc/6b4f95c64bbeadaa6f84cffb51f469f6fdd61215d97b4ec8d89d027e574b/pydantic_core-2.23.2-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:2b1a195efd347ede8bcf723e932300292eb13a9d2a3c1f84eb8f37cbbc905b7f", size = 2111180 },
    { url = "https://files.pythonhosted.org/packages/95/4c/d4a355237ffa3dae28c2224bea9e09d4af69f346bf7611ebb66d8e930574/pydantic_core-2.23.2-cp312-cp312-manylinux_2_5_i686.manylinux1_i686.whl", hash = "sha256:b7efb12e5071ad8d5b547487bdad489fbd4a5a35a0fc36a1941517a6ad7f23e0", size = 1904338 },
    { url = "https://files.pythonhosted.org/packages/83/d6/9f41db9ab2727a050fdac5e56a9e792260aa29e29affa98b4df8a06fd588/pydantic_core-2.23.2-cp312-cp312-musllinux_1_1_aarch64.whl", hash = "sha256:5dd0ec5f514ed40e49bf961d49cf1bc2c72e9b50f29a163b2cc9030c6742aa73", size = 1968729 },
    { url = "https://files.pythonhosted.org/packages/f8/bd/0e795ea5eaf26a96d9691faae43603e00de3dbec6339e3710652f5feae12/pydantic_core-2.23.2-cp312-cp312-musllinux_1_1_x86_64.whl", hash = "sha256:820f6ee5c06bc868335e3b6e42d7ef41f50dfb3ea32fbd523ab679d10d8741c0", size = 2120748 },
    { url = "https://files.pythonhosted.org/packages/be/7d/48ddf9f084b5de1d47c6bcccfeafe80900ceac975ebdf1fe374fd18654e5/pydantic_core-2.23.2-cp312-none-win32.whl", hash = "sha256:3713dc093d5048bfaedbba7a8dbc53e74c44a140d45ede020dc347dda18daf3f", size = 1725557 },
    { url = "https://files.pythonhosted.org/packages/e1/d7/ef3558714427b385f84e22a224c4641b4869f9031f733e83cea6f0eb0154/pydantic_core-2.23.2-cp312-none-win_amd64.whl", hash = "sha256:e1895e949f8849bc2757c0dbac28422a04be031204df46a56ab34bcf98507342", size = 1914466 },
    { url = "https://files.pythonhosted.org/packages/91/42/085e27e5c32220531bbd966c2888c74a595ac35cd7e52a71d3302d041b71/pydantic_core-2.23.2-cp313-cp313-macosx_10_12_x86_64.whl", hash = "sha256:da43cbe593e3c87d07108d0ebd73771dc414488f1f91ed2e204b0370b94b37ac", size = 1845030 },
    { url = "https://files.pythonhosted.org/packages/05/ac/3faf5fd29b221bb7c0aa4bc3fe1a763fb2d38b08d7b5961daeee96f13a8e/pydantic_core-2.23.2-cp313-cp313-macosx_11_0_arm64.whl", hash = "sha256:64d094ea1aa97c6ded4748d40886076a931a8bf6f61b6e43e4a1041769c39dd2", size = 1784493 },
    { url = "https://files.pythonhosted.org/packages/83/52/cc692fc65098904a6bdb13cc502b590d0597718069a8ffa8bfdea680657c/pydantic_core-2.23.2-cp313-cp313-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:084414ffe9a85a52940b49631321d636dadf3576c30259607b75516d131fecd0", size = 1791193 },
    { url = "https://files.pythonhosted.org/packages/53/a9/d7be95020bf6a57ada1d5d18172369ad92e9779dccf9a497b22863d77dd8/pydantic_core-2.23.2-cp313-cp313-manylinux_2_17_armv7l.manylinux2014_armv7l.whl", hash = "sha256:043ef8469f72609c4c3a5e06a07a1f713d53df4d53112c6d49207c0bd3c3bd9b", size = 1780169 },
    { url = "https://files.pythonhosted.org/packages/10/42/16bee4df87a315a8ae3962e5c2251612bced849e624f850e811a2e6097da/pydantic_core-2.23.2-cp313-cp313-manylinux_2_17_ppc64le.manylinux2014_ppc64le.whl", hash = "sha256:3649bd3ae6a8ebea7dc381afb7f3c6db237fc7cebd05c8ac36ca8a4187b03b30", size = 1976946 },
    { url = "https://files.pythonhosted.org/packages/f8/04/8be7280cf309c256bd9fa124fbe15f730b9659ee87d89a40b7da14c6818f/pydantic_core-2.23.2-cp313-cp313-manylinux_2_17_s390x.manylinux2014_s390x.whl", hash = "sha256:6db09153d8438425e98cdc9a289c5fade04a5d2128faff8f227c459da21b9703", size = 2638776 },
    { url = "https://files.pythonhosted.org/packages/24/7b/e102b2073b08b36f78d7336859fe8d09e7483eded849cf12bd3db66f441d/pydantic_core-2.23.2-cp313-cp313-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:5668b3173bb0b2e65020b60d83f5910a7224027232c9f5dc05a71a1deac9f960", size = 2110994 },
    { url = "https://files.pythonhosted.org/packages/90/29/ba00e3e262597203ae95c5eb81d02ce96afcda26b6960484b376a1e5ac59/pydantic_core-2.23.2-cp313-cp313-manylinux_2_5_i686.manylinux1_i686.whl", hash = "sha256:1c7b81beaf7c7ebde978377dc53679c6cba0e946426fc7ade54251dfe24a7604", size = 1904219 },
    { url = "https://files.pythonhosted.org/packages/4b/ef/3899865e9f2e30b79c1ed9498a71898f33b1ca2a08f3b1619eaee754aa85/pydantic_core-2.23.2-cp313-cp313-musllinux_1_1_aarch64.whl", hash = "sha256:ae579143826c6f05a361d9546446c432a165ecf1c0b720bbfd81152645cb897d", size = 1968804 },
    { url = "https://files.pythonhosted.org/packages/19/e9/69742d9c71d08251184584c2b99d436490c78f7487840e588394b1ce97a9/pydantic_core-2.23.2-cp313-cp313-musllinux_1_1_x86_64.whl", hash = "sha256:19f1352fe4b248cae22a89268720fc74e83f008057a652894f08fa931e77dced", size = 2120574 },
    { url = "https://files.pythonhosted.org/packages/5c/fc/7f89094bf3a645fb5b312b6ae907f3b04b6e0d1e37f6eb4c057276d80703/pydantic_core-2.23.2-cp313-none-win32.whl", hash = "sha256:e1a79ad49f346aa1a2921f31e8dbbab4d64484823e813a002679eaa46cba39e1", size = 1725472 },
    { url = "https://files.pythonhosted.org/packages/43/13/39f4b60884174a95c69e3dd196c77a1757c3857841f2567d240bcbd1cf0f/pydantic_core-2.23.2-cp313-none-win_amd64.whl", hash = "sha256:582871902e1902b3c8e9b2c347f32a792a07094110c1bca6c2ea89b90150caac", size = 1914614 },
]

[[package]]
name = "typing-extensions"
version = "4.12.2"
source = { registry = "https://pypi.org/simple" }
sdist = { url = "https://files.pythonhosted.org/packages/df/db/f35a00659bc03fec321ba8bce9420de607a1d37f8342eee1863174c69557/typing_extensions-4.12.2.tar.gz", hash = "sha256:1a7ead55c7e559dd4dee8856e3a88b41225abfe1ce8df57b7c13915fe121ffb8", size = 85321 }
wheels = [
    { url = "https://files.pythonhosted.org/packages/26/9f/ad63fc0248c5379346306f8668cda6e2e2e9c95e01216d2b8ffd9ff037d0/typing_extensions-4.12.2-py3-none-any.whl", hash = "sha256:04e5ca0351e0f3f85c6853954072df659d0d13fac324d0072316b67d7794700d", size = 37438 },
]

[[package]]
name = "tzdata"
version = "2024.1"
source = { registry = "https://pypi.org/simple" }
sdist = { url = "https://files.pythonhosted.org/packages/74/5b/e025d02cb3b66b7b76093404392d4b44343c69101cc85f4d180dd5784717/tzdata-2024.1.tar.gz", hash = "sha256:2674120f8d891909751c38abcdfd386ac0a5a1127954fbc332af6b5ceae07efd", size = 190559 }
wheels = [
    { url = "https://files.pythonhosted.org/packages/65/58/f9c9e6be752e9fcb8b6a0ee9fb87e6e7a1f6bcab2cdc73f02bb7ba91ada0/tzdata-2024.1-py2.py3-none-any.whl", hash = "sha256:9068bc196136463f5245e51efda838afa15aaeca9903f49050dfa2679db4d252", size = 345370 },
]

[[package]]
name = "uv-test"
version = "0.1.0"
source = { virtual = "." }
dependencies = [
    { name = "pydantic" },
]

[package.metadata]
requires-dist = [{ name = "pydantic", specifier = ">=2.9.0" }]

I would suggest inverting the order, such that your registry is the index-url and PyPI is the extra-index-url. In that case, we'll look at PyPI first, and only look at your registry for packages that don't exist on PyPI.

Unfortunately, swapping out index-url and extra-index-url is not a feasible workaround in my case as the internal registry must have higher priority (checked first) as it contains a few packages that have name clashes with PyPI packages (completely different packages which happen to have a name that is already used in PyPI). Currently, the better workaround in my case is adding --disable-fallback to the instance of pypiserver running the internal registry.
However, my main points here are that the lock contents should:

Show the URL of the registry the package was actually fetched from.
Not change based on whether a registry returns 303 or 404 when a package is not found.
Not change based on whether extra-index-url was used or not when adding packages that do not depend on the extra-index-url at all (see the Pydantic example above).

All points boil down to how HTTP redirects are handled when writing the lock file.

Honestly I'm not sure that it'd be correct for us to write the redirected URL to the lockfile. We write the correct paths for the actual distribution files of course, but it's true that we found the package by querying the pypiserver URL. It would be strange if users saw registries in the lockfile that weren't included as index URLs at all in their configuration.

Fair enough. I can see how that could be strange in case the redirected registry wasn't the same as index-url (which happens to be my case).
I guess it could be argued what I considered an uv issue was just a pypiserver misconfiguration.
Also, this should become less of an issue once https://github.com/astral-sh/uv/issues/171 is implemented.
Please feel free to close if the current behavior with regards to the different 303/404 handling is considered correct/expected.


Angular version issue

Hi,
I have tried to run
bower install angular-surveys --save
But I'm getting the following message when it compiles
Unable to find a suitable version for angular, please choose one by typing one of the numbers below:
    1) angular#1.4.14 which resolved to 1.4.14 and is required by angular-mocks#1.4.14
    2) angular#1.5.8 which resolved to 1.5.8 and is required by angular-animate#1.5.8, angular-aria#1.5.8, angular-messages#1.5.8, angular-sanitize#1.5.8, angular-surveys
    3) angular#>=1.2.26 <1.6 which resolved to 1.5.8 and is required by angular-translate#2.12.1
    4) angular#>=1.2.x which resolved to 1.5.8 and is required by angular-ui-sortable#0.13.4
    5) angular#>=1.4.0 which resolved to 1.5.8 and is required by angular-bootstrap#1.3.3
    6) angular#>=1.0.6 which resolved to 1.5.8 and is required by angular-elastic#2.5.1
    7) angular#>=1.3.x which resolved to 1.5.8 and is required by angular-surveys#0.9.1
    8) angular#^1.4.8 which resolved to 1.5.8 and is required by angular-material#1.1.1

Prefix the choice with ! to persist it to bower.json

Any ideas.
Many thanks!

Removed the bower.json file and ran it again. This now works :)

How did removing the bower.json file fix it?

How did removing the bower.json file fix it?

you can find it in the main project.


doc: POSIX arch: Add link to POSIX OS abstraction

In the note about the relationship between the POSIX arch and the POSIX OS abstraction, add a link.

@aescolar  & @stephanosio Thanks for the review, merge and the good work you are doing :)


[GOBBLIN-1217] start metrics reporting with a few map-reduce properties

Dear Gobblin maintainers,
Please accept this PR. I understand that it will not be reviewed until I have checked off all the steps below!
@sv2000 @jack-moseley please review
JIRA

[x] My PR addresses the following Gobblin JIRA issues and references them in the PR title. For example, "[GOBBLIN-XXX] My Gobblin PR"

https://issues.apache.org/jira/browse/GOBBLIN-1217

Description

[x] Here are some details about my PR, including screenshots (if applicable):
Add a few map/reduce task related configs in building metric reporter. One of the use case can be that each mapper/reducer's metrics can be analyzed separately

Tests

[x] My PR adds the following unit tests OR does not need testing for this extremely good reason:
trivial changes

Commits

[x] My commits all reference JIRA issues in their subject lines, and I have squashed multiple commits if they address the same issue. In addition, my commits follow the guidelines from "How to write a good git commit message":

Subject is separated from body by a blank line
Subject is limited to 50 characters
Subject does not end with a period
Subject uses the imperative mood ("add", not "adding")
Body wraps at 72 characters
Body explains "what" and "why", not "how"

Codecov Report

Merging #3065 into master will increase coverage by 0.00%.
The diff coverage is 0.00%.

@@            Coverage Diff            @@
##             master    #3065   +/-   ##
=========================================
  Coverage     45.86%   45.87%
  Complexity     9423     9423
=========================================
  Files          1963     1963
  Lines         74742    74752   +10
  Branches       8310     8314    +4
=========================================
+ Hits          34282    34289    +7
  Misses        37231    37231
- Partials       3229     3232    +3

Impacted Files
Coverage Δ
Complexity Δ

...pache/gobblin/configuration/ConfigurationKeys.java
0.00% <ø> (ø)
0.00 <0.00> (ø)

...ava/org/apache/gobblin/metrics/GobblinMetrics.java
31.21% <0.00%> (-0.89%)
30.00 <0.00> (ø)

...n/java/org/apache/gobblin/yarn/YarnHelixUtils.java
18.42% <ø> (ø)
4.00 <0.00> (ø)

.../modules/scheduler/GobblinServiceJobScheduler.java
57.14% <0.00%> (-2.12%)
24.00% <0.00%> (-2.00%)

.../org/apache/gobblin/cluster/GobblinTaskRunner.java
63.46% <0.00%> (-0.33%)
35.00% <0.00%> (ø%)

.../apache/gobblin/runtime/api/JobExecutionState.java
80.37% <0.00%> (+0.93%)
24.00% <0.00%> (ø%)

...java/org/apache/gobblin/metrics/MetricContext.java
80.91% <0.00%> (+1.52%)
50.00% <0.00%> (ø%)

...lin/restli/throttling/ZookeeperLeaderElection.java
72.22% <0.00%> (+2.22%)
13.00% <0.00%> (ø%)

...in/java/org/apache/gobblin/cluster/HelixUtils.java
37.50% <0.00%> (+5.83%)
14.00% <0.00%> (+2.00%)

Continue to review full report at Codecov.

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


Implement APIv2 BruteForce

Change the BruteForce interface to follow the changes in BVH.

Did you look at performance?

I have not done it yet. We don't really have a good benchmark for the brute force, only benchmarks/brute_force_vs_bvh and examples/brute_force.

A100 results (OACISS/Saturn), brute_force_vs_bvh benchmark, 1,000,000 primitives, 30,000 predicates:
float

Dimension
master (2abcb6c2)
branch (fab0039a)

3
0.23
0.18

2
0.23
0.17

6
0.54
0.28

double

Dimension
master (2abcb6c2)
branch (fab0039a)

2
0.41
0.28

3
0.51
0.32

6
1.01
0.56

This is definitely a consequence of both storing less data for the benchmark (points instead of boxes) as well as the faster intersection routine (point/sphere vs box/sphere).


fix(databricks): correct databricks permissions checks

fix(databricks): correct databricks permissions checks
Reason for Proposed Changes

databricks_permissions checks were not working properly

Proposed Changes

Move not operator
Add test files (containing tests where multiple permissions are present in a single file)

Notes

We do not fully understand the way the not operator works, but found out that doing like so brings the desired behavior :shrug: Some more explanations would be appreciated !

I submit this contribution under the Apache-2.0 license.

you forgot to update assets/queries/terraform/databricks/databricks_permissions/test/positive_expected_result.json

@gabriel-cx If you have an explanation, I'd be interested


Set 'Open in Portal' as the first action on the context menu for resource groups

Storage Explorer Version: 1.13.0
Build: 20200401.4
Branch: rel/1.13.0
Platform/OS: Windows 10/ Linux Ubuntu 16.04/ macOS High Sierra
Architecture: ia32/x64
Regression From: Not a regression
Steps to reproduce:

Expand Disks -> Select one resource group.
Right click the resource group -> Check its context menu.

Expect Experience:
'Open in Portal' is the first action on the context menu.
Actual Experience:
'Open in Portal' is not the first action on the context menu.

More Info:

'Open in Portal' is the first action on the context menu for storage account/ Cosmos DB account/ Data Lake Storage Gen1.

We don't plan to promote "Open in Portal". We want to let people try using it in Storage Explorer first.


admintool.sh problem: TypeError: 'zip' object does not support item deletion

Python 3.6.3
make debug builds successfully
workspace/cita$ admintool.sh
Step 1: ********************************************************
Start generating private Key for Node 0 !
[PrivateKey Path] :  /media/mingrui/960EVO/workspace/cita/node0
End generating private Key for Node 0 !
Start creating Network Node 0 Configuration!
Traceback (most recent call last):
  File "/media/mingrui/960EVO/workspace/cita/target/install/scripts/admintool/create_network_config.py", line 34, in <module>
    main()
  File "/media/mingrui/960EVO/workspace/cita/target/install/scripts/admintool/create_network_config.py", line 22, in main
    del ip_list[nid]
TypeError: 'zip' object does not support item deletion

Only python2.7 are supported.


Error: unsupported BodyInit type when attempting to post data to endpoint accepting the "application/x-www-form-urlencoded" content-type

After updating to the latest version of frisbee to make use of the new abort features, I've encountered errors with posting data in a url-encoded format. I'm downgrading for the time being as I have no issues with v2.0.6.
An example of the offending code is as follows:
api
      .post(constants.routes.authentication.post_login(), {
        body: qs.stringify(credentials),
        headers: {
          "Content-Type": "application/x-www-form-urlencoded"
        },
        abortToken
      })

The end point accepts this format, and this format alone. One thing to note is this error is being thrown before the request to the server has been sent.
Version: 3.0.2
Stack Trace:
unsupported BodyInit type
- node_modules/react-native/Libraries/vendor/core/whatwg-fetch.js:279:24 in _initBody
- node_modules/react-native/Libraries/vendor/core/whatwg-fetch.js:398:19 in Request
- node_modules/react-native/Libraries/vendor/core/whatwg-fetch.js:486:32 in <unknown>
- node_modules/promise/setimmediate/core.js:45:7 in tryCallTwo
- node_modules/promise/setimmediate/core.js:200:23 in doResolve
- node_modules/promise/setimmediate/core.js:66:12 in Promise
- node_modules/react-native/Libraries/vendor/core/whatwg-fetch.js:485:23 in fetch
* /Users/chrisevans/Documents/GitHub/busybees-up-toolkit/node_modules/abortcontroller-polyfill/dist/polyfill-patch-fetch.js:434:53 in abortableFetch
- node_modules/raven-js/src/raven.js:1474:21 in <unknown>
* /Users/chrisevans/Documents/GitHub/busybees-up-toolkit/node_modules/regenerator-runtime/runtime.js:45:44 in tryCatch
* /Users/chrisevans/Documents/GitHub/busybees-up-toolkit/node_modules/regenerator-runtime/runtime.js:271:30 in invoke
* /Users/chrisevans/Documents/GitHub/busybees-up-toolkit/node_modules/frisbee/lib/index.js:3:103 in asyncGeneratorStep
* /Users/chrisevans/Documents/GitHub/busybees-up-toolkit/node_modules/frisbee/lib/index.js:5:212 in _next
* /Users/chrisevans/Documents/GitHub/busybees-up-toolkit/node_modules/frisbee/lib/index.js:5:369 in <unknown>
- node_modules/promise/setimmediate/core.js:45:7 in tryCallTwo
- node_modules/promise/setimmediate/core.js:200:23 in doResolve
- node_modules/promise/setimmediate/core.js:66:12 in Promise
* /Users/chrisevans/Documents/GitHub/busybees-up-toolkit/node_modules/frisbee/lib/index.js:5:108 in <unknown>
* /Users/chrisevans/Documents/GitHub/busybees-up-toolkit/node_modules/regenerator-runtime/runtime.js:45:44 in tryCatch
* /Users/chrisevans/Documents/GitHub/busybees-up-toolkit/node_modules/regenerator-runtime/runtime.js:271:30 in invoke
* /Users/chrisevans/Documents/GitHub/busybees-up-toolkit/node_modules/frisbee/lib/index.js:3:103 in asyncGeneratorStep
* /Users/chrisevans/Documents/GitHub/busybees-up-toolkit/node_modules/frisbee/lib/index.js:5:212 in _next
* /Users/chrisevans/Documents/GitHub/busybees-up-toolkit/node_modules/frisbee/lib/index.js:5:369 in <unknown>
- node_modules/promise/setimmediate/core.js:45:7 in tryCallTwo
- node_modules/promise/setimmediate/core.js:200:23 in doResolve
- node_modules/promise/setimmediate/core.js:66:12 in Promise
* /Users/chrisevans/Documents/GitHub/busybees-up-toolkit/node_modules/frisbee/lib/index.js:5:108 in <unknown>
- node_modules/promise/setimmediate/core.js:37:14 in tryCallOne
- node_modules/promise/setimmediate/core.js:123:25 in <unknown>
- ... 8 more stack frames from framework internals

This is a very serious issue. This line breaks everything now:
https://github.com/niftylettuce/frisbee/blob/master/src/index.js#L289
If you pass a JSON string it will be spread into letters. If you pas a FormData object it will be spread as a simple JS object.
Normally, you should pass a FormData object as a body and the the fetch implementation should handle it (whatwg-fetch)

Thank you @elvinas-engagecraft and @Anitorious, will have this patched, tested, and released soon.

I believe I'm running into a similar issue when attempting to post to a json:api endpoint, e.g.:
      api.post('/entity', {
        headers: {
          'content-type': 'application/vnd.api+json',
        },
        body: JSON.stringify(entityData),
      });

Yields:
    ...
    "659": "i",
   ...(truncated to the first 10000 characters)

[Unhandled promise rejection: Error: Error: unsupported BodyInit type]

Submitted a PR. This probably exposes a hole in test coverage, as well?

Released on npm as<EMAIL_ADDRESS>🎉

This is actually resolved as of v3.1.2, not v3.1.1.  See https://github.com/niftylettuce/frisbee/commit/45f46140f379dc2e2175d8c52afd60f7c24a2dfa.


Add crate: Rust-CUDA

My rust-cuda project was announced recently, with the goal of making that nice GPU Computing box yellow or green :)
However, im not sure what specific crate to include, because the project is many crates that contribute to rust gpu computing.

Addressed in #114


Nested route ErrorBoundaries can cause "Unexpected Server Error" during SSR, if error is thrown below Outlet

Reproduction
Go to https://stackblitz.com/edit/remix-run-remix-e3e3jp
Click link (child HAS boundary) Throw below outlet (crash)
System Info
System:
    OS: Linux 5.0 undefined
    CPU: (8) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
    Memory: 0 Bytes / 0 Bytes
    Shell: 1.0 - /bin/jsh
  Binaries:
    Node: 18.20.3 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 10.2.3 - /usr/local/bin/npm
    pnpm: 8.15.6 - /usr/local/bin/pnpm
  npmPackages:
    @remix-run/dev: * => 2.9.2
    @remix-run/node: * => 2.9.2
    @remix-run/react: * => 2.9.2
    @remix-run/serve: * => 2.9.2
    vite: ^5.1.0 => 5.2.13

Used Package Manager
npm
Expected Behavior
A route with ErrorBoundary export should render the error boundary when runtime exception is thrown, regardless if exception was encountered above or below <Outlet />
Actual Behavior
When

parent route has ErrorBoundary
child route also has ErrorBoundary
in parent route a component after the <Outlet /> throws an exception during SSR
Remix will fail server render with "Unexpected Server Error"

I'm not sure there's anything Remix can do about this internally unfortunately.  React doesn't support Error Boundaries during SSR so Remix is doing it's best to simulate them and tracks how deep we are able to render so we know the deepest successfully rendered route with an error boundary.  That way when we catch an error from SSR we can look "up" to find the nearest rendered ancestor error boundary and we assign the error to that route and SSR a second time.
The problem with this approximation is that it's done in the components, but we don't really know when they start and finish rendering.  So when you do:
<Throw throws={err === "1"} />
<Outlet />
<Throw throws={err === "2"} />

You successfully render <Outlet/> and that sets the withboundary route as the deepest successfully rendered route.  Then after <Outlet> renders, it throws during the second <Throw> rendering and incorrectly thinks it should try to render that error in the withboundary route ErrorBoundary.
When it tries to do so, it renders the Layout component a second time on the way down to the boundary and it throws again and then Remix gives up and returns the 500 Unexpected Server Error.
I don't know if there's a way for us to detect after the withboundary child renders fine that the layout thrw after the Outlet so we can reset the tracked boundary?
One option you could do in userland today would be to use a Suspense boundary to catch SSR errors and retry client rendering.  Using this in your component will cause effectively an empty  <Outlet/> to render on the server and then it will retry full rendering on the client and that will properly bubble errors:
      <React.Suspense>
        <Throw throws={err === "1"} />
        <Outlet />
        <Throw throws={err === "2"} />
      </React.Suspense>

I wonder if in the future, Remix could leverage this Suspense behavior to try to replace our current "best effort" approach.
The RFC above also hints at this being better handled ion the future:

Although it's possible there will later be a separate error boundary API for the server, in the meantime, this change provides a natural way for the app to recover from error.


Added announcements of KubeCon NA & China

Solves issue #29183
Added upcoming announcements about KubeCon North America & China.

@sftim I kept the start time 10 days before the event.
I guess, I made quite the needed changes.

@sftim I took the images from here
https://events.linuxfoundation.org/wp-content/uploads/2020/11/KubeCon_NA_2021_web_web-logo-white-1.svg
https://www.lfasiallc.com/wp-content/uploads/2021/01/KubeCon-China-2020-logos_white.svg
Are this correct?

/label tide/merge-method-squash

/approve
with steering hat for regular kubecon announcements
/hold for docs lgtm

@sftim Can you tell me what is the error?

/approve
/lgtm
looks like @liggitt signed off as well. So sig-docs folks, please remove hold when ready.

/hold cancel
/approve


Use bubble correction as default

It is not used as default because high resolution moist baroclinic wave breaks when using bubble correction, see this build for example. Here is a plot of vertical velocity at some upper level at day 40, and it seems there is some oscillation.

Reopening this for the record. We can investigate it when we have the time.

Note: @tapios suggested that we look at shallow water experiments to see if there are similar patterns.

@simonbyrne, any issues with extruded spaces here?

We should probably have an enable_bubble test in ClimaCore that uses the same space that ClimaAtmos uses by default, on a sphere.

ClimaCore shallow-water simulation with the same target horizontal resolution (ne = 16), run for 15 days, no bubble:

animation:
https://user-images.githubusercontent.com/39932030/218188488-37408420-b984-488b-99b0-2f7ccc5671e6.mp4
final screenshot:

Numerical results:

[ Info: ("Solution L₂ norm at time t = 1296000: ", 10007.370840423204)
[ Info: ("Fluid volume at time t = 1296000: ", 5.101084466643369e18)

Same simulation, with bubble:

animation:
https://user-images.githubusercontent.com/39932030/218188815-106dd81a-9592-47ee-a4b5-5d481d1cd076.mp4

final screenshot:

Numerical results:

[ Info: ("Solution L₂ norm at time t = 1296000: ", 10007.37084042841)
[ Info: ("Fluid volume at time t = 1296000: ", 5.101084473414422e18)

Volume Errors:
julia> day_15_volume_with_bubble = 5.101084473414422e18
5.101084473414422e18

julia> day_15_volume_no_bubble = 5.101084466643369e18
5.101084466643369e18

ulia> rel_error = abs(day_15_volume_with_bubble - day_15_volume_no_bubble)/day_15_volume_no_bubble
1.3273751078377083e-9

@simonbyrne, any issues with extruded spaces here?

I think Simon was referring to this bit of code, but we simply multiply the horizontal J and WJ with the vertical ones. We don't override or recompute them. So there should be no issue there.

Can we see a flow that is more dynamically unstable (e.g., Bickley jet) and thus generates smaller flow scales?


PlotHeatMap.m

Thank you for sharing. I found an error while running this program.
In the 60th line of the function PlotHeatMap. m, the function clim is not defined. I think you want to use the function zlim, but after changing clim to zlim, the heatmap is not displayed. Therefore, I suggest commenting out lines 55 to 60 of the code.

Thanks for raising this issue. The function "clim" is only available for Matlab version 2021 or later. The corresponding lines are commented out as you suggested, so that the users with older Matlab version can also use the toolbox. Many thanks!


Suggestions for milestone 2.0

Hi Nico! Welcome back.
I had all but given up on this project.
What are your plans for milestone 2.0?
I had some changes in the pipeline, but lost momentum when there was no response to my pull requests.
I was working on a proper MarkupExtension Parser based on Irony (https://irony.codeplex.com/).
I also have an idea on how to fix the mixed tab/spaces issue.

What about moving this project to an organization and add a couple of members?
That way it will not rely on one person not being busy.

I'd love to discuss this, maybe take the discussion offline for a bit? drop me an email<EMAIL_ADDRESS>and we'll discuss the future of this extension :)


Allow ignoring warnings in package's dependencies

Rationale:
I'd generally like to include docs validation in CI, and require "no warnings".
Problem:
Can't do that easily since my dependencies sometimes have warnings themselfes. E.g. here's some swift-nio warnings:
/Users/ktoso/code/swift-distributed-actors/.build/checkouts/swift-nio/Sources/NIOCore/AsyncAwaitSupport.swift:271:24: warning: Topic reference 'Swift/AsyncSequence' couldn't be resolved. No local documentation matches this reference.

While building https://github.com/apple/swift-distributed-actors documentation.
With NIO it's easy and I can reach out and fix the warnings, but that's not the case in general and other projects might end up breaking "our" CI if they introduce warnings and are not as strict about them.
Should there be some flag to "ignore warnings in .build/... (dependencies) packages?

For now I guess I'll "grep fu" my way out of this by ignoring warnings in .build folders.

I think this issue is out of the scope of swift-docc 🤔. And maybe more relevant on swift itself, swift-package-manager or Xcode.

Maybe SwiftPM, I keep bringing up this issue since years I guess... I'll poke other folks as well.

@ktoso How are you detecting that a docc build completed with warnings? Are you grepping the output?
It would be nice for docc to have an --warnings-as-errors to promote warnings to errors, which would be opt-in and for which the overarching build system would only pass to docc when building non-dependencies.

Related to https://github.com/apple/swift-package-manager/issues/5569

@ktoso As an alternative to grepping the logs that works today; if you pass the --emit-digest flag to docc convert then DocC will write a few additional files into the output location, one of which is diagnostics.json which contains this information about each diagnostic: Digest.Diagnostic definition, OpenAPI spec. The diagnostic digest information is mostly aimed at other systems who want to present diagnostics form DocC without parsing the logs for severity, source, and location information—so it may be a bit overkill—but it should be easy to tell if there were warnings or errors.

I see, that's pretty good -- I'll use this, thank you!


fix(leadspace): remove image from centered leadspace with no image

Related Ticket(s)
#5417
Description
Image displaying when rendering without image. Added condition to check for image defaultSrc
Changelog
Changed

update condition for _renderImage()

Thanks @ariellalgilmore! The broken image doesn't show up anymore, but the background color still defaults to the gradient instead of remaining under the g100 theme.
I think this could be fixed by changing the breakpoint here to sm since the Web Components seems to be handling the gradient differently than in React.

Thanks @ariellalgilmore! The broken image doesn't show up anymore, but the background color still defaults to the gradient instead of remaining under the g100 theme.
I think this could be fixed by changing the breakpoint here to sm since the Web Components seems to be handling the gradient differently than in React.

oh forgot to add that! thanks @IgnacioBecerra!

@ariellalgilmore can you check Percy results? Looks like the opacity layer isn't behaving properly in some places.

Is it me or the opacity layer a bit bolder than it should be?

Is it me or the opacity layer a bit bolder than it should be?

haha yeah it's not just you. Working on this. the styles are a bit weird


canvas is in the floating window, the content display is missing

As shown in the figure, when the left side is displayed in the suspended window, the title is missing, resulting in total ignorance of the main content of each card when used
Hope this BUG can be fixed, thanks

Can you attach your canvas file?  I'm not seeing any issues like this with mine.  Please also check in sandbox with no themes/CSS snippets/other plugins to make sure it's not a CSS or plugin issue.  Also, report your Obsidian version, installer etc. from the "Show debug info" command in Obsidian.  Thanks.

BBB.md

Test1.canvas.md
So these are the files, and you need to delete the .md
Here is an experiment in an empty library   without any CSS and other plugins

SYSTEM INFO:
Obsidian version: v1.6.7
Installer version: v1.6.7
Operating system: Windows 10 Enterprise 10.0.19045
Login status: not logged in
Insider build toggle: off
Live preview: on
Base theme: dark
Community theme: none
Snippets enabled: 17
Restricted mode: off
Plugins installed: 98
Plugins enabled: 1
1: Hover Editor v0.11.21
RECOMMENDATIONS:
Custom theme and snippets: for cosmetic issues, please first try updating your theme and disabling your snippets. If still not fixed, please try to make the issue happen in the Sandbox Vault or disable community theme and snippets.
Community plugins: for bugs, please first try updating all your plugins to latest. If still not fixed, please try to make the issue happen in the Sandbox Vault or disable community plugins.

I have just upgraded my obsidian to 1.7.6. the problem no longer appears and I will closeSorry to bother youBecause the obsidian of the new Ben has some plug-ins that are not available, I returned 1.6Thank you for this plug-in, which is the most important plug-in for me in obsidian

Just so you know, the issue (which I am able to repro with your test files even on Obsidian 1.5.8), is that the Obsidian default style sheet hides .inline-title blocks when they are in a hover preview or embed.  This isn't a bug in Hover Editor per se, just a styling problem.  You can override the style with something like:
.hover-popover.hover-editor .inline-title { display: block }


Player statistics

There have been classes for player statistics since day zero, including support for storing the data. Now we only have to use them and display the values...

I agree this would be great ! It seemed weird when starting to use the app that there is a logic for creating players... but no actual use of them !
Would you be ok if I started working on it also next month ? I could start by simply saving statistics after each game ends, and displaying an average personal score for each player but also when clicking one player, displaying its scores against typical (most played against) opponents ?

Feel free to record whatever you think is nice. As mentioned in the description there is already a ˋ PlayerStatisticsˋ class that you could use when you start working.


Focus recent doesn't work if space changed display

I have come across this unexpected behaviour (at least for me):
Steps to reproduce:

Change active space to another display
yabai -m space --display 2
Focus recent
yabai -m space --focus recent

The following message is printed on the console:
cannot focus an already focused space.
Expected outcome:
The space that was selected before starting this whole process is selected (recent)
Thank you for your support!

I have two spaces in display 1 [1:coding, 2:browsing] and I have two spaces in display 2 [1:discord, 2:youtube].
when both spaces 1:coding, 1:discord visible and I switch from 1:coding to 2:youtube, executing yabai -m space --focus recent doesn't work and gives the same issue. But switching between visible displays in both displays works fine.
I have this issue since v4.0.0 but is not a major issue.


License

As far I see the project does not contain any Open Source license. Is it intentional?

commited https://github.com/f111fei/react-native-unity-view/commit/e0beb7ad5a34922cd72454ee801d6e3534ae75a9


Updated doc when scanning private repository

PR as requested here : https://github.com/aquasecurity/trivy-azure-pipelines-task/pull/25#issuecomment-1514238443

 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.


simplifying log ingestion guide to use a single node cluster

Signed-off-by: Christopher Manning<EMAIL_ADDRESS>Description
Simplifying login ingestion guide to use a single node opensearch cluster.
Issues

related to: #690

Check List

[x] New functionality includes testing.
[x] New functionality has been documented.

[x] New functionality has javadoc added

[x] Commits are signed with a real name per the DCO

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #695 (8fab9d5) into main (f991d0c) will decrease coverage by 0.16%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##               main     #695      +/-   ##
============================================
- Coverage     91.65%   91.49%   -0.17%
  Complexity      606      606
============================================
  Files            75       75
  Lines          1834     1834
  Branches        152      152
============================================
- Hits           1681     1678       -3
- Misses          117      120       +3
  Partials         36       36

Impacted Files
Coverage Δ

...java/com/amazon/dataprepper/pipeline/Pipeline.java
88.57% <0.00%> (-4.29%)
:arrow_down:

Continue to review full report at Codecov.

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


T6392: backport test for sagitta

T6392: backport test for sagitta
Change Summary

T6392: backport test for sagitta
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes)
[ ] Migration from an old Vyatta component to vyos-1x, please link to related PR inside obsoleted component
[ ] Other (please describe):

Related Task(s)

https://vyos.dev/T6392
Related PR(s)

Component(s) name

Proposed changes

How to test

Smoketest result

Checklist:

[ ] I have read the CONTRIBUTING document
[ ] I have linked this PR to one or more Phabricator Task(s)
[ ] I have run the components SMOKETESTS if applicable
[ ] My commit headlines contain a valid Task id
[ ] My change requires a change to the documentation
[ ] I have updated the documentation accordingly

@Mergifyio backport sagitta


Add direct GitHub links to corresponding MDX source files on each page

To encourage others to contribute to the docs, we should include a link to the source on GitHub for each documentation page. From there, people can choose to fork this repo and edit the file in a branch using GitHub's web editor, or at the very least, they will know where they can find the content of the doc on their filesystem.
This should be dynamically done with Astro, avoiding a scenario where we need to define the URL manually for each page.

Hi mikimih, could you implement the design for the "Edit page" button on each page and open a PR?

@FilipVecek pinging you as well

@ivan-burazin @osslate
here is PR:
https://github.com/daytonaio/docs/pull/28


Lolcode hello world

Lolcode hello world

Thanks for the pr! I removed haskell though as its already added!

Oh sorry did not noticed, LOLCode is fine?

Thanks for the pr! I removed haskell though as its already added!

Oh sorry did not noticed, LOLCode is fine?

Yep they are fine now!


ResultSet fetch size missing in toolbar

System information:

OS: Windows 7x64
DBeaver: <IP_ADDRESS>908191349

Describe the problem you're observing:
The ResultSet fetch size limit is missing in the main toolbar after updating.

I have reset the UI settings and even deleted the workbench.xmi file, but to no avail. I know that I can set the limit under "Connection configuration > Result Sets > ResultSet fetch size" but this is quite inconvenient.
I tried editing the perspective in the "Customize Perspective" menu but I cannot find the correct option. I did notice that under "Tool Bar Visibility > Transaction monitor" there are 2 options that are grayed out:

Since 6.1.0 version fetch size input has been moved to the bottom toolbar

Since 6.1.0 version fetch size input has been moved to the bottom toolbar

OK, I see where it is now. However, I had version 6.1.4 before updating and the input was at the top; only after I updated to 6.1.5 did the location change to the bottom toolbar.


SubstitutionMap cleanups

Please test with following pull request:
https://github.com/apple/swift-lldb/pull/133
@swift-ci Please smoke test


Interface Dispatch support

Added by the interface dispatch feature in commit https://github.com/dotnet/corert/commit/811a3232872e0ac3835b932c0ebbb7a130c11623.

We still need to port the Unix assembly code portions of dispatch, so I'll leave this issue open for now.

With https://github.com/dotnet/corert/pull/684 this feature is now supported across all three platforms.


UI for importing CSV files

This PR adds a basic UI around importing CSV files. You can pick the source you want to import against and then paste in a CSV url from S3 to kick off an Import job. On the show screen, you have to refresh to see progress, but it will tell you when it's done (in-progress vs finished).
What I've done here is just happy path - I haven't done anything about ensuring that errors are handled. My thought was that I'd come at that in a different PR, but maybe that should be here? Not sure what's typical at Artsy for features like this.
Note: this work was done on top of #101 so that it didn't look completely dumb. But it still does look pretty dumb. 😝

Niiiice! Would love to see some screenshots or gifs! 😛

@starsirius here ya go! 😄

It's a real thing!


Homogenise wording

resolves #167 #174 #202 #166
fix a part of #204

@flavens Each issue, which is resolved in a PR, needs is own keyword. Your description resolves #167 #174 #202 #166 closed the first issue only, here #167


implement storing credentials in keychain

[id,password] maybe? or do we need the email? see https://swiftcast.tv/articles/dead-simple-keychain-access

We definitely need

id
password
token

in case the app is reinstalled. Otherwise we'd need to call /users/getIdByMail (which is not implemented yet).


Support RBD object size when registering new ceph images

Author Name: OpenNebula Systems Support Team (OpenNebula Systems Support Team)
Original Redmine Issue: 4663, https://dev.opennebula.org/issues/4663
Original Date: 2016-07-20

None

Doesn't say that this is fixed, might need a reopen

Reopening may mislead the meaning of "size" in the title


I can't get during to work with window streams created using until

I'm having trouble using during with a time window stream created using until.  This works fine:
periodic(1)
|> during(
  at(0, at(5))
) ...

however using various window streams derived from until doesn't seem to work for me:
periodic(1)
|> during(
  never() |> until(at(5))
) ...

Hey @micahscopes, I think the key difference between the first and second example is the first creates a higher-order stream (a stream of streams) whereas the second example does not. During utilizes the higher-order nature to determine when to start subscribing (when the "inner" stream has been emitted) and then when to stop when the "inner" stream has emitted its own value.
I hope that helps to understand the difference

Oh wow... that makes sense, and yes that did it.  I changed the second example to the following and it worked as intended:
periodic(1)
|> during(
  never() |> until(at(5)) |> now
) ...


Error out if rootfs type is not layers

The image spec requries that
MUST be set to layers. Implementations MUST generate an error if
they encounter a unknown value while verifying or unpacking an image.
```
The image-tool should act as the image spec says.

Signed-off-by: Lei Jiang<EMAIL_ADDRESS>

LGTM

it's checked in JSON Schema,need to check it here？

On Thu, Oct 20, 2016 at 11:57:24PM -0700, Zhou Hao wrote:

it's checked in JSON Schema…

It is checked in JSON Schema since opencontainers/image-spec#358, which landed a day after this PR.  So once we bump the vendored image-spec dependency to pull in opencontainers/image-spec#358 we can revert this PR.  I think we want a policy for handling these image-spec validation bugs cleanly going forward (opencontainers/image-spec#406).

It is checked in JSON Schema since opencontainers/image-spec#358, which landed a day after this PR.
I think these fixed values（Such as SchemaVersion and MediaType,and so on） should be checked in JSON Schema.

I think these fixed values（Such as SchemaVersion and MediaType,and so on） should be checked in JSON Schema.

On Fri, Oct 21, 2016 at 12:20:36AM -0700, Zhou Hao wrote:

I think these fixed values (Such as SchemaVersion and MediaType,and so on) should be checked in JSON Schema.

And in image-spec's master, they are.  But in image-tool's master (pulling in opencontainers/image-spec@7e6e2f76d6, v1.0.0-rc1~18), they are not (and are checked by the code which landed via this PR).  Once image-spec cuts v1.0.0.rc2 and image-tools bumps its dependency to pull in that release, we can drop the local check.


Artifactory collector throwing 415 error while executing AQL query

2018-06-22 13:25:02,780 INFO  c.c.d.collector.CollectorTask - Fetched repos                    2s
2018-06-22 13:25:02,780 INFO  c.c.d.collector.CollectorTask - New repos               0        0s
2018-06-22 14:14:24,578 ERROR c.c.d.c.DefaultArtifactoryClient - Error with REST url: http://XXXXXXXXXXX:8081/artifactory/api/search/aql
2018-06-22 14:14:24,579 ERROR c.c.d.c.DefaultArtifactoryClient - 415 Unsupported Media Type
2018-06-22 14:14:24,589 ERROR o.s.s.s.TaskUtils$LoggingErrorHandler - Unexpected error occurred in scheduled task.
java.lang.NullPointerException: null
at com.capitalone.dashboard.collector.DefaultArtifactoryClient.getArtifacts(Unknown Source) ~[classes/:na]
at com.capitalone.dashboard.collector.ArtifactoryCollectorTask.addNewArtifacts(ArtifactoryCollectorTask.java:181) ~

@jagadeeshchirasani : looks like the REST url: http://XXXXXXXXXXX:8081/artifactory/api/search/aql
is expecting a different Content-Type. I am looking at the code base, and the content type being set is "text/plain". I will have to check what content-type is expecting and get back to you. In the meanwhile, if you are able to install "Fiddler", please do that. This will allow you to inspect the network traffic. And form there, please share the header information for this url. Thanks !

@jagadeeshchirasani : I just checked, and the api does expect "text/plain". Please do confirm what you are seeing on Fiddler, share the headers and the pay load. Thanks !

@jagadeeshchirasani My apologies for not having followed up on this.
The error is being thrown in the method "makeRestPost()" in the class "DefaultArtifactoryClient".
If you are able to put log statements in that method, and print out the "body" (Payload) of the post rest call being made, we can figure out if there is something wrong with the message. It has to be in text/plain format. Thanks.

@jagadeeshchirasani Any updates on this at all?

@jagadeeshchirasani Wanted to check one last time, if you have any updates on this at all? Thanks.

@jagadeeshchirasani Since we didn't hear back from you, I am assuming this issue is resolved at your end, and so closing this issue. Thanks !


Update README.md

Add Database Testing to index.
use DatabaseMigrations; instead of use RefreshDatabase; for laravel 5.6 compatibility issue (#1475)

@Smolevich close this please.
Thanks.

Since Database Testing is now in README, I'm closing this PR


Connection options in template toml files

Addresses #727.  The toml file parsing doesn't actually distinguish between config.toml and secrets.toml, so the options can really go in either.  Added some comments to the templates in init.js to encourage safe use (and added missing options).

This change is

:+1:


vertical hd.divider gets height of 0

Describe the bug
The example vertical hd.divider code in the app doesn't work because the default height=100% leads to a height of 0 (one of those wonderful mysteries of css).
Reproduce
The example code in the hyperdiv docs only works because of the flex styling of an ancestor element several levels higher than the example code. You can reproduce this bug in the hd.divider documents by setting the display to block for that ancestor element. Here's a screenshot, showing the bug and the ancestor element relative to the divider component. Note how there is no divider showing between item one and two:

Test case
Here's an app:
import hyperdiv as hd

router = hd.router()

@router.route("/")
def home():
    with hd.hbox():
        hd.text("default height=100% prevents the divider from showing ==>")
        hd.divider(vertical=True, spacing=1)
        hd.text("<=== right there")

    with hd.hbox():
        hd.text("setting height explicitly works ==>")
        hd.divider(vertical=True, spacing=1, height=1)
        hd.text("<== right there")

def main():
    router.run()

hd.run(main)

Thanks! I think if Hyperdiv sets the default height to auto instead of 100% for sl-divider[vertical] it will fix this issue.


Add missing docs for some PKCS12 functions

Some functions listed in include/openssl/pkcs12.h are missing documentation.

[X] documentation is added or updated

https://github.com/openssl/openssl/blob/master/util/openssl-update-copyright
util/openssl-update-copyright —help

The script updates only the end year. For new files, just specify 2019, no range.

Congrats - you have been NITTED :)

Anything else needed for this?

ping

ping

ping @openssl/omc

Squashed the commits and merged to master as eb389a75


Terraform minor upgrade research

Bumped Terraform from 0.12.6 to 0.12.31.
Bumped azurerm provider from 1.38 to 1.44.
Bumped AWS provider from 2.26 to 2.70.1
Fix for epiphany-platform#1569.
Added changelog.

Closing as we are moving forward with major upgrade from pull #2852 based on research in #2825.


⚠ Doshipui has degraded performance

In 97c1733, Doshipui (https://дошипуй.рф/) experienced degraded performance:

HTTP code: 200
Response time: 8779 ms

Resolved: Doshipui performance has improved in 924e11e after 19 minutes.


Task/non majors

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

26 of 26 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.7%) to 76.128%

Totals

Change from base Build<PHONE_NUMBER>:
0.7%

Covered Lines:
641

Relevant Lines:
842

💛  - Coveralls


Recommendation: Simplify NPM/Node code sharing

Proposal
Support typescript.definition in package.json of node packages as a part of module resolution.
Example
Consider this simple NPM package : https://www.npmjs.com/package/example-typescript-a (src: https://github.com/TypeStrong/atom-typescript-examples/tree/master/node/node_modules/example-typescript-a)
It is super simple to use from atom-typescript. Open any typescript file in atom-typescript, if you have done npm install example-typescript-a then you can just use it without any additional configuration: E.g.

import a = require('example-typescript-a');

var num = a.foo.a;
var str = a.foo.b;
console.log(num,str)

import bar = require("example-typescript-a/dist/bar");
console.log(bar.bar);

import bas = require("example-typescript-a/dist/bas");
console.log(bas.bas);

sample usage
How it works
This is because example-typescript-a specifies a location of a definition using typescript.definition :
{
    "name": "cool-module",
    "version": "1.2.3",
    "typescript": {
        "definition": "dist/cool-module.d.ts"
    }
}

And we look at node_modules up its directory and read package.json for typescript.definition, for each such module we implicitly include this definition file as a part of the current project.
Creating such a module
Creating such a module example-typescript-a is also super easy. All you need to do is a package.json like you would with any NPM package (we care about name, typescript.definition and optionally main) and tell us that you plan to use this package.json from tsconfig. Docs : https://github.com/TypeStrong/atom-typescript/blob/master/docs/tsconfig.md#package
Based on this we can create the correct typescript.definition file for you on build f6 :

Sample package.json
Sample tsconfig.json
Sample .d.ts created

Future
If such a module depends on tsd definitions OR other projects that have their own typescript.definition we need a resolution algorithm for that something like take latest and ignore all others. Plan:

we do some smart stuff in reading exported d.ts not giving TypeScript the external reference comments (e.g. node.d.ts here https://github.com/TypeStrong/atom-typescript-examples/blob/master/node/node_modules/example-typescript-b/definition/sample-b.d.ts) And instead pointing to our own .d.ts if we have it in our Typings.

/cc @csnover

:+1:

I certainly like dts-generator, and having support for it in Atom Typescript is awesome. Thanks @csnover and @basarat :rose:
If you're not afraid to npm install -g tsd@next (i.e. v0.6), you can already use tsd link to achieve a similar effect: it uses typescript.definition in package.json.
I'm sure you know that already, but it may help others coming here.
However, I fear that going the dts-generator-road (i.e. the 'wrap modules in declare module "..." road') is not going to work for the more general case of having multiple modules and especially multiple versions of them.
See https://github.com/Microsoft/TypeScript/issues/2568#issuecomment-94414591 (rather lengthy, sorry...) for the reasoning.

The proposal we have is to use typings (or possibly types) see #2338. i know tsd is using typescript.defntions, now the question is, what is the advantages/disadvantageous of using the same name?

@basarat, this looks like it should be subsumed by #2338; do you agree?

Agreed :rose:

Thanks :bow:

now the question is, what is the advantages/disadvantageous of using the same name?

Use the new name. Its clear that its a different feature then and we can phase out what I did previously :+1:


mxnet problem

[11:10:10] src/base.cc:51: Upgrade advisory: this mxnet has been built against cuda library version 9000, which is older than the oldest version tested by CI (10000).  Set MXNET_CUDA_LIB_CHECKING=0 to quiet this warning.
learning rate from lr_scheduler has been overwritten by learning_rate in optimizer.
Traceback (most recent call last):
File "./experiments/deeplab/deeplab_train_test.py", line 23, in
train.main()
File "./experiments/deeplab/../../deeplab/train.py", line 209, in main
config.TRAIN.begin_epoch, config.TRAIN.end_epoch, config.TRAIN.lr, config.TRAIN.lr_step)
File "./experiments/deeplab/../../deeplab/train.py", line 203, in train_net
arg_params=arg_params, aux_params=aux_params, begin_epoch=begin_epoch, num_epoch=end_epoch)
File "./experiments/deeplab/../../deeplab/core/module.py", line 976, in fit
self.update_metric(eval_metric, data_batch.label)
File "./experiments/deeplab/../../deeplab/core/module.py", line 1068, in update_metric
self._curr_module.update_metric(eval_metric, labels)
File "./experiments/deeplab/../../deeplab/core/module.py", line 665, in update_metric
self._exec_group.update_metric(eval_metric, labels)
File "./experiments/deeplab/../../deeplab/core/DataParallelExecutorGroup.py", line 490, in update_metric
eval_metric.update(labels, texec.outputs)
File "/usr/local/anaconda3/envs/py27/lib/python2.7/site-packages/mxnet/metric.py", line 363, in update
metric.update(labels, preds)
File "./experiments/deeplab/../../deeplab/core/metric.py", line 28, in update
pred = pred.asnumpy().reshape((pred.shape[0], pred.shape[1], -1)).transpose((0, 2, 1))
File "/usr/local/anaconda3/envs/py27/lib/python2.7/site-packages/mxnet/ndarray/ndarray.py", line 2535, in asnumpy
ctypes.c_size_t(data.size)))
File "/usr/local/anaconda3/envs/py27/lib/python2.7/site-packages/mxnet/base.py", line 255, in check_call
raise MXNetError(py_str(_LIB.MXGetLastError()))
mxnet.base.MXNetError: [11:10:13] src/operator/fusion/fused_op.cu:604: Check failed: compileResult == NVRTC_SUCCESS (5 vs. 0) : NVRTC Compilation failed. Please set environment variable MXNET_USE_FUSION to 0.
nvrtc: error: invalid value for --gpu-architecture (-arch)
Stack trace:
[bt] (0) /usr/local/anaconda3/envs/py27/lib/python2.7/site-packages/mxnet/libmxnet.so(+0x6b41eb) [0x7f78887981eb]
[bt] (1) /usr/local/anaconda3/envs/py27/lib/python2.7/site-packages/mxnet/libmxnet.so(+0x44fb5a6) [0x7f788c5df5a6]
[bt] (2) /usr/local/anaconda3/envs/py27/lib/python2.7/site-packages/mxnet/libmxnet.so(+0x4505d87) [0x7f788c5e9d87]
[bt] (3) /usr/local/anaconda3/envs/py27/lib/python2.7/site-packages/mxnet/libmxnet.so(+0x37d69b9) [0x7f788b8ba9b9]
[bt] (4) /usr/local/anaconda3/envs/py27/lib/python2.7/site-packages/mxnet/libmxnet.so(+0x37e33d5) [0x7f788b8c73d5]
[bt] (5) /usr/local/anaconda3/envs/py27/lib/python2.7/site-packages/mxnet/libmxnet.so(+0x37bf6d1) [0x7f788b8a36d1]
[bt] (6) /usr/local/anaconda3/envs/py27/lib/python2.7/site-packages/mxnet/libmxnet.so(+0x37c2c10) [0x7f788b8a6c10]
[bt] (7) /usr/local/anaconda3/envs/py27/lib/python2.7/site-packages/mxnet/libmxnet.so(+0x37c2ea6) [0x7f788b8a6ea6]
[bt] (8) /usr/local/anaconda3/envs/py27/lib/python2.7/site-packages/mxnet/libmxnet.so(+0x37bde84) [0x7f788b8a1e84]
I installed mxnet-cu90 and meet this problem,Can anyone help me?Thank you .

I think this issue is related to the hardware and software configuration, please raise an issue in the MXNet repo, and you may get help from their community.


Running on Windows?

Dear author,
I understand that the code that you provided runs on Linux,
but is there any way for me to run the code on Windows?
Thanks!

Hello, this code supports running on Windows.


Add page that instructs on how to verify downloads

This is non typical in that it encourages users to check the fingerprints with third party sources.
Currently it states that devs list their gpg fingerprint on their Github profile. Unsure if we want to enforce that. But I'd like to provide some way where users can verify a key other than just downloading it. It might even be different for each user.
I didn't bother adding keys for the uploaders of rather early (coke, masak, pmichaud, froggs, ...). Should I?
I'm looking for feedback on how to improve this. Pinging @jdv @coke because I have the feeling you might have valuable input here.
Does anyone have Zoffix' public key available? I didn't find it on any keyserver.
ps. My local repo already contains the public keys the page offers for download. I intentionally left that out it this PR until we decide this is the way we want to go.

I don't have anything particularly insightful to add, and I'm not sure I ever signed any of the releases I did.

@AntonOks, @Altai-man, @jdv  I'd like to have your feedback on this PR. Merging it would require your action. It would at least be necessary for you to list your PGP key fingerprint on your GitHub profile (like I did: https://github.com/patrickbkr) and if possible also on other sites.
 Why don't we do it this other way that's much saner?"

Some more information on the "why". (The usage of the words "key" and "key fingerprint" are intentional, they are not interchangeable.)
Why should we sign releases?
The reason why releases should be signed is to provide protection from malicious modification of release files. If release files are always signed with the same key, the users can verify, that the release they have downloaded now was made by the same person that did the release the last time they downloaded something.
Why should releasers provide their keys on rakudo.org when they are already available on a keyserver?
The very popular keys.openpgp.org strips signings off of keys. This means that keys uploaded to that site can not be used to build a web of trust. So having the keys including the signings available for download somewhere makes sense.
It would also be a good idea to have a key signing event at the next conference, where core developers sign each others keys.
Why should I, a releaser, put my key fingerprint on GH?
The more sites connect a releasers key to their identity, the more difficult it will be for an attacker to successfully mount a plausible attack on our releases. If we only have keys on a keyserver and on rakudo.org, then an attacker will only have to break into the rakudo.org server to be able to upload a malicious release file signed with a freshly generated key impersonating a real releaser uploaded to some key server and replaced on the rakudo.org server. If the key fingerprints are also listed on GH then the attacker will also have to break into GH to change the fingerprint listed there. (Or create a new fake GH account impersonating a releaser. But that account will not be related to anything Raku.)

Some more information on the "why". (The usage of the words "key" and "key fingerprint" are intentional, they are not interchangeable.)
Why should we sign releases?
The reason why releases should be signed is to provide protection from malicious modification of release files. If release files are always signed with the same key, the users can verify, that the release they have downloaded now was made by the same person that did the release the last time they downloaded something.
Why should releasers provide their keys on rakudo.org when they are already available on a keyserver?
The very popular keys.openpgp.org strips signings off of keys. This means that keys uploaded to that site can not be used to build a web of trust. So having the keys including the signings available for download somewhere makes sense. It would also be a good idea to have a key signing event at the next conference, where core developers sign each others keys.
Why should I, a releaser, put my key fingerprint on GH?
The more sites connect a releasers key to their identity, the more difficult it will be for an attacker to successfully mount a plausible attack on our releases. If we only have keys on a keyserver and on rakudo.org, then an attacker will only have to break into the rakudo.org server to be able to upload a malicious release file signed with a freshly generated key impersonating a real releaser uploaded to some key server and replaced on the rakudo.org server. If the key fingerprints are also listed on GH then the attacker will also have to break into GH to change the fingerprint listed there. (Or create a new fake GH account impersonating a releaser. But that account will not be related to anything Raku.)

Hi there. My 5cents...

I never signed a piece of SW so far and don't even "own" / have a PGP key.
For my "Rakudo Star" involvement, I don't think this is needed or helpful anyhow, because

Both, the bash-based RSTAR tool and the Windows MSI releases, are build by the GitHub bot and not me ;) so signing it with my private key and by that saying, "YES I SWEAR IT WAS ME BUILDING THIS SW" feels wrong. And remember, the Star releases are build "automatically" just after a Rakudo release tag was pushed, by intention nowadays via GH Actions...

See https://github.com/rakudo/star/actions/workflows/sync_latest_rakudo_release.yml and (new, tested but not in "production" so far... should run with the next release and I'll move it also to rakudo/star then) https://github.com/AntonOks/cronactions/blob/main/.github/workflows/publish_rakudo-star_on_rakudo.org.yml

To give someone the security, the SW is as it was build (on GitHub in the Star case), we create HASH sums, right? Those HASH sums should be used from the various "installers" and "package manages" IMHO... like here

@AntonOks Would it be possible to let GH Actions pipeline automatically sign the files with its own key (so a key that is different from your key)?

That's a good question... I stopped to think about that one because if you look at the releases page (also possible to query this info via the GH API ;) ) you see on the left side it say's clearly (for my understanding :O ) it's build by "github-actions"... so...
Another thought some time back was about "signed commits". But. as said.

I agree that the benefit of automatically signing autogenerated files is diminished for files that stay on GH and are immutable. But those files are then copied over to rakudo.org, right? Then it makes sense to have those files (automatically) signed by GH. Users can then verify that the files they download from rakudo.org are actually the files that were generated by your GH toolchain.

@AntonOks Do I suspect correctly, that you do not oppose this PR and would be willing to introduce a a signing into the automated Rakudo Star release process?

I agree that the benefit of automatically signing autogenerated files is diminished for files that stay on GH and are immutable.

For Star, there are also SHA checksums on GH.

But those files are then copied over to rakudo.org, right?

Exactly, the release binaries AND the checksum files (should be / are) copied. They "belong together".

Then it makes sense to have those files (automatically) signed by GH.

Why? See next...

Users can then verify that the files they download from rakudo.org are actually the files that were generated by your GH toolchain.

It is not "my" GH toolchain!!! Community! Everyone is (please!) invited to add more "automations" and smartness. Let's say i.e. "modules updates" ;)

Users can verify already today, if they want. As you write, assuming the GH chain is not in doubt and "immutable", there are checksums there and those have to be the same wherever the Star release binaries / files show up. If a checksum file, lets say in our case here on raku.org, shows a different SHA then the "original / "immutable" one on GH, something is "wrong" with the binary on rakudo.org.

@AntonOks Do I suspect correctly, that you do not oppose this PR and would be willing to introduce a a signing into the automated Rakudo Star release process?

I'll never "oppose" a PR if the majority / community is up for something
Not sure if I'm willing to "introduce signing"... depends what it rely means and takes and solves and...

@AntonOks I'll see if I can put together a PR.

A PR to adapt the automated Star Bundle release pipeline is available here: https://github.com/rakudo/star/pull/173 Ideally that other PR is merged prior to this one.

I have merged the PR rakudo/star#173. I hope you can go ahead now.

I have removed ancient releasers from the key list. The list now contains:

jdv
patrickbkr
Altai-man
The Rakudo GitHub automation key (used by the fully autonomous Star bundle release process)

@jdv, @Altai-man: Before merging this you should add your key fingerprint to your GitHub profile. I think there is nothing else left to do. This PR is thus now blocking on your action / approval.

@patrickbkr is there an instruction on how to do it? :)

@patrickbkr is there an instruction on how to do it? :)

Go to your profile page, click on edit profile, then enter into the bio field something like PGP Fingerprint: DB2B A39D 1ED9 67B5 84D6  5D71 C09F F113 BB64 10D0 (That's my fingerprint, put in yours instead.)
You can retrieve your fingerprint with gpg2 --fingerprint --show-keys. (I can't verify that command right now, I only have my mobile phone available.)

I added my fiingerprint to my profile page.  Note that my name is spelled "Justin DeVuyst" as can be seen on my profile page.  It is misspelled in this PR.

Oh, so that's how it is, I thought there is something special. Done.

@patrickbkr @Altai-man @jdv @rba @coke
Hi all.
Have you seen / noticed https://github.com/rakudo/star/issues/175 ?
Can I revert https://github.com/rakudo/star/pull/173 or will someone "fix" it... soon?
Thanks & regards


distributions: add Fedora 41

Fedora 40 branched around 2024-02-14, so Rawhide now "is" (to some extent) Fedora 41.
I suspect there's a scripted way to do this, but as the developer guide is 404 and it wasn't anything obvious, I couldn't find it. I based this on the F40 commit with appropriate tweaks (fortunately that swagger blob is gone).
F40 branched around 2024-02-14, and 41 has "existed" to some degree (notably, I think Rawhide osbuild images should have been using this definition) since then. Updating this needs to be on someone's SOP, I guess, if I'm right. CC @nirik

Rebased to drop the modular repos. Fedora has had no modular content since F39, there is no reason to include these repos (and we're debating not having the metalinks exist).

@croissanne could you take a look? I do not fully understand distros yet

/retest

/retest

/retest

/retest

Thank you for your contribution @AdamWill ! :orange_heart:
And sorry it took so long to get it in, the CI was bit moody lately :/


Error when naming camera 'test'

I just discovered that naming a camera test causes RTSP connection to fail.
  - name: test
    host: <IP_ADDRESS>
    port: 554
    username: my-username
    password: thats-a-secret
    path: /s0

[2021-11-01 19:02:31] [INFO    ] [viseron                 ] - -------------------------------------------
[2021-11-01 19:02:31] [INFO    ] [viseron                 ] - Initializing...
[2021-11-01 19:02:32] [INFO    ] [viseron.mqtt            ] - Initializing MQTT connection
[2021-11-01 19:02:32] [DEBUG   ] [viseron.post_processors ] - Initializing post processor face_recognition
[2021-11-01 19:02:34] [DEBUG   ] [viseron.post_processors ] - Successfully imported post processor
[2021-11-01 19:02:34] [DEBUG   ] [viseron.post_processors.face_recognition.dlib] - Initializing dlib
[2021-11-01 19:02:34] [DEBUG   ] [viseron.post_processors.face_recognition.dlib] - Training faces...
[2021-11-01 19:02:34] [ERROR   ] [viseron.post_processors.face_recognition.dlib] - No faces found for training in /config/face_recognition/faces
[2021-11-01 19:02:34] [DEBUG   ] [viseron.post_processors.face_recognition.dlib] - dlib initialized
[2021-11-01 19:02:34] [DEBUG   ] [viseron.post_processors ] - Post processor face_recognition initialized
[2021-11-01 19:02:34] [INFO    ] [viseron                 ] - Initializing NVR threads
[2021-11-01 19:02:35] [INFO    ] [viseron                 ] - Initialization complete
[2021-11-01 19:02:35] [ERROR   ] [viseron.camera.test     ] - FFmpeg process has exited
[2021-11-01 19:02:35] [ERROR   ] [viseron.camera.stream.test] - test: extra argument ‘-loglevel’
[2021-11-01 19:02:40] [ERROR   ] [viseron.camera.test     ] - Restarting frame pipe
[2021-11-01 19:02:40] [ERROR   ] [viseron.camera.test     ] - FFmpeg process has exited
[2021-11-01 19:02:40] [ERROR   ] [viseron.camera.stream.test] - test: extra argument ‘-loglevel’
[2021-11-01 19:02:45] [ERROR   ] [viseron.camera.test     ] - Restarting frame pipe
[2021-11-01 19:02:45] [ERROR   ] [viseron.camera.stream.test] - test: extra argument ‘-loglevel’
[2021-11-01 19:02:45] [ERROR   ] [viseron.camera.test     ] - FFmpeg process has exited
[2021-11-01 19:02:50] [ERROR   ] [viseron.camera.test     ] - Restarting frame pipe
[2021-11-01 19:02:50] [ERROR   ] [viseron.camera.stream.test] - test: extra argument ‘-loglevel’
[2021-11-01 19:02:50] [ERROR   ] [viseron.camera.test     ] - FFmpeg process has exited

Changing just the name of the camera to testy fixes this.

Oh wow that's interesting!
I am creating a symlink to the ffmpeg executable with the camera name so it is easily recognized in the process list.
I am working on a rewrite of Viseron and it's already fixed there so it will be in the next release!

Closed in v2


randomBetween implementation is wrong

The current implementation of randomBetween (as of 2.0.1) is:
int randomBetween(int from, int to,
    {AbstractRandomProvider provider = const DefaultRandomProvider()}) {
  if (from > to) throw Exception('$from cannot be > $to');
  var randomDouble = provider.nextDouble();
  if (randomDouble < 0) randomDouble *= -1;
  if (randomDouble > 1) randomDouble = 1 / randomDouble;
  return ((to - from) * provider.nextDouble()).toInt() + from;
}

I see a few problems:

The documentation claims that the returned value should be in the range [from, to].  As implemented, however, if from != to, it can return values only in the range [from, to).  The (to - from) factor should be (to - from + 1) to use an inclusive upper-bound.  Consider a simple case of randomBetween(0, 1) where you want 2 possible values: Since toInt() truncates (rounds to 0), you ultimately want a double in the range [0, 2) so that toInt() can return an integer in the range [0, 1].  Assuming that provider.nextDouble() returns a fraction in the range [0, 1), you therefore must scale it by 2.  Alternatively change the documented behavior. (The existing test to verify that randomBetween can return the inclusive upper-bound happens to work because it ends up being a degenerate case.)

randomBetween unnecessarily calls provider.nextDouble twice.  It computes an adjusted randomDouble value but then proceeds to ignore it.

I see no documentation from AbstractRandomProvider specifying what nextDouble should return.  Random.nextDouble from dart:math returns a value in the range [0, 1), but it's unclear what expectation AbstractRandomProvider has.  This is a problem because:

That randomBetween tolerates provider.nextDouble() returning a double values < 0 or > 1 suggests that any finite double values are legal.  However, that could cause randomBetween to return random numbers without a uniform distribution, even if provider does have a uniform distribution.  For example, suppose an AbstractRandomProvider is given whose nextDouble implementation returns a random double in the range [0, 100) with a uniform distribution, and suppose that we call randomBetween(0, 1, provider: myProvider).  If randomDouble returns a value > 2 (which would happen 98% of the time), the > 1 check would adjust randomDouble to be < 0.5.  Assuming that randomDouble were used in the final calculation instead of calling provider.nextDouble() again, this would give an undue weight to returning 0 instead of 1.  I suggest:

If provider.nextDouble returns a value outside the expected range, either fail or retry.  Do not try to coerce it into the expected range because doing so is likely to change its distribution.
Document that AbstractRandomProvider.nextDouble must return values in the range [0, 1).

@jamesderlin Thank you for posting this thorough issue.  I will look into this.  Pull requests are also welcome.


Proposal: Meet up presentation: Kaia Vietnam at Hung Vuong Technology Vocational School on 09/10/2024

Description
Join us for a special meetup at Hung Vuong Technology Vocational School to introduce Kaia Vietnam's latest initiatives. Discover cutting-edge technologies, engage with industry experts, and explore new opportunities in tech and innovation. Let's connect, learn, and grow together on 10th September 2024!
Location: https://maps.app.goo.gl/MBjkqVAtaZysDdBq6

Approved for 600 KLAY bounty

for reference:
https://x.com/zxstim/status/1844196903392772365

Closing for payout