performance hint: cupy_backends/cuda/api/driver.pyx:233:31: Exception check after calling 'cuModuleUnload' will always require the GIL to be acquired. Declare 'cuModuleUnload' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
performance hint: cupy_backends/cuda/api/driver.pyx:243:36: Exception check after calling 'cuModuleGetFunction' will always require the GIL to be acquired. Declare 'cuModuleGetFunction' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
performance hint: cupy_backends/cuda/api/driver.pyx:255:34: Exception check after calling 'cuModuleGetGlobal' will always require the GIL to be acquired. Declare 'cuModuleGetGlobal' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
performance hint: cupy_backends/cuda/api/driver.pyx:268:31: Exception check after calling 'cuLaunchKernel' will always require the GIL to be acquired. Declare 'cuLaunchKernel' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
performance hint: cupy_backends/cuda/api/driver.pyx:284:42: Exception check after calling 'cuLaunchCooperativeKernel' will always require the GIL to be acquired. Declare 'cuLaunchCooperativeKernel' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
performance hint: cupy_backends/cuda/api/driver.pyx:300:35: Exception check after calling 'cuFuncGetAttribute' will always require the GIL to be acquired. Declare 'cuFuncGetAttribute' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
performance hint: cupy_backends/cuda/api/driver.pyx:311:35: Exception check after calling 'cuFuncSetAttribute' will always require the GIL to be acquired. Declare 'cuFuncSetAttribute' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
performance hint: cupy_backends/cuda/api/driver.pyx:327:60: Exception check after calling 'cuOccupancyMaxActiveBlocksPerMultiprocessor' will always require the GIL to be acquired. Declare 'cuOccupancyMaxActiveBlocksPerMultiprocessor' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
performance hint: cupy_backends/cuda/api/driver.pyx:340:49: Exception check after calling 'cuOccupancyMaxPotentialBlockSize' will always require the GIL to be acquired. Declare 'cuOccupancyMaxPotentialBlockSize' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
performance hint: cupy_backends/cuda/api/driver.pyx:355:31: Exception check after calling 'cuStreamGetCtx' will always require the GIL to be acquired. Declare 'cuStreamGetCtx' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
[53/62] Cythonizing cupy_backends/cuda/libs/cublas.pyx
[54/62] Cythonizing cupy_backends/cuda/libs/cudnn.pyx
[55/62] Cythonizing cupy_backends/cuda/libs/curand.pyx
warning: cupy_backends/cuda/api/runtime.pxd:28:0: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_typedef.pxi:120:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_typedef.pxi:135:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_typedef.pxi:151:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_typedef.pxi:339:8: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/runtime.pxd:28:0: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_typedef.pxi:120:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_typedef.pxi:135:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_typedef.pxi:151:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_typedef.pxi:339:8: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/driver.pxd:8:0: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/driver.pxd:8:0: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_enum.pxd:102:0: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_enum.pxd:219:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/libs/nvrtc.pxd:8:0: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_enum.pxd:102:0: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_enum.pxd:219:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/runtime.pxd:28:0: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_typedef.pxi:120:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_typedef.pxi:135:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_typedef.pxi:151:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_typedef.pxi:339:8: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/driver.pxd:8:0: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
[56/62] Cythonizing cupy_backends/cuda/libs/cusolver.pyx
warning: cupy_backends/cuda/api/_runtime_enum.pxd:102:0: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_enum.pxd:219:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/runtime.pxd:28:0: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_typedef.pxi:120:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_typedef.pxi:135:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_typedef.pxi:151:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
[57/62] Cythonizing cupy_backends/cuda/libs/cusparse.pyx
warning: cupy_backends/cuda/api/_runtime_typedef.pxi:339:8: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/driver.pxd:8:0: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
[58/62] Cythonizing cupy_backends/cuda/libs/nvrtc.pyx
warning: cupy_backends/cuda/libs/nvrtc.pxd:8:0: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/libs/nvrtc.pyx:24:0: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_enum.pxd:102:0: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_enum.pxd:219:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/libs/cusparse.pyx:1374:0: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/runtime.pxd:28:0: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_typedef.pxi:120:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_typedef.pxi:135:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_typedef.pxi:151:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_typedef.pxi:339:8: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/driver.pxd:8:0: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_enum.pxd:102:0: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_enum.pxd:219:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/libs/cusparse.pyx:4988:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
[59/62] Cythonizing cupy_backends/cuda/libs/nvtx.pyx
performance hint: cupy_backends/cuda/libs/nvrtc.pyx:60:29: Exception check after calling 'nvrtcVersion' will always require the GIL to be acquired. Declare 'nvrtcVersion' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
performance hint: cupy_backends/cuda/libs/nvrtc.pyx:72:42: Exception check after calling 'nvrtcGetNumSupportedArchs' will always require the GIL to be acquired. Declare 'nvrtcGetNumSupportedArchs' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
performance hint: cupy_backends/cuda/libs/nvrtc.pyx:75:43: Exception check after calling 'nvrtcGetSupportedArchs' will always require the GIL to be acquired. Declare 'nvrtcGetSupportedArchs' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
performance hint: cupy_backends/cuda/libs/nvrtc.pyx:110:35: Exception check after calling 'nvrtcCreateProgram' will always require the GIL to be acquired. Declare 'nvrtcCreateProgram' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
performance hint: cupy_backends/cuda/libs/nvrtc.pyx:121:36: Exception check after calling 'nvrtcDestroyProgram' will always require the GIL to be acquired. Declare 'nvrtcDestroyProgram' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
performance hint: cupy_backends/cuda/libs/nvrtc.pyx:136:36: Exception check after calling 'nvrtcCompileProgram' will always require the GIL to be acquired. Declare 'nvrtcCompileProgram' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
performance hint: cupy_backends/cuda/libs/nvrtc.pyx:147:32: Exception check after calling 'nvrtcGetPTXSize' will always require the GIL to be acquired. Declare 'nvrtcGetPTXSize' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
performance hint: cupy_backends/cuda/libs/nvrtc.pyx:154:28: Exception check after calling 'nvrtcGetPTX' will always require the GIL to be acquired. Declare 'nvrtcGetPTX' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
performance hint: cupy_backends/cuda/libs/nvrtc.pyx:169:34: Exception check after calling 'nvrtcGetCUBINSize' will always require the GIL to be acquired. Declare 'nvrtcGetCUBINSize' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
performance hint: cupy_backends/cuda/libs/nvrtc.pyx:179:30: Exception check after calling 'nvrtcGetCUBIN' will always require the GIL to be acquired. Declare 'nvrtcGetCUBIN' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
performance hint: cupy_backends/cuda/libs/nvrtc.pyx:198:33: Exception check after calling 'nvrtcGetNVVMSize' will always require the GIL to be acquired. Declare 'nvrtcGetNVVMSize' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
performance hint: cupy_backends/cuda/libs/nvrtc.pyx:204:29: Exception check after calling 'nvrtcGetNVVM' will always require the GIL to be acquired. Declare 'nvrtcGetNVVM' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
performance hint: cupy_backends/cuda/libs/nvrtc.pyx:217:39: Exception check after calling 'nvrtcGetProgramLogSize' will always require the GIL to be acquired. Declare 'nvrtcGetProgramLogSize' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
performance hint: cupy_backends/cuda/libs/nvrtc.pyx:224:35: Exception check after calling 'nvrtcGetProgramLog' will always require the GIL to be acquired. Declare 'nvrtcGetProgramLog' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
performance hint: cupy_backends/cuda/libs/nvrtc.pyx:236:39: Exception check after calling 'nvrtcAddNameExpression' will always require the GIL to be acquired. Declare 'nvrtcAddNameExpression' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
performance hint: cupy_backends/cuda/libs/nvrtc.pyx:246:36: Exception check after calling 'nvrtcGetLoweredName' will always require the GIL to be acquired. Declare 'nvrtcGetLoweredName' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
[60/62] Cythonizing cupy_backends/cuda/stream.pyx
[61/62] Cythonizing cupyx/cudnn.pyx
warning: cupy_backends/cuda/api/runtime.pxd:28:0: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_typedef.pxi:120:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_typedef.pxi:135:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_typedef.pxi:151:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/runtime.pxd:28:0: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_typedef.pxi:120:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_typedef.pxi:135:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_typedef.pxi:151:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_typedef.pxi:339:8: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/driver.pxd:8:0: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_enum.pxd:102:0: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_enum.pxd:219:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_typedef.pxi:339:8: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/driver.pxd:8:0: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_enum.pxd:102:0: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_enum.pxd:219:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
[62/62] Cythonizing cupyx/cusolver.pyx
warning: cupy_backends/cuda/api/runtime.pxd:28:0: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_typedef.pxi:120:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_typedef.pxi:135:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_typedef.pxi:151:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_typedef.pxi:339:8: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/driver.pxd:8:0: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_enum.pxd:102:0: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: cupy_backends/cuda/api/_runtime_enum.pxd:219:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
performance hint: cupyx/cusolver.pyx:362:22: Exception check after calling 'gesvd' will always require the GIL to be acquired. Declare 'gesvd' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
performance hint: cupyx/cusolver.pyx:923:22: Exception check after calling 'geqrf' will always require the GIL to be acquired. Declare 'geqrf' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
performance hint: cupyx/cusolver.pyx:973:22: Exception check after calling 'orgqr' will always require the GIL to be acquired. Declare 'orgqr' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
multiprocessing.pool.RemoteTraceback:
"""
Traceback (most recent call last):
  File "/home/ev-br/miniforge3/envs/cupyx/lib/python3.10/multiprocessing/pool.py", line 125, in worker
    result = (True, func(*args, **kwds))
  File "/home/ev-br/miniforge3/envs/cupyx/lib/python3.10/multiprocessing/pool.py", line 48, in mapstar
    return list(map(*args))
  File "/home/ev-br/miniforge3/envs/cupyx/lib/python3.10/site-packages/Cython/Build/Dependencies.py", line 1345, in cythonize_one_helper
    return cythonize_one(*m)
  File "/home/ev-br/miniforge3/envs/cupyx/lib/python3.10/site-packages/Cython/Build/Dependencies.py", line 1321, in cythonize_one
    raise CompileError(None, pyx_file)
Cython.Compiler.Errors.CompileError: cupy/_core/_kernel.pyx
"""

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/home/ev-br/repos/cupy/setup.py", line 126, in <module>
    setup(
  File "/home/ev-br/miniforge3/envs/cupyx/lib/python3.10/site-packages/setuptools/__init__.py", line 103, in setup
    return distutils.core.setup(**attrs)
  File "/home/ev-br/miniforge3/envs/cupyx/lib/python3.10/site-packages/setuptools/_distutils/core.py", line 185, in setup
    return run_commands(dist)
  File "/home/ev-br/miniforge3/envs/cupyx/lib/python3.10/site-packages/setuptools/_distutils/core.py", line 201, in run_commands
    dist.run_commands()
  File "/home/ev-br/miniforge3/envs/cupyx/lib/python3.10/site-packages/setuptools/_distutils/dist.py", line 969, in run_commands
    self.run_command(cmd)
  File "/home/ev-br/miniforge3/envs/cupyx/lib/python3.10/site-packages/setuptools/dist.py", line 963, in run_command
    super().run_command(command)
  File "/home/ev-br/miniforge3/envs/cupyx/lib/python3.10/site-packages/setuptools/_distutils/dist.py", line 988, in run_command
    cmd_obj.run()
  File "/home/ev-br/miniforge3/envs/cupyx/lib/python3.10/site-packages/setuptools/command/develop.py", line 33, in run
    self.install_for_development()
  File "/home/ev-br/miniforge3/envs/cupyx/lib/python3.10/site-packages/setuptools/command/develop.py", line 108, in install_for_development
    self.run_command('build_ext')
  File "/home/ev-br/miniforge3/envs/cupyx/lib/python3.10/site-packages/setuptools/_distutils/cmd.py", line 318, in run_command
    self.distribution.run_command(command)
  File "/home/ev-br/miniforge3/envs/cupyx/lib/python3.10/site-packages/setuptools/dist.py", line 963, in run_command
    super().run_command(command)
  File "/home/ev-br/miniforge3/envs/cupyx/lib/python3.10/site-packages/setuptools/_distutils/dist.py", line 988, in run_command
    cmd_obj.run()
  File "/home/ev-br/miniforge3/envs/cupyx/lib/python3.10/site-packages/setuptools/command/build_ext.py", line 88, in run
    _build_ext.run(self)
  File "/home/ev-br/miniforge3/envs/cupyx/lib/python3.10/site-packages/setuptools/_distutils/command/build_ext.py", line 345, in run
    self.build_extensions()
  File "/home/ev-br/repos/cupy/install/cupy_builder/_command.py", line 161, in build_extensions
    self._cythonize(num_jobs)
  File "/home/ev-br/repos/cupy/install/cupy_builder/_command.py", line 140, in _cythonize
    Cython.Build.cythonize(
  File "/home/ev-br/miniforge3/envs/cupyx/lib/python3.10/site-packages/Cython/Build/Dependencies.py", line 1145, in cythonize
    result.get(99999)  # seconds
  File "/home/ev-br/miniforge3/envs/cupyx/lib/python3.10/multiprocessing/pool.py", line 771, in get
    raise self._value
Cython.Compiler.Errors.CompileError: cupy/_core/_kernel.pyx

Cython 3 is not supported yet (https://github.com/cupy/cupy/issues/7870), try to downgrade to 0.29.x, remove the local build directory, and retry from a fresh state.

$ mamba create -n cupyx_ng
$ mamba activate cupyx_ng
$ mamba install python==3.10 numpy scipy pytest ipython
$ mamba install "cython<3"
$ cython --version
Cython version 0.29.37
$ git clean -xdf
$ python setup.py develop

And the build log is here: https://gist.github.com/ev-br/2a28b5ca7d119eb0f3415cd50357e576

Ah OK, you should remove cuDNN from the system. cuDNN 9 is not supported yet.

Ah, that figures, thank you @leofang !
Since this is a shared system, the simplest way is to apply
$ git diff
diff --git a/install/cupy_builder/_features.py b/install/cupy_builder/_features.py
index 2d2c306bf..d44b88621 100644
--- a/install/cupy_builder/_features.py
+++ b/install/cupy_builder/_features.py
@@ -205,21 +205,21 @@ def get_features(ctx: Context) -> Dict[str, Feature]:
             'cusolver',
         ],
     }
-    CUDA_cudnn = {
-        'name': 'cudnn',
-        'file': [
-            'cupy_backends.cuda.libs.cudnn',
-            'cupyx.cudnn',
-        ],
-        'include': [
-            'cudnn.h',
-        ],
-        'libraries': [
-            'cudnn',
-        ],
-        'check_method': build.check_cudnn_version,
-        'version_method': build.get_cudnn_version,
-    }
+#    CUDA_cudnn = {
+#        'name': 'cudnn',
+#        'file': [
+#            'cupy_backends.cuda.libs.cudnn',
+#            'cupyx.cudnn',
+#        ],
+#        'include': [
+#            'cudnn.h',
+#        ],
+#        'libraries': [
+#            'cudnn',
+#        ],
+#        'check_method': build.check_cudnn_version,
+#        'version_method': build.get_cudnn_version,
+#    }
     CUDA_nccl = {
         'name': 'nccl',
         'file': [
@@ -423,7 +423,7 @@ def get_features(ctx: Context) -> Dict[str, Feature]:
         features = [
             CUDA_cuda(ctx),
             _from_dict(CUDA_cusolver, ctx),
-            _from_dict(CUDA_cudnn, ctx),
+#            _from_dict(CUDA_cudnn, ctx),
             _from_dict(CUDA_nccl, ctx),
             _from_dict(CUDA_nvtx, ctx),
             _from_dict(CUDA_cutensor, ctx),

and then CuPy builds and the OP test passes without the OP error. I wonder if there is a less invasive way to disable cuDNN detection via env variables or some such?
In an ideal world, install/cupy_builder/install_build.py could check not only the minimum but also a maximum cuDNN version, but I totally understand if it's too much effort for too little gain.


dataset, please

Dear authors, I'm really in need of the protest dataset very much, could you please send me one? Thanks a lot. my email address is<EMAIL_ADDRESS>, thanks for your great work!

Please refer to this thread
https://github.com/wondonghyeon/protest-detection-violence-estimation/issues/10#issuecomment-2011074183


dotnet-sdk: 2.2.401 -> 3.0.100

Motivation for this change
.NET Core 3.0 was released on 2019-09-23.
Things done
I was able to compile, run and test a .NET Core 3.0 application.
For one application I had a problem that dotnet searched for a non-existing binary (obj/Debug/netcoreapp3.0/project, without a .dll ending). But I don’t know if this is related to .NET Core or a fault of the application I tested.

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

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Notify maintainers
cc @kuznero

Duplicate of https://github.com/NixOS/nixpkgs/pull/69392

Ups, closing then. Thanks!


Fixes major bug

Usage of MD and one liner in Dockerfile presents a serious issue. I've fixed this by deleting everything.  You could also just keep README but as README.txt. No need to thank me. Glad to help.

LGTM

Confirmed working.

This helped make my null run. Thank you.

Nice pr, dude.

I have been dealing with this problem for weeks, looks like someone else solved it before me. Thanks.

Lgtm!

Finally! Nast bug fixed. Thank you!

LGTM!
nice fix

LGTM <3 approved


Failed to use my own .bag data for mapping

Hi, we can run the example *.bag data to build the map correctly, but there is something wrong when i am using my own *.bag data. (i use a velodyne-vlp16). Here are the details:
i use the command to record my own *.bag:
roslaunch velodyne_pointcloud VLP16_points.launch [calibration:=/home/smartcar/sunm/velodyne/VeloView-VLP-16-HiRes.yaml]
rosbag record -O indoor /velodyne_points
does this is right to save my own *.bag data ? thanks a lot
when i using my own  *.bag data , i got the error message in the rviz:

and, i got the error message ine the terminal:

and in the rviz, i only get the motionless point, it seems like it only show one frame:

it seems that there is something wrong in the time of the data recorded according to the error mssage in the rviz. But i don't know how to deal with it ? Would help me with it? thanks a lot!

Hi @sunmiaozju ,
When you played your bag, did you added --clock option? like:
rosbag play --clock ***.bag

Without this option, tf cannot handle timestamps in a bag properly.

Thank you for your answer.  But i indeed use the --clock option to output the timestamps.
I think if the equipment (i am using velodyne-vlp16) is not suitable for the code, because i find that the example bag is from velodyne HDL32e.
can we only use the velodyne-vlp16 for the code? Thanks a lot!

Hi @sunmiaozju ,
We've tested this package with VLP16 as well. But, it could be unstable compared to HLD32e, since it has a narrow field of view and provide fewer points. I think you have to move the sensor slowly.
To check if the scan matching is working, change "Fixed Frame" on rviz to "odom". You'll be able to see the odometry estimated by the matching.


Can this bot override Unbelievabot?

My friends caught on to what I was doing and added some protection bot called unbelievabot can this bypass it?

@baby-Mario if your bot has admin perms it can still ban and kick other members.


Remove version: Jackett.Jackett version 0.21.1441

404 - release deleted
Microsoft Reviewers: Open in CodeFlow

URL: https://github.com/Jackett/Jackett/releases/download/v0.21.1441/Jackett.Installer.Windows.exe
Response Error: The remote server returned an error: (404) Not Found.
(Automated message - build 918)


Add ability command

Nice to see ability info + being able to list the pokemon that can get it

Lol I already implemented this https://github.com/DanielGilchrist/poke_search/issues/57https://github.com/DanielGilchrist/poke_search/issues/57


completion_chain_complete_list error on startup

Version info (latest versions as of today):
NVIM v0.5.0-05fd64777
LuaJIT 2.0.5
completion-nvim: d9be95662fddaee96d59c1322c751b7dffcc28cf

Full error output:
Error detected while processing /Users/matt.bailey/test.vim:
line    5:
E5108: Error executing lua ...iley/.config/nvim/plugged/completion-nvim/lua/source.lua:117: Key not found: completion_chain_complete_list
Press ENTER or type command to continue

testing vimrc (as suggested):
call plug#begin('~/.config/nvim/plugged')
    Plug 'neovim/nvim-lsp'
    Plug 'haorenW1025/completion-nvim'
call plug#end()
lua require'nvim_lsp'.sumneko_lua.setup{on_attach=require'completion'.on_attach}
au Filetype lua setl omnifunc=v:lua.vim.lsp.omnifunc
" Use <Tab> and <S-Tab> to navigate through popup menu
inoremap <expr> <Tab>   pumvisible() ? "\<C-n>" : "\<Tab>"
inoremap <expr> <S-Tab> pumvisible() ? "\<C-p>" : "\<S-Tab>"

" Set completeopt to have a better completion experience
set completeopt=menuone,noinsert,noselect

It was caused by something I updated today... Should be fixed now, please update and check!

excellent, works great now, thanks!


URLs in Code cells get mangled

Original issue over in fastpages https://github.com/fastai/fastpages/issues/215
Take a look at this notebook and scroll down to the NOTE.
https://tylerleonhardt.github.io/blog/jupyter/powershell/pswordcloud/2020/03/16/Word-Clouds.html
I'm using a magic command #!markdown to render markdown instead of a normal code block so I can show the markdown code behind it.
Unfortunately, for some reason fastpages mangles the path of my svg in the code sample:
![.NET Interactive codebase word cloud](/blog/images/copied_from_nb/dotnet-interactive.svg)

instead of
![.NET Interactive codebase word cloud](dotnet-interactive.svg)

which is what it is in source:
https://github.com/TylerLeonhardt/blog/blob/56e0f224d03866fd5118131ab41bcb8effb81453/_notebooks/2020-03-16-Word-Clouds.ipynb#L110
Expected Behavior
My url isn't touched.
![.NET Interactive codebase word cloud](dotnet-interactive.svg)

Actual Behavior
My url is mangled.
![.NET Interactive codebase word cloud](/blog/images/copied_from_nb/dotnet-interactive.svg)

Proposed solution
Don't expand image tags in Code blocks?
More context
so #!markdown is exposed by .NET Interactive:
https://github.com/dotnet/interactive
Which is a new hybrid-language kernel that supports the ability to call upon languages within different cells using magic commands
It supports:
C#, F#, PowerShell, JavaScript, HTML, Markdown
If the default language is PowerShell, for example, and I want to have a cell use Markdown, I can use the #!markdown magic command
Now I can agree that a #!markdown magic command is kinda silly because.. well... that's what a Markdown cell is for...
But the difference is that you see the markdown in addition to the output.
I guess It'd be the equivalent to a Markdown cell of:
## my markdown code

My markdown code

I've also been told to @jph00 by @hamelsmu because you might be interested in PowerShell notebooks! 😅
Let me know if there's anything else I can help with!

I can confirm that this happens.  I was able to reproduce this issue.
Another way of explaining it is if you have markdown syntax for images in a code cell nbdev will change the path as if though its a markdown cell.,
Granted, I have never tried to put markdown in a code cell before, especially in a Jupyter Notebook, but @TylerLeonhardt has a legit use case where needs to do this for PowerShell Notebooks.

Added a test for markdown cells (it was forgotten by mistake).

Thanks @sgugger! @hamelsmu, how will I get this fix in fastpages?

You cannot yet - I had to pin the version because of another nbdev bug which will prevent you from enjoying this fix.
I’m going to help test that and then Sylvian will cut another release.
TLDR; you can’t yet but I’ll comment on this thread when it’s all ready and tested.
Thanks everyone for the coordination

Related issue is  https://github.com/fastai/nbdev/issues/105.

@TylerLeonhardt this should be ready now, you can proceed by just re-generating your pages and everything will just work.  I don't even think you have to upgrade anything


Number Word Conversion fails on numbers over 16

Steps to reproduce:

Map a stroke to {:number_word_conversion:1:2}
Stroke "15" followed by the above stroke --> result is "fifteen" as expected
Stroke "17" followed by the above stroke --> result is "eighteen" (incorrect)
Stroke "19" followed by the above stroke --> result is an error popup

fixed in version 1.1.0
that was such a silly mistake lol, I forgot to define "seventeen" so 19 was out range of the array


Wrong content

Description on this page does not match the options you are presented with in the UI!

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

ID: e3eaf13d-c0f2-5f45-8fe7-a647d3e0da40
Version Independent ID: a644e742-fb10-6c67-dbf0-1c3469234e0f
Content: Connect to Box with Migration Manager - Migrate to Microsoft 365
Content Source: migration/mm-box-step1-connect.md
Service: sharepoint-online
Sub-service: sharepoint-migration
GitHub Login: @JoanneHendrickson
Microsoft Alias: jhendr

Hello @nordtorp the document has now been updated.
Thanks for your feedback!


Updated Azure Storage Driver with Latest SDK

Updated registry/storage/driver/azure/azure.go with the latested SDK (Azure/azure-storage-blob-go).
Resolves #3028

Please sign your commits following these rules:
https://github.com/moby/moby/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "new_sdk" git@github.com:shizhMSFT/distribution.git somewhere
$ cd somewhere
$ git rebase -i HEAD~842354171776
editor opens
change each 'pick' to 'edit'
save the file and quit
$ git commit --amend -s --no-edit
$ git rebase --continue # and repeat the amend for each commit
$ git push -f

Amending updates the existing PR. You DO NOT need to open a new one.

@shizhMSFT it looks like they're sticking with the azure-sdk-for-go pkg, see the azure-storage-blob-go repo readme:

If you would like to access our latest Go SDK, please refer to the new preview azblob package here. If you would like more information on Azure's burgeoning effort to coordinate the development of the SDKs across services, of which this change is a part, please refer to this article.

There is a PR that updates Azure integration: https://github.com/distribution/distribution/pull/3839

Closing this PR as it is outdated and is succeeded by #3839


x/build/dashboard, x/build/app/appengine: add ability to mark builders with a known issue

Currently, all builder failures are displayed the same way on the build.golang.org dashboard, with a red "fail" text linking to the failure log:

Due to new OS versions, new ports, or new features, there are times when a builder is just being added. It is infeasible to guarantee a builder will report useful results as soon as it is added. Trying to make that the case would cause additional overhead and stress, without a good reason.
We can add a field to the dashboard.BuildConfig struct to mark builders as having a known issue and display such builders on the build.golang.org dashboard in a way that makes it easier to see that it's not a new regression that needs to be investigated anew (by many people looking at build.golang.org).
/cc @toothrot @cagedmantis @andybons @bcmills @danscales

Here's what I've prototyped locally (note the linux-amd64-staticlockranking builder column displayed in gray):

I realize that copying the issue number out of a tooltip isn't easy. I'm open to a suggestion how to make it better with the constraint that it shouldn't take up additional space and keeping in mind it doesn't need to be done often.

A test version is deployed and can temporarily be seen at https://20200406t174434-dot-build-dot-golang-org.appspot.com. It looks like this:

I realize that copying the issue number out of a tooltip isn't easy. I'm open to a suggestion how to make it better with the constraint that it shouldn't take up additional space and keeping in mind it doesn't need to be done often.

The builder name at the top of the column isn't currently hyperlinked. Perhaps add a hyperlink from the header to the bug?


[cli] Do the script srcs need to be changed in polymer-3.x element template?

After creating a polymer 3.0 element from polymer init, using polymer-cli version 1.7.0-pre.14, i have to change the script srcs in demo/index.html from
<script<EMAIL_ADDRESS><script type="module"<EMAIL_ADDRESS><script type="module"<EMAIL_ADDRESS>
to
<script<EMAIL_ADDRESS><script type="module"<EMAIL_ADDRESS><script type="module"<EMAIL_ADDRESS>
to get the demo to work.

I converted the URLs in that template to work with /demo/ rather than /components/element-name/demo/ because this is what we eventually want all of the URLs in demo / test HTML files* to use - the demo should work if you go to /demo/. Are there any docs pages or tutorials that use the element template from cli and have polymer serve --open or tell the user to go to the /components/... path?
* specifically, HTML files that aren't meant to be imported

These were reverted in https://github.com/Polymer/tools/pull/366.


Added a new style to the player control

This PR is removing the core fuctionality of fetching data from the api. I'm closing it now.


WIP until #20: Redesign Updates

The relevant changes regarding this branch.
Should be merged after #20
Showcase

Sign Up
User

This looks amazing!
I'll happily review this once I'm off of work, but this is miles of improvement from what was existing!
Thanks for contributing!


Updated Controllers import to adhere to extended coding style guide

Updated the controllers namespacing import to adhere to PHP FIG Extended Coding Style Guide

Related to #302.

This gives PHPCS errors for all of the changes. I've had a quick look but I can't find support for the FIG standard to set in the phpcs.xml file.


Faster Parsing

Hey @davedufresne !
We managed to build a working parser for something like ledger-cli. The 5000-line sample file that we tried to parse (naively) took a massive amount of time to parse (the first iteration even took 13 minutes). We got it down to a few minutes.
The popFirst() on strings is really expensive, as it reallocates a new copy of the string. We managed to speed it up a little bit by using a CharacterView, but still, this mutates the underlying _StringCore type.
As Stream only needs the ArrayLiteralConvertible and the popFirst(), we implemented a new struct that doesn't copy at all. It only changes the "pointer" to the first element in the array. We also tried storing String.CharacterView in this struct, but that was a lot slower.
struct ImmutableCharacters: Stream {
    var characters: [Character]
    var start: Int = 0

    init(string: String) {
        characters = Array(string.characters)
    }

    init(arrayLiteral elements: Character...) {
        characters = elements
    }

    mutating func popFirst() -> Character? {
        guard start < characters.count else { return nil }
        let oldStart = start
        start += 1
        return characters[oldStart]
    }
}

This helped a lot for speed. Our file now parses in 2 seconds. This is still quite slow (we'd like to be able to parse it in milliseconds).
When running this in Instruments, we noticed at least half a second was spent retaining/releasing things. Almost certainly, the characters array. If could work on something like an UnsafeBufferPointer, there would be no need for retain or release. However, this is hard to make work with both the Parsec.string parser, and also the ArrayLiteralConvertible that Stream inherits from.
Have you thought about these issues, and do you have any more ideas for how to make this fast? We're happy to help out. Maybe we could integrate the ImmutableCharacters struct already? It's a drop-in replacement.

Hey Chris,
Many thanks for you feedback, it's really appreciated!
The ImmutableCharacters struct is basically an iterator, which is a good idea. We could generalize your concept by using an iterator provided by a type implementing the Collection protocol. I quickly looked at the code, so I'm not sure about all the implications, but here is what could be done:

Get away with the Stream protocol and replace it with the Collection Protocol. So the new type constraint for the Parsec StreamType associated type would be like that: associatedtype StreamType: Collection.
Instead of passing around the whole collection, only use the iterator (input.makeIterator()).
input.popFirst() would be replaced by input.next().

The advantage of this solution is that the code remains generic.
Tell me what you think. I'll be able to look into this issue a bit further this weekend.

That sounds like a good plan. Does it need to be a collection, or could it be just an Iterator? We could just "destructively" consume the iterator, right? Or do we need value semantics and repeated access?

The input cannot be destructively consumed because of the attempt parser that has to backtrack on failure. That's why I suggested the Collection protocol, it's multi-pass.

Of course =). BTW, if you want to chat about this stuff on Skype or via im
sometime, let me know. It should be easy to find me ;).
On Thu, Jun 30, 2016 at 1:59 PM, David Dufresne<EMAIL_ADDRESS>wrote:

The input cannot be destructively consumed because of the attempt parser
that has to backtrack on failure. That's why I suggested the Collection
protocol, it's multi-pass.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/davedufresne/SwiftParsec/issues/6#issuecomment-229637955,
or mute the thread
https://github.com/notifications/unsubscribe/AAAVBhDTUq4Dd6cGgeWFv9RamPYI4OsZks5qQ6-FgaJpZM4JAN9f
.

--
Chris Eidhof

I fixed the problem. Now the collection being parsed is traversed using an iterator. So the collection is not mutated during the parsing. It didn't change the API, the changes are internal only. They are in the 2.0-dev branch. Could you tell me how much it improved the speed. After we could check if there is more improvements to make.

I haven't checked out the branch yet, will do that in a bit. Some things I've learned while trying to optimize our parser over the weekend (I started with a test that took 2.5 seconds to run):
When using the ImmutableCharacters struct, I managed to get a big speedup making the tokens method more generic. Instead of it taking a StreamType, it can now take any Stream-conforming type, as long as the elements match. That saves a lot of conversions. The string function I use converts the String into a character array first before using the built-in .string method. Now the test took 1.8 seconds.
I extended the Stream protocol to include a first computed property, which peeks (instead of mutating the input). I then added a combinator onlyIf which only succeeds if the first element matches a condition. This saves us from building/destroying results, and gives us quite a speedup (might ba a quite specific use-case). It allowed us to remove almost all attempts. (1.5 seconds)
public extension GenericParser where StreamType.Element: Equatable {
    public func onlyIf(peek check: (StreamType.Element) -> Bool) -> GenericParser<StreamType, UserState, Result> {

Finally, I changed the implementation of satisfy to return anyToken.onlyIf(peek: predicate) and got another decent speedup (tests take 1.2 seconds).
I'll have a look at your changes later on!


Is there any method like torch.diag that can return the diagonal of a given tensor? Thanks in advance.

背景

需求描述

Hi, you can use megengine.functional.nn.eye together with element-wise operations to get the diagonal of a given tensor.
https://github.com/MegEngine/MegEngine/blob/master/python_module/megengine/functional/nn.py#L709

Thanks for your response.

@lqy-megvii Hi, how to achieve this specifically? The link is 404.

OK, use F.cond_take(F.eye(X.shape[0]).astype("bool"), X). It would be nicer if there is a diag function.

OK, use F.cond_take(F.eye(X.shape[0]).astype("bool"), X). It would be nicer if there is a diag function.

Hey, @hiyyg ~ Could you please open a new issue to let me know there are more requests on the diag function?

https://github.com/MegEngine/MegEngine/blob/master/python_module/megengine/functional/nn.py#L709

This file was moved to https://github.com/MegEngine/MegEngine/blob/master/imperative/python/megengine/functional/nn.py
But the best way to find API support is by reading our official doc or the latest source code.

Sure


MarkerWithLabel : problem of overlapping labels when two markers are in the same position

please, Looks this attach file.

Browser / Operating System:
all

*********************************************************
Tip: Star this issue (next to title) to receive notifications of status
changes against this issue, also used as a gauge for how many people are
interested in seeing it resolved.
*********************************************************

Original issue reported on code.google.com by<EMAIL_ADDRESS>on 16 Jul 2010 at 5:08
Attachments:

markerlabel.png

I updated the fiddle referenced above:
http://jsfiddle.net/5zxqo3fs/22/
Changes:

Use currently active resource for markerwithlabel.js;
Change labelInBackground value to 'false'.

It turned out that my local markerwithlabel.js has some extra code with regards to event handling which was breaking the zIndex order as it was not set on the new eventDiv.
This was the code that was breaking the zIndex directive - I haven't corrected this wrapper code as I have no need for it at this moment:
function MarkerLabel_(marker, crossURL, handCursorURL) {
  this.marker_ = marker;
  this.handCursorURL_ = marker.handCursorURL;

  this.labelDiv_ = document.createElement("div");
  this.labelDiv_.style.cssText = "position: absolute; overflow: hidden;";

  // Set up the DIV for handling mouse events in the label. This DIV forms a transparent veil
  // in the "overlayMouseTarget" pane, a veil that covers just the label. This is done so that
  // events can be captured even if the label is in the shadow of a google.maps.InfoWindow.
  // Code is included here to ensure the veil is always exactly the same size as the label.
  this.eventDiv_ = document.createElement("div");
  this.eventDiv_.style.cssText = this.labelDiv_.style.cssText;

  // This is needed for proper behavior on MSIE:
  this.eventDiv_.setAttribute("onselectstart", "return false;");
  this.eventDiv_.setAttribute("ondragstart", "return false;");

  // Get the DIV for the "X" to be displayed when the marker is raised.
  this.crossDiv_ = MarkerLabel_.getSharedCross(crossURL);

}


change_upstream_proxy_server() not working with Error method from HttpEvents

Problem Description
When I try to use flow.live.change_upstream_proxy_server(address) to switch the upstream Proxy in Error() method from HttpEvents, the upstream proxy stay the same and does not change.
Steps to reproduce the behavior:

launch Mitm with an upstream and script:
mitmdump --mode upstream:<IP_ADDRESS>:34084 --ssl-insecure -s scripts/watcher.py
wait for upstream proxy to fail
let watcher.py renew the upstream proxy

Current result:

At this point we assume that the upstream proxy is now changed to <IP_ADDRESS>:8080, but when we renew a request, we can see in the error message that the proxy is still the same (<IP_ADDRESS>:34084) instead of <IP_ADDRESS>:8080 :

Watcher.py
from mitmproxy import http
from mitmproxy import ctx

import requests
import json
import typing

#***** Some fetching to get new proxy from my API*****

def getNewProxy() -> typing.Tuple[str, int]:
    id = str(getRandID())
    params = { 'id': 'eq.' + id, 'select': 'proxy'}
    response = str(requests.get(url = url, params = params).json()[0]['proxy'])[7:].split(':')
    proxIP = (response[0], int(response[1]))
    return (proxIP)

class Events:

    def error(self, flow: http.HTTPFlow):
        ctx.log.info(str(flow.server_conn.address))
        pAddr = getNewProxy()
        ctx.log.info("Switching upstream proxy to: " + pAddr[0] + ":" + str(pAddr[1]))
        flow.live.change_upstream_proxy_server(pAddr)

addons = [
    Events()
]

System Information
mitmproxy --version:
$ mitmdump --version
Mitmproxy: 5.2
Python:    3.7.3
OpenSSL:   OpenSSL 1.1.1g  21 Apr 2020
Platform:  Linux-4.19.0-9-amd64-x86_64-with-debian-10.4

Thanks for your help, really annoyed by this problem right now :grimacing:

Is it the same problem as this one #3628 ?

Yes, mitproxy itself does not support retrying requests at the moment. Thanks for the detailed report though!


create a noop preset

this preset wouldn't make any changes to the input, that way we can implement style changes that are less obtrusive and don't need to reset all the properties (just inherit from the noop preset and override the needed options).
this will only be possible after we add support for -1 to the config options.
PS: issue #1 and #84 are blocking this.

Would creating a default preset with options to set to -1 be a good start here?

that wouldn't help.. we are planning to kill all the presets besides the default (convert them into plugins). right now even if all settings are -1 it will still change the code.

I'm not going to work on this.. if you don't want the code to change use a different tool, maybe echo or tee :stuck_out_tongue_winking_eye:

Thats fair given the work involved :)

for future reference:
we have a bunch of calls to limit that passes a number as second argument - these changes will always happen, no matter what settings you pass. Most of the cases are actually things that you want to happen (eg. always enforce a single space after the new keyword), but in some cases they are hardcoded just because we didn't have a name for that option or didn't think anyone would need to configure that...
There is also the indent.sanitize call (which will remove the original indentation) - we always re-indent the whole file, but this should be easy to ignore with a flag...


fetch-and-ingest-branch: Send Slack notications to test channel

This change was motivated by the unintentional bug introduced in https://github.com/nextstrain/mpox/pull/222 that would only be triggered by using Slack notifications. This allows to test branches and send notifications to the testing channel.
As part of this change, I've added an organization level variable TEST_SLACK_CHANNEL that points our #scratch channel for testing Slack notifications.
Checklist

[ ] Checks pass
[x] Test run: https://github.com/nextstrain/mpox/actions/runs/6883650646 -> successful Slack notifications in #scratch

Nice, thanks! I had to look at docs to find where one sets that variable, it's here for reference: https://github.com/organizations/nextstrain/settings/variables/actions


Fix test compile classpath for kafka-producer

suro-pull-requests #249 FAILURE
Looks like there's a problem with this pull request

NetflixOSS » suro » suro-pull-requests #81 ABORTED


Start refactoring CI playbooks

Split CI-playbooks

ci-provision.yml is now the run-everything playbook, and is made up of individual playbooks named after groups, which can be run independently. (Remember a host can be a member of multiple groups, so this allows you to manage one piece of "functionality" of a node)

You can run ci-provision.yml with --limit to provision a new node, but if you are doing any hardware configuration it's a good idea to reboot in between. E.g. If you are reconfiguring the network run ci-initial.yml first, reboot, then run your other playbook, or just run the parent ci-provision.yml since Ansible is idempotent.

Note: I've started doing something similar with the IDR playbooks, but it made more sense to sort out ci-docker first. Also once everyone's happy with a workflow I'll add some docs (basically the above paragraphs).
Tidied up some vars:

There's no need to force docker_basefs docker_lvfilesystem to be defined when they could be set as defaults in the role.
Added root_filesystem to idr playbooks for consistency.
Made network/network_ifaces var optional, this means you can run ci-initial.yml for any node and if you haven't configured any sepcial networking the playbook will still run.

Local merge worked. Merging.


[SPARK-35316][SQL] UnwrapCastInBinaryComparison support In/InSet predicate

What changes were proposed in this pull request?
This pr add in/inset predicate support for UnwrapCastInBinaryComparison.
Current implement doesn't pushdown filters for In/InSet which contains Cast.
For instance:
spark.range(50).selectExpr("cast(id as int) as id").write.mode("overwrite").parquet("/tmp/parquet/t1")
spark.read.parquet("/tmp/parquet/t1").where("id in (1L, 2L, 4L)").explain

before this pr:
== Physical Plan ==
*(1) Filter cast(id#5 as bigint) IN (1,2,4)
+- *(1) ColumnarToRow
   +- FileScan parquet [id#5] Batched: true, DataFilters: [cast(id#5 as bigint) IN (1,2,4)], Format: Parquet, Location: InMemoryFileIndex(1 paths)[file:/tmp/parquet/t1], PartitionFilters: [], PushedFilters: [], ReadSchema: struct<id:int>

after this pr:
== Physical Plan ==
*(1) Filter id#95 IN (1,2,4)
+- *(1) ColumnarToRow
   +- FileScan parquet [id#95] Batched: true, DataFilters: [id#95 IN (1,2,4)], Format: Parquet, Location: InMemoryFileIndex(1 paths)[file:/tmp/parquet/t1], PartitionFilters: [], PushedFilters: [In(id, [1,2,4])], ReadSchema: struct<id:int>

Does this PR introduce any user-facing change?

No.
How was this patch tested?

New test.

Thanks for the review. @sunchao

@sunchao @cloud-fan Made some changes and add a new test case for the null value. Please take another look. Thanks!

ok to test

Test build #139229 has started for PR 32488 at commit ea0ba38.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/43751/

Kubernetes integration test status success
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/43751/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/43751/

Test build #139229 has finished for PR 32488 at commit ea0ba38.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/139229/

thanks, merging to master!

Hi @cfmcgrady , can you leave a comment in the JIRA so that I can assign it to you?

Thanks a lot. @cloud-fan

Hi @cfmcgrady , can you leave a comment in the JIRA so that I can assign it to you?

Done.

Hi @cfmcgrady this check
https://github.com/apache/spark/blob/fbf53dee37129a493a4e5d5a007625b35f44fbda/sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/optimizer/UnwrapCastInBinaryComparison.scala#L162
can fail with the following case
CREATE TABLE tbl (d decimal(33, 27)) USING PARQUET
SELECT d FROM tbl WHERE d NOT IN (d + 1)

Here in.list can be a CheckOverflow expression:
cast(d#240 as decimal(34,27)) IN (CheckOverflow((promote_precision(cast(d#240 as decimal(34,27))) + 1.000000000000000000000000000), DecimalType(34,27), true))

cc @cloud-fan

@allisonwang-db good catch! can you open a JIRA ticket to track this bug?

@allisonwang-db good catch! can you open a JIRA ticket to track this bug?

Open a JIRA ticket SPARK-36130 and working on this.


How to set size in class emojionearea-wrapper?

How to set size in class emojionearea-wrapper?

Change this values:
https://github.com/mervick/emojionearea/blob/e9f3edd93b468ab690b6104dcd43ab2e42afcfca/scss/_variables.scss#L18-L19


Error when onboarding in PPE

Yoga and I are testing the data aggregation model implementation and we saw this error.  When we de-selected the field to identify existing SDKs, we did not see the error.

We need to revisit all the logic for this SDKs....

Same issues as https://github.com/Azure/azure-sdk-tools/issues/6961
Clossing as dup


bugfix(): fixing rest client unit test

Fixing the callMonoService_givenServerError_expectedApplicationClientException to throw the ApplicationClientException instead of ApplicationServerException

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Wendy Hu seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Allow selling CPMM binary position from bet table

For CPMM, it doesn't really make sense to but a sell button on every individual buy bet, so instead I put it in next to the profit.
Individual market:

Your bets in profile:

Upon clicking, it opens a modal

This is a good change that people want, however:

Sell button is mostly offscreen on mobile.
Sell button still appears after you've sold all your shares. Clicking the sell button again in this case leads to an infinite loop that freezes the tab.


HTML/CSS & JavaScript capstone project - Conference page

Description
In this capstone project, you are going to build is based on an online website for a conference. We provide some design guidelines for you to create the website, but you must personalize the content, i.e., instead of a conference, you can build a website for a concert or for a web development course. It's very important that you personalize your project so that you have something unique in your portfolio to share with potential employers during job searching.
Project Requirements

You should personalize the content of your page. Choose a topic that is different than the one in the original design.
You should follow these design guidelines, including:

Colors.
Typography: font face, size and weight.
Layout: composition and space between elements.

The pages should look almost identical to the original design. Small adjustments like text or image changes are acceptable.
You can use a CSS framework (for example Bootstrap) for styling, if you want to.
You should build only these 2 pages:

The home page.
The about page.

Each of these pages should have versions for 2 different screen sizes:

Mobile: up to 768px wide.
Desktop: 768px or wider.

Interactions

Links

The home page should have a link in the menu to the about page.
The logo in the header links to the home page.

Mobile menu

When the user clicks (or taps) the hamburger button on the header, the mobile menu appears over the page.
There are no guidelines for the mobile menu in the docs, but you should implement it so it is consistent with the design (colors, typography, spacings, etc.).
The mobile menu should have a close (X) button that closes the menu.

Dynamic page

The section "Featured speakers" should be created dynamically in JavaScript.
You should use a JavaScript variable with the data about the speakers and use it when the page loads to create the HTML for this section dynamically.

Project Documentation
For this project, we are also required to record a video presenting our project. Here is the link to the video I recorded: https://www.loom.com/share/9b5dd01eba6341259a7b719b66aa6530

I have corrected the Featured artist design and added the checkerboard behind as requested.
I've also improved the consistency between the program boxes.


Refactor refreshes in Host#scan_from_queue

Having an OpenStack-specific check in the list of refreshes that happen during scan_from_queue was really bothering me.
Refactoring to allow Host subclasses to append their own refreshes during scan_from_queue.
(This will impact #3130 ... so if that gets merged first, I can rebase this one).
/cc @Fryguy, @Ladas

nice refactoring :+1:

@matthewd said:

This method has fallen behind

Thanks!  Fixed.
It suggests it works with openstack, but I don't see anything that suggests it would work. (not supports or similar method calls)
Not sure if moving this code out of here and into vmware repo makes sense,
or if moving this code into a smartstate module (or repo) would make sense.
Or if this would help us in the short term and is even a priority.

According to the Capabilities Matrix: vmware, rhv/ovirt, openstack, aws and azure.


New extra combinator: generalised 'readMaybe'

readMaybe is implemented like this:
readMaybe :: Read a => String -> Maybe a
readMaybe s = case readEither s of
                Left _  -> Nothing
                Right a -> Just a

There's a lot of other types that it would be useful to generalize this to. Here's two ideas I've had:
readFail :: (MonadFail f, Read a) => String -> f a
readFail s = case readEither s of
                Left e  -> fail e
                Right a -> return a

readAlt :: (Alternative f, Read a) => String -> f a
readAlt s = case readEither s of
                Left _  -> empty
                Right a -> pure a

Both of those are the same as readMaybe when f ~ Maybe. The first is useful for custom error monads to preserve whether the problem was "no parse" or "ambiguous parse". The second is useful for MaybeT and lots of other things that have some sort of failure state.

@josephcsible Thanks for the suggestion! I can see how more polymorphic readMaybe can be useful. I would prefer not to change the type of readMaybe to have fewer surprises for the relude users.
I think that both readFail and readAlt can be useful. However, it's not clear which one to choose. So instead of hardcoding implementation of parsing function, I propose to introduce more useful combinators that deal with Either a b and Maybe a.  We only need to decide which ones to add and under what names. Currently, I can say without a doubt that reexporting liftEither from mtl can be done.

In relude we want to be more beginner-friendly and have fewer surprises for users. Changing the type of one of the most common functions would be against our goals. I personally never needed a more polymorphic readMaybe, so I assume that the benefits of this change are low, but the confusion caused by using more abstractions can be noticeable. Moreover, there're multiple competitive choices without a clear winner. I don't think the community has settled on some of the options.
However, such combinator still can be added to some Extra. module. But I would like to avoid populating relude with multiple rarely-used functions, so let's gather more opinions on this issue first before introducing something, we are going to suggest and going to maintain forever.

To clarify, I definitely don't want a new function called readMaybe with a different type. I definitely agree if we add one, it should have a different name.


Can't get ipAddress field from azurenative.containerinstance.ContainerGroup

When I try to get ipAddress (ipAddress = containerGroup.ipAddress.ip) from azurenative.containerinstance.ContainerGroup the Error shows up about deserializing an option.
The error disappears when I comment on the line ipAddress = containerGroup.ipAddress.ip.
Dependencies:
//> using scala "3.3.1"
//> using options -Werror -Wunused:all -Wvalue-discard -Wnonunit-statement
//> using plugin "org.virtuslab::besom-compiler-plugin:0.2.3-SNAPSHOT"
//> using dep "org.virtuslab::besom-core:0.2.3-SNAPSHOT"
//> using dep "org.virtuslab::besom-azure-native:2.34.0-core.0.2-SNAPSHOT"

Main class:
import besom.*
import besom.api.azurenative

@main def main = Pulumi.run {
  val resourceGroup = azurenative.resources.ResourceGroup(
    name = s"test-resource-group",
    azurenative.resources.ResourceGroupArgs(location = "East US")
  )
  val containerGroup = azurenative.containerinstance.ContainerGroup(
    name = s"test-container-group",
    azurenative.containerinstance.ContainerGroupArgs(
      resourceGroupName = resourceGroup.name,
      location = resourceGroup.location,
      osType = azurenative.containerinstance.enums.OperatingSystemTypes.Linux,
      containers = List(
        azurenative.containerinstance.inputs.ContainerArgs(
          name = "test",
          image = "nginx",
          resources = azurenative.containerinstance.inputs.ResourceRequirementsArgs(
            requests = azurenative.containerinstance.inputs.ResourceRequestsArgs(
              cpu = 1.0,
              memoryInGB = 1.5
            )
          ),
          ports = List(
            azurenative.containerinstance.inputs.ContainerPortArgs(
              port = 80
            )
          )
        )
      ),
      ipAddress = azurenative.containerinstance.inputs.IpAddressArgs(
        `type` = azurenative.containerinstance.enums.ContainerGroupIpAddressType.Public,
        ports = List(
          azurenative.containerinstance.inputs.PortArgs(
            port = 80,
            protocol = azurenative.containerinstance.enums.ContainerGroupNetworkProtocol.TCP
          )
        )
      )
    )
  )

  Stack.exports(
    ipAddress = containerGroup.ipAddress.ip
  )
}

Stack trace:
Diagnostics:
  pulumi:pulumi:Stack (azure-aci-bootzooka-dev):
    Compiling project (Scala 3.3.1, JVM (21))
    Compiled project (Scala 3.3.1, JVM (21))
    Exception in thread "main" besom.internal.AggregatedDecodingError: Decoding Errors [2]:
      bootzooka-container-group[azure-native:containerinstance:ContainerGroup].ipAddress: Encountered an error when deserializing an option
      bootzooka-container-group[azure-native:containerinstance:ContainerGroup].ipAddress: Encountered an error when deserializing an option
    (with aggregate stack trace)
        at besom.internal.AggregatedDecodingError$.apply(codecs.scala:99)
        at besom.internal.ResourceDecoder$.besom$internal$ResourceDecoder$$anon$1$$_$$anonfun$14$$anonfun$1(ResourceDecoder.scala:111)
        at besom.internal.Result.flatMap$$anonfun$1(Result.scala:164)
        at besom.internal.Result.runM$$anonfun$7(Result.scala:269)
        at besom.internal.Runtime.flatMapBothM$$anonfun$1$$anonfun$1(Result.scala:118)
        at besom.internal.FutureRuntime.flatMapBoth$$anonfun$1(Result.scala:372)
        at scala.concurrent.impl.Promise$Transformation.run(Promise.scala:477)
        at java.base/java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1423)
        at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:387)
        at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1312)
        at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1843)
        at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1808)
        at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:188)
    Caused by: besom.internal.DecodingError: [bootzooka-container-group[azure-native:containerinstance:ContainerGroup].ipAddress] bootzooka-container-group[azure-native:containerinstance:ContainerGroup].ipAddress: Encountered an error when deserializing an option
        at besom.internal.DecodingError$.apply(codecs.scala:80)
        at besom.internal.Decoder$.besom$internal$Decoder$$anon$7$$_$decode$$anonfun$3$$anonfun$3(codecs.scala:250)
        at besom.util.NonEmptyVector.map(Validated.scala:167)
        at besom.util.Validated.lmap(Validated.scala:47)
        at besom.util.Validated$.lmap$$anonfun$1(Validated.scala:137)
        at besom.internal.Result.map$$anonfun$1(Result.scala:201)
        ... 11 more
        Suppressed: besom.internal.DecodingError: [bootzooka-container-group[azure-native:containerinstance:ContainerGroup].ipAddress] bootzooka-container-group[azure-native:containerinstance:ContainerGroup].ipAddress: Encountered an error when deserializing an option
                at besom.internal.DecodingError$.apply(codecs.scala:80)
                at besom.internal.Decoder$.besom$internal$Decoder$$anon$7$$_$decode$$anonfun$3$$anonfun$3(codecs.scala:250)
                at scala.collection.immutable.Vector1.map(Vector.scala:1911)
                at scala.collection.immutable.Vector1.map(Vector.scala:377)
                ... 15 more
        Caused by: besom.internal.DecodingError: [bootzooka-container-group[azure-native:containerinstance:ContainerGroup].ipAddress.fqdn] bootzooka-container-group[azure-native:containerinstance:ContainerGroup].ipAddress.fqdn: Encountered an error - possible secret - Known(Set(),false,Some(Value(NullValue(NULL_VALUE),UnknownFieldSet(Map()))))
                at besom.internal.DecodingError$.apply(codecs.scala:80)
                at besom.internal.Decoder.decode$$anonfun$1$$anonfun$2(codecs.scala:132)
                at besom.util.NonEmptyVector.map(Validated.scala:167)
                at besom.util.Validated.lmap(Validated.scala:47)
                at besom.internal.Decoder.decode$$anonfun$1(codecs.scala:134)
                at besom.util.Validated$.flatMap$$anonfun$1(Validated.scala:112)
                ... 11 more
        Caused by: besom.internal.DecodingError: [bootzooka-container-group[azure-native:containerinstance:ContainerGroup].ipAddress.fqdn] bootzooka-container-group[azure-native:containerinstance:ContainerGroup].ipAddress.fqdn: Expected a string, got: 'NullValue(NULL_VALUE)'
                at besom.internal.DecodingError$.apply(codecs.scala:80)
                at besom.internal.Decoder$stringDecoder$.mapping(codecs.scala:202)
                at besom.internal.Decoder.decode$$anonfun$1$$anonfun$1(codecs.scala:128)
                at besom.internal.OutputData.traverseValidated(OutputData.scala:93)
                at besom.internal.Decoder.decode$$anonfun$1(codecs.scala:128)
                ... 12 more
    Caused by: besom.internal.DecodingError: [bootzooka-container-group[azure-native:containerinstance:ContainerGroup].ipAddress.autoGeneratedDomainNameLabelScope] bootzooka-container-group[azure-native:containerinstance:ContainerGroup].ipAddress.autoGeneratedDomainNameLabelScope: Encountered an error - possible secret - Known(Set(),false,Some(Value(NullValue(NULL_VALUE),UnknownFieldSet(Map()))))
        at besom.internal.DecodingError$.apply(codecs.scala:80)
        at besom.internal.Decoder.decode$$anonfun$1$$anonfun$2(codecs.scala:132)
        at besom.util.NonEmptyVector.map(Validated.scala:167)
        at besom.util.Validated.lmap(Validated.scala:47)
        at besom.internal.Decoder.decode$$anonfun$1(codecs.scala:134)
        at besom.util.Validated$.flatMap$$anonfun$1(Validated.scala:112)
        ... 11 more
    Caused by: besom.internal.DecodingError: [bootzooka-container-group[azure-native:containerinstance:ContainerGroup].ipAddress.autoGeneratedDomainNameLabelScope] bootzooka-container-group[azure-native:containerinstance:ContainerGroup].ipAddress.autoGeneratedDomainNameLabelScope: Expected a string, got: 'NullValue(NULL_VALUE)'
        at besom.internal.DecodingError$.apply(codecs.scala:80)
        at besom.internal.Decoder$stringDecoder$.mapping(codecs.scala:202)
        at besom.internal.Decoder.decode$$anonfun$1$$anonfun$1(codecs.scala:128)
        at besom.internal.OutputData.traverseValidated(OutputData.scala:93)
        at besom.internal.Decoder.decode$$anonfun$1(codecs.scala:128)
        ... 12 more

    2024.04.03 07:29:42:289 main  ERROR besom.internal.BesomModule.run:69
        besom.internal.AggregatedDecodingError: Decoding Errors [2]:
          bootzooka-container-group[azure-native:containerinstance:ContainerGroup].ipAddress: Encountered an error when deserializing an option
          bootzooka-container-group[azure-native:containerinstance:ContainerGroup].ipAddress: Encountered an error when deserializing an option
        (with aggregate stack trace)
                at besom.internal.AggregatedDecodingError$.apply(codecs.scala:99)
                at besom.internal.ResourceDecoder$.besom$internal$ResourceDecoder$$anon$1$$_$$anonfun$14$$anonfun$1(ResourceDecoder.scala:111)
                at besom.internal.Result.flatMap$$anonfun$1(Result.scala:164)
                at besom.internal.Result.runM$$anonfun$7(Result.scala:269)
                at besom.internal.Runtime.flatMapBothM$$anonfun$1$$anonfun$1(Result.scala:118)
                at besom.internal.FutureRuntime.flatMapBoth$$anonfun$1(Result.scala:372)
                at scala.concurrent.impl.Promise$Transformation.run(Promise.scala:477)
                at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1423)
                at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:387)
                at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1312)
                at java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1843)
                at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1808)
                at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:188)
        Caused by: besom.internal.DecodingError: [bootzooka-container-group[azure-native:containerinstance:ContainerGroup].ipAddress] bootzooka-container-group[azure-native:containerinstance:ContainerGroup].ipAddress: Encountered an error when deserializing an option
                at besom.internal.DecodingError$.apply(codecs.scala:80)
                at besom.internal.Decoder$.besom$internal$Decoder$$anon$7$$_$decode$$anonfun$3$$anonfun$3(codecs.scala:250)
                at besom.util.NonEmptyVector.map(Validated.scala:167)
                at besom.util.Validated.lmap(Validated.scala:47)
                at besom.util.Validated$.lmap$$anonfun$1(Validated.scala:137)
                at besom.internal.Result.map$$anonfun$1(Result.scala:201)
                at besom.internal.Result.flatMap$$anonfun$1(Result.scala:164)
                at besom.internal.Result.runM$$anonfun$7(Result.scala:269)
                at besom.internal.Runtime.flatMapBothM$$anonfun$1$$anonfun$1(Result.scala:118)
                at besom.internal.FutureRuntime.flatMapBoth$$anonfun$1(Result.scala:372)
                at scala.concurrent.impl.Promise$Transformation.run(Promise.scala:477)
                at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1423)
                at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:387)
                at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1312)
                at java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1843)
                at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1808)
                at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:188)
        Caused by: besom.internal.DecodingError: [bootzooka-container-group[azure-native:containerinstance:ContainerGroup].ipAddress.autoGeneratedDomainNameLabelScope] bootzooka-container-group[azure-native:containerinstance:ContainerGroup].ipAddress.autoGeneratedDomainNameLabelScope: Encountered an error - possible secret - Known(Set(),false,Some(Value(NullValue(NULL_VALUE),UnknownFieldSet(Map()))))
                at besom.internal.DecodingError$.apply(codecs.scala:80)
                at besom.internal.Decoder.decode$$anonfun$1$$anonfun$2(codecs.scala:132)
                at besom.util.NonEmptyVector.map(Validated.scala:167)
                at besom.util.Validated.lmap(Validated.scala:47)
                at besom.internal.Decoder.decode$$anonfun$1(codecs.scala:134)
                at besom.util.Validated$.flatMap$$anonfun$1(Validated.scala:112)
                at besom.internal.Result.flatMap$$anonfun$1(Result.scala:164)
                at besom.internal.Result.runM$$anonfun$7(Result.scala:269)
                at besom.internal.Runtime.flatMapBothM$$anonfun$1$$anonfun$1(Result.scala:118)
                at besom.internal.FutureRuntime.flatMapBoth$$anonfun$1(Result.scala:372)
                at scala.concurrent.impl.Promise$Transformation.run(Promise.scala:477)
                at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1423)
                at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:387)
                at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1312)
                at java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1843)
                at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1808)
                at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:188)
        Caused by: besom.internal.DecodingError: [bootzooka-container-group[azure-native:containerinstance:ContainerGroup].ipAddress.autoGeneratedDomainNameLabelScope] bootzooka-container-group[azure-native:containerinstance:ContainerGroup].ipAddress.autoGeneratedDomainNameLabelScope: Expected a string, got: 'NullValue(NULL_VALUE)'
                at besom.internal.DecodingError$.apply(codecs.scala:80)
                at besom.internal.Decoder$stringDecoder$.mapping(codecs.scala:202)
                at besom.internal.Decoder.decode$$anonfun$1$$anonfun$1(codecs.scala:128)
                at besom.internal.OutputData.traverseValidated(OutputData.scala:93)
                at besom.internal.Decoder.decode$$anonfun$1(codecs.scala:128)
                at besom.util.Validated$.flatMap$$anonfun$1(Validated.scala:112)
                at besom.internal.Result.flatMap$$anonfun$1(Result.scala:164)
                at besom.internal.Result.runM$$anonfun$7(Result.scala:269)
                at besom.internal.Runtime.flatMapBothM$$anonfun$1$$anonfun$1(Result.scala:118)
                at besom.internal.FutureRuntime.flatMapBoth$$anonfun$1(Result.scala:372)
                at scala.concurrent.impl.Promise$Transformation.run(Promise.scala:477)
                at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1423)
                at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:387)
                at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1312)
                at java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1843)
                at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1808)
                at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:188)

