Use CurrentCulture, not CurrentUICulture, for dates etc.

Bug type
Other
Component name
No response
What happened?
MudBlazor\Utilities\BindingConverters\Converters.cs uses CurrentUICulture for defining the default culture used for date and number conversion:
public static class Converters
{
    public static CultureInfo DefaultCulture = CultureInfo.CurrentUICulture;

It is my impression that CultureInfo.CurrentUICulture is only supposed to be used for ResourceManager related operations for fetching localized text, etc., cf. the CultureInfo.CurrentUICulture documentation.
Expected behavior
It seems to me that CultureInfo.CurrentCulture should be used instead, cf. the CultureInfo.CurrentCulture documentation:

The CultureInfo object that's returned by this property and its associated objects determine the default format for dates, times, numbers, currency values, the sorting order of text, casing conventions, and string comparisons.

Reproduction link
https://try.mudblazor.com/snippet/QkGQOClZSiDJVuvJ
Reproduction steps
Oftentimes, the two values of CultureInfo.CurrentUICulture and CultureInfo.CurrentCulture are identical, so the effect of using CultureInfo.CurrentUICulture may go unnoticed. However, sometimes they may differ, for instance if Windows applications should display English text, but dates and numbers should be formatted using, say, Danish, German or French culture.
Relevant log output
No response
Version (bug)
6.0.14
Version (working)
No response
What browsers are you seeing the problem on?
Chrome
On what operating system are you experiencing the issue?
Windows
Pull Request

[ ] I would like to do a Pull Request

Code of Conduct

[X] I agree to follow this project's Code of Conduct

I'm now facing this issue as my company is using english windows but german date and number formats. Mudblazor is using a dot as decimal separator while it should use a comma.
Is there any easy workaround?
Here is an example of the issue we have with culture en-DE

Culture Example 1

    CurrentCulture: @CultureInfo.CurrentCulture

Rendered values

Date: @dt

Number: @number.ToString("N2")

<input> elements that don't set a type

    The following <input> elements use
    CultureInfo.CurrentCulture.

Date: <input @bind="dt" />

Number: <input @bind="number" />

<input> elements that set a type

