[BUG] can't be installed on Python 3.11 due to dependency on pyarrow

Memgraph version Which version did you use?
Using the docker image for memgraph: "memgraph/memgraph-platform"
Environment Some information about the environment you are using Memgraph
on: operating system, how do you connect, with or without docker, which driver
etc.
Using docker for memgraph, and using poetry to install gqlalchemy. This is done on a pyenv 3.11 virtual environment in MacOS.
Describe the bug A clear and concise description of what the bug is.
pyarrow is not yet compatible with Python 3.11. Therefore it can't be installed, and breaks gqlalchemy.
To Reproduce Steps to reproduce the behavior:

create a pyenv virtualenv 3.11 and activate
Create a poetry project
Run 'poetry add gqlalchemy'
Run poetry install

Expected behavior A clear and concise description of what you expected to
happen.
The poetry installation should fail due to a failure to install pyarrow
Logs If applicable, add logs of Memgraph, CLI output or screenshots to help
explain your problem.
• Installing pyarrow (9.0.0): Failed
CalledProcessError
Command '['/Users/brandon/.pyenv/versions/3.11.0/envs/fulcrum-maps-test/bin/python', '-m', 'pip', 'install', '--use-pep517', '--disable-pip-version-check', '--prefix', '/Users/brandon/.pyenv/versions/3.11.0/envs/fulcrum-maps-test', '--no-deps', '/Users/brandon/Library/Caches/pypoetry/artifacts/b8/98/15/cf9a801ac46e67488b2720c005c9e5f3756a53f12868504fb202083132/pyarrow-9.0.0.tar.gz']' returned non-zero exit status 1.
at ~/.pyenv/versions/3.10.7/lib/python3.10/subprocess.py:524 in run
520│             # We don't call process.wait() as .exit does that for us.
521│             raise
522│         retcode = process.poll()
523│         if check and retcode:
→  524│             raise CalledProcessError(retcode, process.args,
525│                                      output=stdout, stderr=stderr)
526│     return CompletedProcess(process.args, retcode, stdout, stderr)
527│
528│
The following error occurred when trying to handle this error:
EnvCommandError
Command ['/Users/brandon/.pyenv/versions/3.11.0/envs/fulcrum-maps-test/bin/python', '-m', 'pip', 'install', '--use-pep517', '--disable-pip-version-check', '--prefix', '/Users/brandon/.pyenv/versions/3.11.0/envs/fulcrum-maps-test', '--no-deps', '/Users/brandon/Library/Caches/pypoetry/artifacts/b8/98/15/cf9a801ac46e67488b2720c005c9e5f3756a53f12868504fb202083132/pyarrow-9.0.0.tar.gz'] errored with the following return code 1, and output:
Looking in indexes<EMAIL_ADDRESS>Processing /Users/brandon/Library/Caches/pypoetry/artifacts/b8/98/15/cf9a801ac46e67488b2720c005c9e5f3756a53f12868504fb202083132/pyarrow-9.0.0.tar.gz
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'
Building wheels for collected packages: pyarrow
Building wheel for pyarrow (pyproject.toml): started
Building wheel for pyarrow (pyproject.toml): finished with status 'error'
error: subprocess-exited-with-error
× Building wheel for pyarrow (pyproject.toml) did not run successfully.
│ exit code: 1
╰─> [258 lines of output]
    running bdist_wheel
    running build
    running build_py
    creating build
    creating build/lib.macosx-12.6-arm64-cpython-311
    creating build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/orc.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/conftest.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/_generated_version.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/benchmark.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/_compute_docstrings.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/ipc.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/util.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/flight.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/cffi.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/substrait.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/filesystem.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/__init__.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/plasma.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/types.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/dataset.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/cuda.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/feather.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/pandas_compat.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/fs.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/csv.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/jvm.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/hdfs.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/json.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/serialization.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/compute.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    creating build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_tensor.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_ipc.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/conftest.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_convert_builtin.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_misc.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/arrow_16597.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_gandiva.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/strategies.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_adhoc_memory_leak.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/arrow_7980.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/util.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_orc.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_table.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_array.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_deprecations.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_serialization_deprecated.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/__init__.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_io.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_util.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_cuda_numba_interop.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_cffi.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_schema.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_jvm.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_plasma_tf_op.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_fs.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_udf.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_filesystem.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/pandas_threaded_import.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/pandas_examples.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_cython.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_sparse_tensor.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_dataset.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_builder.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_cuda.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_extension_type.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_feather.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_pandas.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_memory.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_exec_plan.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_flight.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/read_record_batch.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_json.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_serialization.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_compute.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_hdfs.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/deserialize_buffer.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_strategies.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_csv.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_plasma.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_scalars.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_gdb.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_types.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/test_substrait.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    creating build/lib.macosx-12.6-arm64-cpython-311/pyarrow/vendored
    copying pyarrow/vendored/version.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/vendored
    copying pyarrow/vendored/__init__.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/vendored
    copying pyarrow/vendored/docscrape.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/vendored
    creating build/lib.macosx-12.6-arm64-cpython-311/pyarrow/parquet
    copying pyarrow/parquet/encryption.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/parquet
    copying pyarrow/parquet/__init__.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/parquet
    creating build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests/parquet
    copying pyarrow/tests/parquet/test_basic.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests/parquet
    copying pyarrow/tests/parquet/conftest.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests/parquet
    copying pyarrow/tests/parquet/encryption.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests/parquet
    copying pyarrow/tests/parquet/test_parquet_writer.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests/parquet
    copying pyarrow/tests/parquet/test_metadata.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests/parquet
    copying pyarrow/tests/parquet/__init__.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests/parquet
    copying pyarrow/tests/parquet/test_datetime.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests/parquet
    copying pyarrow/tests/parquet/common.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests/parquet
    copying pyarrow/tests/parquet/test_dataset.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests/parquet
    copying pyarrow/tests/parquet/test_data_types.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests/parquet
    copying pyarrow/tests/parquet/test_pandas.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests/parquet
    copying pyarrow/tests/parquet/test_parquet_file.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests/parquet
    copying pyarrow/tests/parquet/test_compliant_nested_type.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests/parquet
    copying pyarrow/tests/parquet/test_encryption.py -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests/parquet
    running egg_info
    writing pyarrow.egg-info/PKG-INFO
    writing dependency_links to pyarrow.egg-info/dependency_links.txt
    writing entry points to pyarrow.egg-info/entry_points.txt
    writing requirements to pyarrow.egg-info/requires.txt
    writing top-level names to pyarrow.egg-info/top_level.txt
    listing git files failed - pretending there aren't any
    reading manifest file 'pyarrow.egg-info/SOURCES.txt'
    reading manifest template 'MANIFEST.in'
    warning: no files found matching '../LICENSE.txt'
    warning: no files found matching '../NOTICE.txt'
    warning: no previously-included files matching '*.so' found anywhere in distribution
    warning: no previously-included files matching '*.pyc' found anywhere in distribution
    warning: no previously-included files matching '*~' found anywhere in distribution
    warning: no previously-included files matching '#*' found anywhere in distribution
    warning: no previously-included files matching '.git*' found anywhere in distribution
    warning: no previously-included files matching '.DS_Store' found anywhere in distribution
    no previously-included directories found matching '.asv'
    writing manifest file 'pyarrow.egg-info/SOURCES.txt'
    copying pyarrow/__init__.pxd -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/_compute.pxd -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/_compute.pyx -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/_csv.pxd -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/_csv.pyx -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/_cuda.pxd -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/_cuda.pyx -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/_dataset.pxd -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/_dataset.pyx -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/_dataset_orc.pyx -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/_dataset_parquet.pyx -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/_exec_plan.pyx -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/_feather.pyx -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/_flight.pyx -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/_fs.pxd -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/_fs.pyx -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/_gcsfs.pyx -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/_hdfs.pyx -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/_hdfsio.pyx -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/_json.pyx -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/_orc.pxd -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/_orc.pyx -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/_parquet.pxd -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/_parquet.pyx -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/_parquet_encryption.pxd -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/_parquet_encryption.pyx -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/_plasma.pyx -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/_s3fs.pyx -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/_substrait.pyx -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/array.pxi -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/benchmark.pxi -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/builder.pxi -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/compat.pxi -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/config.pxi -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/error.pxi -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/gandiva.pyx -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/io.pxi -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/ipc.pxi -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/lib.pxd -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/lib.pyx -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/memory.pxi -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/pandas-shim.pxi -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/public-api.pxi -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/scalar.pxi -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/serialization.pxi -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/table.pxi -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/tensor.pxi -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    copying pyarrow/types.pxi -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow
    creating build/lib.macosx-12.6-arm64-cpython-311/pyarrow/includes
    copying pyarrow/includes/common.pxd -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/includes
    copying pyarrow/includes/libarrow_feather.pxd -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/includes
    copying pyarrow/includes/__init__.pxd -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/includes
    copying pyarrow/includes/libgandiva.pxd -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/includes
    copying pyarrow/includes/libarrow_python.pxd -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/includes
    copying pyarrow/includes/libarrow_flight.pxd -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/includes
    copying pyarrow/includes/libarrow_dataset_parquet.pxd -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/includes
    copying pyarrow/includes/libarrow_dataset.pxd -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/includes
    copying pyarrow/includes/libarrow_substrait.pxd -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/includes
    copying pyarrow/includes/libarrow.pxd -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/includes
    copying pyarrow/includes/libarrow_cuda.pxd -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/includes
    copying pyarrow/includes/libarrow_fs.pxd -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/includes
    copying pyarrow/includes/libplasma.pxd -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/includes
    copying pyarrow/tests/bound_function_visit_strings.pyx -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    copying pyarrow/tests/pyarrow_cython_example.pyx -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests
    creating build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tensorflow
    copying pyarrow/tensorflow/plasma_op.cc -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tensorflow
    creating build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests/data
    creating build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests/data/feather
    copying pyarrow/tests/data/feather/v0.17.0.version.2-compression.lz4.feather -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests/data/feather
    creating build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests/data/orc
    copying pyarrow/tests/data/orc/README.md -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests/data/orc
    copying pyarrow/tests/data/orc/TestOrcFile.emptyFile.jsn.gz -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests/data/orc
    copying pyarrow/tests/data/orc/TestOrcFile.emptyFile.orc -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests/data/orc
    copying pyarrow/tests/data/orc/TestOrcFile.test1.jsn.gz -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests/data/orc
    copying pyarrow/tests/data/orc/TestOrcFile.test1.orc -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests/data/orc
    copying pyarrow/tests/data/orc/TestOrcFile.testDate1900.jsn.gz -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests/data/orc
    copying pyarrow/tests/data/orc/TestOrcFile.testDate1900.orc -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests/data/orc
    copying pyarrow/tests/data/orc/decimal.jsn.gz -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests/data/orc
    copying pyarrow/tests/data/orc/decimal.orc -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests/data/orc
    creating build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests/data/parquet
    copying pyarrow/tests/data/parquet/v0.7.1.all-named-index.parquet -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests/data/parquet
    copying pyarrow/tests/data/parquet/v0.7.1.column-metadata-handling.parquet -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests/data/parquet
    copying pyarrow/tests/data/parquet/v0.7.1.parquet -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests/data/parquet
    copying pyarrow/tests/data/parquet/v0.7.1.some-named-index.parquet -> build/lib.macosx-12.6-arm64-cpython-311/pyarrow/tests/data/parquet
    running build_ext
    creating /private/var/folders/x_/mctxkbfj2wx673tc_r7fy0pc0000gp/T/pip-req-build-9n4wvrvp/build/temp.macosx-12.6-arm64-cpython-311
    -- Running cmake for pyarrow
    cmake -DPYTHON_EXECUTABLE=/Users/brandon/.pyenv/versions/3.11.0/envs/fulcrum-maps-test/bin/python -DPython3_EXECUTABLE=/Users/brandon/.pyenv/versions/3.11.0/envs/fulcrum-maps-test/bin/python "" -DPYARROW_BUILD_CUDA=off -DPYARROW_BUILD_SUBSTRAIT=off -DPYARROW_BUILD_FLIGHT=off -DPYARROW_BUILD_GANDIVA=off -DPYARROW_BUILD_DATASET=off -DPYARROW_BUILD_ORC=off -DPYARROW_BUILD_PARQUET=off -DPYARROW_BUILD_PARQUET_ENCRYPTION=off -DPYARROW_BUILD_PLASMA=off -DPYARROW_BUILD_GCS=off -DPYARROW_BUILD_S3=off -DPYARROW_BUILD_HDFS=off -DPYARROW_USE_TENSORFLOW=off -DPYARROW_BUNDLE_ARROW_CPP=off -DPYARROW_BUNDLE_BOOST=off -DPYARROW_GENERATE_COVERAGE=off -DPYARROW_BOOST_USE_SHARED=on -DPYARROW_PARQUET_USE_SHARED=on -DCMAKE_BUILD_TYPE=release /private/var/folders/x_/mctxkbfj2wx673tc_r7fy0pc0000gp/T/pip-req-build-9n4wvrvp
    CMake Warning:
      Ignoring empty string ("") provided on the command line.

    -- The C compiler identification is AppleClang <IP_ADDRESS>00029
    -- The CXX compiler identification is AppleClang <IP_ADDRESS>00029
    -- Detecting C compiler ABI info
    -- Detecting C compiler ABI info - done
    -- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc - skipped
    -- Detecting C compile features
    -- Detecting C compile features - done
    -- Detecting CXX compiler ABI info
    -- Detecting CXX compiler ABI info - done
    -- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ - skipped
    -- Detecting CXX compile features
    -- Detecting CXX compile features - done
    -- System processor: arm64
    -- Performing Test CXX_SUPPORTS_ARMV8_ARCH
    -- Performing Test CXX_SUPPORTS_ARMV8_ARCH - Success
    -- Arrow build warning level: PRODUCTION
    -- Configured for RELEASE build (set with cmake -DCMAKE_BUILD_TYPE={release,debug,...})
    -- Build Type: RELEASE
    -- Generator: Unix Makefiles
    -- Build output directory: /private/var/folders/x_/mctxkbfj2wx673tc_r7fy0pc0000gp/T/pip-req-build-9n4wvrvp/build/temp.macosx-12.6-arm64-cpython-311/release
    -- Found Python3: /Users/brandon/.pyenv/versions/3.11.0/envs/fulcrum-maps-test/bin/python (found version "3.11.0") found components: Interpreter Development.Module NumPy
    -- Found Python3Alt: /Users/brandon/.pyenv/versions/3.11.0/envs/fulcrum-maps-test/bin/python
    -- Found PkgConfig: /opt/homebrew/bin/pkg-config (found version "0.29.2")
    -- Could NOT find Arrow (missing: Arrow_DIR)
    -- Checking for module 'arrow'
    --   No package 'arrow' found
    CMake Error at /opt/homebrew/Cellar/cmake/3.23.2/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
      Could NOT find Arrow (missing: ARROW_INCLUDE_DIR ARROW_LIB_DIR
      ARROW_FULL_SO_VERSION ARROW_SO_VERSION)
    Call Stack (most recent call first):
      /opt/homebrew/Cellar/cmake/3.23.2/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
      cmake_modules/FindArrow.cmake:450 (find_package_handle_standard_args)
      cmake_modules/FindArrowPython.cmake:46 (find_package)
      CMakeLists.txt:236 (find_package)

    -- Configuring incomplete, errors occurred!
    See also "/private/var/folders/x_/mctxkbfj2wx673tc_r7fy0pc0000gp/T/pip-req-build-9n4wvrvp/build/temp.macosx-12.6-arm64-cpython-311/CMakeFiles/CMakeOutput.log".
    See also "/private/var/folders/x_/mctxkbfj2wx673tc_r7fy0pc0000gp/T/pip-req-build-9n4wvrvp/build/temp.macosx-12.6-arm64-cpython-311/CMakeFiles/CMakeError.log".
    error: command '/opt/homebrew/bin/cmake' failed with exit code 1
    [end of output]