This is an upstream problem (in azure-native) that bubbles up to us. Do you need the value of the ip address? If so, the only way to deal with this is to fix upstream. Our serde layer is lazy (on purpose) so if you don't use a property that fails on deserialization it won't crash your program.

Thank you @polkx for the report. Looks like the underlying cause is two-fold:

field fqdn is required and type of string, we get the protobuf's NULL_VALUE - this is provider breaking its contract
field autoGeneratedDomainNameLabelScope is optional with a default and we mistakenly generate the provider code where the field is not optional - this is besom codegen bug.

The reason why ipAddress = containerGroup.ipAddress.ip is the bug trigger is because besom is trying to be smart about deserialization, and it is done when needed - so until someone accesses the filed witl broken value from the provider, then the problem does not propagate. Since this problem is widely spread among pulumi providers (of unexpected null values) then this should be helpful.
A separate discussion is whether or not, adding an "escape hatch", like a `recover function proposed by @lbialy would be helpful to the user. As pointed out by Łukasz, due to the fact that te user has limited possibilities how to remediate such a problem, the usefulness of such escape hatch would be limited.
For the reference, the schema from upstream defines the ipAddress as:
"azure-native:containerinstance:IpAddressResponse": {
            "description": "IP address for the container group.",
            "properties": {
                "autoGeneratedDomainNameLabelScope": {
                    "type": "string",
                    "description": "The value representing the security enum. The 'Unsecure' value is the default value if not selected and means the object's domain name label is not secured against subdomain takeover. The 'TenantReuse' value is the default value if selected and means the object's domain name label can be reused within the same tenant. The 'SubscriptionReuse' value means the object's domain name label can be reused within the same subscription. The 'ResourceGroupReuse' value means the object's domain name label can be reused within the same resource group. The 'NoReuse' value means the object's domain name label cannot be reused within the same resource group, subscription, or tenant.",
                    "default": "Unsecure"
                },
                "dnsNameLabel": {
                    "type": "string",
                    "description": "The Dns name label for the IP."
                },
                "fqdn": {
                    "type": "string",
                    "description": "The FQDN for the IP."
                },
                "ip": {
                    "type": "string",
                    "description": "The IP exposed to the public internet."
                },
                "ports": {
                    "type": "array",
                    "items": {
                        "type": "object",
                        "$ref": "#/types/azure-native:containerinstance:PortResponse"
                    },
                    "description": "The list of ports exposed on the container group."
                },
                "type": {
                    "type": "string",
                    "description": "Specifies if the IP is exposed to the public internet or private VNET."
                }
            },
            "type": "object",
            "required": [
                "fqdn",
                "ports",
                "type"
            ]
        },

besom azure native code:
final case class ContainerGroup private(
  ...
  ipAddress: besom.types.Output[scala.Option[besom.api.azurenative.containerinstance.outputs.IpAddressResponse]],
  ...
) extends besom.CustomResource

final case class IpAddressResponse private(
  autoGeneratedDomainNameLabelScope: String, // should be optional
  dnsNameLabel: scala.Option[String],
  fqdn: String, // is correct
  ip: scala.Option[String],
  ports: scala.collection.immutable.List[besom.api.azurenative.containerinstance.outputs.PortResponse],
  `type`: String
)

pulumi TS azure native:
    export interface IpAddressResponse {
        autoGeneratedDomainNameLabelScope?: string; // <<<
        dnsNameLabel?: string;
        fqdn: string; // <<<
        ip?: string;
        ports: outputs.containerinstance.PortResponse[];
        type: string;
    }

This is what we get from the engine:
    Value(
      kind = StructValue(
        value = Struct(
          fields = Map(
            "ip" -> Value(kind = StringValue(value = "<IP_ADDRESS>")),
            "ports" -> Value(
              kind = ListValue(
                value = ListValue(
                  values = Vector(
                    Value(
                      kind = StructValue(
                        value = Struct(
                          fields = Map(
                            "port" -> Value(kind = NumberValue(value = 8080.0)),
                            "protocol" -> Value(kind = StringValue(value = "TCP"))
                          )
                        )
                      )
                    )
                  )
                )
              )
            ),
            "type" -> Value(kind = StringValue(value = "Public"))
          )
        )
      )

As visible above, the ip that was accessed in the beginning, is present, and the errors are regarding neighboring fields.
The behavior I would expect is:

when accessing only the ip field - no error
when accessing the entire ipAddress - all errors regarding any of its fields

The question is, how can we do it, and how feasible is this.

Wait, this is an output type of struct, right? The property of a resource is an output of a case class that belongs to outputs package in codegened code? I thought that you meant that it's a property on a resource! If it's a field on a case class that's an output struct we can't do anything about it without breaking the type system. Let me elaborate - let's say we have:
case class SomeProps(a: String, b: Int, c: Double)
case class SomeResource(name: Output[String], props: Output[SomeProps])

Now in serde layer we have a resource decoder that will look up decoder instances for all fields in SomeResource and it will find List(Decoder[String], Decoder[SomeProps]). What we get from gRPC for the props field, for brevity in JSON form, is:
{
  "a": "some string",
  "b": 23
}

Notice the missing value for c field! Given that the definition of SomeProps case class expects non-nullable String, Int and Double there's literally nothing we can do to satisfy this expectation if we have a String and an Int only short of pushing a null into the c: Double position. That is subversion of the type system and as such is strictly against our philosophy of not lying in types.
The only other thing we could do here is to replace all the case classes of the output-kind of structs with wrappers extending Selectable over Maps with type refinements to allow safe, inline-based access to the properties held inside like @prolativ proposed to solve bincompat issues. This would break any support in Intellij because it's unable to comprehend type refinements at all and would force us to write an Intellij plugin for Besom. This solution would also throw on missing values but given that it always happens in Outputs and is literally how we currently work with such defects it would keep the status quo but improve the situation with deeply nested missing or broken props (because it would be possible to defer errors until access to a broken field happens.

You are right, since output classes does not have Output properties, we cannot defer the error to the last minute.
The easiest solution in my opinion would be to have output classes with output fields, then we'd have the granularity we need in regard to decoder errors.
Regarding other possibilities:

... extending Selectable over Maps with type refinements ...

I'd have to dig deeper into this proposal to fully understand all the implications, but I trust your judgment and from what you're saying I'm having mixed feelings about this one, I'm not against thou, just worried about consequences to the DX.

... complaining to the upstream to get their stuff fixed

Yes, this is always an options, unfortunately, I'd be surprised if this type of issue would get high priority, since all other SDK choose to deal with this by hiding the problem.

... patch schema during codegen before and you were against this

Yes, my main concern with schema patching is the scalability of maintenance, this would be fine with big enough community thou, but that's a bit of a chicken and the egg situation

... mark this field as optional ...

This would effectively turn every field into optional field, because if we cannot rely on the provider to conform to its schema then we have to assume that everything is optional, and this does not sound user friendly at all to me

There's one more consideration, the secretness. @polkx has made me aware that, when one of the fields in output class is secret, then the Output of the whole output class is secret, effectively making every field secret, regardless of the underlying schema. Making every field an output would solve this issue as well.

Until we re-architecture the output classes, I'd like to put under consideration the addition of Output.recover to allow for workarounds.


[WIP] Bugfix/Lazy loading the admin module on production/test server

Checklist

[ ] I tested the changes and all related features on the test server https://artemistest.ase.in.tum.de.
[x] ~I documented my source code using the JavaDoc / JSDoc style.~
[x] ~I added integration test cases for the server (Spring) related to the features~
[x] ~I added integration test cases for the client (Jest) related to the features~
[x] ~I added screenshots/screencast of my UI changes~
[x] ~I translated all the newly inserted strings~

Motivation and Context

Issue from https://github.com/ls1intum/Artemis/pull/736.
While working locally, the admin module fails on lazy load on the server:
breadcrumbs.js:58 ERROR Error: Uncaught (in promise): ReferenceError: Cannot access 'vl' before initialization
ReferenceError: Cannot access 'vl' before initialization

The strange thing is that this was working when I tested the PR on the test server: https://github.com/ls1intum/Artemis/pull/736#discussion_r317500373
Description

It seems like it was just the way the routes were imported.
Steps for Testing

Log in to Artemis (on test server!)
Open area in admin module (e.g. User management)
Area should be loaded

Screenshots

I couldn't test this on the test server because of the migration change from https://github.com/ls1intum/Artemis/pull/757.
I confirmed it locally with the production bundle though.