Build Tensorflow Docker image for Ivy Bridge processors

On https://github.com/RadeonOpenCompute/ROCm#supported-cpus, it says that the CPU should support PCIe Gen 3 and PCIe Atomics, and so it requires a Haswell+ architecture. However, my Ivy Bridge CPU (Intel i7-4820k) actually does support atomics (p. 11), as does the Xeon E5-26xx V2 according to this GitHub issue.
Just to demonstrate, amdkfd initializes correctly on my system:
Oct 18 07:44:27 rem kernel: kfd kfd: Initialized module
Oct 18 07:44:27 rem kernel: kfd kfd: Allocated 3969056 bytes on gart
Oct 18 07:44:27 rem kernel: kfd kfd: added device 1002:67df

Unfortunately, the Tensorflow Docker image doesn't run, because it was compiled with -march=haswell:
root@2a2a4a430b33:/root# python3
Python 3.5.2 (default, Nov 23 2017, 16:37:01)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import tensorflow
2018-10-21 14:20:43.079860: F tensorflow/core/platform/cpu_feature_guard.cc:37] The TensorFlow library was compiled to use AVX2 instructions, but these aren't available on your machine.
Aborted (core dumped)
root@2a2a4a430b33:/root#

Would it be possible to lower the march to ivybridge to support these older, but still functional, processors?

We have only tested on CPU later than Haswell hence the default config. If possible you could help provide information running HIP directed tests on your machine?
Please clone HIP at https://github.com/ROCm-Developer-Tools/HIP.git and build and run its unit tests and share the information with us. Thank you very much.

Sure! I'll give it a shot and report back.

CC @jlgreathouse for ROCm lvy Bridge support.