note: This error originates from a subprocess, and is likely not a problem with pip.
ERROR: Failed building wheel for pyarrow

Failed to build pyarrow
ERROR: Could not build wheels for pyarrow, which is required to install pyproject.toml-based projects
Additional context Add any other context about the problem here.

@BorisTasevski I tried to create a branch/PR, but I have no push permissions to this repo. The change is super simple if someone on the project wants to make it.
line 40 in pyproject.toml --> pyarrow = "^10.0.0"
This will also require an update to the poetry.lock file:

Remove the poetry.lock file
reinstall poetry on a fresh python environment

Hi @smithbp ,
thank You for Your contribution,
we will most likely start supporting new python version with the next release of gqlalchemy.

Put this task in the backlog.

Pyarrow supports python 3.11, this is due to using an old version in the poetry dependency specification. Maybe try just updating the dependencies in gqlalchemy.

Hi, are there any updates on this ?
Python 3.11 and Pydantic V2 (see:  Issue 257 ) would be very valuable.

Hi @barosch47, we still need to plan for the next release, and it will be appropriately updated on GitHub. Is this a blocking issue for you? It would help me understand the urgency. P.S. we are always open to outside contributions :)

Python 3.11 support would be very good. 3 dependencies (networkX, numpy, pyarrow) have been mentioned in issues as not being compatible with python 3.11. Each of those dependencies currently work with python 3.11. Maybe there are more dependencies with remaining issues?

Is there any way that this issue's priority can be bumped up?
I want to use gqlalchemy for a Python 3.11 project and no support for the latest python version is a deal breaker for me and I would assume many other potential users.

Hi @mckij, we will discuss priorities on GQLAlchemy next week, and I will keep you posted here. I was just wondering, is this a deal breaker for you using Memgraph or only GQLAlchemy as a client?

I was planning on using the GQLAlchemy client to talk to a Neo4j database.  Unfortunately my existing code base is all on Python 3.11 which means GQLAlchemy is currently not an option for me.

Thank you, both @smithbp and @mckij, for your input. I will get back to you as soon as we discuss this.

Hi @smithbp @kapilt @barosch47 @jngarber-st @mckij and thank you for leaving your comments on this issue. We do appreciate it a lot and we decided to work on the release at the end of the next week. Stay tuned :)


Package request: PINCE

PINCE is a front-end/reverse engineering tool for the GNU Project Debugger (GDB), focused on games. However, it can be used for any reverse-engineering related stuff. PINCE is an abbreviation for "PINCE is not Cheat Engine". PINCE is in development right now, read Features part of the project to see what is done and Roadmap part to see what is currently planned. Also, please read Wiki Page of the project to understand how PINCE works.

homepage URL: https://github.com/korcankaraokcu/PINCE
source URL: https://github.com/korcankaraokcu/PINCE
license: Unknown License
platforms: linux

duplicate of #208981


Misc small fixes - Xcode 13 linkage fix & Intel Iris Plus Graphics driver workaround

Fix Obj-C linkage failures when linking to an app with Xcode 13 or earlier.

Xcode 14 introduced a new Clang compilation optimization option, enabled by default, that generates Obj-C msgsend stubs that cannot be processed by previous Xcode versions (13 and earlier), resulting in a very large number of linker issues.
This fix adds -fno-objc-msgsend-selector-stubs to the OTHER_CFLAGS build setting, and also adds -Wno-unused-command-line-argument to the WARNING_CFLAGS build setting, to suppress compiler warnings about using -fno-objc-msgsend-selector-stubs.
Fixes #1756.