    The following <input> elements use
    CultureInfo.InvariantCulture.

Date: <input type="date" @bind="dt" />

Number: <input type="number" @bind="number" />

<MudForm>
    <MudNumericField @bind-Value="number" />

</MudForm>

@code {
    private DateTime dt = DateTime.Now;
    private double number = 1999.69;
}


Cannot assign Ctrl-Shift-Up to io.emmet.increment_number_by_1. It is already assigned to edit.lineUp

Cannot assign Ctrl-Shift-Up to io.emmet.increment_number_by_1. It is already assigned to edit.lineUp

I have the same issue. I reassigned shortcuts Ctrl-Shift-Up and Ctrl-Shift-Down for emmet in keymap.json file from brackets-emmet folder. I removed increment_by_10 shortcuts and assigned them to increment_by_1. I thought increment_by_1 is more helpful than increment_by_10.

I have the same issue. I reassigned shortcuts Ctrl-Shift-Up and Ctrl-Shift-Down for emmet in keymap.json file from brackets-emmet folder. I removed increment_by_10 shortcuts and assigned them to increment_by_1. I thought increment_by_1 is more helpful than increment_by_10.

where to find the keymap.json file ,tho i have downloaded Emmet i cant find any Brackets-emmet folder.


PROD-2049: Implement sending emails via property-specific messaging templates

Closes PROD-2049
Description Of Changes
This change adds the core logic to determine both:

Whether or not to use property-specific messaging templates
Which messaging template to use when sending emails from Fides

We support property-specific messaging for the following message types

[ ] PRIVACY_REQUEST_REVIEW_APPROVE
[ ] PRIVACY_REQUEST_REVIEW_DENY
[ ] PRIVACY_REQUEST_RECEIPT
[ ] PRIVACY_REQUEST_COMPLETE_ACCESS
[ ] PRIVACY_REQUEST_COMPLETE_DELETION
[ ] SUBJECT_IDENTITY_VERIFICATION (both consent and privacy request)

Code Changes

[ ] Adds new env var to track whether or not we enable property-specific messaging
[ ] Adds property_id field to PrivacyRequest model
[ ] Implements retrieving appropriate messaging template by property id if ENV var is enabled

Steps to Confirm

[ ] With FIDES__NOTIFICATIONS__ENABLE_PROPERTY_SPECIFIC_MESSAGING disabled, confirm that no regressions exist with configuring email templates and sending out emails via Fides (consult the above list for email types to test)
[ ] With FIDES__NOTIFICATIONS__ENABLE_PROPERTY_SPECIFIC_MESSAGING enabled, confirm that we can send property-specific emails. To do this, to the following:
[ ] Configure your email messaging config (e.g. Mailgun) as you did before to enable sending emails from Fides
[ ] Enable your property-specific emails. In the postgres container, run update messaging_template set is_enabled=true;

Pre-Merge Checklist

[ ] All CI Pipelines Succeeded
Documentation:

[ ] documentation complete, PR opened in fidesdocs
[ ] documentation issue created in fidesdocs
[ ] if there are any new client scopes created as part of the pull request, remember to update public-facing documentation that references our scope registry

[ ] Issue Requirements are Met
[ ] Relevant Follow-Up Issues Created
[x] Update CHANGELOG.md
[ ] For API changes, the Postman collection has been updated
If there are any database migrations:

[ ] Ensure that your downrev is up to date with the latest revision on main
[ ] Ensure that your downgrade() migration is correct and works

[ ] If a downgrade migration is not possible for this change, please call this out in the PR description!

Everything worked with FIDES__NOTIFICATIONS__ENABLE_PROPERTY_SPECIFIC_MESSAGING disabled but I ran into this serialization error when I set it to true and tried to use the default templates.
fides  |   File "/fides/src/fides/api/api/v1/endpoints/privacy_request_endpoints.py", line 1131, in verify_identification_code
fides  |     _send_privacy_request_receipt_message_to_user(
fides  |   File "/fides/src/fides/api/api/v1/endpoints/privacy_request_endpoints.py", line 257, in _send_privacy_request_receipt_message_to_user
fides  |     dispatch_message_task.apply_async(
fides  |   File "/opt/fides/lib/python3.10/site-packages/celery/app/task.py", line 564, in apply_async
fides  |     content_type, content_encoding, data = serialization.dumps(
fides  |   File "/opt/fides/lib/python3.10/site-packages/kombu/serialization.py", line 219, in dumps
fides  |     with _reraise_errors(EncodeError):
fides  |   File "/usr/local/lib/python3.10/contextlib.py", line 153, in __exit__
fides  |     self.gen.throw(typ, value, traceback)
fides  |   File "/opt/fides/lib/python3.10/site-packages/kombu/serialization.py", line 45, in _reraise_errors
fides  |     reraise(wrapper, wrapper(exc), sys.exc_info()[2])
fides  |   File "/opt/fides/lib/python3.10/site-packages/kombu/exceptions.py", line 34, in reraise
fides  |     raise value.with_traceback(tb)
fides  |   File "/opt/fides/lib/python3.10/site-packages/kombu/serialization.py", line 41, in _reraise_errors
fides  |     yield
fides  |   File "/opt/fides/lib/python3.10/site-packages/kombu/serialization.py", line 220, in dumps
fides  |     payload = encoder(data)
fides  |   File "/opt/fides/lib/python3.10/site-packages/kombu/utils/json.py", line 63, in dumps
fides  |     return _dumps(s, cls=cls, **dict(default_kwargs, **kwargs))
fides  |   File "/usr/local/lib/python3.10/json/__init__.py", line 238, in dumps
fides  |     **kw).encode(obj)
fides  |   File "/usr/local/lib/python3.10/json/encoder.py", line 199, in encode
fides  |     chunks = self.iterencode(o, _one_shot=True)
fides  |   File "/usr/local/lib/python3.10/json/encoder.py", line 257, in iterencode
fides  |     return _iterencode(o, 0)
fides  |   File "/opt/fides/lib/python3.10/site-packages/kombu/utils/json.py", line 47, in default
fides  |     return super().default(o)
fides  |   File "/usr/local/lib/python3.10/json/encoder.py", line 179, in default
fides  |     raise TypeError(f'Object of type {o.__class__.__name__} '
fides  | kombu.exceptions.EncodeError: Object of type MessagingTemplate is not JSON serializable

Thanks so much for the review @galvana !

Updated as per your suggestion, including adding validation for valid property_id, if passed in to both consent and DSR requests
Fixed the error- turns out I can't pass in DB models to celery workers.
Yes, you'll need to enable the default templates first, I've updated the testing instructions to reflect this. We don't support property-specific messaging in OSS at all. This is only a Plus feature.


Server Error 401 for 2-grams and 3-grams

First, thanks to the whole Computational Story Lab team for making Storywrangler available!
Second, a major bug report:
As of November 5, 2021, ~11:15am, the Storywrangler ngrams API is failing consistently for 2-grams and 3-grams. The response error code is "Error 401" and/or "Database error." Results are consistent through the web interface (https://storywrangling.org/) and direct API access (https://storywrangling.org/api/ngrams/).
To reproduce this error: visit the storywrangling.org interactive web site and the demo query will fail with the following message (but note it works as expected if you remove the 2-gram "tested positive"):

Link: https://storywrangling.org/ngrams?ngrams=🦠,coronavirus,tested positive,vaccinated&language=en&rt=true&scale=log&metric=rank&start=2020-11-03&end=2021-11-04
Error: Error 401: 🦠,coronavirus,tested positive,vaccinated was not found in the database.

Visiting the API endpoint directly to query a 2-gram also fails and gives the following response:

Link: https://storywrangling.org/api/ngrams/potato chips?metric=rank&language=en&rt=FALSE&src=api
Error: {"message":"Database error"}

As an end-user I have no guesses as to what's causing this. The last codebase commit to the API seems to have been in July, so it's not likely to be the API code itself. Perhaps there's been a change to the database?

This has been resolved: One of our VM's ran out of space!

Thanks! A "good" problem to have, if it means you're getting lots of traction! I'll close the issue.


NuGet package license questions

The license associated with the NuGet package for Microsoft.NET.Test.Sdk is the Microsoft .NET Library license even though the repository appears to be licensed under MIT.
I realise this has been brought up before in #1691, but it is a little light on actual help. It left me with two questions:

Are the packages built in this repository not meant to be used in open source development?
Is there a recommended (and legal) way of using this package in an open source project that is compliant with the MSL license?

@Haplois I think you know the most about this.

I am currently doing a license audit on my project and I'm also confused about this... Is the NuGet package dual licensed, or is it actually using a different license than the source code?

@CodeReaper which parts of the license do you think make it illegal to use these libraries in open source?

@CodeReaper which parts of the license do you think make it illegal to use these libraries in open source?

@rouke-broersma
I am no lawyer, but my concern began with the fact that repository is licensed with MIT and the NuGet package lists a different license.
I then assumed this license to be incompatible with open source since I am unable to look it up at:

https://opensource.org/licenses/alphabetical
https://spdx.org/licenses/
https://tldrlegal.com

The NuGet package has had its current license for almost 5 years and the above sites only list MS-PL and MS-RL as valid open source Microsoft licenses.
Therefore I do know not if these libraries are compatible with open source or not. Since I cannot say Yes, I am defaulting to No.

I believe it's this license: https://www.microsoft.com/web/webpi/eula/aspnetcomponent_rtw_enu.htm
Just because it's not on tldr legal and such doesn't mean it's not a compatible license.
I'm also not a legal expert and would love someone from Microsoft to weigh in but from just reading the license terms it doesn't seem to block using nor redistribution the packages. It does seem to restrict modifying the nuget packages or reverse engineering them.
They seem to want to protect their compiled packages with this license for some reason, but the source code itself is MIT licensed. So don't reverse and modify the nuget package and compiled dlls but rather take the actual sources and compile and package it yourself if you wish to modify the sources?
Again no legal expert and ms should clarify but this is what I gather from the licenses and the difference in licenses.

We are looking into it and will come back with an official answer.

I'd like to refresh this issue - it's really quite strange situation:
The MSTest git repo  has MIT license and the MSTest.TestFramework NuGet package has MIT license as well.
The VSTest git repo, this one, has MIT license, BUT the published Microsoft.Net.Test.Sdk NuGet package has custom Microsoft license.
It might seem like not a big deal, but we're using proxy server for all our NuGet packages. This server allows packages with MIT license, but blocks packages with custom license. Such blocked packages like Microsoft.NET.Test.Sdk need to be manually approved and it's quite tedious work for every new released package version.
Tl;dr changing the license of Microsoft.NET.Test.Sdk and related packages to MIT on NuGet, similarly to MSTest NuGets, would be highly appreciated!

Ping @pavelhorak

This is because along with Microsoft.Net.Test.Sdk package we ship Microsoft.CodeCoverage package dependency which isn't MIT licensed.

The Microsoft.CodeCoverage package links to VSTest Source repository with MIT licence, so this answer does not make much sense.

Code Coverage is closed source and we didn't have any public repo but we are about to create one for issue tracking, etc... Once done, we'll reference it from Nuget for Microsoft.CodeCoverage package.

why does Microsoft.Net.Test.Sdk consume Microsoft.CodeCoverage? shouldnt that be an optional thing people pull in?

@jakubch1 for more details.

why does Microsoft.Net.Test.Sdk consume Microsoft.CodeCoverage? shouldnt that be an optional thing people pull in?

I agree it should be optional. Unfortunately removing it would break many projects because dotnet test --collect "Code Coverage" will stop to work. I will try to make change to include Microsoft.CodeCoverage into default templates and after longer time we can remove dependency.
Microsoft.Net.Test.Sdk  is just some build props and targets + Microsoft.NET.Test.Sdk.Program.cs file that you can include into your project and get it behave like test project (you can directly reference <PackageReference Include="Microsoft.TestPlatform.TestHost" Version="17.4.1" />). It could be done as Directory.Build.props and Directory.Build.targets in folder with all your tests projects.


arm64 osx platform not supported?

When trying to install scArches as per instructions in https://docs.scarches.org/en/latest/installation.html, both listed installation options fail on arm64 osx platform.

When installing via a manual route, i.e. by

conda create -n scArches # creating new environment
conda install python=3.8 # installing the recommended python version
conda install anaconda::jupyter
pip install -U scarches

the installation finishes correctly, but when importin scPoli in the following code snippet inside of a jupyter .ipynb file:
import numpy as np
import scanpy as sc
import pandas as pd
import matplotlib.pyplot as plt
import seaborn as sns
from sklearn.metrics import classification_report
from scarches.models.scpoli import scPoli

it throws an error #211.

When trying to clone the repo, it fails due to inavailability of  pytorch-cuda:

git clone https://github.com/theislab/scarches
cd scarches
conda env create -f envs/scarches_linux.yaml
conda activate scarches
Cloning into 'scarches'...
remote: Enumerating objects: 7553, done.
remote: Counting objects: 100% (681/681), done.
remote: Compressing objects: 100% (256/256), done.
remote: Total 7553 (delta 454), reused 618 (delta 421), pack-reused 6872
Receiving objects: 100% (7553/7553), 803.94 MiB | 5.50 MiB/s, done.
Resolving deltas: 100% (5030/5030), done.
Channels:
 - pytorch
 - nvidia
 - defaults
 - anaconda
 - conda-forge
 - bioconda
Platform: osx-arm64
Collecting package metadata (repodata.json): done
Solving environment: failed
Channels:
 - pytorch
 - nvidia
 - defaults
 - anaconda
 - conda-forge
 - bioconda
Platform: osx-arm64
Collecting package metadata (repodata.json): done
Solving environment: failed

LibMambaUnsatisfiableError: Encountered problems while solving:
  - nothing provides cuda 11.8.* needed by pytorch-cuda-11.8-h8dd9ede_2

Could not solve for environment specs
The following package could not be installed
└─ pytorch-cuda 11.8**  is not installable because it requires
   └─ cuda 11.8.* , which does not exist (perhaps a missing channel).

EnvironmentNameNotFound: Could not find conda environment: scarches
You can list all discoverable environments with `conda info --envs`.

it seems like (for now, at least), the first route but with python=3.9, i.e.
conda create -n scArches # creating new environment
conda install python=3.9 # installing the recommended python version
conda install anaconda::jupyter
pip install -U scarches

it doesn't complain when importing scPoli anymore. But pip was complaining about incompatibility of phate and pandas was uninstalled, which is concerning:

pip install -U scarches

Collecting scarches
  Using cached scArches-0.6.1-py3-none-any.whl.metadata (3.5 kB)
Collecting scanpy>=1.6.0 (from scarches)
  Downloading scanpy-1.10.1-py3-none-any.whl.metadata (8.6 kB)
Collecting anndata>=0.7.4 (from scarches)
  Downloading anndata-0.10.7-py3-none-any.whl.metadata (6.6 kB)
Collecting scHPL>=1.0.0 (from scarches)
  Using cached scHPL-1.0.5-py3-none-any.whl.metadata (3.5 kB)
Collecting h5py>=2.10.0 (from scarches)
  Downloading h5py-3.11.0-cp39-cp39-macosx_11_0_arm64.whl.metadata (2.5 kB)
Collecting torch>=1.8.0 (from scarches)
  Downloading torch-2.3.0-cp39-none-macosx_11_0_arm64.whl.metadata (26 kB)
Collecting numpy>=1.19.2 (from scarches)
  Downloading numpy-1.26.4-cp39-cp39-macosx_11_0_arm64.whl.metadata (61 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 61.1/61.1 kB 2.7 MB/s eta 0:00:00
Collecting scipy>=1.5.2 (from scarches)
  Downloading scipy-1.13.1-cp39-cp39-macosx_12_0_arm64.whl.metadata (60 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 60.6/60.6 kB 5.0 MB/s eta 0:00:00
Collecting scikit-learn>=0.23.2 (from scarches)
  Downloading scikit_learn-1.5.0-cp39-cp39-macosx_12_0_arm64.whl.metadata (11 kB)
Collecting matplotlib>=3.3.1 (from scarches)
  Downloading matplotlib-3.9.0-cp39-cp39-macosx_11_0_arm64.whl.metadata (11 kB)
Requirement already satisfied: pandas>=1.1.2 in /Users/administrateur/.local/lib/python3.9/site-packages (from scarches) (2.0.3)
Collecting scvi-tools>=0.12.1 (from scarches)
  Downloading scvi_tools-1.1.2-py3-none-any.whl.metadata (12 kB)
Collecting tqdm>=4.56.0 (from scarches)
  Using cached tqdm-4.66.4-py3-none-any.whl.metadata (57 kB)
Requirement already satisfied: requests in /Users/administrateur/miniforge3/envs/scArches/lib/python3.9/site-packages (from scarches) (2.32.2)
Collecting gdown (from scarches)
  Using cached gdown-5.2.0-py3-none-any.whl.metadata (5.8 kB)
Collecting leidenalg (from scarches)
  Using cached leidenalg-0.10.2-cp38-abi3-macosx_11_0_arm64.whl.metadata (10 kB)
Collecting muon (from scarches)
  Using cached muon-0.1.6-py3-none-any.whl.metadata (7.2 kB)
Collecting array-api-compat!=1.5,>1.4 (from anndata>=0.7.4->scarches)
  Downloading array_api_compat-1.7.1-py3-none-any.whl.metadata (1.5 kB)
Requirement already satisfied: exceptiongroup in /Users/administrateur/miniforge3/envs/scArches/lib/python3.9/site-packages (from anndata>=0.7.4->scarches) (1.2.0)
Collecting natsort (from anndata>=0.7.4->scarches)
  Using cached natsort-8.4.0-py3-none-any.whl.metadata (21 kB)
Requirement already satisfied: packaging>=20.0 in /Users/administrateur/miniforge3/envs/scArches/lib/python3.9/site-packages (from anndata>=0.7.4->scarches) (23.2)
Collecting contourpy>=1.0.1 (from matplotlib>=3.3.1->scarches)
  Downloading contourpy-1.2.1-cp39-cp39-macosx_11_0_arm64.whl.metadata (5.8 kB)
Collecting cycler>=0.10 (from matplotlib>=3.3.1->scarches)
  Using cached cycler-0.12.1-py3-none-any.whl.metadata (3.8 kB)
Collecting fonttools>=4.22.0 (from matplotlib>=3.3.1->scarches)
  Downloading fonttools-4.53.0-cp39-cp39-macosx_11_0_arm64.whl.metadata (162 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 162.2/162.2 kB 6.2 MB/s eta 0:00:00
Collecting kiwisolver>=1.3.1 (from matplotlib>=3.3.1->scarches)
  Downloading kiwisolver-1.4.5-cp39-cp39-macosx_11_0_arm64.whl.metadata (6.4 kB)
Collecting pillow>=8 (from matplotlib>=3.3.1->scarches)
  Downloading pillow-10.3.0-cp39-cp39-macosx_11_0_arm64.whl.metadata (9.2 kB)
Collecting pyparsing>=2.3.1 (from matplotlib>=3.3.1->scarches)
  Using cached pyparsing-3.1.2-py3-none-any.whl.metadata (5.1 kB)
Requirement already satisfied: python-dateutil>=2.7 in /Users/administrateur/miniforge3/envs/scArches/lib/python3.9/site-packages (from matplotlib>=3.3.1->scarches) (2.9.0.post0)
Collecting importlib-resources>=3.2.0 (from matplotlib>=3.3.1->scarches)
  Using cached importlib_resources-6.4.0-py3-none-any.whl.metadata (3.9 kB)
Requirement already satisfied: pytz>=2020.1 in /Users/administrateur/miniforge3/envs/scArches/lib/python3.9/site-packages (from pandas>=1.1.2->scarches) (2024.1)
Collecting tzdata>=2022.1 (from pandas>=1.1.2->scarches)
  Using cached tzdata-2024.1-py2.py3-none-any.whl.metadata (1.4 kB)
Collecting get-annotations (from scanpy>=1.6.0->scarches)
  Using cached get_annotations-0.1.2-py3-none-any.whl.metadata (3.3 kB)
Collecting joblib (from scanpy>=1.6.0->scarches)
  Using cached joblib-1.4.2-py3-none-any.whl.metadata (5.4 kB)
Collecting legacy-api-wrap>=1.4 (from scanpy>=1.6.0->scarches)
  Using cached legacy_api_wrap-1.4-py3-none-any.whl.metadata (1.8 kB)
Collecting networkx>=2.7 (from scanpy>=1.6.0->scarches)
  Using cached networkx-3.2.1-py3-none-any.whl.metadata (5.2 kB)
Collecting numba>=0.56 (from scanpy>=1.6.0->scarches)
  Downloading numba-0.59.1-cp39-cp39-macosx_11_0_arm64.whl.metadata (2.7 kB)
Collecting patsy (from scanpy>=1.6.0->scarches)
  Using cached patsy-0.5.6-py2.py3-none-any.whl.metadata (3.5 kB)
Collecting pynndescent>=0.5 (from scanpy>=1.6.0->scarches)
  Using cached pynndescent-0.5.12-py3-none-any.whl.metadata (6.8 kB)
Collecting seaborn>=0.13 (from scanpy>=1.6.0->scarches)
  Using cached seaborn-0.13.2-py3-none-any.whl.metadata (5.4 kB)
Collecting session-info (from scanpy>=1.6.0->scarches)
  Using cached session_info-1.0.0.tar.gz (24 kB)
  Preparing metadata (setup.py) ... done
Collecting statsmodels>=0.13 (from scanpy>=1.6.0->scarches)
  Downloading statsmodels-0.14.2-cp39-cp39-macosx_11_0_arm64.whl.metadata (9.2 kB)
Collecting umap-learn!=0.5.0,>=0.5 (from scanpy>=1.6.0->scarches)
  Using cached umap_learn-0.5.6-py3-none-any.whl.metadata (21 kB)
Collecting pandas>=1.1.2 (from scarches)
  Downloading pandas-1.5.3-cp39-cp39-macosx_11_0_arm64.whl.metadata (11 kB)
Collecting newick~=1.0.0 (from scHPL>=1.0.0->scarches)
  Using cached newick-1.0.0-py2.py3-none-any.whl.metadata (2.7 kB)
Collecting threadpoolctl>=3.1.0 (from scikit-learn>=0.23.2->scarches)
  Using cached threadpoolctl-3.5.0-py3-none-any.whl.metadata (13 kB)
Collecting docrep>=0.3.2 (from scvi-tools>=0.12.1->scarches)
  Using cached docrep-0.3.2.tar.gz (33 kB)
  Preparing metadata (setup.py) ... done
Collecting flax (from scvi-tools>=0.12.1->scarches)
  Downloading flax-0.8.4-py3-none-any.whl.metadata (10 kB)
Collecting jax>=0.4.4 (from scvi-tools>=0.12.1->scarches)
  Downloading jax-0.4.28-py3-none-any.whl.metadata (23 kB)
Collecting jaxlib>=0.4.3 (from scvi-tools>=0.12.1->scarches)
  Downloading jaxlib-0.4.28-cp39-cp39-macosx_11_0_arm64.whl.metadata (1.8 kB)
Collecting lightning<2.2,>=2.0 (from scvi-tools>=0.12.1->scarches)
  Downloading lightning-2.1.4-py3-none-any.whl.metadata (57 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 57.2/57.2 kB 4.9 MB/s eta 0:00:00
Collecting ml-collections>=0.1.1 (from scvi-tools>=0.12.1->scarches)
  Using cached ml_collections-0.1.1.tar.gz (77 kB)
  Preparing metadata (setup.py) ... done
Collecting mudata>=0.1.2 (from scvi-tools>=0.12.1->scarches)
  Using cached mudata-0.2.3-py3-none-any.whl.metadata (4.7 kB)
Collecting numpyro>=0.12.1 (from scvi-tools>=0.12.1->scarches)
  Downloading numpyro-0.15.0-py3-none-any.whl.metadata (36 kB)
Collecting optax (from scvi-tools>=0.12.1->scarches)
  Downloading optax-0.2.2-py3-none-any.whl.metadata (8.1 kB)
Collecting pyro-ppl>=1.6.0 (from scvi-tools>=0.12.1->scarches)
  Using cached pyro_ppl-1.9.1-py3-none-any.whl.metadata (7.8 kB)
Collecting rich>=12.0.0 (from scvi-tools>=0.12.1->scarches)
  Using cached rich-13.7.1-py3-none-any.whl.metadata (18 kB)
Collecting torchmetrics>=0.11.0 (from scvi-tools>=0.12.1->scarches)
  Using cached torchmetrics-1.4.0.post0-py3-none-any.whl.metadata (19 kB)
Collecting filelock (from torch>=1.8.0->scarches)
  Using cached filelock-3.14.0-py3-none-any.whl.metadata (2.8 kB)
Requirement already satisfied: typing-extensions>=4.8.0 in /Users/administrateur/miniforge3/envs/scArches/lib/python3.9/site-packages (from torch>=1.8.0->scarches) (4.11.0)
Collecting sympy (from torch>=1.8.0->scarches)
  Using cached sympy-1.12.1-py3-none-any.whl.metadata (12 kB)
Requirement already satisfied: jinja2 in /Users/administrateur/miniforge3/envs/scArches/lib/python3.9/site-packages (from torch>=1.8.0->scarches) (3.1.4)
Collecting fsspec (from torch>=1.8.0->scarches)
  Using cached fsspec-2024.6.0-py3-none-any.whl.metadata (11 kB)
Requirement already satisfied: beautifulsoup4 in /Users/administrateur/miniforge3/envs/scArches/lib/python3.9/site-packages (from gdown->scarches) (4.12.2)
Collecting igraph<0.12,>=0.10.0 (from leidenalg->scarches)
  Downloading igraph-0.11.5-cp39-abi3-macosx_11_0_arm64.whl.metadata (3.9 kB)
Collecting protobuf (from muon->scarches)
  Using cached protobuf-5.27.0-cp38-abi3-macosx_10_9_universal2.whl.metadata (592 bytes)
Requirement already satisfied: charset-normalizer<4,>=2 in /Users/administrateur/miniforge3/envs/scArches/lib/python3.9/site-packages (from requests->scarches) (2.0.4)
Requirement already satisfied: idna<4,>=2.5 in /Users/administrateur/miniforge3/envs/scArches/lib/python3.9/site-packages (from requests->scarches) (3.7)
Requirement already satisfied: urllib3<3,>=1.21.1 in /Users/administrateur/miniforge3/envs/scArches/lib/python3.9/site-packages (from requests->scarches) (2.2.1)
Requirement already satisfied: certifi>=2017.4.17 in /Users/administrateur/miniforge3/envs/scArches/lib/python3.9/site-packages (from requests->scarches) (2024.2.2)
Requirement already satisfied: six in /Users/administrateur/miniforge3/envs/scArches/lib/python3.9/site-packages (from docrep>=0.3.2->scvi-tools>=0.12.1->scarches) (1.16.0)
Collecting texttable>=1.6.2 (from igraph<0.12,>=0.10.0->leidenalg->scarches)
  Using cached texttable-1.7.0-py2.py3-none-any.whl.metadata (9.8 kB)
Requirement already satisfied: zipp>=3.1.0 in /Users/administrateur/miniforge3/envs/scArches/lib/python3.9/site-packages (from importlib-resources>=3.2.0->matplotlib>=3.3.1->scarches) (3.17.0)
Collecting ml-dtypes>=0.2.0 (from jax>=0.4.4->scvi-tools>=0.12.1->scarches)
  Downloading ml_dtypes-0.4.0-cp39-cp39-macosx_10_9_universal2.whl.metadata (20 kB)
Collecting opt-einsum (from jax>=0.4.4->scvi-tools>=0.12.1->scarches)
  Using cached opt_einsum-3.3.0-py3-none-any.whl.metadata (6.5 kB)
Requirement already satisfied: importlib-metadata>=4.6 in /Users/administrateur/miniforge3/envs/scArches/lib/python3.9/site-packages (from jax>=0.4.4->scvi-tools>=0.12.1->scarches) (7.0.1)
Requirement already satisfied: PyYAML<8.0,>=5.4 in /Users/administrateur/miniforge3/envs/scArches/lib/python3.9/site-packages (from lightning<2.2,>=2.0->scvi-tools>=0.12.1->scarches) (6.0.1)
Collecting lightning-utilities<2.0,>=0.8.0 (from lightning<2.2,>=2.0->scvi-tools>=0.12.1->scarches)
  Using cached lightning_utilities-0.11.2-py3-none-any.whl.metadata (4.7 kB)
Collecting pytorch-lightning (from lightning<2.2,>=2.0->scvi-tools>=0.12.1->scarches)
  Downloading pytorch_lightning-2.2.5-py3-none-any.whl.metadata (21 kB)
Collecting absl-py (from ml-collections>=0.1.1->scvi-tools>=0.12.1->scarches)
  Using cached absl_py-2.1.0-py3-none-any.whl.metadata (2.3 kB)
Collecting contextlib2 (from ml-collections>=0.1.1->scvi-tools>=0.12.1->scarches)
  Using cached contextlib2-21.6.0-py2.py3-none-any.whl.metadata (4.1 kB)
Collecting llvmlite<0.43,>=0.42.0dev0 (from numba>=0.56->scanpy>=1.6.0->scarches)
  Downloading llvmlite-0.42.0-cp39-cp39-macosx_11_0_arm64.whl.metadata (4.8 kB)
Collecting multipledispatch (from numpyro>=0.12.1->scvi-tools>=0.12.1->scarches)
  Using cached multipledispatch-1.0.0-py3-none-any.whl.metadata (3.8 kB)
Collecting pyro-api>=0.1.1 (from pyro-ppl>=1.6.0->scvi-tools>=0.12.1->scarches)
  Using cached pyro_api-0.1.2-py3-none-any.whl.metadata (2.5 kB)
Collecting markdown-it-py>=2.2.0 (from rich>=12.0.0->scvi-tools>=0.12.1->scarches)
  Using cached markdown_it_py-3.0.0-py3-none-any.whl.metadata (6.9 kB)
Requirement already satisfied: pygments<3.0.0,>=2.13.0 in /Users/administrateur/miniforge3/envs/scArches/lib/python3.9/site-packages (from rich>=12.0.0->scvi-tools>=0.12.1->scarches) (2.15.1)
Requirement already satisfied: soupsieve>1.2 in /Users/administrateur/miniforge3/envs/scArches/lib/python3.9/site-packages (from beautifulsoup4->gdown->scarches) (2.5)
Collecting msgpack (from flax->scvi-tools>=0.12.1->scarches)
  Downloading msgpack-1.0.8-cp39-cp39-macosx_11_0_arm64.whl.metadata (9.1 kB)
Collecting orbax-checkpoint (from flax->scvi-tools>=0.12.1->scarches)
  Downloading orbax_checkpoint-0.5.15-py3-none-any.whl.metadata (1.8 kB)
Collecting tensorstore (from flax->scvi-tools>=0.12.1->scarches)
  Downloading tensorstore-0.1.60-cp39-cp39-macosx_11_0_arm64.whl.metadata (3.0 kB)
Requirement already satisfied: MarkupSafe>=2.0 in /Users/administrateur/miniforge3/envs/scArches/lib/python3.9/site-packages (from jinja2->torch>=1.8.0->scarches) (2.1.3)
Collecting chex>=0.1.86 (from optax->scvi-tools>=0.12.1->scarches)
  Downloading chex-0.1.86-py3-none-any.whl.metadata (17 kB)
Requirement already satisfied: PySocks!=1.5.7,>=1.5.6 in /Users/administrateur/miniforge3/envs/scArches/lib/python3.9/site-packages (from requests[socks]->gdown->scarches) (1.7.1)
Collecting stdlib_list (from session-info->scanpy>=1.6.0->scarches)
  Using cached stdlib_list-0.10.0-py3-none-any.whl.metadata (3.3 kB)
Collecting mpmath<1.4.0,>=1.1.0 (from sympy->torch>=1.8.0->scarches)
  Using cached mpmath-1.3.0-py3-none-any.whl.metadata (8.6 kB)
Collecting toolz>=0.9.0 (from chex>=0.1.86->optax->scvi-tools>=0.12.1->scarches)
  Using cached toolz-0.12.1-py3-none-any.whl.metadata (5.1 kB)
Collecting aiohttp!=4.0.0a0,!=4.0.0a1 (from fsspec[http]<2025.0,>=2022.5.0->lightning<2.2,>=2.0->scvi-tools>=0.12.1->scarches)
  Downloading aiohttp-3.9.5-cp39-cp39-macosx_11_0_arm64.whl.metadata (7.5 kB)
Requirement already satisfied: setuptools in /Users/administrateur/miniforge3/envs/scArches/lib/python3.9/site-packages (from lightning-utilities<2.0,>=0.8.0->lightning<2.2,>=2.0->scvi-tools>=0.12.1->scarches) (69.5.1)
Collecting mdurl~=0.1 (from markdown-it-py>=2.2.0->rich>=12.0.0->scvi-tools>=0.12.1->scarches)
  Using cached mdurl-0.1.2-py3-none-any.whl.metadata (1.6 kB)
Collecting etils[epath,epy] (from orbax-checkpoint->flax->scvi-tools>=0.12.1->scarches)
  Downloading etils-1.5.2-py3-none-any.whl.metadata (6.3 kB)
Requirement already satisfied: nest_asyncio in /Users/administrateur/miniforge3/envs/scArches/lib/python3.9/site-packages (from orbax-checkpoint->flax->scvi-tools>=0.12.1->scarches) (1.6.0)
Collecting aiosignal>=1.1.2 (from aiohttp!=4.0.0a0,!=4.0.0a1->fsspec[http]<2025.0,>=2022.5.0->lightning<2.2,>=2.0->scvi-tools>=0.12.1->scarches)
  Using cached aiosignal-1.3.1-py3-none-any.whl.metadata (4.0 kB)
Requirement already satisfied: attrs>=17.3.0 in /Users/administrateur/miniforge3/envs/scArches/lib/python3.9/site-packages (from aiohttp!=4.0.0a0,!=4.0.0a1->fsspec[http]<2025.0,>=2022.5.0->lightning<2.2,>=2.0->scvi-tools>=0.12.1->scarches) (23.1.0)
Collecting frozenlist>=1.1.1 (from aiohttp!=4.0.0a0,!=4.0.0a1->fsspec[http]<2025.0,>=2022.5.0->lightning<2.2,>=2.0->scvi-tools>=0.12.1->scarches)
  Downloading frozenlist-1.4.1-cp39-cp39-macosx_11_0_arm64.whl.metadata (12 kB)
Collecting multidict<7.0,>=4.5 (from aiohttp!=4.0.0a0,!=4.0.0a1->fsspec[http]<2025.0,>=2022.5.0->lightning<2.2,>=2.0->scvi-tools>=0.12.1->scarches)
  Downloading multidict-6.0.5-cp39-cp39-macosx_11_0_arm64.whl.metadata (4.2 kB)
Collecting yarl<2.0,>=1.0 (from aiohttp!=4.0.0a0,!=4.0.0a1->fsspec[http]<2025.0,>=2022.5.0->lightning<2.2,>=2.0->scvi-tools>=0.12.1->scarches)
  Downloading yarl-1.9.4-cp39-cp39-macosx_11_0_arm64.whl.metadata (31 kB)
Collecting async-timeout<5.0,>=4.0 (from aiohttp!=4.0.0a0,!=4.0.0a1->fsspec[http]<2025.0,>=2022.5.0->lightning<2.2,>=2.0->scvi-tools>=0.12.1->scarches)
  Using cached async_timeout-4.0.3-py3-none-any.whl.metadata (4.2 kB)
Using cached scArches-0.6.1-py3-none-any.whl (130 kB)
Downloading anndata-0.10.7-py3-none-any.whl (122 kB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 122.4/122.4 kB 849.7 kB/s eta 0:00:00
Downloading h5py-3.11.0-cp39-cp39-macosx_11_0_arm64.whl (3.0 MB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3.0/3.0 MB 10.2 MB/s eta 0:00:00
Downloading matplotlib-3.9.0-cp39-cp39-macosx_11_0_arm64.whl (7.8 MB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 7.8/7.8 MB 11.0 MB/s eta 0:00:00
Downloading numpy-1.26.4-cp39-cp39-macosx_11_0_arm64.whl (14.0 MB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 14.0/14.0 MB 8.3 MB/s eta 0:00:00
Downloading scanpy-1.10.1-py3-none-any.whl (2.1 MB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.1/2.1 MB 10.3 MB/s eta 0:00:00
Using cached scHPL-1.0.5-py3-none-any.whl (22 kB)
Downloading pandas-1.5.3-cp39-cp39-macosx_11_0_arm64.whl (11.0 MB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 11.0/11.0 MB 9.6 MB/s eta 0:00:00
Downloading scikit_learn-1.5.0-cp39-cp39-macosx_12_0_arm64.whl (11.0 MB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 11.0/11.0 MB 9.9 MB/s eta 0:00:00
Downloading scipy-1.13.1-cp39-cp39-macosx_12_0_arm64.whl (30.3 MB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 30.3/30.3 MB 8.5 MB/s eta 0:00:00
Downloading scvi_tools-1.1.2-py3-none-any.whl (380 kB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 380.2/380.2 kB 7.5 MB/s eta 0:00:00
Downloading torch-2.3.0-cp39-none-macosx_11_0_arm64.whl (61.0 MB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 61.0/61.0 MB 9.3 MB/s eta 0:00:00
Using cached tqdm-4.66.4-py3-none-any.whl (78 kB)
Using cached gdown-5.2.0-py3-none-any.whl (18 kB)
Using cached leidenalg-0.10.2-cp38-abi3-macosx_11_0_arm64.whl (1.4 MB)
Using cached muon-0.1.6-py3-none-any.whl (293 kB)
Downloading array_api_compat-1.7.1-py3-none-any.whl (37 kB)
Downloading contourpy-1.2.1-cp39-cp39-macosx_11_0_arm64.whl (244 kB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 245.0/245.0 kB 8.0 MB/s eta 0:00:00
Using cached cycler-0.12.1-py3-none-any.whl (8.3 kB)
Downloading fonttools-4.53.0-cp39-cp39-macosx_11_0_arm64.whl (2.2 MB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.2/2.2 MB 10.1 MB/s eta 0:00:00
Downloading igraph-0.11.5-cp39-abi3-macosx_11_0_arm64.whl (1.7 MB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.7/1.7 MB 4.6 MB/s eta 0:00:00
Using cached importlib_resources-6.4.0-py3-none-any.whl (38 kB)
Downloading jax-0.4.28-py3-none-any.whl (1.9 MB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.9/1.9 MB 6.3 MB/s eta 0:00:00
Downloading jaxlib-0.4.28-cp39-cp39-macosx_11_0_arm64.whl (64.1 MB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 64.1/64.1 MB 6.7 MB/s eta 0:00:00
Using cached joblib-1.4.2-py3-none-any.whl (301 kB)
Downloading kiwisolver-1.4.5-cp39-cp39-macosx_11_0_arm64.whl (66 kB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 66.2/66.2 kB 4.2 MB/s eta 0:00:00
Using cached legacy_api_wrap-1.4-py3-none-any.whl (15 kB)
Downloading lightning-2.1.4-py3-none-any.whl (2.0 MB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.0/2.0 MB 3.8 MB/s eta 0:00:00
Using cached fsspec-2024.6.0-py3-none-any.whl (176 kB)
Using cached mudata-0.2.3-py3-none-any.whl (24 kB)
Using cached networkx-3.2.1-py3-none-any.whl (1.6 MB)
Using cached newick-1.0.0-py2.py3-none-any.whl (10 kB)
Downloading numba-0.59.1-cp39-cp39-macosx_11_0_arm64.whl (2.6 MB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.6/2.6 MB 4.0 MB/s eta 0:00:00
Downloading numpyro-0.15.0-py3-none-any.whl (345 kB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 345.7/345.7 kB 4.9 MB/s eta 0:00:00
Downloading pillow-10.3.0-cp39-cp39-macosx_11_0_arm64.whl (3.4 MB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3.4/3.4 MB 4.6 MB/s eta 0:00:00
Using cached pynndescent-0.5.12-py3-none-any.whl (56 kB)
Using cached pyparsing-3.1.2-py3-none-any.whl (103 kB)
Using cached pyro_ppl-1.9.1-py3-none-any.whl (755 kB)
Using cached rich-13.7.1-py3-none-any.whl (240 kB)
Using cached seaborn-0.13.2-py3-none-any.whl (294 kB)
Downloading statsmodels-0.14.2-cp39-cp39-macosx_11_0_arm64.whl (10.1 MB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 10.1/10.1 MB 4.3 MB/s eta 0:00:00
Using cached patsy-0.5.6-py2.py3-none-any.whl (233 kB)
Using cached threadpoolctl-3.5.0-py3-none-any.whl (18 kB)
Using cached torchmetrics-1.4.0.post0-py3-none-any.whl (868 kB)
Using cached umap_learn-0.5.6-py3-none-any.whl (85 kB)
Using cached filelock-3.14.0-py3-none-any.whl (12 kB)
Downloading flax-0.8.4-py3-none-any.whl (698 kB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 698.6/698.6 kB 3.2 MB/s eta 0:00:00
Using cached get_annotations-0.1.2-py3-none-any.whl (4.5 kB)
Using cached natsort-8.4.0-py3-none-any.whl (38 kB)
Downloading optax-0.2.2-py3-none-any.whl (223 kB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 223.7/223.7 kB 1.6 MB/s eta 0:00:00
Using cached protobuf-5.27.0-cp38-abi3-macosx_10_9_universal2.whl (412 kB)
Using cached sympy-1.12.1-py3-none-any.whl (5.7 MB)
Using cached absl_py-2.1.0-py3-none-any.whl (133 kB)
Downloading chex-0.1.86-py3-none-any.whl (98 kB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 98.2/98.2 kB 2.4 MB/s eta 0:00:00
Using cached lightning_utilities-0.11.2-py3-none-any.whl (26 kB)
Downloading llvmlite-0.42.0-cp39-cp39-macosx_11_0_arm64.whl (28.8 MB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 28.8/28.8 MB 4.1 MB/s eta 0:00:00
Using cached markdown_it_py-3.0.0-py3-none-any.whl (87 kB)
Downloading ml_dtypes-0.4.0-cp39-cp39-macosx_10_9_universal2.whl (390 kB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 390.9/390.9 kB 6.1 MB/s eta 0:00:00
Using cached mpmath-1.3.0-py3-none-any.whl (536 kB)
Using cached opt_einsum-3.3.0-py3-none-any.whl (65 kB)
Using cached pyro_api-0.1.2-py3-none-any.whl (11 kB)
Using cached texttable-1.7.0-py2.py3-none-any.whl (10 kB)
Using cached contextlib2-21.6.0-py2.py3-none-any.whl (13 kB)
Downloading msgpack-1.0.8-cp39-cp39-macosx_11_0_arm64.whl (85 kB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 85.1/85.1 kB 6.7 MB/s eta 0:00:00
Using cached multipledispatch-1.0.0-py3-none-any.whl (12 kB)
Downloading orbax_checkpoint-0.5.15-py3-none-any.whl (210 kB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 210.8/210.8 kB 4.7 MB/s eta 0:00:00
Downloading tensorstore-0.1.60-cp39-cp39-macosx_11_0_arm64.whl (13.5 MB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 13.5/13.5 MB 5.8 MB/s eta 0:00:00
Downloading pytorch_lightning-2.2.5-py3-none-any.whl (802 kB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 802.3/802.3 kB 2.0 MB/s eta 0:00:00
Using cached stdlib_list-0.10.0-py3-none-any.whl (79 kB)
Downloading aiohttp-3.9.5-cp39-cp39-macosx_11_0_arm64.whl (390 kB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 390.7/390.7 kB 4.7 MB/s eta 0:00:00
Using cached mdurl-0.1.2-py3-none-any.whl (10.0 kB)
Using cached toolz-0.12.1-py3-none-any.whl (56 kB)
Using cached aiosignal-1.3.1-py3-none-any.whl (7.6 kB)
Using cached async_timeout-4.0.3-py3-none-any.whl (5.7 kB)
Downloading frozenlist-1.4.1-cp39-cp39-macosx_11_0_arm64.whl (53 kB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 53.7/53.7 kB 2.9 MB/s eta 0:00:00
Downloading multidict-6.0.5-cp39-cp39-macosx_11_0_arm64.whl (30 kB)
Downloading yarl-1.9.4-cp39-cp39-macosx_11_0_arm64.whl (81 kB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 81.8/81.8 kB 644.0 kB/s eta 0:00:00
Downloading etils-1.5.2-py3-none-any.whl (140 kB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 140.6/140.6 kB 3.1 MB/s eta 0:00:00
Building wheels for collected packages: docrep, ml-collections, session-info
  Building wheel for docrep (setup.py) ... done
  Created wheel for docrep: filename=docrep-0.3.2-py3-none-any.whl size=19878 sha256=043c44d5311f9f486d5f67448ca9e0e1952290f7906a87377408f8cd2be7ada3
  Stored in directory: /Users/administrateur/Library/Caches/pip/wheels/e5/f0/3f/17394a03ed36922f620186a5a9ebd6bce2b4579020243c7a68
  Building wheel for ml-collections (setup.py) ... done
  Created wheel for ml-collections: filename=ml_collections-0.1.1-py3-none-any.whl size=94508 sha256=ca2b290da869ab787897be78fc88fec1421c144269b85ff1548c6f05ce014c53
  Stored in directory: /Users/administrateur/Library/Caches/pip/wheels/fd/c2/0d/5d94d95e5875ea17b85a9f1f99b8dd2e50517137c8042c6468
  Building wheel for session-info (setup.py) ... done
  Created wheel for session-info: filename=session_info-1.0.0-py3-none-any.whl size=8024 sha256=caff56637067b41cef5c5bc154b0a2644613a0e74e5c821f9e13de69e36f53bb
  Stored in directory: /Users/administrateur/Library/Caches/pip/wheels/d4/fc/2e/00ca60bac7954b84907efd41baa9b4853500eaeec4228410c6
Successfully built docrep ml-collections session-info
Installing collected packages: texttable, pyro-api, newick, multipledispatch, mpmath, array-api-compat, tqdm, toolz, threadpoolctl, sympy, stdlib_list, pyparsing, protobuf, pillow, numpy, networkx, natsort, multidict, msgpack, mdurl, llvmlite, lightning-utilities, legacy-api-wrap, kiwisolver, joblib, importlib-resources, igraph, get-annotations, fsspec, frozenlist, fonttools, filelock, etils, docrep, cycler, contextlib2, async-timeout, absl-py, yarl, torch, session-info, scipy, patsy, pandas, opt-einsum, numba, ml-dtypes, ml-collections, markdown-it-py, leidenalg, h5py, contourpy, aiosignal, torchmetrics, tensorstore, statsmodels, scikit-learn, rich, pyro-ppl, matplotlib, jaxlib, jax, gdown, anndata, aiohttp, seaborn, pynndescent, orbax-checkpoint, numpyro, mudata, chex, umap-learn, scHPL, pytorch-lightning, optax, scanpy, lightning, flax, scvi-tools, muon, scarches
  Attempting uninstall: pandas
    Found existing installation: pandas 2.0.3
    Uninstalling pandas-2.0.3:
      Successfully uninstalled pandas-2.0.3
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
phate 1.0.11 requires Deprecated, which is not installed.
phate 1.0.11 requires future, which is not installed.
phate 1.0.11 requires graphtools>=1.5.3, which is not installed.
phate 1.0.11 requires s_gd2>=1.8.1, which is not installed.
phate 1.0.11 requires scprep>=0.11.1, which is not installed.
phate 1.0.11 requires tasklogger>=1.2, which is not installed.
Successfully installed absl-py-2.1.0 aiohttp-3.9.5 aiosignal-1.3.1 anndata-0.10.7 array-api-compat-1.7.1 async-timeout-4.0.3 chex-0.1.86 contextlib2-21.6.0 contourpy-1.2.1 cycler-0.12.1 docrep-0.3.2 etils-1.5.2 filelock-3.14.0 flax-0.8.4 fonttools-4.53.0 frozenlist-1.4.1 fsspec-2024.6.0 gdown-5.2.0 get-annotations-0.1.2 h5py-3.11.0 igraph-0.11.5 importlib-resources-6.4.0 jax-0.4.28 jaxlib-0.4.28 joblib-1.4.2 kiwisolver-1.4.5 legacy-api-wrap-1.4 leidenalg-0.10.2 lightning-2.1.4 lightning-utilities-0.11.2 llvmlite-0.42.0 markdown-it-py-3.0.0 matplotlib-3.9.0 mdurl-0.1.2 ml-collections-0.1.1 ml-dtypes-0.4.0 mpmath-1.3.0 msgpack-1.0.8 mudata-0.2.3 multidict-6.0.5 multipledispatch-1.0.0 muon-0.1.6 natsort-8.4.0 networkx-3.2.1 newick-1.0.0 numba-0.59.1 numpy-1.26.4 numpyro-0.15.0 opt-einsum-3.3.0 optax-0.2.2 orbax-checkpoint-0.5.15 pandas-1.5.3 patsy-0.5.6 pillow-10.3.0 protobuf-5.27.0 pynndescent-0.5.12 pyparsing-3.1.2 pyro-api-0.1.2 pyro-ppl-1.9.1 pytorch-lightning-2.2.5 rich-13.7.1 scHPL-1.0.5 scanpy-1.10.1 scarches-0.6.1 scikit-learn-1.5.0 scipy-1.13.1 scvi-tools-1.1.2 seaborn-0.13.2 session-info-1.0.0 statsmodels-0.14.2 stdlib_list-0.10.0 sympy-1.12.1 tensorstore-0.1.60 texttable-1.7.0 threadpoolctl-3.5.0 toolz-0.12.1 torch-2.3.0 torchmetrics-1.4.0.post0 tqdm-4.66.4 umap-learn-0.5.6 yarl-1.9.4

So I was able to run the code in what seems to be - judging by the speed of training - a mono-cpu mode. But when trying train, for instance, an scGen model - it takes ages. I suspect that it's because on macos there's no pytorch-cuda, but we do have mps.
How do i check if the GPU is engaged when running, for instance, a simple training from the tutorial? It sure doesn't feel like it
network = sca.models.scgen(adata = source_adata,
                           hidden_layer_sizes=[256,128])
network.train(n_epochs=epoch, early_stopping_kwargs = early_stopping_kwargs)
 |██------------------| 14.0%  - epoch_loss: 0.0647465525 - val_loss: 0.0618337077


S3 consistency guarantees

I was perusing the code a little more, and I wanted to bring this up, because people will run into it. In the S3Map class, you provide a __setitem__. S3 only has eventual consistency guarantees on overwrites. Anecdotally, I've heard that this can be up to 48 hours. If people start to try to use this as a true, consistent key-value store in a production setting, they're going to have a bad time. I suppose removing this is going to be out of the question, so I would at least provide a very visible warning somewhere.

Q: What data consistency model does Amazon S3 employ?

Amazon S3 buckets in all Regions provide read-after-write consistency for PUTS of new objects and eventual consistency for overwrite PUTS and DELETES.

https://aws.amazon.com/s3/faqs/

Thanks for the heads up.

My personal use case (storing large ndarrays) is write-once-read-many, so this doesn't bother me-as-a-user.  However, I recognize that this can introduce super-subtle and damaging bugs.  In the short term I'm tempted to resolve it with loud warnings, both in documentation and in docstrings.  I'm not sure how to handle this long-term.

fwiw, testing around with overwiting a mapping key seems to update immediately. Of course, S3 could be doing fancy caching for my user; or maybe the consistency guarantee refers to access from different regions.

Yeah performance is going to vary, and I don't think you can plan for it,
but I would take them at their word. Regions may matter but if you search
for the issue you'll find that a lot of people discovered this the hard way
down the line in very subtle bugs, particularly in the fake a filesystem
for hadoop use case.
My suggestion would be to avoid the temptation of Python dunder magics for
this and to use verbs for things like put and post that have different code
paths, so users are forced to confront it. Presenting it has a consistent
key-value store like a dictionary is going to bite people.
On Wed, May 25, 2016, 9:39 AM Martin Durant<EMAIL_ADDRESS>wrote:

fwiw, testing around with overwiting a mapping key seems to update
immediately. Of course, S3 could be doing fancy caching for my user; or
maybe the consistency guarantee refers to access from different regions.
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/dask/s3fs/issues/49#issuecomment-221597217

I suppose the lack of consistency only manifests itself in the face of a
partition given the CAP theorem, so you really can't plan for it and you
won't know unless you implement an external system to provide something
approaching consistency in the face of a super, highly available service,
but this is a hard and big problem.
On Wed, May 25, 2016, 10:44 AM Skipper Seabold<EMAIL_ADDRESS>wrote:

Yeah performance is going to vary, and I don't think you can plan for it,
but I would take them at their word. Regions may matter but if you search
for the issue you'll find that a lot of people discovered this the hard way
down the line in very subtle bugs, particularly in the fake a filesystem
for hadoop use case.
My suggestion would be to avoid the temptation of Python dunder magics for
this and to use verbs for things like put and post that have different code
paths, so users are forced to confront it. Presenting it has a consistent
key-value store like a dictionary is going to bite people.
On Wed, May 25, 2016, 9:39 AM Martin Durant<EMAIL_ADDRESS>wrote:

fwiw, testing around with overwiting a mapping key seems to update
immediately. Of course, S3 could be doing fancy caching for my user; or
maybe the consistency guarantee refers to access from different regions.
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/dask/s3fs/issues/49#issuecomment-221597217

Semi-relevant https://blogs.aws.amazon.com/bigdata/post/Tx1WL4KR7SE37YY/Ensuring-Consistency-When-Using-Amazon-S3-and-Amazon-Elastic-MapReduce-for-ETL-W

https://github.com/Netflix/s3mper

Maybe there could be an option to raise an exception if one tries to set a key that already exists?  If there were such an option, having it on by default would be good, I'd think, with a warning in the docstring.


package.json is now using main attribute for autoload

Hi,
I'm editing a React project, and require() method is looking for index.js file which not exists.
Using main attribute fixes javascript main file load.

:+1: Thank you!

Thank you, I really appreciate this.
Do you think you can publish this on npm?

Done! Also npm updated the deps.
On Wed, Jun 17, 2015 at 8:53 PM, Mikaël FIMA<EMAIL_ADDRESS>wrote:

Thank you, I really appreciate this.
Do you think you can publish this on npm?
—
Reply to this email directly or view it on GitHub
https://github.com/cofounders/googletagmanager/pull/1#issuecomment-112789158
.


names and paths not aligned in ImageList class

In ez_zarr 0.2.1 paths and names are wrongly assigned within the image class when using import_Fractal_plate
Example:
plate = ome_zarr.import_Fractal_plate(zarr_directory) # zarr_directory can be any Fractal-test plates
im = plate['B02'] # pick one well to showcase
im.get_paths() # returns .../_mip.zarr/G/02/0' # requested well B02, but returned image at 'G02'

Thanks for the report - indeed I think there is an unmatched sorting step, sorry about that.
Could you try to install ez-zarr from the fix-plate-sort branch and see if that does it on your data set for now? We will fix this in the release version once back from holidays.

I installed the fix-plate-sort branch which seems to work on my data set, now:
plate = ome_zarr.import_Fractal_plate(zarr_directory) # zarr_directory can be any Fractal-test plates
im = plate['B02'] # picking one well ...
im.get_paths() # returns the expected path .../_mip.zarr/B/02/0' # requested well B02, and returned image at 'G02'

Thanks!

Great, thanks for checking! I have added some more unit tests as well 🙂

This has now been released on GitHub and PyPi (version 0.2.3, https://pypi.org/project/ez-zarr/).


scale_to_freq returns repetitive frequencies

Description
I have noticed that the conversion from scales to frequencies returns a vector containing repetitive frequencies. For instance, in the example provided in the README file, there are 245 scales, which are converted to an array of frequencies of length 245. However, around 23% of the frequencies are repetitive values.
I suspect the issue is with the indices of the peaks of the wavelets computed in scale_to_freq  at line 122.
# find peak indices
idxs = np.argmax(psis, axis=-1)

Which seems to have repetitive values. Is this a known behaviour? If so, is there any suggested workaround?
Thank you,
Daniele
Code for reproduction
import numpy as np
import matplotlib.pyplot as plt
from ssqueezepy import ssq_cwt, ssq_stft
from ssqueezepy.experimental import scale_to_freq
from ssqueezepy import Wavelet, cwt, stft, imshow

#%%# Define signal ####################################
N = 2048
t = np.linspace(0, 10, N, endpoint=False)
xo = np.cos(2 * np.pi * 2 * (np.exp(t / 2.2) - 1))
xo += xo[::-1]  # add self reflected
x = xo + np.sqrt(2) * np.random.randn(N)  # add noise

#%%# With units #######################################

fs = 400
t = np.linspace(0, N/fs, N)
wavelet = Wavelet()
Wx, scales = cwt(x, wavelet)

freqs_cwt = scale_to_freq(scales, wavelet, len(x), fs=fs)

print(f"Number of scales: {len(scales)}")
print(f"Lenght of frequency array: {len(freqs_cwt)}")
print(f"Number of unique frequencies: {len(np.unique(freqs_cwt))}")
print(f"Proportion of repetitive frequencies: {round(1-(len(np.unique(freqs_cwt)) / len(freqs_cwt)), 2)}")

A follow up on this. I have tried to replicate Matlab's scale2frq behaviour.
import numpy as np
from ssqueezepy.experimental import scale_to_freq
from ssqueezepy import Wavelet
from ssqueezepy.utils import cwt_scalebounds

# Define signal parameters
sampling_rate_hz  = 1000
signal_duration_s = 1
number_of_samples = signal_duration_s * sampling_rate_hz
time_vector   = np.linspace(0, 1, number_of_samples, endpoint=False)

# Define wavelet
wavelet_type = ("morlet", {"mu":7})
wavelet = Wavelet(wavelet_type)

# Get range of scales
minimum_possible_scales, maximum_possible_scales = cwt_scalebounds(wavelet, number_of_samples, preset = "maximal")
all_scales = make_scales(number_of_samples, min_scale=minimum_possible_scales, max_scale=maximum_possible_scales, scaletype="log-piecewise", wavelet=wavelet)

# Convert to frequencies following Matlab's scal2frq
frequencies       = wavelet.wc_ct / ( all_scales * (1/sampling_rate_hz) )

plt.plot(frequencies)
print(f"Minimum Frequency: {frequencies.min()}")
print(f"Max Frequency: {frequencies.max()}")

I then grabbed the scales (all_scales) and passed onto Matlab to replicate the results:
# all_scales copied from python
approximate_frequencies = scal2frq(all_scales, "cmor1-7", 1/1000);

The results are basically identical, with the mean error being 2.7659e-05.
However, I have a couple of issues because I'm not sure if I can trust these results:

What is the bandwidth of ("morlet", {"mu":7}) or any other wavelet? Is there a way to extract it? For the Matlab example, I've just guessed it was 1.
The results are very different when using scale_to_freq, though they seems more correct. I have computed those with:

scale_to_freq(all_scales, wavelet, number_of_samples, sampling_rate_hz)

Thanks for the report. Reproduced (scale_to_freq problem), fixed in #114.
Now it's 11%. scales='log-piecewise' is already a significant reduction (relative to 'log'), but its handling isn't flawless. It's a fundamental continuous-discrete limitation with CWT. There is a workaround, though not pure-CWT based, and not part of ssqueezepy.
But also, the repetition's in the peak center frequency (what scale_to_freq returns). Other measures wouldn't always agree. Visually inspecting, only a few wavelets are duplicate-ish:

visuals code
from ssqueezepy.visuals import plot

freqs, repeats = [], []
for f in freqs_cwt:
    if f in freqs and f != 2048:  # avoid 2048 to avoid large gap in plot
        repeats.append(f)
    else:
        freqs.append(f)
plot(wavelet._Psih[-66:, :50].T, color='tab:blue',
     vlines=(repeats, {'color': 'tab:red', 'linewidth': 1}))

Patch note: I expect that most affected were the lowest frequencies, and most frequencies were minorly affected. One could measure as |1 - f_new/f_old| vs freq index, with both f_new and f_old computed using the new function, but f_old using scale_to_freq(, padtype=None).
Concerning MATLAB and the rest, I consider it out of scope. But if you can show inaccuracy in scale_to_freq, I'll take it as a bug report.

Thank you for this and for the useful links!
Just one more thing if you don't mind. I saw your fix and how internally the wavelet is padded to the closer power of 2. Are there any drawbacks of increasing the parameter N way above the length of the signal? It seems to reduce the number of repetitive frequencies too. I don't have a good intuition though about the drawbacks of doing this.
import numpy as np
from ssqueezepy.experimental import scale_to_freq
from ssqueezepy import Wavelet, cwt

#%%# Define signal ####################################
N = 2048
t = np.linspace(0, 10, N, endpoint=False)
xo = np.cos(2 * np.pi * 2 * (np.exp(t / 2.2) - 1))
xo += xo[::-1]  # add self reflected
x = xo + np.sqrt(2) * np.random.randn(N)  # add noise

#%%# With units #######################################

fs = 400
t = np.linspace(0, N/fs, N)
wavelet = Wavelet(('morlet', {'mu': 7}), N=1024)
Wx, scales = cwt(x, wavelet)

freqs_cwt_original = scale_to_freq(scales, wavelet, len(x), fs=fs)
freqs_cwt_extrapad = scale_to_freq(scales, wavelet, 10000, fs=fs)

print(f"Repetitive frequencies original: {round(1-(len(np.unique(freqs_cwt_original)) / len(freqs_cwt_original)), 2)}")
print(f"Repetitive frequencies padded: {round(1-(len(np.unique(freqs_cwt_extrapad)) / len(freqs_cwt_extrapad)), 2)}")


Spell check and natural language corrections

Spell check and natural language corrections for making read me docs more natural to read and understand

@DavidAJohnston - thanks for the feedback - I have resolved the conflicts and it is ready to merge now.


Refactor namespaces in Tests

Namespaces should be FemDesign.Area.ClassTest. For example:
FemDesign.AuxiliaryResults.LabelledSectionTests

@andosca
just double checking.
Were you thinking at renaming the namespace in the way I have done it?
https://github.com/strusoft/femdesign-api/commit/3886ea121ea9092d68bb912fa74ea4fc920fa0bb

Yes that looks good!


Revise task page to deploy and access the Kubernetes Dashboard

Update https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/ with a new title, a page description, and some rewording.
Old title: Web UI (Dashboard) (doesn't imply a task)
New title: Deploy and Access the Kubernetes Dashboard
/kind cleanup
/language en

Preview of modified page:
https://deploy-preview-29515--kubernetes-io-main-staging.netlify.app/docs/tasks/access-application-cluster/web-ui-dashboard/

/lgtm
/approve


requests.exceptions.MissingSchema: Invalid URL 'None': No scheme supplied. Perhaps you meant https://None?

Thanks for sharing but I find this error, despite doing all the correct steps.

Thanks for sharing but I find this error, despite doing all the correct steps.

Hi @richkidpe,
This error happens because the scheduler uses the dwn_data function to request data from an API. Within the ticker_dwn module this function is looking for an API_URL environment variable to use in the request.
Commenting out these lines in my_app.py should get it running without needing a valid API_URL
sched = BackgroundScheduler(daemon=True)
# sched.add_job(sensor)
# sched.add_job(sensor, CronTrigger.from_crontab("0,30 13-20 * * 0-4", timezone=UTC))
sched.start()

Thanks for sharing but I find this error, despite doing all the correct steps.

Hi @richkidpe,
This error happens because the app's scheduler uses the dwn_data function to request data from an API. Within the ticker_dwn module this function is looking for an API_URL environment variable to use in the request.
Commenting out these lines in my_app.py should get it running without needing a valid API_URL
# sched.add_job(sensor)
# sched.add_job(sensor, CronTrigger.from_crontab("0,30 13-20 * * 0-4", timezone=UTC))

Thank you for responding. It worked, but it seems there might be issues with loading the CSV data.
Dash is running on http://<IP_ADDRESS>:8050/

Serving Flask app 'my_app'
Debug mode: off
WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.
 The other error is related to the "Date:" string that's pulled from the 3rd line.

Standard & Poors 500 Index,Last: 4405.71,Change:  29.4
"Date: 27 de agosto de 2023, 13:35 GMT-4",Bid: 4372.4199,Ask: 4424.3501,Size: 1*1,Volume: 0
Expiration Date,Calls,Last Sale,Net,Bid,Ask,Volume,IV,Delta,Gamma,Open Interest,Strike,Puts,Last Sale,Net,Bid,Ask,Volume,IV,Delta,Gamma,Open Interest
Fri Aug 25 2023,SPXW230825C04395000,9.03,-5.22,7.7,15.4,27417,0,0,0,1586,4395.00,SPXW230825P04395000,0.05,-23.6,0,0.05,31015,0,0,0,2541
Fri Aug 25 2023,SPXW230825C04400000,6,-6.2,5,6.5,72569,0,0,0,8113,4400.00,SPXW230825P04400000,0.05,-26.5,0,0.05,53405,0,0,0,7909
Fri Aug 25 2023,SPXW230825C04405000,0.4,-9.95,0.25,1.05,46167,0,0,0,1516,4405.00,SPXW230825P04405000,0.4,-29.25,0.3,0.45,34501,0,0,0,1394
Fri Aug 25 2023,SPXW230825C04410000,0.05,-8.6,0,0.05,69650,0,0,0,1552,4410.00,SPXW230825P04410000,4.3,-28.9,4,5,29282,0,0,0,1547
Fri Aug 25 2023,SPXW230825C04415000,0.05,-7.15,0,0.05,65938,0,0,0,2546,4415.00,SPXW230825P04415000,9.6,-26.9,8.8,10.7,15668,0,0,0,1013
Fri Aug 25 2023,SPXW230825C04420000,0.05,-5.85,0,0.05,71006,0,0,0,5770,4420.00,SPXW230825P04420000,15.3,-24.9,9.5,17,7682,0,0,0,1187
Mon Aug 28 2023,SPXW230828C04395000,20.4,0.5,21,21.4,2782,0.0909,0.6164,0.0106,915,4395.00,SPXW230828P04395000,9.38,-20.15,8.8,9.1,3515,0.089,-0.3833,0.0106,511
Mon Aug 28 2023,SPXW230828C04400000,17.7,-0.7,17.9,18.2,5781,0.0895,0.563,0.0111,1243,4400.00,SPXW230828P04400000,10.95,-20.5,10.6,10.9,5528,0.088,-0.4367,0.0111,1419
Mon Aug 28 2023,SPXW230828C04405000,14.8,-1.5,15,15.3,3974,0.0886,0.5073,0.0113,721,4405.00,SPXW230828P04405000,13,-21.7,12.8,13.1,2212,0.0874,-0.4925,0.0113,441
Mon Aug 28 2023,SPXW230828C04410000,12.5,-1.9,12.5,12.7,4763,0.0882,0.4504,0.0114,363,4410.00,SPXW230828P04410000,15.59,-21.85,15.2,15.5,3245,0.0867,-0.5493,0.0114,776
Mon Aug 28 2023,SPXW230828C04415000,10.22,-2.18,10.2,10.4,4269,0.0875,0.3938,0.0111,423,4415.00,SPXW230828P04415000,18.5,-22.75,17.9,18.2,1535,0.086,-0.6059,0.0111,321
Mon Aug 28 2023,SPXW230828C04420000,8.2,-2.63,8.3,8.5,3630,0.0869,0.3391,0.0106,420,4420.00,SPXW230828P04420000,21.04,-23.51,20.9,21.3,1306,0.0857,-0.6606,0.0106,384
Tue Aug 29 2023,SPXW230829C04395000,26.4,2.05,26.7,27.1,355,0.11,0.5882,0.0077,102,4395.00,SPXW230829P04395000,14.85,-17.5,14.1,14.4,694,0.1085,-0.4115,0.0077,200
Tue Aug 29 2023,SPXW230829C04400000,23.6,1.7,23.8,24.1,1569,0.109,0.5497,0.0079,147,4400.00,SPXW230829P04400000,16.6,-18.8,16.1,16.4,1757,0.1078,-0.4501,0.0079,1606
Tue Aug 29 2023,SPXW230829C04405000,20.8,0.8,20.9,21.3,373,0.1086,0.51,0.008,74,4405.00,SPXW230829P04405000,18.6,-19.1,18.3,18.5,314,0.1069,-0.4897,0.008,348
Tue Aug 29 2023,SPXW230829C04410000,18.1,0.5,18.3,18.6,603,0.1074,0.4698,0.0081,104,4410.00,SPXW230829P04410000,21,-19.6,20.6,20.9,227,0.106,-0.5299,0.0081,190
Tue Aug 29 2023,SPXW230829C04415000,16.1,0.4,16,16.2,443,0.107,0.4293,0.008,140,4415.00,SPXW230829P04415000,24.07,-19.78,23.1,23.5,154,0.1053,-0.5704,0.008,99
Tue Aug 29 2023,SPXW230829C04420000,13.7,-0.2,13.7,14,673,0.106,0.3891,0.0079,117,4420.00,SPXW230829P04420000,26.87,-20.18,25.8,26.2,112,0.1046,-0.6106,0.0079,172
Wed Aug 30 2023,SPXW230830C04395000,32.65,5.25,30.9,31.4,227,0.1194,0.5732,0.0064,96,4395.00,SPXW230830P04395000,19.1,-16.45,18.3,18.6,221,0.1186,-0.4266,0.0064,611
Wed Aug 30 2023,SPXW230830C04400000,27.5,2.4,28,28.4,1261,0.1187,0.5413,0.0065,501,4400.00,SPXW230830P04400000,21.15,-17.15,20.4,20.7,1303,0.1174,-0.4584,0.0065,989
Wed Aug 30 2023,SPXW230830C04405000,25.3,2.25,25.2,25.6,249,0.1178,0.5087,0.0066,155,4405.00,SPXW230830P04405000,23.17,-17.88,22.6,22.9,328,0.1164,-0.491,0.0066,160
Wed Aug 30 2023,SPXW230830C04410000,22.4,1.85,22.5,22.9,443,0.1172,0.4757,0.0066,180,4410.00,SPXW230830P04410000,25.3,-18.6,24.9,25.2,377,0.1156,-0.524,0.0066,563
Wed Aug 30 2023,SPXW230830C04415000,20.7,2.1,20,20.4,252,0.116,0.4424,0.0066,125,4415.00,SPXW230830P04415000,28.25,-18.6,27.4,27.7,182,0.115,-0.5572,0.0066,549
Wed Aug 30 2023,SPXW230830C04420000,17.9,1.25,17.7,18.1,326,0.1153,0.4092,0.0066,144,4420.00,SPXW230830P04420000,31.3,-18.55,30,30.5,204,0.114,-0.5905,0.0065,181
Thu Aug 31 2023,SPXW230831C04395000,35.55,3.7,35.4,35.8,286,0.1256,0.5734,0.0056,293,4395.00,SPXW230831P04395000,23.2,-14.75,21.2,21.5,128,0.1241,-0.4268,0.0056,380
Thu Aug 31 2023,SPXW230831C04400000,32.2,3.7,32.5,32.8,2176,0.125,0.5457,0.0057,5944,4400.00,SPXW230831P04400000,23.96,-17.1,23.2,23.5,2500,0.1232,-0.4545,0.0057,9634
Thu Aug 31 2023,SPXW230831C04405000,30.6,3.06,29.6,30,395,0.124,0.5174,0.0057,86,4405.00,SPXW230831P04405000,26.43,-17.3,25.3,25.7,229,0.1225,-0.4828,0.0057,436
Thu Aug 31 2023,SPXW230831C04410000,26.6,2.4,26.9,27.3,335,0.123,0.4887,0.0058,626,4410.00,SPXW230831P04410000,28.78,-17.02,27.6,28,182,0.1215,-0.5115,0.0058,454
Thu Aug 31 2023,SPXW230831C04415000,25,2.95,24.3,24.7,164,0.122,0.4597,0.0058,274,4415.00,SPXW230831P04415000,30.9,-17.9,30,30.4,150,0.1208,-0.5405,0.0058,188
Thu Aug 31 2023,SPXW230831C04420000,23.01,2.96,21.9,22.2,384,0.1211,0.4306,0.0058,524,4420.00,SPXW230831P04420000,33.1,-18.65,32.6,33,111,0.1199,-0.5696,0.0058,517

Hi @richkidpe,
I've released an update that should fix the CSV issue. The calc module only supported the US/EU date formats so it would throw an error with other dates such as 2023年8月29日 GMT-4 22:40 or, in your case, 27 de agosto de 2023, 13:35 GMT-4. G|Flows will now be able to handle most formats, so let me know if the data loads correctly for you.
Thanks for bringing it to my attention

I am also getting same error. Do i need to get the csv file from cboe or the one provided in data folder is good enough to pull the real time options

@rdyvptnm
The format that calc.py looks for is like the examples provided. Without an API, the quickest way to get a CSV file in this format is from the CBOE site.
  ---Example Data---
  Standard & Poors 500 Index,Last: 3990.5601,Change:  56.1801
  "Date: December 12, 2022 at 8:30 PM EST",Bid: 3962.01,Ask: 4016.6299,Size: 1*1,Volume: 0
  Expiration Date,Calls,Last Sale,Net,Bid,Ask,Volume,IV,Delta,Gamma,Open Interest,Strike,Puts,Last Sale,Net,Bid,Ask,Volume,IV,Delta,Gamma,Open Interest
  Mon Dec 12 2022,SPXW221212C01000000,2943.2,0.25,0,0,8,0,0,0,1,1000.00,SPXW221212P01000000,0,0,0,0,0,0,0,0,0
  ...

However, you can modify it to your preference. The spot price is taken from the 2nd line (1st line is ignored), and the date is taken from the 3rd.
  # Get Spot
  spotLine = optionsFileData[1]
  spotPrice = float(spotLine.split("Last:")[1].split(",")[0])
  fromStrike = 0.5 * spotPrice
  toStrike = 1.5 * spotPrice
  # Get Today's Date
  dateLine = optionsFileData[2]
  todayDate = dateLine.split("Date: ")[1].split(",Bid")[0]

The options data is separated in columns starting from the fifth line.
  df = pd.read_csv(filename, sep=",", header=None, skiprows=4)
  df.columns = [
      "ExpirationDate",
      "Calls",
      "CallLastSale",
      "CallNet",
      "CallBid",
      "CallAsk",
      "CallVol",
      "CallIV",
      "CallDelta",
      "CallGamma",
      "CallOpenInt",
      "StrikePrice",
      "Puts",
      "PutLastSale",
      "PutNet",
      "PutBid",
      "PutAsk",
      "PutVol",
      "PutIV",
      "PutDelta",
      "PutGamma",
      "PutOpenInt",
  ]

@rdyvptnm
By default, the format that calc.py looks for is like the examples provided. Without an API, the quickest way to get a CSV file in this format is from the CBOE site.
  ---Example Data---
  Standard & Poors 500 Index,Last: 3990.5601,Change:  56.1801
  "Date: December 12, 2022 at 8:30 PM EST",Bid: 3962.01,Ask: 4016.6299,Size: 1*1,Volume: 0
  Expiration Date,Calls,Last Sale,Net,Bid,Ask,Volume,IV,Delta,Gamma,Open Interest,Strike,Puts,Last Sale,Net,Bid,Ask,Volume,IV,Delta,Gamma,Open Interest
  Mon Dec 12 2022,SPXW221212C01000000,2943.2,0.25,0,0,8,0,0,0,1,1000.00,SPXW221212P01000000,0,0,0,0,0,0,0,0,0
  ...

If you have a different format, you can modify calc.py to your preference. The spot price is taken from the 2nd line (1st line is ignored), and the date is taken from the 3rd.
  # Get Spot
  spotLine = optionsFileData[1]
  spotPrice = float(spotLine.split("Last:")[1].split(",")[0])
  fromStrike = 0.5 * spotPrice
  toStrike = 1.5 * spotPrice
  # Get Today's Date
  dateLine = optionsFileData[2]
  todayDate = dateLine.split("Date: ")[1].split(",Bid")[0]

The options data is separated in columns starting from the fifth line.
  df = pd.read_csv(filename, sep=",", header=None, skiprows=4)
  df.columns = [
      "ExpirationDate",
      "Calls",
      "CallLastSale",
      "CallNet",
      "CallBid",
      "CallAsk",
      "CallVol",
      "CallIV",
      "CallDelta",
      "CallGamma",
      "CallOpenInt",
      "StrikePrice",
      "Puts",
      "PutLastSale",
      "PutNet",
      "PutBid",
      "PutAsk",
      "PutVol",
      "PutIV",
      "PutDelta",
      "PutGamma",
      "PutOpenInt",
  ]

I am using the same file that is under "data" folder.

I commented these 2 lines in my_app.py and  it runs cleanly with out throwing any exceptions  but still no data in the webpage "spx data unavailable try later"

Appreciate looking into this issue

can we hard code some url with some debug log saying this needs to be replaced with your own URL

@rdyvptnm,
It should be able to read files in the data directory without any URL.
Can you set debug mode to True in my_app.py
if __name__ == "__main__":
    cache.clear()
    app.run(debug=True)

and add these print statements to calc.py
df = pd.read_csv(filename, sep=",", header=None, skiprows=4)
print("file:", filename)
print("df:", df)

I'd like to see this output to get a better idea of your issue.

@rdyvptnm,
It should be able to read files in the data directory without any URL.
Can you set debug mode to True in my_app.py
if __name__ == "__main__":
    cache.clear()
    app.run(debug=True)

and add these print statements to calc.py
df = pd.read_csv(filename, sep=",", header=None, skiprows=4)
print("file:", filename)
print("df:", df)

It'll help me get a better idea of the issue.

I found the issue.. for some reason the files in data folder were reset and they were empty.  I downloaded todays data from the cboe web site and its working.
I have couple questions as a follow up:

How do I update this data in real time instead of 15 minutes
Do i need to download data every day from the cboe website?
Do i need to download monthly data or will it be updated automatically.

it looks like for real time data you need the URL. May i know what URL you are using for your website (gflows). is that free version or do i need to pay?

@rdyvptnm,
Glad to hear it's working
To answer your questions:

Real-time data comes with more costs. You'd have to purchase this from a provider that offers it (if there's enough interest, I'll add real-time data in the future but as a subscription).
Unless you provide an API to pull data from, you have to download the CSV files every day from the CBOE site and manually replace the files in the data folder.
The data doesn't update automatically without an API.

it looks like for real time data you need the URL. May i know what URL you are using for your website (gflows). is that free version or do i need to pay?

My API is private.
If you have other questions, please redirect them to the 'Discussions' section


Hexo generate error

When git clone total repo to the themes file at my localhost, and execute hexo generate and hexo server it will show the issue as below.
`Cannot read property 'path' of undefined
TypeError: /Users/niyao/N.Y./Projects/FrontEnd/Fiona2013BlogRepo/themes/Annie/layout/layout.ejs:22
20|
21|

22| 		<%- partial('_partial/footer-after') %>
23|
24|
25|
`

How can I solve it?

Total Error
ERROR /Users/niyao/N.Y./Projects/FrontEnd/Fiona2013BlogRepo/themes/Annie/layout/layout.ejs:22
    20| 		</main>
    21|
 >> 22| 		<%- partial('_partial/footer-after') %>
    23| 	</body>
    24| 	</html>
    25|

/Users/niyao/N.Y./Projects/FrontEnd/Fiona2013BlogRepo/themes/Annie/layout/_partial/footer-after.ejs:12
    10|
    11| <% if (theme.local_search.enable) { %>
 >> 12|     <%- partial('_partial/third/search') %>
    13| <% } %>
    14|
    15| <% if (theme.love.enable) { %>

/Users/niyao/N.Y./Projects/FrontEnd/Fiona2013BlogRepo/themes/Annie/layout/_partial/third/search.ejs:29
    27|     var isXml = true;
    28|     // Search DB path;
 >> 29|     var search_path = "<%= config.search.path %>";
    30|     if (search_path.length === 0) {
    31|       search_path = "search.xml";
    32|     } else if (/json$/i.test(search_path)) {

Cannot read property 'path' of undefined

@Sariay I set the _config.yml as follow
# Local search
# Dependencies: https://github.com/flashlab/hexo-generator-search
local_search:
    enable: false

So that, it will not exist the ERROR. However, it is not the best way to the problem. Can you help me?

oh! you can see the issue issue1
it can help you.
@Fiona2013


Bootstrap is loaded from node_modules folder

From the code
<dnn:DnnJsInclude runat="server" FilePath="node_modules/bootstrap/dist/js/bootstrap.bundle.min.js" ForceProvider="DnnFormBottomProvider" Priority="100" PathNameAlias="SkinPath"  />

I'm guessing you don't intend everyone that installs this to run npm install to get the skin to work.

@donker you are right - this is not expected. @ropalko pls fix

fixed in repo


feat: extend publishing fields, support raw serialization

Close #520

Probably, we need to support key argument in the publish_batch method too:
here https://github.com/airtai/fastkafka/blob/publish-extend/faststream/kafka/publisher.py#L58
and here https://github.com/airtai/fastkafka/blob/publish-extend/faststream/kafka/producer.py#L86


BitmapFont.data.setScale() is inherently flawed

After encountering a weird bug that can be see in the attached video (SelectBox enabling vertical scrollbar on first drop down, but not on subsequent drop downs: https://www.youtube.com/watch?v=PJNcYH4d9gk), I debugged my app and came to find out that the problem is in BitmapFontData.setScale() method.
The problem is with float calculations. Float has a limited precision, and when multiplying it and then dividing it, we risk to change the original value. Let me illustrate this.
In my example, my font has a capHeight of 28 originally. I scale it by factor 0.46, so it becomes 12.88. Then some label scales it by factor 0.414 (in getPrefHeight(), which calls scaleAndComputePrefSize() and sizes the font for a moment to calculate width and height and then scales it back to original value) so capHeight becomes 11.592. It then scales it back by factor 0.46, and the new capHeight value becomes 12.880001.
Here we can see the problem: when we first scaled it, the new capHeight became 12.88, the second time around becomes 12.880001 due to float precision limitations when mupltiplying and dividing floats. To make things short: after a few scalings, the capHeight values stabilizes at 12.880003. Now this seems a small problem, but is not, since the values is not what it originally was and in some widgets that causes problems, like in my case in SelectBox, which does some check "if 12.88 >= 12.880003" which doesn't hold anymore and hence it adds a vertical scrollbar which is not required at all.
setScale() method's code should be fixed. I can make a PR if someone can confirm my issue. My solution would be to store original font attributes in e.g.:
float originalCapHeight
float originalAscent
float originalLineHeight
etc.
and then scale each time based on those original values, not the scaled values themselves. This is how setScale() would create same values each time we would call it.
Version of libGDX and/or relevant dependencies
1.11.0 (the latest, and older ones too)

Created a PR that works well (I tested it in my project):
https://github.com/libgdx/libgdx/pull/7102


[draft]add a flow to check repo's grammar and spelling

Description
Please add an informative description that covers that changes made by the pull request and link all relevant issues.
All Promptflow Contribution checklist:

[ ] The pull request does not introduce [breaking changes]
[ ] CHANGELOG is updated for new features, bug fixes or other significant changes.
[ ] I have read the contribution guidelines.

General Guidelines and Best Practices

[ ] Title of the pull request is clear and informative.
[ ] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[ ] Pull request includes test coverage for the included changes.

close as we have speller check now


Can't install Azure Functions Core Tools on Debian 10

Following current instructions to install on Debian 10, when I try to use sudo apt-get update I get error for packages configured multiple times:
W: Target Packages (main/binary-amd64/Packages) is configured multiple times in /etc/apt/sources.list.d/dotnetdev.list:1 and /etc/apt/sources.list.d/microsoft-prod.list:2
W: Target Packages (main/binary-all/Packages) is configured multiple times in /etc/apt/sources.list.d/dotnetdev.list:1 and /etc/apt/sources.list.d/microsoft-prod.list:2
W: Target Translations (main/i18n/Translation-en) is configured multiple times in /etc/apt/sources.list.d/dotnetdev.list:1 and /etc/apt/sources.list.d/microsoft-prod.list:2
W: Target Packages (main/binary-amd64/Packages) is configured multiple times in /etc/apt/sources.list.d/dotnetdev.list:1 and /etc/apt/sources.list.d/microsoft-prod.list:2
W: Target Packages (main/binary-all/Packages) is configured multiple times in /etc/apt/sources.list.d/dotnetdev.list:1 and /etc/apt/sources.list.d/microsoft-prod.list:2
W: Target Translations (main/i18n/Translation-en) is configured multiple times in /etc/apt/sources.list.d/dotnetdev.list:1 and /etc/apt/sources.list.d/microsoft-prod.list:2

If I remove either dotnetdev.list or microsoft-prod.list and after updating, try to install, it can't locate the package:
sudo apt-get install azure-functions-core-tools
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package azure-functions-core-tools

The content of those files are:
dotnetdev.list:
deb [arch=amd64] https://packages.microsoft.com/debian/10/prod buster main

microsoft-prod.list:
deb [arch=amd64,arm64,armhf] https://packages.microsoft.com/debian/10/prod buster main

I did already install the Azure CLI and Dot Net Core previously (following their official instructions), maybe that's why there is that duplication on source files.
If I compare the files available on the URL for the packages for Debian 9 and Debian 10, I find that the one from Debian 10 under the letter 'a' doesn't have the Functions Core Tools folder:
https://packages.microsoft.com/debian/10/prod/pool/main/a/
https://packages.microsoft.com/debian/9/prod/pool/main/a/
On the Github page, instructions for installing the Core Tools only get to version 9 of Debian.
Following the instructions for "Other Linux Distributions" worked perfectly.
Recomendation to please update the online Debian 10 deb package, or remove mention to Debian 10 installation on this page until it is available. Thanks!

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

ID: b2646ad4-34b7-fc5e-dcc9-d53a061df394
Version Independent ID: bbff4fda-24e4-2b62-24b9-94cda5f53bed
Content: Work with Azure Functions Core Tools
Content Source: articles/azure-functions/functions-run-local.md
Service: azure-functions
GitHub Login: @ggailey777
Microsoft Alias: glenga

@vicenteherrera Thank you for your feedback! We will review and update as appropriate.

@ahmelsayed do you know about Debian 10 support for Core Tools?

@mike-urnun-msft can we have an update? This still happens.

Looks like it wasn't packaged in the buster distribution. Moreover, this issue suggests Debian packaging is yet to be part of the CI pipeline too. As such, I'll remove the row from the documentation for now until we better clarify this with the Functions team. Once my PR for this doc change merges, this issue will auto-close.

It is still not being possible to install azure functions core tools using the underlying instructions on Debian Buster. I´m using the WSL version of Debian Buster.


system-library-rancher-monitoring-0.0.3 not found

when install project monitor find red error msg:
Catalogtemplateversions.management.cattle.io "system-library-rancher-monitoring-0.0.3" not found

Useful
Info

Versions
Rancher v2.2.8 UI: v2.2.94

path
/p/c-h6k59:p-zqw6m/apps/p-zqw6m:project-monitoring

Please check system-library in Global -> Tools -> Catalog page

Please check system-library in Global -> Tools -> Catalog page

thanks , Problem solved


feat(@embark/env): introduce embark-env package

This package comes with a setUpEnv() function that can be called to
prepare Embark's environment variables for different process contexts.
This allows us to set up Embark's environment within a test runner context
without the requirement of importing packages/embark/src/lib/core/env.js,
which happens to set up those necessary environment variables as a side effect.
It's important that a path to packages/embark's root is passed down to setUpEnv()
to ensure EMBARK_PATH gets the correct value.
E.g. within a package embark-console, setUpEnv() can be called within its tests
like the following:
// packages/embark-console/src/test/console.js

import { joinPath } from 'embark-utils';
import { setUpEnv } from 'embark-env';

setUpEnv(joinPath(__dirname, '../../../embark'));

Here, __dirname + '../../../embark' ensures EMBARK_PATH points to the root
of packages/embark. This might look different in other contexts.
For example calling this function from a test file within packages/embark, this would
look like this:
// packages/embark/src/test/some_file.js

import { joinPath } from 'embark-utils';
import { setUpEnv } from 'embark-env';

setUpEnv(joinPath(__dirname, '../../'));

ATTENTION: The base of this PR is refactor/coverage which hasn't landed yet!

As discussed offline with @michaelsbradleyjr we'll be moving setUpEnv() to embark-utils. This also avoids the introduction of another package.

Moved setUpEnv() into embark-utils


Fix Nuvoton Ethernet Build by updating tinycbor path in project file

Fix Nuvoton Ethernet Build failure by updating path to tinycbor files in project file
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/cbmc run checks


Debug normalization

Need to debug normalization next.

This requires a Spec, which is the Fun spec, and a pretty printer, but the latter is under development.


Terminal Window doesn't always display properly

macOS 10.12.6
VSCode Insiders 1.18.0
iTerm2
ZSH
My problem is that the integrated terminal doesn't always fire up at all. I have the line "terminal.external.osxExec": "iTerm.app", in my settings. When it does decide to work, it works really well, displaying the ZSH fonts really nicely, but it only works maybe 50% of the time.
For example, here I have just pressed Ctrl ` to try to activate the terminal - nothing...

Carlca, I had the exact same issue, and minimap not rendering issue. Both were solved for my system probably because I have an older OS version and/or graphics card with relatively low RAM. I am on OS El Capitan 10.11.6 with NVIDIA GeForce 8800 GT 512 MB.
Here's what solved my issue:

close vscode app
from command-line:

open '/Applications/Visual Studio Code.app' --args --disable-gpu

It’s early days so far, and I’ve only tried it a few times, but, by golly, it seems to work!! Thank you so much!
Cheers,
Carl
On 9 Oct 2017, 17:26 +0100, KonaBlend<EMAIL_ADDRESS>wrote:

Carlca, I had the exact same issue, and minimap not rendering issue. Both were solved for my system probably because I have an older OS version and/or graphics card with relatively low RAM. I am on OS El Capitan 10.11.6 with NVIDIA GeForce 8800 GT 512 MB.
Here's what solved my issue:

close vscode app
from command-line:

open '/Applications/Visual Studio Code.app' --args --disable-gpu
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

@KonaBlend's solution worked for me as well.
However, is there a way to persist this command when opening from a dock / desktop icon?
A similar issue was stated here: https://github.com/Microsoft/vscode/issues/15211#issuecomment-330570631
Aliasing did not work for me. El Capitan 10.11.15, NVIDIA GeForce GT 120 512 MB
Thank you!

don,
in the meantime the following is what I do for Finder/Dock launches; but it needs to be done every upgrade.

edit: Visual Studio Code - Insiders.app/Contents/Info.plist

diff --git a/Info.plist b/Info.plist
index 9e1a5a1..9496af8 100644
--- a/Info.plist
+++ b/Info.plist
@@ -7,7 +7,7 @@
     <key>CFBundleDisplayName</key>
     <string>Code - Insiders</string>
     <key>CFBundleExecutable</key>
-    <string>Electron</string>
+    <string>Electron.disable_gpu</string>
     <key>CFBundleIconFile</key>
     <string>Code - Insiders.icns</string>
     <key>CFBundleIdentifier</key>

create new script: Visual Studio Code - Insiders.app/Contents/MacOS/Electron.disable_gpu
(note: important, we drop extension to determine executable name so Electron must be basename and extension can be anything you want but has to match Info.plist entry)

#!/bin/zsh

## executable is script without extension; exec with custom args
exec $0:r --disable-gpu

set executable permissions on script

chmod 755 'Visual Studio Code - Insiders.app/Contents/MacOS/Electron.disable_gpu'

launch and examine Electron command-line

pgrep -fl MacOS/Electron


conflicts with ViaFabricPlus

[04:34:59] [Render thread/WARN]:
 @Redirect conflict. Skipping viafabricplus.mixins.json:base.MixinConnectScreen_1 from mod viafabricplus->@Redirect::mapSocketAddress(Ljava/util/Optional;)Ljava/lang/Object; with priority 1000, already redirected by modflared.mixins.json:ConnectScreenMixin from mod modflared->@Redirect::connect(Ljava/util/Optional;)Ljava/lang/Object; with priority 1000
hope this issue can be fixed. 🙏

oops seems like i just mentioned random guy

Which version of the mod are you using?

hi, im using 1.0.0 with minecraft version 1.20.1
it works fine with new version of 1.1.0 beta3, guess ill just switch to 1.20.4 instead

Since 1.20.4 is available, I will not update 1.20.1.

If you have problems with 1.20.4, please feel free to contact me.


Error building on Linux

Describe the bug
==== Building PsyCross (debug_x86) ====
==== Building REDRIVER2 (debug_x86) ====
DebugOverlay.cpp
In file included from ../DebugOverlay.cpp:1:0:
../Game/driver2.h:4:19: fatal error: types.h: No such file or directory
compilation terminated.
REDRIVER2.make:313: recipe for target 'obj/x86/Debug/REDRIVER2/DebugOverlay.o' failed
make[1]: *** [obj/x86/Debug/REDRIVER2/DebugOverlay.o] Error 1
Makefile:41: recipe for target 'REDRIVER2' failed
make: *** [REDRIVER2] Error 2

To Reproduce
Steps to reproduce the behavior:
Install all dependencies , add Linux version of premake5 , run gen_make2.sh , go to directory project_gmake2_linux and run make
Expected behavior
Building project

Pull request fixing the build would be helpful. It does build for Ubuntu tho (through Appveyor)

It looks there is no types.h header in Linux (probably that Ubuntu got a symlink or workaround?).
I am not sure what types.h specifically is in that context but it may be the equivalent of <sys/types.h> on Linux or other unix-like environments.

it's due to lack of -i386 development package for libc6, however i am myself struggling with working around this.
Having x64 Debian 12-ish by standard i i have everything x86_64, including gcc.

now i am stuck - no package provides 'libcd.h'
lis6502@e595:~/git/REDRIVER2/src_rebuild$ gcc -m32 DebugOverlay.cpp -I/usr/include/linux/
In file included from DebugOverlay.cpp:1:
Game/driver2.h:5:10: fatal error: libcd.h: No such file or directory
    5 | #include <libcd.h>
      |          ^~~~~~~~~
compilation terminated.

Please check how it's getting built with AppVeyor, also it's better to checkout develop-SoapyMan as linux compatibility been improved here


CBMC harness for aws_hash_table_find(), and related fixups.

CBMC harness for aws_hash_table_find

Update hash-table to avoid null dereference on equals and hash functions.

Add pre and post conditions to relevant hash-table functions

Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Spurious failure due to bug in https://github.com/diffblue/cbmc/pull/4444

Should be fixed by https://github.com/diffblue/cbmc/pull/4656

Verification payloads resent as the CBMC fix has been merged.


Add instructions in README on how to edit demo

Not sure if it has just been a long week but I'm struggling to get the demo iOS project to update rebuild a framework of my changes :grimacing:
It looks like it is looking for the Few.framework in a build/Debug-iphoneos directory but that does not exist. I have tried building/running/archiving the framework targets and no frameworks get put there. Is there something I am missing?

Are you trying to rebuild the framework itself, or one of the demo projects?

I was working on adding a fun new feature to Few.Element and I wanted to test it in the demo project. The demo project looks like it relies on a built Few.framework in the build/Debug-iphoneos directory. It didn't seem like my change to Few.Element was being reflect in the demo app but I may have been an idiot :grimacing: I will double check to make sure I was actually doing things right.

Ah, sorry about that! It looks like it was trying to link to the Carthage-built version before. It should be fine now.

Yesssssss, thank you! Expect more PRs from me :blush:


a question for skeleton denoising

Now, I generate 3D pose coordinates  using 3D pose estimation algorithm for a video, but this coordinate have some jitter,  can your algorithm use for skeleton denosing?

Our existing auto-encoder is applied to joint rotations, so it is not straightforward.
Theoretically speaking you can use our skeleton-aware operators with 3D joints positions, but it requires some (minor) modifications of the existing code and re-training of the network to convert noisy 3D position to clean ones (so you should also have clean data for training).


[Bug] Tablist isn't getting cleared upon death.

Describe the bug
The Tablist isn't getting cleared after someone dies, the corpse should be getting removed from the tablist. But instead, it is showing up.
Version
4.0.0
To Reproduce
Give instructions on how we can reproduce the issue.
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots

Additional context
N/A

Update: If you have too many corpses some will make it into chests and you will lose them. Although I thought this was intended behavior, we need to spawn the corpses back.


VM Revert Reasons not returned

Revert reasons are not being passed back by ganache-core anymore
Expected Behavior
Old error.message (v6.4.1)
Returned error: VM Exception while processing transaction: revert ${solidityRevertReason}
Current Behavior
error.message being passed back (v6.7.0-beta.0)
error: execution error: revert
Possible Solution

Steps to Reproduce (for bugs)
Send a transaction that reverts with a solidity revert string.
Your Environment
"truffle": "5.0.34",
"ganache-cli": "6.7.0-beta.0",

This seems to be a problem in estimate gas. Investigating further

Previously, estimate gas was incorrectly returning estimates for failing transactions instead of failing (like other clients do). We'll look into providing the revert reason string to the error message in estimate gas. /cc @nicholasjpaterno

Is there a plan to release #502 any soon?
cc @davidmurdoch


Upgrade<EMAIL_ADDRESS>and<EMAIL_ADDRESS>

Upgrade legend-engine to 4.47.3 and legend-sdlc to 0.163.2

/easycla


Can't instantiate abstract class _Interceptor with abstract method await

Hello, I've a project deps on Quart and Hypercorn , when I build the latest image yesterday, I found the quart cannot work.
After a hard check, I found it was caused by taskgroup's upgrading. It works well with taskgroup==0.0.0a4 but broken with taskgroup==0.1.1(also in 0.0.0a5). I thought it was because the new version taskgroup has some conflicts with my own task management. I'm trying to find it out, but this repository has much too little information, could you add a detailed README or other documentation for taskgroup ？Thank you.

I've provided a bit more info in https://github.com/graingert/taskgroup/pull/21
could you describe more about your issue? Does it fail in 3.11 or 3.12 in the same ways?

could you also try using anycorn instead of hypercorn and see if the issue persists?

Thank you so much for replying and for the PR. I just locked the version to 0.0.0a4  to temporarily solve this issue, but I haven't found the deep cause yet. I'll reply to this issue as soon as I work it out.

I also encountered the same issue on python 3.9.x with following error
Traceback (most recent call last):
  File "..\lib\multiprocessing\process.py", line 315, in _bootstrap
    self.run()
  File "..\lib\multiprocessing\process.py", line 108, in run
    self._target(*self._args, **self._kwargs)
  File "..\lib\site-packages\hypercorn\asyncio\run.py", line 196, in asyncio_worker
    _run(
  File "..\lib\site-packages\hypercorn\asyncio\run.py", line 234, in _run
    runner.run(main(shutdown_trigger=shutdown_trigger))
  File "..\lib\site-packages\taskgroup\runners.py", line 127, in run
    task = _task_factory(self._loop, coro, context=context)
  File "..\lib\site-packages\taskgroup\tasks.py", line 89, in task_factory
    return Task(coro, loop=loop, **kwargs)
  File "..\lib\site-packages\taskgroup\tasks.py", line 63, in __init__
    coro = _Interceptor(coro, context)
TypeError: Can't instantiate abstract class _Interceptor with abstract method __await__
..\lib\multiprocessing\process.py:331: RuntimeWarning: coroutine 'worker_serve' was never awaited
  traceback.print_exc()
RuntimeWarning: Enable tracemalloc to get the object allocation traceback

Happening in both anycorn and hypercorn while running with more than 1 workers.
Python 3.11 works fine
I saw #23, hopefully that fixes it.

ah ok looks like an easy fix (that wasn't fixed in #23), I'll get on it.

@M0N0Atomic can you check if this fixes it?
https://github.com/graingert/taskgroup/pull/25

Yes that fixed it.

@M0N0Atomic thanks for the report, released in 0.2.1!


Add zh_CN PhoneNumber TestCase & TollFreePhoneNumber API & E164PhoneN…

done #2053
If you reject me, please tell me how to do it in rightway, cause I'm a rookie, THX!

Codecov Report

Merging #2054 into master will decrease coverage by 0.31%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##             master    #2054      +/-   ##
============================================
- Coverage     56.56%   56.25%   -0.32%
- Complexity     2068     2070       +2
============================================
  Files           306      306
  Lines          4849     4855       +6
============================================
- Hits           2743     2731      -12
- Misses         2106     2124      +18

Impacted Files
Coverage Δ
Complexity Δ

src/Faker/Provider/zh_CN/PhoneNumber.php
100.00% <100.00%> (ø)
3.00 <2.00> (+2.00)

src/Faker/Provider/de_DE/Person.php
0.00% <0.00%> (-100.00%)
1.00% <0.00%> (ø%)

src/Faker/Provider/id_ID/Company.php
50.00% <0.00%> (-50.00%)
2.00% <0.00%> (ø%)

src/Faker/Provider/en_AU/PhoneNumber.php
0.00% <0.00%> (-50.00%)
2.00% <0.00%> (ø%)

src/Faker/Provider/fa_IR/Address.php
73.33% <0.00%> (-26.67%)
7.00% <0.00%> (ø%)

src/Faker/Provider/es_ES/Person.php
75.00% <0.00%> (-25.00%)
3.00% <0.00%> (ø%)

src/Faker/Provider/en_IN/Address.php
50.00% <0.00%> (-25.00%)
8.00% <0.00%> (ø%)

src/Faker/Provider/nb_NO/Address.php
50.00% <0.00%> (-25.00%)
4.00% <0.00%> (ø%)

src/Faker/Provider/ja_JP/Address.php
76.19% <0.00%> (-23.81%)
8.00% <0.00%> (ø%)

src/Faker/Provider/en_UG/Person.php
60.00% <0.00%> (-20.00%)
5.00% <0.00%> (ø%)

... and 23 more

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 5337ce5...e79d010. Read the comment docs.

I can't understand why test coverage is down , the file I commit allready coverage 100% o(╥﹏╥)o


test: add codecov to stat unit test coverage

Signed-off-by: letty<EMAIL_ADDRESS>
1.Describe what this PR did
Add Codecov to stat unit test coverage.
2.Does this pull request fix one issue?

3.Describe how you did it
First, add coverage statistic in each go test in Makefile, then add an entry in .travis.yml.
Codecov has be well integrated with travisCI.
4.Describe how to verify it
5.Special notes for reviews

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@727c83e). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #447   +/-   ##
=========================================
  Coverage          ?   20.28%
=========================================
  Files             ?       34
  Lines             ?     1592
  Branches          ?        0
=========================================
  Hits              ?      323
  Misses            ?     1234
  Partials          ?       35

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 727c83e...281780a. Read the comment docs.

Thanks greatly for your work. This PR makes us get the basic situation of unit test coverage. 👍

LGTM


CVE-2021-3281 accidentally bumping Django 3.0 to 3.1 when fix exists in 3.0 series

This dependabot alert is faultily upgrading Django 3.0 to 3.1 rather than 3.0.12
https://github.com/advisories/GHSA-fvgf-6h6h-3322

@adamchainz thanks for reporting, looks like the advisory is incorrect in this case. I've raised the issue with the advisory team. This won't fix any existing dependabot PRs but will prevent this from happening on newly discovered advisories for django.

Thanks. Is there any public forum for communicating on advisories?

I think github support is the best route for now but would be neat if you could just report an advisory from the page directly.

Okay. If there were a route for reviewing/discussing them, the Django security team may also be interested in checking them off.

This advisory has been updated to include the correct ranges. New PRs sent out will reflect the current range.

the Django security team may also be interested in checking them off.

This is much appreciated. I think we're still working on a better curation flow that involves maintainers, and we'd love to work with you when we're closer to that!


Additional listener should inherit the configured authentication method

This PR implement the enhancement proposed in #7531 by setting the authentication_method for the additional listeners to the authentication method configured when sasl is enabled.
Fixes #7531

Thanks again, @lburgazzoli! This is now merged in main branch and will be part of the next release.

@eddumelendez thx for fixing up my mistakes