@whchung All tests pass on HIP v1.9.1. Ran in the Ubuntu 18.04 docker image with ROCm 1.9.1 installed from repositories.
It was a bit of a struggle freeing enough memory for one of the memcpy tests ;)
Details:
root@rem:/HIP/build# nice -n 19 ctest
Test project /HIP/build
        Start   1: directed_tests/hipEnvVarDriver.tst
  1/105 Test   #1: directed_tests/hipEnvVarDriver.tst ........................................   Passed    1.40 sec
        Start   2: directed_tests/Functional/device/hipFuncDeviceSynchronize.tst
  2/105 Test   #2: directed_tests/Functional/device/hipFuncDeviceSynchronize.tst .............   Passed    2.63 sec
        Start   3: directed_tests/Functional/device/hipFuncGetDevice.tst
  3/105 Test   #3: directed_tests/Functional/device/hipFuncGetDevice.tst .....................   Passed    0.89 sec
        Start   4: directed_tests/Functional/device/hipFuncSetDevice.tst
  4/105 Test   #4: directed_tests/Functional/device/hipFuncSetDevice.tst .....................   Passed    0.16 sec
        Start   5: directed_tests/Functional/device/hipFuncSetDeviceFlags.tst
  5/105 Test   #5: directed_tests/Functional/device/hipFuncSetDeviceFlags.tst ................   Passed    0.23 sec
        Start   6: directed_tests/context/hipCtx_simple.tst
  6/105 Test   #6: directed_tests/context/hipCtx_simple.tst ..................................   Passed    0.18 sec
        Start   7: directed_tests/context/hipMemsetD8.tst
  7/105 Test   #7: directed_tests/context/hipMemsetD8.tst ....................................   Passed    0.41 sec
        Start   8: directed_tests/context/hipMemsetD8-N10--memsetval0x42.tst
  8/105 Test   #8: directed_tests/context/hipMemsetD8-N10--memsetval0x42.tst .................   Passed    0.29 sec
        Start   9: directed_tests/context/hipMemsetD8-N10013--memsetval0x5a.tst
  9/105 Test   #9: directed_tests/context/hipMemsetD8-N10013--memsetval0x5a.tst ..............   Passed    0.30 sec
        Start  10: directed_tests/context/hipMemsetD8-N256M--memsetval0xa6.tst
 10/105 Test  #10: directed_tests/context/hipMemsetD8-N256M--memsetval0xa6.tst ...............   Passed    1.31 sec
        Start  11: directed_tests/deviceLib/hipDeviceMemcpy.tst
 11/105 Test  #11: directed_tests/deviceLib/hipDeviceMemcpy.tst ..............................   Passed    2.39 sec
        Start  12: directed_tests/deviceLib/hipDoublePrecisionIntrinsics.tst
 12/105 Test  #12: directed_tests/deviceLib/hipDoublePrecisionIntrinsics.tst .................   Passed    0.27 sec
        Start  13: directed_tests/deviceLib/hipDoublePrecisionMathDevice.tst
 13/105 Test  #13: directed_tests/deviceLib/hipDoublePrecisionMathDevice.tst .................   Passed    0.22 sec
        Start  14: directed_tests/deviceLib/hipDoublePrecisionMathHost.tst
 14/105 Test  #14: directed_tests/deviceLib/hipDoublePrecisionMathHost.tst ...................   Passed    0.21 sec
        Start  15: directed_tests/deviceLib/hipFloatMath.tst
 15/105 Test  #15: directed_tests/deviceLib/hipFloatMath.tst .................................   Passed    0.77 sec
        Start  16: directed_tests/deviceLib/hipFloatMathPrecise.tst
 16/105 Test  #16: directed_tests/deviceLib/hipFloatMathPrecise.tst ..........................   Passed    0.80 sec
        Start  17: directed_tests/deviceLib/hipIntegerIntrinsics.tst
 17/105 Test  #17: directed_tests/deviceLib/hipIntegerIntrinsics.tst .........................   Passed    0.30 sec
        Start  18: directed_tests/deviceLib/hipMathFunctions.tst
 18/105 Test  #18: directed_tests/deviceLib/hipMathFunctions.tst .............................   Passed    0.24 sec
        Start  19: directed_tests/deviceLib/hipSimpleAtomicsTest.tst
 19/105 Test  #19: directed_tests/deviceLib/hipSimpleAtomicsTest.tst .........................   Passed    0.22 sec
        Start  20: directed_tests/deviceLib/hipSinglePrecisionIntrinsics.tst
 20/105 Test  #20: directed_tests/deviceLib/hipSinglePrecisionIntrinsics.tst .................   Passed    0.48 sec
        Start  21: directed_tests/deviceLib/hipSinglePrecisionMathDevice.tst
 21/105 Test  #21: directed_tests/deviceLib/hipSinglePrecisionMathDevice.tst .................   Passed    1.54 sec
        Start  22: directed_tests/deviceLib/hipSinglePrecisionMathHost.tst
 22/105 Test  #22: directed_tests/deviceLib/hipSinglePrecisionMathHost.tst ...................   Passed    0.25 sec
        Start  23: directed_tests/deviceLib/hipTestDevice.tst
 23/105 Test  #23: directed_tests/deviceLib/hipTestDevice.tst ................................   Passed    0.28 sec
        Start  24: directed_tests/deviceLib/hipTestDeviceSymbol.tst
 24/105 Test  #24: directed_tests/deviceLib/hipTestDeviceSymbol.tst ..........................   Passed    0.96 sec
        Start  25: directed_tests/deviceLib/hipTestHalf.tst
 25/105 Test  #25: directed_tests/deviceLib/hipTestHalf.tst ..................................   Passed    0.63 sec
        Start  26: directed_tests/deviceLib/hipTestNativeHalf.tst
 26/105 Test  #26: directed_tests/deviceLib/hipTestNativeHalf.tst ............................   Passed    0.24 sec
        Start  27: directed_tests/deviceLib/hipThreadFence.tst
 27/105 Test  #27: directed_tests/deviceLib/hipThreadFence.tst ...............................   Passed    0.22 sec
        Start  28: directed_tests/deviceLib/hipVectorTypes.tst
 28/105 Test  #28: directed_tests/deviceLib/hipVectorTypes.tst ...............................   Passed    0.20 sec
        Start  29: directed_tests/deviceLib/hipVectorTypesDevice.tst
 29/105 Test  #29: directed_tests/deviceLib/hipVectorTypesDevice.tst .........................   Passed    0.20 sec
        Start  30: directed_tests/deviceLib/hip_anyall.tst
 30/105 Test  #30: directed_tests/deviceLib/hip_anyall.tst ...................................   Passed    1.01 sec
        Start  31: directed_tests/deviceLib/hip_ballot.tst
 31/105 Test  #31: directed_tests/deviceLib/hip_ballot.tst ...................................   Passed    0.45 sec
        Start  32: directed_tests/deviceLib/hip_brev.tst
 32/105 Test  #32: directed_tests/deviceLib/hip_brev.tst .....................................   Passed    0.27 sec
        Start  33: directed_tests/deviceLib/hip_clz.tst
 33/105 Test  #33: directed_tests/deviceLib/hip_clz.tst ......................................   Passed    0.21 sec
        Start  34: directed_tests/deviceLib/hip_ffs.tst
 34/105 Test  #34: directed_tests/deviceLib/hip_ffs.tst ......................................   Passed    0.24 sec
        Start  35: directed_tests/deviceLib/hip_mbcnt.tst
 35/105 Test  #35: directed_tests/deviceLib/hip_mbcnt.tst ....................................   Passed    0.31 sec
        Start  36: directed_tests/deviceLib/hip_popc.tst
 36/105 Test  #36: directed_tests/deviceLib/hip_popc.tst .....................................   Passed    0.59 sec
        Start  37: directed_tests/deviceLib/hip_test_ldg.tst
 37/105 Test  #37: directed_tests/deviceLib/hip_test_ldg.tst .................................   Passed    0.76 sec
        Start  38: directed_tests/deviceLib/hip_threadfence_system.tst
 38/105 Test  #38: directed_tests/deviceLib/hip_threadfence_system.tst .......................   Passed    0.51 sec
        Start  39: directed_tests/deviceLib/hip_trig.tst
 39/105 Test  #39: directed_tests/deviceLib/hip_trig.tst .....................................   Passed    0.22 sec
        Start  40: directed_tests/kernel/hipEmptyKernel.tst
 40/105 Test  #40: directed_tests/kernel/hipEmptyKernel.tst ..................................   Passed    0.30 sec
        Start  41: directed_tests/kernel/hipGridLaunch.tst
 41/105 Test  #41: directed_tests/kernel/hipGridLaunch.tst ...................................   Passed    0.61 sec
        Start  42: directed_tests/kernel/hipLanguageExtensions.tst
 42/105 Test  #42: directed_tests/kernel/hipLanguageExtensions.tst ...........................   Passed    0.61 sec
        Start  43: directed_tests/kernel/hipLaunchParm.tst
 43/105 Test  #43: directed_tests/kernel/hipLaunchParm.tst ...................................   Passed    0.59 sec
        Start  44: directed_tests/kernel/hipPrintfKernel.tst
 44/105 Test  #44: directed_tests/kernel/hipPrintfKernel.tst .................................   Passed    0.27 sec
        Start  45: directed_tests/kernel/hipTestConstant.tst
 45/105 Test  #45: directed_tests/kernel/hipTestConstant.tst .................................   Passed    0.29 sec
        Start  46: directed_tests/kernel/hipTestMemKernel.tst
 46/105 Test  #46: directed_tests/kernel/hipTestMemKernel.tst ................................   Passed    0.24 sec
        Start  47: directed_tests/kernel/inline_asm_vadd.tst
 47/105 Test  #47: directed_tests/kernel/inline_asm_vadd.tst .................................   Passed    0.77 sec
        Start  48: directed_tests/runtimeApi/device/hipChooseDevice.tst
 48/105 Test  #48: directed_tests/runtimeApi/device/hipChooseDevice.tst ......................   Passed    0.30 sec
        Start  49: directed_tests/runtimeApi/device/hipDeviceComputeCapability.tst
 49/105 Test  #49: directed_tests/runtimeApi/device/hipDeviceComputeCapability.tst ...........   Passed    0.38 sec
        Start  50: directed_tests/runtimeApi/device/hipDeviceGetByPCIBusId.tst
 50/105 Test  #50: directed_tests/runtimeApi/device/hipDeviceGetByPCIBusId.tst ...............   Passed    0.23 sec
        Start  51: directed_tests/runtimeApi/device/hipDeviceGetName.tst
 51/105 Test  #51: directed_tests/runtimeApi/device/hipDeviceGetName.tst .....................   Passed    0.17 sec
        Start  52: directed_tests/runtimeApi/device/hipDeviceGetPCIBusId.tst
 52/105 Test  #52: directed_tests/runtimeApi/device/hipDeviceGetPCIBusId.tst .................   Passed    0.17 sec
        Start  53: directed_tests/runtimeApi/device/hipDeviceSynchronize.tst
 53/105 Test  #53: directed_tests/runtimeApi/device/hipDeviceSynchronize.tst .................   Passed    0.20 sec
        Start  54: directed_tests/runtimeApi/device/hipDeviceTotalMem.tst
 54/105 Test  #54: directed_tests/runtimeApi/device/hipDeviceTotalMem.tst ....................   Passed    0.14 sec
        Start  55: directed_tests/runtimeApi/device/hipGetDevice.tst
 55/105 Test  #55: directed_tests/runtimeApi/device/hipGetDevice.tst .........................   Passed    0.80 sec
        Start  56: directed_tests/runtimeApi/device/hipGetDeviceAttribute.tst
 56/105 Test  #56: directed_tests/runtimeApi/device/hipGetDeviceAttribute.tst ................   Passed    0.57 sec
        Start  57: directed_tests/runtimeApi/device/hipRuntimeGetVersion.tst
 57/105 Test  #57: directed_tests/runtimeApi/device/hipRuntimeGetVersion.tst .................   Passed    0.36 sec
        Start  58: directed_tests/runtimeApi/device/hipSetCachceConfig.tst
 58/105 Test  #58: directed_tests/runtimeApi/device/hipSetCachceConfig.tst ...................   Passed    0.17 sec
        Start  59: directed_tests/runtimeApi/device/hipSetDevice.tst
 59/105 Test  #59: directed_tests/runtimeApi/device/hipSetDevice.tst .........................   Passed    0.25 sec
        Start  60: directed_tests/runtimeApi/device/hipSetDeviceFlags.tst
 60/105 Test  #60: directed_tests/runtimeApi/device/hipSetDeviceFlags.tst ....................   Passed    0.24 sec
        Start  61: directed_tests/runtimeApi/error/hipPeekAtLastError.tst
 61/105 Test  #61: directed_tests/runtimeApi/error/hipPeekAtLastError.tst ....................   Passed    0.19 sec
        Start  62: directed_tests/runtimeApi/event/hipEventRecord--iterations10.tst
 62/105 Test  #62: directed_tests/runtimeApi/event/hipEventRecord--iterations10.tst ..........   Passed    0.62 sec
        Start  63: directed_tests/runtimeApi/event/record_event.tst
 63/105 Test  #63: directed_tests/runtimeApi/event/record_event.tst ..........................   Passed   96.50 sec
        Start  64: directed_tests/runtimeApi/memory/hipHostGetFlags.tst
 64/105 Test  #64: directed_tests/runtimeApi/memory/hipHostGetFlags.tst ......................   Passed    0.62 sec
        Start  65: directed_tests/runtimeApi/memory/hipHostMalloc.tst
 65/105 Test  #65: directed_tests/runtimeApi/memory/hipHostMalloc.tst ........................   Passed    1.85 sec
        Start  66: directed_tests/runtimeApi/memory/hipHostRegister.tst
 66/105 Test  #66: directed_tests/runtimeApi/memory/hipHostRegister.tst ......................   Passed   12.92 sec
        Start  67: directed_tests/runtimeApi/memory/hipMemPtrGetInfo.tst
 67/105 Test  #67: directed_tests/runtimeApi/memory/hipMemPtrGetInfo.tst .....................   Passed    0.49 sec
        Start  68: directed_tests/runtimeApi/memory/hipMemcpy-modes.tst
 68/105 Test  #68: directed_tests/runtimeApi/memory/hipMemcpy-modes.tst ......................   Passed    6.07 sec
        Start  69: directed_tests/runtimeApi/memory/hipMemcpy-size.tst
 69/105 Test  #69: directed_tests/runtimeApi/memory/hipMemcpy-size.tst .......................   Passed   40.07 sec
        Start  70: directed_tests/runtimeApi/memory/hipMemcpy-dev-offsets.tst
 70/105 Test  #70: directed_tests/runtimeApi/memory/hipMemcpy-dev-offsets.tst ................   Passed    7.13 sec
        Start  71: directed_tests/runtimeApi/memory/hipMemcpy-host-offsets.tst
 71/105 Test  #71: directed_tests/runtimeApi/memory/hipMemcpy-host-offsets.tst ...............   Passed    7.00 sec
        Start  72: directed_tests/runtimeApi/memory/hipMemcpy-multithreaded.tst
 72/105 Test  #72: directed_tests/runtimeApi/memory/hipMemcpy-multithreaded.tst ..............   Passed    2.93 sec
        Start  73: directed_tests/runtimeApi/memory/hipMemcpyDtoD.tst
 73/105 Test  #73: directed_tests/runtimeApi/memory/hipMemcpyDtoD.tst ........................   Passed    0.15 sec
        Start  74: directed_tests/runtimeApi/memory/hipMemcpyDtoDAsync.tst
 74/105 Test  #74: directed_tests/runtimeApi/memory/hipMemcpyDtoDAsync.tst ...................   Passed    0.22 sec
        Start  75: directed_tests/runtimeApi/memory/hipMemcpyPeer.tst
 75/105 Test  #75: directed_tests/runtimeApi/memory/hipMemcpyPeer.tst ........................   Passed    0.14 sec
        Start  76: directed_tests/runtimeApi/memory/hipMemcpyPeerAsync.tst
 76/105 Test  #76: directed_tests/runtimeApi/memory/hipMemcpyPeerAsync.tst ...................   Passed    0.15 sec
        Start  77: directed_tests/runtimeApi/memory/hipMemcpy_simple.tst
 77/105 Test  #77: directed_tests/runtimeApi/memory/hipMemcpy_simple.tst .....................   Passed    1.19 sec
        Start  78: directed_tests/runtimeApi/memory/hipMemcpyAsync-simple.tst
 78/105 Test  #78: directed_tests/runtimeApi/memory/hipMemcpyAsync-simple.tst ................   Passed    0.62 sec
        Start  79: directed_tests/runtimeApi/memory/hipMemoryAllocateCoherentDriver.tst
 79/105 Test  #79: directed_tests/runtimeApi/memory/hipMemoryAllocateCoherentDriver.tst ......   Passed    0.13 sec
        Start  80: directed_tests/runtimeApi/memory/hipMemset.tst
 80/105 Test  #80: directed_tests/runtimeApi/memory/hipMemset.tst ............................   Passed    0.19 sec
        Start  81: directed_tests/runtimeApi/memory/hipMemset-N10--memsetval0x42.tst
 81/105 Test  #81: directed_tests/runtimeApi/memory/hipMemset-N10--memsetval0x42.tst .........   Passed    0.18 sec
        Start  82: directed_tests/runtimeApi/memory/hipMemset-N10013--memsetval0x5a.tst
 82/105 Test  #82: directed_tests/runtimeApi/memory/hipMemset-N10013--memsetval0x5a.tst ......   Passed    0.19 sec
        Start  83: directed_tests/runtimeApi/memory/hipMemset-N256M--memsetval0xa6.tst
 83/105 Test  #83: directed_tests/runtimeApi/memory/hipMemset-N256M--memsetval0xa6.tst .......   Passed    1.77 sec
        Start  84: directed_tests/runtimeApi/memory/hipMemset2D.tst
 84/105 Test  #84: directed_tests/runtimeApi/memory/hipMemset2D.tst ..........................   Passed    0.24 sec
        Start  85: directed_tests/runtimeApi/memory/hipMemset3D-N10--memsetval0x42.tst
 85/105 Test  #85: directed_tests/runtimeApi/memory/hipMemset3D-N10--memsetval0x42.tst .......   Passed    0.26 sec
        Start  86: directed_tests/runtimeApi/memory/hipRandomMemcpyAsync.tst
 86/105 Test  #86: directed_tests/runtimeApi/memory/hipRandomMemcpyAsync.tst .................   Passed    0.21 sec
        Start  87: directed_tests/runtimeApi/memory/hipTestMemcpyPin.tst
 87/105 Test  #87: directed_tests/runtimeApi/memory/hipTestMemcpyPin.tst .....................   Passed    0.50 sec
        Start  88: directed_tests/runtimeApi/module/hipFuncGetAttributes.tst
 88/105 Test  #88: directed_tests/runtimeApi/module/hipFuncGetAttributes.tst .................   Passed    0.56 sec
        Start  89: directed_tests/runtimeApi/module/hipFuncSetCacheConfig.tst
 89/105 Test  #89: directed_tests/runtimeApi/module/hipFuncSetCacheConfig.tst ................   Passed    0.40 sec
        Start  90: directed_tests/runtimeApi/multiThread/hipMultiThreadDevice-serial.tst
 90/105 Test  #90: directed_tests/runtimeApi/multiThread/hipMultiThreadDevice-serial.tst .....   Passed    5.45 sec
        Start  91: directed_tests/runtimeApi/multiThread/hipMultiThreadDevice-pyramid.tst
 91/105 Test  #91: directed_tests/runtimeApi/multiThread/hipMultiThreadDevice-pyramid.tst ....   Passed    5.94 sec
        Start  92: directed_tests/runtimeApi/multiThread/hipMultiThreadDevice-nearzero.tst
 92/105 Test  #92: directed_tests/runtimeApi/multiThread/hipMultiThreadDevice-nearzero.tst ...   Passed    3.82 sec
        Start  93: directed_tests/runtimeApi/multiThread/hipMultiThreadStreams1.tst
 93/105 Test  #93: directed_tests/runtimeApi/multiThread/hipMultiThreadStreams1.tst ..........   Passed    7.76 sec
        Start  94: directed_tests/runtimeApi/multiThread/hipMultiThreadStreams2.tst
 94/105 Test  #94: directed_tests/runtimeApi/multiThread/hipMultiThreadStreams2.tst ..........   Passed    0.32 sec
        Start  95: directed_tests/runtimeApi/stream/hipNullStream.tst
 95/105 Test  #95: directed_tests/runtimeApi/stream/hipNullStream.tst ........................   Passed   57.47 sec
        Start  96: directed_tests/runtimeApi/stream/hipStreamAddCallback.tst
 96/105 Test  #96: directed_tests/runtimeApi/stream/hipStreamAddCallback.tst .................   Passed    0.43 sec
        Start  97: directed_tests/runtimeApi/stream/hipStreamGetFlags.tst
 97/105 Test  #97: directed_tests/runtimeApi/stream/hipStreamGetFlags.tst ....................   Passed    0.36 sec
        Start  98: directed_tests/runtimeApi/stream/hipStreamL5.tst
 98/105 Test  #98: directed_tests/runtimeApi/stream/hipStreamL5.tst ..........................   Passed   28.51 sec
        Start  99: directed_tests/runtimeApi/stream/hipStreamSync2.tst
 99/105 Test  #99: directed_tests/runtimeApi/stream/hipStreamSync2.tst .......................   Passed   21.74 sec
        Start 100: directed_tests/runtimeApi/synchronization/copy_coherency.tst