Work around MTLCounterSet crash on additional Intel Iris Plus Graphics devices.

Add 0x8a5a and 0x8a5c to list of Intel Iris Plus Graphics device IDs requiring workaround.
Fixes #1761.

This ain't gonna work after all.
The build failures indicate that the -fno-objc-msgsend-selector-stubs build setting is incompatible with any Xcode version prior to 14. I haven't been able to find a way to suppress the compile error that occurs as a result of this, nor have I found a way to only apply that build setting for Xcode 14 and above.
Looks like the best approach overall is to remove -fno-objc-msgsend-selector-stubs and just document the change in linkage with Xcode 14 and recommend devs who need to link MoltenVK to their apps with Xcode 13 or earlier also need to build with Xcode 13 or earlier, or build with Xcode 14 after adding the -fno-objc-msgsend-selector-stubs build setting on their MoltenVK build.
I'm going to close this PR, and generate a new one based on that approach.


Home Assistant integration should allow choosing of stream

Currently the stream to post to has to be passed in as part of the URL parameters. Given that the integration is expecting a POST_JSON webhook call from Home Assistant it would be nice if the stream could optionally be set in the JSON payload. This would make the use of the integration much more flexible and allow a more dynamic selection of which message stream to send to
With the current method multiple notify definitions need to be configured in Home Assistant it is desired for the integration to be used against multiple message streams.

@zulipbot add "area: integrations" "needs discussion"

Thank you for the suggestion, @tykeal.
I think it is possible to change the stream to which an integration sends messages programmatically, depending on some value in the payload. However, if that particular stream does not already exist, then that message will not appear anywhere. Therefore, in order for this to work, the stream must exist beforehand.
I would love to hear what others have to say about this.

Personally I sort of expect this. It's already this way with the integration as it defaults to a stream of "home assistant" that needs to already exist as well, or whatever stream is defined in the URL along with the API key

I don't fully understand the product question here, so please let me know whether this answers it.
I think for integrations in general, it's reasonable to require users to create a stream before using it for an integration. There are a bunch of stream properties to configure, and it wouldn't make sense to do that as part of creating the integration.
There can be a note in the documentation about creating the "home assistant" stream first, or else configuring another stream first, if that seems helpful.

My view of the requested feature would be as such:

Required: Whatever stream that the integration sends to must already exist, it doesn't get created if it doesn't (this is the way it already works)

continue allowing the &stream=<stream> to send to stream. If this is defined, it should override the payload

requested new add stream: "<stream>" to the payload to allow dynamically selecting a stream

Hey, apologies for the late reply. This got missed between other issues.
If I can understand this correctly, the proposal is to send the message to the payload stream only if the webhook URL has no stream specified in it. As of now, if there is no stream specified in the URL then the bot sends the notifications via DM to the creator of the bot.
If instead of DMing them suddenly the bot tries to send the notification through a stream that might not be a good user experience as it would leave in thinking about what happened -- as they changed nothing. So, I am not sure we want to change that behavior,
@tykeal Let me know if I am missing something or if I misunderstood something.

@sbansal1999 I thought I was pretty clear that I just want an additional way of directing messages to streams instead of requiring that it be encoded in the URI.
My thoughts on this are this:

The default and current workflows should continue to work as they already do

Add a json payload key of "stream" which if configured and there is no stream URI parameter, then direct the message to the defined stream with all the standard caveats of the stream needing to exist and the bot having rights to the stream.
2.a) If a stream URI parameter exists, then this would take precedence over the json payload (essentially maintain the current functionality)

Basically I want to be able to do the following (using the example in the docs to explain):
notify:
  - platform: rest
    resource: https:{{ external_api_uri }}v1/external/homeassistant?api_key=foo
    method: POST_JSON
    title_param_name: topic

automation:
  trigger:
    platform: sun
    event: sunrise
  action:
    - service: notify.notify
      data:
        message: "It will be hot out there today!"
        title: "Weather forecast"
        stream: "forecast"

at present if I wanted something like the above I have to modify the notify definition like this:
notify:
  - platform: rest
    resource: https:{{ external_api_uri }}v1/external/homeassistant?api_key=foo&stream=forecast
    method: POST_JSON
    title_param_name: topic

and the automation definition would match the current documentation example.
I really just want to be able to use the "simpler" notify definition and then be able to direct messages to different streams based on automation needs without having to define multiple different notify definitions which is what I have to do now to be able to have a given bot send to different streams.
Please note that docs have a bug per your statement and my own usage. The docs state that if stream is not defined it will default to the homeassistant stream but you mention and I have experienced that it sends to the bot creator as a DM.


remove BackendPolicy RBAC

The upcoming v1alpha2 release of Gateway API drops
BackendPolicy. Contour has dropped references to it
in 7013489dac80e71b2373240a83fe451162f4a4c5. This PR
removes RBAC setup for it from the operator.
Signed-off-by: Steve Kriss<EMAIL_ADDRESS>

Looks like the upgrade E2E test does not work well with changes like this, since when deploying the "old" version of the Operator, the old RBAC for the Operator itself isn't applied, so it's using the "new" RBAC with the "old" Operator.

We're going to need to fix the upgrade test at some point, but for now I added back in RBAC for the Operator to BackendPolicy, so the tests will continue to pass. This PR now just removes BackendPolicy from the ClusterRole that the Operator creates when instantiating a Contour. After v1.19 ships, can drop the RBAC for the Operator itself.


Create a slider for the chart to slide across the map

Detailed Description
Create a slider resize the pv remix chart window, replacing the expand and contract arrows that current expand and contract the charts. While maybe a bit tricky to implement, this will make the page a bit cleaner.
Current:

Suggestion:
View the relevant prototype here.
Context
This will make the page a bit sleeker.
Possible Implementation
Remove resize arrows and implement slider. Probably easier said than done.

Close this for now, as we no


Add sweet alert as plugin

How can i make continuous-integration/styleci/pr pass ?

@DaniloBenevides By merging or rebasing from the origin again. There was a misconfiguration, which is fixed now.


ApolloCaffe error

Hi,
I am trying to reproduce the results but I got some error like this when running run.sh on VQA dataset:
Traceback (most recent call last):
File "main.py", line 255, in
main()
File "main.py", line 31, in main
do_iter(task.train, model, config, train=True)
File "main.py", line 97, in do_iter
batch_data, model, config, train, vis)
File "main.py", line 118, in do_batch
predictions = forward(data, model, config, train, vis)
File "main.py", line 170, in forward
dropout=(train and config.opt.dropout), deterministic=not train)
File "/mnt/sdc1/shangxuan/775/nmn2/models/nmn.py", line 440, in forward
question_hidden = self.forward_question(question_data, dropout)
File "/mnt/sdc1/shangxuan/775/nmn2/models/nmn.py", line 648, in forward_question
bottoms=[word], param_names=[wordvec_param]))
File "/mnt/sdc1/shangxuan/775/apollocaffe/python/apollocaffe/layers/caffe_layers.py", line 203, in init
super(Wordvec, self).init(self, name, kwargs)
File "/mnt/sdc1/shangxuan/775/apollocaffe/python/apollocaffe/layers/layer_headers.py", line 6, in init
self.parse(sublayer, name, kwargs)
File "/mnt/sdc1/shangxuan/775/apollocaffe/python/apollocaffe/layers/layer_headers.py", line 57, in parse
raise AttributeError('Layer %s has no keyword argument %s=%s' % (param_type, k, v))
AttributeError: Layer Wordvec has no keyword argument vocab_size=3591
I am using your fork of Apollo Caffe, so I am not sure where the problem goes.

https://github.com/Russell91/apollocaffe/issues/65 This seems a workaround.


bulk download

Having a bulk download button would be great, to locally recreate what would've been the result if I ran everything on the VM - essentially only copying the workspace. A tar or zip wouldn't be too big?

It is currently possible to get everything that the commands produce from the store directory of your workspace - there is no simple button that delivers it all, but you could use a recursive wget command to get everything from it for the time being. This issue will be kept open as a good addition later, but not current priority I think.


Add-style-to-website

This Pr added style to the website and maintained the responsiveness of the website. I have add some pictures and videos for your reference below.

Thank you so much for your appreciation.Your support is invaluable. Looking forward to contributing more to this repository.

Could you please add a hacktoberfest-accepted label on this PR?


Stop nuking node_modules

Our build script deletes the project's node_modules directory before re-installing everything:
# Clean project dependencies.
clean() {
  # If the node directory already exists,
  # clear it so we know we're working with a clean
  # slate of the dependencies listed in package.json.
  if [ -d $NODE_DIR ]; then
    echo 'Removing project dependency directories...'
    rm -rf $NODE_DIR
  fi
  echo 'Project dependencies have been removed.'
}

This is good for idempotence but bad for efficiency.
$ time npm install

real	0m23.881s
user	0m23.155s
sys	0m1.486s

$ rm -rf node_modules/
$ time npm install

real	2m32.014s
user	1m39.444s
sys	0m38.497s

It doesn't affect local development a whole lot but it adds minutes to our CI jobs and slows down deployments. How would y'all feel about removing it from our build script?
@cfpb/cfgov-frontends @chosak

💯

I'm certain that we started doing this intentionally. I don't fully remember why, but are we sure that whatever reason we did it isn't still in play?

I like the idea of removing the deletion by default. Would it be possible to add either a command-line parameter to frontend.sh (and, I suppose, then setup.sh) or an environment variable to retain the option to remove that directory? I'm thinking it might be useful to support a cleaning option in the build scripts, and this would avoid having to refer to $NODE_DIR outside of this script.

I'm certain that we started doing this intentionally. I don't fully remember why, but are we sure that whatever reason we did it isn't still in play?

I think it was added to reduce JS compilation errors by ensuring we always have fresh copies of the project's node modules. I would rather manually wipe node_modules when I run into errors than do it on every install.

