Allow unrolling an arbitrary number of loops (or at least up to 4) and improve load elimination

I've simplified the lowering code as a first step, but it still expects input in terms of unrolled and tiled. This should be replaced with a vector of integers indicating by how much each loop is unrolled (1 means not unrolled).
The more complicated step will be generalizing the constrained optimization problem within solve_tilesize to an arbitrary number of dimensions.
I think I'll have it handle unrolling a single loop as a special case. The solve_tilesize function tries to occupy all the registers, which wouldn't really be appropriate for a single loop.
It also needs the ability to recognize more kinds of loads that can be eliminated. In particular, it should be able to realize that if an array is accessed with both A[i] and A[i+1], unrolling i will only require a single extra load, not 2 extra loads, because A[i+1] == A[(i+1)].
The motivating example was inspired by @timholy , although before LoopVectorization is going to see major benefits over the current performance, it will have to be able to realize t
Most of the code here is also in the offset array tests.
using LoopVectorization, OffsetArrays, BenchmarkTools, Test
function old2d!(out::AbstractMatrix, A::AbstractMatrix, kern)
    rng1k, rng2k = axes(kern)
    rng1,  rng2  = axes(out)
    for j in rng2, i in rng1
        tmp = zero(eltype(out))
        for jk in rng2k, ik in rng1k
            tmp += A[i+ik,j+jk]*kern[ik,jk]
        end
        out[i,j] = tmp
    end
    out
end
function avx2douter!(out::AbstractMatrix, A::AbstractMatrix, kern)
    rng1k, rng2k = axes(kern)
    rng1,  rng2  = axes(out)
    @avx for j in rng2, i in rng1
        tmp = zero(eltype(out))
        for jk in rng2k, ik in rng1k
            tmp += A[i+ik,j+jk]*kern[ik,jk]
        end
        out[i,j] = tmp
    end
    out
end

T = Float32
A = rand(T, 100, 100);
kern = OffsetArray(rand(T, 3, 3), -1:1, -1:1);
out1 = OffsetArray(similar(A, size(A).-2), 1, 1);   # stay away from the edges of A
out2 = similar(out1); out3 = similar(out1);

@avx yields a substantial improvement:
julia> @benchmark old2d!($out1, $A, $kern)
BenchmarkTools.Trial:
  memory estimate:  0 bytes
  allocs estimate:  0
  --------------
  minimum time:     64.591 μs (0.00% GC)
  median time:      64.655 μs (0.00% GC)
  mean time:        65.363 μs (0.00% GC)
  maximum time:     88.856 μs (0.00% GC)
  --------------
  samples:          10000
  evals/sample:     1

julia> @benchmark avx2douter!($out2, $A, $kern)
BenchmarkTools.Trial:
  memory estimate:  0 bytes
  allocs estimate:  0
  --------------
  minimum time:     3.429 μs (0.00% GC)
  median time:      3.451 μs (0.00% GC)
  mean time:        3.458 μs (0.00% GC)
  maximum time:     8.495 μs (0.00% GC)
  --------------
  samples:          10000
  evals/sample:     8

julia> @test out1 ≈ out2
Test Passed

This yields a substantial improvement, but we'd naturally always wonder if we can do better. Let's find out what it's doing.
julia> q2d = :(for j in rng2, i in rng1
       tmp = zero(eltype(out))
       for jk in rng2k, ik in rng1k
       tmp += A[i+ik,j+jk]*kern[ik,jk]
       end
       out[i,j] = tmp
       end);

julia> lsq2d = LoopVectorization.LoopSet(q2d); LoopVectorization.choose_order(lsq2d)
([:j, :i, :jk, :ik], :ik, :j, :i, 4, 4)

This means that it orders the loops [:j, :i, :jk, :ik] (which happens to be the same order in which they were written, but this is not true in general).
The next two symbols indicate that ik and j are unrolled (4x and 4x, respectively), while i is "vectorized". These numbers are machine-dependent, so you're likely to at least see different unroll factors if you don't have avx512 (i.e., something other than 4 and 4).
The most obvious problem we may notice here is that the ik loop is only 3 iterations long, so unrolling by 4 is excessive. We can improve that with static size information:
using LoopVectorization.VectorizationBase: StaticUnitRange
struct SizedOffsetMatrix{T,LR,UR,LC,RC} <: AbstractMatrix{T}
    data::Matrix{T}
end
Base.axes(::SizedOffsetMatrix{T,LR,UR,LC,UC}) where {T,LR,UR,LC,UC} = (StaticUnitRange{LR,UR}(),StaticUnitRange{LC,UC}())
@generated function LoopVectorization.stridedpointer(A::SizedOffsetMatrix{T,LR,UR,LC,RC}) where {T,LR,UR,LC,RC}
    quote
        $(Expr(:meta,:inline))
        LoopVectorization.OffsetStridedPointer(
            LoopVectorization.StaticStridedPointer{$T,Tuple{1,$(UR-LR+1)}}(pointer(A.data)),
            ($(LR-2), $(LC-2))
        )
    end
end
Base.getindex(A::SizedOffsetMatrix, i, j) = LoopVectorization.vload(LoopVectorization.stridedpointer(A), (i,j)) # only needed to print
skern = SizedOffsetMatrix{T,-1,1,-1,1}(parent(kern));

Getting show to work off the AbstractArray interface would take some more methods.
To see that this works, we'll have to inspect a LoopSet object created with type information (not from an expression). The @avx_debug macro lets us do this, but requires all the symbols in the loop to be defined (otherwise, which object's types will it be reading?)
julia> rng1,  rng2  = CartesianIndices(out1).indices;

julia> rng1k, rng2k = axes(skern);

julia> ls2dstatic = LoopVectorization.@avx_debug for j in rng2, i in rng1
       tmp = zero(eltype(out))
       for jk in rng2k, ik in rng1k
       tmp += A[i+ik,j+jk]*skern[ik,jk]
       end
       out1[i,j] = tmp
       end;
OPS = Tuple{:numericconstant,Symbol("##zero#1278"),LoopVectorization.OperationStruct(0x0000000000000012, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000, LoopVectorization.constant, 0x00, 0x01),:i,:i,LoopVectorization.OperationStruct(0x0000000000000002, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000, LoopVectorization.loopvalue, 0x00, 0x02),:ik,:ik,LoopVectorization.OperationStruct(0x0000000000000004, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000, LoopVectorization.loopvalue, 0x00, 0x03),:LoopVectorization,:+,LoopVectorization.OperationStruct(0x0000000000000024, 0x0000000000000000, 0x0000000000000000, 0x0000000000000203, LoopVectorization.compute, 0x00, 0x04),:j,:j,LoopVectorization.OperationStruct(0x0000000000000001, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000, LoopVectorization.loopvalue, 0x00, 0x05),:jk,:jk,LoopVectorization.OperationStruct(0x0000000000000003, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000, LoopVectorization.loopvalue, 0x00, 0x06),:LoopVectorization,:+,LoopVectorization.OperationStruct(0x0000000000000013, 0x0000000000000000, 0x0000000000000000, 0x0000000000000506, LoopVectorization.compute, 0x00, 0x07),:LoopVectorization,:getindex,LoopVectorization.OperationStruct(0x0000000000002413, 0x0000000000000000, 0x0000000000000000, 0x0000000000000407, LoopVectorization.memload, 0x01, 0x08),:LoopVectorization,:getindex,LoopVectorization.OperationStruct(0x0000000000000043, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000, LoopVectorization.memload, 0x02, 0x09),:numericconstant,Symbol("##reductzero#1290"),LoopVectorization.OperationStruct(0x0000000000000012, 0x0000000000000000, 0x0000000000000043, 0x0000000000000000, LoopVectorization.constant, 0x00, 0x0a),:LoopVectorization,:vfmadd,LoopVectorization.OperationStruct(0x0000000000002413, 0x0000000000000043, 0x0000000000000000, 0x000000000008090a, LoopVectorization.compute, 0x00, 0x0a),:LoopVectorization,:reduce_to_add,LoopVectorization.OperationStruct(0x0000000000000012, 0x0000000000000043, 0x0000000000000000, 0x0000000000000b01, LoopVectorization.compute, 0x00, 0x01),:LoopVectorization,:setindex!,LoopVectorization.OperationStruct(0x0000000000000021, 0x0000000000000000, 0x0000000000000000, 0x000000000000000c, LoopVectorization.memstore, 0x03, 0x0b)}
ARF = Tuple{LoopVectorization.ArrayRefStruct(0x0000000000000202, 0x0000000000000407, 0xffffffffffffffde),LoopVectorization.ArrayRefStruct(0x0000000000000101, 0x0000000000000403, 0xffffffffffffff80),LoopVectorization.ArrayRefStruct(0x0000000000000101, 0x0000000000000201, 0xffffffffffffff8f)}
AM = Tuple{0,Tuple{},Tuple{},Tuple{},Tuple{},Tuple{(1, LoopVectorization.IntOrFloat),(10, LoopVectorization.IntOrFloat)},Tuple{}}
LB = Tuple{UnitRange{Int64},UnitRange{Int64},StaticUnitRange{-1,1},StaticUnitRange{-1,1}}
vargs = (VectorizationBase.PackedStridedPointer{Float32,1}(Ptr{Float32} @0x000055dde45035c0, (100,)), LoopVectorization.OffsetStridedPointer{Float32,2,VectorizationBase.StaticStridedPointer{Float32,Tuple{1,3}}}(VectorizationBase.StaticStridedPointer{Float32,Tuple{1,3}}(Ptr{Float32} @0x00007fd441216e50), (-3, -3)), LoopVectorization.OffsetStridedPointer{Float32,2,VectorizationBase.PackedStridedPointer{Float32,1}}(VectorizationBase.PackedStridedPointer{Float32,1}(Ptr{Float32} @0x000055dde34cd0c0, (98,)), (0, 0)))

julia> LoopVectorization.choose_order(ls2dstatic)
([Symbol("##n#1299"), Symbol("##n#1302"), Symbol("##n#1303"), Symbol("##n#1304")], Symbol("##n#1304"), Symbol("##n#1299"), Symbol("##n#1302"), 3, 4)

It gensyms names, but we can figure out that Symbol("##n#1304") is the ik loop as before, but it is now unrolled by a factor of 3, matching the length of this loop.
LoopVectorization's optimizer uses this static size information, but much of the lowering does not: it'll still generate code to handle other sizes. Addressing that's been a low priority, because I've found LLVM to be very good at eliminating all the code handling other sizes.
This yields a sizeable performance improvement:
julia> @benchmark avx2douter!($out3, $A, $skern)
BenchmarkTools.Trial:
  memory estimate:  0 bytes
  allocs estimate:  0
  --------------
  minimum time:     2.713 μs (0.00% GC)
  median time:      2.726 μs (0.00% GC)
  mean time:        2.731 μs (0.00% GC)
  maximum time:     5.395 μs (0.00% GC)
  --------------
  samples:          10000
  evals/sample:     9

julia> @test out1 ≈ out3
Test Passed

