Problem with Setting Up Habitat-Sim

Things I'm using

Ubuntu 16.04.1
Miniconda
Habitat-Sim already cloned

Steps to reproduce

conda create -n habitat python=3.6 cmake=3.14.0
conda activate habitat
cd habitat-sim
pip install -r requirements.txt
python setup.py install --headless

Observed Results
running install
running bdist_egg
running egg_info
writing habitat_sim.egg-info/PKG-INFO
writing dependency_links to habitat_sim.egg-info/dependency_links.txt
writing requirements to habitat_sim.egg-info/requires.txt
writing top-level names to habitat_sim.egg-info/top_level.txt
reading manifest file 'habitat_sim.egg-info/SOURCES.txt'
writing manifest file 'habitat_sim.egg-info/SOURCES.txt'
installing library code to build/bdist.linux-x86_64/egg
running install_lib
running build_py
running build_ext
[0/1] Re-running CMake...
CMake Warning at deps/glog/CMakeLists.txt:49 (find_package):
  By not providing "Findgflags.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "gflags", but
  CMake did not find one.

  Could not find a package configuration file provided by "gflags" (requested
  version 2.2.0) with any of the following names:

    gflagsConfig.cmake
    gflags-config.cmake

  Add the installation prefix of "gflags" to CMAKE_PREFIX_PATH or set
  "gflags_DIR" to a directory containing one of the above files.  If "gflags"
  provides a separate development package or SDK, be sure it has been
  installed.

-- Shared libraries disabled
-- Looking for ZLIB...
-- Checking for module 'zzip-zlib-config'
--   No package 'zzip-zlib-config' found
-- Found ZLIB: optimized;/usr/lib/x86_64-linux-gnu/libz.so;debug;/usr/lib/x86_64-linux-gnu/libz.so
-- Checking for module 'minizip'
--   No package 'minizip' found
-- Enabled formats: AMF 3DS AC ASE ASSBIN ASSXML B3D BVH COLLADA DXF CSM HMP IRRMESH IRR LWO LWS MD2 MD3 MD5 MDC MDL NFF NDO OFF OBJ OGRE OPENGEX PLY MS3D COB BLEND IFC XGL FBX Q3D Q3BSP RAW SIB SMD STL TERRAGEN 3D X X3D GLTF 3MF MMD
-- Disabled formats:
-- Found PythonInterp: /home/zye009/miniconda3/envs/habitat/bin/python (found suitable version "3.6.9", minimum required is "3.6")
-- Bindings being generated for python at /home/zye009/miniconda3/envs/habitat/bin/python
-- Found PythonInterp: /home/zye009/miniconda3/envs/habitat/bin/python (found version "3.6.9")
-- pybind11 v2.3.0
-- Could NOT find EGL (missing: EGL_LIBRARY EGL_INCLUDE_DIR)
CMake Error at deps/magnum/src/Magnum/Platform/CMakeLists.txt:796 (message):
  EGL library, required by some contexts, was not found.  Set
  WITH_*APPLICATION and/or WITH_EGLCONTEXT to OFF to skip building them.

-- Configuring incomplete, errors occurred!
See also "/home/zye009/habitat-sim/build/CMakeFiles/CMakeOutput.log".
See also "/home/zye009/habitat-sim/build/CMakeFiles/CMakeError.log".
FAILED: build.ninja
/home/zye009/miniconda3/envs/habitat/bin/cmake -S/home/zye009/habitat-sim/src -B/home/zye009/habitat-sim/build
ninja: error: rebuilding 'build.ninja': subcommand failed
Traceback (most recent call last):
  File "setup.py", line 368, in <module>
    zip_safe=False,
  File "/home/zye009/miniconda3/envs/habitat/lib/python3.6/site-packages/setuptools/__init__.py", line 145, in setup
    return distutils.core.setup(**attrs)
  File "/home/zye009/miniconda3/envs/habitat/lib/python3.6/distutils/core.py", line 148, in setup
    dist.run_commands()
  File "/home/zye009/miniconda3/envs/habitat/lib/python3.6/distutils/dist.py", line 955, in run_commands
    self.run_command(cmd)
  File "/home/zye009/miniconda3/envs/habitat/lib/python3.6/distutils/dist.py", line 974, in run_command
    cmd_obj.run()
  File "/home/zye009/miniconda3/envs/habitat/lib/python3.6/site-packages/setuptools/command/install.py", line 67, in run
    self.do_egg_install()
  File "/home/zye009/miniconda3/envs/habitat/lib/python3.6/site-packages/setuptools/command/install.py", line 109, in do_egg_install
    self.run_command('bdist_egg')
  File "/home/zye009/miniconda3/envs/habitat/lib/python3.6/distutils/cmd.py", line 313, in run_command
    self.distribution.run_command(command)
  File "/home/zye009/miniconda3/envs/habitat/lib/python3.6/distutils/dist.py", line 974, in run_command
    cmd_obj.run()
  File "/home/zye009/miniconda3/envs/habitat/lib/python3.6/site-packages/setuptools/command/bdist_egg.py", line 172, in run
    cmd = self.call_command('install_lib', warn_dir=0)
  File "/home/zye009/miniconda3/envs/habitat/lib/python3.6/site-packages/setuptools/command/bdist_egg.py", line 158, in call_command
    self.run_command(cmdname)
  File "/home/zye009/miniconda3/envs/habitat/lib/python3.6/distutils/cmd.py", line 313, in run_command
    self.distribution.run_command(command)
  File "/home/zye009/miniconda3/envs/habitat/lib/python3.6/distutils/dist.py", line 974, in run_command
    cmd_obj.run()
  File "/home/zye009/miniconda3/envs/habitat/lib/python3.6/site-packages/setuptools/command/install_lib.py", line 11, in run
    self.build()
  File "/home/zye009/miniconda3/envs/habitat/lib/python3.6/distutils/command/install_lib.py", line 107, in build
    self.run_command('build_ext')
  File "/home/zye009/miniconda3/envs/habitat/lib/python3.6/distutils/cmd.py", line 313, in run_command
    self.distribution.run_command(command)
  File "/home/zye009/miniconda3/envs/habitat/lib/python3.6/distutils/dist.py", line 974, in run_command
    cmd_obj.run()
  File "setup.py", line 195, in run
    self.build_extension(ext)
  File "setup.py", line 263, in build_extension
    shlex.split("cmake --build {}".format(self.build_temp)) + build_args
  File "/home/zye009/miniconda3/envs/habitat/lib/python3.6/subprocess.py", line 311, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['cmake', '--build', 'build', '--config', 'RelWithDebInfo', '--']' returned non-zero exit status 1.

I was thinking it has something with WITH_EGLCONTEXT, but I'm not sure. Any advice?
Expected Results
Build Successful.
Relevant Code
// TODO(you): code here to reproduce the problem

Installing libegl1-mesa-dev should fix that error at least.  Keep in mind that --headless requires an Nvidia GPU with ~modern drivers.

I'm assuming I just have to run apt-get install libegl1-mesa-dev. But the catch is that I don't have root access 😢. Is there a way around this without root access? Or a way to set WITH_EGLCONTEXT to OFF?

EGL is required for --headless, so if you need that, there unfortunately isn't anything we can do.

I see. I tried with python setup.py install too. But now I have this error.
[20/219] Building CXX object deps/magnum/src/Magnum/Shaders/CMakeFiles/MagnumShaders.dir/Flat.cpp.o
[21/219] Building CXX object deps/tinyply/CMakeFiles/example.dir/source/example.cpp.o
[22/219] Building CXX object deps/magnum/src/Magnum/Platform/CMakeFiles/MagnumWindowlessGlxApplication.dir/WindowlessGlxApplication.cpp.o
FAILED: deps/magnum/src/Magnum/Platform/CMakeFiles/MagnumWindowlessGlxApplication.dir/WindowlessGlxApplication.cpp.o
ccache /usr/bin/c++   -I/home/zye009/habitat-sim/src/deps -I/home/zye009/habitat-sim/src/deps/magnum/src/MagnumExternal/OpenGL -I/home/zye009/habitat-sim/src/deps/magnum/src -Ideps/magnum/src -I/home/zye009/habitat-sim/src/deps/corrade/src -Ideps/corrade/src -isystem /home/zye009/habitat-sim/src/cmake/../deps/eigen-git-mirror -isystem /home/zye009/habitat-sim/src/cmake/../deps/Sophus -isystem /home/zye009/habitat-sim/src/cmake/../deps/rapidjson/include -DVERSION_INFO=\"0.1.2\" -fvisibility=hidden -O2 -g -DNDEBUG -fPIC   -Wall -Wextra -Wold-style-cast -Winit-self -Werror=return-type -Wmissing-declarations -pedantic -fvisibility=hidden -fvisibility-inlines-hidden -Wzero-as-null-pointer-constant -Wdouble-promotion -fno-strict-aliasing -Wno-old-style-cast -std=gnu++14 -MD -MT deps/magnum/src/Magnum/Platform/CMakeFiles/MagnumWindowlessGlxApplication.dir/WindowlessGlxApplication.cpp.o -MF deps/magnum/src/Magnum/Platform/CMakeFiles/MagnumWindowlessGlxApplication.dir/WindowlessGlxApplication.cpp.o.d -o deps/magnum/src/Magnum/Platform/CMakeFiles/MagnumWindowlessGlxApplication.dir/WindowlessGlxApplication.cpp.o -c /home/zye009/habitat-sim/src/deps/magnum/src/Magnum/Platform/WindowlessGlxApplication.cpp
In file included from /home/zye009/habitat-sim/src/deps/magnum/src/Magnum/Platform/WindowlessGlxApplication.cpp:26:0:
/home/zye009/habitat-sim/src/deps/magnum/src/Magnum/Platform/WindowlessGlxApplication.h:167:33: error: ‘GLX_CONTEXT_FORWARD_COMPATIBLE_BIT_ARB’ was not declared in this scope
             ForwardCompatible = GLX_CONTEXT_FORWARD_COMPATIBLE_BIT_ARB,
                                 ^
/home/zye009/habitat-sim/src/deps/magnum/src/Magnum/Platform/WindowlessGlxApplication.h:175:21: error: ‘GLX_CONTEXT_DEBUG_BIT_ARB’ was not declared in this scope
             Debug = GLX_CONTEXT_DEBUG_BIT_ARB
                     ^
.
.
.
[32/219] Building CXX object deps/tinyply/CMakeFiles/tinyply.dir/source/tinyply.cpp.o
[33/219] Building CXX object deps/magnum-bindings/src/python/magnum/CMakeFiles/magnum.dir/platform/glx.cpp.o
FAILED: deps/magnum-bindings/src/python/magnum/CMakeFiles/magnum.dir/platform/glx.cpp.o
ccache /usr/bin/c++  -Dmagnum_EXPORTS -I/home/zye009/habitat-sim/src/deps -I/home/zye009/habitat-sim/src/deps/magnum-bindings/src -I/home/zye009/habitat-sim/src/deps/magnum-bindings/src/python -Ideps/magnum-bindings/src/python -I/home/zye009/habitat-sim/src/deps/magnum/src -Ideps/magnum/src -I/home/zye009/habitat-sim/src/deps/corrade/src -Ideps/corrade/src -I/home/zye009/habitat-sim/src/deps/magnum/src/MagnumExternal/OpenGL -I/home/zye009/habitat-sim/src/deps/glfw/include -isystem /home/zye009/habitat-sim/src/cmake/../deps/eigen-git-mirror -isystem /home/zye009/habitat-sim/src/cmake/../deps/Sophus -isystem /home/zye009/habitat-sim/src/cmake/../deps/rapidjson/include -isystem /home/zye009/habitat-sim/src/deps/pybind11/include -isystem /home/zye009/miniconda3/envs/habitat/include/python3.6m -DVERSION_INFO=\"0.1.2\" -fvisibility=hidden -O2 -g -DNDEBUG -fPIC -fvisibility=hidden   -Wall -Wextra -Wold-style-cast -Winit-self -Werror=return-type -Wmissing-declarations -pedantic -fvisibility=hidden -fvisibility-inlines-hidden -Wzero-as-null-pointer-constant -Wdouble-promotion -flto -fno-fat-lto-objects -std=gnu++14 -MD -MT deps/magnum-bindings/src/python/magnum/CMakeFiles/magnum.dir/platform/glx.cpp.o -MF deps/magnum-bindings/src/python/magnum/CMakeFiles/magnum.dir/platform/glx.cpp.o.d -o deps/magnum-bindings/src/python/magnum/CMakeFiles/magnum.dir/platform/glx.cpp.o -c /home/zye009/habitat-sim/src/deps/magnum-bindings/src/python/magnum/platform/glx.cpp
In file included from /home/zye009/habitat-sim/src/deps/magnum-bindings/src/python/magnum/platform/glx.cpp:27:0:
/home/zye009/habitat-sim/src/deps/magnum/src/Magnum/Platform/WindowlessGlxApplication.h:167:33: error: ‘GLX_CONTEXT_FORWARD_COMPATIBLE_BIT_ARB’ was not declared in this scope
             ForwardCompatible = GLX_CONTEXT_FORWARD_COMPATIBLE_BIT_ARB,
                                 ^