Would it be possible to add either a command-line parameter to frontend.sh (and, I suppose, then setup.sh) or an environment variable to retain the option to remove that directory?

I'm into this. Something like ./setup.sh --clean.

I'm into this. Something like ./setup.sh --clean.

👍

I think that is a good compromise. One thing we should be sure to watch out for is running that proactively when we remove a dependency.

We only need to nuke the modules directory when https://github.com/cfpb/cfgov-refresh/blob/master/npm-shrinkwrap.json updates right? Is there some way we could notify folks when they pull down the latest that it's been updated? It's not something I'd think to check very often since it's been kind of automatic so far.

Was this resolved?

After running into some issues with the CF docs branch, it seems you really do sometimes need to nuke a module in order to convince npm to update it. Even after changing the version in package.json I could not get it to update till I deleted the package from the project.

After running into some issues with the CF docs branch, it seems you really do sometimes need to nuke a module in order to convince npm to update it. Even after changing the version in package.json I could not get it to update till I deleted the package from the project.

K then I think we're good here -- the node_modules dir sometimes gets cleaned and other times doesn't based on flags passed at build time.


Putting a client IP into the Server code?

Issue guidelines

[X] I've read the Issue Guidelines and wholeheartedly agree.

Issue Checklist

[X] I have searched open or closed issues for my problem and found nothing related or helpful.
[X] I have read the Documentation and found nothing related to my problem.
[X] I have gone through the Bonus Examples and FAQs and found nothing related or helpful.

Describe your Question
For those used to the idea that a "server" provides their address to a client, then you should recheck your preconceptions! Please read the Netgear instructions carefully, and you will note that it is the client device that defines the IP that is provided to the server config. If you get this the wrong way (using the server IP on the client), then you will get a zmq.error.ZMQError error. Make sure it is the client's IP shared across the two systems.
Can anyone elaborate on the above paragraph?
I have the following setup: 1 server with a camera and 2 clients are trying to access it. Considering the above paragraph, how is it possible that the server is running all the time and waiting for the clients to connect, or in other words, how the clients can find the server streaming video? The server and clients are connected to the same router.
Terminal log output(Optional)
No response
Python Code(Optional)
No response
VidGear Version
0.3.2
Python version
3.8
Operating System version
Windows 11
Any other Relevant Information?
No response

For those used to the idea that a "server" provides their address to a client, then you should recheck your preconceptions! Please read the Netgear instructions carefully, and you will note that it is the client device that defines the IP that is provided to the server config. If you get this the wrong way (using the server IP on the client), then you will get a zmq.error.ZMQError error. Make sure it is the client's IP shared across the two systems.

@mrazadal, I agree, this is somewhat unconventional when compared to what we typically encounter in our daily experiences. Actually, The term "Server" associated with machine that sends frames, while "Receiver" is associated with the one receiving those frames, but this works opposite when ZMQ server-client is considered. Don't worry; it's not a significant issue. You can easily switch roles by simply changing variable names in your Python script.

I have the following setup: 1 server with a camera and 2 clients are trying to access it. Considering the above paragraph, how is it possible that the server is running all the time and waiting for the clients to connect, or in other words, how the clients can find the server streaming video? The server and clients are connected to the same router.

@mrazadal If you went through docs carefully, I assume, you must be aware with advanced multi-clients mode:  https://abhitronix.github.io/vidgear/latest/gears/netgear/advanced/multi_client/, also for any quick questions like this, please refrain from opening an issue, as you can reach us on Gitter community channel. Hope this helps :)


parseInfinibandDevice fails with Intel Omni-Path

It looks like parseInfinibandDevice expects to see a file /sys/class/infiniband/<Name>/hca_type for each Infiniband device. (As well as board_id and fw_ver.)
Unfortunately, this doesn't seem to be provided by the Omni-Path driver, for some reason.
Downstream, this causes the node exporter to be unable to pick up Omni-Path devices with the Infiniband collector. (Which, I guess they're strictly not, but I think it's supposed to cover them as well.)
I'm not 100% sure what's supposed to come out of this file for other types of device: maybe the information from board_id is enough? Here's an example of the contents of that:
$ cat /sys/class/infiniband/hfi1_0/board_id
Intel Omni-Path Host Fabric Interface Adapter 100 Series

And there's also hw_rev:
$ cat /sys/class/infiniband/hfi1_0/hw_rev
11

Or would not producing an error if the hca_type file isn't found be appropriate?

Okay, so, I pulled the snippet from the fixtures ttar, and I also realised we have a different system that has similar Mellanox cards in, so I got the equivalent from there, and then I grabbed the equivalent from our OmniPath system.
 Oh well, not anything I can change.
Reading some more of the Linux kernel documentation I linked above, it looks like providing hca_type is common but not universal, and isn't in the common interface list, so it seems right to not fail if it's not present. I guess that'll just leave the field with an empty string.
I'm happy to take this one on, if that's fine.
I'm not really sure how to deal with accounting for more extensive differences in the available metric sets in future, but that sounds like a more extensive piece of work.

@ikirker would you consider making a PR with your fix to this repo? Otherwise I think this will not be fixed any time soon.

@seb45tian Ah, sorry, I made that naive fix, but making a test for it seemed surprisingly awkward, and then I realised I wasn't sure what to do with OmniPath adapters with respect to this maybe-Mellanox-specific multiplier.
And then I had to shelve it to handle a bunch of other work before I really got a chance to look at how to investigate that.
I'll see if I can make some tests work and commit them to my fork, and if so I'll PR it and some example ttar data. That'll at least give something to work with.

@seb45tian I think this should fix it but I haven't done the node_exporter rebuild yet. (It's late. 😴)
Apart from the actual test in the PR, so far I've only tried it with a little stubby program that sets up the sysfs, detects all the IB devices, and dumps out the struct:
package main

import (
	"encoding/json"
	"fmt"
	"os"

	"github.com/prometheus/procfs/sysfs"
)

func main() {
	var sysfsPath string
	if len(os.Args[1:]) > 0 {
		sysfsPath = os.Args[1]
	} else {
		sysfsPath = "/sys"
	}
	this_fs, err := sysfs.NewFS(sysfsPath)
	if err != nil {
		panic(err)
	}

	ib_devices, err := this_fs.InfiniBandClass()
	if err != nil {
		panic(err)
	}
	structJson, err := json.MarshalIndent(ib_devices, "", "  ")
	if err != nil {
		panic(err)
	}
	fmt.Println(string(structJson))
}

@ikirker thank you for your efforts! I would definitely have failed at getting those tests work. I also rebuild the node_exporter with this fix and, for me, it works flawlessly!
I also looked into the whole multiply by 4 issue and even though I could not find anything specific about how OmniPath treats this counter, I think this might be a standard for all infiniband drivers (c.f. link)? But I am by no means an expert on this.


Add questions to the  spanish Evaluation survey

The file to add the questions to is: java/edu/virginia/psyc/spanish/persistence/Evaluation.java

What did you find most helpful about MindTrails? [free text]

Do you have suggestions for ways to improve MindTrails for individuals experiencing anxiety? [free text]

I think this is simply adding the backing fields to the model


model-util: generateNodeValue throws NullPointerException

Call to buildNewModelInstance sets objectMetadata to NULL if presetNodes is NULL which leads to NullPointerException here.
Should if statement work other way around?

Fixed

Thanks a lot!

My pleasure, enjoy!  Also, if you notice any other bugs and submit a successful PR, I'll send you a Ride t-shirt.
Thanks again for using Ride!


Using CPM Breaks AppHost build on linux with preview 9

Is there an existing issue for this?

[x] I have searched the existing issues

Describe the bug
After updating a project created with  dotnet new aspire-starter  using the 9x templates and then modifying the project to us central package management we start failing to build on ubuntu-latest with github actions giving the following error:
/home/runner/.nuget/packages/aspire.apphost.sdk/9.0.0-rc.1.24511.1/Sdk/Sdk.targets(89,5): error : test-aspire.AppHost is a .NET Aspire AppHost project that needs a package reference to Aspire.Hosting.AppHost version 8.2.0 or above to work correctly. [/home/runner/work/test-aspire/test-aspire/test-aspire.AppHost/test-aspire.AppHost.csproj]

Expected Behavior
Builds without error
Steps To Reproduce
https://github.com/lawrencek76/test-aspire
add directory.packages.props and make relevant changes to proj files.
Exceptions (if any)
No response
.NET Version info
.NET SDK:
 Version:           9.0.100-rc.2.24474.11
 Commit:            315e1305db
 Workload version:  9.0.100-manifests.cea95dba
 MSBuild version:   17.12.0-preview-24473-03+fea15fbd1

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  22.04
 OS Platform: Linux
 RID:         linux-x64
 Base Path:   /usr/share/dotnet/sdk/9.0.100-rc.2.24474.11/

.NET workloads installed:
There are no installed workloads to display.
Configured to use loose manifests when installing new manifests.

Host:
  Version:      9.0.0-rc.2.24473.5
  Architecture: x64
  Commit:       990ebf52fc