100/105 Test #100: directed_tests/runtimeApi/synchronization/copy_coherency.tst ..............   Passed    2.11 sec
        Start 101: directed_tests/surface/hipSurfaceObj2D.tst
101/105 Test #101: directed_tests/surface/hipSurfaceObj2D.tst ................................   Passed    0.34 sec
        Start 102: directed_tests/texture/hipBindTexRef1DFetch.tst
102/105 Test #102: directed_tests/texture/hipBindTexRef1DFetch.tst ...........................   Passed    0.19 sec
        Start 103: directed_tests/texture/hipTextureObj1DFetch.tst
103/105 Test #103: directed_tests/texture/hipTextureObj1DFetch.tst ...........................   Passed    1.24 sec
        Start 104: directed_tests/texture/hipTextureObj2D.tst
104/105 Test #104: directed_tests/texture/hipTextureObj2D.tst ................................   Passed    0.38 sec
        Start 105: directed_tests/texture/hipTextureRef2D.tst
105/105 Test #105: directed_tests/texture/hipTextureRef2D.tst ................................   Passed    0.54 sec
100% tests passed, 0 tests failed out of 105
Total Test time (real) = 350.74 sec

@sunway513 if that particular model of IVB has support for PCIe gen 3 atomics, so much the better. It looks to be the case, based on the kfd finding and enumerating a Polaris 10 GPU (device ID 67df). I updated our documentation to indicate that some Ivy Bridge-E devices support atomics.
That's not to say that all Ivy Bridge processor will work in ROCm, though. And as may be obvious from the conversations here, we don't test Ivy Bridge for any of our releases inside AMD. :)

Hi @ghostplant could you verify if the issue can be reproducible using our dev docker images, e.g.:
rocm/tensorflow:rocm2.1-tf1.12-python3-dev
The docker image includes all the dependencies to build tensorflow from source.

@Pneumaticat are there any updates?