/home/zye009/habitat-sim/src/deps/magnum/src/Magnum/Platform/WindowlessGlxApplication.h:175:21: error: ‘GLX_CONTEXT_DEBUG_BIT_ARB’ was not declared in this scope
             Debug = GLX_CONTEXT_DEBUG_BIT_ARB
                     ^
.
.
.
[53/219] Building CXX object esp/geo/CMakeFiles/geo.dir/OBB.cpp.o
[54/219] Building CXX object deps/magnum-bindings/src/python/magnum/CMakeFiles/magnum.dir/math.matrixfloat.cpp.o
[55/219] Building CXX object deps/magnum-bindings/src/python/magnum/CMakeFiles/magnum.dir/math.matrixdouble.cpp.o
ninja: build stopped: subcommand failed.
Traceback (most recent call last):
  File "setup.py", line 376, in <module>
    zip_safe=False,
  File "/home/zye009/miniconda3/envs/habitat/lib/python3.6/site-packages/setuptools/__init__.py", line 145, in setup
    return distutils.core.setup(**attrs)
  File "/home/zye009/miniconda3/envs/habitat/lib/python3.6/distutils/core.py", line 148, in setup
    dist.run_commands()
  File "/home/zye009/miniconda3/envs/habitat/lib/python3.6/distutils/dist.py", line 955, in run_commands
    self.run_command(cmd)
  File "/home/zye009/miniconda3/envs/habitat/lib/python3.6/distutils/dist.py", line 974, in run_command
    cmd_obj.run()
  File "/home/zye009/miniconda3/envs/habitat/lib/python3.6/site-packages/setuptools/command/install.py", line 67, in run
    self.do_egg_install()
  File "/home/zye009/miniconda3/envs/habitat/lib/python3.6/site-packages/setuptools/command/install.py", line 109, in do_egg_install
    self.run_command('bdist_egg')
  File "/home/zye009/miniconda3/envs/habitat/lib/python3.6/distutils/cmd.py", line 313, in run_command
    self.distribution.run_command(command)
  File "/home/zye009/miniconda3/envs/habitat/lib/python3.6/distutils/dist.py", line 974, in run_command
    cmd_obj.run()
  File "/home/zye009/miniconda3/envs/habitat/lib/python3.6/site-packages/setuptools/command/bdist_egg.py", line 172, in run
    cmd = self.call_command('install_lib', warn_dir=0)
  File "/home/zye009/miniconda3/envs/habitat/lib/python3.6/site-packages/setuptools/command/bdist_egg.py", line 158, in call_command
    self.run_command(cmdname)
  File "/home/zye009/miniconda3/envs/habitat/lib/python3.6/distutils/cmd.py", line 313, in run_command
    self.distribution.run_command(command)
  File "/home/zye009/miniconda3/envs/habitat/lib/python3.6/distutils/dist.py", line 974, in run_command
    cmd_obj.run()
  File "/home/zye009/miniconda3/envs/habitat/lib/python3.6/site-packages/setuptools/command/install_lib.py", line 11, in run
    self.build()
  File "/home/zye009/miniconda3/envs/habitat/lib/python3.6/distutils/command/install_lib.py", line 107, in build
    self.run_command('build_ext')
  File "/home/zye009/miniconda3/envs/habitat/lib/python3.6/distutils/cmd.py", line 313, in run_command
    self.distribution.run_command(command)
  File "/home/zye009/miniconda3/envs/habitat/lib/python3.6/distutils/dist.py", line 974, in run_command
    cmd_obj.run()
  File "setup.py", line 201, in run
    self.build_extension(ext)
  File "setup.py", line 273, in build_extension
    shlex.split("cmake --build {}".format(self.build_temp)) + build_args
  File "/home/zye009/miniconda3/envs/habitat/lib/python3.6/subprocess.py", line 311, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['cmake', '--build', 'build', '--config', 'RelWithDebInfo', '--']' returned non-zero exit status 1.

This is the full log  --> build.log.

Hmmm.  That not building suggests that this is a headless server (no display attached), so you'd definitely need to build with --headless.  Can you ask the system administrator to install libegl1-mesa-dev?

Thanks for your quick replies! They're now trying to give me a GUI server, will take about 2 days. I'll update again if there are any issues :)

Due to privilege issues, I simply did apt-get download libegl1-mesa-dev. How do I specify the cmake file to use this custom path for libegl?
If your machine has a custom installation location for the nvidia OpenGL and EGL drivers, you may need to manually provide the EGL_LIBRARY path to cmake as follows. Add -DEGL_LIBRARY=/usr/lib/x86_64-linux-gnu/nvidia-opengl/libEGL.so to the build.sh command line invoking cmake. When running any executable adjust the environment as follows: LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/nvidia-opengl:${LD_LIBRARY_PATH} examples/example.py.

The above portion is from the habitat-sim repository description concerning common errors.
Where and how should I modify the build.sh file?

@zNotAgain any help needed here?

I'm now using a Linux Machine with GUI. When running python setup.py install on habitat-sim, I get this error:
Could NOT find Vulkan (missing: VULKAN_LIBRARY VULKAN_INCLUDE_DIR)
Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
Using X11 for window creation
CMake Error at deps/glfw/CMakeLists.txt:228 (message):
  The RandR headers were not found

GLFW needs some from xorg-dev libglu1-mesa-dev, i.e. sudo apt install xorg-dev libglu1-mesa-dev.

Thanks! It installs successfully now. I'm facing an issue when running python examples/example.py on habitat-api. It says,
2019-09-26 15:29:18,559 initializing sim Sim-v0
Renderer: llvmpipe (LLVM 8.0, 256 bits) by VMware, Inc.
OpenGL version: 3.3 (Core Profile) Mesa 19.0.8
Using optional features:
    GL_ARB_ES2_compatibility
    GL_ARB_direct_state_access
    GL_ARB_get_texture_sub_image
    GL_ARB_invalidate_subdata
    GL_ARB_multi_bind
    GL_ARB_robustness
    GL_ARB_separate_shader_objects
    GL_ARB_texture_storage
    GL_ARB_texture_storage_multisample
    GL_ARB_vertex_array_object
    GL_KHR_debug
Using driver workarounds:
    no-layout-qualifiers-on-old-glsl
    mesa-forward-compatible-line-width-range
I0926 15:29:19.739832 23532 simulator.py:112] Loaded navmesh data/scene_datasets/habitat-test-scenes/skokloster-castle.navmesh
Shader::compile(): compilation of vertex shader 1 failed with the following message:
0:1(10): error: GLSL 4.10 is not supported. Supported versions are: 1.10, 1.20, 1.30, 1.40, 1.50, 3.30, 1.00 ES, and 3.00 ES
Shader::compile(): compilation of fragment shader 2 failed with the following message:
0:1(10): error: GLSL 4.10 is not supported. Supported versions are: 1.10, 1.20, 1.30, 1.40, 1.50, 3.30, 1.00 ES, and 3.00 ES
Assertion Mn::GL::Shader::compile({vert, frag}) failed in /home/zyeo009/Desktop/habitat-sim/src/esp/gfx/DepthUnprojection.cpp on line 57

Do I have to install another version of GLSL?

This is a snippet of /habitat-sim/src/esp/gfx/DepthUnprojection.cpp

Do I have to change anything here?

I am not sure if we currently support GL < 4.1.  We were relying on a feature from 4.1, but we may longer need that.  If you can install a more recently of OpenGL, that would be preferable.

Hmm, so I tried sudo apt-get update and it seems the issues are resolved.
Here is the output when I run python examples/example.py
2019-10-08 10:18:45,208 initializing sim Sim-v0
WARNING: Logging before InitGoogleLogging() is written to STDERR
I1008 10:18:45.211654 24751 WindowlessContext.cpp:99] [EGL] Detected 3 EGL devices
I1008 10:18:45.222843 24751 WindowlessContext.cpp:120] [EGL] Selected EGL device 0 for CUDA device 0
I1008 10:18:45.227041 24751 WindowlessContext.cpp:134] [EGL] Version: 1.5
I1008 10:18:45.227052 24751 WindowlessContext.cpp:135] [EGL] Vendor: NVIDIA
Renderer: GeForce GTX 1080/PCIe/SSE2 by NVIDIA Corporation
OpenGL version: 4.6.0 NVIDIA 430.50
Using optional features:
    GL_ARB_ES2_compatibility
    GL_ARB_direct_state_access
    GL_ARB_get_texture_sub_image
    GL_ARB_invalidate_subdata
    GL_ARB_multi_bind
    GL_ARB_robustness
    GL_ARB_separate_shader_objects
    GL_ARB_texture_filter_anisotropic
    GL_ARB_texture_storage
    GL_ARB_texture_storage_multisample
    GL_ARB_vertex_array_object
    GL_KHR_debug
Using driver workarounds:
    nv-egl-incorrect-gl11-function-pointers
    no-layout-qualifiers-on-old-glsl
    nv-zero-context-profile-mask
    nv-implementation-color-read-format-dsa-broken
    nv-cubemap-inconsistent-compressed-image-size
    nv-cubemap-broken-full-compressed-image-query
    nv-compressed-block-size-in-bits
I1008 10:18:46.169758 24751 simulator.py:124] Loaded navmesh data/scene_datasets/habitat-test-scenes/skokloster-castle.navmesh
2019-10-08 10:18:46,170 initializing task Nav-v0
Environment creation successful
Agent stepping around inside environment.
Episode finished after 3 steps.
I1008 10:18:46.209467 24751 Simulator.cpp:35] Deconstructing Simulator
I1008 10:18:46.209506 24751 SemanticScene.h:40] Deconstructing SemanticScene
I1008 10:18:46.209509 24751 SceneManager.h:24] Deconstructing SceneManager
I1008 10:18:46.209512 24751 SceneGraph.h:20] Deconstructing SceneGraph
I1008 10:18:46.209522 24751 Sensor.h:82] Deconstructing Sensor
I1008 10:18:46.209525 24751 RenderTarget.h:51] Deconstructing RenderTarget
I1008 10:18:46.222141 24751 Renderer.cpp:33] Deconstructing Renderer
I1008 10:18:46.222182 24751 WindowlessContext.h:16] Deconstructing WindowlessContext
I1008 10:18:46.222199 24751 WindowlessContext.cpp:245] Deconstructing GL context
I1008 10:18:46.222260 24751 PathFinder.h:113] Deconstructing PathFinder

Is this the expected response? 🤔

Yep!  That looks fine!

Great! Thanks for all the help :)

On fedora, one can do sudo yum install mesa-libGL-devel


Expected Address schema should be limited

Currently we can even have addresses starting with ftp, this will cause problems with the addition of the URI records #2869  for the registry. We should only expect addresses with schemes among http, https and agora within Agora.

What about dns:// ? :)
Instinctively, I'd say that should be solvable by checking it in https://github.com/bosagora/agora/blob/f5f801eaf7961b2a7df0d19b876bcffb55f38dd4/source/agora/common/Types.d#L79-L84


Compilation errors on 6.7+ kernel

Several compilation issues, mostly
‘struct cfg80211_inform_bss’ has no member named ‘scan_width’

scan_width seems to be removed starting from 6.7.
Kernel version used when compiling: 6.7.5

Close via commit 35ca058e767d87a7c809091ae910b2bf02687870


 It's the MCEdit-Unified bug tracker...
The one you're looking for is here: https://github.com/mcedit/mcedit2


Include the HUD "package" with the CI and release process