.NET SDKs installed:
  6.0.427 [/usr/share/dotnet/sdk]
  7.0.410 [/usr/share/dotnet/sdk]
  8.0.403 [/usr/share/dotnet/sdk]
  9.0.100-rc.2.24474.11 [/usr/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 6.0.35 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.20 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.10 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 9.0.0-rc.2.24474.3 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 6.0.35 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.20 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.10 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.0-rc.2.24473.5 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
  None

Environment variables:
  DOTNET_ROOT       [/usr/share/dotnet]

global.json file:
  /home/runner/work/test-aspire/test-aspire/global.json

Anything else?
Locally on windows and wsl this error does not occur only seems to happen with github actions.  I have tried to setup my wls ubuntu identically with same versions of .net core as actions but i'm not able to find the difference.

cc @joperezr

Thanks for the report, @lawrencek76 . I'm pretty sure this is fixed in our latest release 8.2.2. Can you try updating to 8.2.2 and verifying? Alternatively, can you share a minimal repro that we can use in case you are still seeing issues?

Scratch that, just saw you have a repro 😄, sorry for not reading through. I'll validate that this is fixed there.

I see what the issue is here. In your repro project, your CPM file is named using lowercase-syntax: directory.packages.props instead of Directory.Packages.props which is what the SDK and NuGet will look for and automatically import. If you are on a case-sensitive OS (like Linux) then your CPM file will not get imported and result in issues of package references not having their versions defined. You hit this issue with Aspire first because it happens that Aspire is one of the first ones that is trying to load a package version, but you'd hit this issue as well with a non-aspire project as well as versions from your CPM file won't be used at all.

I submitted a PR to your repo with the fix. Please pull that and validate that the issue is fixed: https://github.com/lawrencek76/test-aspire/pull/1
Thanks again for reporting this @lawrencek76, I'm closing this as it isn't really a bug in Aspire, that said, please feel free to reopen if you have any follow up questions :).


Code quality fix - Constant names should comply with a naming convention.

This pull request is focused on resolving occurrences of Sonar rule
squid:S00115 - Constant names should comply with a naming convention.
You can find more information about the issue here:
https://dev.eclipse.org/sonar/rules/show/squid:S00115
Please let me know if you have any questions.
Faisal Hameed

@faisal-hameed I used lower case  for the  Type definition has another purpose, in the JSP page, I used it combined to the alert- prefix for css.
eg.  Created a AlertMessage, Type.info
In the page, there is a alert-info css will be applied in the message panel.
Please read the template.jsp code in the webapp folder.

For compatibility, you can define the enum as "
 Type{
     INFO("info"), WARN("warning");

    String type;
    class Type(String type){this.type= type;}
     public String toString(){
         return this.type;
     }
 }


Feature: Search capability

Pertaining WasmEdge #3504
This PR aims to add search capabilities to the RAG API Server. This functionality will be enabled through the search feature. It will also leverage the llamaedge-query-server to deliver nuanced search queries and provide the RAG API Server something to fall back on in case the RAG fails due to no RAG query matches.

Hello, I am a code review agent on flows.network.
It could take a few minutes for me to analyze this PR. Relax, grab a cup of coffee and check back later. Thanks!

@suryyyansh Please fix the CI failure. Thank you!

Hi @suryyyansh
Could you please write documentation on how to use the search API server? Thanks. https://github.com/LlamaEdge/docs
Is there a GitHub repo called search-api-server? If so, could you please send us your repo link and add README.md about the project? Thanks.

@suryyyansh Could you please fix the conflicts? Thanks a lot.

@suryyyansh Could you please rebase this PR onto the latest code. Thanks a lot!


OpenSearch Spec and Client Generation

This issue describes a roadmap for generating API specs and clients for OpenSearch. Each issue linked has a detailed description of the part.

[ ] Convert legacy rest-api-spec in OpenSearch to Smithy models. - https://github.com/opensearch-project/opensearch-api-specification/issues/80
[ ] Test the generated Smithy models for accuracy with the server with the current test framework in the opensearch-api-specification repo.
[ ] Explore the use of already existing yml test cases[1] to test the Smithy models.
[ ] Implement workflow to auto-update specs when a change is made to Smithy models. - https://github.com/opensearch-project/opensearch-api-specification/issues/74
[ ] Publish OpenAPI specs. - https://github.com/opensearch-project/opensearch-api-specification/issues/34
[ ] Deprecate the rest-api-spec in OpenSearch. - https://github.com/opensearch-project/OpenSearch/issues/4027
[ ] Write client generators for different programming language clients to generate all or selected new/missing APIs. - https://github.com/opensearch-project/opensearch-clients/issues/19
[ ] With the flood of APIs generated in the clients, explore the possibility of an automated test case generation with a common test case data. For example, if the test data resides in opensearch-api-specification repo, use this test data in all clients to test against the server for those APIs. This will help get test coverage with reduced manual effort. See if yml files from [1] can be used similar to the rust client.
[ ] Update the clients when a change is made to the Smithy models. - https://github.com/opensearch-project/opensearch-api-specification/issues/74
[ ] Implement continuous integration framework for generated clients.
[ ] Modify client generators to generate existing APIs in clients and maintain backwards compatibility.
[ ] Extensions support for clients. - https://github.com/opensearch-project/opensearch-clients/issues/55
[ ] https://github.com/opensearch-project/opensearch-api-specification/issues/84

Client Generators

[ ] Java - https://github.com/opensearch-project/opensearch-java/issues/284
[ ] Ruby - https://github.com/opensearch-project/opensearch-ruby/issues/139
[ ] Python - https://github.com/opensearch-project/opensearch-py/issues/348
[ ] Go - https://github.com/opensearch-project/opensearch-go/issues/284

[1] - https://github.com/opensearch-project/OpenSearch/tree/main/rest-api-spec/src/main/resources/rest-api-spec/test

I opened https://github.com/opensearch-project/opensearch-api-specification/issues/84 for API versioning. I think we may want to resolve that one earlier than later.

I opened opensearch-project/opensearch-api-specification#84 for API versioning. I think we may want to resolve that one earlier than later in order to enable clients to have a strong schema against various versions and flavors of OpenSearch.

Makes sense. Moving it up the list.

Closing this in favor of #19 which encompasses most work here.


add progressive and copy options as jpegtran supports

In this libjpeg-turbo/libjpeg-turbo#153 issue, flags and options have been added to the jpegtran lib to enable progressive encoding and not copy markers.
So I add a corresponding api. Hope it helps.

Thanks for this, but why only COPYNONE?  I need COPYALL :-).


auto commit off ?

Hi,
Thank you for this wonderful library,
Sadly this auto commits the operation,
Is it possible to add a way to explicitly call the commit Connection.commit()

My bad,
Finally it depends on aspw,
Sorry 😅
https://rogerbinns.github.io/apsw/example.html


Move babel runtime transform plugin to devDependencies

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
134

Relevant Lines:
134

💛  - Coveralls


code sample on readme doc doesn't iterate

I could be wrong since I'm generally new to this language and started playing around with this library the function
func ExampleScrape() {
  doc, err := goquery.NewDocument("http://metalsucks.net")
  if err != nil {
    log.Fatal(err)
  }

  doc.Find(".reviews-wrap article .review-rhs").Each(func(i int, s *goquery.Selection) {
    band := s.Find("h3").Text()
    title := s.Find("i").Text()
    fmt.Printf("Review %d: %s - %s\n", i, band, title)
  })
}

doesn't acutally iterate on the .Each(). Maybe metalsucks's design changed since this was written and those selctors are no longer valid?

Thanks for the heads-up, indeed the structure of the website did change.


[HTML]  element docs tasks for Fx 70

Trello: https://trello.com/c/KZ1QBGnm/30-input-element-improvements-fx-70
Acceptance criteria

[x] Make available and enable password generation on desktop

Added to Fx 70 release notes

Added Fx70 info to Turning off form autocompletion

Does not affect BCD, as this attribute value was supported as of Fx67. This new behavior is not part of the spec.


Fix section filter

Tasks:

https://app.clickup.com/t/861n0aq0h
https://app.clickup.com/t/863h46j7u

Lodash is added to compare the form's current values with the default values. I and @lukasvice couldn't find a different solution. With tree-shaking the bundle size increase of React UI should be minimal.

@alexlanz I get an SSL error when I try to load https://243.react-ui.aboutbits.dev

@devgioele the preview deployment has failed because it was not able to build-storybook. See logs here: https://github.com/aboutbits/react-ui/actions/runs/5609710624/jobs/10263833203?pr=243

Have a look now, please

Lodash is added to compare the form's current values with the default values. @lukasvice and I couldn't find a different solution. With tree-shaking the bundle size increase of React UI should be minimal.

It is really nice to see that you think also of such points! Great job @devgioele! 🔥 And it helps the reviewer a lot when you highlight such important points.


[@sapphire/plugin-i18next] Fixed loading of languages that do not use hyphens

Summary
When using the i18next plugin, even though I inserted "ja(Japanese)" in the language directory, it was not actually loaded and the following error occurred.
2021-09-18 21:53:34 - ERROR - Encountered error on command "example" at path "/src/commands/General/help.js" ReferenceError: Invalid language provided
2021-09-18 21:53:34 - ERROR -     at InternationalizationHandler.format (/node_modules/@sapphire/plugin-i18next/dist/lib/InternationalizationHandler.js:194:19)
2021-09-18 21:53:34 - ERROR -     at Object.resolveKey (/node_modules/@sapphire/plugin-i18next/dist/lib/functions.js:52:36)
2021-09-18 21:53:34 - ERROR -     at processTicksAndRejections (node:internal/process/task_queues:96:5)
2021-09-18 21:53:34 - ERROR -     at async HelpCommand.run (/src/commands/General/help.js:28:29)
2021-09-18 21:53:34 - ERROR -     at async CoreListener.run (/node_modules/@sapphire/framework/dist/listeners/command-handler/CoreCommandAccepted.js:15:28)
2021-09-18 21:53:34 - ERROR -     at async CoreListener._run (/node_modules/@sapphire/framework/dist/lib/structures/Listener.js:92:13)

The directory structure is as follows.
/
    src
        commands
            General
                example.js
        languages
            en-US
            ja
        main.js
    package.json
    package-lock.json

So I traced the error and found out that the function "walkLanguageDirectory" has a variable "isLanguage" which is the result of judging whether the language directory is a language directory or not, based on whether the language directory has a hyphen or not.
// This structure may very well be changed in future.
// See i18next/i18next-fs-backend#13
const isLanguage = fn.includes('-');
if (isLanguage) languages.push(fn);