Yet, I think ideally, it ought to be much more aggressive.
It's important to emphasize that most modern CPU's throughput for unaligned loads is half that of fma instructions. This means that naively following how the function is written, where you load from both A and kern for each fma, it will spend up to 4 times longer loading memory than it will computing arithmetic. Loading and arithmetic don't really interfere, so the time is going to be governed largely by memory loading; anything we can do will help.
Given static size information, it should completely unroll the small -1:1 loops, and then additionally unroll the other loops to save on redundant loads. Then we know for sure it is not reloading kern, and the additional unrolling on the i and j loops will yield savings because of all the reuse we get since many of them will be the same across iterations.
function avx2dunrolled!(out::AbstractMatrix, A::AbstractMatrix, kern::SizedOffsetMatrix{T,-1,1,-1,1}) where {T}
    rng1,  rng2  = axes(out)
    Base.Cartesian.@nexprs 3 jk -> Base.Cartesian.@nexprs 3 ik -> kern_ik_jk = kern[ik-2,jk-2]
    @avx for j in rng2, i in rng1
        tmp_0 = zero(eltype(out))
        Base.Cartesian.@nexprs 3 jk -> Base.Cartesian.@nexprs 3 ik -> tmp_{ik+(jk-1)*3} = A[i+(ik-2),j+(jk-2)] * kern_ik_jk + tmp_{ik+(jk-1)*3-1}
        out[i,j] = tmp_9
    end
    out
end

This yields
julia> @benchmark avx2dunrolled!($out3, $A, $skern)
BenchmarkTools.Trial:
  memory estimate:  0 bytes
  allocs estimate:  0
  --------------
  minimum time:     1.990 μs (0.00% GC)
  median time:      1.997 μs (0.00% GC)
  mean time:        2.001 μs (0.00% GC)
  maximum time:     3.033 μs (0.00% GC)
  --------------
  samples:          10000
  evals/sample:     10

julia> @test out1 ≈ out3
Test Passed

Another big improvement. But, LoopVectorization doesn't realize how aggressive it can get yet, due to not itself realizing that many of the loads alias. LLVM does, so it should eliminate redundant loads and give us the performance benefits, even if we cheat to make LoopVectorization be more aggressive.
function avx2dunrolled4x4!(out::AbstractMatrix, A::AbstractMatrix, kern::SizedOffsetMatrix{T,-1,1,-1,1}) where {T}
    rng1,  rng2  = axes(out)
    Base.Cartesian.@nexprs 3 jk -> Base.Cartesian.@nexprs 3 ik -> kern_ik_jk = kern[ik-2,jk-2]
    @avx tile=(4,4) for j in rng2, i in rng1
        tmp_0 = zero(eltype(out))
        Base.Cartesian.@nexprs 3 jk -> Base.Cartesian.@nexprs 3 ik -> tmp_{ik+(jk-1)*3} = A[i+(ik-2),j+(jk-2)] * kern_ik_jk + tmp_{ik+(jk-1)*3-1}
        out[i,j] = tmp_9
    end
    out
end

I'm specifying 4,4 here, and performance looks quite good. Without AVX512, it is likely that smaller numbers will give you better performance.
The generated assembly shows lots of chunks that look like this:
        vfmadd213ps     %zmm18, %zmm26, %zmm27 # zmm27 = (zmm26 * zmm27) + zmm18
        vfmadd213ps     %zmm18, %zmm28, %zmm21 # zmm21 = (zmm28 * zmm21) + zmm18
        vfmadd231ps     56(%r8,%rcx), %zmm10, %zmm1 # zmm1 = (zmm10 * mem) + zmm1
        vfmadd231ps     %zmm10, %zmm8, %zmm25 # zmm25 = (zmm8 * zmm10) + zmm25
        vfmadd231ps     %zmm10, %zmm19, %zmm27 # zmm27 = (zmm19 * zmm10) + zmm27
        vfmadd231ps     %zmm10, %zmm23, %zmm21 # zmm21 = (zmm23 * zmm10) + zmm21
        vfmadd231ps     60(%r8,%rcx), %zmm11, %zmm1 # zmm1 = (zmm11 * mem) + zmm1
        vfmadd231ps     %zmm11, %zmm24, %zmm25 # zmm25 = (zmm24 * zmm11) + zmm25
        vfmadd231ps     %zmm11, %zmm20, %zmm27 # zmm27 = (zmm20 * zmm11) + zmm27
        vfmadd231ps     %zmm11, %zmm22, %zmm21 # zmm21 = (zmm22 * zmm11) + zmm21
        vfmadd231ps     %zmm12, %zmm26, %zmm25 # zmm25 = (zmm26 * zmm12) + zmm25
        vfmadd231ps     %zmm12, %zmm28, %zmm27 # zmm27 = (zmm28 * zmm12) + zmm27
        vfmadd213ps     %zmm1, %zmm12, %zmm2 # zmm2 = (zmm12 * zmm2) + zmm1
        vmovups 52(%r8,%rbp), %zmm1
        vmovups 56(%r8,%rbp), %zmm29
        vmovups 60(%r8,%rbp), %zmm30
        vfmadd231ps     %zmm12, %zmm1, %zmm21 # zmm21 = (zmm1 * zmm12) + zmm21
        vfmadd231ps     %zmm13, %zmm19, %zmm25 # zmm25 = (zmm19 * zmm13) + zmm25
        vfmadd213ps     %zmm2, %zmm13, %zmm8 # zmm8 = (zmm13 * zmm8) + zmm2
        vfmadd231ps     %zmm13, %zmm23, %zmm27 # zmm27 = (zmm23 * zmm13) + zmm27
        vfmadd231ps     %zmm13, %zmm29, %zmm21 # zmm21 = (zmm29 * zmm13) + zmm21
        vfmadd231ps     %zmm14, %zmm20, %zmm25 # zmm25 = (zmm20 * zmm14) + zmm25
        vfmadd231ps     %zmm14, %zmm22, %zmm27 # zmm27 = (zmm22 * zmm14) + zmm27
        vfmadd231ps     %zmm14, %zmm30, %zmm21 # zmm21 = (zmm30 * zmm14) + zmm21
        vfmadd213ps     %zmm8, %zmm14, %zmm24 # zmm24 = (zmm14 * zmm24) + zmm8
        vfmadd213ps     %zmm24, %zmm15, %zmm26 # zmm26 = (zmm15 * zmm26) + zmm24
        vfmadd213ps     %zmm25, %zmm15, %zmm28 # zmm28 = (zmm15 * zmm28) + zmm25
        vfmadd213ps     %zmm27, %zmm15, %zmm1 # zmm1 = (zmm15 * zmm1) + zmm27
        vfmadd231ps     52(%r8,%rbx), %zmm15, %zmm21 # zmm21 = (zmm15 * mem) + zmm21
        vfmadd213ps     %zmm28, %zmm16, %zmm23 # zmm23 = (zmm16 * zmm23) + zmm28
        vfmadd213ps     %zmm26, %zmm16, %zmm19 # zmm19 = (zmm16 * zmm19) + zmm26
        vfmadd213ps     %zmm1, %zmm16, %zmm29 # zmm29 = (zmm16 * zmm29) + zmm1
        vfmadd231ps     56(%r8,%rbx), %zmm16, %zmm21 # zmm21 = (zmm16 * mem) + zmm21
        vfmadd213ps     %zmm23, %zmm17, %zmm22 # zmm22 = (zmm17 * zmm22) + zmm23
        vfmadd213ps     %zmm29, %zmm17, %zmm30 # zmm30 = (zmm17 * zmm30) + zmm29
        vfmadd231ps     60(%r8,%rbx), %zmm17, %zmm21 # zmm21 = (zmm17 * mem) + zmm21
        vfmadd213ps     %zmm19, %zmm17, %zmm20 # zmm20 = (zmm17 * zmm20) + zmm19

Mountains of vectorized arithmetic. (Note however that many of the vfmadd___ps instructions access mem)
julia> @benchmark avx2dunrolled4x4!($out3, $A, $skern)
BenchmarkTools.Trial:
  memory estimate:  0 bytes
  allocs estimate:  0
  --------------
  minimum time:     1.649 μs (0.00% GC)
  median time:      1.667 μs (0.00% GC)
  mean time:        1.670 μs (0.00% GC)
  maximum time:     2.788 μs (0.00% GC)
  --------------
  samples:          10000
  evals/sample:     10

julia> @test out1 ≈ out3
Test Passed

Finally, we can align the loads and stores by spacing the columns of A and out at multiples of 64-byte intervals (64 bytes is 16 x Float32):
julia> Av = view(similar(A, 112, 100), 1:100, :) .= A;

julia> outv = OffsetArray(view(similar(A, 112, 98), 1:98, :), 1, 1);

julia> @benchmark avx2dunrolled4x4!($outv, $Av, $skern)
BenchmarkTools.Trial:
  memory estimate:  0 bytes
  allocs estimate:  0
  --------------
  minimum time:     1.543 μs (0.00% GC)
  median time:      1.553 μs (0.00% GC)
  mean time:        1.555 μs (0.00% GC)
  maximum time:     2.779 μs (0.00% GC)
  --------------
  samples:          10000
  evals/sample:     10

julia> @test out1 ≈ outv
Test Passed

That's more than 40x the original version without LoopVectorization!
But it'd be great if we could get this performance automatically (or, at least automatically given size information), without the need for both Base.Cartesian unrolling and manually specifying additional unrolling behavior on top of it.

Dang! A real tour de force. I had only just started thinking along similar lines, but had gotten nowhere close to where you've arrived. I think ImageFiltering could easily have blocks that look like
    if all(s->s <= 9, size(kern))
        wrappedkernel = SizedOffsetArray{params...}(kern)
        _imfilter!(out, img, wrappedkernel)
    else
        _imfilter!(out, img, kernel)
    end

There's going to be dynamic dispatch for the Sized case but that's probably not a problem in practice unless people are filtering really tiny arrays. We could even pull out very common cases (e.g., axes are (-1:1, -1:1)) and do what is essentially manual union-splitting.
Is it worth asking whether it makes sense to just provide static size information about the first dimension of the kernel? That would make it easy to have a block like
    if axes(kern, 1) === Base.IdentityUnitRange(-1:1)
        _imfilter!(out, img, StaticSize1{-1,1}(kern))
    if axes(kern, 1) === Base.IdentityUnitRange(0:2)
        _imfilter!(out, img, StaticSize1{0,2}(kern))
    if axes(kern, 1) === Base.IdentityUnitRange(-2:0)
        _imfilter!(out, img, StaticSize1{-2,0}(kern))
    elseif  axes(kern, 1) === Base.IdentityUnitRange(-2:2)
        _imfilter!(out, img, StaticSize1{-2,2}(kern))
    elseif ...
    else ...
    end

and it would never need dynamic dispatch.
My suspicion is that, given your demo above, this particular use of dynamic dispatch is not worth worrying about and we should provide static information for any reasonably-small kernel. We're talking microseconds vs nanoseconds.

I added benchmarks over a size range of 2:256 for out using double precision.
The unrolled avx function was just like avx2dunrolled! above, meaning I did not add a tile= argument.
Regular/Base julia actually performed equally well, as did all the other compilers, with the exception of ifort. I guess none of them did anything fancy (i.e., block).
Because (for now), the base Julia version is equally fast when completely unrolled, compiles much more quickly, and does not require any dependencies, it's worth considering. For reference, the benchmarked function was (source):
function filter2dunrolled!(out::AbstractMatrix, A::AbstractMatrix, kern::SizedOffsetMatrix{T,-1,1,-1,1}) where {T}
    rng1,  rng2  = axes(out)
    Base.Cartesian.@nexprs 3 jk -> Base.Cartesian.@nexprs 3 ik -> kern_ik_jk = kern[ik-2,jk-2]
    @inbounds for j in rng2
        @simd ivdep for i in rng1
            tmp_0 = zero(eltype(out))
            Base.Cartesian.@nexprs 3 jk -> Base.Cartesian.@nexprs 3 ik -> tmp_{ik+(jk-1)*3} =  Base.FastMath.add_fast(Base.FastMath.mul_fast(A[i+(ik-2),j+(jk-2)], kern_ik_jk), tmp_{ik+(jk-1)*3-1})
            out[i,j] = tmp_9
        end
    end
    out
end