Adds support for packaging and releasing the HUD "package" in the same manner as the Client itself.

One minor question about sass dependency update, but besides that, looks good :shipit:


Numba wheel doesn't install six

six seems to be a dependency, but it does not seem to get install by pip install numba inside an empty environment.

Our approach has been to vendor the parts of six we need into numba.six, but there have been places in the past where someone accidentally used the global six.  Did you find something?

Ah, I see. I got:
>>> increment[64, 64](da)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/antoine/t/tt/lib/python3.7/site-packages/numba/cuda/compiler.py", line 765, in __call__
    kernel = self.specialize(*args)
  File "/home/antoine/t/tt/lib/python3.7/site-packages/numba/cuda/compiler.py", line 776, in specialize
    kernel = self.compile(argtypes)
  File "/home/antoine/t/tt/lib/python3.7/site-packages/numba/cuda/compiler.py", line 792, in compile
    **self.targetoptions)
  File "/home/antoine/t/tt/lib/python3.7/site-packages/numba/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/home/antoine/t/tt/lib/python3.7/site-packages/numba/cuda/compiler.py", line 62, in compile_kernel
    cres = compile_cuda(pyfunc, types.void, args, debug=debug, inline=inline)
  File "/home/antoine/t/tt/lib/python3.7/site-packages/numba/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/home/antoine/t/tt/lib/python3.7/site-packages/numba/cuda/compiler.py", line 51, in compile_cuda
    locals={})
  File "/home/antoine/t/tt/lib/python3.7/site-packages/numba/compiler.py", line 925, in compile_extra
    args, return_type, flags, locals)
  File "/home/antoine/t/tt/lib/python3.7/site-packages/numba/compiler.py", line 276, in __init__
    targetctx.refresh()
  File "/home/antoine/t/tt/lib/python3.7/site-packages/numba/targets/base.py", line 271, in refresh
    self.load_additional_registries()
  File "/home/antoine/t/tt/lib/python3.7/site-packages/numba/cuda/target.py", line 72, in load_additional_registries
    from . import cudaimpl, printimpl, libdevice
  File "/home/antoine/t/tt/lib/python3.7/site-packages/numba/cuda/cudaimpl.py", line 5, in <module>
    import six
ModuleNotFoundError: No module named 'six'

ah, yes, it looks like you tripped over this bug which we fixed:
https://github.com/numba/numba/commit/64f6859b0a5f172acf8244fc0923664e591e6315#diff-a3ad32c82e29f57220d54a522266e48c
The next release is planned for the end of February.

Thanks for the quick response :-) Feel free to close.


Separate BlockManager from SyncSystem

Description
Currently BlockManager is an internal part of the sync system but it's the parallel of AttestationManager which is it's own submodule and used directly from places like ValidatorApiHandler.  We should move BlockManager to the same model.
We should also move it to use a wrapper class like ValidatableAttestation so that blocks which are added to pending or future queues can report when they are eventually processed or dropped.  Currently we report errors importing blocks published directly to us by a validator client, but only if they aren't deferred via the future queue. Would be much better to report failures for future blocks once they can be processed as well.

Reopening as we still need to move the BlockManager class into a more suitable module and package.


Collection variables

Is your feature request related to a problem? Please describe.
At work we love Altair and would like to promote it to our clients. For that we plan to create a collection with queries and mutations to make the start even easier. For that we also want to use variables (eg. the URL), but unfortunately at the moment the variables are just specifiable in environments which you can not export together with the collection.
Postman for example supports collection scoped variables and so these variables can be easily exported/imported together with the collection.
Describe the solution you'd like
I would like to have some mechanism where I can add variables to a collection and then be able to export/import these together with the collection

Thanks for reporting this! I'd look into it as soon as I can.

One main challenge I have with all these is the organization of all these features and functionality in Altair. I'm still trying to figure out the best organizational strategy to use design-wise (I'm afraid my design capabilities have limits 😄), and not just for this feature but for all the other features.
I wish to be able to keep a clean interface (it's already busier than I would like) while supporting these many features.


cmd/cue: trim default + optional interaction

What version of CUE are you using (cue version)?

$ cue version v0.3.0-beta.4 linux/amd64

Does this issue reproduce with the latest release?
yes
What did you do?
tmp.cue
#maybeString: {ip?: string}
something: ip: *"default" | string
something: #maybeString

cue trim tmp.cue

What did you expect to see?
I don't think this looks like something that can be trimmed, so probably no change.
What did you see instead?
  {
      #maybeString: close({
        ip?: string
      })
      something: {
-         ip: (*"default" | string) & string
+         ip?: string
      }
  }
Aborting trim, output differs after trimming. This is a bug! Use -i to force trim.
You can file a bug here: https://github.com/cuelang/cue/issues/new?assignees=&labels=NeedsInvestigation&template=bug_report.md&title=

Confirmed with 760aa11:
cp main.cue.golden main.cue
exec cue trim ./...
cmp main.cue main.cue.golden

-- main.cue.golden --
package main

#maybeString: {ip?: string}
something: ip: *"default" | string
something: #maybeString

Marking as a feature request because trim needs to be coded for each case.

This issue has been migrated to https://github.com/cue-lang/cue/issues/759.
For more details about CUE's migration to a new home, please see https://github.com/cue-lang/cue/issues/1078.


WIP Support GeometryBasics.AbstractGeometries

using Pkg
pkg"activate polygons"
pkg"add Shapefile#sd/geometrybasics"
pkg"add AbstractPlotting#sd/geom_merge"
pkg"add GeometryBasics#sd/polygons"
pkg"add CairoMakie"
pkg"add https://github.com/greimel/CategoricalArrays#orderstyle" # EDIT: add this line

using Shapefile # for loading the data
using AbstractPlotting
using CairoMakie
using AlgebraOfGraphics

dir = "shp-dir"
if !isdir(dir)
    url_gadm = "https://biogeo.ucdavis.edu/data/gadm3.6/shp/gadm36_DEU_shp.zip"
    zip_archive = download(url_gadm) # 29 MB

    mkdir(dir)
    #dir = mktempdir()
    run(`unzip $zip_archive -d $dir`)
end

tbl_states = Shapefile.Table(joinpath(dir, "gadm36_DEU_1.shp"))
shp_states = tbl_states.Geometry

using DataFrames
df = tbl_states |> DataFrame

df[!,:z_var] = rand(size(df,1))
df[!,:grp] = rand([:grp1, :grp2, :grp3], size(df,1))

df # a DataFrame
categorical!(df, :Geometry) # Geometry is a vector of MultiPolygons

dta = data(df)
geom = spec(Poly)
aog = dta * geom * style(:Geometry, color = :grp)

dog |> draw

This needs to wait until a bug in AbstractPlotting is fixed. plot!(ax, Poly, args...) doesn't currently work.
EDIT:
It also needs JuliaData/CategoricalArrays.jl#292 because of https://github.com/JuliaData/CategoricalArrays.jl/issues/291

Nice! Does this work out of the box just by doing style(:geometry, color=:someproperty)?
Also, I got a bit lost with all the GeometryBasics / GeoInterface changes, but is the name of the "geometry" (the column with all the polygons) always the same, regardless of whether it's a MetaPoint, MetaPolygon, or something else? (I only have a very vague understanding on the Geo / Geometry side of things.)

yes, I added runnable code above. So far I only tested it with MultiPolynomial, but in principle it should work with every object that AbstractPlotting can plot. (But only after this one bug mentioned above is fixed)
I guess one doesn't really need the Meta stuff, because you can just put the geometric objects in a DataFrame to hold your other data.

As an aside, I tried coloring with a continuous variable with this code. But it seems that this is not supported in general, right?

As an aside, I tried coloring with a continuous variable with this code. But it seems that this is not supported in general, right?

Mhm, I would have though that should work, will check later!

As an aside, I tried coloring with a continuous variable with this code. But it seems that this is not supported in general, right?

never mind, it does work for simple cases. I need to check what goes wrong here.

Here is an update on this.
The branches in AbstractPlotting and GeometryBasics got merged and released, and so did my PR JuliaData/CategoricalArrays.jl#291.
Note that the shapes are plain Vectors (no categorical vectors!). But they seem to be transformed to categorical vectors in the pipeline. That is why I needed to add this method for replace_categorical.
Here is a demonstration. (The map from above still works, the only branch that is still needed is for Shapefiles.jl)
Homogenous shapes work
using AlgebraOfGraphics, AbstractPlotting, CairoMakie
using GeometryBasics, DataFrames

r1 = Point.([(2,2), (3,3)]) |> Rect
r2 = Point.([(0,0), (1,1)]) |> Rect
c1 = Circle(Point((2.0,2.0)), 2.0)
c2 = Circle(Point((0.0,0.0)), 1.0)
df1 = DataFrame(Geometry = [r1, r2], grp = categorical(["grp 1", "grp 2"]))
df2 = DataFrame(Geometry = [c1, c2], grp = categorical(["grp 1", "grp 2"]))

dta = data(df1)
geom = spec(Poly)
aog = dta * geom * style(:Geometry, color = :grp)

aog |> draw

dta = data(df2)
geom = spec(Poly)
aog = dta * geom * style(:Geometry, color = :grp)

aog |> draw

Mixed shapes don't work
df3 = [df1; df2]
dta = data(df3)
geom = spec(Poly)
aog = dta * geom * style(:Geometry, color = :grp)

aog |> draw

This is due to a limitation of AbstractPlotting:
poly(df3.Geometry, color = 1:4)

gives the error
There was no `AbstractPlotting.convert_arguments` overload found for
the plot type Scatter{...}, or its conversion trait AbstractPlotting.PointBased().
The arguments were:
(Array{GeometryBasics.GeometryPrimitive{2,T} where T,1},)

To fix this, define `AbstractPlotting.convert_arguments(::Scatter{...}, ::Array{GeometryBasics.GeometryPrimitive{2,T} where T,1})`.

error(::String) at error.jl:33
convert_arguments(::Type{Scatter{...}}, ::Array{GeometryBasics.GeometryPrimitive{2,T} where T,1}; kw::Base.Iterators.Pairs{Union{},Union{},Tuple{},NamedTuple{,Tuple{}}}) at conversions.jl:46
convert_arguments(::Type{Scatter{...}}, ::Array{GeometryBasics.GeometryPrimitive{2,T} where T,1}) at conversions.jl:41
convert_arguments(::Type{Poly{...}}, ::Array{GeometryBasics.GeometryPrimitive{2,T} where T,1}) at basic_recipes.jl:46
plot!(::Scene, ::Type{Poly{...}}, ::Attributes, ::Array{GeometryBasics.GeometryPrimitive{2,T} where T,1}; kw_attributes::Base.Iterators.Pairs{Union{},Union{},Tuple{},NamedTuple{,Tuple{}}}) at interfaces.jl:608
plot! at interfaces.jl:595 [inlined]
plot(::Type{Poly{...}}, ::Attributes, ::Array{GeometryBasics.GeometryPrimitive{2,T} where T,1}; kw_attributes::Base.Iterators.Pairs{Union{},Union{},Tuple{},NamedTuple{,Tuple{}}}) at interfaces.jl:556
plot at interfaces.jl:553 [inlined]
#plot#192 at interfaces.jl:547 [inlined]
plot at interfaces.jl:546 [inlined]
#poly#293 at recipes.jl:12 [inlined]
(::AbstractPlotting.var"#poly##kw")(::NamedTuple{(:color,),Tuple{UnitRange{Int64}}}, ::typeof(poly), ::Array{GeometryBasics.GeometryPrimitive{2,T} where T,1}) at recipes.jl:12
top-level scope at aog.jl:163
include_string(::Function, ::Module, ::String, ::String) at loading.jl:1088

@piever sorry, the case with continuous styling doesn't work.
The problem is that Attributes contain a NamedArray that cannot be processed by AbstractPlotting.
My guess is that this happens because AoG thinks that the Geometries are categorical, so that they would be split eventually, but they aren't.
I cannot find the place where the Vector{Geometry} is transformed to a categorical array. Could you give me a hint where this happens?

@piever, should I open an issue at NamedDims about adding broadcasting style, or do you want to change the handling of attributes here?
Is there a reason that you save the attributes as named columns?

If the broadcasting bug for NamedDimArrays gets fixed, this can be merged from my side.
Here a demonstration with a local patch
using GeometryBasics, DataFrames