@sunway513 Not much - I just tried @ghostplant's suggestion of using -march=x86-64 on the image tag you mentioned, but it appears that even the build tools are compiled with instructions not present on Ivy Bridge; protoc fails with illegal instruction:
ERROR: /root/tensorflow/tensorflow/core/BUILD:2408:1: ProtoCompile tensorflow/core/lib/core/error_codes.pb.cc failed (Illegal
instruction): protoc failed: error executing command
  (cd /root/.cache/bazel/_bazel_root/efb88f6336d9c4a18216fb94287b8d97/execroot/org_tensorflow && \
  exec env - \
    PATH=/opt/rocm/opencl/bin:/opt/rocm/bin:/opt/rocm/hcc/bin:/opt/rocm/hip/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/
bin:/sbin:/bin \
    PYTHON_BIN_PATH=/usr/bin/python \
    PYTHON_LIB_PATH=/usr/local/lib/python2.7/dist-packages \
    TF_DOWNLOAD_CLANG=0 \
    TF_NEED_CUDA=0 \
    TF_NEED_OPENCL_SYCL=0 \
    TF_NEED_ROCM=1 \
  bazel-out/host/bin/external/protobuf_archive/protoc '--cpp_out=bazel-out/k8-opt/genfiles/' -I. -Iexternal/protobuf_archive/src -Ibazel-out/k8-opt/genfiles/external/protobuf_archive/src tensorflow/core/lib/core/error_codes.proto): protoc failed: error executing command
  (cd /root/.cache/bazel/_bazel_root/efb88f6336d9c4a18216fb94287b8d97/execroot/org_tensorflow && \
  exec env - \
    PATH=/opt/rocm/opencl/bin:/opt/rocm/bin:/opt/rocm/hcc/bin:/opt/rocm/hip/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \
    PYTHON_BIN_PATH=/usr/bin/python

I suspect the build would work, however, if not for the build tools not being compatible. Not sure if there is an easier way to compile the tools for a build environment myself?

Hi @Pneumaticat , maybe you can revert the following commit and try again with the dev docker image: https://github.com/ROCmSoftwarePlatform/tensorflow-upstream/commit/6616c9272a3021d52b377e48b714918a3791b7cf

@sunway513 To provide an update, I reverted that commit as you suggested using the develop-upstream-rocm2.3-updates branch using manually installed ROCM dependencies in an Ubuntu 16.04 container, and Tensorflow successfully built and starts!
I have not yet tried out training on the GPU, but I will test that shortly.

...Actually, it seems like the stock rocm/tensorflow:latest now works? No more crash on import.
docker run --rm -it --privileged rocm/tensorflow                                                        130 ↵
root@81e6a4c40e32:/root# impor^C
root@81e6a4c40e32:/root# python3
Python 3.5.2 (default, Nov 12 2018, 13:43:14)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import tensorflow as tf
>>> sess = tf.Session(config=tf.ConfigProto(log_device_placement=True))
2019-04-21 02:24:30.496717: I tensorflow/core/platform/cpu_feature_guard.cc:141] Your CPU supports instructions that this TensorFlow binary was not compiled to use: SSE4.1 SSE4.2 AVX
2019-04-21 02:24:30.514573: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1531] Found device 0 with properties:
name: Device 67df
AMDGPU ISA: gfx803
memoryClockRate (GHz) 1.36
pciBusID 0000:03:00.0
Total memory: 8.00GiB
Free memory: 7.75GiB

I'm not sure what changed in the build configuration of the stock image, but in any case it seems like the issue has been resolved. Thanks!


Multiple accordions on one page screws up Accordion collapse duration

I have multiple accordions on a page. Collapsing accordions sometimes skip the duration and happens instantly. Ideas?

This used to happen (in my case) when the data inside the accordion was being fetched from an API. The lag made the accordion to skip the animation.

@maasha would be great if you could provide an example, but I guess we need some kind of async prop/flag to control that.


malformed observer registration yields a difficult to debug error

...
observers: ['foo(zap, tap']
...

Seems like something we might want to catch and surface a bit better

best
day
ever

Thanks @samccone :heart:


Allow using an externally defined db parameter group

Add two optional input variables, one to indicate an external parameter group should be used instead of the built-in one, and the other to specify the name of the group to use. For now, a single variable doesn't appear to be sufficient due to hashicorp/terraform#12570
Fixes #29

LGTM

New release - https://github.com/terraform-community-modules/tf_aws_rds/releases/tag/v1.0.3

yay 🎉 cheers guys!


Fix embedding of multiple shared cards

It is broken due to a bug in query code:
Sharing information about the bug discussed in the morning for a VM where a user is attaching multiple Shared NICs. get_matching_nodes_with_components returns an empty list.
zz_neo4j_pg_test.py::test_arm_load test fails when i request for two SharedNICs.
    def __candidate_nodes(self, *, sliver: NodeSliver) -> List[str]:
        """
        Identify candidate worker nodes in this site that have at least
        as many needed components as in the sliver.
        """
        node_props = {ABCPropertyGraphConstants.PROP_SITE: sliver.site,
                      ABCPropertyGraphConstants.PROP_TYPE: str(NodeType.Server)}
        return self.combined_broker_model.get_matching_nodes_with_components(
            label=ABCPropertyGraphConstants.CLASS_NetworkNode,
            props=node_props,
            comps=sliver.attached_components_info)

The bug is in neo4j_cbm.get_matching_nodes_with_components(). It builds a query based on components types and counts, counting each individual component. However for shared NICs the count should be 1, no matter how many shared NICs are requested.

Fixed in #72


make this more like a command

i fucked something up and have two PRs in one and i am tired and don't want to fix it right this moment, the first one changes the dir structure a bit to make this closer to the common dir structure for library+cmd (though this should probably be inverted to be just cmd or cmd+lib structure), and the second increase the available colors to 36 and makes the same pod get the same color each time

In this case, I think it makes more sense to move the cmd related code to the root.

Closing due to lack of activity (and it's pretty outdated). Would be great to get the better color support added though…


Update PP inference benchmark script

Description

Update PP inference benchmark script
Just need to run run-pipeline-parallel-arc.sh and modify NUM_GPUS in it to specify gpu number.
Fix Assertion 'input.scalar_type() == weight.scalar_type()' failed when setting torch_dtype=torch.float16

4. How to test?

[ ] Unit test
[x] Local test

We could also update the readme here? https://github.com/intel-analytics/ipex-llm/tree/main/python/llm/dev/benchmark/all-in-one#config

Have updated :)


Profile view

be able to see you profile
for future - be able to update existing info

hopefully its right =)


Property animation timeline with keyframe tweening and easing

Related to #82
As a data storyteller
I would like the camera to move around smoothly and automatically over time
So I can focus on the narrative I am trying to convey
Feature
Add a 'camera automation timeline' interface to enable sequenced camera movements. The movements might be encoded in keyframes that contain the camera location and rotation (abstracted from the internal viewport data representation). Camera position would be animated by 'tweening' the values between keyframes. Non-linear tweens, or easings, would give a natural feeling to camera motion.

On further reflection, this 'tweened keyframe animation timeline' might also be used to animate other viewspace properties. For example, it might be meaningful to animate the time filter window start/end points. The combination of camera time filter animation could be very useful for highlighting data nuances and trends.

A hypothetical workflow would be to allow the user to directly manipulate the camera and time filter window and then insert a keyframe somewhere along the automation timeline by selecting the point in time and clickung a keyframe button and the properties for which they want to capture values. Rinse and repeat 🌻

There are two main 'storytelling modes', which are somewhat complementary.

time-sequenced - a timeline with keyframes that are controlled via a playback head (similar to the current time filter)
scene-based - I.e. a slideshow presentation where each scene would be a snapshot of desired parameter state and navigation jumps from scene to scene

They seem interrelated as, for example, a scene-based presentation may have scenes with sub-timeline events (such as a slide deck with animations on some slides).
In conjunction with camera placement and time control, the visibility and opacity of layers could be toggled/tweened as part of the narration.

Godot Engine serves as a good example of a keyframe animation UX.
Here is the Godot keyframe timeline:

Any property that can be keyframed has a corresponding key icon that the user can click to 'record' the property at that value in time:
Godot property recording

Hi @brylie
This is awesome, thanks for suggesting this feature. The UI is very helpful. The uber Elevate team, in fact, have built a customized tool adding keyframe animation features with kepler.gl programmatically. Your UI suggestion is exactly what we need to make this animation feature purely in the UI without having to write any code. We will take your suggestion and see how can we put it into our roadmap. Thanks again!