So I made a list of the languages available in the existing Discord and edited the array to add a language if it matches the directory.
The following is the code that picks up the changes.
const availableLanguages: string[] = ['en-US', 'en-GB', 'zh-CN', 'zh-TW', 'cs', 'da', 'nl', 'fr', 'de', 'el', 'hu', 'it', 'ja', 'ko', 'no', 'pl', 'pt-BR', 'ru', 'es-ES', 'sv-SE', 'tr', 'bg', 'uk', 'fi', 'hr', 'ro', 'lt'];

const isLanguage = availableLanguages.includes(fn);

For a list of languages, see the following website.
https://discord.com/developers/docs/dispatch/field-values#predefined-field-values-accepted-locales

Hardcoding a list of valid languages is NOT a good solution. People represent these languages in many different ways - with caps, without caps, with hyphens, etc, which are all valid with the right i18next-fs-backend options.
We need to explore other options - or, alternatively, we could treat any end directory with no subdirectories as a language. In any case, we need a more concrete solution.

Copy that.
I'll look into another solution.

For @sapphire/plugin-i18next we follow the standardized format of <ISO-639-1 language code>-<ISO3166-1 Country Code> for the language directories.
Examples of valid languages codes are:
- de-DE for German as spoken in Germany
- en-GB for English as spoken in Great Britain
- en-US for English as spoken in The United States
- es-ES for Spanish as spoken in Spain
- fa-IR for Persian as spoken in Iran
- pt-BR for Portuguese as spoken in Brazil
- es-MX for Spanish as spoken in Mexico
- hi-IN for Hindi as spoken in India
- hi-Latn-IN for Hindi, but using Latin characters, as spoken in India (also known as Hinglish)
- ja-JP for Japanese as spoken in Japan
- nb-NO for Norwegian Bokmal as spoken in Norway
- nl-NL for Dutch as spoken in The Netherlands
- ro-RO for Romanian as spoken in Romania
- ru-RU for Russian as spoken in Russia
- sl-SI for Slovenian as spoken in Slovenia
- tr-TR for Turkish as spoken in Turkey


Update tested Python and Django versions.

Remove tox configuration file.
Add Python 3.7, Django 2.1, and Django 2.2 to Travis-CI configuration file and setup classifiers.

I've updated this pull request with Python 3.8 as well.
Since Django 3.0 removes some Python 2 compatibility functions that django-flatblocks currently uses and since the official recommendation is to drop Django 1.11 and Python 2 support when adding Django 3.0 support, I have not added it.

LGFM!


useSortable transition and animation does not smooth drag & drop as demonstrated in the demo

Hello. In this demo,
cards are being shown smoothly switching places as they are being dragged and dropped. This does not seem to happen by default when configured as described by this docs page. Attached is a minimal reproducible example repo and a video of what im talking about
https://github.com/GNUGradyn/dnd-kit-mre
https://github.com/clauderic/dnd-kit/assets/20762604/a932a0b4-c28d-4ec1-b4a1-bd5c02f1cad6

Another thing I just noticed is the library is adding --translate-x and --translate-y when items are sorted in the demo. This does not appear to happen by default (see my MRE). Since there is no translate property being added the transition is not doing anything
https://github.com/clauderic/dnd-kit/assets/20762604/1bc56454-b0bd-4b3d-af46-149959ef7a4a
https://github.com/clauderic/dnd-kit/assets/20762604/fadd9196-4a0d-47e5-9809-4b9b7745e97c

It's because you didn't specify a key on your Sortable component:
 <SortableContext items={items} strategy={horizontalListSortingStrategy}>           {items.map(x => (               <Sortable id={x} key={x} />           ))}         </SortableContext>

Thanks. This fixed it. Might be worth documenting not having a key prop will break animations


rename PowerMockito#mock to PowerMockito#powermock

From<EMAIL_ADDRESS>on August 12, 2009 15:42:26
I'd like to suggest renaming the PowerMockito#mock methods to
PowerMockito#powermock. The reason for this is to allow the PowerMockito
and vanilla Mockito mock methods both to be used through static imports.
Currently you can only use one of them in this way per compilation unit.
It seems reasonable to restrict usage of PowerMock mocking to those classes
that actually need it, and avoid the @PrepareForTest arguments for those
classes that can be mocked using Mockito.
Backwards compatibility needn't be an issue; leave the current methods and
deprecate them, delegating to powermock().
Aside:
On the other hand, perhaps a more complete solution would be to do away
with the PowerMockito methods all together, instead mocking the Mockito
class to work for all classes that PowerMockito is able to mock, allowing
the user to say Mockito#mock(String.class) or whatever and leaving the
PowerMock infrastructure to decide what to do.
(This is an enhancement request, not a defect.)
Original issue: http://code.google.com/p/powermock/issues/detail?id=138

From<EMAIL_ADDRESS>on August 12, 2009 07:46:54
Thanks for your input. We will take it into consideration when developing the
PowerMockito extension in PowerMock 1.3. Our goal is to have much improved support
for Mockito in 1.3.
The reason why the method is called the same as in plain Mockito is that we'd like
PowerMockito to be a replacement for Mockito where needed. EasyMock classextensions
provides the same mechanism for plain EasyMock , i.e. just replace the
EasyMock#createMock method with EasyMockClassExtension#createMock method to support
the mocking of classes. The class extensions then delegates to plain EasyMock if the
type is an interface. The philosophy for PowerMockito has been along these lines as
well so far.
Labels: -Type-Defect Type-Enhancement Milestone-Release1.3

From<EMAIL_ADDRESS>on August 12, 2009 08:02:32
Ah, so is the intention that all mocking when using PowerMock and Mockito should go
through PowerMockito, even when the class is non-final etc. and can be handled
normally by Mockito, but only requiring the @PrepareForTest annotation for those
classes that need special treatment?
That makes sense. Thanks for clarifying that.

From<EMAIL_ADDRESS>on August 12, 2009 23:18:27
Yes that's the intention. You can still mix and match Mockito and PowerMockito, only
using the features of PowerMockito when you need them. At least that's the goal :)

From<EMAIL_ADDRESS>on September 01, 2009 06:20:43
Status: WontFix


Missing rounding conversion operators

Why don't these work?
https://godbolt.org/z/5ExhKM9d3

Another seemingly-missing conversion: https://godbolt.org/z/Er6Mforaa


Multiple sequential actions cause asyncio TimeoutError

Rasa version: 1.2.4
Rasa SDK version: 1.2.0
Python version: Python 3.6.9 (Anaconda 4.5.13)
Operating system : Win10, 64bit
Issue:
Multiple sequential actions (I would say 4 and more)  in row in one story lead to Task exception was never retrieved error (see traceback).
Story:
## FULL 1b
* want_search
    - action_search_start_print_utter
    - action_search_start_print_utter
    - action_search_start_print_utter
    - action_search_start_print_utter
    - action_search_start_print_utter

Action:
class ActionSearchStartPrintUtter(Action):
    def name(self):
        return "action_search_start_print_utter"

    def run(self, dispatcher, tracker, domain):
        dispatcher.utter_template("utter_lets_do_it", tracker)
        return []

Command or request that led to error:
[Rasa]
rasa shell --credentials credentials.yml --endpoints endpoints.yml --port 4444  --log-file logs/out.log --debug  --verbose

[SDK]
python -m rasa_sdk --actions action_sdk.actions --verbose --debug

Error (including full traceback):
2019-09-03 21:17:53 INFO     root  - Connecting to channel 'cmdline' which was specified by the '--connector' argument. Any other channels will be ignored. To connect to all given channels, omit the '--connector' argument.
2019-09-03 21:17:53 INFO     root  - Starting Rasa server on http://localhost:4444
Bot loaded. Type a message and press enter (use '/stop' to exit):
Your input ->  neco hledam

2019-09-03 21:18:14 WARNING  root  - Could not parse timestamp c1f48ac98a26479687b85d9aa9e1c2ec. Instead current UTC time will be passed to duckling. Error: invalid literal for int() with base 10: 'c1f48ac98a26479687b85d9aa9e1c2ec'
Lets do this
Lets do this
Lets do this
2019-09-03 21:18:22 ERROR    asyncio  - Task exception was never retrieved
future: <Task finished coro=<configure_app.<locals>.run_cmdline_io() done, defined at c:\users\tomas\anaconda3\envs\eqs_chatbot\lib\site-packages\rasa\core\run.py:122> exception=TimeoutError()>
Traceback (most recent call last):
  File "c:\users\tomas\anaconda3\envs\eqs_chatbot\lib\site-packages\rasa\core\run.py", line 126, in run_cmdline_io
    server_url=constants.DEFAULT_SERVER_FORMAT.format(port)
  File "c:\users\tomas\anaconda3\envs\eqs_chatbot\lib\site-packages\rasa\core\channels\console.py", line 138, in record_messages
    async for response in bot_responses:
  File "c:\users\tomas\anaconda3\envs\eqs_chatbot\lib\site-packages\async_generator\_impl.py", line 366, in step
    return await ANextIter(self._it, start_fn, *args)
  File "c:\users\tomas\anaconda3\envs\eqs_chatbot\lib\site-packages\async_generator\_impl.py", line 205, in throw
    return self._invoke(self._it.throw, type, value, traceback)
  File "c:\users\tomas\anaconda3\envs\eqs_chatbot\lib\site-packages\async_generator\_impl.py", line 209, in _invoke
    result = fn(*args)
  File "c:\users\tomas\anaconda3\envs\eqs_chatbot\lib\site-packages\rasa\core\channels\console.py", line 103, in send_message_receive_stream
    async for line in resp.content:
  File "c:\users\tomas\anaconda3\envs\eqs_chatbot\lib\site-packages\aiohttp\streams.py", line 40, in __anext__
    rv = await self.read_func()
  File "c:\users\tomas\anaconda3\envs\eqs_chatbot\lib\site-packages\aiohttp\streams.py", line 329, in readline
    await self._wait('readline')
  File "c:\users\tomas\anaconda3\envs\eqs_chatbot\lib\site-packages\aiohttp\streams.py", line 297, in _wait
    await waiter
  File "c:\users\tomas\anaconda3\envs\eqs_chatbot\lib\site-packages\aiohttp\helpers.py", line 585, in __exit__
    raise asyncio.TimeoutError from None