centers = 0:0.1:5
circs = [Circle(Point((c,c)), 0.05) for c in centers]
df = DataFrame(x = centers, Geometry=circs)
data(df) * spec(Poly) * style(:Geometry, color=:x) |> draw

The two commits contain two different ways to get this working.
It depends a bit on how you think of categorical arrays. Do you want to convert shapes into a categorical array, or not?

Now that https://github.com/JuliaPlots/Makie.jl/issues/709 is solved, this branch works as it should.
 Examples 1 and 2 (Maps)
#using Pkg
#pkg"add Shapefile#sd/geometrybasics"

using Shapefile # for loading the data
using AbstractPlotting
using CairoMakie
using AlgebraOfGraphics

dir = "shp-dir"
if !isdir(dir)
    url_gadm = "https://biogeo.ucdavis.edu/data/gadm3.6/shp/gadm36_DEU_shp.zip"
    zip_archive = download(url_gadm) # 29 MB

    mkdir(dir)
    #dir = mktempdir()
    run(`unzip $zip_archive -d $dir`)
end

tbl_states = Shapefile.Table(joinpath(dir, "gadm36_DEU_1.shp"))
shp_states = tbl_states.Geometry

using DataFrames
df = tbl_states |> DataFrame

df[!,:z_var] = rand(size(df,1))
df[!,:grp] = rand([:grp1, :grp2, :grp3, :grp4], size(df,1)) |> categorical

dta = data(df)
geom = spec(Poly)

aog_c = dta * geom * style(:Geometry, color = :z_var)
aog_d = dta * geom * style(:Geometry, color = :grp)

aog_c |> draw

aog_d |> draw

 Example 3
using GeometryBasics, DataFrames

centers = 0:0.1:5
circs = [Circle(Point((c,c)), 0.05) for c in centers]
df = DataFrame(x = centers, Geometry=circs)
data(df) * spec(Poly) * style(:Geometry, color=:x) |> draw

As mentioned above, plotting heterogenous shapes doesn't work due to a bug in AbstractPlotting https://github.com/JuliaPlots/Makie.jl/issues/710.
I am looking forward to your review.

Sorry for the slow response time, things have been a bit hectic on my side.
I like to keep attributes as named vectors, because I use that information for legends. I would actually like to drop the CategoricalArrays dependency at some point, but that's still a refactor away.
Concerning the example, I really think it should be the map. How far are we from getting that branch of Shape file merged?

How far are we from getting that branch of Shape file merged?

It's not quite there yet, and depends on a few other things, that should be released together, so still at least a month away. But it will get merged for sure.

I'm merging this as is (version 2, do not convert Geometry stuff into categorical arrays). We should add the map example when there branch in Shapefile gets merged.


lint hint "The declaration '_missingPluralResolver' isn't referenced"

Not sure if this code should be removed but please check. I am attaching the image:

Well, I can fix that also.
But keep in mind that generated dart usually should not be tracked by the dart analyser.

Thank you @Tienisto
Thing is that I can only ignore the entire file but thing is that there are things in the generated file that is good to be reported (an example is an extra translation not available in the main translation that is reported as an invalid override). So I find it good to have this generated file as not ignored

btw thanks a lot for such a great plugin!

Fixed in 5.0.0


Compressed every game's image

✨ Description
Images are compressed for improved performance.
Linked Issue:
🔄 Type of Change

[ ] 🐞 Bug fix
[ ] ✨ New feature
[ ] 🔧 Improvement

✅ Checklist

[ ] 📝 Code follows project style guidelines
[ ] 🔗 Relevant issue is linked and moved to 'In Progress'
[ ] 🧪 All relevant tests have been added or updated
[ ] ✔ Continuous integration (CI) tests have passed
[ ] 👀 Ready for review

📄 Additional Information

[like]  Ahmad Mohammad Al-Qadiri reacted to your message:

From: Mathias @.>
Sent: Monday, December 16, 2024 6:46:05 PM
To: SP-SDU/GameLibrary @.>
Cc: Ahmad Mohammad Al-Qadiri @.>; Author @.>
Subject: Re: [SP-SDU/GameLibrary] Compressed every game's image (PR #33)
@RespectMathias approved this pull request.
Sorry, didn't notice it until now.
Approve 👍
—
Reply to this email directly, view it on GitHubhttps://github.com/SP-SDU/GameLibrary/pull/33#pullrequestreview-2507000592, or unsubscribehttps://github.com/notifications/unsubscribe-auth/APLYBJZKGMBXJX72OJMBO6T2F4NW3AVCNFSM6AAAAABTVX63YKVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDKMBXGAYDANJZGI.
You are receiving this because you authored the thread.Message ID: @.***>


fix: dep update

:tada: This PR is included in version 6.3.2 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Rename downloaded folder

Rename the folder from "constant-contact-subscribe-master" to "constantcontactsubscribe" to get it to show up in your plugins folder.

Thanks. I renamed the repository.


HTTP Error 403: rate limit exceeded when loading model

🐛 Bug

To Reproduce
Steps to reproduce the behavior:

import torch
model = torch.hub.load('pytorch/vision:v1.9.0','resnet50', pretrained=True)

Expected behavior
Load the model
Environment
Google Colab and also local with the latest pytorch and torchvision installed
Error Output
HTTPError                                 Traceback (most recent call last)
 in ()
1 import torchvision
2
----> 3 model = torch.hub.load('pytorch/vision:v1.9.0','resnet50', pretrained=True)
8 frames
/usr/lib/python3.7/urllib/request.py in http_error_default(self, req, fp, code, msg, hdrs)
647 class HTTPDefaultErrorHandler(BaseHandler):
648     def http_error_default(self, req, fp, code, msg, hdrs):
--> 649         raise HTTPError(req.full_url, code, msg, hdrs, fp)
650
651 class HTTPRedirectHandler(BaseHandler):
HTTPError: HTTP Error 403: rate limit exceeded

I'm able to download on my local machine. With the following command
import torch
model = torch.hub.load('pytorch/vision:v0.10.0', 'resnet50', pretrained=True)

Also with
import torch
model = torch.hub.load('pytorch/vision:v0.9.0', 'resnet50', pretrained=True)

Can you give one more try @ichamatidis ?

I tried it with both versions that you mentioned, still the same result in Google Colab and locally. I provide bellow the error output form the 0.10.0 version from Google Colab.
Error Output

HTTPError                                 Traceback (most recent call last)
 in ()
1 import torch
2
----> 3 model = torch.hub.load('pytorch/vision:v0.10.0','resnet50', pretrained=True)
8 frames
/usr/lib/python3.7/urllib/request.py in http_error_default(self, req, fp, code, msg, hdrs)
647 class HTTPDefaultErrorHandler(BaseHandler):
648     def http_error_default(self, req, fp, code, msg, hdrs):
--> 649         raise HTTPError(req.full_url, code, msg, hdrs, fp)
650
651 class HTTPRedirectHandler(BaseHandler):
HTTPError: HTTP Error 403: rate limit exceeded

True. I can reproduce this over Google Colab. Not locally though
Here is link
Unsure why colab should do that.
But you can access pretrained model from
rnet = torchvision.models.resnet50(pretrained=True)

Yeah it's a weird bug and must be recent(less than 2 weeks cause it was working normally before). Does your local machine has Windows or Linux?

Linux Ubuntu 20.04.2

I have Ubuntu 21.04, so I assume it's some connection error.

Issue is also observed here and I'm also able to reproduce it using Ubuntu20.04.

This seems to be a bug in torch.hub with pytorch/pytorch#56138 as possible offender. I can't reproduce the issue with torch==1.8.0 that does not has this commit. cc @cyyever @ailzhang

Yea I think it's introduced in that PR cc: @cyyever. It's probably hitting the rate limit set by github. My guess is it's only reproducible on CI machines/Google Colab since those machines might send a lot of API requests from the same public IP address so github only errors out on those. Our personal dev machines didn't hit the limit so it's not reproducible there.
If we still don't want to introduce dependency on system git, we probably need to either find another way to validate branch/tag or somehow workaround the rate limit.

torch==1.8.0

can confirm using torch==1.8.0 and restarting runtime in colab works

Hi everyone,
With me the error happens with any model used. And even resetting the collab the problem persists.

@ailzhang I can reproduce this locally and @NicolasHug seems to have hit the same in #4157. So it is not only CI machines and Colab.

Bumping priority due to user activity.

I'm getting the same error even while trying to run the torch hub models on docker containers. In my opinion, that should not happen.
The system is running Ubuntu 20.04.

This is because we are using github api to check existence of the repo. I have submitted a PR to return succ in the case of 403. To work around this error temporarily, you can delete line 163 on torch/hub.py
_validate_not_a_forked_repo(repo_owner, repo_name, branch)

pytorch/pytorch#61761 for reference.

Also @ichamatidis :

torch.hub.load('pytorch/vision:v1.9.0','resnet50', pretrained=True)

This should be either vision:v0.9.0 or vision:v0.10.0, as torchvision's version 1.9 doesn't exist.

@NicolasHug  Yeah copy-paste error, but the HTTP error persists even with wrong parameters, thus we can narrow that the error happens before any checks

Similar error here!

Noticed similar issue on personal machine

Likely something to do with the conda env python/pytorch versions:

Works with python=3.7 and pytorch=1.7

Python 3.7.10 | packaged by conda-forge | (default, Feb 19 2021, 16:07:37)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import torch
>>> torch.__version__
'1.7.0'
>>> model = torch.hub.load('pytorch/vision:v0.10.0', 'resnet50', pretrained=True, force_reload=True)
Downloading: "https://github.com/pytorch/vision/archive/v0.10.0.zip" to /home/ml/farleylai/.cache/torch/hub/v0.10.0.zip

Failed with python=3.9 and pytorch=1.9