@brylie Just wanted to chime in! I'm the engineer who built the keyframe animation features used in the video @heshan0131 linked to. I'm continuing to make progress on the library and UI components. Thank you for your suggestions. I've kept them in mind!

@chrisgervang sounds cool. I agree that video export may not be as high priority, since there are ready made screen capture tools. It may arise later that rendering the frames makes screen captured video somewhat jerky, in which case a baked in renderer may make sense.


Add documentation on pyproject.toml plugin entry-points

Links & content can be adjusted as necessary.
Although there is more detailed documentation available for users about entry-points (E.g. the PyPA pyproject.toml specification/writing guide or Hatch's configuration documentation), a good starting point to allow users to see that this feature is available would be useful. uv should advertise the starting point of the pyproject.toml feature and allow users to explore more

This is a duplicate of #9329, do you mind commenting there with any suggestions or waiting until that is done?

Welcome to the project <3

Apologies for the duplicate work, I forgot to do a check for existing changes

The documentation written in #9329 is far superior to the changes made here, and I don't think there is a great need for specific examples of using the entry-points specification for specific projects' plugins systems. Therefore I will close this PR


Created pancake_sort.py in algorithms/sorts

(Put an X inside the [ ] to denote check mark [X].)

[ X ] If creating a new file :

[ X ] added links to it in the README files ?
[ X ] included tests with it ?
[ X ] added description (overview of algorithm, time and space compleixty, and possible edge case) in docstrings ?

[ ] if done some changes :

[ ] wrote short description in the PR explaining what the changes do ?
[ ] Fixes #[issue number] if related to any issue

[ ] other

Pull Request Test Coverage Report for Build 558

12 of 13 (92.31%)  changed or added relevant lines in 2 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage increased (+0.06%) to 69.352%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

algorithms/sort/pancake_sort.py
10
11
90.91%

Files with Coverage Reduction
New Missed Lines
%

algorithms/linkedlist/is_palindrome.py
1
93.33%

Totals

Change from base Build 555:
0.06%

Covered Lines:
3220

Relevant Lines:
4643

💛  - Coveralls

@9967han Great! Thanks PR


Return class ids with dataloaders

We need train_y and val_y returned as well as the pytorch dataloaders when doing loader.get_loader(batch_size=batch_s, split=splt)
For reference is this lines (166 and 167):
https://github.com/alan-turing-institute/affinity-vae/blob/5c0d2c8da76dbbc39606822d8de2944248b74b61/avae/data.py#L166

This is not necessary as we can obtain labels from the loaders. Thanks, @mooniean for helping debug! Closing.


Python list comprehensions give error when reusing comprehension variable name

loop:
    items = [i for i in self.findItems() if i.pos.x<38]
    item = self.findNearest(items)
    if item:
        self.moveXY(item.pos.x, item.pos.y)
    else:
        items = [i for i in self.findItems() if i.pos.x>38 and i.pos.y>33]
        item = self.findNearest(items)
        self.moveXY(item.pos.x, item.pos.y)

This code gives a strange error. When the second items =  is called it ends up as a list ['next','throw'].  I tested with loop:
for k in items:
    self.say(String(k))

When I changed the code to the following it runs properly.
loop:
    top = [i for i in self.findItems() if i.pos.x>38 and i.pos.y>33]
    left = [i for i in self.findItems() if i.pos.x<38]
    if self.now()<52:
        items = left
    else:
        items = top
    item = self.findNearest(items)
    if item:
        self.moveXY(item.pos.x, item.pos.y)

Apparently having the comprehension inside the if caused problems.  Not sure if the if is the problem or the fact that it is indented twice.

When I try this now, I don't see the problem with the list being ['next', 'throw'], but I do see it throwing this error if I re-use the same list comprehension local variable:

When I name it i2, it works.

Should be fixed after next production deploy.  Our Python parser doesn't support strict mode, which was recently turned on.
https://github.com/codecombat/aether/commit/3f124071ad5b3e51564ec1a7368ad784e94e3145


feat(protocol): improve sync header storage on L2

Now both the height and the hash of latest synced L1 block is known.

@cyberhorsey I run tokenonmics tests but found there are errors:
commiting  12 with commit slot 3
proposing 12 with commit slot 3
Proposed block 0x765f1c9ef93964233b559131ac15a1f1b5d6c2618ab782e963832341fbe1a392
-----------PROPOSED--------------- 12 BigNumber { value: "4" }
NEW PROOF REWARD 0.989249431387414707  TKO
NEW PROPOSER TKO BALANCE 100.0  TKO
NEW BLOCK FEE 1.09375  TKO
AssertionError: expected false to equal true
    at JsonRpcProvider.<anonymous> (/Users/d/Projects/taiko/taiko-mono/packages/protocol/test/tokenomics/Tokenomics.test.ts:163:25)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (node:internal/process/task_queues:96:5) {
  showDiff: true,
  actual: false,
  expected: true,
  operator: 'strictEqual'
}
    ✔ block fee should increase as the halving period passes, while no blocks are proposed (5105ms)
commiting  14 with commit slot 4
proposing 14 with commit slot 4
Proposed block 0xc81fa5dcb3903d311978cbefef04c648dc7e40648c901c324118ab0caf66997a
-----------PROPOSED--------------- 14 BigNumber { value: "5" }
NEW PROOF REWARD 0.989249431387414707  TKO
NEW PROPOSER TKO BALANCE 100.0  TKO
NEW BLOCK FEE 1.240234375  TKO
AssertionError: expected false to equal true
    at JsonRpcProvider.<anonymous> (/Users/d/Projects/taiko/taiko-mono/packages/protocol/test/tokenomics/Tokenomics.test.ts:163:25)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (node:internal/process/task_queues:96:5) {
  showDiff: true,
  actual: false,
  expected: true,
  operator: 'strictEqual'
}
commiting  13 with commit slot 5
proposing 13 with commit slot 5
Proposed block 0x0aab62ee9acbd2f61aa2c279df36eaa025479bcb8b28030099b5202892f74484
-----------PROPOSED--------------- 13 BigNumber { value: "6" }
NEW PROOF REWARD 0.989249431387414707  TKO
NEW PROPOSER TKO BALANCE 100.0  TKO
NEW BLOCK FEE 1.240234375  TKO
AssertionError: expected false to equal true
    at JsonRpcProvider.<anonymous> (/Users/d/Projects/taiko/taiko-mono/packages/protocol/test/tokenomics/Tokenomics.test.ts:163:25)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (node:internal/process/task_queues:96:5) {
  showDiff: true,
  actual: false,
  expected: true,
  operator: 'strictEqual'
}
    ✔ expects the blockFee to go be 0 when no periods have passed

  3 passing (34s)

Tests seem to pass, but there are assertion errors. Please take a look.


@pchasco Technically, SQLite allows creating indexes on expression (aka. JSON_EXTRACT(...)), so it is possible, but managing indexes from the Admin UI will be handled as part of issue https://github.com/pocketbase/pocketbase/issues/345 and https://github.com/pocketbase/pocketbase/issues/544 (this will be after v0.8.0 release since it already comes with a lot of changes).

    @pchasco Technically, SQLite allows creating indexes on expression (aka. `JSON_EXTRACT(...)`), so it is possible, but managing indexes from the Admin UI will be handled as part of issue https://github.com/pocketbase/pocketbase/issues/345 and https://github.com/pocketbase/pocketbase/issues/544 (this will be after v0.8.0 release since it already comes with a lot of changes).

Originally posted by @ganigeorgiev in https://github.com/pocketbase/pocketbase/issues/423#issuecomment-1258338542

Please don't create issues like that.


Supplybots interact with the environment as if they are huminoid

Description
Supplybots slip on puddles and can be shocked by electrified gates. They will stutter when they are shocked.
They should act more like borgs do. Be immune to slipping and not get shocked.

This should be closed no right?


Kalideo Package Issue

The dependency "kaleido==0.0.3" is not available for macos and causing "df2img" library to be unusable. Should we consider bumping it ?

@jaskirat8
There are issues with kaleido for some time now. What I figured out is that the latest kaleido version is not compatible with plotly (the charting backend used in df2img) anymore.
For Windows machines, kaleido==0.1.0.post1 is working. For Linux, you need to downgrade to kaleido==0.0.3. That is, I previously put the lowest version into pyproject.toml.
Now I changed the required kaleido version in the pyproject.toml file depending on the operating system. As I don't have any MacOS at hand to fully test it, I am wondering if you can clone the repo to your local machine and check out the new branch update_kaleido? If all pytest unit tests pass, everything will be fine and I'll merge it into main.


Add option to generator for skippable fields

Add a configuration object to any struct::read or fill methods, with a boolean per skippable field
Adjust generated match statements, for example

match last_field_id {
    ...
    3 => if !config.skip_meta_data {
        self.meta_data.fill_field(input, field_type)?;
    }

The config would have to be a generic parameter on the CompactThriftInput trait. That is a bit annoying since that parameter would be unused by all the implementations on standard types, and would cause additional code generation during monomorphization for different config types.


Feature: Remember used tail numbers

Add a means of tracking what tail numbers have been used on which types of aircraft.
I'm thinking this would be a simple list with a button that effectively auto-populates the field to create a new tail number and submits the change.

Making some progress and should have this released soon. Here's a sneak peek!


Fix bug breaking multiple DVGeos for MPhys

Purpose
A small change introduced to DVGeo with how DV names were handled wasn't propagated to the MPhys wrapper. This change was to append the DVGeo name to the DV name when a name is present, which mostly only happens when you have multiple DVGeos to keep track of. MPhys wasn't expecting this full name so it wasn't accumulating the derivatives and they were all 0. Try this one cool trick to get 0-1s in one iteration!
I also cleaned up some random duplicate code and simplified the handling of child DVGeos in MPhys
Expected time until merged
This isn't urgent, likely no one else has this use case
Type of change

[x] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (non-backwards-compatible fix or feature)
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no API changes)
[ ] Documentation update
[ ] Maintenance update
[ ] Other (please describe)

Testing
Creating two DVGeo objects (or just naming one) leads to immediate 0-1s. Maybe someone with MPhys scripts (especially using child DVGeos) should run using this to make sure I didn't miss anything?
Checklist

[ ] I have run flake8 and black to make sure the Python code adheres to PEP-8 and is consistently formatted
[ ] I have formatted the Fortran code with fprettify or C/C++ code with clang-format as applicable
[ ] I have run unit and regression tests which pass locally with my changes
[ ] I have added new tests that prove my fix is effective or that my feature works **
[ ] I have added necessary documentation

** is it time to talk about how we can implement tests for our MPhys wrappers

@eytanadler can you check that this runs on your MPhys case with child DVGeos?

@eytanadler can you check that this runs on your MPhys case with child DVGeos?

It seems to work for my case

@mdolab/pygeo_maintainers this is ready to merge, but I don't have the permissions.  Can one of you take care of it?


[FEATURE] Add Copyright Year to Footer

Description
The footer should display the current year dynamically, ensuring it updates automatically each year.
On normal screens:

For smaller screens:

implementing as dynamic copyright year, hence it will change accordingly.
@FrancescoXX please look into this and assign it to me.
Thanks

hey i did not realize i pushed it to main without a making a separate branch... can you look into it? @FrancescoXX


modify titles and subtitles

Codecov Report
Attention: 5 lines in your changes are missing coverage. Please review.

Comparison is base (5ad92a6) 52.98% compared to head (6dcb61f) 52.98%.
Report is 8 commits behind head on dev.

Files
Patch %
Lines

...ions_widgets/most_severe_accidents_table_widget.py
0.00%
3 Missing :warning:

...ment_widgets/accident_count_by_day_night_widget.py
0.00%
1 Missing :warning:

...nt_widgets/accident_count_by_driver_type_widget.py
0.00%
1 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##              dev    #2505   +/-   ##
=======================================
  Coverage   52.98%   52.98%
=======================================
  Files         117      117
  Lines        9645     9645
=======================================
  Hits         5110     5110
  Misses       4535     4535

Flag
Coverage Δ

unittests
52.98% <16.66%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

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


feat(randomBytes): adding support to generate different bytes via RngCore

 fixes #8805
Motivation

Solution

vm.randomBytes already exists

@DaniPopes yes, but we need new randomBytes that works exactly like rng.fill_bytes and doesn't generate random U256


What does gt_zero do in resize_label_image()?

In inputs/kitti_seg_input.py there is a function for resizing the image and its corresponding gt_image. What is the purpose of gt_zero here? And what is the purpose of dividing the resized image pixels by 255?
def resize_label_image(image, gt_image, image_height, image_width):
    image = scipy.misc.imresize(image, size=(image_height, image_width),
                                interp='cubic')
    shape = gt_image.shape
    gt_zero = np.zeros([shape[0], shape[1], 1])
    gt_image = np.concatenate((gt_image, gt_zero), axis=2)
    gt_image = scipy.misc.imresize(gt_image, size=(image_height, image_width),
                                   interp='nearest')
    gt_image = gt_image[:, :, 0:2]/255

    return image, gt_image

I want to adapt this function to the multi-class case, but it wasn't enough to change the line to:
gt_image = gt_image[:, :, :-1]/255

So I must be misunderstanding something.

What is the purpose of gt_zero here?

scipy.misc.imresize requires the input to have one, three or four channel. gt_image has two channels. So gt_zero is used to pad the image.

And what is the purpose of dividing the resized image pixels by 255

The input gt_image consists of values 0 and 1. scipy.misc.imresize however converts this to 0 and 255. This line brings the labels back into the desired scale.

I want to adapt this function to the multi-class case

You will need to slice the gt_image into tensors having only one, three or four channels (in order to use  scipy.misc.imresize). You could also try using this function with method=“nearest”.

FYI: Karpathy is not happy about how scipy.misc.imresize magically changes image values eather:
https://github.com/scipy/scipy/issues/4458#issuecomment-269067103

Thank you so much! Your answers provided a lot of insight into the issue. My code is running as expected now.


Test both SSL and cleartext

This adds the tests for #2429.

Diff against #2754: https://github.com/jcanizales/grpc/compare/support-test-certificates...jcanizales:test-ssl-too?expand=1

@DavidPhillipOster: This pull request adds the tests for the feature you just reviewed. It's small enough that one can just look at the aggregated diffs of its commits.
We already had an InteropTests : XCTestCase class that run tests against a local non-SSL server. This makes that class query a class method for the server address. It then adds a InteropTestsLocalSSL : InteropTests that returns a different address (to a locally-running SSL server), and configures that address with the test SSL parameters the server requires.

LGTM


Battle simulation Abilities Cloud Nine should still display status of the weather

When I run npm test, this happens:
1) Battle simulation Abilities Cloud Nine should still display status of the weather:
Error: timeout of 2000ms exceeded. Ensure the done() callback is being called in this test.

