Configuring accelerators with optional dependencies from docs fails

Hi !
I was testing using uv with PyTorch and ran into this issue.
I copy-pasted the pyproject.toml from the docs:
[project]
name = "project"
version = "0.1.0"
requires-python = ">=3.12.0"
dependencies = []

[project.optional-dependencies]
cpu = [
  "torch>=2.5.1",
  "torchvision>=0.20.1",
]
cu124 = [
  "torch>=2.5.1",
  "torchvision>=0.20.1",
]

[tool.uv]
conflicts = [
  [
    { extra = "cpu" },
    { extra = "cu124" },
  ],
]

[tool.uv.sources]
torch = [
  { index = "pytorch-cpu", extra = "cpu", marker = "platform_system != 'Darwin'" },
  { index = "pytorch-cu124", extra = "cu124" },
]
torchvision = [
  { index = "pytorch-cpu", extra = "cpu", marker = "platform_system != 'Darwin'" },
  { index = "pytorch-cu124", extra = "cu124" },
]

[[tool.uv.index]]
name = "pytorch-cpu"
url = "https://download.pytorch.org/whl/cpu"
explicit = true

[[tool.uv.index]]
name = "pytorch-cu124"
url = "https://download.pytorch.org/whl/cu124"
explicit = true

uv sync and the verbose output
$ uv sync --extra cu124 -v
DEBUG uv 0.5.4 (c62c83c37 2024-11-20)
DEBUG Found project root: `C:\Users\jeanp\code\tmp`
DEBUG No workspace root found, using project root
DEBUG Using Python request `>=3.12.0` from `requires-python` metadata
DEBUG The virtual environment's Python version satisfies `>=3.12.0`
DEBUG Using request timeout of 30s
DEBUG Found static `pyproject.toml` for: project @ file:///C:/Users/jeanp/code/tmp
DEBUG No workspace root found, using project root
DEBUG Solving with installed Python version: 3.13.0
DEBUG Solving with target Python version: >=3.12.0
DEBUG Pre-fork all marker environments took 0.000s
DEBUG Splitting resolution on root==0a0.dev0 over project into 3 resolution with separate markers
DEBUG Adding direct dependency: project*
DEBUG Adding direct dependency: project*
DEBUG Adding direct dependency: project[cpu]*
DEBUG Adding direct dependency: project*
DEBUG Adding direct dependency: project[cu124]*
DEBUG Searching for a compatible version of project @ file:///C:/Users/jeanp/code/tmp (*)
DEBUG Adding transitive dependency for project==0.1.0: project==0.1.0
DEBUG Adding transitive dependency for project==0.1.0: project[cu124]==0.1.0
DEBUG Searching for a compatible version of project @ file:///C:/Users/jeanp/code/tmp (==0.1.0)
DEBUG Searching for a compatible version of project @ file:///C:/Users/jeanp/code/tmp (==0.1.0)
DEBUG Adding transitive dependency for project==0.1.0: torch>=2.5.1
DEBUG Adding transitive dependency for project==0.1.0: torchvision>=0.20.1
DEBUG No cache entry for: https://download.pytorch.org/whl/cu124/torch/
DEBUG No cache entry for: https://download.pytorch.org/whl/cu124/torchvision/
DEBUG Searching for a compatible version of torch (>=2.5.1)
DEBUG Selecting: torch==2.5.1+cu124 [compatible] (torch-2.5.1+cu124-cp312-cp312-linux_x86_64.whl)
DEBUG Found stale response for: https://download.pytorch.org/whl/cu124/torch-2.5.1%2Bcu124-cp312-cp312-linux_x86_64.whl#sha256=bf6484bfe5bc4f92a4a1a1bf553041505e19a911f717065330eb061afe0e14d7
DEBUG Sending revalidation request for: https://download.pytorch.org/whl/cu124/torch-2.5.1%2Bcu124-cp312-cp312-linux_x86_64.whl#sha256=bf6484bfe5bc4f92a4a1a1bf553041505e19a911f717065330eb061afe0e14d7
DEBUG Found not-modified response for: https://download.pytorch.org/whl/cu124/torch-2.5.1%2Bcu124-cp312-cp312-linux_x86_64.whl#sha256=bf6484bfe5bc4f92a4a1a1bf553041505e19a911f717065330eb061afe0e14d7
DEBUG Adding transitive dependency for torch==2.5.1+cu124: filelock*
DEBUG Adding transitive dependency for torch==2.5.1+cu124: fsspec*
DEBUG Adding transitive dependency for torch==2.5.1+cu124: jinja2*
DEBUG Adding transitive dependency for torch==2.5.1+cu124: networkx*
DEBUG Adding transitive dependency for torch==2.5.1+cu124: nvidia-cublas-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'}>=<IP_ADDRESS>, <<IP_ADDRESS>+
DEBUG Adding transitive dependency for torch==2.5.1+cu124: nvidia-cuda-cupti-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'}>=12.4.127, <12.4.127+
DEBUG Adding transitive dependency for torch==2.5.1+cu124: nvidia-cuda-nvrtc-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'}>=12.4.127, <12.4.127+
DEBUG Adding transitive dependency for torch==2.5.1+cu124: nvidia-cuda-runtime-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'}>=12.4.127, <12.4.127+
DEBUG Adding transitive dependency for torch==2.5.1+cu124: nvidia-cudnn-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'}>=<IP_ADDRESS>, <<IP_ADDRESS>+
DEBUG Adding transitive dependency for torch==2.5.1+cu124: nvidia-cufft-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'}>=<IP_ADDRESS>, <<IP_ADDRESS>+
DEBUG Adding transitive dependency for torch==2.5.1+cu124: nvidia-curand-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'}>=<IP_ADDRESS>, <<IP_ADDRESS>+
DEBUG Adding transitive dependency for torch==2.5.1+cu124: nvidia-cusolver-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'}>=<IP_ADDRESS>, <<IP_ADDRESS>+
DEBUG Adding transitive dependency for torch==2.5.1+cu124: nvidia-cusparse-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'}>=<IP_ADDRESS>, <<IP_ADDRESS>+
DEBUG Adding transitive dependency for torch==2.5.1+cu124: nvidia-nccl-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'}>=2.21.5, <2.21.5+
DEBUG Adding transitive dependency for torch==2.5.1+cu124: nvidia-nvjitlink-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'}>=12.4.127, <12.4.127+
DEBUG Adding transitive dependency for torch==2.5.1+cu124: nvidia-nvtx-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'}>=12.4.127, <12.4.127+
DEBUG Adding transitive dependency for torch==2.5.1+cu124: setuptools{python_full_version >= '3.12'}*
DEBUG Adding transitive dependency for torch==2.5.1+cu124: sympy{python_full_version >= '3.9'}>=1.13.1, <1.13.1+
DEBUG Adding transitive dependency for torch==2.5.1+cu124: triton{python_full_version < '3.13' and platform_machine == 'x86_64' and platform_system == 'Linux'}>=3.1.0, <3.1.0+
DEBUG Adding transitive dependency for torch==2.5.1+cu124: typing-extensions>=4.8.0
DEBUG Searching for a compatible version of torchvision (>=0.20.1)
DEBUG Found fresh response for: https://pypi.org/simple/filelock/
DEBUG Selecting: torchvision==0.20.1+cu124 [compatible] (torchvision-0.20.1+cu124-cp312-cp312-linux_x86_64.whl)
DEBUG Found fresh response for: https://pypi.org/simple/jinja2/
DEBUG Found fresh response for: https://pypi.org/simple/nvidia-cublas-cu12/
DEBUG Found fresh response for: https://pypi.org/simple/networkx/
DEBUG Found fresh response for: https://pypi.org/simple/fsspec/
DEBUG Found fresh response for: https://pypi.org/simple/nvidia-cuda-cupti-cu12/
DEBUG Found fresh response for: https://pypi.org/simple/nvidia-cudnn-cu12/
DEBUG Found fresh response for: https://pypi.org/simple/nvidia-cufft-cu12/
DEBUG Found fresh response for: https://pypi.org/simple/nvidia-cuda-nvrtc-cu12/
DEBUG Found fresh response for: https://pypi.org/simple/nvidia-cuda-runtime-cu12/
DEBUG Found fresh response for: https://pypi.org/simple/nvidia-cusolver-cu12/
DEBUG Found fresh response for: https://pypi.org/simple/nvidia-nccl-cu12/
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/b9/f8/feced7779d755758a52d1f6635d990b8d98dc0a29fa568bbe0625f18fdf3/filelock-3.16.1-py3-none-any.whl.metadata
DEBUG Found fresh response for: https://pypi.org/simple/nvidia-nvjitlink-cu12/
DEBUG Found fresh response for: https://pypi.org/simple/nvidia-curand-cu12/
DEBUG Found fresh response for: https://pypi.org/simple/sympy/
DEBUG Found fresh response for: https://pypi.org/simple/triton/
DEBUG Found fresh response for: https://pypi.org/simple/typing-extensions/
DEBUG Found fresh response for: https://pypi.org/simple/nvidia-nvtx-cu12/
DEBUG Found fresh response for: https://pypi.org/simple/setuptools/
DEBUG Found fresh response for: https://pypi.org/simple/nvidia-cusparse-cu12/
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/31/80/3a54838c3fb461f6fec263ebf3a3a41771bd05190238de3486aae8540c36/jinja2-3.1.4-py3-none-any.whl.metadata
DEBUG Found stale response for: https://download.pytorch.org/whl/cu124/torchvision-0.20.1%2Bcu124-cp312-cp312-linux_x86_64.whl#sha256=d1053ec5054549e7dac2613b151bffe323f3c924939d296df4d7d34925aaf3ad
DEBUG Sending revalidation request for: https://download.pytorch.org/whl/cu124/torchvision-0.20.1%2Bcu124-cp312-cp312-linux_x86_64.whl#sha256=d1053ec5054549e7dac2613b151bffe323f3c924939d296df4d7d34925aaf3ad
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/b9/54/dd730b32ea14ea797530a4479b2ed46a6fb250f682a9cfb997e968bf0261/networkx-3.4.2-py3-none-any.whl.metadata
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/c6/b2/454d6e7f0158951d8a78c2e1eb4f69ae81beb8dca5fee9809c6c99e9d0d0/fsspec-2024.10.0-py3-none-any.whl.metadata
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/26/9f/ad63fc0248c5379346306f8668cda6e2e2e9c95e01216d2b8ffd9ff037d0/typing_extensions-4.12.2-py3-none-any.whl.metadata
DEBUG Found not-modified response for: https://download.pytorch.org/whl/cu124/torchvision-0.20.1%2Bcu124-cp312-cp312-linux_x86_64.whl#sha256=d1053ec5054549e7dac2613b151bffe323f3c924939d296df4d7d34925aaf3ad
DEBUG Adding transitive dependency for torchvision==0.20.1+cu124: numpy*
DEBUG Adding transitive dependency for torchvision==0.20.1+cu124: pillow>=5.3.0, <8.3.dev0 | >=8.4.dev0
DEBUG Adding transitive dependency for torchvision==0.20.1+cu124: torch>=2.5.1, <2.5.1+
DEBUG Searching for a compatible version of filelock (*)
DEBUG Selecting: filelock==3.16.1 [compatible] (filelock-3.16.1-py3-none-any.whl)
DEBUG Found fresh response for: https://pypi.org/simple/pillow/
DEBUG Searching for a compatible version of fsspec (*)
DEBUG Selecting: fsspec==2024.10.0 [compatible] (fsspec-2024.10.0-py3-none-any.whl)
DEBUG Searching for a compatible version of jinja2 (*)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/1c/a3/26e606ff0b2daaf120543e537311fa3ae2eb6bf061490e4fea51771540be/pillow-11.0.0-cp312-cp312-macosx_10_13_x86_64.whl.metadata
DEBUG Selecting: jinja2==3.1.4 [compatible] (jinja2-3.1.4-py3-none-any.whl)
DEBUG Found fresh response for: https://pypi.org/simple/numpy/
DEBUG Adding transitive dependency for jinja2==3.1.4: markupsafe>=2.0
DEBUG Searching for a compatible version of networkx (*)
DEBUG Selecting: networkx==3.4.2 [compatible] (networkx-3.4.2-py3-none-any.whl)
DEBUG Searching for a compatible version of nvidia-cublas-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'} (>=<IP_ADDRESS>, <<IP_ADDRESS>+)
DEBUG Selecting: nvidia-cublas-cu12==<IP_ADDRESS> [compatible] (nvidia_cublas_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Adding transitive dependency for nvidia-cublas-cu12==<IP_ADDRESS>: nvidia-cublas-cu12==<IP_ADDRESS>
DEBUG Adding transitive dependency for nvidia-cublas-cu12==<IP_ADDRESS>: nvidia-cublas-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'}==<IP_ADDRESS>
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/8a/f0/385eb9970309643cbca4fc6eebc8bb16e560de129c91258dfaa18498da8b/numpy-2.1.3-cp312-cp312-macosx_10_13_x86_64.whl.metadata
DEBUG Searching for a compatible version of nvidia-cublas-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'} (==<IP_ADDRESS>)
DEBUG Selecting: nvidia-cublas-cu12==<IP_ADDRESS> [compatible] (nvidia_cublas_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/7f/7f/7fbae15a3982dc9595e49ce0f19332423b260045d0a6afe93cdbe2f1f624/nvidia_cublas_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl.metadata
DEBUG Found fresh response for: https://pypi.org/simple/markupsafe/
DEBUG Searching for a compatible version of nvidia-cublas-cu12 (==<IP_ADDRESS>)
DEBUG Selecting: nvidia-cublas-cu12==<IP_ADDRESS> [compatible] (nvidia_cublas_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Searching for a compatible version of nvidia-cuda-cupti-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'} (>=12.4.127, <12.4.127+)
DEBUG Selecting: nvidia-cuda-cupti-cu12==12.4.127 [compatible] (nvidia_cuda_cupti_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Adding transitive dependency for nvidia-cuda-cupti-cu12==12.4.127: nvidia-cuda-cupti-cu12==12.4.127
DEBUG Adding transitive dependency for nvidia-cuda-cupti-cu12==12.4.127: nvidia-cuda-cupti-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'}==12.4.127
DEBUG Searching for a compatible version of nvidia-cuda-cupti-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'} (==12.4.127)
DEBUG Selecting: nvidia-cuda-cupti-cu12==12.4.127 [compatible] (nvidia_cuda_cupti_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/22/09/d1f21434c97fc42f09d290cbb6350d44eb12f09cc62c9476effdb33a18aa/MarkupSafe-3.0.2-cp312-cp312-macosx_10_13_universal2.whl.metadata
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/93/b5/9fb3d00386d3361b03874246190dfec7b206fd74e6e287b26a8fcb359d95/nvidia_cuda_cupti_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl.metadata
DEBUG Searching for a compatible version of nvidia-cuda-cupti-cu12 (==12.4.127)
DEBUG Selecting: nvidia-cuda-cupti-cu12==12.4.127 [compatible] (nvidia_cuda_cupti_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Searching for a compatible version of nvidia-cuda-nvrtc-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'} (>=12.4.127, <12.4.127+)
DEBUG Selecting: nvidia-cuda-nvrtc-cu12==12.4.127 [compatible] (nvidia_cuda_nvrtc_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Adding transitive dependency for nvidia-cuda-nvrtc-cu12==12.4.127: nvidia-cuda-nvrtc-cu12==12.4.127
DEBUG Adding transitive dependency for nvidia-cuda-nvrtc-cu12==12.4.127: nvidia-cuda-nvrtc-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'}==12.4.127
DEBUG Searching for a compatible version of nvidia-cuda-nvrtc-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'} (==12.4.127)
DEBUG Selecting: nvidia-cuda-nvrtc-cu12==12.4.127 [compatible] (nvidia_cuda_nvrtc_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/77/aa/083b01c427e963ad0b314040565ea396f914349914c298556484f799e61b/nvidia_cuda_nvrtc_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl.metadata
DEBUG Searching for a compatible version of nvidia-cuda-nvrtc-cu12 (==12.4.127)
DEBUG Selecting: nvidia-cuda-nvrtc-cu12==12.4.127 [compatible] (nvidia_cuda_nvrtc_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Searching for a compatible version of nvidia-cuda-runtime-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'} (>=12.4.127, <12.4.127+)
DEBUG Selecting: nvidia-cuda-runtime-cu12==12.4.127 [compatible] (nvidia_cuda_runtime_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Adding transitive dependency for nvidia-cuda-runtime-cu12==12.4.127: nvidia-cuda-runtime-cu12==12.4.127
DEBUG Adding transitive dependency for nvidia-cuda-runtime-cu12==12.4.127: nvidia-cuda-runtime-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'}==12.4.127
DEBUG Searching for a compatible version of nvidia-cuda-runtime-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'} (==12.4.127)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/a1/aa/b656d755f474e2084971e9a297def515938d56b466ab39624012070cb773/nvidia_cuda_runtime_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl.metadata
DEBUG Selecting: nvidia-cuda-runtime-cu12==12.4.127 [compatible] (nvidia_cuda_runtime_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Searching for a compatible version of nvidia-cuda-runtime-cu12 (==12.4.127)
DEBUG Selecting: nvidia-cuda-runtime-cu12==12.4.127 [compatible] (nvidia_cuda_runtime_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Searching for a compatible version of nvidia-cudnn-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'} (>=<IP_ADDRESS>, <<IP_ADDRESS>+)
DEBUG Selecting: nvidia-cudnn-cu12==<IP_ADDRESS> [compatible] (nvidia_cudnn_cu12-<IP_ADDRESS>-py3-none-manylinux2014_x86_64.whl)
DEBUG Adding transitive dependency for nvidia-cudnn-cu12==<IP_ADDRESS>: nvidia-cudnn-cu12==<IP_ADDRESS>
DEBUG Adding transitive dependency for nvidia-cudnn-cu12==<IP_ADDRESS>: nvidia-cudnn-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'}==<IP_ADDRESS>
DEBUG Searching for a compatible version of nvidia-cudnn-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'} (==<IP_ADDRESS>)
DEBUG Selecting: nvidia-cudnn-cu12==<IP_ADDRESS> [compatible] (nvidia_cudnn_cu12-<IP_ADDRESS>-py3-none-manylinux2014_x86_64.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/9f/fd/713452cd72343f682b1c7b9321e23829f00b842ceaedcda96e742ea0b0b3/nvidia_cudnn_cu12-<IP_ADDRESS>-py3-none-manylinux2014_x86_64.whl.metadata
DEBUG Adding transitive dependency for nvidia-cudnn-cu12==<IP_ADDRESS>: nvidia-cublas-cu12*
DEBUG Searching for a compatible version of nvidia-cudnn-cu12 (==<IP_ADDRESS>)
DEBUG Selecting: nvidia-cudnn-cu12==<IP_ADDRESS> [compatible] (nvidia_cudnn_cu12-<IP_ADDRESS>-py3-none-manylinux2014_x86_64.whl)
DEBUG Adding transitive dependency for nvidia-cudnn-cu12==<IP_ADDRESS>: nvidia-cublas-cu12*
DEBUG Searching for a compatible version of nvidia-cufft-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'} (>=<IP_ADDRESS>, <<IP_ADDRESS>+)
DEBUG Selecting: nvidia-cufft-cu12==<IP_ADDRESS> [compatible] (nvidia_cufft_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Adding transitive dependency for nvidia-cufft-cu12==<IP_ADDRESS>: nvidia-cufft-cu12==<IP_ADDRESS>
DEBUG Adding transitive dependency for nvidia-cufft-cu12==<IP_ADDRESS>: nvidia-cufft-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'}==<IP_ADDRESS>
DEBUG Searching for a compatible version of nvidia-cufft-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'} (==<IP_ADDRESS>)
DEBUG Selecting: nvidia-cufft-cu12==<IP_ADDRESS> [compatible] (nvidia_cufft_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/7a/8a/0e728f749baca3fbeffad762738276e5df60851958be7783af121a7221e7/nvidia_cufft_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl.metadata
DEBUG Adding transitive dependency for nvidia-cufft-cu12==<IP_ADDRESS>: nvidia-nvjitlink-cu12*
DEBUG Searching for a compatible version of nvidia-cufft-cu12 (==<IP_ADDRESS>)
DEBUG Selecting: nvidia-cufft-cu12==<IP_ADDRESS> [compatible] (nvidia_cufft_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Adding transitive dependency for nvidia-cufft-cu12==<IP_ADDRESS>: nvidia-nvjitlink-cu12*
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/9d/d7/c5383e47c7e9bf1c99d5bd2a8c935af2b6d705ad831a7ec5c97db4d82f4f/nvidia_nvjitlink_cu12-12.6.85-py3-none-manylinux2010_x86_64.manylinux_2_12_x86_64.whl.metadata
DEBUG Searching for a compatible version of nvidia-curand-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'} (>=<IP_ADDRESS>, <<IP_ADDRESS>+)
DEBUG Selecting: nvidia-curand-cu12==<IP_ADDRESS> [compatible] (nvidia_curand_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Adding transitive dependency for nvidia-curand-cu12==<IP_ADDRESS>: nvidia-curand-cu12==<IP_ADDRESS>
DEBUG Adding transitive dependency for nvidia-curand-cu12==<IP_ADDRESS>: nvidia-curand-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'}==<IP_ADDRESS>
DEBUG Searching for a compatible version of nvidia-curand-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'} (==<IP_ADDRESS>)
DEBUG Selecting: nvidia-curand-cu12==<IP_ADDRESS> [compatible] (nvidia_curand_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/80/9c/a79180e4d70995fdf030c6946991d0171555c6edf95c265c6b2bf7011112/nvidia_curand_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl.metadata
DEBUG Searching for a compatible version of nvidia-curand-cu12 (==<IP_ADDRESS>)
DEBUG Selecting: nvidia-curand-cu12==<IP_ADDRESS> [compatible] (nvidia_curand_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Searching for a compatible version of nvidia-cusolver-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'} (>=<IP_ADDRESS>, <<IP_ADDRESS>+)
DEBUG Selecting: nvidia-cusolver-cu12==<IP_ADDRESS> [compatible] (nvidia_cusolver_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Adding transitive dependency for nvidia-cusolver-cu12==<IP_ADDRESS>: nvidia-cusolver-cu12==<IP_ADDRESS>
DEBUG Adding transitive dependency for nvidia-cusolver-cu12==<IP_ADDRESS>: nvidia-cusolver-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'}==<IP_ADDRESS>
DEBUG Searching for a compatible version of nvidia-cusolver-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'} (==<IP_ADDRESS>)
DEBUG Selecting: nvidia-cusolver-cu12==<IP_ADDRESS> [compatible] (nvidia_cusolver_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/46/6b/a5c33cf16af09166845345275c34ad2190944bcc6026797a39f8e0a282e0/nvidia_cusolver_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl.metadata
DEBUG Adding transitive dependency for nvidia-cusolver-cu12==<IP_ADDRESS>: nvidia-cublas-cu12*
DEBUG Adding transitive dependency for nvidia-cusolver-cu12==<IP_ADDRESS>: nvidia-cusparse-cu12*
DEBUG Adding transitive dependency for nvidia-cusolver-cu12==<IP_ADDRESS>: nvidia-nvjitlink-cu12*
DEBUG Searching for a compatible version of nvidia-cusolver-cu12 (==<IP_ADDRESS>)
DEBUG Selecting: nvidia-cusolver-cu12==<IP_ADDRESS> [compatible] (nvidia_cusolver_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Adding transitive dependency for nvidia-cusolver-cu12==<IP_ADDRESS>: nvidia-cublas-cu12*
DEBUG Adding transitive dependency for nvidia-cusolver-cu12==<IP_ADDRESS>: nvidia-cusparse-cu12*
DEBUG Adding transitive dependency for nvidia-cusolver-cu12==<IP_ADDRESS>: nvidia-nvjitlink-cu12*
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/eb/eb/6681efd0aa7df96b4f8067b3ce7246833dd36830bb4cec8896182773db7d/nvidia_cusparse_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.manylinux_2_17_aarch64.whl.metadata
DEBUG Searching for a compatible version of nvidia-cusparse-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'} (>=<IP_ADDRESS>, <<IP_ADDRESS>+)
DEBUG Selecting: nvidia-cusparse-cu12==<IP_ADDRESS> [compatible] (nvidia_cusparse_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Adding transitive dependency for nvidia-cusparse-cu12==<IP_ADDRESS>: nvidia-cusparse-cu12==<IP_ADDRESS>
DEBUG Adding transitive dependency for nvidia-cusparse-cu12==<IP_ADDRESS>: nvidia-cusparse-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'}==<IP_ADDRESS>
DEBUG Searching for a compatible version of nvidia-cusparse-cu12 (==<IP_ADDRESS>)
DEBUG Selecting: nvidia-cusparse-cu12==<IP_ADDRESS> [compatible] (nvidia_cusparse_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/96/a9/c0d2f83a53d40a4a41be14cea6a0bf9e668ffcf8b004bd65633f433050c0/nvidia_cusparse_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl.metadata
DEBUG Adding transitive dependency for nvidia-cusparse-cu12==<IP_ADDRESS>: nvidia-nvjitlink-cu12*
DEBUG Searching for a compatible version of nvidia-cusparse-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'} (==<IP_ADDRESS>)
DEBUG Selecting: nvidia-cusparse-cu12==<IP_ADDRESS> [compatible] (nvidia_cusparse_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Adding transitive dependency for nvidia-cusparse-cu12==<IP_ADDRESS>: nvidia-nvjitlink-cu12*
DEBUG Searching for a compatible version of nvidia-nccl-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'} (>=2.21.5, <2.21.5+)
DEBUG Selecting: nvidia-nccl-cu12==2.21.5 [compatible] (nvidia_nccl_cu12-2.21.5-py3-none-manylinux2014_x86_64.whl)
DEBUG Adding transitive dependency for nvidia-nccl-cu12==2.21.5: nvidia-nccl-cu12==2.21.5
DEBUG Adding transitive dependency for nvidia-nccl-cu12==2.21.5: nvidia-nccl-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'}==2.21.5
DEBUG Searching for a compatible version of nvidia-nccl-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'} (==2.21.5)
DEBUG Selecting: nvidia-nccl-cu12==2.21.5 [compatible] (nvidia_nccl_cu12-2.21.5-py3-none-manylinux2014_x86_64.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/df/99/12cd266d6233f47d00daf3a72739872bdc10267d0383508b0b9c84a18bb6/nvidia_nccl_cu12-2.21.5-py3-none-manylinux2014_x86_64.whl.metadata
DEBUG Searching for a compatible version of nvidia-nccl-cu12 (==2.21.5)
DEBUG Selecting: nvidia-nccl-cu12==2.21.5 [compatible] (nvidia_nccl_cu12-2.21.5-py3-none-manylinux2014_x86_64.whl)
DEBUG Searching for a compatible version of nvidia-nvjitlink-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'} (>=12.4.127, <12.4.127+)
DEBUG Selecting: nvidia-nvjitlink-cu12==12.4.127 [compatible] (nvidia_nvjitlink_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Adding transitive dependency for nvidia-nvjitlink-cu12==12.4.127: nvidia-nvjitlink-cu12==12.4.127
DEBUG Adding transitive dependency for nvidia-nvjitlink-cu12==12.4.127: nvidia-nvjitlink-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'}==12.4.127
DEBUG Searching for a compatible version of nvidia-nvjitlink-cu12 (==12.4.127)
DEBUG Selecting: nvidia-nvjitlink-cu12==12.4.127 [compatible] (nvidia_nvjitlink_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/02/45/239d52c05074898a80a900f49b1615d81c07fceadd5ad6c4f86a987c0bc4/nvidia_nvjitlink_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl.metadata
DEBUG Searching for a compatible version of nvidia-nvjitlink-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'} (==12.4.127)
DEBUG Selecting: nvidia-nvjitlink-cu12==12.4.127 [compatible] (nvidia_nvjitlink_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Searching for a compatible version of nvidia-nvtx-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'} (>=12.4.127, <12.4.127+)
DEBUG Selecting: nvidia-nvtx-cu12==12.4.127 [compatible] (nvidia_nvtx_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Adding transitive dependency for nvidia-nvtx-cu12==12.4.127: nvidia-nvtx-cu12==12.4.127
DEBUG Adding transitive dependency for nvidia-nvtx-cu12==12.4.127: nvidia-nvtx-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'}==12.4.127
DEBUG Searching for a compatible version of nvidia-nvtx-cu12{platform_machine == 'x86_64' and platform_system == 'Linux'} (==12.4.127)
DEBUG Selecting: nvidia-nvtx-cu12==12.4.127 [compatible] (nvidia_nvtx_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/06/39/471f581edbb7804b39e8063d92fc8305bdc7a80ae5c07dbe6ea5c50d14a5/nvidia_nvtx_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl.metadata
DEBUG Searching for a compatible version of nvidia-nvtx-cu12 (==12.4.127)
DEBUG Selecting: nvidia-nvtx-cu12==12.4.127 [compatible] (nvidia_nvtx_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Searching for a compatible version of setuptools{python_full_version >= '3.12'} (*)
DEBUG Selecting: setuptools==75.6.0 [compatible] (setuptools-75.6.0-py3-none-any.whl)
DEBUG Adding transitive dependency for setuptools==75.6.0: setuptools==75.6.0
DEBUG Adding transitive dependency for setuptools==75.6.0: setuptools{python_full_version >= '3.12'}==75.6.0
DEBUG Searching for a compatible version of setuptools{python_full_version >= '3.12'} (==75.6.0)
DEBUG Selecting: setuptools==75.6.0 [compatible] (setuptools-75.6.0-py3-none-any.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/55/21/47d163f615df1d30c094f6c8bbb353619274edccf0327b185cc2493c2c33/setuptools-75.6.0-py3-none-any.whl.metadata
DEBUG Searching for a compatible version of setuptools (==75.6.0)
DEBUG Selecting: setuptools==75.6.0 [compatible] (setuptools-75.6.0-py3-none-any.whl)
DEBUG Searching for a compatible version of sympy{python_full_version >= '3.9'} (>=1.13.1, <1.13.1+)
DEBUG Selecting: sympy==1.13.1 [compatible] (sympy-1.13.1-py3-none-any.whl)
DEBUG Adding transitive dependency for sympy==1.13.1: sympy==1.13.1
DEBUG Adding transitive dependency for sympy==1.13.1: sympy{python_full_version >= '3.9'}==1.13.1
DEBUG Searching for a compatible version of sympy{python_full_version >= '3.9'} (==1.13.1)
DEBUG Selecting: sympy==1.13.1 [compatible] (sympy-1.13.1-py3-none-any.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/b2/fe/81695a1aa331a842b582453b605175f419fe8540355886031328089d840a/sympy-1.13.1-py3-none-any.whl.metadata
DEBUG Adding transitive dependency for sympy==1.13.1: mpmath>=1.1.0, <1.4
DEBUG Searching for a compatible version of sympy (==1.13.1)
DEBUG Selecting: sympy==1.13.1 [compatible] (sympy-1.13.1-py3-none-any.whl)
DEBUG Found fresh response for: https://pypi.org/simple/mpmath/
DEBUG Adding transitive dependency for sympy==1.13.1: mpmath>=1.1.0, <1.4
DEBUG Searching for a compatible version of triton{python_full_version < '3.13' and platform_machine == 'x86_64' and platform_system == 'Linux'} (>=3.1.0, <3.1.0+)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/43/e3/7d92a15f894aa0c9c4b49b8ee9ac9850d6e63b03c9c32c0367a13ae62209/mpmath-1.3.0-py3-none-any.whl.metadata
DEBUG Selecting: triton==3.1.0 [compatible] (triton-3.1.0-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl)
DEBUG Adding transitive dependency for triton==3.1.0: triton==3.1.0
DEBUG Adding transitive dependency for triton==3.1.0: triton{python_full_version < '3.13' and platform_machine == 'x86_64' and platform_system == 'Linux'}==3.1.0
DEBUG Searching for a compatible version of triton{python_full_version < '3.13' and platform_machine == 'x86_64' and platform_system == 'Linux'} (==3.1.0)
DEBUG Selecting: triton==3.1.0 [compatible] (triton-3.1.0-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/78/eb/65f5ba83c2a123f6498a3097746607e5b2f16add29e36765305e4ac7fdd8/triton-3.1.0-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata
DEBUG Adding transitive dependency for triton==3.1.0: filelock*
DEBUG Searching for a compatible version of triton (==3.1.0)
DEBUG Selecting: triton==3.1.0 [compatible] (triton-3.1.0-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl)
DEBUG Adding transitive dependency for triton==3.1.0: filelock*
DEBUG Searching for a compatible version of typing-extensions (>=4.8.0)
DEBUG Selecting: typing-extensions==4.12.2 [compatible] (typing_extensions-4.12.2-py3-none-any.whl)
DEBUG Searching for a compatible version of numpy (*)
DEBUG Selecting: numpy==2.1.3 [compatible] (numpy-2.1.3-cp312-cp312-macosx_10_13_x86_64.whl)
DEBUG Searching for a compatible version of pillow (>=5.3.0, <8.3.dev0 | >=8.4.dev0)
DEBUG Selecting: pillow==11.0.0 [compatible] (pillow-11.0.0-cp312-cp312-macosx_10_13_x86_64.whl)
DEBUG Searching for a compatible version of markupsafe (>=2.0)
DEBUG Selecting: markupsafe==3.0.2 [compatible] (MarkupSafe-3.0.2-cp312-cp312-macosx_10_13_universal2.whl)
DEBUG Searching for a compatible version of mpmath (>=1.1.0, <1.4)
DEBUG Selecting: mpmath==1.3.0 [compatible] (mpmath-1.3.0-py3-none-any.whl)
DEBUG Tried 27 versions: filelock 1, fsspec 1, jinja2 1, markupsafe 1, mpmath 1, networkx 1, numpy 1, nvidia-cublas-cu12 1, nvidia-cuda-cupti-cu12 1, nvidia-cuda-nvrtc-cu12 1, nvidia-cuda-runtime-cu12 1, nvidia-cudnn-cu12 1, nvidia-cufft-cu12 1, nvidia-curand-cu12 1, nvidia-cusolver-cu12 1, nvidia-cusparse-cu12 1, nvidia-nccl-cu12 1, nvidia-nvjitlink-cu12 1, nvidia-nvtx-cu12 1, pillow 1, project 1, setuptools 1, sympy 1, torch 1, torchvision 1, triton 1, typing-extensions 1
DEBUG all marker environments resolution took 1.178s
DEBUG Searching for a compatible version of project @ file:///C:/Users/jeanp/code/tmp (*)
DEBUG Adding transitive dependency for project==0.1.0: project==0.1.0
DEBUG Adding transitive dependency for project==0.1.0: project[cpu]==0.1.0
DEBUG Searching for a compatible version of project @ file:///C:/Users/jeanp/code/tmp (==0.1.0)
DEBUG Searching for a compatible version of project @ file:///C:/Users/jeanp/code/tmp (==0.1.0)
DEBUG Pre-fork all marker environments took 0.003s
DEBUG Splitting resolution on project[cpu]==0.1.0 over torch, torchvision into 2 resolution with separate markers
DEBUG Adding transitive dependency for project==0.1.0: torch{platform_system == 'Darwin'}>=2.5.1
DEBUG Adding transitive dependency for project==0.1.0: torchvision{platform_system == 'Darwin'}>=0.20.1
DEBUG Adding transitive dependency for project==0.1.0: torch{platform_system != 'Darwin'}>=2.5.1
DEBUG Adding transitive dependency for project==0.1.0: torchvision{platform_system != 'Darwin'}>=0.20.1
DEBUG Solving split (platform_system != 'Darwin') (requires-python: RequiresPython { specifiers: VersionSpecifiers([VersionSpecifier { operator: GreaterThanEqual, version: "3.12.0" }]), range: RequiresPythonRange(LowerBound(Included("3.12.0")), UpperBound(Unbounded)) })
DEBUG No cache entry for: https://download.pytorch.org/whl/cpu/torch/
DEBUG No cache entry for: https://download.pytorch.org/whl/cpu/torchvision/
DEBUG Found fresh response for: https://pypi.org/simple/torchvision/
DEBUG Found fresh response for: https://pypi.org/simple/torch/
DEBUG Searching for a compatible version of torch{platform_system != 'Darwin'} (>=2.5.1)
DEBUG Selecting: torch==2.5.1+cpu [compatible] (torch-2.5.1+cpu-cp312-cp312-linux_x86_64.whl)
DEBUG Adding transitive dependency for torch==2.5.1+cpu: torch==2.5.1+cpu
DEBUG Adding transitive dependency for torch==2.5.1+cpu: torch{platform_system != 'Darwin'}==2.5.1+cpu
DEBUG Searching for a compatible version of torch{platform_system != 'Darwin'} (==2.5.1+cpu)
DEBUG Selecting: torch==2.5.1+cpu [compatible] (torch-2.5.1+cpu-cp312-cp312-linux_x86_64.whl)
DEBUG Found stale response for: https://download.pytorch.org/whl/cpu/torch-2.5.1%2Bcpu-cp312-cp312-linux_x86_64.whl#sha256=4856f9d6925121d13c2df07aa7580b767f449dfe71ae5acde9c27535d5da4840
DEBUG Sending revalidation request for: https://download.pytorch.org/whl/cpu/torch-2.5.1%2Bcpu-cp312-cp312-linux_x86_64.whl#sha256=4856f9d6925121d13c2df07aa7580b767f449dfe71ae5acde9c27535d5da4840
DEBUG Found not-modified response for: https://download.pytorch.org/whl/cpu/torch-2.5.1%2Bcpu-cp312-cp312-linux_x86_64.whl#sha256=4856f9d6925121d13c2df07aa7580b767f449dfe71ae5acde9c27535d5da4840
DEBUG Adding transitive dependency for torch==2.5.1+cpu: filelock*
DEBUG Adding transitive dependency for torch==2.5.1+cpu: fsspec*
DEBUG Adding transitive dependency for torch==2.5.1+cpu: jinja2*
DEBUG Adding transitive dependency for torch==2.5.1+cpu: networkx*
DEBUG Adding transitive dependency for torch==2.5.1+cpu: setuptools{python_full_version >= '3.12'}*
DEBUG Adding transitive dependency for torch==2.5.1+cpu: sympy{python_full_version >= '3.9'}>=1.13.1, <1.13.1+
DEBUG Adding transitive dependency for torch==2.5.1+cpu: typing-extensions>=4.8.0
DEBUG Searching for a compatible version of torch (==2.5.1+cpu)
DEBUG Selecting: torch==2.5.1+cpu [compatible] (torch-2.5.1+cpu-cp312-cp312-linux_x86_64.whl)
DEBUG Adding transitive dependency for torch==2.5.1+cpu: filelock*
DEBUG Adding transitive dependency for torch==2.5.1+cpu: fsspec*
DEBUG Adding transitive dependency for torch==2.5.1+cpu: jinja2*
DEBUG Adding transitive dependency for torch==2.5.1+cpu: networkx*
DEBUG Adding transitive dependency for torch==2.5.1+cpu: setuptools{python_full_version >= '3.12'}*
DEBUG Adding transitive dependency for torch==2.5.1+cpu: sympy{python_full_version >= '3.9'}>=1.13.1, <1.13.1+
DEBUG Adding transitive dependency for torch==2.5.1+cpu: typing-extensions>=4.8.0
DEBUG Searching for a compatible version of torchvision{platform_system != 'Darwin'} (>=0.20.1)
DEBUG Selecting: torchvision==0.20.1+cpu [compatible] (torchvision-0.20.1+cpu-cp312-cp312-linux_x86_64.whl)
DEBUG Adding transitive dependency for torchvision==0.20.1+cpu: torchvision==0.20.1+cpu
DEBUG Adding transitive dependency for torchvision==0.20.1+cpu: torchvision{platform_system != 'Darwin'}==0.20.1+cpu
DEBUG Searching for a compatible version of torchvision{platform_system != 'Darwin'} (==0.20.1+cpu)
DEBUG Selecting: torchvision==0.20.1+cpu [compatible] (torchvision-0.20.1+cpu-cp312-cp312-linux_x86_64.whl)
DEBUG Found stale response for: https://download.pytorch.org/whl/cpu/torchvision-0.20.1%2Bcpu-cp312-cp312-linux_x86_64.whl#sha256=5f46c7ac7f00a065cb40bfb1e1bfc4ba16a35f5d46b3fe70cca6b3cea7f822f7
DEBUG Sending revalidation request for: https://download.pytorch.org/whl/cpu/torchvision-0.20.1%2Bcpu-cp312-cp312-linux_x86_64.whl#sha256=5f46c7ac7f00a065cb40bfb1e1bfc4ba16a35f5d46b3fe70cca6b3cea7f822f7
DEBUG Found not-modified response for: https://download.pytorch.org/whl/cpu/torchvision-0.20.1%2Bcpu-cp312-cp312-linux_x86_64.whl#sha256=5f46c7ac7f00a065cb40bfb1e1bfc4ba16a35f5d46b3fe70cca6b3cea7f822f7
DEBUG Adding transitive dependency for torchvision==0.20.1+cpu: numpy*
DEBUG Adding transitive dependency for torchvision==0.20.1+cpu: pillow>=5.3.0, <8.3.dev0 | >=8.4.dev0
DEBUG Adding transitive dependency for torchvision==0.20.1+cpu: torch>=2.5.1, <2.5.1+
DEBUG Searching for a compatible version of torchvision (==0.20.1+cpu)
DEBUG Selecting: torchvision==0.20.1+cpu [compatible] (torchvision-0.20.1+cpu-cp312-cp312-linux_x86_64.whl)
DEBUG Adding transitive dependency for torchvision==0.20.1+cpu: numpy*
DEBUG Adding transitive dependency for torchvision==0.20.1+cpu: pillow>=5.3.0, <8.3.dev0 | >=8.4.dev0
DEBUG Adding transitive dependency for torchvision==0.20.1+cpu: torch>=2.5.1, <2.5.1+
DEBUG Searching for a compatible version of filelock (*)
DEBUG Selecting: filelock==3.16.1 [preference] (filelock-3.16.1-py3-none-any.whl)
DEBUG Searching for a compatible version of fsspec (*)
DEBUG Selecting: fsspec==2024.10.0 [preference] (fsspec-2024.10.0-py3-none-any.whl)
DEBUG Searching for a compatible version of jinja2 (*)
DEBUG Selecting: jinja2==3.1.4 [preference] (jinja2-3.1.4-py3-none-any.whl)
DEBUG Adding transitive dependency for jinja2==3.1.4: markupsafe>=2.0
DEBUG Searching for a compatible version of networkx (*)
DEBUG Selecting: networkx==3.4.2 [preference] (networkx-3.4.2-py3-none-any.whl)
DEBUG Searching for a compatible version of setuptools{python_full_version >= '3.12'} (*)
DEBUG Selecting: setuptools==75.6.0 [preference] (setuptools-75.6.0-py3-none-any.whl)
DEBUG Adding transitive dependency for setuptools==75.6.0: setuptools==75.6.0
DEBUG Adding transitive dependency for setuptools==75.6.0: setuptools{python_full_version >= '3.12'}==75.6.0
DEBUG Searching for a compatible version of setuptools{python_full_version >= '3.12'} (==75.6.0)
DEBUG Selecting: setuptools==75.6.0 [preference] (setuptools-75.6.0-py3-none-any.whl)
DEBUG Searching for a compatible version of setuptools (==75.6.0)
DEBUG Selecting: setuptools==75.6.0 [preference] (setuptools-75.6.0-py3-none-any.whl)
DEBUG Searching for a compatible version of sympy{python_full_version >= '3.9'} (>=1.13.1, <1.13.1+)
DEBUG Selecting: sympy==1.13.1 [preference] (sympy-1.13.1-py3-none-any.whl)
DEBUG Adding transitive dependency for sympy==1.13.1: sympy==1.13.1
DEBUG Adding transitive dependency for sympy==1.13.1: sympy{python_full_version >= '3.9'}==1.13.1
DEBUG Searching for a compatible version of sympy{python_full_version >= '3.9'} (==1.13.1)
DEBUG Selecting: sympy==1.13.1 [preference] (sympy-1.13.1-py3-none-any.whl)
DEBUG Adding transitive dependency for sympy==1.13.1: mpmath>=1.1.0, <1.4
DEBUG Searching for a compatible version of sympy (==1.13.1)
DEBUG Selecting: sympy==1.13.1 [preference] (sympy-1.13.1-py3-none-any.whl)
DEBUG Adding transitive dependency for sympy==1.13.1: mpmath>=1.1.0, <1.4
DEBUG Searching for a compatible version of typing-extensions (>=4.8.0)
DEBUG Selecting: typing-extensions==4.12.2 [preference] (typing_extensions-4.12.2-py3-none-any.whl)
DEBUG Searching for a compatible version of numpy (*)
DEBUG Selecting: numpy==2.1.3 [preference] (numpy-2.1.3-cp312-cp312-macosx_10_13_x86_64.whl)
DEBUG Searching for a compatible version of pillow (>=5.3.0, <8.3.dev0 | >=8.4.dev0)
DEBUG Selecting: pillow==11.0.0 [preference] (pillow-11.0.0-cp312-cp312-macosx_10_13_x86_64.whl)
DEBUG Searching for a compatible version of markupsafe (>=2.0)
DEBUG Selecting: markupsafe==3.0.2 [preference] (MarkupSafe-3.0.2-cp312-cp312-macosx_10_13_universal2.whl)
DEBUG Searching for a compatible version of mpmath (>=1.1.0, <1.4)
DEBUG Selecting: mpmath==1.3.0 [preference] (mpmath-1.3.0-py3-none-any.whl)
DEBUG Tried 41 versions: filelock 2, fsspec 2, jinja2 2, markupsafe 2, mpmath 2, networkx 2, numpy 2, pillow 2, project 2, setuptools 2, sympy 2, torch 2, torchvision 2, typing-extensions 2, nvidia-cublas-cu12 1, nvidia-cuda-cupti-cu12 1, nvidia-cuda-nvrtc-cu12 1, nvidia-cuda-runtime-cu12 1, nvidia-cudnn-cu12 1, nvidia-cufft-cu12 1, nvidia-curand-cu12 1, nvidia-cusolver-cu12 1, nvidia-cusparse-cu12 1, nvidia-nccl-cu12 1, nvidia-nvjitlink-cu12 1, nvidia-nvtx-cu12 1, triton 1
DEBUG split `platform_system != 'Darwin'` resolution took 0.935s
DEBUG Solving split (platform_system == 'Darwin') (requires-python: RequiresPython { specifiers: VersionSpecifiers([VersionSpecifier { operator: GreaterThanEqual, version: "3.12.0" }]), range: RequiresPythonRange(LowerBound(Included("3.12.0")), UpperBound(Unbounded)) })
DEBUG Searching for a compatible version of torch{platform_system == 'Darwin'} (>=2.5.1)
DEBUG Selecting: torch==2.5.1 [compatible] (torch-2.5.1-cp312-cp312-manylinux1_x86_64.whl)
DEBUG Adding transitive dependency for torch==2.5.1: torch==2.5.1
DEBUG Adding transitive dependency for torch==2.5.1: torch{platform_system == 'Darwin'}==2.5.1
DEBUG Searching for a compatible version of torch{platform_system == 'Darwin'} (==2.5.1)
DEBUG Selecting: torch==2.5.1 [compatible] (torch-2.5.1-cp312-cp312-manylinux1_x86_64.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/8b/5c/36c114d120bfe10f9323ed35061bc5878cc74f3f594003854b0ea298942f/torch-2.5.1-cp312-cp312-manylinux1_x86_64.whl.metadata
DEBUG Adding transitive dependency for torch==2.5.1: filelock*
DEBUG Adding transitive dependency for torch==2.5.1: fsspec*
DEBUG Adding transitive dependency for torch==2.5.1: jinja2*
DEBUG Adding transitive dependency for torch==2.5.1: networkx*
DEBUG Adding transitive dependency for torch==2.5.1: setuptools{python_full_version >= '3.12'}*
DEBUG Adding transitive dependency for torch==2.5.1: sympy{python_full_version >= '3.9'}>=1.13.1, <1.13.1+
DEBUG Adding transitive dependency for torch==2.5.1: typing-extensions>=4.8.0
DEBUG Searching for a compatible version of torch (==2.5.1)
DEBUG Selecting: torch==2.5.1 [compatible] (torch-2.5.1-cp312-cp312-manylinux1_x86_64.whl)
DEBUG Adding transitive dependency for torch==2.5.1: filelock*
DEBUG Adding transitive dependency for torch==2.5.1: fsspec*
DEBUG Adding transitive dependency for torch==2.5.1: jinja2*
DEBUG Adding transitive dependency for torch==2.5.1: networkx*
DEBUG Adding transitive dependency for torch==2.5.1: setuptools{python_full_version >= '3.12'}*
DEBUG Adding transitive dependency for torch==2.5.1: sympy{python_full_version >= '3.9'}>=1.13.1, <1.13.1+
DEBUG Adding transitive dependency for torch==2.5.1: typing-extensions>=4.8.0
DEBUG Searching for a compatible version of torchvision{platform_system == 'Darwin'} (>=0.20.1)
DEBUG Selecting: torchvision==0.20.1 [compatible] (torchvision-0.20.1-cp312-cp312-macosx_11_0_arm64.whl)
DEBUG Adding transitive dependency for torchvision==0.20.1: torchvision==0.20.1
DEBUG Adding transitive dependency for torchvision==0.20.1: torchvision{platform_system == 'Darwin'}==0.20.1
DEBUG Searching for a compatible version of torchvision{platform_system == 'Darwin'} (==0.20.1)
DEBUG Selecting: torchvision==0.20.1 [compatible] (torchvision-0.20.1-cp312-cp312-macosx_11_0_arm64.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/c5/eb/4ba19616378f2bc085999432fded2b7dfdbdccc6dd0fc293203452508100/torchvision-0.20.1-cp312-cp312-macosx_11_0_arm64.whl.metadata
DEBUG Adding transitive dependency for torchvision==0.20.1: numpy*
DEBUG Adding transitive dependency for torchvision==0.20.1: pillow>=5.3.0, <8.3.dev0 | >=8.4.dev0
DEBUG Adding transitive dependency for torchvision==0.20.1: torch>=2.5.1, <2.5.1+
DEBUG Searching for a compatible version of torchvision (==0.20.1)
DEBUG Selecting: torchvision==0.20.1 [compatible] (torchvision-0.20.1-cp312-cp312-macosx_11_0_arm64.whl)
DEBUG Adding transitive dependency for torchvision==0.20.1: numpy*
DEBUG Adding transitive dependency for torchvision==0.20.1: pillow>=5.3.0, <8.3.dev0 | >=8.4.dev0
DEBUG Adding transitive dependency for torchvision==0.20.1: torch>=2.5.1, <2.5.1+
DEBUG Searching for a compatible version of filelock (*)
DEBUG Selecting: filelock==3.16.1 [preference] (filelock-3.16.1-py3-none-any.whl)
DEBUG Searching for a compatible version of fsspec (*)
DEBUG Selecting: fsspec==2024.10.0 [preference] (fsspec-2024.10.0-py3-none-any.whl)
DEBUG Searching for a compatible version of jinja2 (*)
DEBUG Selecting: jinja2==3.1.4 [preference] (jinja2-3.1.4-py3-none-any.whl)
DEBUG Adding transitive dependency for jinja2==3.1.4: markupsafe>=2.0
DEBUG Searching for a compatible version of networkx (*)
DEBUG Selecting: networkx==3.4.2 [preference] (networkx-3.4.2-py3-none-any.whl)
DEBUG Searching for a compatible version of setuptools{python_full_version >= '3.12'} (*)
DEBUG Selecting: setuptools==75.6.0 [preference] (setuptools-75.6.0-py3-none-any.whl)
DEBUG Adding transitive dependency for setuptools==75.6.0: setuptools==75.6.0
DEBUG Adding transitive dependency for setuptools==75.6.0: setuptools{python_full_version >= '3.12'}==75.6.0
DEBUG Searching for a compatible version of setuptools{python_full_version >= '3.12'} (==75.6.0)
DEBUG Selecting: setuptools==75.6.0 [preference] (setuptools-75.6.0-py3-none-any.whl)
DEBUG Searching for a compatible version of setuptools (==75.6.0)
DEBUG Selecting: setuptools==75.6.0 [preference] (setuptools-75.6.0-py3-none-any.whl)
DEBUG Searching for a compatible version of sympy{python_full_version >= '3.9'} (>=1.13.1, <1.13.1+)
DEBUG Selecting: sympy==1.13.1 [preference] (sympy-1.13.1-py3-none-any.whl)
DEBUG Adding transitive dependency for sympy==1.13.1: sympy==1.13.1
DEBUG Adding transitive dependency for sympy==1.13.1: sympy{python_full_version >= '3.9'}==1.13.1
DEBUG Searching for a compatible version of sympy{python_full_version >= '3.9'} (==1.13.1)
DEBUG Selecting: sympy==1.13.1 [preference] (sympy-1.13.1-py3-none-any.whl)
DEBUG Adding transitive dependency for sympy==1.13.1: mpmath>=1.1.0, <1.4
DEBUG Searching for a compatible version of sympy (==1.13.1)
DEBUG Selecting: sympy==1.13.1 [preference] (sympy-1.13.1-py3-none-any.whl)
DEBUG Adding transitive dependency for sympy==1.13.1: mpmath>=1.1.0, <1.4
DEBUG Searching for a compatible version of typing-extensions (>=4.8.0)
DEBUG Selecting: typing-extensions==4.12.2 [preference] (typing_extensions-4.12.2-py3-none-any.whl)
DEBUG Searching for a compatible version of numpy (*)
DEBUG Selecting: numpy==2.1.3 [preference] (numpy-2.1.3-cp312-cp312-macosx_10_13_x86_64.whl)
DEBUG Searching for a compatible version of pillow (>=5.3.0, <8.3.dev0 | >=8.4.dev0)
DEBUG Selecting: pillow==11.0.0 [preference] (pillow-11.0.0-cp312-cp312-macosx_10_13_x86_64.whl)
DEBUG Searching for a compatible version of markupsafe (>=2.0)
DEBUG Selecting: markupsafe==3.0.2 [preference] (MarkupSafe-3.0.2-cp312-cp312-macosx_10_13_universal2.whl)
DEBUG Searching for a compatible version of mpmath (>=1.1.0, <1.4)
DEBUG Selecting: mpmath==1.3.0 [preference] (mpmath-1.3.0-py3-none-any.whl)
DEBUG Tried 54 versions: filelock 3, fsspec 3, jinja2 3, markupsafe 3, mpmath 3, networkx 3, numpy 3, pillow 3, setuptools 3, sympy 3, torch 3, torchvision 3, typing-extensions 3, project 2, nvidia-cublas-cu12 1, nvidia-cuda-cupti-cu12 1, nvidia-cuda-nvrtc-cu12 1, nvidia-cuda-runtime-cu12 1, nvidia-cudnn-cu12 1, nvidia-cufft-cu12 1, nvidia-curand-cu12 1, nvidia-cusolver-cu12 1, nvidia-cusparse-cu12 1, nvidia-nccl-cu12 1, nvidia-nvjitlink-cu12 1, nvidia-nvtx-cu12 1, triton 1
DEBUG split `platform_system == 'Darwin'` resolution took 0.035s
DEBUG Searching for a compatible version of project @ file:///C:/Users/jeanp/code/tmp (*)
DEBUG Tried 55 versions: filelock 3, fsspec 3, jinja2 3, markupsafe 3, mpmath 3, networkx 3, numpy 3, pillow 3, project 3, setuptools 3, sympy 3, torch 3, torchvision 3, typing-extensions 3, nvidia-cublas-cu12 1, nvidia-cuda-cupti-cu12 1, nvidia-cuda-nvrtc-cu12 1, nvidia-cuda-runtime-cu12 1, nvidia-cudnn-cu12 1, nvidia-cufft-cu12 1, nvidia-curand-cu12 1, nvidia-cusolver-cu12 1, nvidia-cusparse-cu12 1, nvidia-nccl-cu12 1, nvidia-nvjitlink-cu12 1, nvidia-nvtx-cu12 1, triton 1
DEBUG all marker environments resolution took 0.002s
INFO Solved your requirements for 4 environments
DEBUG Distinct solution for split (platform_system != 'Darwin') with 15 packages
DEBUG Distinct solution for split (platform_system == 'Darwin') with 15 packages
Resolved 31 packages in 2.17s
error: Distribution `torch==2.5.1+cu124 @ registry+https://download.pytorch.org/whl/cu124` can't be installed because it doesn't have a source distribution or wheel for the current platform

I'm on Windows with CUDA and an amd CPU
The wheel uv is looking for exists: https://download.pytorch.org/whl/cu124/torch-2.5.1%2Bcu124-cp312-cp312-win_amd64.whl#sha256=3c3f705fb125edbd77f9579fa11a138c56af8968a10fc95834cdd9fdf4f1f1a6

You're trying to install on Python 3.13: Solving with installed Python version: 3.13.0

Oh thanks! with ``--python 3.12` it now works.

Sweet!


Handle invalid or missing config files more gracefully

Coverage increased (+0.3%) to 46.455% when pulling 5b14900cf5e00be802cbd6a0838e76188f34c626 on invalid-config into 8d7c2b54d024ad4988d9b50dc1fbb6b5a37235c5 on master.


Feat 188: Use spikeinterface for LSB correction

fixes #188
The LSB correction has been implemented in SpikeInterface>=0.97.1
See implementation here: https://github.com/SpikeInterface/spikeinterface/blob/master/spikeinterface/preprocessing/correct_lsb.py
@jtyoung84 should I remove the disable_tqdm everywhere, since it's not used anymore?

I saw it. Will fix tests tomorrow morning!


PLATUI-1173: generate trait with instance of plugin provided accessibility linters

this is a draft to support https://github.com/hmrc/scalatest-accessibility-linter/pull/4

I was over complicating this with the generated code! Now we have default linters in the trait https://github.com/hmrc/scalatest-accessibility-linter/blob/PLATUI-1173_known-issue-filters/src/main/scala/uk/gov/hmrc/scalatestaccessibilitylinter/AccessibilityMatchers.scala#L28 it's possible that no changes are needed to sbt-accessibility-linter beside a version bump of scalatest-accessibility-linter


Support for calculated columns

MySQL table schema can have generated columns which are not understood by CH.
Let us fix this in 2 steps :

the DDL translation should convert generated columns into ALIAS columns

clickhouse_loader.py
sink-connector schema java converter

if the calculated expression is not understood by CH, it should be overridable (see schema overrides)

Example column :
`concat_key` varchar(1000) COLLATE latin1_general_cs GENERATED ALWAYS AS (concat(one, '-', two) VIRTUAL,

https://dev.mysql.com/doc/refman/8.0/en/create-table-generated-columns.html
MySQL / Postgres should be supported.

python utilities now support generated columns see https://github.com/Altinity/clickhouse-sink-connector/pull/426/files

The issue was verified by the Altinity QA team and marked as qa-verified.
Build used for testing: altinityinfra/clickhouse-sink-connector:443-678d8ae2567c2c1d89f5430fa57ede619d6ea851-lt
Automated TestFlows tests were added to the develop branch:
https://github.com/Altinity/clickhouse-sink-connector/blob/develop/sink-connector-lightweight/tests/integration/tests/calculated_columns.py
Requirements for the ClickHouse Sink Connector Lightweight were updated.


Update to serde 0.9

The majority of this PR is replacing the use of ObjectBuilder and ArrayBuilder with the new json!({}) macro. The only place where this got a little tricky was in view.rs; the code around building updates heavily relied on passing around builder objects. I've now mostly modified it to just build Vec<Value>s in place, which hopefully has the side-benefit of making the code a bit easier to follow. I'm not sure if there were any subtle optimizations that I might've undone, but in general I was careful to keep things as streamlined as possible.
closes #182

Thanks!

💯


Slide crashing upon opening

iPhone SE 10.2.1
Slide 1.0.1 (15)
https://streamable.com/digpe

I'm on an iOS 10 emulator and can't reproduce this, have you tried reinstalling?

Should be fixed in build 16


save results data to result folder

right now, i like how dsAnalyze does separate posthoc folders 'analyzedData' and 'postSimPlots'. during sim plots already go to 'plots'. lets put data from analysis_functions into 'results' or 'analysis' instead of 'data' with all the actual simulation data files.

@jsherfey will this mess up the gui at all?

@jsherfey bump? i don't want to start this if it'll screw up the gui

okay im switching it to 'results' and 'postSimResults'


error during make

I have this error when installing:
make
make[1]: Entering directory '/home/davide/code/coq/FormalML'
COQDEP VFILES
COQC coq/lib_utils/LibUtilsCoqLibAdd.v
COQC coq/lib_utils/LibUtilsLift.v
COQC coq/lib_utils/LibUtilsListAdd.v
COQC coq/lib_utils/LibUtilsStringAdd.v
COQC coq/lib_utils/LibUtilsAssoc.v
File "./coq/lib_utils/LibUtilsAssoc.v", line 1502, characters 14-40:
Error: No such bound variable dec0 (possible names are: dec, l, a and b).

make[2]: *** [Makefile.coq:793: coq/lib_utils/LibUtilsAssoc.vo] Error 1
make[1]: *** [Makefile.coq:409: all] Error 2
make[1]: Leaving directory '/home/davide/code/coq/FormalML'
make: *** [Makefile:9: coq] Error 2

I kind of solved replacing dec0 with dec (but I'm not sure is ok)
but now I get this error
make
make[1]: Entering directory '/home/davide/code/coq/FormalML'
COQDEP VFILES
COQC coq/lib_utils/LibUtilsAssoc.v
COQC coq/lib_utils/LibUtilsSortingAdd.v
COQC coq/lib_utils/LibUtilsSublist.v
COQC coq/lib_utils/LibUtilsBag.v
COQC coq/lib_utils/LibUtilsCompat.v
COQC coq/lib_utils/LibUtilsBindings.v
COQC coq/lib_utils/LibUtilsBindingsNat.v
COQC coq/lib_utils/LibUtilsClosure.v
COQC coq/lib_utils/LibUtilsDigits.v
File "./coq/lib_utils/LibUtilsDigits.v", line 154, characters 80-81:
Error: The reference H was not found in the current environment.

make[2]: *** [Makefile.coq:793: coq/lib_utils/LibUtilsDigits.vo] Error 1
make[1]: *** [Makefile.coq:409: all] Error 2
make[1]: Leaving directory '/home/davide/code/coq/FormalML'
make: *** [Makefile:9: coq] Error 2

I managed to fix second error by installing it in a new switch with opam switch create nnsopt 4.07.0, maybe some version of the default switch is not compatible, in any case I still have the first error and other similar that I fixed as said before (removing the 0 from the name of the variable) but now I have this:
File "./coq/utils/RealAdd.v", line 5318, characters 19-29:
Error: The reference Qreals.Q2R was not found in the current environment.

Hi!  What version of Coq are you using?  We currently use 8.12.2.  Something in the 8.12 line should work, but we have not tested with newer versions, and it is very likely that things break due to changes in hypothesis naming and such.
If this is a problem for your intended use case (e.g. if you are thinking of using it as part of another development), please tell us, and what version of Coq you need to use.

thanks, I managed to compile it by downgrading coq, do you know how I can import the library in coqide? (I'm new with coq)

Inspired by your post, I just updated our repo to support coq 8.16.1 (it should still support 8.12.2 as well, so no need to change back)

If you use opam, running something like opam install . in the FormalML directory should work

thank you very much, with the new updated version I have this error:
Compiled library FormalML.ProbTheory.Event (in file /home/davide/code/coq/FormalML/coq/ProbTheory/Event.vo) makes inconsistent assumptions over library Coq.Init.Ltac
do you know how to fix this?

@davidenitti if you are using proof general + emacs, there is a flag coq-compile-before-toggle which you can set to recompile all the files that you import using Require. Within CoqIde there is also a Compile > Make option that I see which might help, although I haven't tried it myself.

thanks it works now, but I still have to specify the library in the call: coqide -R FormalML/coq FormalML, not sure if there is a way to automatically find the library. (I installed with opam install with the new code).
if also there is any paper that explain the library would be great.
thank you very much for the support!

I would recommend putting that in a _CoqProject file (which lives in your top level directory): you can create such a file with -R FormalML/coq FormalML as the only line in it.  CoqIDE, as well as other coq tools should read that file and add the argument for you

Section 3 of https://arxiv.org/pdf/2202.05959.pdf gives highlights of some of the development, although we have added more since then (also, it is of course simplified).


Use ".?" operator

By swapping characters you can greatly simplify parsers job and eliminate every potential conflict.
It allows expansion to arrays and function even if final syntax would  be weird :)

I don’t understand what is exactly the issue you are trying to resolve.

By swapping characters you can greatly simplify parsers job and eliminate every potential conflict.

The current syntax uses a simple lookahead in the lexical grammar to avoid conflict. By swapping the characters, you just avoid that lookahead. I’m not sure that that alone "greatly simplifies parsers job". Or am I missing something?

It allows expansion to arrays and function even if final syntax would be weird :)

The current proposal has already a working-although-weird expansion to arrays and functions.

parser should work hard so we would work less harder.
coffee script solves this issue by eliminating ternary operator completely, and using if then else instead.
you can't have this here, and imho, it will take a good fight for this proposal to pass.

I’m with @nhz-io in thinking the syntax is weird. IMHO the weirdier is o?.[k].
I propose another candidate which is ??:
obj??             =>   (typeof obj !== 'undefined' && obj !== null && obj !== undefined)
obj??.key         =>   ((obj??) ? obj.key : undefined)
obj??[key]        =>   ((obj??) ? obj[key] : undefined)
fun??(...a)       =>   ((fun??) ? fun(...a) : undefined)
obj.fun??(...a)   =>   ((obj.fun??) ? obj.fun(...a) : undefined)

// and obviously...
obj??.fun??( ...a )   =>   ((obj??) && (obj.fun??) ? : obj.fun(...a) : undefined)

I propose another candidate which is ??

Yeah, i had this one in mind as well, this is actually cleanest approach and no collisions with anything and no lookahead

I really like this ?? approach, very generic, very readable, very
likable. I'll fight for this one instead of my .? :)
On Fri, Feb 5, 2016 at 3:28 PM Ishi Ruy<EMAIL_ADDRESS>wrote:

I propose another candidate which is ??
Yeah, i had this one in mind as well, this is actually cleanest approach
and no collisions with anything and no lookahead
—
Reply to this email directly or view it on GitHub
https://github.com/claudepache/es-optional-chaining/issues/2#issuecomment-180379645
.

This ?? completely illiminates issues with ternary, the other big issues left is making them accept it :P

I really like this ?? approach, very generic, very readable, very likable. I'll fight for this one instead of my .? :)

parser should work hard so we would work less harder.

Yeah but when it comes to propose new syntax, I think it's good to keep in mind that the less hard the parser will have to work, the less impact on performance this syntax will have, and the more chance it will have to be adopted.

The ?? token works well by itself. However, it is used in several other languages for the null-coalescing operator, which has different semantics.

@claudepache If you’re talking about this then… what about this(wild idea):
a ?? b   =>   ((a??) ? a : b)

@nhz-io @naholyr Thank you! Very glad to contribute!

@claudepache Actually ?? is null-coalescing only in C# (which is a pretty big market by itself) but there’s ?: in PHP and others which looks nice.

@claudepache Argh a ?? b is a bad idea:
a ?? b   =>   ((a??) ? a : b)
a??b     =>   ((a??) ? a : b)

a??[k]   =>   ((a??) ? a : [k])  // this or…
         =>   ((obj??) ? obj[key] : undefined) // this?

@claudepache Actually ?? is null-coalescing only in C# (which is a pretty big market by itself) but there’s ?: in PHP and others which looks nice.

Also used in Swift and in PHP 7. (The ?: operator of PHP is more like the || operator of JavaScript.)

@claudepache Argh a ?? b is a bad idea:
a ?? b   =>   ((a??) ? a : b)
a??b     =>   ((a??) ? a : b)

That is approximatively the semantics of the null-coalescing operator, which is completely different from optional chaining. You can’t indeed use the same operator for both operations.

That part was just to make it clear the possible collisions.

Swift language has these proposed tokens ?., ?[, ?(.
Which totally makes sense to me.. the question mark is used as an addition to the regular and "unsafe" versions of MemberExpression and CallExpression.
Also, I suppose that only adding an optional flag to those types will suffice to make the AST transform use them.
The only problem being the ternary operator, which Swift in contrast to coffee script has left for your free usage. So we should try to make it work regardless, in my opinion.

The tokens ?[ and ?( won’t work well, because of interaction of the conditional operator ? : and backward compatibility constraints. For instance, you have to distinguish between:
a?[b] + c: d // interpreted as: a ? ([b] + c) : d

(whose meaning cannot be changed) and:
a?[b] + c; // should be interpreted as: (a?[b]) + c;

Note in particular the difference of precedence level between ? : and ?[.  I expect that it would be difficult for a parser to analyse that efficiently (i.e., quickly); and even if this problem could be solved, it could be confusing for the user.
The syntax ?.[ and ?.( was chosen as a least bad option under difficult constraints. However, I have not yet written down my arguments behind that statement (which is the main reason why this issue is still open).

Hey @claudepache,
Thanks for your response!

The tokens ?[ and ?( won’t work well, because of interaction of the conditional operator ? : and backward compatibility constraints. For instance, you have to distinguish between:

a?[b] + c: d // interpreted as: a ? ([b] + c) : d`

IMHO this should not be allowed. I understand that it is a breaking change, thus it may not be accepted, but for the most part, the vagueness of this syntax is mostly harming and should be avoided.
Also, a simple restriction of making this symbol whitespace intolerant, will eliminate most syntax obscurities.
I suggest adding to the token types file 3 new tokens that will be parsed with question special readToken function (similar to that of dot ). It will check for following character being either ., ( or [.
After resolving the tokens, parsing of expressions can be done pretty easily by updating the subscript expression parse method and call expression parse method to check for cases of the new tokens.
In the more general sense, it means that the new tokens are preceding the ternary operator, and that lines of the sort you've specified above will be syntax error for that implementation.

a?[b] + c: d // interpreted as: a ? ([b] + c) : d

IMHO this should not be allowed. I understand that it is a breaking change, thus it may not be accepted, but for the most part, the vagueness of this syntax is mostly harming and should be avoided.

Backward compatibility is quite a hard requirement on the web. There are very plausible use cases such as useArray?[foo]:foo (whether it is good style is not the question), which we cannot conceivably break (and browser vendors will refuse to break, anyway).

Hmm yeah I now realised the problem with that example.
And you think due to minification we cannot allow for whitespace separation to solve this problem?
If that's the case then the only possible syntax is one that allows for the ternary operator to have precedence over the optional chaining. or as you've suggested have a non conflicting syntax.
What do you think of changing the following line https://github.com/babel/babylon/blob/master/src/parser/expression.js#L158
to a condition where if there is no colon found you will than try to parse optional subscript?
As far as I see on the current babylon implementation, this is not something that is thought of as bad implementation.
My main argument for preferring this syntax over another is that it fits well with the non optional member expression. Also it is to say that we are not optimizing before checking the impact of said change on the parser's performance.
On the browser implementation end, we could optimize by other ways like making sure that those obscure sections are easily resolved by adding parenthesis on the expression.

C# also has ?., ?[ and ?(, as well as ternary ? :, and they apparently are doing fine. Maybe look at how they define the four?

I like the idea of ??. For null-coalescing operator, we could use ??? or ??:.

@hax how would you handle array lookup then?

C# also has ?., ?[ and ?(, as well as ternary ? :, and they apparently are doing fine. Maybe look at how they define the four?

@hax Does C# uses [ ... ] for array literals or some other literal value? If not, they don’t have the parsing issue that JS would have for ?[. If yes, we may be interested to explore how they handle this case. (Note that parsing should be not only possible, but also reasonably efficient.)

@Alxandr See @yuchi 's comment: https://github.com/claudepache/es-optional-chaining/issues/2#issuecomment-180378416

I like the idea of ??. For null-coalescing operator, we could use ??? or ??: or ?|| ...

The issue with ??. is not technical but social. I foresee confusion among developers if we use ?? for something different from what is common in other languages.

@claudepache C# uses [..] for array access (and arbitrary property access).

@claudepache Yes I agree it's better to stick on similar syntax but x.?[prop] also not align to other languages. And not every language use ?. for example Ruby use &., perl use .?. So I think if JS choose a little different syntax is ok.

@claudepache And I remember I have seen a language use ?? for optional chaining but forget which language 🤔

Note there are other options in the old discussion at https://esdiscuss.org/topic/existential-operator-null-propagation-operator includes .? (as the title of this issue), ?? and prefix version of ?.

Does C# uses [ ... ] for array literals or some other literal value?

To confirm, they do not. Array literals/expressions in C# use { ... } along with other syntax.

Ah. Sorry, I misread. Didn't see that the question was of array literals.

C# has both   obj?.prop and ternary evaluation. This MUST NOT be an issue.
"If they can we can".

Questions of preference for a particular token aside, x?.3:0 is currently a valid ternary expression and this proposal would change that as currently specced. I’m pretty sure that there’s never been a backwards incompatible change made to the lexical grammar in JavaScript’s 22 years, and I doubt it would be considered justified here — "don’t break the web" is a pretty high priority I think. I would second @yuchi’s ?? suggestion as a way to avoid this while still giving the operator a pretty intuitive symbol.

"x?.3:0" is valid ternary but not valid chaining operator (orphan ":") so
that could be solved with ahead parsing. Which makes the parsing a bit more
complex (that's where I got lost when trying to modify babel's parser), but
we should be able to keep the operator that way. I didn't find hard
conflicts making breaking compatibility.
As an alternative, I obviously prefer ".?" (and maybe its brother "]?").
On Tue, May 2, 2017 at 8:28 AM Darien Maillet Valentine <
<EMAIL_ADDRESS>wrote:

Questions of preference for a particular token aside, x?.3:0 is currently
a valid ternary expression and this proposal would change that as currently
specced. I’m pretty sure that there’s never been a backwards incompatible
change made to the lexical grammar in JavaScript’s 22 years, and I doubt it
would be considered justified here — "don’t break the web" is a pretty high
priority I think. I would second @yuchi https://github.com/yuchi’s ??
suggestion as a way to avoid this while still giving the operator a pretty
intuitive symbol.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/claudepache/es-optional-chaining/issues/2#issuecomment-298507877,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AANEMzxppd3F8hHEX4PpL6xk4-1zro7hks5r1s0HgaJpZM4HUMfj
.

Personally I think ?. makes more semantic sense than .?. I intuitively interpret person?.name as

if person exists, give me the name property

but person.?name as

if the name property exists on person, give me its value

The second one feels a bit awkward, and with that interpretation it'd also be redundant unless there are multiple levels of chaining (person.?name would be equivalent to person.name), so it's a more confusing syntax to me. Your mileage may vary.

Personally I think ?. makes more semantic sense than .?.

So do I, and it is the reason why that form was chosen rather than this one.
But sure, if there is feedback from implementors that this is too hard to parse, alternative syntaxes will be considered.

@bathos const, let, ()=>, **...  backwards incompatible changes made to the lexical grammar in less than 5 years.

@Wedvich @claudepache I agree with the syntax, not with hard to implement.
This is a sample of lookahead
/(\w+)[\s\S]*?\?(?=[\s\S]*?\.[\s\S]*?(\w*))/im.exec('obj?.prop')
If is possible with RegExp, it is possible programmatically.

const, let, ()=>, **... backwards incompatible changes made to the lexical grammar in less than 5 years.

@leodutra Those were not backward-incompatible (except for an edge-case involving let [ in non-strict mode), in the sense that only invalid syntax became valid. Maintaining backward compatibility, i.e. not changing the meaning of already valid syntax, has resulted in minor tweaks in the grammar for some of those new forms (such as forbidding line-terminators in some places). Backward-compatibility is a hard requirement on the web.

@leodutra There is a distinction between the lexical and syntactic grammars in ES. If you need to information about an arbitrarily distant token in order to lex the token you’re "at", that is a concern of the syntactic, not lexical grammar. If that were introduced here, then one would need to add additional goal symbols to the lexical grammar. That has been done before — first for regular expression literals and second for template spans. But each additional lexical ambiguity expands the set of goals potentially by a lot. In this case I’m pretty sure that would mean adding four new ones:
InputElementDivOrNullProp
InputElementDivOrTernaryColon
InputElementRegExpOrNullProp
InputElementRegExpOrTernaryColon
InputElementRegExpOrTemplateTailOrNullProp
InputElementRegExpOrTemplateTailOrTernaryColon
InputElementTemplateTailOrNullProp
InputElementTemplateTailOrTernaryColon

@claudepache Ah... you are speaking about not breaking existing code. Right, but no proposal here, till now, would break existing code. It would not work in old engines, as let, const and lambdas... that's what I mean.
If we are not ok with lookaheads, only a single symbol or an totally new symbol for JS can evade lookaheads.
Pick yours: #, @, §, &, ...
user#props ? true : false
user??props ? true : false
user?.props ? true : false
I don't care about the lexer/parser. Their devs shall sweat blood and pain, as any dev shall do for top grade stuff. The important part is JavaScript pushes the best of known C-like languages.
C# ?. is clean and very known.
An Optional proposal would be very welcome as, widely, most functional languages relies on this for feature rich optional chaining.

By the way, I'm not a C# fan. But I can't deny the greatness of their chaining and Lisp (although this last one is constantly raped by bad approaches).
More about Option, for those who may not know it.

I don't care about the lexer/parser. Its devs shall sweat blood and pain, as any dev shall do for top grade stuff.

I don’t think it’s a question of implementation difficulty? Complexity maybe. What you described implied a "bigger touch" to the lexical grammar than the proposal as it currently stands; meanwhile ?? and similar solutions represent very small touches. I’m not saying it’s a bad idea — just pointing out that such concerns do end up being factors when proposals are being reviewed.

@bathos I agree Option Type is a greedy eye on conditionals.
C# has different meaning for ??... it works more like ours || (or).
An option for ?. would be the requirement for no spacing between the two chars, behaving like the spread operator (... always together).

An option for ?. would be the requirement for no spacing between the two chars,

There is already no space allowed between the two chars. The token ?. is defined by the lexical grammar, where spaces are significant.

I'm closing this issue, as I won’t change the syntax, and it is not possible to satisfy everyone anyway. Any choice has its own pros and cons.
If you have a strong feeling about the result, you may discuss it either on es-discuss or on the official repo.

Created this method which you might find useful (it's type-safe btw):
/**
 * Type-safe access of deep property of an object
 *
 * @param obj                   Object to get deep property
 * @param unsafeDataOperation   Function that returns the deep property
 * @param valueIfFail           Value to return in case if there is no such property
 */
export function getInSafe<O,T>(obj: O, unsafeDataOperation: (x: O) => T, valueIfFail?: any) : T {
    try {
        return unsafeDataOperation(obj)
    } catch (error) {
        return valueIfFail;
    }
}

And you can use it like this:
getInSafe(sellTicket, x => x.phoneDetails.imeiNumber, '');


Support GPU Materialization for UnsetEncodingOp

I think the issue is that there are expand_shape + transpose right before the unpack, but @lialan creates the unpack op first.

@hanhanW I remember the reason was that I need to insert the collapse + expand shape transform to connect the producer and the unpack op, so I need to materialize unpack os first to get the shape of it:
auto sourceShape = unPackOp->getSourceType().getShape();

Is there a simple way to get the unpack's source shape without materializing it first?

I think the issue is that there are expand_shape + transpose right before the unpack, but @lialan creates the unpack op first.

@hanhanW I remember the reason was that I need to insert the collapse + expand shape transform to connect the producer and the unpack op, so I need to materialize unpack os first to get the shape of it:
auto sourceShape = unPackOp->getSourceType().getShape();

Is there a simple way to get the unpack's source shape without materializing it first?

I see. IIUC, the issue is that you use the unpack's source shape in the transpose op and collapse_shape op creation. E.g.,
    // unPackOp->getSourceType() is used here.
    auto collapseShapeOp = rewriter.create<tensor::CollapseShapeOp>(
        loc, unPackOp->getSourceType(), transposeOp->getResult(0),
        *collapseReassoc);

The maybeEncodingInfo should have enough information. I think you can construct the shape by taking the leading shape from adaptor.getSource().getType() and append innerTileSizes. So it is something like:
// This gives you the
auto srcConvertedType = cast<RankedTensorType>(adaptor.getSource.getType());
// The srcRank is missing, which is fixed in my other PR.
SmallVector<int64_t> unpackSrcShape(srcConvertedType.getShape().take_front(maybeEncodingInfo->srcRank));
unpacksrcShape.append(maybeEncodingInfo->innerTileSizes.begin(), maybeEncodingInfo->innerTileSizes.end());

(The fix in my PR (https://github.com/iree-org/iree/pull/18294) is just adding one line to getEncodingInfoForMatmul method.)
I don't have a strong opinion about which PR should go first. I don't mind to address the conflicts. Please take a quick look at https://github.com/iree-org/iree/pull/18294 and let me know how you think.

@hanhanW I updated the code and included your small one line change about the srcRank. So if this patch goes in first then you need to do a little conflict resolving.


:sha512 and :sha384

When signing a request with :sha512 and :sha384, it appears that the presence of a newline character in the signature can cause the signature validation to fail.
Is anyone else seeing this kind of problem?
I believe the use of Base64.strict_encode64 would eliminate the issue without impacting other signature digests.

@ckoch-ncsa can you give a sample body ? or just any body with a newline in it ?

@lanej
It's not the body that causes an error it's the spec encode64 complies with; :encode64 includes newline chars at a fixed point (60 chars), per RFC2045 while strict_encode64 complies with RFC4648 where no line feeds are added.
See: https://ruby-doc.org/stdlib-2.1.3/libdoc/base64/rdoc/Base64.html#method-i-encode64
This is not an issue with :sha256 signatures as they are less than 60 chars.
It only appears in longer SHA hashes.
Below is some example code illustrate the point.
def signature(key_secret, digest)
  Base64.encode64(
    OpenSSL::HMAC.digest(
      OpenSSL::Digest.new(digest.to_s), key_secret, "GET\n\n\n/some_path")).strip
end
encode64:
  signature("abcdef", :sha256) = "te0hL1veaPBq8vQEAyxSA6b0Okj/Qs7GsSUMwAXWuTU="

  signature("abcdef", :sha384) = "nZTR8vJdlDsej6DAjXOx1izpKjUloyMRKBhY053VwPwno3XtzL/j/7jHFKm8\nmjrO"

  signature("abcdef", :sha512) = "+hl/Mr4rI705JR/IzpR9iUinzrqeitVjKRur6azjxtdHcpCv7WtQGYiKmAwR\nc8qadHcGyaeZvm7MTgdKsw6e4w=="

def signature(key_secret, digest)
  Base64.strict_encode64(
    OpenSSL::HMAC.digest(
      OpenSSL::Digest.new(digest.to_s), key_secret, "GET\n\n\n/some_path")).strip
end
strict_encode64:
  signature("abcdef", :sha256) = "te0hL1veaPBq8vQEAyxSA6b0Okj/Qs7GsSUMwAXWuTU="

  signature("abcdef", :sha384) = "nZTR8vJdlDsej6DAjXOx1izpKjUloyMRKBhY053VwPwno3XtzL/j/7jHFKm8mjrO"

  signature("abcdef", :sha512) = "+hl/Mr4rI705JR/IzpR9iUinzrqeitVjKRur6azjxtdHcpCv7WtQGYiKmAwRc8qadHcGyaeZvm7MTgdKsw6e4w=="

I concur. I've dealt with the line break issue with encode64 before.  Switching to strict_encode64 should fix the problem.


[FLINK-4766] Port TM config parameters to Config Options

This PR ports most taskmanager related config parameters to config options.
The following keys were not ported as i wasn't sure whether they should really belong to the TaskManagerOptions.
DEFAULT_SPILLING_MAX_FAN_KEY = "taskmanager.runtime.max-fan";
DEFAULT_SORT_SPILLING_THRESHOLD_KEY = "taskmanager.runtime.sort-spilling-threshold";
RUNTIME_HASH_JOIN_BLOOM_FILTERS_KEY = "taskmanager.runtime.hashjoin-bloom-filters";
FS_STREAM_OPENING_TIMEOUT_KEY = "taskmanager.runtime.fs_timeout";

The PR contains 1 commit for each ported parameter.
The majority of changes are straight-forward.
Special attention should be given to MAX_REGISTRATION_DURATION in the YarnResourceManager.
The existing code parsed a timeunit String (i.e. "5 ms") directly as an integer via Configuration#getInteger(). This didn't make any sense to me, so i changed it to first create a Duration, convert it to seconds, and then create a FiniteDuration from it.

Will re-open this PR in a bit.


Building column partitions discards category dtype

System information

OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Any
Modin version (modin.__version__): c2e7f9ecb6a31cd0d59f4ce17dacb059980c45f7
Python version: 3.7.5
Code we can use to reproduce:

import os

# Setting Python engine to be able to see the printed output inside `applier`
os.environ["MODIN_ENGINE"] = "python"

import modin.pandas as pd
import numpy as np

def applier(df, other=None):
    print(f"df dtypes inside 'applier':\n{df.dtypes}\n")
    if other is not None:
        print(f"'other' dtypes inside 'applier':\n{other.dtypes}\n")

data = {f"col{i}": np.arange(256) for i in range(6)}
md_df = pd.DataFrame(data).astype({"col0": "category"})
other = md_df[["col1", "col2"]].astype({"col1": "category"})

print(f"proper 'df' dtypes:\n{md_df.dtypes}")
print(f"proper 'other' dtypes:\n{other.dtypes}\n")
md_df._query_compiler._modin_frame._apply_full_axis(axis=0, func=applier)
md_df._query_compiler._modin_frame.broadcast_apply_full_axis(
    axis=0, func=applier, other=other._query_compiler._modin_frame
)

 Output
proper 'df' dtypes:
col0    category
col1       int64
col2       int64
col3       int64
col4       int64
col5       int64
dtype: object
proper 'other' dtypes:
col1    category
col2       int64
dtype: object

df dtypes inside 'applier':
col0    int64
col1    int64
col2    int64
col3    int64
col4    int64
col5    int64
dtype: object

df dtypes inside 'applier':
col0    int64
col1    int64
col2    int64
col3    int64
col4    int64
col5    int64
dtype: object

'other' dtypes inside 'applier':
col1    int64
col2    int64
dtype: object

Describe the problem
The problem is in how we're building column partitions and broadcasted frame inside deploy_axis_func and deploy_func_between_two_axis_partitions, we're just concating partitions and that leads to discarding category dtype:
>>> pd_df1
  col0  col1
0    a     0
1    a     1
>>> pd_df2
  col0  col1
0    b     2
1    a     3
>>> pd_df1.dtypes
col0    category
col1       int64
dtype: object
>>> pd_df2.dtypes
col0    category
col1       int64
dtype: object
>>> pandas.concat([pd_df1, pd_df2]).dtypes
col0    object  # category dtype were discarded
col1     int64
dtype: object

To save categories we can use the same approach we're using to do to_pandas in concatenate by union categories. Unioning categories slows down the building of column partitions by about 30% for frames that contain categories, however, if the frame already has computed dtypes then we can pass them into our concatenate function and reuse already unioned categories, which should not give a noticeable slowdown.

This problem still seems to exist on the latest master.


Bark on google collab

This happens when i click generate my audio
NameError: name 'generate_audio' is not defined

Do you have imported it?
from bark import generate_audio, SAMPLE_RATE


Hierarchy Editor pages throw Exceptions

Hierarchy Editor pages throw Exceptions. All of which are similar to this one:
Environment:
Request Method: GET
Request URL: http://<IP_ADDRESS>:8000/editor/sources/
Django Version: 1.7.1
Python Version: 2.7.6
Installed Applications:
('django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'mptt',
'editor')
Installed Middleware:
('django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.auth.middleware.SessionAuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.clickjacking.XFrameOptionsMiddleware')
Traceback:
File "/Library/Python/2.7/site-packages/django/core/handlers/base.py" in get_response
111.                     response = wrapped_callback(request, *callback_args, **callback_kwargs)
File "/Users/eric/proj/metaeditor/editor/views.py" in sources
30.     root = Source.objects.filter(level=0)[0]
File "/Library/Python/2.7/site-packages/django/db/models/query.py" in getitem
177.         return list(qs)[0]
File "/Library/Python/2.7/site-packages/django/db/models/query.py" in iter
141.         self._fetch_all()
File "/Library/Python/2.7/site-packages/django/db/models/query.py" in _fetch_all
966.             self._result_cache = list(self.iterator())
File "/Library/Python/2.7/site-packages/django/db/models/query.py" in iterator
265.         for row in compiler.results_iter():
File "/Library/Python/2.7/site-packages/django/db/models/sql/compiler.py" in results_iter
700.         for rows in self.execute_sql(MULTI):
File "/Library/Python/2.7/site-packages/django/db/models/sql/compiler.py" in execute_sql
786.             cursor.execute(sql, params)
File "/Library/Python/2.7/site-packages/django/db/backends/utils.py" in execute
81.             return super(CursorDebugWrapper, self).execute(sql, params)
File "/Library/Python/2.7/site-packages/django/db/backends/utils.py" in execute
65.                 return self.cursor.execute(sql, params)
File "/Library/Python/2.7/site-packages/django/db/utils.py" in exit
94.                 six.reraise(dj_exc_type, dj_exc_value, traceback)
File "/Library/Python/2.7/site-packages/django/db/backends/utils.py" in execute
65.                 return self.cursor.execute(sql, params)
File "/Library/Python/2.7/site-packages/django/db/backends/sqlite3/base.py" in execute
485.         return Database.Cursor.execute(self, query, params)
Exception Type: OperationalError at /editor/sources/
Exception Value: no such column: editor_source.lft

you need to do db migrations.
python manage.py migrate

On Feb 24, 2015, at 10:27 AM, David Zhang<EMAIL_ADDRESS>wrote:
you need to do db migrations.
python manage.py migrate

I did that:
[eric@gala metaeditor]$ rm database.db
    [eric@gala metaeditor]$ DJANGO_DATABASE='devel' python manage.py migrate

Then, I get the same error:
django.db.utils.OperationalError: no such column: editor_category.lft

While it is running the migration for:
editor.0003_auto_20150125_0430

All of the prior migrations work.
eric.

Eric Busboom<PHONE_NUMBER>
<EMAIL_ADDRESS>http://www.busboom.org

Actually this migration is not needed. Please pull latest codes and migrate again.


Typo in Beta Responsive Web Design CSS Box Model (Rothko Painting)

Affected page

https://github.com/freeCodeCamp/freeCodeCamp/blob/main/curriculum/challenges/english/14-responsive-web-design-22/learn-the-css-box-model-by-building-a-rothko-painting/step-041.md
Your code

Expected behavior

The text of the challenge should say:
and bottom-right radius to 8px, and top-right and bottom-left radius to 10px.
But it displays:
and bottom-right radii to 8px, and top-right and bottom-left radii to 10px.
Screenshots

System

Device: [e.g. iPhone6, Laptop] Laptop Toshiba Satelite 655
OS: [e.g. iOS 14, Windows 10, Ubuntu 20.4] Ubuntu 20.4
Browser: [e.g. chrome, safari] Chrome
Version: [e.g. 22]

Additional context

@TrshDesigns Radii is the plural or radius. So I think there is nothing to change in that sentence🙂.


add layout to tabler.options

Description
Add the default layout so that tests pass.
Types of changes

[ X ] Bug fix (non-breaking change which fixes an issue)

Checklist

[ ] I updated the documentation (see here)
[X ] I agree that this code will be published under the MIT license

Already done.
(sorry for late response)


Double tap zoom

Hi @barteksc
I am planning to zoom in the pdf page on the point user double tapped. but as of now it is zooming from the center of the page.
How can I achieve my solutions. It's good to have such a library you provided but as per my requirement please suggest and want to achieve this.
Thanks
Vinod

Hi @barteksc
I have implemented that feature, when double tap on the pdf view it is moving to that x,y coordinates but I want to move with animation. Can you please how to give animations to move method.
on Doubletap method In Dragpinchmanager class I have done following changes:
if (pdfView.getZoom() >= pdfView.getMaxZoom()) {
pdfView.resetZoomWithAnimation();
} else {
pdfView.zoomCenteredRelativeTo(pdfView.getMidZoom(),new PointF(x,y));
}
Thanks
Vinod


fix restore compaction/run_status api can show be's overall compaction status and refactor code

bp: #35278

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall


Splitting ruby arguments list chained to a block inverses the order of the arguments

When I have an argument list such as this:
expect {
  something
}.raise_error(some_token, /nil/)

And place my cursor on ( and activate splitjoin:
expect {
  something
}.raise_error(
  /nil/,
  some_token,
)

when I would expect the following:
expect {
  something
}.raise_error(
  some_token,
  /nil/,
)

Whatever the last argument is, a regexp, string, any class - it inverses the order.

That's very odd. I can't seem to reproduce it locally, so it's probably some combination of settings that I haven't considered. Difficult to tell where the issue lies.
Could you try running the following command with the cursor on the opening bracket of the joined string:
:echo sj#argparser#ruby#ParseArguments(col('.'), col('$'), getline('.'))

You can then paste the result and it'll at least give me an idea if the bug comes from parsing or replacing.

Oh, also, if you could let me know of any custom splitjoin settings you have (trailing comma, for instance), and the output of vim --version, this might help give me some context to test with.

I think I found the culprit, when reporting the bug I anonymized the code - where the original sample had a namespace in it. So changing it to the following makes this reproducable for me aswell, with and without my configuration.
expect {
  something
}.to raise_error(NameSpace::Whatever, /nil/)

But, to give you all the details you requested.
The output of the function call is:
[24, 46, ['/nil/'], ['NameSpace::Class'], 'new']

The configuration I have is:
let g:splitjoin_trailing_comma = 1
let g:splitjoin_ruby_hanging_args = 0
let g:splitjoin_ruby_curly_braces = 0

My vim --version is
VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Mar 30 2018 07:37:16)
macOS version
Included patches: 1-1650
Compiled by Homebrew
Huge version without GUI.  Features included (+) or not (-):
+acl               +farsi             +mouse_sgr         -tag_any_white
+arabic            +file_in_path      -mouse_sysmouse    -tcl
+autocmd           +find_in_path      +mouse_urxvt       +termguicolors
-autoservername    +float             +mouse_xterm       +terminal
-balloon_eval      +folding           +multi_byte        +terminfo
+balloon_eval_term -footer            +multi_lang        +termresponse
-browse            +fork()            -mzscheme          +textobjects
++builtin_terms    -gettext           +netbeans_intg     +timers
+byte_offset       -hangul_input      +num64             +title
+channel           +iconv             +packages          -toolbar
+cindent           +insert_expand     +path_extra        +user_commands
-clientserver      +job               +perl              +vertsplit
+clipboard         +jumplist          +persistent_undo   +virtualedit
+cmdline_compl     +keymap            +postscript        +visual
+cmdline_hist      +lambda            +printer           +visualextra
+cmdline_info      +langmap           +profile           +viminfo
+comments          +libcall           -python            +vreplace
+conceal           +linebreak         +python3           +wildignore
+cryptv            +lispindent        +quickfix          +wildmenu
+cscope            +listcmds          +reltime           +windows
+cursorbind        +localmap          +rightleft         +writebackup
+cursorshape       -lua               +ruby              -X11
+dialog_con        +menu              +scrollbind        -xfontset
+diff              +mksession         +signs             -xim
+digraphs          +modify_fname      +smartindent       -xpm
-dnd               +mouse             +startuptime       -xsmp
-ebcdic            -mouseshape        +statusline        -xterm_clipboard
+emacs_tags        +mouse_dec         -sun_workshop      -xterm_save
+eval              -mouse_gpm         +syntax
+ex_extra          -mouse_jsbterm     +tag_binary
+extra_search      +mouse_netterm     +tag_old_static
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
       defaults file: "$VIMRUNTIME/defaults.vim"
  fall-back for $VIM: "/usr/local/share/vim"
Compilation: clang -c -I. -Iproto -DHAVE_CONFIG_H   -DMACOS_X -DMACOS_X_DARWIN  -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: clang   -L. -fstack-protector -L/usr/local/lib -L/usr/local/opt/libyaml/lib -L/usr/local/opt/openssl/lib -L/usr/local/opt/readline/lib  -L/usr/local/lib -o vim        -lncurses -liconv -framework AppKit   -mmacosx-version-min=10.13 -fstack-protector-strong -L/usr/local/lib  -L/usr/local/Cellar/perl/5.26.1/lib/perl5/5.26.1/darwin-thread-multi-2level/CORE -lperl -lm -lutil -lc  -L/usr/local/opt/python/Frameworks/Python.framework/Versions/3.6/lib/python3.6/config-3.6m-darwin -lpython3.6m -framework CoreFoundation  -lruby.2.5.1 -lobjc

Right, I can reproduce this now and I understand the problem -- for some reason, the Namespace::Whatever part is interpreted as the option hash rather than an argument. I'll see what I can do to fix it.

Fantastic, thank you!

I pushed a fix to master. Try it out and let me know if it seems to work.

Works wonders! Thank you.


Codabar start/end control chars should be included in the result

At least the native Barcode Detection APIs from Android Chrome and iOS17/macOS Sonoma 14 (which can be manually activated through Safari Settings) include the two start/end control chars (A,B,C or D) into the result.
There might be an appropriate (deprecated?) option in zxing-wasm:
https://zxing-wasm.deno.dev/interfaces/full.ReaderOptions.html#returnCodabarStartEnd
Perhaps it makes sense to conform to the current implementations of the native API in the fields.

There might be an appropriate (deprecated?) option in zxing-wasm:

Yes, this option will be removed but it will be enabled always. Ref: https://github.com/zxing-cpp/zxing-cpp/discussions/704
Can you confirm enabling this option aligns with the native Barcode Detection APIs from Android Chrome and iOS17/macOS Sonoma 14 in this demo page? Although it is marked as deprecated it still works.

Yes, this option will be removed but it will be enabled always. Ref: zxing-cpp/zxing-cpp#704

Thanks for pointing me to that discussion. Very interessting to read - also the thoughts behind code 39 and code 93.

Can you confirm enabling this option aligns with the native Barcode Detection APIs from Android Chrome and iOS17/macOS Sonoma 14 in this demo page? Although it is marked as deprecated it still works.

Seems they all output the control chars.

Scan in Android Chrome 127
using this webapp https://georapbox.github.io/barcode-scanner/ results in A2342342$2022+B.
Scan in iOS 17.6.1 Safari
using this webapp https://georapbox.github.io/barcode-scanner/
with native Shape Detection API manually activated via Safari settings, results in A2342342$2022+B.
Scanning Codabar barcode, with Return Codabar Start End activated:
using https://zxing-wasm-demo.deno.dev/ results in A2342342$2022+B.
[
  {
    "isValid": true,
    "error": "",
    "format": "Codabar",
    "bytes": {
      "0": 65,
      "1": 50,
      "2": 51,
      "3": 52,
      "4": 50,
      "5": 51,
      "6": 52,
      "7": 50,
      "8": 36,
      "9": 50,
      "10": 48,
      "11": 50,
      "12": 50,
      "13": 43,
      "14": 66
    },
    "bytesECI": {
      "0": 93,
      "1": 70,
      "2": 48,
      "3": 65,
      "4": 50,
      "5": 51,
      "6": 52,
      "7": 50,
      "8": 51,
      "9": 52,
      "10": 50,
      "11": 36,
      "12": 50,
      "13": 48,
      "14": 50,
      "15": 50,
      "16": 43,
      "17": 66
    },
    "text": "A2342342$2022+B",
    "eccLevel": "",
    "contentType": "Text",
    "hasECI": false,
    "position": {
      "topLeft": {
        "x": 42,
        "y": 2
      },
      "topRight": {
        "x": 345,
        "y": 2
      },
      "bottomRight": {
        "x": 345,
        "y": 101
      },
      "bottomLeft": {
        "x": 42,
        "y": 101
      }
    },
    "orientation": 0,
    "isMirrored": false,
    "isInverted": false,
    "symbologyIdentifier": "]F0",
    "sequenceSize": -1,
    "sequenceIndex": -1,
    "sequenceId": "",
    "readerInit": false,
    "lineCount": 100,
    "version": ""
  }
]

Thank you, I think I should change the returnCodabarStartEnd option for this library. This might be a breaking change for others but I consider this as a bug given that this library is meant to be used as a polyfill, so a patch release will be published including this fix.


Tabular: Added persist_models, unpersist_models methods to TabularPredictor

Issue #, if available:
#376
Description of changes:
Added persist_models, unpersist_models methods to TabularPredictor
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Job PR-640-1 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-640/1/index.html

Job PR-640-2 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-640/2/index.html

Job PR-640-3 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-640/3/index.html

Looks good to me, just have minor comments about clarity. I also think 'best' should be the default for models in predictor.persist_models() since most users probably don't require all other models persisted as well.
Should also consider if we want to persist at the end of task.fit() by default or not. I imagine if the models occupy hardly any of the available memory, then persisting them by default is reasonable.

Regarding persisting by default, this is planned for a future PR to ensure stability, since this is a major change in functionality and we need to be careful about the % of memory to allow by default.

Job PR-640-4 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-640/4/index.html


Draft and send thank you comms to suppliers

What
Send thank you comms to suppliers
Why
As a gesture of our appreciation.
Who needs to work on this
Imran
Who needs to review this
N/A
Done when sent to

[x] AV supplier
[x] Venue
[x] Caterers
[x] Photographer

https://docs.google.com/document/d/1LAICuDqDTpmKFRiG-6JgVxKaRvXTO6tKatkE5UVEEI0/edit
Imran to check and send Thank you messages

Thank you comms sent to suppliers