Python 3.9.5 (default, Jun  4 2021, 12:28:51)
[GCC 7.5.0] :: Anaconda, Inc. on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import torch
>>> torch.__version__
'1.9.0'
>>> model = torch.hub.load('pytorch/vision:v0.10.0', 'resnet50', pretrained=True, force_reload=True)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/ml/farleylai/miniconda3/envs/sinet39/lib/python3.9/site-packages/torch/hub.py", line 362, in load
    repo_or_dir = _get_cache_or_reload(repo_or_dir, force_reload, verbose)
  File "/home/ml/farleylai/miniconda3/envs/sinet39/lib/python3.9/site-packages/torch/hub.py", line 162, in _get_cache_or_reload
    _validate_not_a_forked_repo(repo_owner, repo_name, branch)
  File "/home/ml/farleylai/miniconda3/envs/sinet39/lib/python3.9/site-packages/torch/hub.py", line 124, in _validate_not_a_forked_repo
    with urlopen(url) as r:
  File "/home/ml/farleylai/miniconda3/envs/sinet39/lib/python3.9/urllib/request.py", line 214, in urlopen
    return opener.open(url, data, timeout)
  File "/home/ml/farleylai/miniconda3/envs/sinet39/lib/python3.9/urllib/request.py", line 523, in open
    response = meth(req, response)
  File "/home/ml/farleylai/miniconda3/envs/sinet39/lib/python3.9/urllib/request.py", line 632, in http_response
    response = self.parent.error(
  File "/home/ml/farleylai/miniconda3/envs/sinet39/lib/python3.9/urllib/request.py", line 561, in error
    return self._call_chain(*args)
  File "/home/ml/farleylai/miniconda3/envs/sinet39/lib/python3.9/urllib/request.py", line 494, in _call_chain
    result = func(*args)
  File "/home/ml/farleylai/miniconda3/envs/sinet39/lib/python3.9/urllib/request.py", line 641, in http_error_default
    raise HTTPError(req.full_url, code, msg, hdrs, fp)
urllib.error.HTTPError: HTTP Error 403: rate limit exceeded

Similar as @farleylai, no dice with pytorch 1.9.0. This was working previously with pytorch 1.7.0 and 1.8.0.
root@pc:~#  python3
Python 3.8.10 (default, Jun  2 2021, 10:49:15)
[GCC 9.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import torch
>>> torch.__version__
'1.9.0a0+gitd69c22d'
>>> model = torch.hub.load('pytorch/vision:v0.10.0', 'resnet50', pretrained=True, force_reload=True)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.8/dist-packages/torch/hub.py", line 362, in load
    repo_or_dir = _get_cache_or_reload(repo_or_dir, force_reload, verbose)
  File "/usr/local/lib/python3.8/dist-packages/torch/hub.py", line 162, in _get_cache_or_reload
    _validate_not_a_forked_repo(repo_owner, repo_name, branch)
  File "/usr/local/lib/python3.8/dist-packages/torch/hub.py", line 124, in _validate_not_a_forked_repo
    with urlopen(url) as r:
  File "/usr/lib/python3.8/urllib/request.py", line 222, in urlopen
    return opener.open(url, data, timeout)
  File "/usr/lib/python3.8/urllib/request.py", line 531, in open
    response = meth(req, response)
  File "/usr/lib/python3.8/urllib/request.py", line 640, in http_response
    response = self.parent.error(
  File "/usr/lib/python3.8/urllib/request.py", line 569, in error
    return self._call_chain(*args)
  File "/usr/lib/python3.8/urllib/request.py", line 502, in _call_chain
    result = func(*args)
  File "/usr/lib/python3.8/urllib/request.py", line 649, in http_error_default
    raise HTTPError(req.full_url, code, msg, hdrs, fp)
urllib.error.HTTPError: HTTP Error 403: rate limit exceeded

No need for more repros. This behavior was introduced in pytorch/pytorch#56138 which was shipped with 1.9.0 and will be fixed by pytorch/pytorch#61761. I don't know if we release a 1.9.1 that includes this fix since it seems to affect quite a few users (@seemethere ?). If not we have to wait for the 1.10 release.

I have a temporary fix for this problem.
" base_model= torch.hub.load('pytorch/vision:v0.9.0', 'densenet121', pretrained=True, progress=True) " : gives me "HTTP Error 403: rate limit exceeded"
BUT,
" base_model = torchvision.models.densenet121(pretrained=True, progress=True) " : works completely fine

Yes, this is a problem with torch.hub. You can access everything through torchvision directly.

Yes the hack fix for now is to use
model = torchvision.models.densenet121(pretrained=True, progress=True)

instead of
model = torch.hub.load('pytorch/vision:v0.9.0', 'densenet121', pretrained=True, progress=True)

Note that this hack has a small problem.
torch.hub does not need torchvision to be installed. It will load the model without torchvision being installed through pip / conda.
Whereas the hack to load using torchvision needs torchvision to be installed.

the hack fix

This is not a hack, but a stable feature of torchvision. If you have torchvision installed, one could also say it is superior, because torch.hub downloads the repo in addition to the weights. Still, you are correct, torch.hub is the way to go if you don't have access to torchvision or don't want it as dependency.
For anyone wondering what can be loaded by torch.hub, have a look at
https://github.com/pytorch/vision/blob/300a8a40132c5d3ee7dc936034c6046fd30ca4c0/hubconf.py#L1-L21

Temporary fix by @malfet that he mentioned in this comment:

As a workaround, can you please adding the following line before making any "torch.hub" calls:
torch.hub._validate_not_a_forked_repo=lambda a,b,c: True

Temporary fix by @malfet that he mentioned in this comment that fixes things for me:

As a workaround, can you please adding the following line before making any "torch.hub" calls:
torch.hub._validate_not_a_forked_repo=lambda a,b,c: True

That works for me too.

You can simply download pretrained model by torchvision.model
it seems like there is bug in torch.hub

I was able to reproduce the error on CentOS 7 https://stackoverflow.com/questions/68901236/urllib-error-httperror-http-error-403-rate-limit-exceeded-when-loading-resnet1

PR#62139 just added an option skip_validation: bool when loading a model from GitHub. So just add skip_validation=True like
model = torch.hub.load("pytorch/vision", "resnet18", skip_validation=True)

This is because we are using GitHub API to check the existence of the repo. I have submitted a PR to ignore HTTP error 403. To work around this error temporarily, you can delete line 163 on torch/hub.py
_validate_not_a_forked_repo(repo_owner, repo_name, branch)

it works, the bug is gone.


Add files via upload

use jetbrain tools

@adnanchandoul I have to close this request without merging, because it is in wrong format. You did not need to upload a .zip file, you had to unzip it with suggested directory structure (lib/domain/tn/rnu/issetmd.txt), and create a pull request to add this file with this path lib/domain/tn/rnu/issetmd.txt to this repository.
Also, please: provide us with:

the university official website URL, if different from the domain you are submitting
an URL of a page on the official website where an IT-related long-term (>1 year) course is offered by the university
an URL of a page or another proof (.pdf or a screenshot are OK) showing that the university recognizes the domain which you are submitting as an official email domain for the students.


Operator instead of a function ?

Just to continue here our twitter discussion:
What about a custom operator version:
target.closure <= (self, other, { strongSelf, strongOther, some, args in
    // ... code
})

Are any limitation from user point of view to code completion of using Strongify ?

It would probably work fine, I'm just not a fan of custom operators outside of very few specific domains, I've background in gamedev where C++ had custom operator for ever and when people keep adding them it just becomes a mess.
That being said if enough people would want it I can consider it as an option.


Make openssl check -rsa ... to work for both RSA and RSA-PSS.

Fixes openssl#17167

Checklist

[ ] documentation is added or updated
[x] tests are added or updated

This pull request is ready to merge

Merged to openssl-3.0 and master branch. Thank you.


PEP8 imports

I've done some tidying to bring the code more into line with PEP8, in particular the recommendations on imports.
What this PR includes:

[x] ordered imports according to the PEP8 guidelines (i.e. standard library imports first, third-party libraries second, ipyvolume imports last)
[x] replaced wildcard imports with explicit imports
[x] moved all import statements to the top of the file

I haven't touched very much of examples.py or test_all.py, not sure if they need slightly special handling.

The question of dependencies
Moving import statements to the top of each file has surfaced a few (possibly optional) dependencies. Should these be hard or optional dependencies?

bokeh
scipy
scikit-image
ChromeDevTools (this one looks like a debugging tool left in there)

If optional, does that mean those imports should be wrapped in a try/except, or handled in some other way?

Resolving inconsistencies
It's brought to light some of the inconsistencies that have confused me (both across ipyvolume as a whole, but there are also inconsistencies within the same file). Eg:
1)
import ipyvolume
import ipyvolume as ipv

I'd guess  import ipyvolume as ipv to be standard across the library, since this's what's used in all the tutorial examples I've seen. What do other people think here?
2)
import ipywidgets
import ipywidgets as widgets

I'd guess import ipywidgets should be preferred, since otherwise it could cause confusion with the ipyvolume widgets module. Thoughts?
3)
import ipyvolume.pylab as p3
from ipyvolume import pylab

I'd guess from ipyvolume import pylab should be preferred, since p3 is pretty ambiguous. Is that right?

t's brought to light some of the inconsistencies that have confused me (both across ipyvolume as a whole, but there are also inconsistencies within the same file). Eg:
1)
import ipyvolume
import ipyvolume as ipv

The last one should be standard, p3 was what I used a long time ago.

Moving import statements to the top of each file has surfaced a few (possibly optional) dependencies. Should these be hard or optional dependencies?

bokeh
scipy
scikit-image
ChromeDevTools (this one looks like a debugging tool left in there)

If optional, does that mean those imports should be wrapped in a try/except, or handled in some other way?

I prefer imports not at the top when they are optional.

Nice work! Do you want me to merge this as it is?

Sure go ahead and merge if you can confirm that these changes aren't the reason the TravisCI build is currently failing,
Travis can't pip install ipyvolume, which is potentially quite serious. But it looks like it's something to do with webpack and the javascript, so I don't think my changes should have affected this?
The command "pip install -e ." failed and exited with 1 during .

Command "python setup.py egg_info" failed with error code 1 in /home/travis/build/maartenbreddels/ipyvolume/