Relevant code

Is this already fixed? I didn't see this message when running npm test.

I also haven't found a way to recreate this. Closing.


Iterator is invalidated after erase (Possible crash or corruption if reused)

I noticed at https://github.com/mohabouje/WinToast/blob/master/src/wintoastlib.cpp#L794
The _buffer iterator is reused after erase(). According to C++ Reference and CPlusPlus webpage:
https://en.cppreference.com/w/cpp/container/map/erase
"References and iterators to the erased elements are invalidated. Other references and iterators are not affected."
https://cplusplus.com/reference/map/map/erase/
"Iterators, pointers and references referring to elements removed by the function are invalidated."
After the iterator is invalidated, it must not be used again. The iterator has to be assigned a fresh iterator from begin() again.

I don't understand the issue correctly. That specific line is a typical pattern to iterate and remove elements from standard containers. The method std::map::erase returns a valid iterator according to the standard:
1-3) Iterator following the last removed element.

The cppreference documentation shows an example of this same pattern:
#include <map>
#include <iostream>

int main()
{
    [std::map](https://en.cppreference.com/w/cpp/container/map)<int, [std::string](https://en.cppreference.com/w/cpp/string/basic_string)> c =
    {
        {1, "one" }, {2, "two" }, {3, "three"},
        {4, "four"}, {5, "five"}, {6, "six"  }
    };

    // erase all odd numbers from c
    for (auto it = c.begin(); it != c.end();)
    {
        if (it->first % 2 != 0)
            it = c.erase(it);
        else
            ++it;
    }

    for (auto& p : c)
        [std::cout](https://en.cppreference.com/w/cpp/io/cout) << p.second << ' ';
}


chore(main): release 0.6.1

:robot: I have created a release beep boop
0.6.1 (2023-12-14)
Bug Fixes

document the operator and ident constructors (#24) (329fa2c)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/nfejzic/alemat/releases/tag/v0.6.1 :sunflower:


Don't create extra models in the db when passing association overrides to create

This addresses #1298. Hope this change works for you.

Thank you!


Add type definitions and use correct AsyncStorage package

Hi,
I made some type definitions for this package in a recent project and thought you might find them useful. They have worked well for my use cases but I doubt everything is covered – perhaps it's best to treat them as a first attempt! 😄
I've also updated the project to use the @react-native-async-storage/async-storage package as this functionality has been deprecated from the React Native module.
Cheers!

Hi @tjelen, this PR will really benefit our build + dev experience, possible to have a look?  Thanks!

Hi @etemadiehs, thanks for the reminder and sorry for the delay! I'll try to review it as soon as possible.

Looks good, thank you very much!


[Guide] Activate delegated harvesting

Create a step-by-step guide to activate/deactivate remote harvesting.

I can take this one

@kyleqchain Updated the description with some links.
You will see that the SDK function to enable delegated harvesting is not implemented yet. The guide can still be written, reviewing if the code proposed works or needs some minor changes.

@kyleqchain The latest SDK version enables to send AccountLinkTransactions.


Anyway to disable this?

 Is that what you are referring to?


unsupported operand type(s)

I try to convert TridentNet to engine, but I have an error:
load checkpoint from local path: /home/ariel/mmdetection2/tridentnet/epoch_33.pth
can't find wrap module for type:<class 'mmdet.models.detectors.trident_faster_rcnn.TridentFasterRCNN'>, use <class 'mmdet2trt.models.detectors.two_stage.TwoStageDetectorWraper'> instead.
can't find wrap module for type:<class 'mmdet.models.backbones.trident_resnet.TridentResNet'>, use <class 'mmdet2trt.models.backbones.base_backbone.BaseBackboneWraper'> instead.
/home/ariel/anaconda3/envs/mim/lib/python3.7/site-packages/mmdet/models/dense_heads/anchor_head.py:123: UserWarning: DeprecationWarning: anchor_generator is deprecated, please use "prior_generator" instead
warnings.warn('DeprecationWarning: anchor_generator is deprecated, '
can't find wrap module for type:<class 'mmdet.models.roi_heads.trident_roi_head.TridentRoIHead'>, use <class 'mmdet2trt.models.roi_heads.standard_roi_head.StandardRoIHeadWraper'> instead.
can't find wrap module for type:<class 'mmdet.models.roi_heads.bbox_heads.bbox_head.BBoxHead'>, use None instead.
[02/23/2022-16:32:58] [TRT] [I] [MemUsageChange] Init CUDA: CPU +174, GPU +0, now: CPU 1724, GPU 1158 (MiB)
[02/23/2022-16:32:58] [TRT] [I] [MemUsageSnapshot] Begin constructing builder kernel library: CPU 1724 MiB, GPU 1158 MiB
[02/23/2022-16:32:58] [TRT] [I] [MemUsageSnapshot] End constructing builder kernel library: CPU 1785 MiB, GPU 1158 MiB
Traceback (most recent call last):
File "convert.py", line 15, in
trt_model = mmdet2trt(cfg_path, weight_path, fp16_mode=True,device= 'cuda:0')#opt_shape_param=opt_shape_param,max_workspace_size=max_workspace_size
File "/home/ariel/mmdetection-to-tensorrt/mmdet2trt/mmdet2trt.py", line 151, in mmdet2trt
int8_calib_algorithm=int8_calib_algorithm)
File "/home/ariel/torch2trt_dynamic/torch2trt_dynamic/torch2trt_dynamic.py", line 527, in torch2trt_dynamic
outputs = module(*inputs)
File "/home/ariel/anaconda3/envs/mim/lib/python3.7/site-packages/torch/nn/modules/module.py", line 1102, in _call_impl
return forward_call(*input, **kwargs)
File "/home/ariel/mmdetection-to-tensorrt/mmdet2trt/models/detectors/two_stage.py", line 47, in forward
feat = self.extract_feat(x)
File "/home/ariel/mmdetection-to-tensorrt/mmdet2trt/models/detectors/two_stage.py", line 38, in extract_feat
x = self.backbone_wraper(img)
File "/home/ariel/anaconda3/envs/mim/lib/python3.7/site-packages/torch/nn/modules/module.py", line 1102, in _call_impl
return forward_call(*input, **kwargs)
File "/home/ariel/mmdetection-to-tensorrt/mmdet2trt/models/backbones/base_backbone.py", line 22, in forward
return self.module(*args, **kwargs)
File "/home/ariel/anaconda3/envs/mim/lib/python3.7/site-packages/torch/nn/modules/module.py", line 1102, in _call_impl
return forward_call(*input, **kwargs)
File "/home/ariel/anaconda3/envs/mim/lib/python3.7/site-packages/mmdet/models/backbones/resnet.py", line 643, in forward
x = res_layer(x)
File "/home/ariel/anaconda3/envs/mim/lib/python3.7/site-packages/torch/nn/modules/module.py", line 1102, in _call_impl
return forward_call(*input, **kwargs)
File "/home/ariel/anaconda3/envs/mim/lib/python3.7/site-packages/torch/nn/modules/container.py", line 141, in forward
input = module(input)
File "/home/ariel/anaconda3/envs/mim/lib/python3.7/site-packages/torch/nn/modules/module.py", line 1102, in _call_impl
return forward_call(*input, **kwargs)
File "/home/ariel/anaconda3/envs/mim/lib/python3.7/site-packages/mmdet/models/backbones/trident_resnet.py", line 174, in forward
out = _inner_forward(x)
File "/home/ariel/anaconda3/envs/mim/lib/python3.7/site-packages/mmdet/models/backbones/trident_resnet.py", line 150, in _inner_forward
out = self.conv2(out)
File "/home/ariel/anaconda3/envs/mim/lib/python3.7/site-packages/torch/nn/modules/module.py", line 1102, in _call_impl
return forward_call(*input, **kwargs)
File "/home/ariel/anaconda3/envs/mim/lib/python3.7/site-packages/mmdet/models/backbones/trident_resnet.py", line 85, in forward
self.dilations[self.test_branch_idx])
File "/home/ariel/torch2trt_dynamic/torch2trt_dynamic/torch2trt_dynamic.py", line 319, in wrapper
converter'converter'
File "/home/ariel/torch2trt_dynamic/torch2trt_dynamic/converters/conv2d.py", line 30, in convert_conv2d
bias=need_bias)
File "/home/ariel/anaconda3/envs/mim/lib/python3.7/site-packages/torch/nn/modules/conv.py", line 435, in init
False, _pair(0), groups, bias, padding_mode, **factory_kwargs)
File "/home/ariel/anaconda3/envs/mim/lib/python3.7/site-packages/torch/nn/modules/conv.py", line 83, in init
if in_channels % groups != 0:
TypeError: unsupported operand type(s) for %: 'int' and 'NoneType
How can I fix it?