concurrent.futures._base.TimeoutError

Rasa SDK output (if needed):
2019-09-03 21:16:20 INFO     rasa_sdk.endpoint  - Action endpoint is up and running. on ('<IP_ADDRESS>', 5055)
2019-09-03 21:18:16 DEBUG    rasa_sdk.executor  - Received request to run
2019-09-03 21:18:16 DEBUG    rasa_sdk.executor  - Finished running 'action_search_start_print_utter'
<IP_ADDRESS> - - [2019-09-03 21:18:16] "POST /webhook HTTP/1.1" 200 200 0.032939
2019-09-03 21:18:18 DEBUG    rasa_sdk.executor  - Received request to run
2019-09-03 21:18:18 DEBUG    rasa_sdk.executor  - Finished running 'action_search_start_print_utter'
<IP_ADDRESS> - - [2019-09-03 21:18:18] "POST /webhook HTTP/1.1" 200 200 0.019048
2019-09-03 21:18:20 DEBUG    rasa_sdk.executor  - Received request to run
2019-09-03 21:18:20 DEBUG    rasa_sdk.executor  - Finished running 'action_search_start_print_utter'
<IP_ADDRESS> - - [2019-09-03 21:18:20] "POST /webhook HTTP/1.1" 200 200 0.018976
2019-09-03 21:18:22 DEBUG    rasa_sdk.executor  - Received request to run
2019-09-03 21:18:22 DEBUG    rasa_sdk.executor  - Finished running 'action_search_start_print_utter'
<IP_ADDRESS> - - [2019-09-03 21:18:22] "POST /webhook HTTP/1.1" 200 200 0.014997
2019-09-03 21:18:24 DEBUG    rasa_sdk.executor  - Received request to run
2019-09-03 21:18:24 DEBUG    rasa_sdk.executor  - Finished running 'action_search_start_print_utter'
<IP_ADDRESS> - - [2019-09-03 21:18:24] "POST /webhook HTTP/1.1" 200 200 0.008981

When I change story to:
## FULL 1b
* want_search
    - utter_lets_do_it
    - utter_lets_do_it
    - utter_lets_do_it
    - utter_lets_do_it
    - utter_lets_do_it

and don't use custom actions, it works properly:
2019-09-03 21:45:21 INFO     root  - Connecting to channel 'cmdline' which was specified by the '--connector' argument. Any other channels will be ignored. To connect to all given channels, omit the '--connector' argument.
2019-09-03 21:45:21 INFO     root  - Starting Rasa server on http://localhost:4444
Bot loaded. Type a message and press enter (use '/stop' to exit):
Your input ->  neco hledam

2019-09-03 21:45:28 WARNING  root  - Could not parse timestamp 2eaa916a3aa74cbb99dbfd18e1cfbd6c. Instead current UTC time will be passed to duckling. Error: invalid literal for int() with base 10: '2eaa916a3aa74cbb99dbfd18e1cfbd6c'
Lets do this
Lets do this
Lets do this
Lets do this
Lets do this
Your input ->

Original story and using run command (which starts socket channel):
rasa run --credentials credentials.yml --endpoints endpoints.yml --log-file logs/out.log

it also works properly.
There is probably problem between rasa sdk and shell.

Thanks for raising this issue, @msamogh will get back to you about it soon✨
Please also check out the docs and the forum in case your issue was raised there too 🤗

It looks like it could be a bug.

@msamogh Did you manage to reproduce it? Could you please label the issue accordingly?

@msamogh What's the state on this? Could you reproduce it?

@wochinge No, I was not able to reproduce this with this example, but I remember experiencing it when using PDB to debug my Rasa code, and if I lingered for too long in the middle of the code responsible for communicating with the action server, I would get this TimeoutError.

and if I lingered for too long in the middle of the code responsible for communicating with the action server, I would get this TimeoutError.

well, that also makes sense right? 😄

Okay I wasn't sure if that was expected behavior. If it is, then no, I was not able to reproduce this.

@tocosastalo Any updates on that? I'd close it for now otherwise.

Ah, I think it found the problem. @tocosastalo Could it be that these 5 actions run for longer than 10 seconds? Then there is indeed a timeout which is triggered. We could set that higher, but not sure how relevant that is since a bot should respond in < 10 seconds?

@wochinge yes you are right. Timeout is triggered after 10 seconds.

I am using several actions in a sequence in specific cases (for example, if I need to differentiate whether the user has done this intent before (and ask whether use previous result) or whether slots in action have been set, ...):
### Happy 1
* want_search OR enter_search_query
    - action_preserve_search_slots
    - action_check_last_search
    - slot{"has_last_search": false}
    - action_fill_preserved_search_slots
    - action_search_start_print_utter
    - search_query_form
    - form{"name": "search_query_form"}
    - form{"name": null}
    - action_fetch_keyword_suggestions
    - action_ask_more_keywords_mode
> check_asked_more_keywords_mode

But I don't mind, because it looks like it works in another channel (I use console channel only for debugging).

@tocosastalo But did you check the runtime of your actions? If 5 actions take 10 seconds, then it's also quite bad for the users with the other channels and I'd suggest checking if you can make that somehow more efficient.

I would say that generally run mode takes the same action less time than in shell mode in my environment. So users of other channels are not very affected.
Returning to the beginning of the issue, the action was as simple as it could have been - it utters one text-only template:
class ActionSearchStartPrintUtter(Action):
    def name(self):
        return "action_search_start_print_utter"

    def run(self, dispatcher, tracker, domain):
        dispatcher.utter_template("utter_lets_do_it", tracker)
        return []

Story was also very simple:
* want_search
    - action_search_start_print_utter
    - action_search_start_print_utter
    - action_search_start_print_utter
    - action_search_start_print_utter
    - action_search_start_print_utter

And it hit the timeout limit in shell mode. In run mode it is done in 1 second. I thought it was a bug, but it would be a problem on my side. I think we can close this.

I'm having same issue using shell.  So should I ignore shell and just use run for testing?

@ShaunHolt This is related to https://github.com/RasaHQ/rasa/issues/4606 . There will be fix in the next release https://github.com/RasaHQ/rasa/pull/5686

Thank you. I am enjoying Rasa.  A wonderful learning experience.
Get Outlook for Android
On Mon, Apr 27, 2020 at 2:52 AM -0400, "Tobias Wochinger"<EMAIL_ADDRESS>wrote:
@ShaunHolt This is related to #4606 . There will be fix in the next release #5686
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.


Support for Nginx

I would like to have the Nginx config if possible

I will try to add a snippet as soon as I get some free time.


Use inside general.php

Question
I am trying to load a built css file in my general.php file. What's the PHP version of {{ craft.vite.entry("app.css") }}?

I think you probably should not be loading CSS inside of your config/general.php file but:
Vite::$plugin->viteService->entry($path)

https://github.com/nystudio107/craft-plugin-vite/blob/develop/src/variables/ViteVariableTrait.php#L83

Here is some context: I am using doublesecretagency/craft-cpcss plugin to load some custom styling in the control panel, which I generate using Vite. In it's settings I am referencing a custom alias @controlPanelCss.
In the general.php file I have this:

use craft\helpers\App;
use nystudio107\vite\Vite;

return [
    ...
    'aliases' => [
        ...
        '@controlPanelCss' => App::env('SITE_URL') . Vite::$plugin->vite->entry('src/js/website-styles.css'),
        ...
    ],
    ...
];

But now I get this error:
Fatal error: Uncaught Error: Typed static property nystudio107\vite\Vite::$plugin must not be accessed before initialization in /var/www/html/cms/config/general.php:15 Stack trace: #0 /var/www/html/cms/vendor/craftcms/cms/src/services/Config.php(277): include() #1 /var/www/html/cms/vendor/craftcms/cms/src/services/Config.php(269): craft\services\Config->_configFromFileInternal('/var/www/html/c...') #2 /var/www/html/cms/vendor/craftcms/cms/bootstrap/bootstrap.php(166): craft\services\Config->getConfigFromFile('general') #3 /var/www/html/cms/vendor/craftcms/cms/bootstrap/web.php(40): require('/var/www/html/c...') #4 /var/www/html/cms/web/index.php(11): require('/var/www/html/c...') #5 {main} thrown in /var/www/html/cms/config/general.php on line 15

Any thoughts?

Plugins are not loaded yet when general.php is executed.
I'd suggest just writing a little custom module to load your CSS, ala: https://github.com/nystudio107/craft/blob/craft-vite/cms/modules/sitemodule/src/SiteModule.php#L111

Thanks! I will pursue this path.


Update index - Copy (10).md

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

realtimeinsighttest/1/index - Copy (10).md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Add testing ByteBufAllocator for leak unit testing

Motivation:
Currently the only way to detect leaks during testing is log scanning which is
difficult to automate.  As an alternative it would be nice to fail unit tests
that leak buffers.
Modifications:
Added try with resources friendly TestingPooledByteBufAllocator which throws
an AssertionError in close if all buffers have not been freed.  To implement
this, I modified modified ResourceLeakDetector to allow sub clases to force
tracking and error reporting regardless of the global static tracking level,
or the configuration of the logging system.  I also added a method to allow
sub classes to dispose of all tracked references, which triggers reporting
if the referant was not freed. Then I modified, AbstractByteBufAllocator and
PooledByteBufAllocator to allow package local sub classes to hook the call to
the global static toLeakAwareBuffer methods.  Finally, I added
TestingPooledByteBufAllocator which is a subclass of PooledByteBufAllocator
containing a private ResourceLeakDetector that always tracks and warns on
leaks.
Result:
Developers using Netty can now easily verify that all buffers have been
released in unit tests.

