Legion: random out of bounds access in CUDA kernel

I have a task that uses some DeferredBuffers and that used to work fine until 99431fe48e9f8fb05d86cf34d9d211fd391d9567. If the same task is executed with cuda-memcheck on any commit after dc577dc427fc0d2761944f44effbf44ca32d8fa8 (which I think is the merge of eager-pool), a random out of bound access is detected by cuda-memcheck at an assignment to a write-only FieldAccessor. The point that is accessed is within the bounds of the region requirement and sometimes the code executes correctly.
I am working on a small reproducer but please feel free to contact me in case there are experiments that I can directly run in my code.

Adding @magnatelee and @lightsighter .  Did the final version of eager pool stuff use instances in Realm memories or direct calls to cudaMalloc?

All eager pools use Realm instances.

Hmm...  problems with Realm instances shouldn't really ever result in an invalid address - the memory backing the instances is all allocated at startup.  @lightsighter can you suggest anything to try to get closer to the root cause?

How many dimensions in the shape of the deferred buffer? I'm betting there is a problem with the affine mapping from N-D down to the offset assigned to the deferred buffer in the 1-D eager buffer instance.

@magnatelee do we have any tests for N-D deferred buffers with N > 1?

It is defined on a 3d index space composed by the union of up to three rectangles

if it was an instance, it would have needed to be mapped with a MultiAffineAccessor

@lightsighter I don't think we have any such tests.

@magnatelee How do you ensure that N-D deferred instances are mapped down to the realm instance correctly?