TridentNet has not been supported yet.


consider deleting old statements

Reticketing from @mattbk at https://github.com/gratipay/gratipay.com/issues/3556#issuecomment-121306989:

[I]t's confusing to not be able to give money to a person, especially when I can see a profile that may still (post 1.0) explain what this person is doing and where contributions will be used.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

An update to this: I don't see any giving/receiving numbers anywhere but on the community pages now (e.g., https://gratipay.com/for/javascript/).

Or turn them off in the UI but leave them around for people to salvage for parts later, as we did with the old Team form fields (#3694).

Haven't seen much traffic on this ticket. Still worth considering, @mattbk?

Closing. The confusion between participants and projects is better addressed on https://github.com/gratipay/gratipay.com/issues/3852.


fix(runtime-core): skip getChildRoot if patchFlag equals -1

close #3133

Hi, I close this one because it has been fixed, sorry I forgot it was fixed by me. see https://github.com/vuejs/vue-next/pull/2750


update readme

There is no documentation is wriiten as how to launch this project on local system (I mean  localhost3030 or 8080).
Therefore I want to add this npm i and npm start into the readme.
So please Assign me this issue, So that I could add it into readme

There is no documentation is wriiten as how to launch this project on local system (I mean localhost3030 or 8080).
Therefore I want to add this npm i and npm start into the readme.
So please Assign me this issue, So that I could add it into readme


Add NewInstancesProtectedFromScaleIn: true to the ASG

We continue to experience customer reports of a race condition in the ASG which spontaneously replaces terminating instances only to kill a random instance immediately afterwards. We previously observed the addition of Cooldown: 60 fixing this but that appears to have been an incomplete fix.
This approach was suggested in Slack. I have tested that it still allows instances to self-terminate using the aws autoscaling terminate-instance-in-auto-scaling-group but the proof will be whether it successfully prevents the ASG from terminating an instance during scale-in 🤔

Sep 20 04:20:54 ip-10-0-2-101.ec2.internal buildkite-agent[4454]: 2021-09-20 04:20:54 INFO   buildkite-scaleinprotection-i-00102c6bcb2e28a9c-1 All agents have been idle for 600 seconds. Disconnecting...
Sep 20 04:20:54 ip-10-0-2-101.ec2.internal buildkite-agent[4454]: 2021-09-20 04:20:54 INFO   buildkite-scaleinprotection-i-00102c6bcb2e28a9c-1 Disconnecting...
Sep 20 04:20:54 ip-10-0-2-101.ec2.internal terminate-instance[4784]: sleeping for 10 seconds before terminating instance to allow agent logs to drain to cloudwatch...
Sep 20 04:21:04 ip-10-0-2-101.ec2.internal terminate-instance[4784]: requesting instance termination...
Sep 20 04:21:05 ip-10-0-2-101.ec2.internal terminate-instance[4784]: {
Sep 20 04:21:05 ip-10-0-2-101.ec2.internal terminate-instance[4784]: "Activity": {
Sep 20 04:21:05 ip-10-0-2-101.ec2.internal terminate-instance[4784]: "Description": "Terminating EC2 instance: i-00102c6bcb2e28a9c",
Sep 20 04:21:05 ip-10-0-2-101.ec2.internal terminate-instance[4784]: "AutoScalingGroupName": "buildkite-scaleinprotection-AgentAutoScaleGroup-63TU3ILVSIGI",
Sep 20 04:21:05 ip-10-0-2-101.ec2.internal terminate-instance[4784]: "ActivityId": "56a5f005-be8a-2631-6d83-e67bb162b693",
Sep 20 04:21:05 ip-10-0-2-101.ec2.internal terminate-instance[4784]: "Details": "{\"Subnet ID\":\"subnet-088774992a7599844\",\"Availability Zone\":\"us-east-1b\"}",
Sep 20 04:21:05 ip-10-0-2-101.ec2.internal terminate-instance[4784]: "StartTime": "2021-09-20T04:21:05.801Z",
Sep 20 04:21:05 ip-10-0-2-101.ec2.internal terminate-instance[4784]: "Progress": 0,
Sep 20 04:21:05 ip-10-0-2-101.ec2.internal terminate-instance[4784]: "Cause": "At 2021-09-20T04:21:05Z instance i-00102c6bcb2e28a9c was taken out of service in response to a user request, shrinking the capacity from 10 to 9.",
Sep 20 04:21:05 ip-10-0-2-101.ec2.internal terminate-instance[4784]: "StatusCode": "InProgress"
Sep 20 04:21:05 ip-10-0-2-101.ec2.internal terminate-instance[4784]: }
Sep 20 04:21:05 ip-10-0-2-101.ec2.internal terminate-instance[4784]: }

Ah just looking around, maybe i'm in fact being re-bitten by https://github.com/buildkite/elastic-ci-stack-for-aws/issues/927?
In any case i'm not convinced that the instance protection thing is good for us.


Ivy use without decorator

I'm sorry for abusing the issues for a simple question. Maybe take this as a documentation request.
Is it correct that there is no way to use the operator without the decorator under Ivy?

Correct.


Removes unnecessarily trailing comma in README.md

I generally prefer to keep it unless I need to support old IEs


'/node_modules/.vite/deps/vuetify_lib.js?v=5b28369c' does not provide an export named Vjsf issue

I was using @koumoul/vjsf library in my project and recently I migrate from weback to vite , I am getting this issue that Vjsf library trying to resolve through vuetify resolver . Not able to find any solution for this
vite.config.js
import { createVuePlugin } from "vite-plugin-vue2"
import Components from "unplugin-vue-components/vite"
import { VuetifyResolver } from "unplugin-vue-components/resolvers"
import resolveExtensionVue from "vite-plugin-resolve-extension-vue"
// import vuetifyLoader from "vite-plugin-vuetify"

import path from "path"

/**
 * @type {import('vite').UserConfig}
 */
export default () => {
	// eslint-disable-next-line
	require("dotenv").config()
	return {
		resolve: {
			extensions: [".mjs", ".js", ".ts", ".jsx", ".tsx", ".json", ".vue"],
			alias: [
				{
					find: "@/",
					replacement: `${path.resolve(__dirname, "./src")}/`,
				},
				{
					find: "src/",
					replacement: `${path.resolve(__dirname, "./src")}/`,
				},
			],
		},
		// extensions: [".mjs", ".js", ".ts", ".jsx", ".tsx", ".json", ".vue"],
		plugins: [
			createVuePlugin(),
			resolveExtensionVue(),
			// vuetifyLoader({ autoImport: true }),
			Components({
				resolvers: [VuetifyResolver()],
			}),
		],
		server: {
			port: 8080,
		},
		define: {
			"process.env": process.env,
		},
	}
}

your resolvers defination contains VuetifyResolver only, so only VuetifyResolver will work.
According to Vuetify Resolver
export function VuetifyResolver(): ComponentResolver {
  return {
    type: 'component',
    resolve: (name: string) => {
      if (name.match(/^V[A-Z]/))
        return { name, from: 'vuetify/lib' }
    },
  }
}

Vjsf could not found in Vuetify lib => get this error
resolve process is the first matching one works
 async findComponent(name: string, type: 'component' | 'directive', excludePaths: string[] = []): Promise<ComponentInfo | undefined> {
    // resolve from fs
    let info = this._componentNameMap[name]
    if (info && !excludePaths.includes(info.from) && !excludePaths.includes(info.from.slice(1)))
      return info

    // custom resolvers
    for (const resolver of this.options.resolvers) {
      if (resolver.type !== type)
        continue

      const result = await resolver.resolve(name)
      if (result) {

so I think you could make your own resolver and put it as the first item
something like
vite.config.js
Components({
  resolvers: [
    (componentName) => {
      if (componentName.startsWith('Vjsf'))  //do not know the UI lib naming rule
        return { name: componentName, from: '@koumoul\vjsf\lib'}
    },
    VuetifyResolver()
  ],
})

hope it works

That worked for me. Thanks a lot!
I had to do couple minor fixes:

Capitalization: 'VJsf' instead of 'Vjsf'
Path: '@koumoul/vjsf' instead '@koumoul\vjsf\lib'


Add FastCopy

Adds FastCopy.
Microsoft Reviewers: Open in CodeFlow

 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.:x: auanasgheps sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.


web_path and web_port parameters read from wrong places in the config

https://github.com/praekelt/junebug/blob/develop/junebug/utils.py#L132 returns None for
{
  "type": "smpp",
  "amqp_queue": "queue",
  "config": {
    "web_path": "/api",
    "web_port": 8051,
  }
}

Instead I have to duplicate the info as a top level key in the config:
{
  "type": "smpp",
  "amqp_queue": "queue",
  "public_http": {
    "enabled": true,
    "web_path": "/api",
    "web_port": 8051
  },
  "config": {
    "web_path": "/api",
    "web_port": 8051,
  }
}

This seems odd?

I think that maybe it should be looking in properties['config']['web_path'] instead of properties['web_path'], but will have to investigate to make sure.

@smn @rudigiesler Ready for review.
Probably needs some careful reading given that most of the config keys at all levels start with web_. :/

:+1: from me, thanks for taking care of this. I'll update my configs to reflect this once released.

:+1: from me too


Lighthouse test

This improves the lighthouse test

I'm not sure if chrome-aws-lambda will work in Circle CI since its probably not AWS Lambda.

Did you mean to add chrome-aws-lambda as a dependency?

Codecov Report

Merging #3 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master       #3   +/-   ##
=======================================
  Coverage   89.44%   89.44%
=======================================
  Files          10       10
  Lines         938      938
=======================================
  Hits          839      839
  Misses         99       99

Continue to review full report at Codecov.

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

It worked!?

Oh right, because this doesn't test that the code is executable.

Oh right, because this doesn't test that the code is executable.

Can you clarify?

(the integration tests are very much executed... try adding a logger into the js file)

@guybedford I don't see the console.log('success')

@styfle yes it's outputting an error -

Error: Chromium revision is not downloaded. Run "npm install" or "yarn install".

I can't think of a way to add proper support here since chrome-aws-lambda is the chrome binaries compiled specifically for AWS Lambda.
Should we pursue this or close in favor of https://github.com/zeit/now-builders/pull/731 ??

Agreed if this is lambda specific then let's close this one.