... and in more detail:
><EMAIL_ADDRESS>prepublish /home/travis/build/maartenbreddels/ipyvolume/js
    > webpack

    internal/crypto/hash.js:58
        throw new ERR_INVALID_ARG_TYPE('data',
        ^

    TypeError [ERR_INVALID_ARG_TYPE]: The "data" argument must be one of type string, TypedArray, or DataView. Received type undefined

Yeah, that's bad, I have to look into it soon, many thanks for all the work you are doing!


A11y test for CIO DevOps Survey

Staging link to form: https://forms-staging.cdssandbox.xyz/id/72
Dev accessibility Test Scope

[x] Entire pages and templates(designs)
[x] Page content and Widgets

A basic testing routine

[x] Run an Automated check (using Axe DevTools or Wave)
[x] Screen Reader Resources (voiceOver, Narrator)

###Keyboard Accessibility

[x] Enabling Keyboard Access (On Mac | Windows)
[x] Test tab focusability and tab order
[x] Check keyboard functionality
[x] Check Visual Focus Indicator
[x] Test Keyboard Functionality with Screen Reader On
[ ] Test effective Focus Management (Form Validation)

Test for Touch Device Accessibility ( if applicable)

[ ] Touch Functionality
[ ] Touch Target Size
[ ] Touch Functionality with Screen Reader On

Common tests

[ ] Test link text quality
[ ] Test Alt text quality
[ ] Test if Form Labels and Instructions are clear
[ ] Test if the form validation works or not
[ ] Test If the labels are correctly written and placed or not.
[ ] Test If the audio/video content is properly audible/visible or not.
[ ] Test If the colour contrast ratio is maintained or not with a Colour Contrast Analyser (CCA).
[ ] Test If the short keys are provided for the menu then you need to check if all of those are working fine.
[ ] Test if the navigation between tabs is an easy task.
[ ] Test If the heading is unique and conveying the meaning & structure or not.
[ ] Test If the link text is written with content description instead of creating ambiguity.
[ ] Test If the instructions are clearly given or not.
[ ] Test If the content is clear, concise and understandable or not.

Finally

[ ] Test If a page has followed all the principles and guidelines above.
[ ] Create or update the related task with ATR card in the New Issues column
[ ] Tag issues with a11y tag, and provide a triage rating

Triage methodology

Known issues #295 and #323 on focus management


feat: add module build script

Bundles src/index.js with esbuild as an esm target. The bundle generated is intended to be consumed by other packages that require vitessce as a dependency. The target therefore does not bundle dependencies, and instead only:

compiles sass -> .css
inlines worker module
imports .svg as ReactComponent

You can run the script with:
node scripts/build-esm.js

which will generate dist/esm/index.{js,css}. It would be best to see if these outputs can be consumed by hubmap.
EDIT: This looks much more complicated than I thought. I tried loading this in portal_ui and ran into a few issues:

some dependencies can't be found: @turf/area is missing
portal_ui doesn't transpile modern ES syntax, so some syntax isn't recognized/supported. We can set the target to es6, but @hms-dbmi/viv also ships modern es syntax so this pushes the error down.
shaders aren't compiled via glslify.

I have ideas of how to resolve the first two issues, but where currently in the build scripts do the shader imports require('glsl-colormap/*') sget resolved?

Although some things aren't working, I built #1045 using this script and the simple dynamic imports are supported

@keller-mark is this used though?  I though they were compiled directly via glsl as strings.  Possible I ma misunderstanding this.

Relatedly @manzt I did look at this but ran into the issues you ran in to above.  Do you have any ideas of what you might want to do to resolve them?  I am trying out upgrading webpack but it seems like there are easier solutions, at least for the transpiling issue.

@ilan-gold I have some changes and will push in a bit.

@ilan-gold. I added an esbuild plugin to transform some files with babel. This is inefficient compared to esbuild's native transforms, so I added a filter to restrict this plugin to only files with "shader" in the filename. In addition, I had to convert the build script to a module ('.mjs') since esbuild-plugin-babel is ESM only (can't load via commonjs require()).
As a side node, if we changed shader imports from babel-transpiled javascript modules to static assets (e.g. import fs from './fs.glsl) then we wouldn't need to have the babel plugin at all. However, the goal of this PR is avoid touching the source code or any other webpack config. This is something we can look into in the future but doesn't need to be address at the moment IMO.
Also, Babel seems to require that a NODE_ENV or BABEL_ENV flag are set in the environment when transpiling. I am not sure what to set this to when building our target, but for now you will need to run:
NODE_ENV=development node script/build-esm.mjs

@manzt Trying it out now but I got an error on this latest commit:
esbuild.build({
        ^

TypeError: esbuild.build is not a function
    at file:///Users/ilan_gold/gehlenborg/vitessce/scripts/build-esm.mjs:107:9
    at ModuleJob.run (internal/modules/esm/module_job.js:140:23)
    at async Loader.import (internal/modules/esm/loader.js:165:24)
    at async Object.loadESM (internal/process/esm_loader.js:68:5)

which seeemed to be fixed by using
import esbuild from "esbuild";

instead of
import * as esbuild from "esbuild";

It should work. What version of node are you using?

@manzt I am on 14.7.  Besides this, I was able to load the higlass component in the portal without issue.

In addition, I had to convert the build script to a module ('.mjs') since esbuild-plugin-babel is ESM only

Is the build-esm.js script no longer needed?

I experienced the same error as Ilan, I am on Node v14.0.0

@manzt One thing I notice here is that this seems to push the txml problem further up the stack, which I think is not desirable since people don't even know where txml is coming from.  It seems like merging the recent geotiff shift away from it: https://github.com/geotiffjs/geotiff.js/pull/245 and then upgrading Viv would be the long term solution (before any release of this branch).  Seems like not a blocker, but if you have a quick fix for this here, that would of course be welcome.
As for the node v10 support, I wonder how many people are still using it.  I'd be fine dropping it.


Fix/list keys with alignment not correct

Summary (Please recap what you changed or fixed)

Align list pharse keys with minWidth

Checklist (If you won't pass this checklist please comment why)

[x] I removed all commented or unnecessary code.
[x] Provide the screenshots due to UI changed or bug fixed
[ ] My code has covered these test cases (please list down your tested cases):

LGTM


Trumbowyg isn't compatible with IE9/10

In trumbowyg.js (line 1284 & 1289) a variable type named "const" is used. This type was published in
ECMAScript 6/ECMAScript 2015. But Internet Explorer has only supported this standard since version 11.
I changed these two variables to "var" and it works.
On alex-d.github.io/Trumbowyg/ is written, that your libary works for IE9+. Pls fix that. :)
source: https://caniuse.com/#search=es6

Use master. It's fixed.

2.11.0 is published now and it should fix your issue.


Dependabot Alert #1 - @actions/core is vulnerable

Impact
The core.exportVariable function uses a well known delimiter that attackers can use to break out of that specific variable and assign values to other arbitrary variables. Workflows that write untrusted values to the GITHUB_ENV file may cause the path or other environment variables to be modified without the intention of the workflow or action author.
Patches
Users should upgrade to @actions/core v1.9.1.
Workarounds
If you are unable to upgrade the @actions/core package, you can modify your action to ensure that any user input does not contain the delimiter _GitHubActionsFileCommandDelimeter_ before calling core.exportVariable.
References
More information about setting-an-environment-variable in workflows
If you have any questions or comments about this advisory:

Open an issue in actions/toolkit

Related Trello card: https://trello.com/c/priQUGgn/23-niaid-monarch-actions-switch-account-dependabot-alert-1-actions-core-is-vulnerable


Save last known location of closed docking windows

Description
(Note: I believe I reported this before, but can no longer find it in the issues list. The bug still exists in v1.2, so I'm re-posting it. Apologies for the double post, as I was previously logged in with the wrong account!)
When using the RenderDoc API to initiate a capture from my app, the instance of RenderDoc that is launched to display the capture does not retain my docked tab layout from the last instance I ran.
As a concrete example, I have the Texture Viewer tab un-docked into its own window and placed on a second monitor. When performing a capture, the instance of RenderDoc that opens places the "Connection" tab (containing the API information and the list of all the captures that have been taken for that connection) docked inside the Texture Viewer window. Each time this happens I manually drag the Connection tab back and dock it with the other tabs (Pipeline State, Mesh Output, Resource Inspector, Launch Application), but when I re-run my program and take another capture, RenderDoc opens up and places the connection tab docked with the Texture Viewer again. I would expect that RenderDoc would either remember where I have asked the Connection tab to be placed, and place it there, or choose to dock it by default in the main RenderDoc window, rather than next to any other tabs that I've pulled out of that window (alternatively, always dock it next to the Launch Application tab).
Repro steps
Reset RenderDoc layout. Drag the Texture Viewer out into its own window, leaving the other tabs alone and docked in the main RenderDoc window. Exit RenderDoc.
Re-open RenderDoc, and notice that the Texture Viewer is still out in its own window, as expected. Exit RenderDoc.
Use the API to take a capture of an application. Notice that the "Connection" tab has been docked next to the Texture Viewer. Manually move the Connection tab and dock it next to the others in the main RenderDoc window. Exit RenderDoc.
Repeat the above capture step, and notice that the Connection tab is again spawned docked next to the Texture Viewer, instead of where it was placed manually.
Environment

RenderDoc v1.2
Windows 10
D3D11

Granted, this is a VERY minor nitpick, but given that everything else in RenderDoc remembers how I set it up and keeps track of my preferences, it would be really nice if this did as well.

That commit will favour the capture dialog when it's open as mentioned above.
I'm going to leave the issue open because I think this feature would be nice but the main problem is how to store the location where a panel would open without it actually being part of the docking hierarchy. Realistically I doubt I'll get around to this any time soon.


Deferral Nominal and Economic Basis Driver

Deferral Nominal are too sensitive to the input structure.

move the current implementation to the appropriate project
use discounted deferral also for nominal calculation (Rename)
consider having the EconomicBasisDriver default value for LRA PAA set to L
OCI (to be looked into)

The OCI looks into the effect of the yield curve (locked-in vs current). If this parameter is missing from the inputs, it doesn’t find the locked-in (calculated as zero) and the delta is shown.


Return facet list for each page

The JSON result should have
{
"data": [{..}],
"pagination": {},
"facets": {
 "mapping_justification": [],
 "predicate_id": [],
 "mapping_provider": [],
 "object_source": [],
 "confidence": [],
 "mapping_set_title": []
}
}

The facets don't have a label for the UI. How to deal with it?
This is how it's returned:
"facets": {
    "mapping_justification": [
      "https://w3id.org/semapv/LogicalReasoning",
      "https://w3id.org/semapv/LexicalMatching"
    ],
    "predicate": [
      "http://www.w3.org/2004/02/skos/core#closeMatch",
      "http://www.w3.org/2004/02/skos/core#exactMatch"
    ],
    "mapping_provider": null,
    "object_source": null
  }

No no, there is no SEMAPV endpoint - only the vocabulary https://github.com/mapping-commons/semantic-mapping-vocabulary/blob/main/semapv.owl
Basically we have two options:

We have the UI depend on OLS for obtaining labels for sempav, and make a semapv OLS endpoint mandatory when configuring the UI (this could be ok because we can simply link the public OLS endpoint for this purpose)
We add a very basic /terminology endpoint to the SSSOM API to request labels and definitions for semapv / sssom vocabulary. Input: ID (CURIE), output: Label, Definition

I personally prefer the second because this is self contained, but you may want to check with @udp for which solution is advidable.

I looked into the vocabulary file semapv.owl, and it seems they have different IRIs used for the mapping_justification values.
The IRI I have when generating SSSOM:
https://w3id.org/semapv/LexicalMatching
The IRI in the semapv.owl file:
https://w3id.org/semapv/vocab/LexicalMatching
Which one is not up to date?

https://w3id.org/semapv/vocab/LexicalMatching

Is correct.
I had already fixed that in bioregistry: https://bioregistry.io/registry/semapv
Made an issue in sssom py to fix this: https://github.com/mapping-commons/sssom-py/issues/362


Crash on startup in Linux related to #153

I'm running Arch Linux with the latest rustup stable toolchain and neovim v0.4.3. The error happens on the latest nightly toolchain as well.
Neovide crashes with the attached stack trace from the AUR and when using cargo run on master.
I ran a git bisect and it seems the crash starts happened at the following commit;
✦ ➜ git bisect good
#153 is the first bad commit
commit 0b301cb69007316e8588444ddd57d56a88b6ce1d
Author: Raffael Zica<EMAIL_ADDRESS>Date:   Thu Feb 27 16:55:34 2020 +0100

    Shaper includes system symbol fonts into cache

    This should fix #153 on Windows but needs testing on Linux and macOS.

 src/renderer/caching_shaper.rs | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

Stacktrace:
stacktrace.txt

Fixed.

Same error on the latest master (c9b9b3eee8397150deca54dbbdfee853eaf5519d).
stacktrace2.txt

Ok it should actually be fixed now. Can you try again? Sorry for the struggles

No worries and thanks for all the effort!
Still crashing but now the windows pops up briefly and I have a different error:
$ RUST_BACKTRACE=full cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.27s
     Running `target/debug/neovide`
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /rustc/f3e1a954d2ead4e2fc197c7da7d71e6c61bad196/src/libcore/macros/mod.rs:15:40
stack backtrace:
   0:     0x556029da3864 - backtrace::backtrace::libunwind::trace::he25250f78ba1020d
                               at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/libunwind.rs:88
   1:     0x556029da3864 - backtrace::backtrace::trace_unsynchronized::hd7e25f35da233a1e
                               at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/mod.rs:66
   2:     0x556029da3864 - std::sys_common::backtrace::_print_fmt::h5578a566a4c2ae4e
                               at src/libstd/sys_common/backtrace.rs:84
   3:     0x556029da3864 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hd4f87054ec86e936
                               at src/libstd/sys_common/backtrace.rs:61
   4:     0x556029dc99bc - core::fmt::write::h393d55821fa8e2cb
                               at src/libcore/fmt/mod.rs:1025
   5:     0x556029da0517 - std::io::Write::write_fmt::hc6645302c23e4504
                               at src/libstd/io/mod.rs:1426
   6:     0x556029da5a0e - std::sys_common::backtrace::_print::he8a0a3ebec70e1d6
                               at src/libstd/sys_common/backtrace.rs:65
   7:     0x556029da5a0e - std::sys_common::backtrace::print::hc2635fd6c7743ade
                               at src/libstd/sys_common/backtrace.rs:50
   8:     0x556029da5a0e - std::panicking::default_hook::{{closure}}::h9849388798b72b2b
                               at src/libstd/panicking.rs:193
   9:     0x556029da5701 - std::panicking::default_hook::h66e3afff11b02e47
                               at src/libstd/panicking.rs:210
  10:     0x556029da60eb - std::panicking::rust_panic_with_hook::hf6d05969fcffff03
                               at src/libstd/panicking.rs:471
  11:     0x556029da5c9e - rust_begin_unwind
                               at src/libstd/panicking.rs:375
  12:     0x556029dc5d1e - core::panicking::panic_fmt::he794217b0df3f806
                               at src/libcore/panicking.rs:84
  13:     0x556029dc5c6a - core::panicking::panic::h104b3bcaeb5f1ff0
                               at src/libcore/panicking.rs:51
  14:     0x5560293e9032 - core::option::Option<T>::unwrap::hf11eb513fa7d43dc
                               at /rustc/f3e1a954d2ead4e2fc197c7da7d71e6c61bad196/src/libcore/macros/mod.rs:15
  15:     0x55602931865a - neovide::renderer::caching_shaper::CachingShaper::get_skia_font::h4f70f50ed3c9ab15
                               at src/renderer/caching_shaper.rs:189
  16:     0x556029318c57 - neovide::renderer::caching_shaper::CachingShaper::shape::h5504983b2195a264
                               at src/renderer/caching_shaper.rs:214
  17:     0x556029319166 - neovide::renderer::caching_shaper::CachingShaper::shape_cached::hc0f6952afe9c9225
                               at src/renderer/caching_shaper.rs:234
  18:     0x5560293690c8 - neovide::renderer::Renderer::draw_foreground::hb492aa15926eeec9
                               at src/renderer/mod.rs:97
  19:     0x556029369de5 - neovide::renderer::Renderer::draw::hee9de24d542ac628
                               at src/renderer/mod.rs:155
  20:     0x55602931ead9 - neovide::window::WindowWrapper::draw_frame::{{closure}}::h5047be50bc98c8be
                               at src/window.rs:274
  21:     0x55602935d78c - skulpin::renderer::renderer::Renderer::do_draw::haf32b9cb3d1d3818
                               at /home/dpendolino/.cargo/git/checkouts/skulpin-2e78d5d442751fde/3c87846/src/renderer/renderer.rs:409
  22:     0x55602935cc69 - skulpin::renderer::renderer::Renderer::draw::h9585f1ba006cc7b9
                               at /home/dpendolino/.cargo/git/checkouts/skulpin-2e78d5d442751fde/3c87846/src/renderer/renderer.rs:300
  23:     0x5560292c4253 - neovide::window::WindowWrapper::draw_frame::hcd500a54db5f0b84
                               at src/window.rs:271
  24:     0x5560292c48c7 - neovide::window::ui_loop::h90bb22428641f4b7
                               at src/window.rs:334
  25:     0x556029276311 - neovide::main::h4ecea022b68cece7
                               at src/main.rs:31
  26:     0x556029308570 - std::rt::lang_start::{{closure}}::hf51aa8f4ea25ce42
                               at /rustc/f3e1a954d2ead4e2fc197c7da7d71e6c61bad196/src/libstd/rt.rs:67
  27:     0x556029da5b33 - std::rt::lang_start_internal::{{closure}}::h4aedff5d9863b36b
                               at src/libstd/rt.rs:52
  28:     0x556029da5b33 - std::panicking::try::do_call::h0630fe3da32a089b
                               at src/libstd/panicking.rs:292
  29:     0x556029dae01a - __rust_maybe_catch_panic
                               at src/libpanic_unwind/lib.rs:78
  30:     0x556029da6580 - std::panicking::try::hdfbe2fd873ac646c
                               at src/libstd/panicking.rs:270
  31:     0x556029da6580 - std::panic::catch_unwind::hd7a9c10fa2bee1bc
                               at src/libstd/panic.rs:394
  32:     0x556029da6580 - std::rt::lang_start_internal::hb8081e0e7e42ac0d
                               at src/libstd/rt.rs:51
  33:     0x556029308549 - std::rt::lang_start::h6a00d96480657865
                               at /rustc/f3e1a954d2ead4e2fc197c7da7d71e6c61bad196/src/libstd/rt.rs:67
  34:     0x55602927634a - main
  35:     0x7f4611c10023 - __libc_start_main
  36:     0x55602924d34e - _start
  37:                0x0 - <unknown>

The process also never seems to exit.

are you running from the release or building from master for the above error?
Sent with GitHawk

Sorry , my bad for not specifying. The above trace was from the current master branch.
I have also tried on the 0.5.0 tag and get this error instead:
 RUST_BACKTRACE=full cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.16s
     Running `target/debug/neovide`
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /rustc/f3e1a954d2ead4e2fc197c7da7d71e6c61bad196/src/libcore/macros/mod.rs:15:40
stack backtrace:
   0:     0x556040c1b9c4 - backtrace::backtrace::libunwind::trace::he25250f78ba1020d
                               at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/libunwind.rs:88
   1:     0x556040c1b9c4 - backtrace::backtrace::trace_unsynchronized::hd7e25f35da233a1e
                               at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/mod.rs:66
   2:     0x556040c1b9c4 - std::sys_common::backtrace::_print_fmt::h5578a566a4c2ae4e
                               at src/libstd/sys_common/backtrace.rs:84
   3:     0x556040c1b9c4 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hd4f87054ec86e936
                               at src/libstd/sys_common/backtrace.rs:61
   4:     0x556040c41b1c - core::fmt::write::h393d55821fa8e2cb
                               at src/libcore/fmt/mod.rs:1025
   5:     0x556040c18677 - std::io::Write::write_fmt::hc6645302c23e4504
                               at src/libstd/io/mod.rs:1426
   6:     0x556040c1db6e - std::sys_common::backtrace::_print::he8a0a3ebec70e1d6
                               at src/libstd/sys_common/backtrace.rs:65
   7:     0x556040c1db6e - std::sys_common::backtrace::print::hc2635fd6c7743ade
                               at src/libstd/sys_common/backtrace.rs:50
   8:     0x556040c1db6e - std::panicking::default_hook::{{closure}}::h9849388798b72b2b
                               at src/libstd/panicking.rs:193
   9:     0x556040c1d861 - std::panicking::default_hook::h66e3afff11b02e47
                               at src/libstd/panicking.rs:210
  10:     0x556040c1e24b - std::panicking::rust_panic_with_hook::hf6d05969fcffff03
                               at src/libstd/panicking.rs:471
  11:     0x556040c1ddfe - rust_begin_unwind
                               at src/libstd/panicking.rs:375
  12:     0x556040c3de7e - core::panicking::panic_fmt::he794217b0df3f806
                               at src/libcore/panicking.rs:84
  13:     0x556040c3ddca - core::panicking::panic::h104b3bcaeb5f1ff0
                               at src/libcore/panicking.rs:51
  14:     0x55604026fa22 - core::option::Option<T>::unwrap::hf11eb513fa7d43dc
                               at /rustc/f3e1a954d2ead4e2fc197c7da7d71e6c61bad196/src/libcore/macros/mod.rs:15
  15:     0x55604023303a - neovide::renderer::caching_shaper::CachingShaper::get_skia_font::hf85486747b31ca25
                               at src/renderer/caching_shaper.rs:175
  16:     0x556040233517 - neovide::renderer::caching_shaper::CachingShaper::shape::h943f606b4e4c1f04
                               at src/renderer/caching_shaper.rs:200
  17:     0x5560402339f6 - neovide::renderer::caching_shaper::CachingShaper::shape_cached::he963e47d6cb97826
                               at src/renderer/caching_shaper.rs:220
  18:     0x55604016a798 - neovide::renderer::Renderer::draw_foreground::h895ae6bb4a0f192a
                               at src/renderer/mod.rs:97
  19:     0x55604016b4b5 - neovide::renderer::Renderer::draw::ha6dbc8eeecaa4c93
                               at src/renderer/mod.rs:155
  20:     0x5560400d9c4b - neovide::window::WindowWrapper::draw_frame::{{closure}}::hef646911c6e04b0c
                               at src/window.rs:249
  21:     0x556040144c4c - skulpin::renderer::renderer::Renderer::do_draw::h313fc65f39882f27
                               at /home/dpendolino/.cargo/git/checkouts/skulpin-2e78d5d442751fde/9c62459/src/renderer/renderer.rs:409
  22:     0x556040144129 - skulpin::renderer::renderer::Renderer::draw::h5bbee638c13412aa
                               at /home/dpendolino/.cargo/git/checkouts/skulpin-2e78d5d442751fde/9c62459/src/renderer/renderer.rs:300
  23:     0x5560401b478d - neovide::window::WindowWrapper::draw_frame::h31a6606248939b25
                               at src/window.rs:246
  24:     0x5560401b4d8d - neovide::window::ui_loop::h6624d8c68d9347cf
                               at src/window.rs:304
  25:     0x55604023d541 - neovide::main::hebbacce28095f401
                               at src/main.rs:31
  26:     0x556040189b80 - std::rt::lang_start::{{closure}}::h5974723f4987a49e
                               at /rustc/f3e1a954d2ead4e2fc197c7da7d71e6c61bad196/src/libstd/rt.rs:67
  27:     0x556040c1dc93 - std::rt::lang_start_internal::{{closure}}::h4aedff5d9863b36b
                               at src/libstd/rt.rs:52
  28:     0x556040c1dc93 - std::panicking::try::do_call::h0630fe3da32a089b
                               at src/libstd/panicking.rs:292
  29:     0x556040c2617a - __rust_maybe_catch_panic
                               at src/libpanic_unwind/lib.rs:78
  30:     0x556040c1e6e0 - std::panicking::try::hdfbe2fd873ac646c
                               at src/libstd/panicking.rs:270
  31:     0x556040c1e6e0 - std::panic::catch_unwind::hd7a9c10fa2bee1bc
                               at src/libstd/panic.rs:394
  32:     0x556040c1e6e0 - std::rt::lang_start_internal::hb8081e0e7e42ac0d
                               at src/libstd/rt.rs:51
  33:     0x556040189b59 - std::rt::lang_start::h76a60a04db8b47f8
                               at /rustc/f3e1a954d2ead4e2fc197c7da7d71e6c61bad196/src/libstd/rt.rs:67
  34:     0x55604023d57a - main
  35:     0x7f95f7a87023 - __libc_start_main
  36:     0x5560400d52fe - _start
  37:                0x0 - <unknown>
[xcb] Unknown sequence number while appending request
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
neovide: xcb_io.c:145: append_pending_request: Assertion `!xcb_xlib_unknown_seq_number' failed.
Aborted (core dumped)

Mh so I looked into it and the first crash is probably fixed now and could have been avoided by declaring Unifont as a dependency on Linux. The master stack trace relates to #145 tho.
I'm looking into reproducing this type of crash and see if I can work around it.

I added some more error propagation to the font loading which might do a better job of catching the error

@SirJson maybe we should embed Unifont? I know people are already complaining about the build size, but I figure it would just fix some of these issues...

Yea I just saw that 20 minutes ago someone exactly implemented the workaround, and I was wondering why it didn't crash :grin:
So the issue with Unifont is the licence. As far as I know it is under GPL3 which would mean that if Unifont is embedded neovide also has to be GPL3.
I think the better solution is to detect that the symbol font isn't there, tell the user that and give him the option to choose another symbol font instead.
Also now with the workaround in place I think a similar notice should be implemented for text fonts. Because right now if I build without embedded fonts, don't have Unifont on my system and set my guifont to "Tamzen" I just get a empty window without any error message.

The struggle becomes how to notify the user. I suppose I can use error logging so that the message gets printed to the console, but that doesn't exactly work on windows machines where a console isn't necessarily visible
I seem to recall sdl having a messagebox system... I'll look into it.

Weird, I also thought SDL had something like this but I can't find it in the Wiki.
But I wouldn't worry about Windows too much here, a call to MessageBoxW is super easy. It's the other two platforms where SDL would really help.

https://rust-sdl2.github.io/rust-sdl2/sdl2/messagebox/index.html

Atm all errors are either logging messages or std out. What we are proposing here is a third category which is a messagebox error for when we don't think the editor will recover but need to show some text to the user that we are sure they would see. Maybe I could hook error logs and always show them via messagebox since they should be fatal in general?

@dpendolino sorry to keep attempting. Can you try again? I fixed the next error you encountered.

@Kethku No worries! Latest master is building and running great, just a couple of warnings:
warning: unused variable: `command_error`
  --> src/bridge/mod.rs:95:16
   |
95 |     if let Err(command_error) = nvim.command("runtime! ginit.vim").await {
   |                ^^^^^^^^^^^^^ help: consider prefixing with an underscore: `_command_error`
   |
   = note: `#[warn(unused_variables)]` on by default

warning: field is never read: `ignore_text_input`
  --> src/window.rs:52:5
   |
52 |     ignore_text_input: bool,
   |     ^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: `#[warn(dead_code)]` on by default

    Finished dev [unoptimized + debuginfo] target(s) in 1m 35s
     Running `target/debug/neovide`

Thanks!


The point you selected is not in the image.

data: sct_testing_small/20151025_emil/t2
sct_propseg -i t2.nii.gz -c t2 -init-mask viewer

likely related to anisotropic resolution?

On my images it doesn't work either. Also the doc of propseg doesn't refer to option -init-mask viewer


Lazy-loading the required modules to avoid loading the global config

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 90.01%. Comparing base (82227b2) to head (aa76b54).

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #10      +/-   ##
==========================================
- Coverage   90.05%   90.01%   -0.04%
==========================================
  Files          13       13
  Lines         533      531       -2
==========================================
- Hits          480      478       -2
  Misses         53       53

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


✨ Support daemonSet with AddOnTemplate

Summary
Related issue(s)
https://github.com/open-cluster-management-io/ocm/issues/368
Fixes #

/cc @qiujian16 @zhiweiyin318

/approve

/lgtm
/hold

LGTM

@zhiweiyin318 @haoqing0110 Some conflicts have just been resolved, PTAL.

/lgtm

/unhold


All public members of YAXSerializer (generic/non-generic) should be fully covered by unit tests

Included in PR #186


centos: Update CentOS documentation

SLES documentation was created based on the CentOS document. Some
updates were made to add more clarity to the installation steps. This
commit adds the updates back to the CentOS guide.
Fixes: #864

lgtm

Hi @klynnrif - could you review please?

Hi @klynnrif - please could you review?

@jodh-intel This lgtm 👍 If I need to take additional action on this let me know. Thanks!

Hi @klynnrif - thanks, but please can you add the "lgtm" comment at the start of a line to trigger the approval (this is documented here, but admittedly it doesn't exactly stand out https://github.com/clearcontainers/runtime/blob/master/CONTRIBUTING.md#reviews :-)

@jodh-intel ...someday I'll have it down :) Thanks!

pullapprove seems to be "stuck" as it's ignoring the doc team approval. As we're all happy with this, merging...


Editing permissions

Allow specific records to be edited by a selectable list of users

Backend functionality only: record owners should be a list of users (store the user_id).

Also, the review status should be modifiable only by admins (as required by the clients).

Can we add a permission to allow teams to be read without authentication, for the registration page?

record_editors = models.ManyToManyField(User, blank=True) is added to the record model to store a list of users that can edit a record instance. A string of unlinked user names cannot be created upon the creation, as the ManyToManyField only works with a record_id that is generated after the creation.


Fix engagement started on the chat screen

Jira issue:
https://glia.atlassian.net/browse/MOB-3888
What was solved?
When the chat screen opens with the secure conversation state, resubscribe to the engagement streams. This solves the upgrade to chat state issue.
Release notes:

[ ] Feature
[x] Ignore
[ ] Release notes (Is it clear from the description here?)
[ ] Migration guide (If changes are needed for integrator already using the SDK - what needs to be communicated? Add underneath please)

Additional info:

[ ] Is the feature sufficiently tested? All tests fixed? Necessary unit, acceptance, snapshots added? Check that at least new public classes & methods are covered with unit tests
[ ] Did you add logging beneficial for troubleshooting of customer issues?
[ ] Did you add new logging? We would like the logging between platforms to be similar. Refer to Logging from Android SDKs → Things to consider for newly added logs in Confluence for more information.

Screenshots:

@AndriiHorishniiMOC, could you please rebase this branch?

@AndriiHorishniiMOC, could you please rebase this branch?

I've rebased it ✅


pick lower timeout among all values, rather than the first available

Currently if idle timer is lower than loss timer, but loss timer is not
None, we will pick the loss timer over the idle one, so we might end up
never timing out the connection if there are outstanding packets that
have not been acknowledged.

Oh wait, this doesn't work actually.

Correction, it does work, but causes a bunch of spurious timeouts when draining timer is set. Updated it with fix.

Currently if idle timer is lower than loss timer, but loss timer is not None,

Can you describe what scenario it is? My understanding is that idle timeout is always bigger than PTO. ("10.2.  Idle Timeout" of -transport) and if there is unacked data we should continue with PTO  first.

@junhochoi the PTO timer has a backoff mechanism (timeout * (2 ^ pto_count)) in case of repeated loss, so the idea here is that if pto_count is big enough, then the PTO timer will exceed idle timer.
Indeed the spec says:

When a PTO timer expires, the PTO period MUST be set to twice its current value. This exponential reduction in the sender’s rate is important because the PTOs might be caused by loss of packets or acknowledgements due to severe congestion. The life of a connection that is experiencing consecutive PTOs is limited by the endpoint’s idle timeout.

That last sentence is what appears to not be working correctly here. Though we are actually still testing whether this works as intended so I added the hold label back.

Also note that (-transport 10.2) it looks updated since draft 19:

If the idle timeout is enabled, a connection is silently closed and the state is discarded when it remains idle for longer than both the advertised idle timeout (see Section 18.2) and three times the
current Probe Timeout (PTO).
https://github.com/quicwg/base-drafts/commit/6f09658c18cfeca0df0c4b1fc435cceaf550b7e8

So idle timeout will be max (<idle timeout advertised>, 3 * current_pto_timeout)
And it seems like we restart idle timer only when sending packet, not when receiving packet. but this can be a separate issue.

We restart the idle timer when receiving packets as well https://github.com/cloudflare/quiche/blob/master/src/lib.rs#L1363


Do we have the plan to support go modules

Since go modules has been released for quit a long time and accepted by the community, I think it is convenient to have this new golang feature supported.

Go modules is a great way to maintain dependencies, now we are using dep which works well for us. Go module is alse acceptable, would you like to submit a PR changing from dep to go moduels?

@shafreeck Sure, I will give a try. :)

I tried to switch to go1.11.2 with modules, but a package named github.com/pingcap/tidb(v2.0.8, according to Gopkg.lock)  raises the following errors when building.
# github.com/pingcap/tidb/util/mock
../../.go/pkg/mod/github.com/pingcap/tidb@v2.0.8+incompatible/util/mock/client.go:58:7: undefined: tipb.ExprType_And
../../.go/pkg/mod/github.com/pingcap/tidb@v2.0.8+incompatible/util/mock/client.go:58:26: undefined: tipb.ExprType_Or
../../.go/pkg/mod/github.com/pingcap/tidb@v2.0.8+incompatible/util/mock/client.go:58:44: undefined: tipb.ExprType_Not
../../.go/pkg/mod/github.com/pingcap/tidb@v2.0.8+incompatible/util/mock/client.go:61:7: undefined: tipb.ExprType_LT
../../.go/pkg/mod/github.com/pingcap/tidb@v2.0.8+incompatible/util/mock/client.go:61:25: undefined: tipb.ExprType_LE
../../.go/pkg/mod/github.com/pingcap/tidb@v2.0.8+incompatible/util/mock/client.go:61:43: undefined: tipb.ExprType_EQ
../../.go/pkg/mod/github.com/pingcap/tidb@v2.0.8+incompatible/util/mock/client.go:61:61: undefined: tipb.ExprType_NE
../../.go/pkg/mod/github.com/pingcap/tidb@v2.0.8+incompatible/util/mock/client.go:62:3: undefined: tipb.ExprType_GE
../../.go/pkg/mod/github.com/pingcap/tidb@v2.0.8+incompatible/util/mock/client.go:62:21: undefined: tipb.ExprType_GT
../../.go/pkg/mod/github.com/pingcap/tidb@v2.0.8+incompatible/util/mock/client.go:62:39: undefined: tipb.ExprType_NullEQ
../../.go/pkg/mod/github.com/pingcap/tidb@v2.0.8+incompatible/util/mock/client.go:62:39: too many errors
# github.com/pingcap/tidb/parser
../../.go/pkg/mod/github.com/pingcap/tidb@v2.0.8+incompatible/parser/lexer.go:132:26: undefined: yySymType
../../.go/pkg/mod/github.com/pingcap/tidb@v2.0.8+incompatible/parser/misc.go:594:24: undefined: yySymType
../../.go/pkg/mod/github.com/pingcap/tidb@v2.0.8+incompatible/parser/yy_parser.go:70:11: undefined: yySymType
../../.go/pkg/mod/github.com/pingcap/tidb@v2.0.8+incompatible/parser/yy_parser.go:71:9: undefined: yySymType
../../.go/pkg/mod/github.com/pingcap/tidb@v2.0.8+incompatible/parser/yy_parser.go:72:9: undefined: yySymType
# github.com/pingcap/tidb/store/tikv
../../.go/pkg/mod/github.com/pingcap/tidb@v2.0.8+incompatible/store/tikv/coprocessor.go:72:7: undefined: tipb.ExprType_And
../../.go/pkg/mod/github.com/pingcap/tidb@v2.0.8+incompatible/store/tikv/coprocessor.go:72:26: undefined: tipb.ExprType_Or
../../.go/pkg/mod/github.com/pingcap/tidb@v2.0.8+incompatible/store/tikv/coprocessor.go:72:44: undefined: tipb.ExprType_Not
../../.go/pkg/mod/github.com/pingcap/tidb@v2.0.8+incompatible/store/tikv/coprocessor.go:75:7: undefined: tipb.ExprType_LT
../../.go/pkg/mod/github.com/pingcap/tidb@v2.0.8+incompatible/store/tikv/coprocessor.go:75:25: undefined: tipb.ExprType_LE
../../.go/pkg/mod/github.com/pingcap/tidb@v2.0.8+incompatible/store/tikv/coprocessor.go:75:43: undefined: tipb.ExprType_EQ
../../.go/pkg/mod/github.com/pingcap/tidb@v2.0.8+incompatible/store/tikv/coprocessor.go:75:61: undefined: tipb.ExprType_NE
../../.go/pkg/mod/github.com/pingcap/tidb@v2.0.8+incompatible/store/tikv/coprocessor.go:76:3: undefined: tipb.ExprType_GE
../../.go/pkg/mod/github.com/pingcap/tidb@v2.0.8+incompatible/store/tikv/coprocessor.go:76:21: undefined: tipb.ExprType_GT
../../.go/pkg/mod/github.com/pingcap/tidb@v2.0.8+incompatible/store/tikv/coprocessor.go:76:39: undefined: tipb.ExprType_NullEQ
../../.go/pkg/mod/github.com/pingcap/tidb@v2.0.8+incompatible/store/tikv/coprocessor.go:76:39: too many errors

It is weird, and seems to tell that the github.com/pingcap/tidb is not a completed go package.
And when I grep under the vender folder in the codebase, I do find some defined types missing from the  newly cloned repo. I got confused. Could you please tell what's happening there? @shafreeck

Sorry for the delayed response. It is a problem of TiKV: there is a generated go file that will be ignored be go dep because of the .gitignore.

@shafreeck So, do we have any workaround for the TiKV issue? Is it a version specific issue?

@lylex We did some workaround when use dep that copies the generated file to the vendor.  I did not try the go module. Maybe you should try using TiDB 2.1?


Update dependencies

The automatic build is failing on #945 because the recent update of appcompat changed some parameters from nullable to non-nullable and vice-versa.
This PR should fix the build.

@rosariopfernandes thank you!  This is great.


KYLIN-4925 Use Spark3 for Kylin 4.0

Proposed changes
Describe the big picture of your changes here to communicate to the maintainers why we should accept this pull request. If it fixes a bug or resolves a feature request, be sure to link to that issue.
Types of changes
What types of changes does your code introduce to Kylin?
Put an x in the boxes that apply

[ ] Bugfix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation Update (if none of the other choices apply)

Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

[x] I have create an issue on Kylin's jira, and have described the bug/feature there in detail
[x] Commit messages in my PR start with the related jira ID, like "KYLIN-0000 Make Kylin project open-source"
[x] Compiling and unit tests pass locally with my changes
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] If this change need a document change, I will prepare another pr against the document branch
[ ] Any dependent changes have been merged

Further comments
Tested for Spark 2.4.7 and Spark 3.1.1. We make it compatible to use either Spark 2.4 (default) or Spark 3.1. When build with spark 3.1, active profile with mvn -Pspark3.

@xiacongling Thank you for your contribution, I will review this PR ASAP.

Codecov Report

:exclamation: No coverage uploaded for pull request base (kylin-on-parquet-v2@f5ec8f3). Click here to learn what that means.
The diff coverage is n/a.

@@                  Coverage Diff                   @@
##             kylin-on-parquet-v2    #1601   +/-   ##
======================================================
  Coverage                       ?   24.52%
  Complexity                     ?     4648
======================================================
  Files                          ?     1141
  Lines                          ?    64530
  Branches                       ?     9309
======================================================
  Hits                           ?    15823
  Misses                         ?    47060
  Partials                       ?     1647

Continue to review full report at Codecov.

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

LGTM, thank you for your contribution, this feature is great.

Why put classes of package org.apache.spark.memory into folder org/apache/spark/monitor?

@pan3793 Thanks for your mentioning, I will check later.


ModuleNotFoundError: No module named 'prometheus_client'

Describe the bug
In the protocoll of the "suivi-bourse-app"-Container I receive the message "ModuleNotFoundError: No module named 'prometheus_client'" after strating successfully the docker-compose.yaml.
To Reproduce
Steps to reproduce the behavior:

Execute docker-compose.yaml
Go to protocoll of "suivi-bourse-app"-Container

Expected behavior
No error message because, 'prometheus_client' should be part of the container
Screenshots

Installation mode: (choose one)

[ ] Standalone
[ ] Docker
[X] Docker-Compose

regards
Alex

Hi,
The new version of the image (3.1.0) fixes this issue ! I tested it and it should work now.
Thanks to contribute to this project

Perfect Paul! Image 3.1.0 works. "suivi-bourse-app"-Container pulls data and prometheus collects :-)

Thanks for the hint!
regards
Alex


Add Main Menu Basic

Can't control the character after clicking "Play" in main menu.

Fixed issue