BTW, I attempted to make the smallest addition to public APIs in this change.  They are limited to the new protected methods on ResourceLeakDetector, which are required because it is in a different package from the buffer allocators, and the new TestingPooledByteBufAllocator.  As an alternative to this implementation, you might may want to add a constructor to the allocators that allow the ResourceLeakDetector to be set to an instance level instead of requiring, and the "hook" methods I added.  Additionally, you may want to add a new constructor to ResourceLeakDetector that force enables resource tracking.

@netty-bot test this please

I updated the code to not call the super reportTracedLeak method as this logs a LEAK message which causes the build to fail.  Instead the new version stores the leak records and then throws an AssertionError containing all of the leaks in a single message, and the tests simply verify the message without printing.  Here is an example of the output you will get if the AssertionError is not caught https://gist.github.com/dain/5fece0946d7a1439b535a7af775f5a57

Retrieving log messages in a test is a pain, and this is a great idea, but

I don't like how it's specific to ByteBufAllocator. Leak detector is used in other places. Seems like it should be a feature of the leak detector.
There is a ResourceLeakDetector.setLevel which should obviate the changes to AbstractByteBufAllocator.
The feature of the leak detector can be boiled down to having it write to a stringbuilder instead of a log, and offer a public method to reportLeaks as an assertion error. Asserting the sb is empty is the same as asserting on a list of strings.

@almson the approach you are suggestion has a few problems for my testing environment:

My tests are executed concurrently to reduce build latencies, and the existing resource detection system is a global static, so leaks from one test can pollute results from another.
The existing leak detector requires that an buffer be GCed, before a leak can be detected.  Since there can be a leak in a hard reference to a buffer, the object may never be GCed.  This change checks that all tracked objects are collected at the end of the test.

@dain

How do you execute your tests concurrently? Might not forkMode resolve the issue of statics? There's plenty of other statics all over the place.
You're right that reportLeaks looks in refQueue while your disposeAllReferences looks in allLeaks. That's fine. My point is that such a method can be added directly to ResourceLeakDetector (named, "assertAllResourcesReleased" or somesuch) and properly documented without making the class any worse for it. This way, someone else stands a chance of discovering this functionality. It might even be useful in production (asserts often are.)

Btw, I'm not a core contributor, so don't take my criticism too seriously, but I did muck about in ResourceLeakDetector quite a bit just recently.

How do you execute your tests concurrently? Might not forkMode resolve the issue of statics? There's plenty of other statics all over the place.

We use multithreaded Maven tests and use the TestNG framework.  In my experience, forkMode option isn't great for fine grained parallelism (each test method could be creating an allocator), and not something the project uses.

You're right that reportLeaks looks in refQueue while your disposeAllReferences looks in allLeaks. That's fine. My point is that such a method can be added directly to ResourceLeakDetector (named, "assertAllResourcesReleased" or somesuch) and properly documented without making the class any worse for it. This way, someone else stands a chance of discovering this functionality.

I agree.  In a comment above, I mention that I tried to limit the additions to the public interfaces of this project, but in the long run, it might be better to explicitly support this without needing to subclass the allocator and resource tracker.

@normanmaurer updated.  Can you take another look?

My alternate proposal: https://github.com/netty/netty/pull/8431

Let me close this ... I think a better approach would be to do something with a RunListener: https://junit.org/junit4/javadoc/4.12/org/junit/runner/notification/RunListener.html


Updated monitoring.md

Added official Zabbix monitoring integrations.

@RogerTheUnicornHive Please sign the Contributor License Agreement!
Click here to manually synchronize the status of this Pull Request.
See the FAQ for frequently asked questions.

@RogerTheUnicornHive Thank you for signing the Contributor License Agreement!

Thank you!


gdal2 v2

Done:

Seperated ogerext / ograpi for gdal1 and 2.
Ported ogrext / ograpi to gdal2
Replace  OGR_DETECTED_ENCODING/OLC_STRINGSASUTF8 to utf8 for gdal2
Detect gdal2 in setup.py and copy the right implementation

Open issues:

Gdal switch for windows builds (no gdal-config --version available)
Internal handling of bigints (32/64bit Python 2x)
Add tests

@rbuffat do you want to take on the open issues within this PR or are they better done in new branches?

@sgillies  a seperate branch would be nice, especially as this enables other to contribute more easily

I've tested these changes in the fiona Debian package, and I needed these additional patches to make the build with GDAL 2.0.1 succeed:
$ cat debian/patches/0004-clean-setup.patch
Description: Don't cythonize in clean target.
 Just like [rasterio](https://github.com/mapbox/rasterio/blob/master/setup.py#L141)
Author: Bas Couwenberg<EMAIL_ADDRESS>
--- a/setup.py
+++ b/setup.py
@@ -131,7 +131,7 @@ ext_options = dict(
     extra_link_args=extra_link_args)

 # When building from a repo, Cython is required.
-if os.path.exists("MANIFEST.in"):
+if os.path.exists("MANIFEST.in") and "clean" not in sys.argv:
     log.info("MANIFEST.in found, presume a repo, cythonizing...")
     if not cythonize:
         log.critical(

$ cat debian/patches/0005-builtins.patch
Description: Use __builtin__ module for Python 2.
 Fixes exception:
  ImportError: No module named builtins
Author: Bas Couwenberg<EMAIL_ADDRESS>
--- a/fiona/ogrext2.pyx
+++ b/fiona/ogrext2.pyx
@@ -23,7 +23,11 @@ from fiona.rfc3339 import FionaDateType,

 from libc.stdlib cimport malloc, free
 from libc.string cimport strcmp
-from builtins import int
+
+if sys.version_info > (3,):
+    from builtins import int
+else:
+    from __builtin__ import int

 log = logging.getLogger("Fiona")
 class NullHandler(logging.Handler):
--- a/tests/test_props.py
+++ b/tests/test_props.py
@@ -2,11 +2,16 @@ import json
 import os.path
 from six import text_type
 import tempfile
+import sys

 import fiona
 from fiona import prop_type, prop_width
 from fiona.rfc3339 import FionaDateType
-from builtins import int
+
+if sys.version_info > (3,):
+    from builtins import int
+else:
+    from __builtin__ import int

 def test_width_str():
     assert prop_width('str:254') == 254

@sebastic
Regarding the builtins import: I used the information from http://python-future.org/what_else.html#int.  On the CI we test for Python 2.7, 3.3 and 3.4 and it does not fail: https://travis-ci.org/Toblerity/Fiona/builds/87333488
I'm courious why it fails for you.

@sgillies seems like the issues about gdal2 start to increase.
I added the argument "gdalversion" to setup.py for cases when gdal-config is not available. Do you know someone that builds fiona for windows and could test that? E.g. http://www.lfd.uci.edu/~gohlke/pythonlibs/ However it is not done in a nice way. The nice way to do it would be to subclass  command as in https://stackoverflow.com/questions/677577/distutils-how-to-pass-a-user-defined-parameter-to-setup-py However that needs more setup.py refactoring.

On 25-10-15 18:49, René Buffat wrote:

Regarding the builtins import: I used the information from http://python-future.org/what_else.html#int.  On the CI we test for Python 2.7, 3.3 and 3.4 and it does not fail: https://travis-ci.org/Toblerity/Fiona/builds/87333488
I'm courious why it fails for you.

Because the Debian package build environment didn't have python-future
installed, with the patch the future module isn't required.
If the future module will stay as a new requirement it should also be
included in the 'Python Requirements' in the README.rst to match
requirements.txt.

@rbuffat @sebastic I'm :-1: on the future requirement. I think six should cover our needs.
The import of int from builtins can be removed from tests/test_props.py. I'm not sure it's even needed in ogrext2.pyx, to be honest. Let's remove it from that file, too, and only add it if necessary after this PR gets merged.

Replaced by #286.

Coverage remained the same at 72.786% when pulling 01c8b6fff8f0a4a0279b069fad9fff63d98bc1dd on rbuffat:newgdal2 into 3406b623af8058079a0a25a63c0a434c415cbed7 on Toblerity:master.


bump python from 3.11 to 3.12

active support for 3.11 ended ~3 months ago
steps taken

change the PYTHON_VERSION variable which is used by our docker files
run action to build our base image using these changes here

!! after doing this, every branch will be using this base image even before this is merged to main !!

re-run docker image builds in this PR's tests here to use new base image

old base image tag and new base image tag

compile python packages using this branch
run all builds using new python and package versions

is this PR supposed to be a draft? Otherwise ready to approve!

gonna merge to unblock #952


Correction for raw affiliation Obs. de Lyon, CRAL, ENS Lyon, CNRS, Univ. Lyon 1, UMR 5574, 9 avenue Charles André, 69230 Saint-Genis Laval, France

Correction needed for raw affiliation Obs. de Lyon, CRAL, ENS Lyon, CNRS, Univ. Lyon 1, UMR 5574, 9 avenue Charles André, 69230 Saint-Genis Laval, France
raw_affiliation_name: Obs. de Lyon, CRAL, ENS Lyon, CNRS, Univ. Lyon 1, UMR 5574, 9 avenue Charles André, 69230 Saint-Genis Laval, France
new_rors: 029brtt94;02feahw73;04zmssz18;0084x3h80
previous_rors: 029brtt94;02feahw73;04zmssz18
works_examples: W2173379747
contact: 1a7142c577230f5e189d2c60e941cf6e:8c2455e16e5bbed04165b7de9059 @ ens-lyon.fr

This issue was accepted and ingested by the OpenAlex team on 2024-12-19. The new affiliations should be visible within the next 7 days.


Prepare for 24.05

This will succeed once https://hydra.nixos.org/job/nixos/release-24.05/tested has a finished job

Perhaps I should use https://hydra.nixos.org/jobset/nixos/release-24.05-small instead?