so an @generated function _imfilter! could see a lot of improvement as is for all the small kernel sizes.
Once I make the changes proposed in this issue, @avx should improve to be more inline with the tile= versions. Or just using it now and specifying the tile= argument should yield better performance.
I like the idea of manual union splitting here. I think it would be best to pass both axis parameters, because we want small kernels to be completely unrolled.
Although, as you note, nanoseconds penalty for a dynamic dispatch that earns microseconds of saving is well worth it.
Compile times could be an issue if kernel sizes change often.
Also, for some reason, the unrolled versions are all about half a microsecond slower today (and old2d is now 170 microseconds instead of 70), and tile=(2,2) is now the fastest (at 2.2 microseconds, 2 when aligning columns). That's a pretty serious regression. I haven't been able to find out why, and I haven't been able to pin down any differences. Although I think I'm seeing a lot more leaq and movqs now than I did before.

Very interesting! I get a 2.5x performance improvement from imfilter just by switching to a StaticArray, but this gives yet another 10x improvement. Since it's such a simple optimization I might steal it for ImageFiltering now (and credit the PR to you).

I made a couple changes and updated the benchmarks.
I'm now using a hack to mark the arrays as not aliasing one another. This works by defining an LLVM function that returns a ptr with the noalias attribute and making sure that it is not inlined -- if it were, LLVM will eliminate it and discard the attribute.
However, this means using the hack introduces overhead for one non-inlined function call per array, even though the function is a no-op. In the case of dot products, which are very fast, this actually takes a significant bite out of their performance.
Maybe one day I'll look more into what it would take to try and add an @restrict macro, where function foo(@restrict(a), b) #do things end would add the noalias attribute to a like the restrict keyword in C. I'd use it in the _avx_! definition, since this library makes those assumptions already.
But in the case of most of the other benchmarks, a handful of nanoseconds of overhead gets lost in the noise.
For the unrolled image filtering benchmark, LLVM is now again eliminating redundant loads, restoring performance.

I follow this work and I am totally amazed by your work ! A dummy question : I wonder why a "hack" is required for the restrict information: it cannot be passed explicitly to LLVM ? (LLVM is used to compile C which do have the restrict keyword).

Thankfully, I found a way to remove the hack this morning. I am rerunning all the benchmarks. (When they're done, I'll issue new releases of VectorizationBase followed by SIMDPirates, and then push those benchmark results and latest changes to LoopVectorization to master.)
LLVM lets you add noalias as a function parameter attribute, which is what restrict in C does.
That would be exactly what I want, but I'm pretty sure it would require a PR to Julia to implement it. (Having an @restrict macro would be cool!).
Currently, I cannot add attributes to Julia function parameters. I also cannot define my Julia function inside an LLVM call, and while I can call a ccallable Julia function from llvmcall, it won't inline, meaning it won't recompile with the noalias information. Plus, the ccallable requirement means there's only a single method, which means we'd need to figure out a knew way of doing things.
LLVM also allows the noalias attribute to be added to function return values. This is what I did with the hack. Unfortunately, if the call is inlined, the attribute gets lost, meaning I need noinline.
What I'm using now is:

noalias and alias.scope metadata. These don't seem to work with masked operations.
Reordering operations to be a little better about placing stores last. load(A,i); store(B,j); load(A,i) will stop the second load from being eliminated, because the store may have changed the contents. If I instead have load(A,i); load(A,i); store(B,j), LLVM will eliminate the second load automatically (assuming there isn't another store hiding in between them).

Latest filtering benchmarks: LoopVectorization is now as fast with a dynamically sized kernel matrix as the others are with statically sized. It's much faster when it also has a statically sized kernel.

LoopVectorization now achieves roughly 45-50 double precision GFLOPS on my home computer with dynamically sized kernels over the size range of about N = 40 x 40 through 220 x 220.
All of the alternatives I benchmarked only got up to around 40 GFLOPS with statically sized kernels, even with manual unrolling (in which case LoopVectorization hit the 55 to 60 GFLOPS range).
I also used CartesianIndexing with Julia when not manually unrolling:
function filter2davx!(out::AbstractMatrix, A::AbstractMatrix, kern)
    @avx for J in CartesianIndices(out)
        tmp = zero(eltype(out))
        for I ∈ CartesianIndices(kern)
            tmp += A[I + J] * kern[I]
        end
        out[J] = tmp
    end
    out
end

Sorry I have been unresponsive, I have been fairly tied up with helping manage the university's COVID-19 shutdown program and a spate of student advising.
This is unbelievably impressive!! I have to start playing with this pronto...which means it still might be a few days, but this is tremendously exciting.

A lot of universities are abruptly changing to online-only classes, which must be quite a transition.

This is unbelievably impressive!! I have to start playing with this pronto...which means it still might be a few days, but this is tremendously exciting.

One of the benefits of having this as Julia code we can hack on is that we can fiddle with things until they're fast.
I haven't addressed this issue in a too disciplined a way, and instead hacked on some of the code to produce desired behavior. Thus it may need some extra fiddling to also get the desired performance with AVX(2) instead of AVX512 (like on the computer I ran the benchmarks on).
Some things you can try fiddling with are the maximum unrolling factor, and convolution cost factor.
Convolution cost factor tries to recognize a pair of loops where, if you unroll both of the, it can CSE loads.
The correct thing to do would be eliminate the costs of eliminated loads -- no reciprocal throughput or register pressure.
Actually modeling this correctly would require a little restructuring, and changing the solve_tilesize code to be able to handle costs that don't simply change in direct proportion with the unroll factors (U and T).
The maximum unroll factor of 6 helped, because when it was set to 8, it would choose to unroll the convolved column loops by 1 and 8, which doesn't actually allow for any eliminated loads at all. Capping it at 6 resulted in factors of 3 and 6, which does allow loads to be eliminated.
Because convolution cost factor just decreases the load costs by some factor when both column loops are unrolled (even if unrolled by just "1"; because the actual number isn't determined yet when convolution cost factor is called) instead of by the amount of loads getting eliminated, it can choose eventual unroll factors that don't eliminate many loads at all.
You may want to try different values in place of the 4 in the maxTbase = maxUbase = VectorizationBase.REGISTER_COUNT == 32 ? 6 : 4 line. I'd be inclined to keep the 6 for architectures with 32 registers per core.
6 regardless of the register count may work. Note that whenever you change this, a few choose_order tests will fail. Not a big deal; update them (the tests are there largely so I'm aware of things changing, and know that I should benchmark to look for possible regressions).
The function convolution_cost_factor uses isoptranslation to look for convolving loops that could allow loads to be eliminated. As an approximation to eliminating loads, it reduces their cost, both in reciprocal throughput and register pressure. However, LLVM likes to unroll short statically sized loops, which would of course inflate the register pressure beyond solve_tilesize is estimating, leading to suboptimal decisions.
So if some other loop that isn't already being unrolled by LoopVectorization is short enough that LLVM is likely to want to unroll that loop itself, convolution_cost_factor will not deflate the register pressure (but it still decreases the reciprocal throughput).
If the hacks start getting more complicated than the correct approach, it'd be high time to be correct.

A lot of universities are abruptly changing to online-only classes, which must be quite a transition.

The far harder part in my world has been shutting down all but nonessential experimental research, forming committees to come up with standards for what constitutes essential and then rendering verdicts on requests to continue, and finally supporting people whose careers are being disrupted. All incredibly necessary under the circumstances but it's a lot of work to stop all this on a dime. I am grateful that so much of my life is computational in nature, but still the majority of people who work with me do bench research.


Issues with ./inference_demo.ipynb

Hi,
Congratulations on the great work!
I am trying to run the inference_demo.ipynb you provided, however, I am unable to get the correct results. The flow and features look different than your reported results.
I noticed that you ran this:
path = 'humangps_pretrained'
model = tf.saved_model.load(path)
Would you please share the humangps_pretrained model.
Thanks!

Hi,
Thanks for your interest! We provide a script in this repository to download pretrained model, we can run "bash download_model.sh" to download it.
Best,

Thanks.

Hi,
Sorry for the confusion. There is a bug in the demo code and I just removed the rebundant code in the demo code. The bug should be fixed.
The model should be loaded with
checkpoint = tf.train.Checkpoint(
      model=model,
      step=tf.Variable(-1, dtype=tf.int64),
      training_finished=tf.Variable(False, dtype=tf.bool),
  )
status = checkpoint.restore(checkpoint_path)
status.assert_existing_objects_matched()
status.expect_partial()
instead of
path = 'humangps_pretrained'
model = tf.saved_model.load(path)
Thanks for reporting the issue!


error while first build/start

you have massive error in library see this
This warning is caused by a @providesModule declaration with the same name across two different files.
jest-haste-map: @providesModule naming collision:
  Duplicate module name: RCTEventEmitter
  Paths<EMAIL_ADDRESS>collides with /Users/yeoman/Development/Xeront/ReactNative/ispApp/node_modules/react-native/Libraries/EventEmitter/RCTEventEmitter.js

This warning is caused by a @providesModule declaration with the same name across two different files.
jest-haste-map: @providesModule naming collision:
  Duplicate module name: NativeEventEmitter
  Paths<EMAIL_ADDRESS>collides with /Users/yeoman/Development/Xeront/ReactNative/ispApp/node_modules/react-native/Libraries/EventEmitter/NativeEventEmitter.js

This warning is caused by a @providesModule declaration with the same name across two different files.
jest-haste-map: @providesModule naming collision:
  Duplicate module name: RCTNativeAppEventEmitter
  Paths<EMAIL_ADDRESS>collides with /Users/yeoman/Development/Xeront/ReactNative/ispApp/node_modules/react-native/Libraries/EventEmitter/RCTNativeAppEventEmitter.js

This warning is caused by a @providesModule declaration with the same name across two different files.
jest-haste-map: @providesModule naming collision:
  Duplicate module name: Linking
  Paths<EMAIL_ADDRESS>collides with /Users/yeoman/Development/Xeront/ReactNative/ispApp/node_modules/react-native/Libraries/Linking/Linking.js

This warning is caused by a @providesModule declaration with the same name across two different files.
jest-haste-map: @providesModule naming collision:
  Duplicate module name: Share
  Paths<EMAIL_ADDRESS>collides with /Users/yeoman/Development/Xeront/ReactNative/ispApp/node_modules/react-native/Libraries/Share/Share.js

This warning is caused by a @providesModule declaration with the same name across two different files.
jest-haste-map: @providesModule naming collision:
  Duplicate module name: promiseRejectionIsError
  Paths<EMAIL_ADDRESS>collides with /Users/yeoman/Development/Xeront/ReactNative/ispApp/node_modules/react-native/Libraries/promiseRejectionIsError.js

This warning is caused by a @providesModule declaration with the same name across two different files.
jest-haste-map: @providesModule naming collision:
  Duplicate module name: Promise
  Paths<EMAIL_ADDRESS>collides with /Users/yeoman/Development/Xeront/ReactNative/ispApp/node_modules/react-native/Libraries/Promise.js

This warning is caused by a @providesModule declaration with the same name across two different files.
jest-haste-map: @providesModule naming collision:
  Duplicate module name: react-native
  Paths<EMAIL_ADDRESS>collides with /Users/yeoman/Development/Xeront/ReactNative/ispApp/node_modules/react-native/package.json

This warning is caused by a @providesModule declaration with the same name across two different files.
jest-haste-map: @providesModule naming collision:
  Duplicate module name: react-native
  Paths<EMAIL_ADDRESS>collides with /Users/yeoman/Development/Xeront/ReactNative/ispApp/node_modules/react-native/package.json

This warning is caused by a @providesModule declaration with the same name across two different files.

and the error goes on. could you please check it and fix? I tried to delete react native from node_modules as mentioned here https://github.com/Ramotion/react-native-circle-menu/issues/4
but then I got Touchable error.

Any updates? I have the same issue

This is duplicate of #4


Creation of TIDs takes Too Long

The current implementation of creating and uploading TIDs to a keystore is suboptimal and takes too long (>10s) such that a timeout it triggered.

The problems seems to be gPAS which needs roughly 1s to create 100 pseudonyms and doesn't seem to know async...


[ceres:x64-windows] example code build failure

Compiler: Visual studio 2019
OS: Windows 10
After installing ceres:x64-windows, try to build the example code helloworld.cc. The following error occurs:
F:\vcpkg\installed\x64-windows\include\ceres\jet.h(583,36): error C3861: 'M_2_SQRTPI': identifier not found
This is because that visual studio requires _USE_MATH_DEFINES before including cmath or math.h, see docs
Proposed solution
Add a patch file to add _USE_MATH_DEFINES before including cmath or math.h

Hi @bhwqy, thanks for reporting this issue!
I can't repro it on my machine.
Could you provide a sample project?
Thanks.

For cpp sources, use macros _USE_MATH_DEFINES should include cmath instead of math.h
And cmath is already included in jet.h.
See https://docs.microsoft.com/en-us/cpp/c-runtime-library/math-constants?view=msvc-160#syntax

Hi @JackBoosY , here is a sample project which fails to build on my machine.
SampleCode.zip
Reproduce requires a higher version of Visual Studio and compiler option /permissive- must be declared. It seems that _USE_MATH_DEFINES is not a part of C++ standard. MSVC will build the code for strict conformance with  /permissive- specified, which leads to a build failure.
Check /permissive- for more details.

Confirmed, but I'm not clear if this is a upstream bug.

Okay, that's because _USE_MATH_DEFINES is not automatically declared in the custom project.
The current integrated MSVC project is flawed. I think we should add the function of automatically declaring macros to ports in the future.

IMO this is an upstream bug

@BillyONeal Probably not, Ceres' CMakeLists does export the macro _USE_MATH_DEFINES, but this is not automatically set in its source code.

@BillyONeal Probably not, Ceres' CMakeLists does export the macro _USE_MATH_DEFINES, but this is not automatically set in its source code.

When we are doing the VS integration scenario, there is no such thing as an "exported macro" -- that concept is entirely a CMake-ism and there's no CMake there. Moreover, when integrating with VS, we don't know what libraries the user is really using -- we reverse engineer what they need by looking at the resulting output binary.


None of the MLIR Optimization Passes are enabled (registered 2)

Hi,
Getting the error "None of the MLIR Optimization Passes are enabled (registered 2)" after that the RetinaNet Object detection training got stuck. I use TensorFlow 2.6.0 version.
Could you please help in resolving the error.

Can you post your hardware config?

I tried the model training (https://keras.io/examples/vision/retinanet/) in Docker container (in my Windows10 laptop as well as AWS EC2 ) and got the error Got the error "None of the MLIR Optimization Passes are enabled (registered 2)".
The Dockerfile details are, (docker image contains the below packages)
FROM tensorflow/tensorflow
RUN apt-get update -y
RUN apt-get install -y python
RUN pip install opencv-python &&
pip install opencv-contrib-python
RUN apt install -y libgl1-mesa-glx
RUN	pip install tensorflow_datasets
RUN	pip install numpy
RUN pip install matplotlib
As discussed at https://discuss.tensorflow.org/t/none-of-the-mlir-optimization-passes-are-enabled/2247/5, now I am creating the COCO tfrecords freshly in the same docker environment and will try the Training.
However, Training works fine with Google Collab(Jupyter notebook)
Please let me know do you have any input on the mentioned error.
Thanks.

The hang issue is not related to MLIR optimization, its related to batch_size and tf.data.Dataset.
When I use "batch_size > 16", it hangs on "model.fit" and continue to occupy the CPU.
If the batch_size < 16,there is no issue.
Thanks.

Check https://github.com/srihari-humbarwadi/retinanet-tensorflow2.x, this has much better performance than the tutorial


Feature: Projects listed by commit activity

It would be interesting to have the page of projects where the project could be ordered, using their commit activity or by using the points burn graph

yes - would be wonderful to have more options - we do currently have them listed at the moment by some function of github activity - however I think we need to split out things that are developer facing from those are charity facing, i.e. be thinking about all these things in terms of our key stakeholders for the site or sites


[component]: Link list

Description
Implement styles for the link list component
Design
https://www.figma.com/design/xZ0IW0MJO0vnFicmrHiKaY/Components-Post?node-id=30036-39980&node-type=frame&t=9S5ISrEjDt8dXCYT-0

[x] Documentation final

Tokens

[ ] Tokens for this component are ready

## Tasks
- [ ] Review Design (All states present? Possible to implement?)
- [ ] #3496
- [ ] #3437
- [ ] HTML/CSS implementation
- [ ] Documentation in Storybook
- [ ] Design review

Closing as duplicate of #3447


click.option silently swallows invalid *args.

As demonstrated below, the code for checking the choice type does not verify the entire string and will pass if a subset is given.
[click]$ setrackinfo ifcfg-param add 1
Usage: setrackinfo ifcfg-param add [OPTIONS] NODEID INTF PARAM [VALUE]

Error: Missing argument "Choice(['public', 'private'])".
[click]$ setrackinfo ifcfg-param add 1 pub
Usage: setrackinfo ifcfg-param add [OPTIONS] NODEID INTF PARAM [VALUE]

Error: Missing argument "Choice(['mtu', 'xmit_hash_policy'])".

I imagine the convert function should be updated to ensure that the given input is actually in the choices and not just a subset is matched.
class Choice(ParamType):
   ....
   ....
    def convert(self, value, param, ctx):
        # Exact match
        if value in self.choices:
            return value

Sorry, but I have absolutely no idea what you're referring to. Please give:

a reproducible, minimal example, including sourcecode.
a command to execute including expected output

@ifcfgParam.command('add')
@click.argument('nodeID', click.IntRange(1, 24))
@click.argument('intf', click.Choice(['public','private']))
@click.argument('param', click.Choice(['mtu','xmit_hash_policy']))
@click.argument('value', nargs=1, default=0)
def addIfcfgParam(**kwargs):
print "Add ifcfgParam"
pprint.pprint(kwargs)
On the command line if I pass "pub" instead of "public" it will accept it (and it should not)

You need to pass your click.Choice instance explicitly with the type kwarg. Click probably should validate this better and show a nicer error message.

I'm sorry, I do not follow. How do you mean pass it explicitly?

click.option(name, type=click.Choice(...))
On 30 April 2016 22:50:24 CEST, PWiggins84<EMAIL_ADDRESS>wrote:

I'm sorry, I do not follow. How do you mean pass it explicitly?

You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/pallets/click/issues/568#issuecomment-215994007

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Isn't that what I am doing here for the argument?
@click.argument('intf', click.Choice(['public','private']))

Again, no.
On 30 April 2016 23:19:38 CEST, PWiggins84<EMAIL_ADDRESS>wrote:

Isn't that what I am doing here for the argument?
@click.argument('intf', click.Choice(['public','private']))

You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/pallets/click/issues/568#issuecomment-215996108

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

I just realized what you were saying. thank you.
Added the type= portion to explicitly set it. Works as expected now.
thank you.

Continuing at https://github.com/pallets/click/issues/574


$x .= m.n is a trap

The problem
The following two lines are equivalent:
$x .= split(',').grep(?*);
($x .= split(',')).grep(?*);

The following two lines are not:
$x .= split(',').grep(?*);
$x .= split(','); $x .= grep(?*);

Although the latter is probably what somebody expects.
Thanks to @AlexDaniel for clarifying this in IRC and finding at least two examples of the trapped:

https://github.com/moritz/perl6-all-modules/blob/08c1a2471fcb8508881862f88cb348c464745f42/cpan/ELIZABETH/List-MoreUtils/lib/List/MoreUtils.pm6#L335
https://github.com/moritz/perl6-all-modules/blob/08c1a2471fcb8508881862f88cb348c464745f42/cpan/HYTHM/Grid/lib/Grid.pm#L398

Suggestions
Document this as a trap in the page that lists traps.

See also: https://github.com/rakudo/rakudo/issues/4863

I believe this addressed successfully in 992d269.


Fix Helm subscription not applying updates to HelmRelease in some situations

for https://github.com/open-cluster-management/backlog/issues/18183
Signed-off-by: Mike Ng<EMAIL_ADDRESS>

/hold


Update to Chromium 86.0.4240.111

Notable changes:

A snapshot of Clang 12 is used.

Current issues:

v8 is still preventing a successful build.

This build should pass if combined with #60 and without windows-fix-v8_build patch.

I was able to get a successful build. This should be safe to merge now.


Correct zk mutability in docs for TSERV_SESSION_MAXIDLE and TSERV_UPDATE_SESSION_MAXIDLE

Partially addresses #4723
These two props were being incorrectly tagged as being zk mutable. This change makes it so these properties will be properly displayed with "yes but requires restart" in the docs.

This doc update should be applied to the website as part of the 2.1.3 release.


compose_control_buttons: Use data-tippy-content instead of title.

We don't want browser default titles and tooltips to overlap,
so we remove titles here.
see discussion in https://chat.zulip.org/#narrow/stream/101-design/topic/giphy.20integration

Merged, thanks @amanagr!


Fast node/edge removal

The changes allow for fast node and edge removal (time proportional to the number of removed edges/nodes).
In order to implement it I needed to remove the nodesArray and edgesArray arrays (they didn't seem to be really needed as far as I could see as the 'nodes' and 'edges' methods can construct results on the fly) and introduce the allAdjacentEdgesIndex object that maps node ids into dictionaries that map adjacent edges ids into edges.
I developed these changes for Data4Cure (http://www.data4cure.com) and the company is ok with sharing them.

Hello @bogklug. This is an interesting change indeed. However, note that it would probably increase the cost of retrieving the list of all nodes/edges. Furthermore, even if it seems this would not break anything, I cannot affirm something else somewhere doesn't rely on the presence of those arrays. (Notably, some people use it to simulate a kind of hacky z-index). So I'll need some time to find those and take a decision concerning your PR.
On the other hand, the idea is that we will soon redevelop the library but this time using external graph data management utilities we are currently developing here, (organization here). Those utilities implement something along your idea to avoid costly node & edge deletion. Your input & feedback would be more than welcome about it if you find time.

Thanks for this PR, even though it hasn't been merged.
For a few years, we focused on Sigma.js v2, and this week we released it!
It is probably better now to upgrade to this new version as v1 will no longer be maintained.
This PR will therefore be closed.


XHR error angular2-schema-form not found (I'm using rc.5)

Hi,
I'm trying to use this on my application, I followed the installation on the main page and its giving me
Error: Error: XHR error (404 Not Found) loading http://localhost:3000/angular2-schema-form(…)
I'm using SystemJs Config and I also tried adding it in my config js but then it throws an error regarding lodash and validator.
var map = { 'angular2-schema-form': 'node_modules/angular2-schema-form' }
var packages = {  'angular2-schema-form': { main: './dist/index.js', defaultExtension: 'js' }
Can you shed a light on this, please.
Is it possible to have a guide for rc.5 and for systemjs config users?
Thanks

You should definitely upgrade to Angular 2.0 final.
Note: To set up a clean ng2 project, I recommend to use the ng CLI.

Thanks for the reply, I'm using 2.0.0-rc.5.
Oh I see, I've pretty much setup all my stuff using sysmtemjs.config.js. Is it gonna be easy to change from that to CLI? Because when I setup my application I was just following the guide from ng2 site quickstart.

Will see if upgrading to 2.0 final will fix the issue, if so then ill stick with that for a while before moving to CLI. as I have pretty much completed my demo.

@ebrehault will angular2-schema-form still work on rc4?

Not the current master or last release.
But if you go back to 1.0.0-alpha.16, it should work.

sorry I meant 2.0.0-rc.4

Yes that's what I meant too :) : angular2-schema-form 1.0.0-alpha.16 should work with Angular 2.0.0-rc.4

Oh right :), cool thanks.
Though I'm getting this error using .16 any idea about this?
node_modules/angular2-schema-form/dist/src/schema-form/model/formproperty.d.ts(31,14): error TS1005: '=' expected. node_modules/angular2-schema-form/dist/src/schema-form/model/formproperty.d.ts(31,19): error TS1005: ';' expected.

Yeah, well I do not know, at the time we were struggling in the infinite RC/breaking changes/upgrades nightmare so...
Give a try to angular2-schema-form 1.0.0-alpha.15 :)

Oh right yeah seems like it, even alpha.15 is giving me the same error. I guess I will just have to update.

Are you sure you have installed .16 ? At this time the file "formproperty.ts" didn't exist.


Git diff for ipynb files is being replaced by the notebook editor

Bug: Notebook Editor, Interactive Window, Editor cells

Steps to cause the bug to occur

Click python notebook file with changes in the Git pane.

Actual behavior
Diff window shows briefly and then notebook editor replaces the tab.
Expected behavior
Diff editor should remain open. Notebook editor should not start in a git diff view.
Your Jupyter and/or Python environment
Please provide as much info as you readily know

Jupyter server running:  Remote
Extension version:  2020.8.103604
VS Code version: 1.48.0
OS: Linux

Python Output
Microsoft Data Science for VS Code Engineering Team: @rchiodo, @IanMatthewHuff, @DavidKutu, @DonJayamanne, @greazer, @joyceerhl

Which version of the extension was this working in?

Which version of the extension was this working in?

We believe this is a problem that should be solved on the VS Code side, because a custom editor should not be used for git diff.

Filed upstream https://github.com/microsoft/vscode/issues/118764

Trying to validate this. Doesn't seem right here?

I was testing in stable with CustomEditor.

Yeah, I believe this is a small improvement in that you can at least see the two editor SxS to look for differences, but it's not really a real diff view. We're also in an odd state where both notebooks are executable, even when not backed by a writable file. So you can execute on the old git file and get odd errors when you try to save.

Pulling back to backlog.

It is working for me now. I had the same issue before. It was fixed when I installed the insider version, but after that it also worked in the stable version. My understanding is during installing the insider version, it fixed the config. You can try using the following config in the user settings.
    "notebook.kernelProviderAssociations": [
        {
            "viewType": "jupyter-notebook",
            "kernelProvider": "ms-toolsai.jupyter"
        }
    ]

With that, it can show two different modes of diff. First pic shows the new native feature, where you can even ignore metadata and/or output. Click it again, it'll show the traditional text based diff (second pic).

According to https://github.com/microsoft/vscode/issues/118764#issuecomment-799836958, for custom editors if we want the raw json to show up in the diff view we would need to implement a raw text custom editor provider and reroute git diff file opens to that provider. Like Ian said earlier, whether we fix this depends on the rollout timeline for the new preview native notebooks.

Is there a work-around for this;
So far I've tried all the workarounds i can find on the net:

adding "jupyter.useNotebookEditor": false, to settings; it greys out and doesnt recognise the setting
adding "jupyter.experiments.optOutFrom": [ "NativeNotebookEditor", ], doesnt help
adding "files.associations": { "*.ipynb": "text" }, no help
adding "notebook.diff.enablePreview": false, no help
disabling the plugin (apparently it is required by the python plugin, thus needs me to disable python too which is   depended upon by other plugins i use)
can't set language mode as no text editor is active

I hacked around it by pinning to an earlier version.
I think I followed this from @jamesmyatt

This was working in v2021.2.603412351, but broken again in v2021.3.619093157

This might be a workaround if you don't need anything bleeding edge

Is there a work-around for this;
So far I've tried all the workarounds i can find on the net:

adding "jupyter.useNotebookEditor": false, to settings; it greys out and doesnt recognise the setting
adding "jupyter.experiments.optOutFrom": [ "NativeNotebookEditor", ], doesnt help
adding "files.associations": { "*.ipynb": "text" }, no help
adding "notebook.diff.enablePreview": false, no help
disabling the plugin (apparently it is required by the python plugin, thus needs me to disable python too which is   depended upon by other plugins i use)
can't set language mode as no text editor is active

You are right,
there seems to be no solution to this

When pasting this in the settings.json it just grays out and doesn't work.
    "notebook.kernelProviderAssociations": [         {             "viewType": "jupyter-notebook",             "kernelProvider": "ms-toolsai.jupyter"         }     ]

Is this an issue ?, or the setting must go inside a different object than the root of the settins json object ?

When pasting this in the settings.json (as in the last response from @chenfeibo) it just grays out and doesn't work.

Is this an issue ?, or the setting must go inside a different object than the root of the settins json object ?

Just re-checked mine, these lines are greyed as well. It could be some latest updates invalidated them. Then I don't know what operation helped, maybe the installation of a inside build.

I hacked around it by pinning to an earlier version.
I think I followed this from @jamesmyatt

This was working in v2021.2.603412351, but broken again in v2021.3.619093157

This might be a workaround if you don't need anything bleeding edge

Confirmed @jamesmyatt and @scrambldchannel's posts. I resorted to pinning Jupyter back to that version as well.

Thanks. Then it seems like a confirmed issue on the current extension version.

And in that case documenting here the temporal workaround can be very helpful.
I don't see any v2021.2.603412351 in the releases.
Am I looking at the right place ?
Or
Do you guys know if the following is the working version ?

@Ortega-Dan I don't know how the releases on github translate to the versions available in the VSCode app itself, but if you go to your extensions panel in VSCode, go to your Jupyter extension, click the gear, click "Install another version", should see "2021.2.603412351" as one of the options you can roll back to.

Thank you so much for the great help. !!
It looks like it is working now on the latest version with stable vscode.
Here:

Cool, working for me too - thanks for sorting this out team :+1:

Just to make sure I haven't messed up my settings too much, this is still just available on Insiders, not VSCode proper, right? That's how it's looking on my machine at least

@benlindsay It's available in everyone in Insiders and a fraction of users in Stable. If you're in VS Code stable you can also opt into the new native notebooks UI: https://github.com/microsoft/vscode-jupyter/wiki/Native-Notebook-Support-in-VS-Code#enabling-the-new-experience

@joyceerhl Neat, thanks for the info! I did that and got the new stuff in VSCode stable now. Git diffing looks great! The kernel stuff was acting really weird but that's a battle for another day :)

@joyceerhl Thank you so much; that new git diffing workflow is so much better 👏💯

Thanks for your feedback. This issue is addressed with new native support for editing notebooks starting with v1.59 of VS Code. If this issue continues to occur in the latest build of VS Code, please reopen or enter a new issue.


[IO-826] Reimplemented add runtime exception support to broken streams

As discussed in #528.
One point to note: Is there a reason to keep the deprecated constructors such as BrokenInputStream(final IOException exception)?  Given that the new constructors such as BrokenInputStream(final Throwable exception) accept a superclass of IOException, it seems the old constructor could be removed without a breaking change.

While this may not break source compatibility, it would break binary compatibility per https://docs.oracle.com/javase/specs/jls/se8/html/jls-13.html#jls-13.4.12 (at least how I read it and how japicmp sees it).

Yes, you're absolutely right.  I hadn't thought of that.

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

Comparison is base (6b0ed87) 86.17% compared to head (62c67cc) 86.01%.

Files
Patch %
Lines

...java/org/apache/commons/io/input/BrokenReader.java
30.00%
7 Missing :warning:

...g/apache/commons/io/output/BrokenOutputStream.java
42.85%
4 Missing :warning:

...ava/org/apache/commons/io/output/BrokenWriter.java
42.85%
4 Missing :warning:

Additional details and impacted files
@@             Coverage Diff              @@
##             master     #530      +/-   ##
============================================
- Coverage     86.17%   86.01%   -0.17%
+ Complexity     3433     3424       -9
============================================
  Files           229      229
  Lines          8162     8171       +9
  Branches        959      959
============================================
- Hits           7034     7028       -6
- Misses          845      860      +15
  Partials        283      283

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

@markslater PR merged, TY!


[SMALLFIX] Netty version upgrade

Upgrade netty from 4.0 to 4.1
New features in 4.1:
http://netty.io/wiki/new-and-noteworthy-in-4.1.html
The ones that are very relevant to us:

Easier and more precise buffer leak tracking
PooledByteBufAllocator as the default allocator
Globally unique channel ID

@calvinjia

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/12540/
Test PASSed.

@peisun1115 I notice Netty does not guarantee backward compatibility between 4.1 and 4.0, will this change be backward compatible for us?

@calvinjia
I am not aware of any backward compatibility issue yet.
The 4.1 release note says
"""
Although we did our best to keep the backward compatibility from 4.0, 4.1 contains multiple additions which might not be fully backward-compatible with 4.0. Please make sure to recompile your application against the new version.
When you recompile your application, you might find some deprecation warnings. Please make sure to fix them all by using the suggested alternative, so that you have less trouble when upgrading to the next version.
"""
I didn't see any "deprecation warnings" when i recompile. And all tests passed. Let me know if you have any suggestions to further verify.

I've also tested the old client on the new server by running
./bin/alluxio fs copyFromLocal /tmp/a /a (cache_through to excise the netty code)
./bin/alluxio fs cat /a
I also did ./bin/alluxio runTests
all worked

LGTM

@calvinjia can you merge this PR? thank you.


Have pull down to refresh content stay visible while the component is refreshing

Hi,
First of all thanks for this amazing library! I have a question. Right now, as soon as you release after pulling down to refresh, the PTR content gets hidden again above the page. Is it possible to have the PTR content stay visible while the page is refreshing? I.e. 50px of content would be displayed, with some animated loading spinner, then when loading is finished that content disappears. Hopefully I'm explaining this well enough.
Thanks for any advice anyone can give me!

I am not sure if I get what you're saying right but in my case PTR just goes away thanks to the div with infinite-scroll-component class. If I disable overflow: auto in devTools I can see my PTR element again. But this is so annoying since I have already told InfiniteScroll in its style prop that I do not wanna have scrollbar at all. Yet since it is being added with JS it adds it yet again + some new inline css stylistic rules.
What I am thinking right now is why they did not use CSS and added them using JS. I mean I think they could add some aria tags and in css decides to style them in a specific way. How this can help? Then we could potentially override their styles (with inline CSS passed to the element through props or important).


Incompatibility (namespace , dll pair) with existing xaml due to refactoring

Elaborating on namespace – dll mapping issue: As you know , Workflow XAML created by WWF from net48 versions, maintains a list of namespaces and its corresponding assembly information.
The same is accessed by WWF/CoreWF during XAML deserialization to find the implementation via reflection. But the lib has changed the assembly containing VisualBasic.Activities resulting into processing error."System.Xaml.XamlObjectWriterException : Cannot set unknown member  {clr-namespace:Microsoft.VisualBasic.Activities; assembly=System.Activities, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=31bf3856ad364e35}”
We would need a type forwading configuration from system.activities to UiPath.Workflow dll

Types with the Microsoft.VisualBasic.Activities namespace are currently added to UiPath.Workflow.dll (see files under src\UiPath.Workflow\Microsoft\VisualBasic\Activities.)
Reflection-loading of VisualBasic.Activities types from System.Activities (src\UiPath.Workflow.Runtime\UiPath.Workflow.Runtime.csproj) could still succeed if UIPath.Workflow.dll (src\UiPath.Workflow\UiPath.Workflow.csproj) contained TypeForwardedTo attributes redirecting relevant types to System.Activities, e.g.:
[assembly: System.Runtime.CompilerServices.TypeForwardedTo(typeof(type))]
Creating these entries is not currently possible because src\UiPath.Workflow\UiPath.Workflow.csproj depends on UiPath.Workflow.Runtime.csproj.


Upgrading async to 3.2.2

Upgrading async to fix this vulnerability https://www.whitesourcesoftware.com/vulnerability-database/CVE-2021-43138

It might be worth upgrading @types/async to ^3.2.9 which was released around when async 3.2.2 was released

There's also a reference in the lockfile for the getkeys tool: https://github.com/microsoft/FluidFramework/security/dependabot/220

@tylerbutler async in getKeys is coming from ms-rest-azure package. This package has not been updated with the latest version of async yet. I'll still upgrade 'ms-rest-azure' to latest in getKeys though.
side note- i was not able to access the link you shared.


[Pick 2.1](inverted index) support inverted index format v2 (#30145)

Proposed changes
Issue Number: close #xxx

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

#30145


The given model has already started the "post_publication" process

hello !
My error comes from my controller ($modelSate =$processHandler->start($model);).
I looked in the processHandler to identify the error but I don't know of or comes this error,
Thank you in advance for your help and I will be happy to resolve the error with you.

What is the error ? An exception ? An configuration error ... ?

this is an exception because the controller is taken into account but it has blocked the start function.
that's what we but an error message with the process level.
thank you for your help

@Nekker check getWorkflowIdentifier method of your model. In case you use the same implementation as in example and pass an entity with id equals to null you will get the duplication of identifier that causes the error.

@bakurin Thanks for help but this issue is has solved half.
How could you do it and she variables to switch between steps is another view in the twig.


[Bug][Connector-V2][Kafka]Fixed Kafka all messages were sent to partition zero

Purpose of this pull request

If the partition exists when the record is generated, the specified key does not take effect.
Due to the initial value of partition is 0, the record will be sent to partition 0, which is easy to cause data backlog.
Check list

[ ] Code changed are covered with tests, or it does not need tests for reason:
[ ] If any new Jar binary package adding in your PR, please add License Notice according
New License Guide
[ ] If necessary, please update the documentation to describe the new feature. https://github.com/apache/incubator-seatunnel/tree/dev/docs
[ ] If you are contributing the connector code, please check that the following files are updated:

Update change log that in connector document. For more details you can refer to connector-v2
Update plugin-mapping.properties and add new connector information in it
Update the pom file of seatunnel-dist

[Hotfix] is better, please refer to this guide and change your pull request title.
https://seatunnel.apache.org/docs/contribution/coding-guide


Default Machine::spawned implementation

Each time I've implemented Machine, I've used the exact same function body for the spawned method. Perhaps a default implementation could be provided?
fn spawned(self, scope: &mut Scope<Self::Context>) -> Response<Self, Self::Seed> {
    Response::ok(self)
}

Slightly related, but perhaps more controversial: Maybe Machine could provide default stubs for other less important methods also, like mio::Handler does. Such as timeout and wakeup defaulting to just return ok(self).

@seanmonstar any pointers? My use cases are:

Socket accepting. It's well covered by rotor_stream::Accept, and even if you implement it by hand I believe it's better to accept next connection in spawned() rather than wait for next level-triggered event. While is it the best way or not depends on many things, I want it to be a deliberate decision, rather than default.
Establishing client connections. If you have a connection pool state machine which spawns client connections, there is nothing that ensures that maximum single connection can be created per wake up of connection pool.
The only case with ok() I have is in rotor-carbon, which is a monitoring protocol, which have an inherently single connection

The (3) looks more like exception rather than rule. There are many more cases that does have unreachable!() in spawned rather than ok().
The timeout and wakeup are also deliberately non-defaulted. In my perspective, almost nobody will use rotor::Machine in end-user application. It's more suited for protocol writers. And for writing another protocol on top of rotor:Machine you must deliberately choose if you want to skip timeouts and wakeups. Most protocols should provide timeout and wakeup in the handler based on top of it, so user can use asynchronous things in handler. Off the top of my head, I think only unidirectional protocols might ignore the events.
The spawned case is also similar, only protocol writers will need to write it, not the protocol users, so I believe it is better to enforce a decision. Ignoring the is easy. But unawareness of these things may lead to ugly workarounds.
Does it make sense?

Yes, that makes sense. I agree, I don't expose Machine to a user, but instead a server::Handler that is ignorant of the internals.


⚠ Bofrost.at has degraded performance

In 17289a0, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1284 ms

Resolved: Bofrost.at performance has improved in ae8df9e.


Transitions in data card

Hey @Sakshamjain98,
Thanks for the patch, lgtm.
Send me your Name, Branch, Library ID, Test ID

Name : Saksham Jain
Library ID: 2327CSE (AI&ML)1004
Branch : CSE
Test ID : I387

Done @1010varun


Add DIGEST authentication support

From @GoogleCodeExporter on May 11, 2015 15:4
Add DIGEST authentication support

Original issue reported on code.google.com by<EMAIL_ADDRESS>on 14 Mar 2011 at 12:23
Copied from original issue: twogee/missing-link#6

From @GoogleCodeExporter on May 11, 2015 15:4
Original comment by<EMAIL_ADDRESS>on 29 Mar 2011 at 11:17

Added labels: Milestone-1.2
Removed labels: Milestone-1.1

From @GoogleCodeExporter on May 11, 2015 15:4
Original comment by<EMAIL_ADDRESS>on 19 Mar 2011 at 12:03

Added labels: Milestone-1.1

From @GoogleCodeExporter on May 11, 2015 15:4
Original comment by<EMAIL_ADDRESS>on 19 Mar 2011 at 2:20

Added labels: Project-ant-http


Remove vset_match function in favor of vset_join

The VSet_match functions are a specialization of the join function (for a single vector) and have a broken interface exposing the internal domain representation of the BDD package via p_id.
@gijskant do you see any objections to this? Could the player selection in the SPG tool become slower when we do this?

There is a performance issue with enum_match.
Enum_match: given a set of long vectors and a single short vector, enumerate all long vectors that "match" the short vector (i.e. are in the intersection, which is what join would compute). Currently, lddmc applies the intersection with the given short vector on-the-fly, thus does not actually compute the LDD of this intersection.

Right, we can keep enum_match (perhaps generalize it?).
I actually meant vset_copy_match and vset_copy_match_proj.

I agree with that point.
I further propose that we should check semantics of set_project and set_join to make sure they are correctly implemented. My understanding is that a sets are created always as projections relative to the full state vector. For set_project in particular, set_project should have as the requirement that the projection of the destination set must be a subset of the projection of the source set. Then the implementation of set_project can figure out how to implement computing a projection of a projection, relative to the full long vector.

One could generalize enum_match, but is there a use case for that?
Just generalizing for the sake of generalizing should be avoided, otherwise we end up with enum versions of every operation...

This work is not tested yet, but perhaps you can provide some feedback @trolando:
c12b093c058a9b41fb51714a6e3fe35d252fc1da

For Sylvan:
9993ec094b3e51d787881eb2e542099df398c8a4

I dony't see how they do the same thing.
The current documentation of vset_join says:
/**
\brief res := (a | a in left and a in right), like join in relational databases.
Put result in dst.
*/
extern void vset_join(vset_t dst, vset_t left, vset_t right);

That does not make sense to me. Anyone a better suggestion?
The vset_copy_match_proj was indeed introduced for the symbolic parity game solver, but only as a workaround because of a limition of listdd (see 3b859e96032c3300d754781df220952e0440e82d).
I agree that the p_id should not be exposed as int, this should be of type vset_t, but then vproj_create needs to return vset_t.

Join({abc, bca, cab, acb, bac, cba}, project({ab},2)) = {abc, cba}

Then that should in principle be sufficient. And I don't have the impression that the current vset_copy_match_proj is really built for performance.
Only issue is that vset_copy_match_proj has a default implementation (in vector_set.c: defaults to vset_copy_match if not implemented; it is only implemented in listdd, as a workaround, as described earlier); but vset_join is not implemented in all vset implementations. It is in ldd64 and in lddmc, which may be sufficient.
I would suggest to drop / deprecate vset_copy_match_proj, but leave vset_copy_match for now. Or let it use vset_join if available (in vector_set.c).

Let me clarify vset_join semantics.
Given left projected onto a set of variables Q, and right projected onto a set of variables R.
Then the join computes a set of states, projected onto a set S which is the union of Q and R.
The result contains precisely all states s for which proj(s,Q) is in left, and proj(s,R) is in right.
Furthermore, vset_join is currently not implemented in vset_sylvan.c but this is not very difficult, because it is trivial for BDDs. For BDDs it is just the intersection computed with sylvan_and.

Re extending set_project, I propose not changing this on the side of Sylvan, but to let the VSet glue code compute the "diff".
something like:
if source is not full state vector, then for every variable in my projection, find its position in the projection of the source.
for an example where the source set has projection "0,1,3,5,8,9" (always ordered) and the target set has projection "0,3,9" (and target projection must always be a subset of source projection), this would result in "0,2,5" as the projection-to-be-performed with LDDs. (with lddmc this is the 'meta vector' [1,0,1,0,0,1,-2]) With BDDs it is much simpler, because sylvan_project (and its dual sylvan_exists) are sufficient.

So I guess the sylvan interface does not track variables identities as PIN S does. You could still add some sanity checks in LDDMC (projection should be a subsets of the LDD's domain).
In the case of BDDs, do you mean that the projection may introduce variables as well? We will still need to do the translation to preserve variable identities right?

Re 'vset_join' for Sylvan BDDs:
Does sylvan_and support sets with different projections?

So join is basically intersect with a separate result set (the standard vset_intersect operation merges both sets into the left operand). As the result set of join might have another support all together, this operation essentially does a simultaneous project. But the latter seems useless in both possible use cases:
--- when projecting further down (the input sets could achieve the same if the result's support is constrained to be equal the left and right operands' support), and
--- when projecting sets up (MDD implementations cannot support variable introduction).

@alaarman Lots of questions, let me try to answer them.
With BDDs, the variable identities are "baked in". So if you have a BDD, the nodes read e.g. the Boolean variables x24,x25,...,x48. These are the same as the full vector. So you don't need to do extra work when projecting a projection. With LDDs this is not the case: the variable identities are not stored in the graph, they can be derived by remembering the projection. So you need to do some extra work when projecting a projection.
Projection never introduces variables, it's like existential quantification except you tell it which variables to keep instead of which variables to remove.
Let me point out one minor nuance: join does not do a simultaneous project, because it is not performing a projection, the support of the result is strictly the union of the supports of left and right. If you would do the vset_intersect where the left is also the result, then this is like join where the right support is a subset of the left support. In fact, vset_intersect is just a special case of join where left and dst are identical and all sets have the same projection/support.
An important difference between BDDs and LDDs is that you can encode "all values" for a variable in a BDD by skipping nodes, whereas you cannot do this with an LDD. So you can silently add variables to a BDD and then perform an intersection to compute the join. With an LDD you need to know every possible value that an integer holds and obviously if this is 0..MAX_INT you will run out of memory fast.

Note: This would get rid of vset_proj_create as well.

@trolando
A general definition of projection could introduce variables as it is the opposite of existentially quantifying variables (away) as you mention.
Thanks for the explanations.
Currently vset_join does not seem to have a clearly defined interface and is implemented differently in the different DDs.
Personally, I favor an additional function vset_intersect3 or vset_intersect_projectwhich is the same as vset_intersect, except that it has a third operand (as its first operand) for the result set with whatever dimension the user pleases (LDDs should throw an error if the projection is not supported). This seems clearer and cleaner to me than vset_join.

@alaarman That's not what I said. The opposite of projection would be extension. Maybe I was not clear. When I say "dual" I don't mean "opposite". It is the dual in the sense that exists specifies the variables to remove, project specifies the variables to keep. If you want to keep variables that are not in the original, then it is not going to magically add these variables. You can't keep something that's not there. With BDDs this is not really a problem as you can always pretend that you extend some BDD to some larger domain without changing the BDD, but this does not work with LDDs.
So vset_intersect_project would actually semantically function like vset_join followed by vset_project? I can see how I can implement that in Sylvan to perform both operations in one algorithm, doing the projection "on-the-fly" with the intersection.

By the way, I found an inconsistency in set_add and set_member.
The supplied int* vectors for these two functions, for a projected set, are they full vectors or projected vectors?
For some reason my current Sylvan implementation thinks it is always given a full vector, whereas other implementations think they get the projected vector...


Properly escape variables in /etc/defaults/

If one use a password contains special characters (like $ or ! ), then it expands to shell.
To prevent this use single quote in REDIS_PASSWORD

Thanks @l-flame ... Let me know if you have any other issues!


DBZ-4205 Change stream follow-up

Applied, thx, @jpechane!

@gunnarmorling  When we are using debezium-mongodb. If I shutdown kafka-connector for a while, DB changes during this period will not be synced to Kafka. In debezium log, I saw offset can't be found.

@mjiangcn Hi, could you please create a Jira issue with log an detailed description of the scenario in question?

@jpechane  can you share some guidance what's the jira link I can file an issue? Sorry for replying late. We were trying MongoDB's native change stream in the past month. It doesn't lost data with kafka connector.

@mjiangcn https://issues.redhat.com/projects/DBZ/


Disable use of auxiliary file to prevent permission error on XcodeCloud

Motivation

RELATED #246

Modifications
The implementation of swift-openapi-generator is try encoder.encode(container).write(to: url, atomically: true, encoding: .utf8). if atomically is true, the content is written to an intermediate file and then moved to the outputURL. However, XocdeCloud does not seem to allow writing outside of the pluginWorkDirectory, even for temporary files created by the Foundation framework.

https://developer.apple.com/documentation/foundation/nsdata/1408033-write

The easiest way to get Build to succeed on Xcode Cloud seems to be to change "atomically" to false.
What do you think about this change?
Result
Swift Package Manager's Build Tools plug-in works on XcodeCloud
Test Plan
N/A

Interesting. Are you saying that, with this patch, you no longer need the defaults-write workaround detailed here: https://developer.apple.com/forums/thread/732893?

@czechboy0 Sorry, this method didn't solve the problem.

No problem, thanks for taking the time to investigate @novr! Hopefully the defaults-write workaround detailed in the other issue will allow you to make use of Xcode Cloud, if that's your goal.


Update 2.0.0 upgrade notes

Mention that is required to use a handler_id if you are using Redis sessions.
We just upgraded a project from 1.1.9 to 2.0.0 and this broke our sessions.

Thanks @gigo6000


Check for no remote branches

Fixes https://github.com/microsoft/vscode-azurestaticwebapps/issues/117
While ideally, we could just create a remote branch for the user, it's a complicated UI experience due to the fact that we can't guarantee that the repo they selected is what they currently have in the local workspace.  GitHub doesn't have an API call to create a new branch (as far as I know) so an error message seems better than nothing.
If anyone knows how to make it more of an error message or change the color of the message/icon, let me know.  I looked through the VS Code API and didn't see anything about it.
Before:

After:

I guess instead of a pick item, I could change the placeHolder though I don't know how immediately obvious that would be.


fix chocolatey

Description
fix chocolatey
Test plan
https://github.com/MystenLabs/sui/actions/runs/10393957131

we don't actually need this anymore, the nuspec file was broken.


Issues/#285 defaults for technologies

Fixes #285

I think this PR depends on #331 (there are EDSN-related changed in installed_technology.rb); after #331 is merged, I'll also merge this.

I rebased against master to account for the changes there, but there are some quirks to the form (which may be intentional). @ChaelKruip @grdw can you tell me if this is intended behaviour?
For these examples, I (unrealistically) added a default_volume of 10.0 to the solar PV technology.

Default values do not appear on the "import" form when it first loads; I have to change the profile to get the default value to show up. The -1.5 capacity does show up: this value is imported from ETEngine.

If I change the selected profile, the -1.5 capacity now disappears, and the volume of 10.0 shows up.

My expectation is that:

Default values should be shown in the table when it first loads.

If a field is editable, an existing value should not be automatically deleted or changed. Perhaps the value can be altered if the user has made no changes (current value == default value) but this needs to account for values which are imported from ETEngine which should also not be deleted.

If the value of a field is a function of the selected profile (e.g. an EV profile which has a hard-coded capacity of 3.7kW) then the field should not be editable by the user (set disabled="disabled").

can you tell me if this is intended behaviour?

No. Your expectations are my expectations.

Default values should be shown in the table when it first loads.

So ignoring the values that are imported from ETEngine?

So ignoring the values that are imported from ETEngine?

No. I think the values from ETEngine are a 'special kind' of defaults. There are, however also default values that are not present in ETE such as 'volume'.
In this comment I have described which default values should be 'fixed' (not editable by the user but depending on the profile or the technology).

So ignoring the values that are imported from ETEngine?

User-provided value > ETEngine value > default value.

To put it in more abstract terms: the user experience should be consistent. Here's what would currently happen:

The page loads and my technology has selected "profile_one", a capacity of -1.5 and no volume.
I change the profile to "profile_two"; my technology now has no capacity and a volume of 10.0.
I change the profile back to "profile_one", but my technology has no capacity and a volume of 10.0.

The user experience is inconsistent because, despite reverting my changes, the technology row has different values (capacity and volume) than when the page first loaded.
But, if we can apply the rule above – user value > ETE value > profile default > technology default – then hopefully the UX becomes consistent when a user makes, and reverts, changes.

I've made changes according to:

User-provided value > ETEngine value > default value.

If you would be so kind to check again.

Looks good, thanks!


Code snippets with header units are incorrect

C++ header units require a semi-colon at the end, this example,
import <vector>
import "myheader.h"

Should have been written as
import <vector>;
import "myheader.h";

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

ID: ad1fef9a-9c55-a8ab-faf4-8b9ceb9ff688
Version Independent ID: 0eadb3ed-bb38-58bc-b335-687b10f0fd31
Content: Overview of modules in C++
Content Source: docs/cpp/modules-cpp.md
Product: visual-cpp
Technology: cpp-language
GitHub Login: @corob-msft
Microsoft Alias: corob

@pjmlp
Good catch. A fix is in the works for later today.


Client WARN message when running too many concurrent activity.

Example:
2017-12-01T12:05:01.376-0800    DEBUG    cadence/internal_event_handlers.go:295    ExecuteActivity    {"Domain": "canary-test", "TaskList": "canary-task-queue", "WorkerID": "52523@wenquanx-C02V91NKHTDG@canary-task-queue", "WorkflowType": "workflow.concurrent-execution", "WorkflowID": "cron.workflow.sanity/workflow.sanity-3/workflow.concurrent-execution", "RunID": "3f468701-5af6-4306-b01f-c191698ebdfa", "ActivityID": "1999", "ActivityType": "activity.concurrent-execution"}
2017-12-01T12:05:01.673-0800    WARN    cadence/internal_task_handlers.go:472    Cached sticky workflow state is missing some events.    {"Domain": "canary-test", "TaskList": "canary-task-queue", "WorkerID": "52523@wenquanx-C02V91NKHTDG@canary-task-queue", "CachedPreviousStartedEventID": 0, "TaskFirstEventID": 2800, "TaskStartedEventID": 2864, "TaskPreviousStartedEventID": 2799}
code.uber.internal/devexp/cadence-canary/vendor/go.uber.org/cadence.(workflowTaskHandlerImpl).getOrCreateWorkflowContext
code.uber.internal/devexp/cadence-canary/vendor/go.uber.org/cadence/internal_task_handlers.go:472
code.uber.internal/devexp/cadence-canary/vendor/go.uber.org/cadence.(workflowTaskHandlerImpl).ProcessWorkflowTask
code.uber.internal/devexp/cadence-canary/vendor/go.uber.org/cadence/internal_task_handlers.go:544
code.uber.internal/devexp/cadence-canary/vendor/go.uber.org/cadence.(workflowTaskPoller).ProcessTask
code.uber.internal/devexp/cadence-canary/vendor/go.uber.org/cadence/internal_task_pollers.go:180
code.uber.internal/devexp/cadence-canary/vendor/go.uber.org/cadence.(baseWorker).processTask
code.uber.internal/devexp/cadence-canary/vendor/go.uber.org/cadence/internal_worker_base.go:249

My guess that it could be related to pagination logic being executed for a large history.

fixed by https://github.com/uber-go/cadence-client/pull/303


Add Incubation Proposal for CNCF Review

We need to have a incubation proposal created for when we are ready to ask for the CNCF TOC vote on moving to incubation.

@mfdii: There is not a label identifying the kind of this issue.
Please specify it either using /kind <group> or manually from the side menu.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

/kind documentation

We want this !


Bounds silently accepts negative values in dimensions leading to UI.Handles that are visible but non functional.

Description
When a Handle is created using negative values in the Bounds dimensions the Handle is drawn in the UI and the Aura effect appears when hand is near but its not possible to grab the handle.. (I had been using negative dimensions to place the visible handle where I needed it relative to other parts of the UI before discovering this was a use case for the center parameter.. obviously user error but considering the time it took to figure why this wasn't working may be worth saving others from shooting themself in the foot with an argument check during creation of Bounds)
Platform / Environment
Windows, Visual Studio 2022, using C# and testing with WMR headset (AppMode.XR and AppMode.Window)

I've modified this behavior a bit in v0.4 on the Handle side, but I haven't really tested this particular use-case! It's an interesting problem, I'll have to think about it and see if there's a nice way to prevent this. Argument check during bounds creation won't work with the native API, might work fine for C# but wouldn't necessarily guarantee things.


fix: force<EMAIL_ADDRESS>

Codecov Report

Merging #47 (6b7f550) into main (81b3190) will decrease coverage by 0.53%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main      #47      +/-   ##
==========================================
- Coverage   94.91%   94.38%   -0.54%
==========================================
  Files          14       28      +14
  Lines         708     1407     +699
  Branches      142      152      +10
==========================================
+ Hits          672     1328     +656
- Misses         36       79      +43

Impacted Files
Coverage Δ

...metry-instrumentation-document-load/src/version.ts

...telemetry-instrumentation-long-task/src/version.ts

...etry-plugin-react-load/src/enums/AttributeNames.ts

...ry-instrumentation-user-interaction/src/version.ts

...entation-document-load/src/enums/AttributeNames.ts

...strumentation-document-load/src/instrumentation.ts

...ation-user-interaction/src/enums/AttributeNames.ts

...etapackages/auto-instrumentations-web/src/utils.ts

...trumentation-document-load/src/enums/EventNames.ts

...entelemetry-instrumentation-long-task/test/util.ts

... and 32 more


Update model::equal() to compare selectedPerson

Currently it doesn't compare and make any test where orders need to be listed less valid

And also createCopy()


feat: mosaic-fe-samples-host version upgrade

Pull Request
Prerequisites

[x] My code follows the coding conventions
[x] All tests pass

Description

Will abandon this PR and raise new PR with latest version of mosaic-fe-samples-host lib


OCPBUGS-30574: Update OLM Default Catalog Sources to 4.15

OCP 4.15.0 is GA, we can now update the default catalog sources to point to 4.15 indices instead of 4.14 (Note: 4.16 catalogs are not available yet.)

What this PR does / why we need it:
Which issue(s) this PR fixes (optional, use fixes #<issue_number>(, fixes #<issue_number>, ...) format, where issue_number might be a GitHub issue, or a Jira story:
Fixes #
Checklist

[ ] Subject and description added to both, commit and PR.
[ ] Relevant issues have been referenced.
[ ] This change includes docs.
[ ] This change includes unit tests.

/jira refresh

/retest
For Konflux test

/retest
For Konflux test

PVC quota exceeded, I'll ask for RHTAP support.

/retest

/approve


common: enable -Wrange-loop-analysis and fix errors

With Xcode 12 enabled, -Wrange-loop-analysis becomes active and yields errors preventing Envoy Mobile from building. This PR fixes the errors and enables -Wrange-loop-analysis in Envoy itself to prevent future violations.
Fixes https://github.com/envoyproxy/envoy/issues/13139.
Risk Level: Low
Testing: Existing unit tests
Signed-off-by: Michael Rebello<EMAIL_ADDRESS>

CI failure looks unrelated:
Updated Homebrew from 484c2b4fa to 871abe8b9.
Error: 767: unexpected token at '{
  "java11": "homebrew/core",
}
'

cc @yanavlasov @lizan based on context in https://github.com/envoyproxy/envoy/issues/11949

Hmm, it looks like there are some external violations:
bazel-out/darwin-fastbuild/bin/external/com_googlesource_quiche/quiche/spdy/core/hpack/hpack_header_table.cc:258:19: error: loop variable 'it' of type 'const std::__1::pair<const std::__1::basic_string_view<char, std::__1::char_traits<char> >, const spdy::HpackEntry *>' creates a copy from type 'const std::__1::pair<const std::__1::basic_string_view<char, std::__1::char_traits<char> >, const spdy::HpackEntry *>' [-Werror,-Wrange-loop-analysis]
  for (const auto it : static_name_index_) {
                  ^
bazel-out/darwin-fastbuild/bin/external/com_googlesource_quiche/quiche/spdy/core/hpack/hpack_header_table.cc:258:8: note: use reference type 'const std::__1::pair<const std::__1::basic_string_view<char, std::__1::char_traits<char> >, const spdy::HpackEntry *> &' to prevent copying
  for (const auto it : static_name_index_) {
       ^~~~~~~~~~~~~~~
bazel-out/darwin-fastbuild/bin/external/com_googlesource_quiche/quiche/spdy/core/hpack/hpack_header_table.cc:266:19: error: loop variable 'it' of type 'const std::__1::pair<const std::__1::basic_string_view<char, std::__1::char_traits<char> >, const spdy::HpackEntry *>' creates a copy from type 'const std::__1::pair<const std::__1::basic_string_view<char, std::__1::char_traits<char> >, const spdy::HpackEntry *>' [-Werror,-Wrange-loop-analysis]
  for (const auto it : dynamic_name_index_) {
                  ^
bazel-out/darwin-fastbuild/bin/external/com_googlesource_quiche/quiche/spdy/core/hpack/hpack_header_table.cc:266:8: note: use reference type 'const std::__1::pair<const std::__1::basic_string_view<char, std::__1::char_traits<char> >, const spdy::HpackEntry *> &' to prevent copying
  for (const auto it : dynamic_name_index_) {
       ^~~~~~~~~~~~~~~
2 errors generated.

Is there a way to apply this rule only for Envoy code or do we need to fix each dependency?

cc @danzh2010. We will need to fix QUICHE also since ultimately xcode will end up complaining there also.

Looks like Envoy Mobile does not depend on QUICHE code right now, so the fixes in this PR are sufficient for getting Envoy Mobile to compile again. I dropped the build rule change and instead filed an issue to enable that separately: https://github.com/envoyproxy/envoy/issues/13154
@mattklein123 mind taking another look?

I believe remaining CI failures are unrelated

Please merge main to fix CI.
/wait

In addition the quiche issues the following is required to build in MacOS
diff --git a/source/extensions/filters/http/common/compressor/compressor.cc b/source/extensions/filters/http/common/compressor/compressor.cc
index 4e0a1b48c..e8e604295 100644
--- a/source/extensions/filters/http/common/compressor/compressor.cc
+++ b/source/extensions/filters/http/common/compressor/compressor.cc
@@ -224,7 +224,7 @@ CompressorFilter::chooseEncoding(const Http::ResponseHeaderMap& headers) const {
   }

   // Find all encodings accepted by the user agent and adjust the list of allowed compressors.
-  for (const auto token : StringUtil::splitToken(*accept_encoding_, ",", false /* keep_empty */)) {
+  for (const auto& token : StringUtil::splitToken(*accept_encoding_, ",", false /* keep_empty */)) {
     EncPair pair =
         std::make_pair(StringUtil::trim(StringUtil::cropRight(token, ";")), static_cast<float>(1));
     const auto params = StringUtil::cropLeft(token, ";");

Thanks @moderation - added that as a task for https://github.com/envoyproxy/envoy/issues/13154


Remove epel-8 and python-3.6 specifics

First round: Remove epel-8 targets, %if clauses in the spec file, no need to bundle copytree as it will never run and mypy was complaining about
tmt/utils.py:101: error: Signature of "is_relative_to" incompatible with supertype "PurePath"  [override]
tmt/utils.py:101: note:      Superclass:
tmt/utils.py:101: note:          def is_relative_to(self, *other: Union[str, PathLike[str]]) -> bool
tmt/utils.py:101: note:      Subclass:
tmt/utils.py:101: note:          def is_relative_to(self, other: Union[str, Path]) -> bool

The #2209 does much more changes and I'm afraid it will take some time until things settle there, so lets' drop python3.6 asap and have easier life with open PR

Hm, 'testing-farm:centos-stream-8-x86_64 Expected — Waiting for status to be reported' is configured in github, let's change that but only after this PR looks acceptable.

I'd be pretty fine with this PR as it is, but I'm not going to Approve it yet, as I'd like to wait till @lukaszachy and @martinhoyer settle on some opened issues and sync on the approach on removing Python 3.6 & co. It may lead to more changes in this PR, who knows, I'm watching you :)

I think there are no open conversations which need some code change, or are they? @martinhoyer

I'd be pretty fine with this PR as it is, but I'm not going to Approve it yet, as I'd like to wait till @lukaszachy and @martinhoyer settle on some opened issues and sync on the approach on removing Python 3.6 & co. It may lead to more changes in this PR, who knows, I'm watching you :)

I think it make sense merge this one now as #2209 is more about packaging and will require further discussions and decisions.
@lukaszachy Comparing the changes from here and https://github.com/teemtee/tmt/pull/2209/commits/a9f9f3f0103c9e0b9c63baf6813e8f973c774be7, at glance, I noticed there are still some (easy-to-remove) Python<3.9 "leftovers" in this PR, most notably typing imports.
Otherwise lgtm.

@martinhoyer very good point. Dropped more stuff in this PR.

@martinhoyer @happz I hope this is final version now, approval(s) would be nice to have ;)

@psss I'm disabling testing-farm:centos-stream-8-x86_64 job now.

@psss I'm disabling testing-farm:centos-stream-8-x86_64 job now.

Yeap!


Vendor dependencies, update k8s to 1.16.3

Towards giantswarm/giantswarm#7675

This is used in kvm-operator. Going with this so we can update the SHA in kvm-operator.
https://github.com/giantswarm/kvm-operator/blob/b0a4b1d3d6890f1c1a82c11af1e0eea58934c6b7/service/controller/v23/key/key.go#L59


functionality while in --api mode?

Is there any way to get this extension to work with the server in --api mode?
It works fine when I run a prompt through the gradio webui, but when I send a prompt to the api endpoint (/sdapi/v1/txt2img), it doesn't seem to parse the syntax.
Thanks a ton, I love this extension.

I don't know if there is a difference, but I use it in API mode in the Vlad fork and it works fine.

Recent update to A1111 webui itself seems to have fixed the issue I was having!


Document build-support package for substituteAll and substitute

the shell command substituteAll is documented, but the build-support package isn't. This is especially useful in situations like this
cc @worldofpeace

I did a breakdown on how someone can produce patches for this purpose in https://github.com/NixOS/nixpkgs/pull/70512#pullrequestreview-297842523.
I'm guessing I should document this when time permits.
And probably reference it in the Gnome nixpkgs documentation since it's a frequent task.

I still think this is useful to document. @worldofpeace, could you get to this?

still relevant.

still relevant.

FOR THE LOVE OF GOD SOMEONE DOCUMENT BECAUSE I AM TOO LAZY

whoever does eventually document this, please also document #73712 while you are at it :+1:

Still relevant.

I'm happy to try to help with this, but it will be my first documentation contribution.
For my future convenience:

substituteAll function: https://github.com/NixOS/nixpkgs/blob/4d968c70fb320edbe0a94d6a6a834d9ed2de351f/pkgs/stdenv/generic/setup.sh#L938
substituteAll documentation: https://github.com/NixOS/nixpkgs/blob/4d968c70fb320edbe0a94d6a6a834d9ed2de351f/doc/stdenv/stdenv.chapter.md#substituteall-infile-outfile-fun-substituteall
substitute packages: https://github.com/NixOS/nixpkgs/tree/4d968c70fb320edbe0a94d6a6a834d9ed2de351f/pkgs/build-support/substitute

Reading through the nixpkgs contributing buide and the manual's section on contributing to documentation, I'm guessing this would go into something like... nixpkgs/doc/packages/stdenv.section.md? Or maybe nixpkgs/doc/packages/substitute.section.md?

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/link-in-run-current-system-sw-bin/47002/7


The tasext container report http error

2020/03/12 05:08:16 Get http://localhost:8111/cache/policies/default/demo-policy: dial tcp: i/o timeout
But actually I can use a service to expose 8111 to custer and use curl to access it.
Any possible reason for this ?

Issue fixed by using http://<IP_ADDRESS>:8111 instead of http://localhost:8111. This could be tasext container issue, it cannot resolve localhost as hostname...

Huh, I'm not exactly sure what's going on there ?  Is the initial error from the TAS logs? If so we may need to change the dnsPolicy passed to it in the container. Alternatively this could be a proxy issue - especially given it's timing out, the issue doesn't seem to be no-resolve.

The kube-scheduler can access https://localhost:9001 without problem, so the dnsPolicy should work.
The issue comes from tasext to access tascon http://localhost:8111, the cache server.
sounds like tascon has not localhost in hosts file.

Yeah - TAS components are build on scratch containers so the resolv.conf is created by the docker runtime. I'm getting output like
nameserver <IP_ADDRESS>
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

Which is from Docker/Kubernetes and might change with CRI implementation. I think changing the DNS policy passed in the deployment should take care of this. I'll take a look at the different options

The easiest way is in my commit: - --cacheEndpoint=http://<IP_ADDRESS>:8111/cache/, this is to tell the tasext container to use <IP_ADDRESS> instead of default "localhost". There is no much interest to use DNS to resolve localhost since they are all inside the same POD.

Thanks for this - in #12 I added the bare IP (<IP_ADDRESS>:8111) as the default value for the cacheEndpoint. This should hopefully prevent people from running into the same issue.


do not cache nil values for outdoor_temp

Delete key from cache in WeatherMan if it is nil.

closed by #82