@lightsighter I'm relying on bytes_used in the realm layout being correct here, so if the layout is lying about the size, the allocation can be smaller than it needs to be. I didn't touch the part where the realm layout is constructed for a deferred buffer (e.g., https://gitlab.com/StanfordLegion/legion/-/blob/control_replication/runtime/legion/legion.inl#L15584-15600).

Ok, that wasn't what I was talking about. Looking at the code, it looks like you are making a Realm external instance on top of an existing normal Realm instance (e.g. they alias memory), with the external instance having an N-D layout. @streichler can you think of any reasons that would be problematic?
@mariodirenzo Can you report the exact error from cuda-memcheck. Are you sure that it is an out-of-bounds access and not a misaligned access?

Having an external instance alias a Realm-allocated instance ought to be fine from a address computation perspective.  Realm won't detect the aliasing, so it's up to higher-level code to ensure that any potential races between the two different access paths are avoided.
How are accesses to this external instance being performed?  I don't believe a MultiAffineAccessor works properly in device code yet, but that should lead to a consistent failure rather than anything intermittent.

Deferred buffers always make Realm::AffineAccessors right now. They should also be making layouts for the external instance consistent with that as well since we're calling Realm::InstanceLayoutGeneric::choose_instance_layout which should compute a convex hull bounding box. If anything, that should always over approximate the memory required.
@mariodirenzo Can you also turn on the bounds checks on the deferred accessor? (Last template parameter argument, or just compile with -DBOUNDS_CHECKS)

@mariodirenzo Can you report the exact error from cuda-memcheck. Are you sure that it is an out-of-bounds access and not a misaligned access?

The error looks like this
========= CUDA-MEMCHECK
========= Invalid __global__ read of size 8
=========     at 0x00003e90 in /scratch/cfd/direnzo/htr/src/prometeo_metric.cu:88:void ComputeMetrics_kernel<direction=0>(Legion::DeferredBuffer<double, int=3, __int64, bool=0>, Legion::FieldAccessor<legion_privilege_mode_t=268435458, double, int=3, __int64, Realm::AffineAccessor<double, int=3, __int64>, bool=0>, Legion::FieldAccessor<legion_privilege_mode_t=268435458, double, int=3, __int64, Realm::AffineAccessor<double, int=3, __int64>, bool=0>, Legion::FieldAccessor<legion_privilege_mode_t=268435458, double, int=3, __int64, Realm::AffineAccessor<double, int=3, __int64>, bool=0>, Legion::FieldAccessor<legion_privilege_mode_t, MyArray<double, int=3>, int=3, __int64, Realm::AffineAccessor<MyArray<double, int=3>, int=3, __int64>, bool=0>, Legion::FieldAccessor<legion_privilege_mode_t, int, int=3, __int64, Realm::AffineAccessor<int, int=3, __int64>, bool=0>, Realm::Rect<int=3, __int64>, Realm::Rect<int=3, __int64>, double, __int64, __int64, __int64, __int64)
=========     by thread (0,0,0) in block (0,0,1)
=========     Address 0x2b69fffffe78 is out of bounds
=========     Device Frame:/scratch/cfd/direnzo/htr/src/prometeo_metric.cu:88:void ComputeMetrics_kernel<direction=0>(Legion::DeferredBuffer<double, int=3, __int64, bool=0>, Legion::FieldAccessor<legion_privilege_mode_t=268435458, double, int=3, __int64, Realm::AffineAccessor<double, int=3, __int64>, bool=0>, Legion::FieldAccessor<legion_privilege_mode_t=268435458, double, int=3, __int64, Realm::AffineAccessor<double, int=3, __int64>, bool=0>, Legion::FieldAccessor<legion_privilege_mode_t=268435458, double, int=3, __int64, Realm::AffineAccessor<double, int=3, __int64>, bool=0>, Legion::FieldAccessor<legion_privilege_mode_t, MyArray<double, int=3>, int=3, __int64, Realm::AffineAccessor<MyArray<double, int=3>, int=3, __int64>, bool=0>, Legion::FieldAccessor<legion_privilege_mode_t, int, int=3, __int64, Realm::AffineAccessor<int, int=3, __int64>, bool=0>, Realm::Rect<int=3, __int64>, Realm::Rect<int=3, __int64>, double, __int64, __int64, __int64, __int64) (void ComputeMetrics_kernel<direction=0>(Legion::DeferredBuffer<double, int=3, __in
=========     Saved host backtrace up to driver entry point at kernel launch time
=========     Host Frame:/lib64/libcuda.so.1 (cuLaunchKernel + 0x346) [0x2c4fd6]
=========     Host Frame:/scratch/cfd/direnzo/legion/bindings/regent/libregent.so [0x30029d8]
=========     Host Frame:/scratch/cfd/direnzo/legion/bindings/regent/libregent.so (cudaLaunchKernel + 0x60) [0x301e61a]
=========     Host Frame:/scratch/cfd/direnzo/htr/src/prometeo_AirMix.exec [0x48785d]
=========     Host Frame:/scratch/cfd/direnzo/htr/src/prometeo_AirMix.exec [0x4860f3]
=========     Host Frame:/scratch/cfd/direnzo/htr/src/prometeo_AirMix.exec [0x486186]
=========     Host Frame:/scratch/cfd/direnzo/htr/src/prometeo_AirMix.exec [0x489d33]
=========     Host Frame:/scratch/cfd/direnzo/htr/src/prometeo_AirMix.exec [0x4840c2]
=========     Host Frame:/scratch/cfd/direnzo/htr/src/prometeo_AirMix.exec [0x4340d2]
=========     Host Frame:/scratch/cfd/direnzo/htr/src/prometeo_AirMix.exec [0x4356d1]
=========     Host Frame:/scratch/cfd/direnzo/legion/bindings/regent/libregent.so [0x2f0982c]
=========     Host Frame:/scratch/cfd/direnzo/legion/bindings/regent/libregent.so [0x2d50a5f]
=========     Host Frame:/scratch/cfd/direnzo/legion/bindings/regent/libregent.so [0x2d54b0e]
=========     Host Frame:/scratch/cfd/direnzo/legion/bindings/regent/libregent.so [0x301d86d]
=========     Host Frame:/scratch/cfd/direnzo/legion/bindings/regent/libregent.so [0x2d539ff]
=========     Host Frame:/scratch/cfd/direnzo/legion/bindings/regent/libregent.so [0x2d53ed0]
=========     Host Frame:/scratch/cfd/direnzo/legion/bindings/regent/libregent.so [0x2d5a504]
=========     Host Frame:/scratch/cfd/direnzo/legion/bindings/regent/libregent.so [0x2d2bbd1]
=========     Host Frame:/lib64/libpthread.so.0 [0x7dd5]
=========     Host Frame:/lib64/libc.so.6 (clone + 0x6d) [0xfdead]
=========
========= ERROR SUMMARY: 1 error

with '/scratch/cfd/direnzo/htr/src/prometeo_metric.cu:88' that looks like
m_e[p] = 1.0/(coord[p] - unwarpCoordinate<dir>(coord[pm1], width, -1, p, Fluid_bounds));

where m_e is a FieldAccessor (based on AffineAccessor) with write privileges and coord is a DeferredBuffer.
The errors disappears if the assignment is done though a temporary variable.

@mariodirenzo Can you also turn on the bounds checks on the deferred accessor? (Last template parameter argument, or just compile with -DBOUNDS_CHECKS)

It detects a series of out-of-bounds on the deferred buffer
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [1,0,0], thread: [0,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [1,0,0], thread: [1,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [1,0,0], thread: [2,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [1,0,0], thread: [3,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [1,0,0], thread: [4,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [1,0,0], thread: [5,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [1,0,0], thread: [6,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [1,0,0], thread: [7,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [1,0,0], thread: [8,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [1,0,0], thread: [9,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [1,0,0], thread: [10,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [1,0,0], thread: [11,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [1,0,0], thread: [12,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [1,0,0], thread: [13,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [1,0,0], thread: [14,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [1,0,0], thread: [15,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [1,0,0], thread: [16,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [1,0,0], thread: [17,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [0,0,0], thread: [0,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [0,0,0], thread: [1,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [0,0,0], thread: [2,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [0,0,0], thread: [3,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [0,0,0], thread: [4,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [0,0,0], thread: [5,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [0,0,0], thread: [6,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [0,0,0], thread: [7,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [0,0,0], thread: [8,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [0,0,0], thread: [9,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [0,0,0], thread: [10,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [0,0,0], thread: [11,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [0,0,0], thread: [12,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [0,0,0], thread: [13,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [0,0,0], thread: [14,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [0,0,0], thread: [15,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [0,0,0], thread: [16,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [0,0,0], thread: [17,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [0,0,0], thread: [18,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [0,0,0], thread: [19,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [0,0,0], thread: [20,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [0,0,0], thread: [21,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [0,0,0], thread: [22,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [0,0,0], thread: [23,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [0,0,0], thread: [24,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [0,0,0], thread: [25,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [0,0,0], thread: [26,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [0,0,0], thread: [27,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [0,0,0], thread: [28,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [0,0,0], thread: [29,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [0,0,0], thread: [30,0,0] Assertion `bounds.bounds.contains(p)` failed.
/scratch/cfd/direnzo/legion/runtime/legion/legion.inl:16968: T &Legion::DeferredBuffer<T, DIM, COORD_T, CHECK_BOUNDS>::operator[](const Realm::Point<DIM, COORD_T> &) const [with T = double, DIM = 3, COORD_T = long long, CHECK_BOUNDS = true]: block: [0,0,0], thread: [31,0,0] Assertion `bounds.bounds.contains(p)` failed.

From another log from Mario, I see two external instances allocated on the gpu:
[0 - 2b6a07c12800]  362.940119 {2}{inst}: creating new local instance:<PHONE_NUMBER>400005
[0 - 2b6a07c12800]  362.940202 {1}{inst}: allocation completed: inst=4000000000400005 offset=0
[0 - 2b6a07c12800]  362.940208 {2}{inst}: external instance created: inst=4000000000400005
[0 - 2b6a07c12800]  362.940216 {1}{inst}: external instance layout: inst=4000000000400005 layout=Layout(bytes=0, align=16, fields={0=0+0}, lists=[[<0,1,0>..<49,601,49>->affine(<240400,400,8>+18446744073709551216)]])
[0 - 2b6a07c12800]  362.955884 {2}{inst}: creating new local instance:<PHONE_NUMBER>400006
[0 - 2b6a07c12800]  362.955934 {1}{inst}: allocation completed: inst=4000000000400006 offset=12020000
[0 - 2b6a07c12800]  362.955940 {2}{inst}: external instance created: inst=4000000000400006
[0 - 2b6a07c12800]  362.955946 {1}{inst}: external instance layout: inst=4000000000400006 layout=Layout(bytes=0, align=16, fields={0=0+0}, lists=[[<0,0,0>..<49,600,49>->affine(<240400,400,8>+0)]])

Both of these appear to be suballocations from this instance:
[0 - 2b69d78a6800]  134.665829 {2}{inst}: creating new local instance:<PHONE_NUMBER>400000
[0 - 2b69d78a6800]  134.666177 {1}{inst}: instance layout: inst=4000000000400000 layout=Layout(bytes=2936012800, align=32, fields={0=0+0}, lists=[[<0>..<2936012799>->affine(<1>+0)]])
[0 - 2b69d78a6800]  134.666270 {1}{inst}: allocation completed: inst=4000000000400000 offset=0
[0 - 2b69d78a6800]  134.666277 {2}{inst}: instance created: inst=4000000000400000 bytes=2936012800 ready=0

I don't have logging for the base device pointer of gpu allocations (which is where the first byte of<PHONE_NUMBER>400000 would be), but the failing addresses start 400 bytes below a large-power-of-2 boundary:
=========     Address 0x2b91bffffe78 is out of bounds
=========     Address 0x2b91bffffe80 is out of bounds
=========     Address 0x2b91bffffe70 is out of bo...

which suggests that instance<PHONE_NUMBER>400005 is being accessed for points <0,0,0>... rather than starting at <0,1,0>
Another observation that is probably not related to the failure we're seeing, but might matter for performance later:  I see from the logs that these external instances are being created using C-style layout (i.e. DIM_Z fastest), while the mapper-created instances are all Fortran-style (i.e. DIM_X fastest), so if they get copied to a real field later, there's going to be a lot of transposing going on.

It is also weird that legion reports an out of bound access for threads that access points in the index space of the deferred buffer. For instance it reports the thread [0,0,0] of the block [0,0,0], which access the points (p.x=0 p.y=0 p.z=0) and (pm1.x=49 pm1.y=0 pm1.z=0) , which are inside the bounds of the rectangle (bnd.lo.x=0 bnd.lo.y=0 bnd.lo.z=0, bnd.hi.x=49 bnd.hi.y=601 bnd.hi.z=49) used to define the deferred buffer. (these data are obtained with aprintf in the failing kernel)

Ok, the fact that Legion is reporting a bounds check error is a strong indicator that this is an application bug.

which suggests that instance<PHONE_NUMBER>400005 is being accessed for points <0,0,0>... rather than starting at <0,1,0>

I would start here as Sean suggests. I don't think the rect that you are asking Legion to make create a deferred buffer for matches your expectations. It seems like the lower bound on the y-dimension starts at 1 and not 0.

The bug was in my code and it has been exposed by the new allocation of the DeferredBuffers. I'm sorry for the confusion


Debug impl of Fp outputs elements in Montgomery form.

This can trip up users. Should we change this?

@Pratyush Status on this? Just got pinged in Discord and curious as to your suggested approach.

The simplest thing to do would be to invoke into_bigint in the Debug impl


Docs

Make sure readme is up to date with all instructions.
Also record a video walk-through of the codebase explaining how the components work, for future reference.

Make sure we have documented our custom APIs and any nuances that make EVM GW different from other geth nodes.


Add logic to wait for HNC role propagation

Is there a related GitHub Issue?
No. There is a slack thread here though: https://cloudfoundry.slack.com/archives/C0297673ASK/p1646344103600849
What is this change about?

This is basically a workaround for the problem that HNC reports
readiness before it has completed role binding propagation. If HNC
fixes that (or we stop using it) this code would no longer be
necessary.
After a new SubNamespaceAnchor is ready, we wait until we have rights in
the namespace before returning OK.
For now, we test access by listing CFApps with exponential backoff. There might be a more appropriate resource type to use, or we may find a better resource type to test with later (e.g. CFSpace)

Does this PR introduce a breaking change?
No
Acceptance Steps

With a newly deployed environment
Run the following: cf co o && cf target -o o && cf create-space s && cf target -s s

This command should work without adding any additional delays between commands.

Tag your pair, your PM, and/or team
@gnovv @gcapizzi

@julian-hj please close #538 once this goes in!


Allow regexp replacement for markdown link insert default text

It would be super cool if the default link text wouldn't be text, but vscode#204371.
I could imagine that there is some markdown.defaultLinkText property:
"markdown.defaultLinkText": {
   "https://github.com/([a-zA-Z0-9]+)/([a-zA-Z0-9]+)/issues/([0-9]+)": "\1#\3",
}

Closing since this hasn't gotten much feedback since it was opened


Fix/35 throw if subdir not exist

Fixes: https://github.com/tiged/tiged/issues/35

I think I should write some test for this...

added test


Save new Whitehall attachments to Asset Manager

We'll want to update the AttachmentUploader to use the Whitehall::AssetManagerAndQuarantinedFileStorage storage engine so that we start saving attachments to Asset Manager.
We'll probably want to mark all attachments as draft initially to avoid serving anything that should be protected.

This was deployed to staging and production yesterday.
I can see assets in integration asset-manager that have been created since 11am yesterday and whose legacy_url_path matches /government/uploads/system/uploads/attachment_data/file. I'm confident these were uploaded from Whitehall to Asset Manager yesterday and are appearing in integration after the overnight data sync.
I've also tested the behaviour in integration by adding an attachment to a consultation and confirming that it appears in the Whitehall NFS mount and in the asset-manager database.
I think this is all done so I'm closing the issue.


Monero added to online store

Issue solved for https://github.com/monero-project/monero-site/issues/795 ?

You did it right @FatBirdie!

Yey :) thanks again @el00ruobuob !

You're very welcome


rl-2411: lib release notes

Just like last release and the one before, I'm adding release notes for lib.
Determined by listing commits since the initial 24.05 release:
git log e4df0129a73d91eca342c7313194654196f4c6aa..upstream/release-24.11 --no-merges -- lib

Things done

[x] Successfully built and checked the result of nix-build nixos/release.nix -A manualHTML.x86_64-linux

This work is funded by Tweag and Antithesis :sparkles:
Add a :+1: reaction to pull requests you find important.

Rebased to fix conflicts

Damnit, why did it fail‽

Oh because of the redirects

Backport: https://github.com/NixOS/nixpkgs/pull/360255


API Lab testing

e5f07b6e2a2afb35bc407313b919bd5998e89339 Reformated the test.py to pytest formatted unit tests.

I figured out how to do simple Postman requests mimicking the current API requests we have with Python Lab.

ae84795ba2832abc0d76236e17d646a3d46e3cb7, improved tests by using asserts to test the contents of the response from request methods.
f1a7e0ff13a954c69b98a85a13f0d4e782d9e4be, changed success codes to be accurate in testing.
9ac92ab9b8c98182dbfde1dc8dabaa5a9d99d57c, modify delete request message and test for it.

Did a pass through with Postman, this images definitely made tutorial user friendly.


Cleanup in org.matrix.androisdk.call

Pull Request Checklist

[x] Pull request is based on the develop branch
[x] Pull request updates CHANGES.rst
[x] Pull request includes a sign off

@bmarty this is in line with ecc314546c633fb22b24b93eb20c53456b2261cd to simplify the calls implementation.

Thanks @awesome-manuel ,
We will check this. After a first sight it seems correct, but I need to do more test.
Benoit

@bmarty any update on this?

Hi @awesome-manuel
I'm looking at your PR. Does it fixes some issue or is it just cleanup?

Hi @awesome-manuel
I'm looking at your PR. Does it fixes some issue or is it just cleanup?

This PR is just a cleanup. The only fix or workaround that seems to improve the situation is to remove the call to PeerConnectionFactory.dispose().

Ok, thanks.
It seems that commit 98cb1872da5f0815d9fe0930674c3ae77aac3927 has not been pushed to the PR. Is it intended?

98cb187 is just a preview and not completed yet, so it should go in a separate PR when it's ready.

Ok, thanks for quick answer :)


Blockchain started syncing then got 'Service bitcoind is not running' message

Debug report for 'Service bitcoind is not running' message
admin@raspberrypi:~ $ /home/admin/XXdebugLogs.sh | nc termbin.com 9999
tail: error reading '/mnt/hdd/lnd/logs/bitcoin/mainnet/lnd.log': Input/output error
nginx: [emerg] BIO_new_file("/mnt/hdd/app-data/nginx/tls.cert") failed (SSL: error:02001005:system library:fopen:Input/output error:fopen('/mnt/hdd/app-data/nginx/tls.cert','r') error:2006D002:BIO routines:BIO_new_file:system lib)
nginx: configuration file /etc/nginx/nginx.conf test failed
/home/admin/config.scripts/blitz.statusscan.sh: line 4: /mnt/hdd/raspiblitz.conf: Input/output error
/home/admin/config.scripts/blitz.ups.sh: line 4: /mnt/hdd/raspiblitz.conf: Input/output error
https://termbin.com/1u3g

seems your nginx is missing his tls.cert? you can try to repair in menu your certificates

@kbholden bitcoind AND lnd do not run correctly. Something went bad during install. If this is a fresh install I would recommend to start fresh: Format HDD/SSD on laptop and start again with fresh sd card image. If this is after an update: Shutdown and reboot with a fresh sd card again.

Pls close this.


Calendar not showing

Before it was working perfectly for me I have no Idea what caused the issue.

The plugins I have installed:

I'm sorry, I don't think I'll be able to debug this considering the number of plugins installed. I'd recommend https://github.com/chrisgrieser/obsidian-divide-and-conquer to help debug.


Delay highlighting

Initial build for issue 170
Now highlights intersections and lanes for cars, bikes and walking. That have spent over the threshold (30s) time waiting.
This is highlighted on the map, and colour coordinated for the severity of the delay
In addition it is also shown as hotspots on the timeline bar, with more information available when hovered upon.
Also contains some "fixes" for Canocilsing imports @dabreegster
Including:

sim/src/lib.rs
pub use crate::render
geom/src/spped
import trim_f64 in wrong place
widgetry/src/text.rs
use crate assets in wrong place

I regenerated the prebaked analytics data. montlake stayed the same size, and lakeslice increased from 61MB to 64MB -- that's a totally fine amount, nice! After we merge, I'll immediately followup with the uploaded data.
This pretty much LGTM, minus the build break. And if you can, run cargo +nightly fmt too, to deal with the slight import order difference. Next, I'm going to attempt some refactoring of info/trip.rs next to consolidate tooltips and all the different cases for trips (future, ongoing, cancelled, finished).

Thanks for the PR! Going to merge this now, and follow up with the new prebaked data, some cleanups, and a fix for the timeline indicator icon.


Example of "Web Deploy Parameters File"?

Can you provide an example of "Web Deploy Parameters File" in use, say to do a web.config transform to a specified configuration or otherwise ensure that the web.config has the correct values for a target environment (e.g., if the target environment is "production" then the correct connection strings are in the web.config file).
This is all I see under the topic. It does not provide sufficient explanation to use this field, as I am doing this for the first time.

"Web Deploy Parameters File: The parameter file is used to override the default settings in the web deploy zip package file like, the IIS Web application name or the database connection string. This helps in having a single package that can be deployed across dev, test, staging, and production, with a specific parameter file for each environment. The parameter takes in the location of the parameter file on the target machines or on a UNC path."

Thank you. This statement says it all:  "But this feature is not supported
for WinRM based web app deploy task."
I was hoping that WinRM would have an option that makes my life easier. At
present, I do have another method that does work correctly, but there are
more steps involved.
Henry Wyckoff
<EMAIL_ADDRESS>On Thu, Apr 5, 2018 at 2:54 AM, Ajay Kumar Yadav<EMAIL_ADDRESS>wrote:

You can achieve substitution of values across multiple connection strings
using XML variable substitution.
Variable substiution and transformation
https://docs.microsoft.com/en-us/vsts/build-release/tasks/transforms-variable-substitution?view=vsts
But this feature is not supported for WinRM based web app deploy task.
I would suggest you here to configure deployment group
https://docs.microsoft.com/en-us/vsts/build-release/concepts/definitions/release/deployment-groups/?view=vsts
and use "IIS Web App Deploy" task which supports variable substitution.
Let me know if you face any issue for configuration of deployment group.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vsts-rm-extensions/issues/405#issuecomment-378882456,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ARLhUAyVY5m0YEjkSaZ5oGZAD01urlVfks5tlenXgaJpZM4TF5ig
.

For future references, by the looks of it "IIS Web App Deploy" is deprecated in TFS 2018. WinRM task does offer similar properties, e.g. Web Deploy Parameter File and Override Parameters, which are passed down the line to the web deploy executable.
In case you are having trouble with the format of the file, I can highly recommend using the following VS extension:  (Web Deploy Parameters Toolkit)


Bug: diff doesn't update current buffer unless :e or navigating to other buffer and reenter

Not sure if this is rooted in lualine or specific to vim config but it should update in realtime, right?

require('lualine').setup{
  options = {
    theme = 'base16_tomorrow_night',
    section_separators = {'', ''},
    component_separators = {''},
    disabled_filetypes = {},
    icons_enabled = true,
  },
  sections = {
    lualine_a = { {'mode', upper = true} },
    lualine_b = { {'branch', icon = ''}, {'diff'} },
    lualine_c = { {'filename', file_status = false, path = 1} },
    lualine_x = { 'filetype' },
    lualine_y = { 'ConflictedVersion', 'progress' },
    lualine_z = { 'location' },
  },
  inactive_sections = {
    lualine_a = {  },
    lualine_b = {  },
    lualine_c = { 'filename' },
    lualine_x = { 'location' },
    lualine_y = { 'ConflictedVersion' },
    lualine_z = {  }
  },
  extensions = { 'fzf', 'fugitive' }
}

Diff count is showing file diff not buffer diff . It'll update when you save the changes to the file .


When db don't support comments, then show warning instead throw excep…

Q
A

Is bugfix?
?

New feature?
?

Breaks BC?
?

Tests pass?
yes

Fixed issues
#11841

Migration
<?php

use yii\db\Migration;

class m160705_104733_test_sqlite extends Migration
{
    public function up()
    {
                $this->createTable('some', [
                        'column' => $this->string()->comment('hay hay'),
                ]);
    }

    public function down()
    {
        echo "m160705_104733_test_sqlite cannot be reverted.\n";

        return false;
    }
}

Before
Yii Migration Tool (based on Yii v2.0.9-dev)

Creating migration history table "migration"...Done.
Total 1 new migration to be applied:
	m160705_104733_test_sqlite

Apply the above migration? (yes|no) [no]:yes
*** applying m160705_104733_test_sqlite
    > create table some ...
Exception 'yii\base\UnknownMethodException' with message 'Calling unknown method: m160705_104733_test_sqlite::db()'

in /var/www/at.anikanov.me/yiihack/web/vendor/yiisoft/yii2/base/Component.php:285

Stack trace:
...

After
Yii Migration Tool (based on Yii v2.0.9-dev)

Creating migration history table "migration"...Done.
Total 1 new migration to be applied:
	m160705_104733_test_sqlite

Apply the above migration? (yes|no) [no]:yes
*** applying m160705_104733_test_sqlite
    > create table some ...
    > sqlite is not support comments
    > done (time: 0.011s)
*** applied m160705_104733_test_sqlite (time: 0.032s)

1 migration was applied.

Migrated up successfully.

I don't think this can be merged as-is, it contains some files that shouldn't be in Yii core.

@SamMousa Sorry, my mistake.
Fixed.


cmd/go2go: better error message for failing type inference

What version of Go are you using (go version)?

$ go version
go version devel +0a030888da Sat Jun 20 04:46:40 2020 +0000 linux/amd64

What did you do?
I felt upon this while toying with go2go.
This is the minimal reproducible example illustrating what I think is a bug/problem.
type (
	iterable(type T)   interface{} // empty constraint
	binaryTree(type T) struct{}
)

func forEach(type T)(t iterable(T)) {}

func main() {
	v := binaryTree(int){}

	forEach(v) // error: type binaryTree(int) of v does not match iterable(T)
	// forEach(int)(v) // ok
}

https://go2goplay.golang.org/p/TBApH4WbSxk
What did you expect to see?
First, I think  int should not have to be provided explicitly since it can be inferred from v.
Also v does match iterable(T) since iterable is the empty constraint.

Thanks.  This does seem like a problem with the type checker.

Since no explicit type argument is passed to forEach, it must be inferred. But the (underlying) type of v is struct{} and the underlying type of the t argument type of forEach is interface{}. They don't match in any way and so type inference fails. (Note that for inference to have a chance to succeed, the types must have identical structure at a minimum.) Now, in this case, even if they had the same structure, since the T type parameters are never used, they cannot be inferred anyway, and it would still fail.
If an explicit type argument is provided, it works.
Thus this is working as intended. Leaving open as a reminder that the error message could perhaps be improved. Not urgent.

I am running into the same issue, but IIUC the explanation above, it does not seem to apply:
https://go2goplay.golang.org/p/dVyEtkQ6oGD
(as a side note, if it somehow were to apply then it's extremely unfortunate that the most simple and intuitive way of performing the Bar call is actually the only one that is not accepted)

@CAFxX I don't think that's the same issue.  But I also don't think it is expected to work.  The type inference in your final example is more or less the one described at https://github.com/golang/go/issues/39049#issuecomment-652761696; the current algorithm doesn't support that.

I suppose you meant to link a different issue. Regardless, if really the current design doesn't support it then please consider the bit above after the example as general feedback on the design rather than on the implementation. If appropriate I can add this to #15292 (or file a new one?).

Sorry about that, I meant to link to https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#type-inference-for-generic-function-arguments
Thanks, the feedback is noted.  I don't think it's time yet to file issues against the design draft.

I believe the first example correctly reports an error now.
The [second example](type foo[int] of f does not match Foo[T] (cannot infer T)) may be related to #51593.

The remaining error here is justified:
package main

type (
	iterable[T any]   interface{} // empty constraint
	binaryTree[T any] struct{}
)

func forEach[T any](t iterable[T]) {}

func main() {
	v := binaryTree[int]{}
	forEach(v)      // error: type binaryTree[int] of v does not match iterable[T] (cannot infer T)

	// arbitrary types T make this work - therefore type inference cannot infer the "correct" one
	forEach[int](v)
	forEach[string](v)
	forEach[bool](v)
}

Since arbitrary types may be used to satisfy the constraint, type inference cannot infer the "correct" type.
Closing.


fix: do not strip query parameters from connection URL

Reported on: https://github.com/viniciusgerevini/sse-client/issues/11

Thanks for the quick reply, I appreciate it!


Stop-AvdSessionHost Single Session Host issue.

This is not working correctly for a single sessionhost.
Stop-AvdSessionHost -HostpoolName AVD-Testpool -ResourceGroupName RG -Name AVDW11
HINT: use -Force to skip this message.

If you use -Force it appears to try to stop all hosts.
Documentation has -Name and -SessionHostName specified.  -Name works.

Hi @WiseK did you try the beta release from this repository? You can find it under releases.

Hi @WiseK could you please check release : https://github.com/srozemuller/AzAvd/releases/tag/3.0.0-beta.264


Update Yargs to ^12.0.2

I was browsing through Webpacker and on issue 1706 someone pointed out that os-locale has a vulnerability through the mem package. The solution is to update to the latest version of that library but in order to do so I had to upgrade yargs to the latest version.
https://snyk.io/vuln/npm:mem:20180117
Here's the yargs issue which also mentions that 12.02 is the solution to upgrade https://github.com/yargs/yargs/issues/1209

What kind of change does this PR introduce?
This updates the version of yargs to 12.02, which updates dependencies

Did you add tests for your changes?
I wasn't able to test much other than a simple regression for my applications. I'd love feedback from the webpack-cli team
Does this PR introduce a breaking change?
I went through the yargs breaking changes, however it didn't seem like all the code related to the breaking changes was working as intended.
What needs to be documented once your changes are merged?
I believe the only task would be to cut another release for webpack 3.

yargs@12 depends on find-up@3 which is not node 4 compatible.
webpack@3 claims to be node 4 compatible. Changing this would be a breaking change.

The Breaking Changes of yargs@12 also list it:

drop Node 4 from testing matrix, such that we'll gradually start drifting away from supporting Node 4.

Is yargs@11 possible?

So there's not a release of Yargs 11.* that has the latest version of os-locale but let me reach out and see if they would be willing to release one if I branched off of their latest 11.x tag and submitted a PR

@evenstensberg it's for a security vulnerability. But it appears that it's not possible to upgrade anyway...
@corymcdonald Was there any movement in the yargs or mem yet?


ANF #20210102.1 Pipeline failure

https://azurecat.visualstudio.com/hpccat/_build/results?buildId=10382&view=logs&j=6e4f1cc6-8050-5bf9-8495-3efafd6ef526&t=d55b938c-7420-5d64-4f01-a655a6be2261&l=719
Resource : hpcnetapp/anfpool/anfvol1 - InternalServerError
Message  : Error when creating - VLAN conflict in storage server -
please contact support
additionalInfo: None
code: NetworkAllocationFailed
details: None
message: Error when creating - VLAN conflict in storage server -
please contact support
target: None

manually reran and passed

manually reran and passed


Signature coordinates error on different operating systems

I tested pyhanko on Window and Ubuntu,
I have a question why the coordinates of signature field are different.
for example with coordinates:
signature_coords = {'x1': 158.30325, 'y1': 591.17825, 'x2':<PHONE_NUMBER>0000005, 'y2':<PHONE_NUMBER>999999}

on Ubuntu  fill in the order x1,y1,x2,y2 and the result is as expected.
                pdf_signer = signers.PdfSigner(
                    signature_meta=signers.PdfSignatureMetadata(
                        field_name=data['signature_field_name']
                    ),
                    new_field_spec=SigFieldSpec(
                        sig_field_name=data['signature_field_name'],
                        on_page=data['on_page'] - 1,
                        box=(
                            int(signature_coords['x1']),
                            int(signature_coords['y1']),
                            int(signature_coords['x2']),
                            int(signature_coords['y2'])
                        )
                    ),

                    signer=window_signer
                )

But on Windows, I have to fill in differently to get the correct box like on Ubuntu.
box=(
    int(signature_coords['x1']),
    int(signature_coords['y2']),
    int(signature_coords['x2']),
    int(signature_coords['y1'])
)

I want my code to run well on different operating systems, this makes me wonder.
===
version: 0.25.1

Adjusting Coordinates Based on Platform
You can programmatically detect the platform using Python's os module and adjust the coordinates accordingly. For example:
Detect the Operating System:
python

import os
platform = os.name  # 'posix' for Ubuntu, 'nt' for Windows

Coordinate Transformation (if needed): If the origin or orientation differs, you might need to flip the Y-axis or adjust the coordinates accordingly. For example, if the Y-axis is inverted on Windows, you could modify the y1 and y2 values.
Here is a generalized approach:
python

if platform == 'nt':  # Windows
    # Assuming the Y-axis is inverted on Windows
    pdf_height = 842  # Example for an A4 page height in points (adjust accordingly)
    signature_coords['y1'] = pdf_height - signature_coords['y1']
    signature_coords['y2'] = pdf_height - signature_coords['y2']

Use Adjusted Coordinates in the Box: Now you can fill the box with the adjusted coordinates:

python

box=(
    int(signature_coords['x1']),
    int(signature_coords['y1']),
    int(signature_coords['x2']),
    int(signature_coords['y2'])
)

Example Code with Platform Check:
python

import os

# Signature coordinates example
signature_coords = {
    'x1': 158.3025,
    'y1': 591.17825,
    'x2': 278.30235,
    'y2': 666.17825
}

Detect platform
platform = os.name  # 'posix' for Ubuntu, 'nt' for Windows
Adjust coordinates based on platform (example adjustment for Windows)
if platform == 'nt':  # Windows
    pdf_height = 842  # Example A4 page height in points, adjust as per your PDF
    signature_coords['y1'] = pdf_height - signature_coords['y1']
    signature_coords['y2'] = pdf_height - signature_coords['y2']

Fill the box with adjusted coordinates
box = (
    int(signature_coords['x1']),
    int(signature_coords['y1']),
    int(signature_coords['x2']),
    int(signature_coords['y2'])
)

Now use this box for creating the signature field as in your original code
pdf_signer = signers.PdfSigner(
    signature_meta=signers.PdfSignatureMetadata(
        field_name_data=['signature_field_name']
    ),
    new_field_spec=SigFieldSpec(
        sig_field_name_data='signature_field_name',
        on_page_data=['on_page'] - 1,
        box=box
    ),
    signer=window_signer
)

Explanation:
Platform Detection: This allows the script to know whether it's running on Windows or Ubuntu.
Y-axis Adjustment: If the Y-axis is inverted on Windows (common in some systems), the y1 and y2 coordinates are recalculated by subtracting them from the page height (pdf_height), essentially flipping the Y-axis.
Box Filling: After the coordinates are adjusted, the signature field is placed using the modified coordinates to ensure consistent behavior across platforms.

Yes, I sloved that problem, but i'm not sure if it always happens with windows os.

@niranjanpathak-np1 While your attempt at a solution is appreciated, please don't just blindly post LLM-generated answers to questions. Especially when the LLM misses the point by a mile...
Anyway, this is not likely to be a pyHanko issue, but rather a "I have two PDF viewers that produce different results when fed the same file" issue. The difference in OSes is also not really relevant. PyHanko is completely platform-agnostic and performs the exact same PDF manipulations regardless of the platform on which it is executed.
Please include the names & versions of the viewers you're using, and also your input document, since this can only be pyHanko's fault if it somehow turned a valid PDF into an invalid one during the signing process.
I'll also be converting this into a discussion.


Application/Json response

failing test
Expectations:  control when to record request and response content (i.e. based on content type?)
Now, Verify.Http only records when request or response content type is Text.

can you try 1.1.2. i actually already had a more robust method of testing if something is text. I am hoping that change will meet your requirement (and fix the bug) without the need to add and document a new API

Hi, I will test 1.1.2 in a few days. Thanks for your quick fix

The new 1.1.2 works for me. Thanks.
PR closed, fixed in #395

@coenm awesome. just to be clear, i am not against a new api. i would just prefer to have someone who really requires to for it to be justified.

@coenm awesome. just to be clear, i am not against a new api. i would just prefer to have someone who really requires to for it to be justified.

I understand your point. No offence taken.

I understand your point. No offence taken.


Create README.md

Adding the slides from the JNUC 2024 presentation of App Auto-Patch

Adding slides from JNUC 2024 presentation.


BUG: Math.cos and Math.sin function cause crash

This seems a little ridiculous, but I am encountering a sudden crash in a very simple usage of the JSRT.
This is my complete usage:
constexpr auto kScript = R"(
var module = {}
module.foo = function() {
  var junk = Math.cos(0.5) * 0;
}
module;
)";

int main() {
 JsRuntimeHandle runtime;
  JsCreateRuntime(JsRuntimeAttributeNone, nullptr, &runtime);

  JsContextRef context;
  JsCreateContext(runtime, &context);

  JsValueRef module;
  {
    JsSetCurrentContext(context);

    JsValueRef script, url;
    JsCreateExternalArrayBuffer((void*)kScript, strlen(kScript), nullptr, nullptr, &script);
    JsCreateString("foo.js", 6, &url);

    JsRun(script, 0, url, JsParseScriptAttributeNone, &module);
    JsAddRef(module, nullptr);

    JsSetCurrentContext(JS_INVALID_REFERENCE);
  }

  for (int i = 0; i < 100000; i += 1) {
    std::cout << "iteration=" << i << std::endl;
    JsSetCurrentContext(context);

    JsValueRef fn;
    JsPropertyIdRef prop_id;
    JsCreatePropertyId("foo", 3, &prop_id);
    JsGetProperty(module, prop_id, &fn);

    JsValueRef undefined;
    JsGetUndefinedValue(&undefined);
    JsValueRef args[] = {undefined};

    JsValueRef ret;
    JsCallFunction(fn, args, 1, &ret);

    JsSetCurrentContext(JS_INVALID_REFERENCE);
  }
}

When I run the program it gets to iteration 200 or so and then terminates with error code "1073807364". The unbelievable thing is that I can replace the actual JS script with some fairly arbitrarily complicated code and everything works fine. There is something in particular about operating on the result of Math.cos (even multiplying by 0) that causes the crash.
I can reproduce the value by replacing Math.cos(0.5) with Math.sin(0.5) or Math.sin(0.1) but if I actually hard-code the result of these functions I don't get the premature termination. I'm on Windows 10 and linking to Chakra with a vcpkg installation.

BTW this repros if I use a global function approach as well:
constexpr auto kScript = R"(
function foo() {
  var junk = Math.cos(0.5) * 0;
}
)";

,,,

    JsValueRef global, fn;
    JsGetGlobalObject(&global);
    JsPropertyIdRef prop_id;
    JsCreatePropertyId("foo", 3, &prop_id);
    JsGetProperty(global, prop_id, &fn);

    JsValueRef undefined;
    JsGetUndefinedValue(&undefined);
    JsValueRef args[] = {undefined};

    JsValueRef ret;
    JsCallFunction(fn, args, 1, &ret);

I can't seem to reproduce this issue on my machine. What version of ChakraCore are you using, and are you building for x86 or x64, release or debug, windows or Linux or mac?
The error code that you get is 0x40010004 which is used for DBG_TERMINATE_PROCESS which essentially means that we hit some kind of fatal error, but that can come from a number of different places and without being able to debug it I can't say where.

Using the same dlls and libs that we published for 1.11, I still don't see this failure. Is it possible for you to make a self-contained repro, e.g. put your build files into a repo, or zip it up and put it somewhere I can see it?

Made a repo: https://github.com/taylorgordon20/charkra_test
It's setup to use bazel to build (the chakra_test target builds the test executable with issues), The compilation is effectively some command like:
C:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/VC/Tools/MSVC/14.15.26726/bin/HostX64/x64/cl.exe /nologo /DCOMPILER_MSVC /DNOMINMAX /D_WIN32_WINNT=0x0600 /D_CRT_SECURE_NO_DEPRECATE /D_CRT_SECURE_NO_WARNINGS /D_SILENCE_STDEXT_HASH_DEPRECATION_WARNINGS /bigobj /Zm500 /J /Gy /GF /EHsc /wd4351 /wd4291 /wd4250 /wd4996 /I. /Ibazel-out/x64_windows-fastbuild/genfiles /Ibazel-out/x64_windows-fastbuild/bin /Iexternal/bazel_tools /Ibazel-out/x64_windows-fastbuild/genfiles/external/bazel_tools /Ibazel-out/x64_windows-fastbuild/bin/external/bazel_tools /Ithird_party/include /Ibazel-out/x64_windows-fastbuild/genfiles/third_party/include /Ibazel-out/x64_windows-fastbuild/bin/third_party/include /showIncludes /MD /Od /Z7 /DDEBUG /Fobazel-out/x64_windows-fastbuild/bin/_objs/chakra_test/main.obj /c main.cpp
And the linking is:
C:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/VC/Tools/MSVC/14.15.26726/bin/HostX64/x64/link.exe /nologo /OUT:bazel-out/x64_windows-fastbuild/bin/chakra_test.exe /SUBSYSTEM:CONSOLE /MACHINE:X64 @bazel-out/x64_windows-fastbuild/bin/chakra_test.exe-2.params /DEBUG:FASTLINK /INCREMENTAL:NO

Using your repo I can reproduce the error, but the chakracore.dll that you've included there isn't one that we have published ourselves, and if I replace the chakracore.dll with one that we published, then the issue goes away.
I am not familiar with vcpkg, but looking at https://github.com/Microsoft/vcpkg/blob/master/ports/chakracore/portfile.cmake it seems like it is actually trying to compile chakracore itself / have you compile it yourself. It does mention pdbs in there; do you have the pdb for your chakracore.dll? If so, could you share that, then I can try to work out the specific cause of the crash, which may point to what's gone wrong in making the chakracore.dll?

I've updated the git repo to include the ChakraCore.pdb file.

Thanks for the repro @taylorgordon20, it looks like this is an incompatibility between ChakraCore and the dynamically linked CRT.  When I tried this myself I ended up with a build which linked to ucrtbase rather than msvcrt.  That's not currently a supported configuration for building ChakraCore, which explains the fail fast you're hitting.
To work around the issue you can create a new triplet and build ChakraCore with dynamic library linkage and static CRT linkage.
Just create a new file:
\triplets\x64-windows-mt
set(VCPKG_TARGET_ARCHITECTURE x64)
set(VCPKG_CRT_LINKAGE static)
set(VCPKG_LIBRARY_LINKAGE dynamic)

Then install ChakraCore again:
> vcpkg install chakracore:x64-windows-mt

And update your documentation to include/link against the new output directory in your vcpkg root:
> dir .\installed\x64-windows-mt\

    Directory: E:\GitHub\vcpkg\installed\x64-windows-mt

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----        9/27/2018   4:56 PM                bin
d-----        9/27/2018   4:56 PM                debug
d-----        9/27/2018   4:56 PM                include
d-----        9/27/2018   4:56 PM                lib
d-----        9/27/2018   4:56 PM                share
d-----        9/27/2018   4:56 PM                tools

I tested this out locally and after fixing the build configuration the test app runs successfully.

Thanks for investigating! I'll try with the suggested triplet. :)

Let us know if you hit any other issues, but I've opened a PR against vcpkg to force static linking of the CRT.


release new version with all emit events

I can see that master branch already has emit functionality for events.
Please make  a new release, so we can all get it from npm.js

zeppelin-solidity/contracts/token/ERC20/BasicToken.sol:38:5: Warning: Invoking events without "emit" prefix is  @deprecated.     Transfer(msg.sender, _to, _value);
@rstormsf is this related to this problem???


HSEARCH-4850 Add compatibility with OpenSearch 2.7

https://hibernate.atlassian.net/browse/HSEARCH-4850

Tests passed locally and on CI too 🎉

Merged, thanks!


No data to calculate MR Review time

Data is missing to calculate 'MR Review time'.
No record in table 'gitlab_merge_requests' has a valid 'first_comment_time'.
The DB I connected is <IP_ADDRESS>:45432.

Verified


Rounding Issue

Hi @ionspin !
I am having problem with figure rounding. I have an application that can support trailing decimal point number configuration. We have a setting that will configure this thing, so it will be dynamic.
Let's say the total decimal point number set is 3. So given number 12.5671, it will round to 12.567, if it is 2, it becomes 12.56 and so on.
I have a test case like following

and here is my round function

The purpose why I convert to BigInteger first is to get the number before the decimal point, and then use the value from the setting to add the trailing decimal point. The test case above will result to java.lang.reflect.InvocationTargetException
Can you guide me on how to directly use the BigDecimal number and then use my custom setting value to set the trailing decimal point number?
 Thanks for this amazing library!

Hey, I can definitely help you with that, and you should be able to do everything by using BigDecimal and decimal mode directly, I'll just need some time to write an understandable explanation, because it's a bit different from the way Java BigInteger does it. Could you in the mean time grab a stack trace when that InvocationTargetException is thrown, because that is definitely a bug.
Thanks!

I'll need to add this to wiki in more details, but here is the gist of it.
Each BigDecimal can have a parameter of type DecimalMode and here is the definition of decimal mode:

Ok, so while going through the process, I found a couple of bugs, so I'd suggest that you use a snapshot until I release a next version.
Your approach will give you a correct result, but it's creating an uneccessary BigInteger instance, and the rounding mode is also giving you troubles, so let's look at a different way of getting to the desired result.
So to round to a specific number of digits after the decimal point, you should be looking at two properties of BigDecimal, the precision and exponent
precision - describes how many digits does the significand have
`exponent - exponent describes to which degree the significand needs to be raised/lowered to properly describe the number.
One important thing to keep in mind is that significand (which is a BigInteger) is NOT representing an integer! I know it's a bit confusing, but keeping that in mind will help you when debuggin later.
Some examples will make it more clear (pay attention to where the decimal point is when calculating the big decimal):
Significand = 123
Exponent = 3
BigDecimal = 1.23 * 10^3 = 1230

Significand = 654
Exponent = -3
BigDecimal = 6.54 * 10^-3 = 0.00654

Significand = 987
Exponent = 0
BigDecimal = 9.87 * 10^0 = 9.87

Hope that clears it up a bit.
And that would be enough and work perfectly, if we had unlimited memory, but because we don't we need to introduce desired precision parameter. Otherwise cases such as 10/3 =0.3333... would result in all the memory being used to store the repeating 3.
When you are creating BigDecimals without specifying DecimalMode they default to infinite precision (it's represented with precision = 0, and rounding mode NONE)
In those cases, precision will always equal the length of underlying significand.
So let's look at how BigDecimal can look if we introduce precision:
Lets use this as our BigDecimal BigDecimal.fromIntWithExponent(123456789, 3)
what we will actually get is the following
Significand = 123456789
Precision = 9
Exponent = 3
BigDecimal = 1.23456789 * 10^3 = 1234.56789

So if you want to have the BigDecimal with a specific number of digits after the decimal point, you should be modifying the precision parameter.
So let's say that we want to convert that BigDecimal from previous example into a BigDecimal with just 2 trailing digits.
We would first look if the exponent is positive, because if it is, we know that the position of the decimal point is at position exponent + 1. So in our case that will be 4.
If the exponent is negative, it gets a little trickier, but you'll figure it out if you play around with it a bit.
Then we want the new precision to be 4 + 2 (desired number of digits after the decimal point), so 6.
And this far your rounding method would work fine, but the problem is the RoundingMode cannot be NONE, you need to pick a RoundingMode that suits your calculation, you can look at different rounding modes and their description on wikipedia article on Rounding
So doing something like
BigDecimal.fromIntWithExponent(123456789, 3).round(DecimalMode(6, RoundingMode.ROUND_HALF_AWAY_FROM_ZERO))
That should give you the desired result of 1234.57 (note the 7 at the end because of rounding)
There is another caveat here. This rounded number now has a set decimal mode of 6 and HALF_AWAY_FROM_ZERO
Next time you use this number in a arithmetic operation, and you don't specify desired decimal mode for the operation yourself, it will use the one that came with the number. Which might not give you desired result if the second number has a precision higher than 6.
I haven't had the time to tackle that yet, but I will probably add a global BigDecimal DecimalMode parameter where you can set the default overrideing DecimalMode for all operations, that would then discard the DecimalMode that comes with the number itself. But this might be an API breaking change, so be warned.
Hope this clears up things a bit, if you have a suggestion on how you would LIKE this to work, feel free to share it, as the library should be easy to use, and this is the perfect time to break the API in early stages.
I'll also add a method called something like `roundToDigitsAfterRadix(numberOfDigitsAfterRadix : Int) that will do exactly what you want.

Hey @avjiang I added a couple of methods that should make this much more straightforward. roundToDigitPosition and roundToDigitPositionAfterDecimalPoint, they are in snapshot so you can try them out. I still have to do some cleanup and add documentation.
Also you'll notice that I broke the previous API by renaming round() to roundSignificand() which describes better what it actually does, I'm not completely sure that I will leave it public at all with those two new methods. Anyways, that change is going to break your build, so sorry about that :)

hi @ionspin, these few days my team still working on it. Thank you so much for the detailed explanation! So I think I can try those 2 new methods first. See how it works. Will come back to you again later. Much thanks!

btw, i couldn't use the snapshot version. here is the error
Could not find com.ionspin.kotlin:bignum:0.1.4-SNAPSHOT.
Searched in the following locations:
- https://dl.google.com/dl/android/maven2/com/ionspin/kotlin/bignum/0.1.4-SNAPSHOT/maven-metadata.xml
- https://dl.google.com/dl/android/maven2/com/ionspin/kotlin/bignum/0.1.4-SNAPSHOT/bignum-0.1.4-SNAPSHOT.module
- https://dl.google.com/dl/android/maven2/com/ionspin/kotlin/bignum/0.1.4-SNAPSHOT/bignum-0.1.4-SNAPSHOT.pom
- https://jcenter.bintray.com/com/ionspin/kotlin/bignum/0.1.4-SNAPSHOT/maven-metadata.xml
- https://jcenter.bintray.com/com/ionspin/kotlin/bignum/0.1.4-SNAPSHOT/bignum-0.1.4-SNAPSHOT.module
- https://jcenter.bintray.com/com/ionspin/kotlin/bignum/0.1.4-SNAPSHOT/bignum-0.1.4-SNAPSHOT.pom

I have tried with all three rounding methods provided. My objective is to round to 2 decimal points (after decimal point)
So these are the results tested with different rounding methods:
roundSignificant:
if(bigDecimal.exponent>0)
bigDecimal = bigDecimal.roundSignificand(decimalMode = DecimalMode(bigDecimal.exponent.longValue() + 1 + 2, RoundingMode.ROUND_HALF_CEILING))
else
bigDecimal = bigDecimal.roundSignificand(decimalMode = DecimalMode(-1 + 2, RoundingMode.ROUND_HALF_CEILING))
input:0.00123121
expected result:0.00
output:0.002
input:0.0123121
expected:0.01
output:0.02
input:0.1123121
expected:0.11
output:0.2
roundToDigitPositionAfterDecimalPoint
var bigDecimal = input.roundToDigitPositionAfterDecimalPoint((input.exponent.longValue() + 2), RoundingMode.ROUND_HALF_TOWARDS_ZERO)

from the method name I thought I just have to set the precision point after decimal point but after tested I still need to count the number of digit before decimal point and include as my digit of precision

input:10.3333
expected: 10.33
result:10.34
input:10.345364
expected:10.35
result: 10.35
var bigDecimal = input.roundToDigitPosition((input.exponent.longValue() + 1 + 2), RoundingMode.ROUND_HALF_AWAY_FROM_ZERO)
input:10.12345
expected:10.12
result:10.13
if i set the digit precision to 3
input:0.00123432432
expected:0.00
result:0.01
I have tested with ROUND_HALF_CEILING and ROUND_HALF_AWAY_FROM_ZERO rounding mode, but it does not return me the result as expected. I would like to round figure below 5 to 0 and figure 5 and above to next number

Ah, I'll have to look into the rounding modes, I'll try to do that today after work. ROUND_HALF_AWAY_FROM_ZERO should be the one to use, but it's not giving proper results in your testing. Let me get back to you on this.

I've found a bug in the rounding function, it would return wrong results most of the time, but unfortunately  my tests covered only working cases. I also changed the two new funcations a bit. Here's how it works now:
        assertTrue {
            val rounded = BigDecimal.parseString("1000000.12355")
                .roundToDigitPositionAfterDecimalPoint(3, RoundingMode.ROUND_HALF_AWAY_FROM_ZERO)
            rounded.toStringExpanded() == "1000000.124"
        }

        assertTrue {
            val rounded = BigDecimal.parseString("1000000.12355")
                .roundToDigitPositionAfterDecimalPoint(3, RoundingMode.ROUND_HALF_TOWARDS_ZERO)
            rounded.toStringExpanded() == "1000000.123"
        }

It should be available in the snapshot in an hour or so, once the Travis build is complete. And a heads up tomorrow or a day after, I will be changing exponent in big decimal from BigInteger to Long so you won't have to do this ... input.exponent.longValue() ... any more. Will break the build again :)

I tried to run your test again, but if failed. i am using version 0.1.4-SNAPSHOT

Hi @avjiang, I presume that snapshot didn't update on your side, gradle can be sometimes finicky if you don't force snapshot update. In any case, version 0.1.4 was just fully released so you might want to try with that one.

Hi @ionspin, updated to version 0.1.4, and I found another issue

Expected result is: 1000000.12
However, the function will return 1000000.13
Please advise

Excellent catch, it's because the discarded part is "055" which is unfortunately inspected as "55". I'll fix that after work and put the fix in 1.5-SNAPSHOT.

@avjiang Fixed in 0.1.5-SNAPSHOT, but I didn't have time to test properly, so I wouldn't be surprised if you find some other corner cases. Thanks for reporting the problems and providing the test cases, it helps a lot!

I'm considering this issue resolved as #77 should have taken care of final problems. If there are further rounding problems we should track them in new issues.


Handle first_page and last_page cases when reaching there.

While try vuejs-paginator component with yii2 rest, I found there are 2 cases where first_page and last_page can not handle properly. Hence my try is to check those 2 cases to ensure the component can work properly. Hopefully if this fits for other rest api(s)

Hey @longthanhtran,
thanks for your contribution.
Why your API returns next/previous page urls when they don't exist?
Maybe you are doing something wrong?

Hi, since I use yii2 and it always return "no prev" on first page or "no next" on last page. I think this is also reasonable as these case there should be optional. Otherwise, the component fails to render first / last list

@longthanhtran you are doing this check
this.current_page === this.last_page

But this doesn't solve the issued with 'no prev', right?

the  this.current_page === this.last_page to handle last page where I don't need to worry about 'no prev'. On the other side, I only take care first page without worry about 'no next'. Both of the cases are checked :)

won't this.current_page === this.last_page return false when last_page is 'no next'?

I am sorry, seems I make you confuse. Here are the cases I checked.

next_page_url. When I see the last page this.last_page then I simply use null instead of no value from API. (in my case, there is no last_page from API). For example, this.current_page is 10 and this.last_page also is 10, then the returned value to next_page_url is null.

this.next_page_url = (this.current_page === this.last_page) ? null : utils.getNestedValue(data, this.config.remote_next_page_url);

prev_page_url. Where the current_page is 1 then this should be the first page, I don't expect to have prev_page and I use null for this case. (in my case, there is no prev_page from API)

this.prev_page_url = (this.current_page === 1) ? null : utils.getNestedValue(data, this.config.remote_prev_page_url);

@longthanhtran oh I see now.
Thanks!


os-telegraf : timestamp is in UTC but formatted as local

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

[X] I have read the contributing guide lines at https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md
[X] I have searched the existing issues, open and closed, and I'm convinced that mine is new.
[X] The title contains the plugin to which this issue belongs

Describe the bug
In Telegraf log file, the timestamp is in UTC but formatted as local. My Opnsense system timezone is currently CET (UTC+1) but the timestamp displayed is UTC+0 (one hour late)
Tip: to validate your setup was working with the previous version, use opnsense-revert (https://docs.opnsense.org/manual/opnsense_tools.html#opnsense-revert)
To Reproduce
Steps to reproduce the behavior:

Go to Telegraf>Log file
Timestamp shows 2022-02-26T17:14:51 whereas the 'date' command returns Sat Feb 26 18:14:51 CET 2022

Expected behavior
The plugin should log the current date and time in local timezone : 2022-02-26T18:14:51 instead of 2022-02-26T17:14:51 (for a CET system).
Environment
OPNsense 22.1.1_3-amd64
FreeBSD 13.0-STABLE
LibreSSL 3.3.5

I looked further into this issue. In /var/log/telegraf/telegraf.log, I have :
2022-02-26T23:09:10Z E! [inputs.ping] Error in plugin: ...
but it's displayed
2022-02-26T23:09:10 on "Services: Telegraf: Log File"
Telegraf correctly logs the time in UTC format (ending with Z) but the GUI removes the Z without converting the time value to local.


Checking if Node Exists - Bracket Notation Syntax

Hi,
I currently have data file with rows of json objects containing information I want to extract.
Currently, there is a field called random which will sometimes appear in some of the data.
[1, 2, {"d": { "random":null, date: 1234} , "l": filler } ]
Using bracket notation, to check if a node exists, should the syntax not be:
$[2]['d'][?(@.random)]['date']

The filter checks if the node exists, and if it does, then the query will retrieve date. Is this the proper way to do it, or is there an underlying issue with bracket notation with jsonpaths.
Thank you

Hi,
There are several issues with how filters are handled when applied to objects. Not sure what the issue is and how it is supposed work. The reference implementation does not give all the answers.
I need to look into this.

This is much appreciated.
Thank you.

I think the problem is that the value of random is null, which JsonPath interprets as "does not exist", see Criteria.java:395.

I think EXISTS should compare with JsonProvider.UNDEFINED instead of null. The problem was introduced in 290edb540c35034dd317edbb282f2685bbc15283.

This works as expected now.


Update docs for parallel HDF5

In https://github.com/JuliaIO/HDF5.jl/pull/1061 HDF5.jl changed to use Preferences.jl to enable a system-provided HDF5 library.

HDF5.jl v.0.17 has finally been released. So this can be merged.

I just checked that it's using v0.17 of HDF5.jl in at least one CI job. Let's keep fingers crossed that CI passes this time. Thanks for your effort, @JoshuaLampert!


Unable to get started with Adonis on Windows OS

Hi,
I am on Windows 10 64 bits.
I have node v6.1.0 and npm v3.9.0
I execute these command :

npm install -g adonis-cli
adonis new my-project

I have an error :

I cd into my project directory and execute npm start :

So I am unable to get started with Adonis.

npm install has failed for you. Just remove the node_modules and re-run npm install and make sure it is able to install all packages.

Actually, I have tried many times.
I don't know what's wrong. I have tried with node v4.4.4 and v6.1.0, on Windows.
On my second screenshot, you can see that I have no node_modules directory before I execute npm install. Actually, npm install fails before creating the node_modules directory.
I am going to try to install Adonis on my linux distribution tomorrow, at the office. I think this issue is Windows OS specific.

Hi,
I just try to install Adonis on my linux distribution. I have tried with node v4.4.4 and v6.1.0 and npm v3.9.0.
I am not able to execute the npm install command, and adonis new my-project fails too.

Can you share the errors?

Hi,
Of course, here is a screenshot :

You know what ? Actually, I am able to execute with success adonis new my-project with npm v3.8.x !!! The bug seems to be linked to npm v3.9.0 !

@KevinNTH Yeah npm throws EMISSINGARGerror. Will debug it by upgrading to Node6.0.

@krisanalfa What's the npm version?

@thetutlage Mine is 3.9.0.
krisanalfa@localhost ~ % npm --version
3.9.0
krisanalfa@localhost ~ % node --version
v6.2.0

The issue is with npm version 3.9.0. This thread can help https://github.com/npm/npm/issues/12647. Everyone switched to 3.8.9 and that what I can recommend

I confirm downgrading to 3.8.* fixed this problem.

Closing this issue as not directly related to AdonisJs


NullReferenceException at Parse.PlatformHooks.Initialize ()

Unity 5.2.1p1
Parse.Unity SDK 1.6.0
Built with Mono2x backend and "Strip Byte Code" stripping level.  While running in Xcode I get the following error:
NullReferenceException: A null value was found where an object instance was required.
at System.Reflection.MonoProperty.CreateGetterDelegate (System.Reflection.MethodInfo method) [0x00000] in :0
at System.Reflection.MonoProperty.GetValue (System.Object obj, System.Object[] index) [0x00000] in :0
at Parse.PlatformHooks.Initialize () [0x00000] in :0
at Parse.ParseClient.Initialize (System.String applicationId, System.String dotnetKey) [0x00000] in :0
at Parse.ParseInitializeBehaviour.Initialize () [0x00000] in :0
at Parse.ParseInitializeBehaviour.Awake () [0x00000] in :0

Hi Nick,
Thank you for your report. We'll investigate this issue further and will let you know if there's any progress/fix.

@hallucinogen: Thanks for looking into this.  We're up against a tight release deadline, and am wondering if there's anything we can do to help explore/expedite this issue.  Thanks!

After further investigation, we can't repro this issue. The starter project at least works just fine under
Unity 5.2.1f1
Mono2x backend
.NET 2.0 Subset
Both simulator and device (iPhone 5S, iOS 9)
Can you try stripping all the code until only Parse initialization and see if it works on yours, too?

I've downloaded the latest code release here and used that in my build, and this issue seems to have gone away.


[!feat] Refactor Kraken

Implementation details

cleanup bothan-kraken
bothan-kraken use new store

Please ensure the following requirements are met before submitting a pull request:

[x] The pull request is targeted against the correct target branch
[ ] The pull request is linked to an issue with appropriate discussion and an accepted design OR is linked to a spec that describes the work.
[x] The pull request includes a description of the implementation/work done in detail.
[ ] The pull request includes any appropriate unit/integration tests
[ ] You have added a relevant changelog entry to CHANGELOG.md
[x] You have re-reviewed the files affected by the pull request (e.g. using the Files changed tab in the GitHub PR explorer)

does it need unit tests, I found out that there are unit tests but not in here initially @warittornc

Do we need 2 approval for this pr?


Switch property storage_keys to slots in access list at Pallet Ethereum

Switch property from non-existent storage_keys to slots each time when creating access_list at Pallet Ethereum.

[x] Fixes runtime builds with latest v0.9.17 Polkadot

@MaciejBaj thank you for your contribution.
Currently we are overriding the ethereum crate here until we get a new offical release (in Moonbeam as well).
This includes renaming from slots to storage_keys for AccessListItem.


Update samples link to point at root of repository

Existing link deep links to a single sample rather than root of all samples.

@sjwaight : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Looks good. Thanks @sjwaight


Webpage is returning a 404

Deployed app link in README.md is returning a 404.

Thanks for reporting issue !! It seems some domain problem will investigate furthur

Solved !! must be working fine now. Can you please confirm once?

Excellent. It looks great! :+1:


Update create-self-hosted-integration-runtime.md

https://github.com/MicrosoftDocs/azure-docs/issues/9338

@PatMyron : Thanks for your contribution! The author, @nabhishek, has been notified to review your proposed change.

@PatMyron Thank you so much for catching that! It looks like you now have a merge conflict. If you can resolve this, we can merge your pr. Or, if you prefer, close your current pr and create a new one against the current version of the file.
@douglaslMS

Think someone else got to it already:
https://github.com/MicrosoftDocs/azure-docs/commit/0e13d0c5b7b9dc82fdc89cabd78b3bedc2b8f7fc#diff-718ba317d556c2683043153487d5dd05


TreeBinAssert.java fails on Coretto

Describe the bug
TreeBinAssert.java fails against a build of Coretto's jdk11.
This bug was fixed upstream in openjdk11 by this code change, however this change did not get imported into Corretto (despite its age).
Could this be a bug with Coretto's merge system?
Coretto bug raised here.
To Reproduce
https://trss.adoptopenjdk.net/output/test?id=5efea4b42e55416417c06c11
Expected behavior
The test should pass.
Additional context
Add any other context about the problem here.

We have already had another case where the test code we take is not the correct version with the repo that is used to build Corretto.  In order to be able to match the repo, the build pipeline should pass the SHA of the jdk11u repo to test pipelines, otherwise we have to make the assumption that its built from tip.
I believe this is the case, and that the fix would be to update how corretto build pipeline is called.
See https://github.com/AdoptOpenJDK/openjdk-build/issues/1674

Here the Coretto team assert that "Our master and develop branches are still based on 11.0.7, but after 11.0.8 releases, they will be updated (and this error will be fixed)"
So I don't expect this issue to go away until after the release.

https://github.com/AdoptOpenJDK/openjdk-tests/pull/1876 has addressed the issue with matching test material to jdk repo.


✅ Add all currently supported versions of Node.js to test matrix

Fixes #39.
The following Node.js versions of are supported by the Node.js working group, and should be included in the test matrix for this library:

10.0.0
9.11.1
8.11.1
6.14.2
4.9.1

The engine definition within this library's package.json specified the version to be >= 8.11.1, which is too restrictive for this version set.

cc @orlandoc01
Removing the engine restriction in the library's package.json fixed the problem. To prevent this from happening again, I've also added all currently supported versions of Node.js to the Travis CI test matrix.


--help flag doesn't work for subcommands

Running npx checkly test --help (or --help for any other command) gives the following:
$ npx checkly test --help
Test checks on Checkly

    TypeError: (cmd.args || []).filter is not a function

We should fix --help so that it describes all of the relevant command line flags.

Weird, this only happens with the released version

It is related to oclif.manifest.json weirdly


Windows Self-hosted agents should support Windows 11.

Update Pre-requisites to include Windows 11.

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

ID: cfd11746-d49c-f249-38a5-c7ddf0863ffe
Version Independent ID: cfd11746-d49c-f249-38a5-c7ddf0863ffe
Content: Deploy an Azure Pipelines agent on Windows - Azure Pipelines
Content Source: docs/pipelines/agents/windows-agent.md
Service: azure-devops-pipelines
Sub-service: azure-devops-pipelines-agents
GitHub Login: @steved0x
Microsoft Alias: sdanie

I'll update the docs and fork/pull request


Uninstalled Ubuntu terminal is not removed from Windows Terminal list

Environment
Windows build number: Microsoft Windows [Version 10.0.18362.535]
Windows Terminal version (if applicable): Windows Terminal (Preview)Version: 0.7.3382.0
Any other software: Ubuntu 18.04 LTS from windows store
Steps to reproduce

I uninstalled Ubuntu 18.04
Then install Ubuntu 18.04

Expected behavior
Ubuntu 16.04 or (uninstalled terminal) should be remove from list of windows terminal.
Actual behavior
Ubuntu 16.04 still in the  list of windows terminal even already uninstalled.

If you have never cleared your profiles.json, now is the time to do it.
If you are carrying around a profiles.json from before version 0.5, WSL distributions that have been uninstalled will not automatically be removed.
The distribution scanning happens on launch.


Made the memory_nav benchmark a little more robus

After scrolling until the Material "Text Fields" demo item is visible, make sure that the center of the item is visible, since we're going to tap the center of the item.

If you're sure that this fixes it would unmark it as flaky too

LGTM


docker support

This code is apache2 and should be able to be sucked in to an extent:
https://github.com/dotcloud/openstack-docker

I am a bit confused on what is the status here.
Reading the docs (at http://salt.readthedocs.org/en/latest/topics/cloud/index.html) suggests there is support for lxc container, but not docker containers? Is this accurate, and if so, why??
I would like to provision multiple docker containers using salt, later on I would like to change from using docker as the provisioner to ec2, it seemed that salt-cloud would be the place to do both of these, but maybe I am confused.

There is a salt module for docker and state for docker.
Salt Cloud was merged into salt.

Thanks Jeff. I know about salts docker module.
However the api would be a bit different in salt-cloud.in particular what in my use case what I wanted was to use docker instead of was to test my app locally.
Then to deploy I hoped to just change a config var from docker to aws and let salt cloud do its magic.
If I just use the plain salt docker module then my local and production salt setups will share less code (and salt cloud would only be used for the local one). Does that make sense?
Maybe I should open this issue at the main salt repo?


Force linking with libstdc++ for test_marshall

If jemalloc isn't compiled with the --disable-cxx flag, it might cause double free issues with some class destructors. This fixes the problem when running test_marshall when ATS is compiled jemalloc (without the --disable-cxx flag).
The problem is that for some reason, the new Regex() call is using libc, but delete is going through jemalloc's code path for c++ support.

This doesn't seem correct.  Why are we overriding the delete method and not the new?

Yes, I was wondering about this interacts with this code that creates a Regex instance with new Regex.

Just realized there's more to dig into this problem, putting this on hold for now.

Perhaps,  @duke8253, you could update the top comment to explain the details of the actual problem.

I thought I did? Maybe it didn't refresh, let me try that again.

The root issue here is that the regression test framework does not use any of libstdc++ and therefore due to the --as-needed linking flags, it's not linked in to the executable. This results in that library not being loaded before jemalloc which means jemalloc doesn't do the intercept properly. The solution is to force that linking with the executable, either by using C++ in the regression frame work or, as @duke8253  has done, explicitly link it.


Debian: Illegal Instruction when adding filter

Debian 12 Bookworm amd64.
Solution to the first problem of the plugin not being found (Issue #95) is to sym-link it into the correct location for Debian/Ubuntu and derivative distros expected location as dictated by the obs-studio package itself.
$ sudo ln -s /usr/lib/obs-plugins/obs-virtualbg.so /usr/lib/x86_64-linux-gnu/obs-plugins/

(the Debian .deb package should install to this location).
OBS now sees the plugin and can add it to a source as a Filter but as soon as we try to add the Effect by pressing on the Effects + button OBS crashes with:
...
info:   Loaded Modules:
...
info:     obs-virtualbg.so
...
info: [Virtual BG detector] detecter_create version:v1.2.0
info: User added filter 'Virtual Background Detector' (virtualbg) to source 'HD PTZ Cam (Inside-Out)'
info: [Virtual BG detector] frame size or format change detected
info: [Virtual BG detector] video_scaler_create success. 1920x1080 -> 256x144
Illegal instruction (core dumped)

Debugging reveals that the illegal instruction actually happens as soon as the filter was selected:
info: [Virtual BG detector] detecter_create version:v1.2.0
[New Thread 0x7ffed2a226c0 (LWP 252074)]
[New Thread 0x7ffed22216c0 (LWP 252075)]
[New Thread 0x7ffed1a206c0 (LWP 252076)]
[New Thread 0x7ffed121f6c0 (LWP 252077)]
[New Thread 0x7ffed0a1e6c0 (LWP 252078)]
[New Thread 0x7ffeb7fff6c0 (LWP 252079)]
[New Thread 0x7ffeb77fe6c0 (LWP 252080)]
info: User added filter 'Virtual Background Detector' (virtualbg) to source 'HD PTZ Cam (Inside-Out)'
info: [Virtual BG detector] frame size or format change detected
info: [Virtual BG detector] video_scaler_create success. 1920x1080 -> 256x144
[New Thread 0x7ffeb6ffd6c0 (LWP 252081)]
[New Thread 0x7ffeb67fc6c0 (LWP 252082)]
[New Thread 0x7ffeb5ffb6c0 (LWP 252083)]
[New Thread 0x7ffeb57fa6c0 (LWP 252084)]
[New Thread 0x7ffeb4ff96c0 (LWP 252085)]
[New Thread 0x7ffeabfff6c0 (LWP 252086)]
[New Thread 0x7ffeab7fe6c0 (LWP 252087)]
[New Thread 0x7ffeaaffd6c0 (LWP 252088)]
[New Thread 0x7ffeaa7fc6c0 (LWP 252089)]
[New Thread 0x7ffea9ffb6c0 (LWP 252090)]
[New Thread 0x7ffea97fa6c0 (LWP 252091)]
[New Thread 0x7ffea8ff96c0 (LWP 252092)]
[New Thread 0x7ffea3fff6c0 (LWP 252093)]
[New Thread 0x7ffea37fe6c0 (LWP 252094)]
[New Thread 0x7ffea2ffd6c0 (LWP 252095)]

Thread 56 "libobs: graphic" received signal SIGILL, Illegal instruction.
[Switching to Thread 0x7ffeb5ffb6c0 (LWP 252083)]
0x00007fff805a5187 in blur_par_for_output_s0_v1_rebased () from /usr//lib/x86_64-linux-gnu/obs-plugins/obs-virtualbg.so
(gdb) bt full
#0  0x00007fff805a5187 in blur_par_for_output_s0_v1_rebased () at /usr//lib/x86_64-linux-gnu/obs-plugins/obs-virtualbg.so
#1  0x00007fff805aa445 in Halide::Runtime::Internal::worker_thread_already_locked(Halide::Runtime::Internal::work*) ()
    at /usr//lib/x86_64-linux-gnu/obs-plugins/obs-virtualbg.so
#2  0x00007fff805ab3a1 in Halide::Runtime::Internal::worker_thread(void*) () at /usr//lib/x86_64-linux-gnu/obs-plugins/obs-virtualbg.so
#3  0x00007fff805ab40d in Halide::Runtime::Internal::spawn_thread_helper(void*) () at /usr//lib/x86_64-linux-gnu/obs-plugins/obs-virtualbg.so
#4  0x00007ffff42a7fd4 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
        ret = <optimized out>
        pd = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140731951855296,<PHONE_NUMBER>843570091, -320, 16,<PHONE_NUMBER>31584,<PHONE_NUMBER>64960, -5317279444410208853, -5316577220224651861}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
#5  0x00007ffff43285bc in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Same issue.


[Event Request] Function "LogSegment" in Codeunit 5051 "SegManagement"

Dear Team, we would like to have the following publisher added to the Function "LogSegment" in Codeunit 5051 "SegManagement":
procedure LogSegment(SegmentHeader: Record "Segment Header"; Deliver: Boolean; Followup: Boolean)
var
    [...]
begin
    [...]

    LoggedSegment.Reset;
    LoggedSegment.Init;
    [...]
    OnBeforeLoggedSegmentInsert(LoggedSegment);
    LoggedSegment.Insert;
    // START NEW EVENT 1
    OnAfterLoggedSegmentInsert(LoggedSegment, SegmentHeader);
    // END NEW EVENT 1

    [...]

    if SegmentLine.FindSet then begin
        [...]
        repeat
            [...]
            OnBeforeInteractLogEntryInsert(InteractLogEntry, SegmentLine);
            InteractLogEntry.Insert;
            // START NEW EVENT 2
            OnAfterInteractLogEntryInsert(InteractLogEntry, SegmentLine);
            // END NEW EVENT 2
            [...]
        until SegmentLine.Next = 0;
    end else
        Error(Text001, SegmentHeader."No.");

    [...]

    if Followup then begin
        Clear(SegmentHeader);
        SegmentHeader."Campaign No." := CampaignNo;
        SegmentHeader.Description := CopyStr(StrSubstNo(Text002, SegmentNo), 1, 50);
        // START NEW EVENT 3
        OnBeforeInsertFollowUpSegment(SegmentHeader, LoggedSegment);
        // END NEW EVENT 3
        SegmentHeader.Insert(true);
        SegmentHeader.ReuseLogged(LoggedSegment."Entry No.");
        OnAfterInsertFollowUpSegment(SegmentHeader);
    end;

    [...]
end;

// EVENT 1:
[IntegrationEvent(false, false)]
local procedure OnAfterLoggedSegmentInsert(var LoggedSegment: Record "Logged Segment"; SegmentHeader: Record "Segment Header")
begin
end;

// EVENT 2:
[IntegrationEvent(false, false)]
local procedure OnAfterInteractLogEntryInsert(var InteractionLogEntry: Record "Interaction Log Entry"; SegmentLine: Record "Segment Line")
begin
end;

// EVENT 3:
[IntegrationEvent(false, false)]
local procedure OnBeforeInsertFollowUpSegment(var SegmentHeader: Record "Segment Header"; LoggedSegment: Record "Logged Segment")
begin
end;

Hi @TillZoell . Can you explain why do you need for example OnAfterLoggedSegmentInsert(LoggedSegment, SegmentHeader) if there are two lines above OnBeforeInsert event with LoggedSegment as var? Is it because of absence SegmentHeader as parameter in event before or there is any other deep meaning of having one by one events?

Hi @RomanZanizdra . We need the OnAfterLoggedSegmentInsert(...) there for two reasons. The first reason is as you mentioned the abesence of SegmentHeader in the OnBeforeLoggedSegmentInsert(..)-Event. The other reason is that for our logic we need the System-ID of the Logged Segment and the System ID of the Logged Segment is only filled after the Insert. That is why we need the OnAfterLoggedSegmentInsert(...) Event.

Hi @TillZoell , thanks for clarification. Then one more question about third event, OnBeforeInsertFollowUpSegment. There is one more event two lines below, could it be enough if we add LoggedSegment as paramter in this event? If not then why?

Hi @RomanZanizdra , we need the OnBeforeInsertFollowUpSegment because we have created a subscriber to the OnAfterInsert Event of the Segment Header table. In this subscriber we fill some fields with some values. However, if the Segment Header is a FollowUp segment we do not want to execute the OnAfterInsert Event of the Segment Header table because in this case we want to fill some fields differently. So for this we need the OnBeforeInsertFollowUpSegment to fill the fields for the FollowUp Segment there and then simply skip the OnAfterInsert subscriber in the Segment Header table if the fields are already filled.
It would be ideal if the LoggedSegment parameter could be added to the OnAfterInsertFollowUp as you mentioned, because here too we need the System ID of the FollowUp Segment.

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability.


The number of filter for generate offset is [num_deformable_groups * 2 * kH * kW]?

Inside the paper of  Deformable ConvNets V2,  a modulation scalars was used to modulate the input feature amplitudes from different spatial locations/bins.  As the following description,

So, i'm curious about the usage example of DeformConv()  in  test.py  , which setting the number of filter for generate offset as num_deformable_groups * 2 * kH * kW.  Shouldn't it be num_deformable_groups * 3 * kH * kW?
Thanks a lot for your code, hope for your reply.

One more question, i trained a Deformable ConvNets for Classification task and have gained accurancy. Then i extract the value feature map for predicting the offset,  which range from -99 to 99 approximately. This result also bothered me, whether the value should be squeezed to a  reasonable range, such as [-5, 5]

num_deformable_groups * 2 * kH * kW is for normal Deformable Conv.
num_deformable_groups * 3 * kH * kW` is for modulated Deformable Conv.

@xvjiarui Thanks for your reply!  The second question about the offset value range,  any help?


Setup GitHub Action workflow for App Mesh Adapter

Issue Description
This repository needs the same set of GitHub Actions as what is already setup for the meshery-istio adapter.
Please copy the meshery-istio adataper's workflows to the .github folder in this octarine repo.
Update the name in line 1 of the Action from Meshery-Istio to Meshery-app-mesh.

@ashiscs could we do one other update here? Will you rename "main.yml" to be consistent with the other workflow names to "ci.yml"?

Fixed by #12