Consider setting a fixed minimum Rust version

When I use the procedure in the README to build pydantic-core, the build fails. The issue can be reproduced in the following way:
git clone -b v2.16.1 https://github.com/pydantic/pydantic-core.git
cd pydantic-core
python3.11 -m venv env
source env/bin/activate
make install

It results in this output

+ git clone -b v2.16.1 https://github.com/pydantic/pydantic-core.git
Cloning into 'pydantic-core'...
Note: switching to '4538190f0e7a47a99ca44351f744007b016511d4'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:
git switch -c
Or undo this operation with:
git switch -
Turn off this advice by setting config variable advice.detachedHead to false
+ cd pydantic-core
+ python3.11 -m venv env
+ source env/bin/activate
++ deactivate nondestructive
++ '[' -n '' ']'
++ '[' -n '' ']'
++ '[' -n /usr/bin/bash -o -n '' ']'
++ hash -r
++ '[' -n '' ']'
++ unset VIRTUAL_ENV
++ unset VIRTUAL_ENV_PROMPT
++ '[' '!' nondestructive = nondestructive ']'
++ VIRTUAL_ENV=/tmp/pydantic-core/env
++ export VIRTUAL_ENV
++ _OLD_VIRTUAL_PATH=/home/arnaud/.local/bin:/home/arnaud/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin
++ PATH=/tmp/pydantic-core/env/bin:/home/arnaud/.local/bin:/home/arnaud/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin
++ export PATH
++ '[' -n '' ']'
++ '[' -z '' ']'
++ _OLD_VIRTUAL_PS1=
++ PS1='(env) '
++ export PS1
++ VIRTUAL_ENV_PROMPT='(env) '
++ export VIRTUAL_ENV_PROMPT
++ '[' -n /usr/bin/bash -o -n '' ']'
++ hash -r
+ make install
/usr/bin/which: no maturin in (/tmp/pydantic-core/env/bin:/home/arnaud/.local/bin:/home/arnaud/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin)
/usr/bin/which: no maturin in (/tmp/pydantic-core/env/bin:/home/arnaud/.local/bin:/home/arnaud/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin)
/usr/bin/which: no maturin in (/tmp/pydantic-core/env/bin:/home/arnaud/.local/bin:/home/arnaud/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin)
/usr/bin/which: no maturin in (/tmp/pydantic-core/env/bin:/home/arnaud/.local/bin:/home/arnaud/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin)
/usr/bin/which: no maturin in (/tmp/pydantic-core/env/bin:/home/arnaud/.local/bin:/home/arnaud/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin)
/usr/bin/which: no maturin in (/tmp/pydantic-core/env/bin:/home/arnaud/.local/bin:/home/arnaud/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin)
pip install -U pip wheel pre-commit
Looking in indexes: https://artifacts.internal.inmanta.com/inmanta/dev
Requirement already satisfied: pip in ./env/lib64/python3.11/site-packages (22.3.1)
Collecting pip
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/505/2d7889c1f9d05/pip-23.3.2-py3-none-any.whl (2.1 MB)
Collecting wheel
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/177/f9c9b0d45c478/wheel-0.42.0-py3-none-any.whl (65 kB)
Collecting pre-commit
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/c25/5039ef399049a/pre_commit-3.6.0-py2.py3-none-any.whl (204 kB)
Collecting cfgv>=2.0.0
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/b72/65b1f29fd3316/cfgv-3.4.0-py2.py3-none-any.whl (7.2 kB)
Collecting identify>=1.0.0
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/d40/ce5fcd7628176/identify-2.5.33-py2.py3-none-any.whl (98 kB)
Collecting nodeenv>=0.11.1
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/df8/65724bb3c3adc/nodeenv-1.8.0-py2.py3-none-any.whl (22 kB)
Collecting pyyaml>=5.1
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/d2b/04aac4d386b17/PyYAML-6.0.1-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (757 kB)
Collecting virtualenv>=20.10.0
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/423/8949c5ffe6876/virtualenv-20.25.0-py3-none-any.whl (3.8 MB)
Requirement already satisfied: setuptools in ./env/lib64/python3.11/site-packages (from nodeenv>=0.11.1->pre-commit) (65.5.1)
Collecting distlib<1,>=0.3.7
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/034/db59a0b96f8ca/distlib-0.3.8-py2.py3-none-any.whl (468 kB)
Collecting filelock<4,>=3.12.2
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/57d/bda9b35157b05/filelock-3.13.1-py3-none-any.whl (11 kB)
Collecting platformdirs<5,>=3.9.1
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/061/4df2a2f37e1a6/platformdirs-4.2.0-py3-none-any.whl (17 kB)
Installing collected packages: distlib, wheel, pyyaml, platformdirs, pip, nodeenv, identify, filelock, cfgv, virtualenv, pre-commit
Attempting uninstall: pip
Found existing installation: pip 22.3.1
Uninstalling pip-22.3.1:
Successfully uninstalled pip-22.3.1
Successfully installed cfgv-3.4.0 distlib-0.3.8 filelock-3.13.1 identify-2.5.33 nodeenv-1.8.0 pip-23.3.2 platformdirs-4.2.0 pre-commit-3.6.0 pyyaml-6.0.1 virtualenv-20.25.0 wheel-0.42.0
pip install -r tests/requirements.txt
Looking in indexes: https://artifacts.internal.inmanta.com/inmanta/dev
Collecting git+https://github.com/dateutil/dateutil.git@f2293200747fb03d56c6c5997bfebeabe703576f (from -r tests/requirements.txt (line 6))
Cloning https://github.com/dateutil/dateutil.git (to revision f2293200747fb03d56c6c5997bfebeabe703576f) to /tmp/pip-req-build-q77eh6k6
Running command git clone --filter=blob:none --quiet https://github.com/dateutil/dateutil.git /tmp/pip-req-build-q77eh6k6
Running command git rev-parse -q --verify 'sha^f2293200747fb03d56c6c5997bfebeabe703576f'
Running command git fetch -q https://github.com/dateutil/dateutil.git f2293200747fb03d56c6c5997bfebeabe703576f
Running command git checkout -q f2293200747fb03d56c6c5997bfebeabe703576f
Resolved https://github.com/dateutil/dateutil.git to commit f2293200747fb03d56c6c5997bfebeabe703576f
Installing build dependencies: started
Installing build dependencies: finished with status 'done'
Getting requirements to build wheel: started
Getting requirements to build wheel: finished with status 'done'
Preparing metadata (pyproject.toml): started
Preparing metadata (pyproject.toml): finished with status 'done'
Ignoring exceptiongroup: markers 'python_version < "3.11"' don't match your environment
Collecting coverage==7.4.0 (from -r tests/requirements.txt (line 1))
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/485/e9f897cf4856a/coverage-7.4.0-cp311-cp311-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_17_x86_64.manylinux2014_x86_64.whl (237 kB)
Collecting dirty-equals==0.7.1.post0 (from -r tests/requirements.txt (line 2))
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/7fb/9217ea7cd04c0/dirty_equals-0.7.1.post0-py3-none-any.whl (27 kB)
Collecting hypothesis==6.92.9 (from -r tests/requirements.txt (line 3))
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/8c1/ab9f3c883fe63/hypothesis-6.92.9-py3-none-any.whl (431 kB)
Collecting pandas==2.1.3 (from -r tests/requirements.txt (line 8))
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/d5d/ed6ff28abbf0e/pandas-2.1.3-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (12.2 MB)
Collecting pytest==7.4.4 (from -r tests/requirements.txt (line 9))
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/b09/0cdf5ed60bf4c/pytest-7.4.4-py3-none-any.whl (325 kB)
Collecting pytest-codspeed~=2.2.0 (from -r tests/requirements.txt (line 11))
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/5da/48b842fc46592/pytest_codspeed-2.2.0-py3-none-any.whl (10 kB)
Collecting pytest-examples==0.0.10 (from -r tests/requirements.txt (line 14))
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/3d0/b52424e454846/pytest_examples-0.0.10-py3-none-any.whl (17 kB)
Collecting pytest-speed==0.3.5 (from -r tests/requirements.txt (line 15))
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/ef9/f17d6800b158e/pytest_speed-0.3.5-py3-none-any.whl (9.7 kB)
Collecting pytest-mock==3.11.1 (from -r tests/requirements.txt (line 16))
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/21c/279fff83d7076/pytest_mock-3.11.1-py3-none-any.whl (9.6 kB)
Collecting pytest-pretty==1.2.0 (from -r tests/requirements.txt (line 17))
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/6f7/9122bf53864ae/pytest_pretty-1.2.0-py3-none-any.whl (6.2 kB)
Collecting pytest-timeout==2.2.0 (from -r tests/requirements.txt (line 18))
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/bde/531e096466f49/pytest_timeout-2.2.0-py3-none-any.whl (13 kB)
Collecting pytz==2023.3.post1 (from -r tests/requirements.txt (line 19))
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/ce4/2d816b81b6850/pytz-2023.3.post1-py2.py3-none-any.whl (502 kB)
Collecting numpy==1.26.2 (from -r tests/requirements.txt (line 21))
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/96c/a5482c3dbdd05/numpy-1.26.2-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (18.2 MB)
Collecting attrs>=22.2.0 (from hypothesis==6.92.9->-r tests/requirements.txt (line 3))
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/99b/87a485a5820b2/attrs-23.2.0-py3-none-any.whl (60 kB)
Collecting sortedcontainers<3.0.0,>=2.1.0 (from hypothesis==6.92.9->-r tests/requirements.txt (line 3))
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/a16/3dcaede0f1c02/sortedcontainers-2.4.0-py2.py3-none-any.whl (29 kB)
Collecting tzdata>=2022.1 (from pandas==2.1.3->-r tests/requirements.txt (line 8))
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/aa3/ace4329eeacda/tzdata-2023.4-py2.py3-none-any.whl (346 kB)
Collecting iniconfig (from pytest==7.4.4->-r tests/requirements.txt (line 9))
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/b6a/85871a79d2e3b/iniconfig-2.0.0-py3-none-any.whl (5.9 kB)
Collecting packaging (from pytest==7.4.4->-r tests/requirements.txt (line 9))
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/8c4/91190033a9af7/packaging-23.2-py3-none-any.whl (53 kB)
Collecting pluggy<2.0,>=0.12 (from pytest==7.4.4->-r tests/requirements.txt (line 9))
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/7db/9f7b503d67d1c/pluggy-1.4.0-py3-none-any.whl (20 kB)
Collecting black>=23 (from pytest-examples==0.0.10->-r tests/requirements.txt (line 14))
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/b3d/64db762eae4a5/black-24.1.1-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (1.7 MB)
Collecting ruff>=0.0.258 (from pytest-examples==0.0.10->-r tests/requirements.txt (line 14))
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/b17/b93c02cdb6aeb/ruff-0.1.15-py3-none-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (7.5 MB)
Collecting click>=7 (from pytest-speed==0.3.5->-r tests/requirements.txt (line 15))
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/ae7/4fb96c20a0277/click-8.1.7-py3-none-any.whl (97 kB)
Collecting rich>=12 (from pytest-speed==0.3.5->-r tests/requirements.txt (line 15))
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/6da/14c108c4866ee/rich-13.7.0-py3-none-any.whl (240 kB)
Collecting six>=1.5 (from python-dateutil==2.8.3.dev33+gf229320->-r tests/requirements.txt (line 6))
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/8ab/b2f1d86890a2d/six-1.16.0-py2.py3-none-any.whl (11 kB)
Collecting cffi~=1.15.1 (from pytest-codspeed~=2.2.0->-r tests/requirements.txt (line 11))
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/944/11f22c3985aca/cffi-1.15.1-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (462 kB)
Collecting filelock~=3.12.2 (from pytest-codspeed~=2.2.0->-r tests/requirements.txt (line 11))
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/08c/21d87ded6e2b9/filelock-3.12.4-py3-none-any.whl (11 kB)
Collecting mypy-extensions>=0.4.3 (from black>=23->pytest-examples==0.0.10->-r tests/requirements.txt (line 14))
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/439/2f6c0eb8a5668/mypy_extensions-1.0.0-py3-none-any.whl (4.7 kB)
Collecting pathspec>=0.9.0 (from black>=23->pytest-examples==0.0.10->-r tests/requirements.txt (line 14))
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/a0d/503e138a4c123/pathspec-0.12.1-py3-none-any.whl (31 kB)
Requirement already satisfied: platformdirs>=2 in ./env/lib64/python3.11/site-packages (from black>=23->pytest-examples==0.0.10->-r tests/requirements.txt (line 14)) (4.2.0)
Collecting pycparser (from cffi~=1.15.1->pytest-codspeed~=2.2.0->-r tests/requirements.txt (line 11))
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/8ee/45429555515e1/pycparser-2.21-py2.py3-none-any.whl (118 kB)
Collecting markdown-it-py>=2.2.0 (from rich>=12->pytest-speed==0.3.5->-r tests/requirements.txt (line 15))
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/355/216845c60bd96/markdown_it_py-3.0.0-py3-none-any.whl (87 kB)
Collecting pygments<3.0.0,>=2.13.0 (from rich>=12->pytest-speed==0.3.5->-r tests/requirements.txt (line 15))
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/b27/c2826c47d0f32/pygments-2.17.2-py3-none-any.whl (1.2 MB)
Collecting mdurl~=0.1 (from markdown-it-py>=2.2.0->rich>=12->pytest-speed==0.3.5->-r tests/requirements.txt (line 15))
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/840/08a41e51615a4/mdurl-0.1.2-py3-none-any.whl (10.0 kB)
Building wheels for collected packages: python-dateutil
Building wheel for python-dateutil (pyproject.toml): started
Building wheel for python-dateutil (pyproject.toml): finished with status 'done'
Created wheel for python-dateutil: filename=python_dateutil-2.8.3.dev33+gf229320-py2.py3-none-any.whl size=78541 sha256=d7e0b776f15454f56276ca921cc5d8d5e1fb95456eaf891b59906d007a55b118
Stored in directory: /home/arnaud/.cache/pip/wheels/c8/bf/d9/05659cade1e93b6b2474d6824f963c0dfd9a402e3561b5686d
Successfully built python-dateutil
Installing collected packages: sortedcontainers, pytz, tzdata, six, ruff, pygments, pycparser, pluggy, pathspec, packaging, numpy, mypy-extensions, mdurl, iniconfig, filelock, dirty-equals, coverage, click, attrs, python-dateutil, pytest, markdown-it-py, hypothesis, cffi, black, rich, pytest-timeout, pytest-mock, pytest-examples, pytest-codspeed, pandas, pytest-speed, pytest-pretty
Attempting uninstall: filelock
Found existing installation: filelock 3.13.1
Uninstalling filelock-3.13.1:
Successfully uninstalled filelock-3.13.1
Successfully installed attrs-23.2.0 black-24.1.1 cffi-1.15.1 click-8.1.7 coverage-7.4.0 dirty-equals-0.7.1.post0 filelock-3.12.4 hypothesis-6.92.9 iniconfig-2.0.0 markdown-it-py-3.0.0 mdurl-0.1.2 mypy-extensions-1.0.0 numpy-1.26.2 packaging-23.2 pandas-2.1.3 pathspec-0.12.1 pluggy-1.4.0 pycparser-2.21 pygments-2.17.2 pytest-7.4.4 pytest-codspeed-2.2.0 pytest-examples-0.0.10 pytest-mock-3.11.1 pytest-pretty-1.2.0 pytest-speed-0.3.5 pytest-timeout-2.2.0 python-dateutil-2.8.3.dev33+gf229320 pytz-2023.3.post1 rich-13.7.0 ruff-0.1.15 six-1.16.0 sortedcontainers-2.4.0 tzdata-2023.4
pip install -r tests/requirements-linting.txt
Looking in indexes: https://artifacts.internal.inmanta.com/inmanta/dev
Collecting griffe==0.38.1 (from -r tests/requirements-linting.txt (line 1))
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/334/c79d3b5964ade/griffe-0.38.1-py3-none-any.whl (1.0 MB)
Collecting pyright==1.1.345 (from -r tests/requirements-linting.txt (line 2))
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/008/91361baf58698/pyright-1.1.345-py3-none-any.whl (18 kB)
Collecting ruff==0.1.13 (from -r tests/requirements-linting.txt (line 3))
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/9a1/600942485c6e6/ruff-0.1.13-py3-none-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (7.5 MB)
Collecting mypy==1.8.0 (from -r tests/requirements-linting.txt (line 4))
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/d19/c413b3c07cbec/mypy-1.8.0-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (12.4 MB)
Collecting colorama>=0.4 (from griffe==0.38.1->-r tests/requirements-linting.txt (line 1))
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/4f1/d9991f5acc0ca/colorama-0.4.6-py2.py3-none-any.whl (25 kB)
Requirement already satisfied: nodeenv>=1.6.0 in ./env/lib64/python3.11/site-packages (from pyright==1.1.345->-r tests/requirements-linting.txt (line 2)) (1.8.0)
Collecting typing-extensions>=4.1.0 (from mypy==1.8.0->-r tests/requirements-linting.txt (line 4))
Using cached https://artifacts.internal.inmanta.com/root/pypi/%2Bf/af7/2aea155e91adf/typing_extensions-4.9.0-py3-none-any.whl (32 kB)
Requirement already satisfied: mypy-extensions>=1.0.0 in ./env/lib64/python3.11/site-packages (from mypy==1.8.0->-r tests/requirements-linting.txt (line 4)) (1.0.0)
Requirement already satisfied: setuptools in ./env/lib64/python3.11/site-packages (from nodeenv>=1.6.0->pyright==1.1.345->-r tests/requirements-linting.txt (line 2)) (65.5.1)
Installing collected packages: typing-extensions, ruff, colorama, pyright, mypy, griffe
Attempting uninstall: ruff
Found existing installation: ruff 0.1.15
Uninstalling ruff-0.1.15:
Successfully uninstalled ruff-0.1.15
Successfully installed colorama-0.4.6 griffe-0.38.1 mypy-1.8.0 pyright-1.1.345 ruff-0.1.13 typing-extensions-4.9.0
pip install -e .
Looking in indexes: https://artifacts.internal.inmanta.com/inmanta/dev
Obtaining file:///tmp/pydantic-core
Installing build dependencies: started
Installing build dependencies: finished with status 'done'
Checking if build backend supports build_editable: started
Checking if build backend supports build_editable: finished with status 'done'
Getting requirements to build editable: started
Getting requirements to build editable: finished with status 'done'
Preparing editable metadata (pyproject.toml): started
Preparing editable metadata (pyproject.toml): finished with status 'done'
Requirement already satisfied: typing-extensions!=4.7.0,>=4.6.0 in ./env/lib64/python3.11/site-packages (from pydantic_core==2.16.1) (4.9.0)
Building wheels for collected packages: pydantic_core
Building editable for pydantic_core (pyproject.toml): started
Building editable for pydantic_core (pyproject.toml): finished with status 'error'
error: subprocess-exited-with-error
× Building editable for pydantic_core (pyproject.toml) did not run successfully.
│ exit code: 1
╰─> [154 lines of output]
Running maturin pep517 build-wheel -i /tmp/pydantic-core/env/bin/python3.11 --compatibility off --editable
📦 Including license file "/tmp/pydantic-core/LICENSE"
🍹 Building a mixed python/rust project
🔗 Found pyo3 bindings
🐍 Found CPython 3.11 at /tmp/pydantic-core/env/bin/python3.11
📡 Using build options features, bindings from pyproject.toml
warning: unused manifest key lints (may be supported in a future version)
  this Cargo does not support nightly features, but if you
  switch to nightly channel you can pass
  `-Zlints` to enable this feature.
     Compiling autocfg v1.1.0
     Compiling proc-macro2 v1.0.76
     Compiling target-lexicon v0.12.9
     Compiling unicode-ident v1.0.10
     Compiling python3-dll-a v0.2.9
     Compiling libc v0.2.147
     Compiling once_cell v1.18.0
     Compiling version_check v0.9.4
     Compiling cfg-if v1.0.0
     Compiling heck v0.4.1
     Compiling static_assertions v1.1.0
     Compiling lexical-util v0.8.5
     Compiling num-traits v0.2.16
     Compiling ahash v0.8.7
     Compiling quote v1.0.35
     Compiling pyo3-build-config v0.20.2
     Compiling syn v2.0.48
     Compiling getrandom v0.2.10
     Compiling lock_api v0.4.10
     Compiling num-integer v0.1.45
     Compiling parking_lot_core v0.9.8
     Compiling zerocopy v0.7.32
     Compiling rustversion v1.0.13
     Compiling memoffset v0.9.0
     Compiling num-bigint v0.4.4
     Compiling scopeguard v1.1.0
     Compiling smallvec v1.11.2
     Compiling allocator-api2 v0.2.16
     Compiling tinyvec_macros v0.1.1
     Compiling tinyvec v1.6.0
     Compiling hashbrown v0.14.3
     Compiling pyo3-ffi v0.20.2
     Compiling pyo3 v0.20.2
     Compiling lexical-write-integer v0.8.5
     Compiling lexical-parse-integer v0.8.6
     Compiling serde v1.0.195
     Compiling memchr v2.6.3
     Compiling lexical-parse-float v0.8.5
     Compiling lexical-write-float v0.8.5
     Compiling unicode-normalization v0.1.22
     Compiling aho-corasick v1.0.2
     Compiling parking_lot v0.12.1
     Compiling pyo3-macros-backend v0.20.2
     Compiling unicode-bidi v0.3.13
     Compiling indoc v2.0.4
     Compiling equivalent v1.0.1
     Compiling serde_json v1.0.109
     Compiling percent-encoding v2.3.1
     Compiling regex-syntax v0.8.2
     Compiling unindent v0.2.3
     Compiling form_urlencoded v1.2.1
     Compiling indexmap v2.0.0
     Compiling idna v0.5.0
     Compiling lexical-core v0.8.5
     Compiling pydantic-core v2.16.1 (/tmp/pydantic-core)
     Compiling ryu v1.0.14
     Compiling serde_derive v1.0.195
     Compiling strum_macros v0.25.3
     Compiling regex-automata v0.4.3
     Compiling pyo3-macros v0.20.2
     Compiling itoa v1.0.8
     Compiling enum_dispatch v0.3.12
     Compiling url v2.5.0
     Compiling strum v0.25.0
     Compiling speedate v0.13.0
     Compiling regex v1.10.2
     Compiling uuid v1.6.1
     Compiling base64 v0.21.7
     Compiling jiter v0.0.6
  error[E0446]: crate-private type `extra::Extra<'_>` in public interface
     --> src/serializers/fields.rs:149:5
      |
  149 | /     pub fn main_to_python<'py>(
  150 | |         &self,
  151 | |         py: Python<'py>,
  152 | |         main_iter: impl Iterator<Item = PyResult<(&'py PyAny, &'py PyAny)>>,
  ...   |
  155 | |         extra: Extra,
  156 | |     ) -> PyResult<&'py PyDict> {
      | |______________________________^ can't leak crate-private type
      |
     ::: src/serializers/extra.rs:73:1
      |
  73  |   pub(crate) struct Extra<'a> {
      |   --------------------------- `extra::Extra<'_>` declared as crate-private

  error[E0446]: crate-private type `extra::Extra<'_>` in public interface
     --> src/serializers/fields.rs:214:5
      |
  214 | /     pub fn main_serde_serialize<'py, S: serde::ser::Serializer>(
  215 | |         &self,
  216 | |         main_iter: impl Iterator<Item = PyResult<(&'py PyAny, &'py PyAny)>>,
  217 | |         expected_len: usize,
  ...   |
  221 | |         extra: Extra,
  222 | |     ) -> Result<S::SerializeMap, S::Error> {
      | |__________________________________________^ can't leak crate-private type
      |
     ::: src/serializers/extra.rs:73:1
      |
  73  |   pub(crate) struct Extra<'a> {
      |   --------------------------- `extra::Extra<'_>` declared as crate-private

  error[E0446]: crate-private type `extra::Extra<'_>` in public interface
     --> src/serializers/fields.rs:260:5
      |
  260 | /     pub fn add_computed_fields_python(
  261 | |         &self,
  262 | |         model: Option<&PyAny>,
  263 | |         output_dict: &PyDict,
  ...   |
  266 | |         extra: &Extra,
  267 | |     ) -> PyResult<()> {
      | |_____________________^ can't leak crate-private type
      |
     ::: src/serializers/extra.rs:73:1
      |
  73  |   pub(crate) struct Extra<'a> {
      |   --------------------------- `extra::Extra<'_>` declared as crate-private

  error[E0446]: crate-private type `extra::Extra<'_>` in public interface
     --> src/serializers/fields.rs:277:5
      |
  277 | /     pub fn add_computed_fields_json<S: serde::ser::Serializer>(
  278 | |         &self,
  279 | |         model: Option<&PyAny>,
  280 | |         map: &mut S::SerializeMap,
  ...   |
  283 | |         extra: &Extra,
  284 | |     ) -> Result<(), S::Error> {
      | |_____________________________^ can't leak crate-private type
      |
     ::: src/serializers/extra.rs:73:1
      |
  73  |   pub(crate) struct Extra<'a> {
      |   --------------------------- `extra::Extra<'_>` declared as crate-private

  For more information about this error, try `rustc --explain E0446`.
  error: could not compile `pydantic-core` (lib) due to 4 previous errors
  💥 maturin failed
    Caused by: Failed to build a native library through cargo
    Caused by: Cargo build finished with "exit status: 101": `env -u CARGO PYO3_ENVIRONMENT_SIGNATURE="cpython-3.11-64bit" PYO3_PYTHON="/tmp/pydantic-core/env/bin/python3.11" PYTHON_SYS_EXECUTABLE="/tmp/pydantic-core/env/bin/python3.11" "cargo" "rustc" "--features" "pyo3/extension-module" "--message-format" "json-render-diagnostics" "--manifest-path" "/tmp/pydantic-core/Cargo.toml" "--release" "--lib" "--crate-type" "cdylib"`
  Error: command ['maturin', 'pep517', 'build-wheel', '-i', '/tmp/pydantic-core/env/bin/python3.11', '--compatibility', 'off', '--editable'] returned non-zero exit status 1
  [end of output]

note: This error originates from a subprocess, and is likely not a problem with pip.
ERROR: Failed building editable for pydantic_core
Failed to build pydantic_core
ERROR: Could not build wheels for pydantic_core, which is required to install pyproject.toml-based projects
make: *** [Makefile:18: install] Error 1

Could someone provide me more insight into what is going wrong here?
System details:

Python version: 3.11.5
Rust version: 1.71.1

@arnaudsjs are you able to try building with latest Rust stable? (Rust 1.75.0 at present.)

I tried building the package with Rust version 1.75.0 and like that the build does work.

I think this change in the rust compiler introduced in v1.74.0 (See also: RFC) is causing the issue.

Because neither AlmaLinux 8 nor AlmaLinux 9 has a newer version of Rust available in the official repositories.

I think we should add an official minimum supported rust-version to our Cargo.toml and also test it in CI. Based on the features that we heavily use in this repository, I suspect that we could make something in the range 1.65 - 1.71 work, with a little effort.
It would likely not be a breaking change so we should be able to ship this as a patch release.
@arnaudsjs @locobastos would either of you be interested in helping create a PR to extend our rust support backwards and guarantee it?
Also, do you know how frequently AlmaLinux updates available Rust version? It would be helpful to know how many versions we should consider lagging current stable by.

This issue also persists with alpine Linux <= 3.19 as it uses Rust 1.72.1-r0. This breaks my builds of a python docker container for the ARMv6 Raspberry Pi platform.
As said above, the last working version is Pydantic 2.5.3 + Pydantic-Core 2.14.6.

Python 3.11.6-r1
Rust 1.72.1-r0

Red Hat is pretty slow to release package because of their aim of the stability. Anyway, here is what I've found on the version history:

Rust 1.47.0
--> Released on 8 October 2020
--> Available in AlmaLinux 8.3 repository on 12 March 2021
--> + 155 days
Rust 1.49.0
--> Release on 31 December 2020
--> Available in AlmaLinux 8.4 repository on 17 April 2021
--> + 107 days
Rust 1.52.1
--> Released on 10 May 2021
--> Available in AlmaLinux 8.4 repository on 11 August 2021
--> + 101 days
Rust 1.54.0
--> Released on 29 July 2021
--> Available in AlmaLinux 8.5 repository on 10 October 2021
--> + 73 days
Rust 1.58.1
--> Released on 20 January 2022
--> Available in AlmaLinux 8.6 repository on 12 April 2022
--> + 82 days
Rust 1.62.1
--> Released on 19 July 2022
--> Available in AlmaLinux 8.7 repository on 13 October 2022
--> + 86 days
Rust 1.66.1
--> Released on 10 January 2023
--> Available in AlmaLinux 8.8 repository on 6 April 2023
--> + 86 days
Rust 1.71.1
--> Released on 3 August 2023
--> Available 18 October 2023
--> + 49 days

It seems they decrease the time between the release date and the availibility date, but I also know that they will release only version they need.

@davidhewitt, I will not have the time to help you. The only one thing I will do, is to try on an AlmaLinux 8 docker container as I'm doing today. I'm not sure I'll have a capital gains on this issue. @arnaudsjs already gave the command to reproduce this issue.

Thanks @locobastos, that table is very helpful 👍

@davidhewitt I won't have the time to work on this. We are currently working around this issue by using the binary wheel instead. We were facing this issue on RockyLinux 8, which is like AlmaLinux, a binary-compatible derivative of RedHat Enterprise Linux. So the above-mentioned table should hold for both AlmaLinux, RockyLinux and RedHat Enterprise Linux.

This is also happening on Alpine, for which no wheels are available.
The latest rust version available there is 1.72, and installing a lot of stuff has recently become impossible, specially if pydantic-core is a build-time dependency.

@BtbN I'm surprised you are finding there are no Alpine wheels, we do build for musllinux.
Can you run pip debug and show the first 10 compatible tags it lists? E.g. for my desktop I get
Compatible tags: 1041
  cp312-cp312-manylinux_2_38_x86_64
  cp312-cp312-manylinux_2_37_x86_64
  cp312-cp312-manylinux_2_36_x86_64
  cp312-cp312-manylinux_2_35_x86_64
  cp312-cp312-manylinux_2_34_x86_64
  cp312-cp312-manylinux_2_33_x86_64
  cp312-cp312-manylinux_2_32_x86_64
  cp312-cp312-manylinux_2_31_x86_64
  cp312-cp312-manylinux_2_30_x86_64
  cp312-cp312-manylinux_2_29_x86_64
  ...
  [First 10 tags shown. Pass --verbose to show all.]

We have a user needing 1.68 in #1202.
To extend back that far we'd need to replace our OnceLock from the std library with the external once_cell crate. Not the end of the world.

Thanks @davidhewitt for pointing me to this issue.
Is there a chance to catch that type of problem earlier, i.e. with some kind of an explicit dependency check before failing with an obscure compile error?

Yes, there is a rust-version key we should set in the Cargo.toml.

Rust 1.75.0
--> Released on 28 December 2023
--> Available since 10 April 2024 on AlmaLinux 8.10
--> + 104 days
This Rust version allows us to build pydantic-core v2.16.3 / pydantic 2.6.4
@davidhewitt

👍 next pydantic-core will have MSRV of 1.75.0

Just a note.
On an AlmaLinux 8.10 with Rust 1.75.0 + Cargo 1.75.0 + Python 3.11.7:
pydantic == 2.5.3            Build OK
└── pydantic_core == 2.14.6  Build OK

pydantic == 2.6.0            Build OK
└── pydantic_core == 2.16.1  Build OK

pydantic == 2.6.1            Build OK
└── pydantic_core == 2.16.2  Build OK

pydantic == 2.6.2            Build OK
└── pydantic_core == 2.16.3  Build OK

pydantic == 2.6.3            Build OK
└── pydantic_core == 2.16.3  Build OK

pydantic == 2.6.4            Build OK
└── pydantic_core == 2.16.3  Build OK

pydantic == 2.7.0            Build OK
└── pydantic_core == 2.18.1  Build FAILED (Need Rust >= 1.76)

pydantic == 2.7.1            Build OK
└── pydantic_core == 2.18.2  Build FAILED (Need Rust >= 1.76)

pydantic == 2.7.2            Build OK
└── pydantic_core == 2.18.3  Build FAILED (Need Rust >= 1.76)

pydantic == 2.7.3            Build OK
└── pydantic_core == 2.18.4  Build FAILED (Need Rust >= 1.76)


Avoid sending extra query request after invalidating the cache.

After I use cache.invalidate, there is an extra query request sent that I would like to avoid.
I have the following query in my app:
query($pageId: Int!) {
  page(pageId: $pageId) {
    id
    title
    modules {
      id
      type
      config
    }
  }
}

After I delete the module, I would like  to update the cache optimistically:
cacheExchange({
  schema: introspection,
  optimistic: {
    removeModule: ({ moduleId }, cache) => {
      cache.invalidate({ __typename: "Module", id: moduleId })
    }
  },
}),

But the problem is, when I delete a module, a new request is sent to fetch the page again. I've seen in docs, that using cache.invalidate may lead to additional request unless I use schema awareness. But in my case, I use schema awareness and the request is still sent.
Here it is my schema definition for the additional context:
type Page {
  id: Int!
  title: String!
  modules: [Module!]!
}

type Module {
  id: Int!
  type: ModuleType
  config: JSONObject!
}

extend type Mutation {
  removeModule(moduleId: Int!): Boolean
}

I assume, that it may happen because module list element type is marked as required in the modules field definition - [Module!]!, but if I make it optional([Module]!), I get null value in the array after invalidation which is undesired behavior as well.
Any way I can make the required item to disappear from the array without making an additional request since I exactly know what's the schema should look like without making a new query?
Best wishes

If you are using schema-awareness and you are seeing an additional request that means your graphql schema is saying that a module is not nullable. Which is the case modules: [Module!]! the ! after Module means that it isn't nullable.

@aiven715 It would be very nice and useful to have a reproduction of the problem on codesandbox.

@frederikhors I don't believe that's necessary as it's documented behaviour :+1:
So yes again, you're completely right in that invalidating an item in a list while using schema awareness will set the item to null without an additional request if it is indeed nullable. But if it can't be set to null then the "missing data" cascades upward. The list can't be null (which would be undesirable anyway) and the Page can't be null, and so on...
Either way, you'd be missing data, so an additional request would be made. That almost always happens with cache.invalidate. It deletes data, which means that whatever the outcome is, Graphcache is likely going to acknowledge that data is missing and will issue a request. The difference is what it does in the meantime, and with schema awareness it can still serve partial data to bridge the gap.
But you're still advised to update lists manually in most cases if you want the correct result to be displayed without an additional request.

@aiven715 Yes, an optimistic update is tentative until the mutation completes. Under the hood this is a layer on top of the entity so it can have temporary attributes. When a response comes in we delete this layer, this way when there's an error we have no issues later on with inconsistent data, ....
Because optimistic and updates have the same semantics you should be able to reuse the function body but have a different signature:
const optimistic = ({ moduleId }, cache) => action(moduleId, cache)
const updater = (result, args, cache, info) => action(args.moduleId, cache)

const action = the body of your current func

Works perfectly, the issue is resolved, thanks!

Just a quick note; the updater will also run for optimistic updates (as long as there's an optimistic function to provide this update), so you can also just return true there and do the removal from the list only in updates :)

That's outstanding, so I don't even need to duplicate the code. Perfect!


Add missing mixins annotations

Fixes #401

This change is

Reviewed 2 of 2 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved, some commit checks failed.

Comments from Reviewable


Allow using a composite build as a source dependency

https://github.com/gradle/gradle/pull/5890 adds support for nested included builds. However, this does not yet work for source dependencies. We should add support for using a composite build as a source dependency.

I'm confused on what this means:

add support for using a composite build as a source dependency

How can you create a composite build using composite builds that are not source dependencies? If your PR doesn't allow for composite of composite projects, then what exactly does it do? Does it allow for nesting of project like this answer describes?

If I'm not mistaken this is adding support for nested composite builds as part of a new feature not yet announced called source dependencies. You can see an example of how this works in the native samples.

Correct, the dependency substitution should work correctly with nested included build outside of VCS. If it doesn't work, open an issue so we can look into it.


Added Ukrainian localization

Thanks. Will merge next week

Please try.
-Uninstall
-Remove .zip and install
app-release.apk.zip

sorry, but i forgot to translate 71 line of the help file. please replace "basic arithmetic" with "базова арифметика".


[2.0.0-beta.7] WSL on Windows write permissions issue with ./craft migrate/create

Description
I don't think this is specific to Nitro, more likely the Docker layer as I know this happens on Docker generally as well. WSL in particularly struggles with the permissions setup due to the Docker container using www-data. This makes commands that perform write actions like ./craft migrate/create fail.
/app $ ./craft migrate/create test
Yii Migration Tool (based on Yii v2.0.40)

Create new migration '/app/migrations/m210302_111825_test.php'? (yes|no) [no]:yes
PHP Warning 'yii\base\ErrorException' with message 'file_put_contents(/app/migrations/m210302_111825_test.php): failed to open stream: Permission denied'

in /app/vendor/craftcms/cms/src/helpers/FileHelper.php:377

Stack trace:
#0 {main}

This happens with nitro ssh or nitro craft. The only solution I know of related to Docker, is using docker exec with the user context.
docker exec --user 1000:1000 -it container_name /bin/sh

Then running ./craft migrate/create, which will work because of user context being different.
I'm not sure there is a easy solution to this, but just for info.

@jamesmacwhite can you try running php craft migrate/create test instead of using the ./ syntax?

Same with using php command format, trying with nitro ssh. Ultimately this a docker level issue I believe. I'm not sure what the permissions situation is like on real unix i.e. macOS and Linux hosts, but it's mostly down the user context in the container I believe, having --user 1000:1000 when using docker exec works. However for most operations you don't need to set this.

Can you perform an ls -la on the WSL2 terminal and with the nitro ssh command and provide the output here?

/app $ ls -la
total 1240
drwxr-xr-x   20 1000     1000          4096 Mar  1 15:12 .
drwxr-xr-x    1 root     root          4096 Mar  2 09:31 ..
-rw-r--r--    1 1000     1000           380 Jan 10 10:43 .babelrc
-rw-r--r--    1 1000     1000            55 Jan 10 10:43 .browserslistrc
drwxr-xr-x    7 1000     1000          4096 Mar  1 15:12 .docker-config
-rw-r--r--    1 1000     1000           657 Jan 10 10:43 .editorconfig
-rw-r--r--    1 1000     1000          1114 Feb 26 18:05 .env
-rw-r--r--    1 1000     1000          5099 Mar  1 15:12 .env.example
-rw-r--r--    1 1000     1000          2404 Mar  1 14:52 .env.production.example
-rw-r--r--    1 1000     1000            23 Jan 10 10:43 .eslintignore
-rw-r--r--    1 1000     1000           710 Jan 10 10:43 .eslintrc.js
drwxr-xr-x    8 1000     1000          4096 Mar  2 10:40 .git
-rwxr-xr-x    1 1000     1000          1263 Feb 22 14:24 .gitignore
drwxr-xr-x    3 1000     1000          4096 Mar  2 18:53 .idea
-rw-r--r--    1 1000     1000          2150 Jan 10 10:43 .snyk
-rw-r--r--    1 1000     1000          5213 Mar  1 15:12 README.md
-rwxr-xr-x    1 1000     1000             9 Jan 10 10:43 VERSION
drwxr-xr-x    9 1000     1000          4096 Jan 10 10:43 assets
drwxr-xr-x    4 1000     1000          4096 Feb 26 13:10 build
-rwxrwxrwx    1 1000     1000          4148 Feb 22 18:01 composer.json
-rwxr-xr-x    1 1000     1000        525655 Mar  1 14:52 composer.lock
drwxr-xr-x    7 1000     1000          4096 Mar  1 14:52 config
-rwxr-xr-x    1 1000     1000           623 Jan 11 11:37 craft
-rw-r--r--    1 1000     1000           330 Jan 10 10:43 craft.bat
drwxr-xr-x    2 1000     1000          4096 Feb 23 16:38 data
-rw-r--r--    1 1000     1000          1378 Mar  1 15:12 docker-compose.yml
-rw-r--r--    1 1000     1000          4023 Jan 10 10:43 fractal.config.js
drwxr-xr-x    2 1000     1000          4096 Mar  2 11:24 migrations
drwxr-xr-x   10 1000     1000          4096 Jan 10 10:43 modules
drwxr-xr-x 1280 1000     1000         36864 Jan 23 15:06 node_modules
-rw-r--r--    1 1000     1000          2802 Jan 23 15:06 package.json
drwxr-xr-x    5 1000     1000          4096 Jan 10 10:43 redirects
drwxr-xr-x    2 1000     1000          4096 Jan 10 10:43 scripts
-rw-r--r--    1 1000     1000          2554 Feb 19 17:03 secrets.json
-rw-r--r--    1 1000     1000          1162 Feb 20 14:22 secrets.json.example
drwxrwxrwx    9 1000     1000          4096 Feb 18 15:18 storage
drwxr-xr-x    7 1000     1000          4096 Feb  3 22:58 styleguide
drwxr-xr-x   23 1000     1000          4096 Mar  1 14:52 templates
drwxr-xr-x    3 1000     1000          4096 Jan 10 10:43 translations
drwxrwxrwx  105 1000     1000          4096 Mar  1 12:32 vendor
drwxr-xr-x    4 1000     1000          4096 Mar  2 10:12 web
-rw-r--r--    1 1000     1000        526787 Jan 23 15:06 yarn.lock

Does it show the same user and group when running the ls -la command in WSL2?

No it will be under the WSL user so in my case jameswhite:jameswhite

https://user-images.githubusercontent.com/8067792/109705960-48186f00-7b90-11eb-8e1d-87e377e1539d.mp4
Quick demo with a shell. I use Windows Terminal because of it's full Unicode support (so emojis show up!), rather than a plain WSL bash terminal. It doesn't matter for this, as the error is coming from PHP I believe.

Hmm ok, there might be an easier way to detect this going forward. We can set the user here: https://github.com/craftcms/nitro/blob/main/command/ssh/ssh.go#L169
It defaults to www-data or if you pass the --root flag it will use the root user. We might be able to detect is this is linux/WSL and switch it to the 1000 user/group (you are right that is the www-data user in the docker image).

Could be an option, although, I'm not fully aware of the ramifications setting the user context for the overall container interaction i.e. nitro ssh. I assume this is specific to WSL2 because of the Docker WSL integration, so I wouldn't want to pollute Nitro with Windows hacks. I know this happens with vanilla Docker containers too through WSL.
This might need a bit more investigation, I'm not sure running the container under that user context works for everything and might not be the best idea, if it starts to modify permissions of other elements and cause issues.
Example, after running composer update under the --user 1000:1000
> @php craft clear-caches/all
Clearing cache: Asset caches
Clearing cache: Asset indexing data
Clearing cache: Asset transform index
Clearing cache: Compiled templates
Could not clear the directory Compiled templates: rmdir(/app/storage/runtime/compiled_templates/49): Directory not empty
Clearing cache: Control panel resources
Error clearing cache Control panel resources: rmdir(/app/web/cpresources/69cd9a2a): Directory not empty
Clearing cache: Data caches
Clearing cache: Imager image transform cache
Clearing cache: Imager remote images cache
Clearing cache: Retour redirect caches
Clearing cache: SEOmatic frontend template caches
Clearing cache: SEOmatic metadata caches
Clearing cache: SEOmatic sitemap caches
Clearing cache: Temp files
Clearing cache: Twitter caches
Could not clear the directory Twitter caches: rmdir(/app/storage/runtime/twitter/userimages/49967368/96): Permission denied
Clearing cache: Videos caches

For the most part the way it is now works for most actions, I think you hit this when a write is attempted within the /app path by PHP.

Just released 2.0.7 with better support on Linux and WSL2 machines.


Connector will stop parsing files at 20mo

I've been using file pulse for a while now and it was working really well for our usecases (many thanks !)
I'm currently encountering an issue with a csv file where it stops sending record at ling 86850 (at about 20 mo)
I have checked the line where it stopped and it is not malformed in any way.
There's no stacktrace in the logs (in fact in goes on about no records being produced).
Just before stopping producing records I have :
A message produced in the connect status topic :
{"position":19116435,"rows":86851,"timestamp":1644512304203}

And an other in the file pulse status topic :
{
  metadata: {
    uri: "gcs://some_folder/file.csv",
    name: file.csv",
    contentLength: 38342440,
    lastModified:<PHONE_NUMBER>831,
    contentDigest: {
      digest: "M47ZqA==",
      algorithm: "CRC32"
    },
    userDefinedMetadata: {
      gcs.blob.bucket: "some_bucket",
      gcs.blob.storageClass: "STANDARD",
      gcs.blob.name: "some_file.csv",
      gcs.blob.createTime:<PHONE_NUMBER>831,
      gcs.blob.contentType: "text/csv",
      gcs.blob.etag: "COCm8avh8/UCEAE="
    }
  },
  offset: {
    position: 19115848,
    rows: 86848,
    timestamp:<PHONE_NUMBER>200
  },
  status: "READING"
}

Any idea about what could be the issue ?
Does filepulse have a limit on the size of the file its parsing ?
Thanks !

Hi @lucas-dclrcq, FilePulse does not have a limit on the file size. This problem may be coming from the GCP connection, if you manage to reproduce this problem, it would be interesting to enable the log DEBUG level to see if there is a network problem.


Django runserver error

these error are occurred after the command 'python manage.py runserver'
Traceback (most recent call last):
File "C:\python\pycharm\projects\web\venv\lib\site-packages\django\core\management\base.py", line 328, in run_from_argv
self.execute(*args, **cmd_options)
File "C:\python\pycharm\projects\web\venv\lib\site-packages\django\core\management\commands\runserver.py", line 60, in execute
super().execute(*args, **options)
File "C:\python\pycharm\projects\web\venv\lib\site-packages\django\core\management\base.py", line 369, in execute
output = self.handle(*args, **options)
File "C:\python\pycharm\projects\web\venv\lib\site-packages\django\core\management\commands\runserver.py", line 67, in handle
if not settings.DEBUG and not settings.ALLOWED_HOSTS:
File "C:\python\pycharm\projects\web\venv\lib\site-packages\django\conf_init_.py", line 76, in getattr
self.setup(name)
File "C:\python\pycharm\projects\web\venv\lib\site-packages\django\conf_init.py", line 63, in setup
self.wrapped = Settings(settings_module)
File "C:\python\pycharm\projects\web\venv\lib\site-packages\django\conf_init.py", line 142, in init
mod = importlib.import_module(self.SETTINGS_MODULE)
File "C:\python\lib\importlib_init.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1006, in _gcd_import
File "", line 983, in _find_and_load
File "", line 953, in _find_and_load_unlocked
File "", line 219, in _call_with_frames_removed
File "", line 1006, in _gcd_import
File "", line 983, in _find_and_load
File "", line 965, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'src'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "manage.py", line 20, in
main()
File "manage.py", line 16, in main
execute_from_command_line(sys.argv)
File "C:\python\pycharm\projects\web\venv\lib\site-packages\django\core\management_init_.py", line 401, in execute_from_command_line
utility.execute()
File "C:\python\pycharm\projects\web\venv\lib\site-packages\django\core\management_init_.py", line 395, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "C:\python\pycharm\projects\web\venv\lib\site-packages\django\core\management\base.py", line 341, in run_from_argv
connections.close_all()
File "C:\python\pycharm\projects\web\venv\lib\site-packages\django\db\utils.py", line 225, in close_all
for alias in self:
File "C:\python\pycharm\projects\web\venv\lib\site-packages\django\db\utils.py", line 219, in iter
return iter(self.databases)
File "C:\python\pycharm\projects\web\venv\lib\site-packages\django\utils\functional.py", line 48, in get
res = instance.dict[self.name] = self.func(instance)
File "C:\python\pycharm\projects\web\venv\lib\site-packages\django\db\utils.py", line 153, in databases
self.databases = settings.DATABASES
File "C:\python\pycharm\projects\web\venv\lib\site-packages\django\conf_init.py", line 76, in getattr
self.setup(name)
File "C:\python\pycharm\projects\web\venv\lib\site-packages\django\conf_init.py", line 63, in setup
self.wrapped = Settings(settings_module)
File "C:\python\pycharm\projects\web\venv\lib\site-packages\django\conf_init.py", line 142, in init
mod = importlib.import_module(self.SETTINGS_MODULE)
File "C:\python\lib\importlib_init.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1006, in _gcd_import
File "", line 983, in _find_and_load
File "", line 953, in _find_and_load_unlocked
File "", line 219, in _call_with_frames_removed
File "", line 1006, in _gcd_import
File "", line 983, in _find_and_load
File "", line 965, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'src'

It could be that DJANGO_SETTINGS_MODULE is incorrect. It appears in the manage.py file as well as in the .pyproj, I'm not sure of the exact situation when the one in the .pyproj applies. You should check that they match, and that it is correct. The module is resolved from the root folder of your project.
Given this project structure, this works (on Django 2.2):

And from the .pyproj:
    <DjangoSettingsModule>DjangoWebProject2.settings</DjangoSettingsModule>

If this is still a problem, please reopen an issue, ideally with steps to repro. Thanks!


View older versions of docs on https://airbnb.io/enzyme/

Is your feature request related to a problem? Please describe.
I'm using version 3.1.1 of enzyme, and it'd be nice to view the docs for that version so I know I won't run into issues or things being outdated. I know I can find the docs on github, but the website is much easier to navigate.
Describe the solution you'd like
Being able to select the version of the docs you want to view on the website.
Describe alternatives you've considered
Keeping a bookmark to the older version of the docs (which I'm not sure if it's even right). https://github.com/airbnb/enzyme/tree/enzyme%403.1.1/docs

At the moment, only the latest version is available.
Duplicate of #860.


How would I use signals for a bigger form?

I want to use an signals-object to keep track of the state for a multistep form. I asked Copilot and it suggests this approach:

class FormData {
  String name;
  String email;

  FormData({required this.name, required this.email});
}

class MyForm extends StatefulWidget {
  @override
  _MyFormState createState() => _MyFormState();
}

class _MyFormState extends State<MyForm> {
  final _formKey = GlobalKey<FormState>();
  final _formDataSignal = Signal<FormData>(initialValue: FormData(name: '', email: ''));

  @override
  Widget build(BuildContext context) {
    return Form(
      key: _formKey,
      child: Column(
        children: <Widget>[
          TextFormField(
            onChanged: (value) => _formDataSignal.value = FormData(name: value, email: _formDataSignal.value.email),
            validator: (value) {
              if (value == null || value.isEmpty) {
                return 'Please enter some text';
              }
              return null;
            },
          ),
          TextFormField(
            onChanged: (value) => _formDataSignal.value = FormData(name: _formDataSignal.value.name, email: value),
            validator: (value) {
              if (value == null || value.isEmpty) {
                return 'Please enter some text';
              }
              return null;
            },
          ),
          ElevatedButton(
            onPressed: () {
              if (_formKey.currentState.validate()) {
                ScaffoldMessenger.of(context).showSnackBar(
                  SnackBar(content: Text('Processing Data')),
                );
              }
            },
            child: Text('Submit'),
          ),
        ],
      ),
    );
  }
}

I don't like this part if the form is big having to reassign values:
 onChanged: (value) => _formDataSignal.value = FormData(name: _formDataSignal.value.name, email: value)

Do you have any other suggestion that is better for such a use-case?

I want to break out each form step inte separate Widgets. Not sure if I should keep the state object as global or pass it to each form step as argument. If passing as argument does the reactivity remain for rebuilds?

How about this?
final _nameSignal = signal('');
final _emailSignal = signla('');
final _formDataSignal = computed(() => FormData(name: _nameSignal(), email: _emailSignal()));

You could also use a map signal too!


Fix handling for KUBECONFIG env var

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

8 of 8 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-1.04%) to 56.012%

Totals

Change from base Build<PHONE_NUMBER>:
-1.04%

Covered Lines:
2017

Relevant Lines:
3601

💛  - Coveralls


keepassxc: 2.2.4 -> 2.3.0

Motivation for this change
HN-driven development. https://news.ycombinator.com/item?id=16483722
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Fits CONTRIBUTING.md.

Failure on x86_64-darwin (full log)
Partial log (click to expand)
Package ‘libargon2-20171227’ in /Users/graham/nix-borg/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/grahamc-ndnd/pkgs/development/libraries/libargon2/default.nix:28 is not supported on ‘x86_64-darwin’, refusing to evaluate.

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowBroken = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowBroken = true; }
to ~/.config/nixpkgs/config.nix.

@GrahamcOfBorg build keepassxc

Success on x86_64-linux (full log)
Partial log (click to expand)
shrinking /nix/store/qn9z5y9j9q6qi7czpckrjv2r5sdhb36l-keepassxc-2.3.0/bin/keepassxc-cli
shrinking /nix/store/qn9z5y9j9q6qi7czpckrjv2r5sdhb36l-keepassxc-2.3.0/bin/keepassxc
shrinking /nix/store/qn9z5y9j9q6qi7czpckrjv2r5sdhb36l-keepassxc-2.3.0/lib/keepassxc/libkeepassx-autotype-xcb.so
gzipping man pages under /nix/store/qn9z5y9j9q6qi7czpckrjv2r5sdhb36l-keepassxc-2.3.0/share/man/
strip is /nix/store/b0zlxla7dmy1iwc3g459rjznx59797xy-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/qn9z5y9j9q6qi7czpckrjv2r5sdhb36l-keepassxc-2.3.0/lib  /nix/store/qn9z5y9j9q6qi7czpckrjv2r5sdhb36l-keepassxc-2.3.0/bin
patching script interpreter paths in /nix/store/qn9z5y9j9q6qi7czpckrjv2r5sdhb36l-keepassxc-2.3.0
checking for references to /tmp/nix-build-keepassxc-2.3.0.drv-0 in /nix/store/qn9z5y9j9q6qi7czpckrjv2r5sdhb36l-keepassxc-2.3.0...
postPatchMkspecs
postPatchMkspecs

Failure on x86_64-darwin (full log)
Partial log (click to expand)
/nix/store/9avjr40zgds5rycm2ndw9imrfpkb3vga-CF-osx-10.10.5-private/Library/Frameworks/CoreFoundation.framework/Headers/CFUserNotification.h:123:78: error: use of old-style cast [-Werror,-Wold-style-cast]
CF_INLINE CFOptionFlags CFUserNotificationPopUpSelection(CFIndex n) {return ((CFOptionFlags)(n << 24));}
                                                                             ^              ~~~~~~~~~
11 errors generated.
make[2]: *** [src/CMakeFiles/keepassx_core.dir/build.make:519: src/CMakeFiles/keepassx_core.dir/core/ScreenLockListenerPrivate.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [CMakeFiles/Makefile2:197: src/CMakeFiles/keepassx_core.dir/all] Error 2
make: *** [Makefile:163: all] Error 2
builder for '/nix/store/khvf1asxnjlrrk1pa5gjip43g2y01xp6-keepassxc-2.3.0.drv' failed with exit code 2
error: build of '/nix/store/khvf1asxnjlrrk1pa5gjip43g2y01xp6-keepassxc-2.3.0.drv' failed

Success on x86_64-linux (full log)
Partial log (click to expand)
shrinking /nix/store/qn9z5y9j9q6qi7czpckrjv2r5sdhb36l-keepassxc-2.3.0/bin/keepassxc-cli
shrinking /nix/store/qn9z5y9j9q6qi7czpckrjv2r5sdhb36l-keepassxc-2.3.0/bin/keepassxc
shrinking /nix/store/qn9z5y9j9q6qi7czpckrjv2r5sdhb36l-keepassxc-2.3.0/lib/keepassxc/libkeepassx-autotype-xcb.so
gzipping man pages under /nix/store/qn9z5y9j9q6qi7czpckrjv2r5sdhb36l-keepassxc-2.3.0/share/man/
strip is /nix/store/b0zlxla7dmy1iwc3g459rjznx59797xy-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/qn9z5y9j9q6qi7czpckrjv2r5sdhb36l-keepassxc-2.3.0/lib  /nix/store/qn9z5y9j9q6qi7czpckrjv2r5sdhb36l-keepassxc-2.3.0/bin
patching script interpreter paths in /nix/store/qn9z5y9j9q6qi7czpckrjv2r5sdhb36l-keepassxc-2.3.0
checking for references to /tmp/nix-build-keepassxc-2.3.0.drv-0 in /nix/store/qn9z5y9j9q6qi7czpckrjv2r5sdhb36l-keepassxc-2.3.0...
postPatchMkspecs
postPatchMkspecs

Success on x86_64-linux (full log)
Partial log (click to expand)
/nix/store/qn9z5y9j9q6qi7czpckrjv2r5sdhb36l-keepassxc-2.3.0
/nix/store/31rjpj51sv2vs1h6402qa5f4yrdy7shd-libargon2-20171227

Failure on x86_64-darwin (full log)
Partial log (click to expand)
                                                                              ^              ~~~~~~~~~~~~~~~~~
/nix/store/9avjr40zgds5rycm2ndw9imrfpkb3vga-CF-osx-10.10.5-private/Library/Frameworks/CoreFoundation.framework/Headers/CFUserNotification.h:123:78: error: use of old-style cast [-Werror,-Wold-style-cast]
CF_INLINE CFOptionFlags CFUserNotificationPopUpSelection(CFIndex n) {return ((CFOptionFlags)(n << 24));}
                                                                             ^              ~~~~~~~~~
11 errors generated.
make[2]: *** [src/CMakeFiles/keepassx_core.dir/build.make:519: src/CMakeFiles/keepassx_core.dir/core/ScreenLockListenerPrivate.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:197: src/CMakeFiles/keepassx_core.dir/all] Error 2
make: *** [Makefile:163: all] Error 2
builder for '/nix/store/y84iiclw5a954g9pqb101fj1a12cfh4f-keepassxc-2.3.0.drv' failed with exit code 2
error: build of '/nix/store/y84iiclw5a954g9pqb101fj1a12cfh4f-keepassxc-2.3.0.drv' failed

Is the browser extension build by default?

I would suggest to disable KeePassHTTP by default:
CMake Warning at CMakeLists.txt:53 (message):
  KeePassHTTP support has been deprecated and will be removed in a future
  version.  Please use WITH_XC_BROWSER instead!
  For enabling / disabling network access code, WITH_XC_HTTP has been
  replaced by WITH_XC_NETWORKING.

Failure on aarch64-linux (full log)
Partial log (click to expand)
[ 72%] Built target testcsvparser_autogen
[ 73%] Built target testcsvparser
[ 74%] Automatic MOC, UIC and RCC for target testmerge
[ 74%] Built target testmerge_autogen
[ 74%] Built target testmerge
[ 74%] Automatic MOC, UIC and RCC for target testkdbx4
[ 74%] Built target testkdbx4_autogen
[ 76%] Built target testkdbx4
building of '/nix/store/nzdknsyi8pjfj8j20kkcmqrwbjz1wfx6-keepassxc-2.3.0.drv' timed out after 3600 seconds
error: build of '/nix/store/nzdknsyi8pjfj8j20kkcmqrwbjz1wfx6-keepassxc-2.3.0.drv' failed

Success on aarch64-linux (full log)
Partial log (click to expand)
shrinking /nix/store/dmz3w56np3bxnq6im850rvxlf5z88qzg-keepassxc-2.3.0/bin/keepassxc-cli
shrinking /nix/store/dmz3w56np3bxnq6im850rvxlf5z88qzg-keepassxc-2.3.0/bin/keepassxc
gzipping man pages under /nix/store/dmz3w56np3bxnq6im850rvxlf5z88qzg-keepassxc-2.3.0/share/man/
strip is /nix/store/lvx1acn1ig1j2km8jds5x3ggh3f2wa8v-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/dmz3w56np3bxnq6im850rvxlf5z88qzg-keepassxc-2.3.0/lib  /nix/store/dmz3w56np3bxnq6im850rvxlf5z88qzg-keepassxc-2.3.0/bin
patching script interpreter paths in /nix/store/dmz3w56np3bxnq6im850rvxlf5z88qzg-keepassxc-2.3.0
checking for references to /build in /nix/store/dmz3w56np3bxnq6im850rvxlf5z88qzg-keepassxc-2.3.0...
postPatchMkspecs
postPatchMkspecs
/nix/store/dmz3w56np3bxnq6im850rvxlf5z88qzg-keepassxc-2.3.0

Success on aarch64-linux (full log)
Partial log (click to expand)
these derivations will be built:
  /nix/store/nib871al02lnyy991iixwy2jz4crsqki-source.drv
  /nix/store/nzdknsyi8pjfj8j20kkcmqrwbjz1wfx6-keepassxc-2.3.0.drv
waiting for locks or build slots...
/nix/store/dmz3w56np3bxnq6im850rvxlf5z88qzg-keepassxc-2.3.0
/nix/store/jf03y908hmc8qd6zljampzvapwmvycn3-libargon2-20171227

@jonafato can you take over? I'm probably not going to finish this

@zimbatm See #36281.


LGTM to RFM label github bot

We have Looks Good To Me system in many repos, it would be great to have a bot that would remove needs review tag from the issues (possibly configurable) and adding RFM (also configurable). If someone from the team writes LGTM at the begging of comment (so comments like that "Apart from ... LGTM" don't have their labels changed).
@RichardLitt

Also it would be nice if there was possibility of it waiting for two people to SMGT (Seems Good To Me)

It would also be good to have a bot to automatically update links in READMEs. Discussed briefly here: https://github.com/dignifiedquire/aegir/pull/53#event-779298476.

Bot to remove the "needs review" tag is fine, though I think in general
it won't be always clear: some things need more than 1 "LGTM" because it's
a big important change or involves multiple people. Maybe it could parse
something like:

RFC @jbenet @whyrusleeping

Which would assign those two people, and then:

unassign them when they have "LGTM"
remove "Needs Review" when all have LGTMed
re-assign the original author.

Also:

Please no bots ever saying RFM. That is an explicit action that should
have responsibility of devs calling it. Critical to avoid problems.

On Tue, Sep 6, 2016 at 6:41 PM Richard Littauer<EMAIL_ADDRESS>wrote:

It would also be good to have a bot to automatically update links in
READMEs. Discussed briefly here: dignifiedquire/aegir#53 (comment)
https://github.com/dignifiedquire/aegir/pull/53#event-779298476.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ipfs/community/issues/138#issuecomment-245011523, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAIcoSca81UxdRCrDR3W0C1d-ytQhhEFks5qnZefgaJpZM4I58TU
.


Shift in Navigation Text on 'fixedHeader' class animation on displays @ < 1450

This has been corrected.


feat(wrpc): Add support for interface linking and storing component specifications

Feature or Problem
This PR introduces mostly backwards compatible changes (new public member in control interface may be considered breaking, new functionality in RPC isn't documented but could alter behavior) to support both actor component interface linking and storing component specifications in the LATTICEDATA bucket.
This is designed in a way that we can make incremental progress towards a full wRPC implementation but does not alter the test functionality. Because of this, it's not recommended to merge this to main until we can release v0.82 after #1478.
Related Issues
Partially implements #1389
Release Information
v1.0.0
Consumer Impact

Testing
No tests were modified for this PR as the point is to get some of the plumbing for wRPC components implemented without modifying today's functionality.
Unit Test(s)

Acceptance or Integration

Manual Verification
To test this PR, I went through a few manual steps to ensure that a component could receive a message on its wRPC topic and send a wasmbus Invocation out on a wRPC topic.
# Start the example component from our quickstart
wash start actor file:///Users/brooks/github.com/wasmcloud/wasmCloud/examples/rust/actors/http-hello-world/build/http_hello_world_s.wasm --skip-wait --max 5
# Interface link the component to another component for its keyvalue calls
nats req 'wasmbus.ctl.default.linkdefs.wrpc' '{"source_id": "http_hello_world", "target": "wasmcloud_azurecr_io_kvredis_0_19_0", "package": "wasi:keyvalue", "interfaces": ["atomic", "readwrite"]}'
# Send request to wRPC topic
nats req "default.http_hello_world.wrpc.0.0.1.wasi:http/incoming-handler.handle" 'hello'

In another terminal, subscribing on *.*.wrpc.> will show you:
[#13] Received on "default.wasmcloud_azurecr_io_kvredis_0_19_0.wrpc.0.0.1.wasi:keyvalue/atomic.increment" with reply "_INBOX.NEqcFNu6SQ8Ka2NYvMhMSF.NEqcFNu6SQ8Ka2NYvMhMYt"
originpublic_key8MDMIKQQUBEQ7XROPNV4C2EXDU6MWFXWYGLYKTQNPMG4QMAK37K3KQIZ6link_namecontract_idtargetpublic_key#wasmcloud_azurecr_io_kvredis_0_19_0link_namedefaultcontract
......

This testing was done using the commented-out functionality to set the component_id to a sanitized version of the OCI reference, which is similar to what wash or wadm may do in the future. What this does show is that a component can receive an invocation on a wRPC topic and the inner component plumbing can properly resolve a target based on the Wasm interface call.

Just a note that this PR includes a few TODOs where this functionality is implemented but either commented out or not normally accessible with existing APIs to ensure tests work as expected. Should still merge after 0.82


/validate endpoint throwing a datadog tracer error

Why is this issue important?
Awaiting a deployment to production and the functionality is not passing QA
Current State
When a user uploads or validates a workbook, they are receiving a 503 error
{"error":"tracer.tracer is not a function"}
Expected State
When a user uploads or validates a workbook, they will not receive an error
Implementation Plan
No response
Relevant Code Snippets
No response

https://github.com/usdigitalresponse/usdr-gost/pull/1732/files#r1291753788

Error trace in Datadog, here (screenshot below).
The actual issue appears to be a teeny tiny typo – there's a call to tracer.tracer() that should be tracer.trace():
https://github.com/usdigitalresponse/usdr-gost/blob/e1710100b1d4b1bb82845fdfd8208f01b0164135/packages/server/src/arpa_reporter/services/persist-upload.js#L233


Windows support

Hi, I'd like to implement this library in a cross-platform app for Windows and Mac.
Could it be possible to build the source code for Windows as it is now, or it would require some work on the code?

Yes, it can work with Windows provided that all the dependencies are compiled for it and updated "third_party" directory to use correct tarballs.


For-in does not work with arrays/dynamic arrays

Hi, great work on this project!  I found a bug while trying to iterating through dynamic arrays with the for-in statement.  The following should output two lines "Child 1" and "Child 2" but it outputs empty strings.
program ArrayForIn;

uses
  Sempare.Template;

type
  TMember = record
    Name: String;
  end;

  TParent = record
    Members: TArray<TMember>;
  end;

begin
    var tpl := Template.Parse(
       '<% for member in members %>'+#13#10+
         '<% member.name %>'+
       '<% end %>');

    var parent: TParent;

    SetLength(parent.Members, 2);
    parent.Members[0].Name := 'Child 1';
    parent.Members[1].Name := 'Child 2';

    writeln(Template.Eval(tpl, parent));

    Readln;
end.

Thank you. I’ll have a look. I thought that was covered by a test. I’ll investigate.

Ah you're right here it is:
procedure TTestTemplateArr.TestDynArray;
var
  a: tarray<integer>;
  i: integer;
begin
  setlength(a, 5);
  for i := Low(a) to High(a) do
    a[i] := i * 2;
  Assert.AreEqual('0 2 4 6 8 ', Template.Eval('<%for i in _%><% _[i]%> <%end%>', a));
end;

It looks like it was intentional for i to be the index into the array, rather than the element value.  I had assumed it was a bug because it wasn't documented how it works, but I can understand how changing the behavior now would be a breaking change and likely frustrate others.
It looks like you may have modeled this behavior on Javascript.  Would you consider adding a new syntax for-of?  Example:
  Assert.AreEqual('0 2 4 6 8 ', Template.Eval('<%for value of _%><% value %> <%end%>', a));

I had some time to think about it... Did a quick test on Dictionary, and realised that the 'for x in dict' actually returns a pair<key, value> when enumerating, so not what I was thinking above.
when I ran all the unit tests, the fix did fail. One way is to introduce the support as you described with the 'of'.  Another is using a feature flag, like using the context options where an option like eoForInArrayWithValues could be set. Using 'of' may be easier to use rather than requiring context config to be setup and passed, so am not opposed to the idea you suggested, and it should be fairly trivial to include.

Sure, a context flag is a good idea too.  I think I prefer the of syntax, so that there isn't a need to go back through existing templates to be compatible with the new behavior.  But it's not that important, so either option is great.  Thanks for considering it.

I've implemented basic for-of support in #109. Hope to finalise this next week.

Hi Craig,
The for-of functionality is now in the dev branch.
I'll prepare a release branch onto the main branch if you can confirm I've address the core issues.
Regards,
Conrad

Thank you Conrad.  My team and I will be testing it soon, and I will let you know.

Hi Craig.
Just following up if you had a chance to confirm if the latest dev branch addressed your issues.
I'm going to prepare the release in the meantime.

Great stuff! Thanks again for validating!


Bash script to copy the chains public sig key

It copies it to a secret in your current project/namespace so it can
be used conveniently without requiring access to the secret in
tekton-chains which includes the protected secret key.
Inspired by:
https://github.com/redhat-appstudio/build-definitions/pull/56
https://github.com/redhat-appstudio/infra-deployments/pull/293

I'll take the previous approve from @lcarva and merge this. Let's do a rebase since it's on top anyhow afaict.

Also there's one more typo fix i want to get merged quickly.


Upgrade to Lambda base image to Node 18.x

See #424

getting this now with actions/checkout@v4
/tmp/runner/externals/node20/bin/node: /lib64/libm.so.6: version `GLIBC_2.27' not found (required by /tmp/runner/externals/node20/bin/node)
I guess needs another issue to upgrade to node20? :grin: not sure

Did checkout@v4 ever work in Lambda? Is this a new issue?

yeah I don't think it was ever working with v4. v3 works though, so idk if it's that important 🤷

@kichik configure-aws-credentials@v4 also expects node20, which throws a GLIBC mismatch error. The base image needs to be something newer I suspect...


Refactoring of features storage I/O and an initial (probably inefficient) HDF storage implementation

OK so I looked into HDF5 a little bit. This is a rough draft, failing tests, no comments/docs etc. just checking if this design is adequate and can work. It's mostly refactoring of the writing-to-individual-files storage method so that it's easy to plug in some other backend - this is done by introducing FeaturesWriter and FeaturesReader. They have a name which is written into feature manifests so during load the correct FeaturesReader can be instantiated (because it's decorated with @registered_reader decorator). Since that would lead to opening and closing handles on HDF file all the time, it is being held in an LRU cache (global program state) and can be cleared with a close_cached_hdf_files() call. It shouldn't lead to any problems with forking because I expect that the first call to load_features() will only happen after a fork (for multi-process training/dataloading), so each subprocess will open its own file handles.
The HDF5 raw-string handling documentation is not great (they suggest putting binary data into metadata headers?!) and I might be doing something dumb. Maybe somebody more familiar with HDF can comment on that.
Below is a screenshot of usage in practice. A naive benchmark doesn't show much difference in terms of runtime on my MacBook, probably need to check on more data and on the CLSP grid which has slow I/O and will reveal any possible performance benefits. IDK when I'll have time to pick this up so feel free to comment on this in the meanwhile.

I wonder if int8_t might be a better way to store the raw character data?

Have you ever seen someone use hdf5 for stuff like speech data that would naturally be indexed by, say, string and then be an uneven-sized array?  I don't know what the normal pattern is.  It's hard to be confident we're doing it right without knowing how someone would use hdf5 for our kind of data.

I multiplied mini_librispeech train set size by 20 and extracted the features with either files or hdf5 storage with lilcom compression. Then, I benchmarked the features loading sequentially with a single thread from a NFS node on the CLSP grid.
Mean loading times for 7 runs:
Files + lilcom: 57.3 seconds
HDF5 + lilcom: 38.1 seconds
So HDF5 reader managed to load it in 66% of the time. I'll also later check the HDF5 without lilcom compression for comparison.

I wonder if int8_t might be a better way to store the raw character data?

I checked, there was no difference either in size or speed compared to void.
I have more news about the different storage strategies:
Files + lilcom: 57.3 seconds
HDF5 + lilcom: 38.1 seconds
pure HDF5: 15.8 seconds
In terms of storage size:
HDF5 + lilcom: 1.7GB
pure HDF5: 5.8GB
So lilcom enables more than 3x size reduction at the cost of 2.5x longer reads. The benefits are likely become more pronounced with parallel reads but I don't have the bandwidth to test it right now. Also, @danpovey maybe the decompression can be further optimized to reduce the read times?
Another issue with the current implementation is doing parallel writes to HDF5 file (if you wanted to use multiprocessing/threading to parallelize). I know there is some support for that in HDF5 but you need to compile with MPI and add some extra arguments. We can always split the RecordingSet/CutSet into a few parts and launch individual processes to store the data in separate HDF5 files. I'm open to suggestions (and contributions).
I'll fix the tests sometime soon and make this PR ready to merge.

Great!
There is probably some scope for optimizing the decompression speed; but
the motivation for it was more about not overloading the file server,
especially for cases where there is parallel training.  We can look at that
once it's a limiting factor,
Dan
On Wed, Oct 7, 2020 at 5:52 AM Piotr Żelasko<EMAIL_ADDRESS>wrote:

I wonder if int8_t might be a better way to store the raw character data?
I checked, there was no difference either in size or speed compared to
void.
I have more news about the different storage strategies:
Files + lilcom: 57.3 seconds
HDF5 + lilcom: 38.1 seconds
pure HDF5: 15.8 seconds
In terms of storage size:
HDF5 + lilcom: 1.7GB
pure HDF5: 5.8GB
So lilcom enables more than 3x size reduction at the cost of 2.5x longer
reads. The benefits are likely become more pronounced with parallel reads
but I don't have the bandwidth to test it right now. Also, @danpovey
https://github.com/danpovey maybe the decompression can be further
optimized to reduce the read times?
Another issue with the current implementation is doing parallel writes to
HDF5 file (if you wanted to use multiprocessing/threading to parallelize).
I know there is some support for that in HDF5 but you need to compile with
MPI and add some extra arguments. We can always split the
RecordingSet/CutSet into a few parts and launch individual processes to
store the data in separate HDF5 files. I'm open to suggestions (and
contributions).
I'll fix the tests sometime soon and make this PR ready to merge.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/pzelasko/lhotse/pull/92#issuecomment-704572926, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAZFLO3BU6VFBJXLQXRGPZTSJOGTDANCNFSM4SB6WTZQ
.

@danpovey ready for final review if you'd like


Add build_info metrics for jaeger components

Signed-off-by: Ashmita Bohara<EMAIL_ADDRESS>
Which problem is this PR solving?
Resolves https://github.com/jaegertracing/jaeger/issues/3062
Short description of the changes
Following this blog, exposing build_info metrics for every jaeger component.
Example for Jaeger Agent metrics endpoint:

( I have a local git tag as v1.32.0 hence version is showing that)

I like this idea, but we went in a different direction with #1333. The main reason is this, seen in a comment from @yurishkuro:

Good idea. the only issue I foresee is that some metrics systems (in particular, Uber's M3) flush all metrics periodically, which results in the single data point in the time series db, thus if you're looking at the last hour of metrics and that point was earlier, you won't get any data.
Perhaps instead of metrics (which are meant for time series, even if gauges), these values are better exposed via expvar.

Thank you @albertteoh @jpkrohling for the review. I will look at the PR associated with that issue and update it accordingly.

On reading more about expvar, I have a question about it:
It looks like expvar is golang related endpoint rather than prometheus related endpoint. That means if we expose it via expvar, it is exposed at /debug/vars which doesn't seems to be consumable by prometheus (since it's not exposing in prometheus format)
As per the blog linked to the issue, they are trying to add version label to other timeseries using some kind of join. This will not be possible if we expose it as expvar.
Looking at other tools like prometheus, alertmanager, victoriametrics, they are exposing this build information as metrics rather than expvar.
I tried exposing the gauge as expvar which came something like this at http://localhost:14271/debug/vars

I am not sure what will be the right way.

Responding to @jpkrohling/@yurishkuro 's comment, we use _info metrics regurlarly that are scraped by prometheus to build dashboards that include versioning information. I don't know the details of M3 but in Prometheus this series is always available to be joined against as long as the application is publishing it.

Hi @jpkrohling @yurishkuro
May I ask for your review for this PR please.
Regards.

Should we convert the ones from #1333 as well, in name of consistency?

I don't have any strong opinion but I think command line flags should be kept as expvar unless they are changing dynamically during the runtime.

At least one value might be changing: the dyn-queue-size value.


Creating GVRWebView or GVRFrameLayout in onCreate forces the GVR application to run declared view in Monoscopic

GVRf version: 3.3.1-SNAPSHOT
gvr.xml:
        <mono-mode-parms
            monoFullScreen="false"
            monoMode="false" />

GVR application forces to run in monoscopic view when we create an object as follows,
GVRWebView webView = new GVRWebView(this)
or
GVRFrameLayout frameLayout = new GVRFrameLayout(this);
Further debugging above classes I found out its causing when executing following line in above constructors:
context.registerView(this);
I know GVRWebView and GVRFrameLayout classes are deprecated but I need to use these as GVRGUISceneObject expects objects of these classes.
Thanks,

@channae Replace the use of GVRWebView with WebView and GVRFrameLayout with FrameLayout. That should be enough.
For example I updated one of our demos exhibiting the same problem: https://github.com/gearvrf/GearVRf-Demos/pull/540

Hi @liaxim,
Thanks for the quick response. I was using the GVRViewSceneObject with WebView before GVRGUISceneObject class was introduced.
Problem with GVRViewSceneObject is that touch events cannot be dispatched to the WebView. However even though GVRGUISceneObject class is handling touch events it uses deprecated classes which results in forcing to monoscopic mode.
Thanks,

Hi @liaxim,
Thanks for the quick response. I was using the GVRViewSceneObject with WebView before GVRGUISceneObject class was introduced.
Problem with GVRViewSceneObject is that touch events cannot be dispatched to the WebView. However even though GVRGUISceneObject class is handling touch events it uses deprecated classes which results in forcing to monoscopic mode.
Thanks,

@channae Luckily changing GVRGUISceneObject is rather straightforward. Here is the pull request https://github.com/Samsung/GearVRf/pull/1554. Let us know how it works for you. Thanks.

Hi @liaxim, Good news is now the touch events gets when using View in GVRGUISceneObject class as you suggested. Now the issue is touch events coordinates are inaccurate.

As you can see in the screenshot, I was able to navigate to "Getting Started" page. However clicking on top of the "Getting Started" link did not do anything. Navigation worked when I click on middle of the page (where the cursor is right now). I assume height and width of Android WebView is not in sync with rendered GVRGUISceneObject. Thanks :)

@channae I have modified gvr-sceneobjects in https://github.com/liaxim/GearVRf-Demos/tree/webviewtest. While there is some offset, it is not as big as you describe. I want to get our tests in sync. There have been api changes and what not recently. This demo works with the 3.3 snapshot which I presume you use also. Are you consistently observing vertical offset only? If the app I shared is not quite what you have, could you please share a sample project?

Hi @liaxim,
I was able to resolve the touch dispatch issue with WebView as you suggested. However I was seeing an extreme lag in dispatching touch events to the WebView.
Approach with GVRWebView
Then I tried to identify the root cause behind forcing GVRWebView to monoscopic view in my project (For this purpose I reverted GVRGUISceneObject to work with GVRWebView).
After further analyzing I could identify the root cause behind the issue and get it resolved. Now GVRWebView works in sterioscopc mode and its lag free and touch events are very accurate and responsive.
My app pop up with an interactive webview once the user gaze at a specific GVRCubeSceneObject. So the webview creation logic was used to execute at onStep after gazing at GVRCubeSceneObject. When using the 3.1.2-SNAPSHOT webview worked in sterioscopic mode even though touch events did not work.
Seems like when using gearvrf 3.3 onwards we need to create the GVRGUISceneObject with GVRWebView within onInit (which forces to run in sterioscopic mode) and add it to the main scene during onStep.
Now I'm trying to get my GVRFrameLayout working so I added below in onInit and got rid of the monoscopic issue of my GVRFrameLayout,
layoutObject = new GVRGUISceneObject(gvrContext, gvrFrameLayout, gvrContext.createQuad(Utils.QUAD_X, Utils.QUAD_Y));
However touch events does not get dispatched when I follow the same steps I did as GVRWebView. Do you have a working sample which uses GVRGUISceneObject with GVRFrameLayout?
Thanks,
Channa

Hi @liaxim,
As I couldn't move ahead with the GVRGUISceneObject with GVRFrameLayout approach (Even though I could managed to work with GVRGUISceneObject with GVRWebView). I changed my previous picking code and replaced following deprecated method and got it to work with GVRViewSceneObject.
deprecated: float[] hitPoint = event.getHitPoint();
replaced by: float[] hitPoint = event.getPickedObject().getHitLocation();
Thanks,
Channa

@channae I am glad you are moving along nicely. Can we close this issue then? Please open other issues in case you experience different problems.
You must have learned a lot. Do you have any fixes or suggestions how to improve the framework? We would be happy to incorporate them.

Hi @liaxim,
Sorry for the late response. This issue can be closed as I'm creating GVRGUISceneObjects with respective GVRFrameLayout, GVRWebView objects during onInit to get rid of monoscopic issue.
Sure I'll let you know if I find any more issues/fixes that could help to improve the framework. Also appreciate the support given to me through out the development.
Thanks,
Channa


ETL exercise: provide hint to student to lowercase the letters

For the merge comment, [no important changes] would be appropriate here: http://forum.exercism.org/t/maintainers-new-no-important-files-changed-flag-added/6500

Ah, we must have pressed the button at almost the exact same time... disregard.

I was wondering why the UI was glitching for me.

12 rep seems excessive for this PR. You could add the x:rep/tiny label.

Fixed. I didn't see a way to add labels through the mobile UI.


Fixes missing Reset in ResetVT

When using Pooling and so ResetVT we definitively want to reuse slices.
However a bug was recently discovered where it would not zeroed slice items.
https://github.com/planetscale/vtprotobuf/pull/35 introduces a fixes by simply removing slice recycling which I think makes pooling a bit less interesting.
This PR rollback #35 and takes another approach that actually Reset the member even if ResetVT is not available because the feature pool is deactivate for that type.
I can't generate anything unfortunately I don't have the protoc version I'd appreciate help for re-generating those.

Please squash merge if approved !

Thank you! Merged and fixed the conflicts manually.


visionOS support

Please file feature requests at the ideas discussions page.
Of course, these are answered just as often and reliably, but offer a better surface to deal with them. Any issue that is actually a feature request will otherwise be turned into a discussion anyway.

Created a PR https://github.com/lucaszischka/BottomSheet/pull/151


[Enhancement] Scaling optimization on Windows high-resolution screen

The font that Apple Music Electron shows on my Windows (2K, 150% Scale) is too small to read. But when I change the compatibility setting of the EXE to system (enhanced), the font will be blurred.
Sincerely hope that a font size setting could be added or optimization on high-resolution screen could be considered!

What is the version of the app are you using right now ? On 3.0.0 , Go to preferences ( by clicking the your avatar ), then scroll down to Interface Scaling Multiplier, you can decrease it to suit your view

What is the version of the app are you using right now ? On 3.0.0 , Go to preferences ( by clicking the your avatar ), then scroll down to Interface Scaling Multiplier, you can increase it to suit your view

! I'm using 3.0.0 and I'm not native English speaker (and the default font size is so small) so I didn't find it before, and thank you!! But now I got a new problem:
I don't remember how I changed the theme but it looks like this, and, using this theme makes me unable to click the avatar to change the preference 😭

Most likely you are being fallen back to using the (non-beta) site, due to an internet error. The app will still run, with limitations ( like you're currently facing).
An app restart should fix the issue:
https://media.discordapp.net/attachments/843960846933688331/913736012235165716/unknown.png

I'm sure that the "useBetaSite" setting in config.json is right, but restart didn't fix it.
And when I reinstall it, I meet a NEW problem, if I click on Preferences, it will jump to Listen-Now, like this:

I'm really puzzled >.<

I'm sure that the "useBetaSite" setting in config.json is right, but restart didn't fix it. And when I reinstall it, I meet a NEW problem, if I click on Preferences, it will jump to Listen-Now, like this:  I'm really puzzled >.<

Something is really wrong with your current app, I've never faced this bug, please delete %Appdata%/AppleMusic folder.

It really works! Thank you!!!!
(last tiny enhancementable point: I've already changed Interface Scaling Multiplier to 1.5, but it seems like the right-click menu of
the tray bar icon is not multiplied)

I'm sure that the "useBetaSite" setting in config.json is right, but restart didn't fix it. And when I reinstall it, I meet a NEW problem, if I click on Preferences, it will jump to Listen-Now, like this:  I'm really puzzled >.<

I'm sure that the "useBetaSite" setting in config.json is right, but restart didn't fix it. And when I reinstall it, I meet a NEW problem, if I click on Preferences, it will jump to Listen-Now, like this:  I'm really puzzled >.<

Something is really wrong with your current app, I've never faced this bug, please delete %Appdata%/AppleMusic folder. (no reinstall needed)

I meet the same bug also, and I try to delete the %Appdata%/AppleMusic folder and restart the app, but I still can't open the Preferences. After trying to delete the folder and restart several times, I gived up. Now I can only edit the config.json file directly to change my preferences.
I have a suppose, maybe this bug is language related, cause he and I both are Chinese user?

This should be fixed by  #410 (url)

I'm sure that the "useBetaSite" setting in config.json is right, but restart didn't fix it. And when I reinstall it, I meet a NEW problem, if I click on Preferences, it will jump to Listen-Now, like this:  I'm really puzzled >.<

I'm sure that the "useBetaSite" setting in config.json is right, but restart didn't fix it. And when I reinstall it, I meet a NEW problem, if I click on Preferences, it will jump to Listen-Now, like this:  I'm really puzzled >.<

Something is really wrong with your current app, I've never faced this bug, please delete %Appdata%/AppleMusic folder. (no reinstall needed)

I meet the same bug also, and I try to delete the %Appdata%/AppleMusic folder and restart the app, but I still can't open the Preferences. After trying to delete the folder and restart several times, I gived up. Now I can only edit the config.json file directly to change my preferences. I have a suppose, maybe this bug is language related, cause he and I both are Chinese user?


Send telemetry on unhandled exceptions inside the AnalysisQueue

Fixes #445.
I've also reworked the telemetry for exception-type events to a common place. If the exception is an AggregateException, then the first inner exception is the "main" exception reported. The outer exception is also included, but in different fields. This makes it easier to group events by where the first exception thrown actually occurs rather than special casing it in some query later.
AggregateExceptions can of course contain more than one inner exception, but because the telemetry properties must be strings, we can't really represent them without encoding something to JSON first and then re-parsing it later. I'd rather not bother until we have a good reason to send a big blob in the telemetry events.
~One thing I want feedback on: Is analyzer.unhandledException alright for the event name?~

I've changed the event name to analysis_queue.unhandled_exception to better match the look/feel of the VSC exception's events.


Access to Pan details info for display Overlay label when dragging card

Hello,
I want to display overlay labels when user dragging the card.
To do so I need access to "DragUpdateDetails" onPanDown, onPanUpdate and onPanEnd for let me interpolate overlay labels opacity OR access to animated X and Y of the card, can you provide callbacks plz ?

@xrr2016

@xrr2016 any news about this ?

I'd think the easiest way to do this is to just surround your "photo card" by a Listener() widget.
For example, if today your cards are something like this:
    final cards = List.generate(
      500,
      (index) => Card(
        Image.asset(
          'some file or url here',
        ),
      ),
    );

surround it by a Listener as such:
    final cards = List.generate(
      500,
      (index) => Listener(
        onPointerDown: (event) {
          print('down: $event');
        },
        onPointerMove: (event) {
          print('move: $event');
        },
        onPointerUp: (event) {
          print('up: $event');
        },
        child: Card(
          Image.asset(
            'some file or url here',
          ),
        ),
      ),
    );

When onPointerDown is triggered, use a local variable to set the originalXCoordinate and newXCoordinate, and then onPointerMove triggers, update newXCoordinate. Use the difference between the two or whatever calculation you desire to calculate what you want. Use onPointerUp to reset newXCoordinate to originalXCoordinate so that you reset that calculation.
This is what I do at least...


When the seata-server starts, it should takes a delay to delete the expired undo log

[x] I have searched the issues of this repository and believe that this is not a duplicate.

Ⅰ. Issue Description
When the seata-server starts, it should takes a delay to delete the expired undo log. when the
delete the expired undo log schedule run the first，rm channel was not registered.

Ⅱ. Describe what happened
If there is an exception, please attach the exception trace:
Just paste your stack trace here!

Ⅲ. Describe what you expected to happen
Ⅳ. How to reproduce it (as minimally and precisely as possible)

xxx
xxx
xxx

Ⅴ. Anything else we need to know?
Ⅵ. Environment:

JDK version :
OS :
Others:

can i fix it?


Face detection not working

I switched from 0.0.9 to 0.1.1, it doesn't capture face landmarks.

@muzammil-git The issue with capturing face landmarks that you encountered after switching from version 0.0.9 to 0.1.1 has been resolved in version 0.1.2. Please update to the latest version and verify if the problem persists. If you continue to experience the same error, feel free to reopen the issue for further assistance.

Thanks @Conezi, I will check it up.


Docker memory size requirement calculation

Is your feature request related to a problem? Please describe.
What is the memory size needed to be allocated to Docker for segmentation on a set of images? For example, if I have a set of 50 images that I want the segmentation script to process altogether at once, and each image is around 17MB, how much memory would have to be allocated to Docker?
I am always unsure of how much memory is needed by Docker to segment my image sets. It is difficult to decide on which computer the segmentation script should be run when the required memory size is unknown.
Describe the solution you'd like
The segmentation script reads in the image set and outputs an estimation of the memory size needed.
Describe alternatives you've considered
Given a formula to calculate the memory size needed, so we can make an estimation ourselves.
Thank you!

Hi Rita,
I think what we'll do is make the script take significantly less memory so that it can be run on a laptop even if you have tons of images. As people start running larger and larger cohorts this is going to become a more common problem, thanks for flagging it for us.


Flux Lora producing blurry images

I trained a Lora for a dress on flux and it gives me blurry results. I am using it at weights 1 and 1.3, but training other dresses does not produce this effect. Why is this?

What network dim and alpha are you using? It happened with me as well turns out flux learns even the bad quality from the images if you are using 128 network dim and alpha reduce it ti 64. It worked for me


add “--show-all” to kubectl get pods

add “--show-all” to "kubectl get pods  --selector=job-name=pi --output=jsonpath={.items..metadata.name}"，because the pod was ended.

This change is

This is a duplicate of #2516, so I'm closing it.


shows menu bar at the bottom occasionlly

Issue Type: Bug
it will show a menu bar at the bottom occasionlly when switch to debug console

VS Code version: Code 1.29.1 (bc24f98b5f70467bc689abf41cc5550ca637088e, 2018-11-15T19:13:36.375Z)
OS version: Windows_NT x64 10.0.17134

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz (4 x 2592)

GPU Status
2d_canvas: enabledchecker_imaging: disabled_offflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: disabled_softwarerasterization: enabledvideo_decode: enabledvideo_encode: enabledwebgl: enabledwebgl2: enabled

Memory (System)
7.90GB (3.56GB free)

Process Argv

Screen Reader
no

VM
0%

Extensions: none

@liudaoping can you share repro steps and try on the latest release 1.30? Specifically, what were you doing before this occurred? Did you use the mouse or keyboard to switch to the debug console? Does it exit the state? Is so how?

@sbatten
I update to the latest release 1.30,and the issue still occurs. and the steps to repro as below

click "output" tab
switch to debug console
click the area of debug console, and it shows the menu bar

@liudaoping
I am unable to reproduce this with the steps:

Click output
Click debug console
Click in debug console area

Is this the only graphical issue you see when this happens?

@sbatten

Is this the only graphical issue you see when this happens?
yes

@sbatten
I found other issues, check below images:

@bpasero electron?

@sbatten
one more similar issue：

start vs code
select menu：view -> output

click welcome area，and shows something like below

We are building exploration builds that use a much newer version of Electron (our UI framework). I wonder if this issue reproduces with one of these builds, could you try? Download:

macOS: Download
Linux: Download
Windows: Download

@bpasero
I have downloaded and tried it, and it works fine! Above issues doesn't occur!
So, how can i fix these issues?

@liudaoping you can switch to our nightly insider builds until we released this fix to stable (end of January):  You can give our preview releases a try from: https://code.visualstudio.com/insiders/

@bpasero
OK, thx