Bowser board movement in MP2 crashy

I have had several reports of Bowser causing crashes in MP2 when he appears on the board and starts to move around. My impression was that this worked sometimes, but maybe there are some cases that are failing for some reason.

Here's a code to help investigate this, frome gamemasterplc.
 gamemasterplc: Bowser's Appearing Act Always On:
 D10F93C6 0003
 810F8D16 0001

Based on discussion, the problem is when a star space is the last space in a chain. The space events from the initial space are presumably not ran, leading to corrupted "next space" state.

Hmm... I'll try my rom, thank you very much.


⚠ Bofrost.com has degraded performance

In bacf520, Bofrost.com (https://www.bofrost.com) experienced degraded performance:

HTTP code: 200
Response time: 770 ms

Resolved: Bofrost.com performance has improved in d4c6cee after 9 minutes.


src: update build command help text

:broom:  Update build command help text a bit

/override "On Cluster RT Test (1.18.x, ubuntu-latest)"

Shouldn't this also include an update to the docs?

Oops! Yes of course.  It should be there now.

/lgtm

/override "On Cluster Test (1.18.x, ubuntu-latest)"


ENH: vectorize some distance functions

as these are reductions they can't be autovectorized by gcc without
adding unsafe-math optimization flags, so vectorize them manually for
SSE2 which is available on all amd64 machines.
This changes the numerical result as the summation ordering is different,
but the change should be only in the order of a few machine precisions.
Also release the GIL during the computations.

most of the other functions could also be vectorized with relatively little effort, though I don't know which ones are most worthwhile to tackle, so I only did those I know about for now, if you know of one which is important I'll be glad to look at it too.

as for tests, the existing suite looks good, I intentionally broke lots of parts of the code and the existing tests always failed.

I can't read any of this. Isn't it better to use #pragma omp simd or #pragma simd (Cilk Plus) for this kind of thing? GCC 4.9 has an option -fopenmp-simd (or something like that) to get the former without dragging in libgomp and all the rest of OpenMP.

Or in fact: what happens when we do add -funsafe-math in the build system, just for this module?

with the option (+ -O3/-ftree-vectorize) gcc can vectorize it, but the options are gcc specific while this code works on pretty much all compilers.
Unfortunately it is not recommended to use these semantic changing flags on a per function basis (optimize attribute) so its only whole file or nothing.

I just don't like the idea of multiple code paths, one of which contains thinly disguised inline assembler for a particular platform (even if it's the most popular one). Of course, I'm perfectly ok with releasing the GIL around a big batch computation.
Why is it "not recommended" to do this per function?
And I forgot to ask the main question: what does this buy us? Any profiling results?

its not recommended because its full of bugs, mostly it just does nothing. The attribute only really works as intended for non semantic changing flags like optimization levels, unrolling control etc.
performance improves by a factor of 1.5x-2x for appropriate inputs.
e.g.
d = np.random.uniform(size=((1000,1000)))
%timeit scipy.spatial.distance.pdist(d)
d = np.random.uniform(size=((3,10000)))
%timeit scipy.spatial.distance.cdist(d,d)
d = np.random.uniform(size=((10000,3)))
%timeit scipy.spatial.distance.cdist(d,d)

1 loops, best of 3: 613 ms per loop
10000 loops, best of 3: 115 µs per loop
1 loops, best of 3: 1.15 s per loop
to
1 loops, best of 3: 356 ms per loop
10000 loops, best of 3: 65.3 µs per loop
1 loops, best of 3: 972 ms per loop

Those timings looks nice, especially for high-d. Ping @WarrenWeckesser.

How does vectorization compare to using the dot function?

the dot is only used for the cosine distance, and it is a vector dot so there is not much more optimization potenzial available, possibly you can squeeze some percent by unrolling and AVX is an option, though its likely memory bandwidth bound too quickly.
Additionally blas libraries typically have very large overheads for small sizes.
So I don't think its that worthwhile to investigate.

You are of course absolutely right, sorry for the noise. I think I have seen enough code for today...

Does unrolling this loop give any benefits? I tried it to see if GCC would start vectorizing (nope), but didn't profile the resulting code.

it should provide benefit as it breaks a dependency chain allowing the processor to do stuff in parallel, though the cpu might also be able to do that on its own until it reaches the sum so it likely only saves a few cycles. But its probably an interesting experiment.

#4256 replaces the dot product function with a call to NumPy's. I was already having second thoughts because of the hacky implementation.

added double hamming vectorization and unrolled the loops once, it gives a relevant 10% performance increase on my i5 haswell. I didn't unroll seuclidean as it has a division in it which to my knowledge can't be efficiently pipelined even in new cpus.

I noticed all boolean optimizations of the distance functions are disabled by https://github.com/scipy/scipy/blob/master/scipy/spatial/distance.py#L2005
is this accidental? the git blame does not indicate intention. Assuming distance on booleans are relevant in practice this misses out on significant performance improvements in some areas.

Like @larsmans I'm worried by this. I can't read the code at all, and I think the maintainability hit is not worth it for a factor 1.5x-2x speedup.
Note that we don't really have an official "policy" on this kind of thing, but IIRC we discussed the maintainability/speed tradeoff of np.add.reduce vs. np.sum, and had a preference for np.sum - readability over performance.

While I cannot read it either, I'm wondering if there's a way of providing both optimized and original versions as fallbacks. Sort of similar to pickle/cpickle, kdtree/ckdtree etc.

I also can't read the code, but if there is a trade-off between readability and performance then isn't scipy a relatively good place to hide this unreadable code from user applications?  Or should it go into a layer like BLAS/LAPACK?

... or still the compiler.

its not so bad once you get used to it, its just +-*/ replaced with well documented functions doing the same thing on two doubles at once.
one can write the same vectorized but without the function calls using gccs vector extensions, the only drawback is that its less portable to other compilers. Would you prefer that?
Also note that the non-vectorized fallback is right below the vectorized part, so you can quickly see what the code is doing in case you can't read it.
using unsafe-math-optimziations is also an option, though that requires checking every function in the file if that flag is safe (also it won't work for hamming, that kind of transformation is not available in current gcc)

concerning if its worthwhile to speed up, sklearn reimplements some of the functions apparently because they are too slow, so I think its worthwhile to have the generic variants in scipy more optimal even if it goes a bit against readability.

scikit-learn reimplements Euclidean distance also because the one in SciPy doesn't support sparse matrices. It uses a different algorithm that is less numerically stable.
In benchmarks, I've found scikit-learn to be faster for high-d, but SciPy for low-d (think 4× for 3-d space, or something like that).

note that these optimizations are only really noticeable for high-d while not slowing down low-d

@juliantaylor if there's a clean way to add this flag (not sure how to best check for gcc in setup.py) that would be preferable I'd think. Or otherwise do nothing. Adding code that cuts the people that are able to maintain it by an order of magnitude is unhealthy imho.
@ev-br that pickle/cPickle style thing is outdated and Python itself doesn't do that anymore.

@juliantaylor and I know it looks easy for you, but for us simple Python programmers who happen to know some C it's a different story.... It's not just about reading the fallback to know what it's doing; if a change to the code is needed both code paths need the same change. So I simply wouldn't be able to touch this code anymore without a lot of effort.

Should we merge the GIL releases and setup.py fix in a separate PR already?

I have never jumped down the vectorization intrinsics rabbit hole, but have looked down it a couple of times.
And I think Julian is mostly right: with a template to follow (which his code is providing), and the abundant documentation that can be found googling the function names (e.g. this and this for the code in this PR), it is relatively easy to figure out what is being done, and modify it if needed, even if not understanding very well what exactly is going on.

The decision we take here should also be valid for the next times this comes up, so I'd like to hear a few more opinions. @pv @WarrenWeckesser?

I'd argue that even the gcc specific feature detection would be more complicated than this. I haven't found any any infrastructure for this in scipy.
The advantage would be that gcc could use AVX automatically if users configure it so, but I doubt many really do this.
Should I just copy numpy configure infrastructure into scipy?
Regardless of helping the compiler or not, I'd like to keep the hamming code as the compiler is unable to do this by itself.
The whole code is really the most basic C code evne if unfamiliar with the basics you should be able to grasp it in detail in a very reasonable time. It is even similar to how numpy itself works, instead of scalar loops you work on vectors, this shouldn't be unfamiliar to python coders.
You also accept new cython code, which is also just C again if you want it fast. I'm not adding any tricky CPython api usage here.
I could add some comments but I consider them very redundant the functions have very clear names:
    /* unroll 4 loop elements */
    for (; i < n - (n & 3); i+=4) {
        __m128d uv1 = _mm_loadu_pd(&u[i]); /* load uv1 = u[i], u[i+1] */
        __m128d vv1 = _mm_loadu_pd(&v[i]); /* load vv1 = v[i], v[i+1] */
        __m128d uv2 = _mm_loadu_pd(&u[i + 2]); /* load uv2 = u[i+2], u[i+3] */
        __m128d vv2 = _mm_loadu_pd(&v[i + 2]); /* load vv2 = v[i+2], v[i+3] */
        __m128d dv1 = _mm_sub_pd(uv1, vv1); /* dv1 = uv1 - vv1 */
        __m128d dv2 = _mm_sub_pd(uv2, vv2); /* dv2 = uv2 - vv2 */
        dv1 = _mm_mul_pd(dv1, dv1);  /* dv1 = dv1 * dv1 */
        dv2 = _mm_mul_pd(dv2, dv2);  /* dv2 = dv2 * dv2 */
        sv1 = _mm_add_pd(sv1, dv1);  /* sv1 += dv2 */
        sv2 = _mm_add_pd(sv2, dv2);  /* sv1 += dv2 */
    }
    sv1 = _mm_add_pd(sv1, sv2); /* sv1 + sv2 */
    s = horizontal_add(sv1);    /* sv1[0] + sv1[1] */

sv1 = _mm_add_pd(sv1, dv1);  /* sv1 += dv2 */
sv2 = _mm_add_pd(sv2, dv2);  /* sv1 += dv2 */

I assume these comments are typo'd.

I don't think comments add a lot. I take my comment about "thinly disguised assembler" back, because I read up intrinsics and at least register allocation is done by the compiler, so it's less tricky than I thought.
I also looked at how this stuff is implemented by GCC and Clang, and they both support the same vector extension syntax, so an SSE register is
typedef double __m128d __attribute__((__vector_size__(16)));

and multiplication is actually defined as
static __inline__ __m128d __attribute__((__always_inline__, __nodebug__))
_mm_mul_pd(__m128d __a, __m128d __b)
{
  return __a * __b;
}

in both compilers. I.e., it looks to me like they're implementing intrinsics by mapping them onto a cleaner API. Would it be feasible to program using these vector extensions directly instead of using the intrinsics? A dot product can be written
typedef double Double2 __attribute__((vector_size(16)));

double dot(const double *a, const double *b, npy_intp n)
{
    Double2 acc = {0, 0};
    double s;
    npy_intp i;

    for (i = 0; i < n - (n & 1); i += 2) {
        acc += (Double2){a[i], a[i + 1]} * (Double2){b[i], b[i + 1]};
    }
    s = acc[0] + acc[1];
    for (; i < n; i++) {
        s += a[i] * b[i];
    }
    return s;
}

The inner loop of the above compiles to
.L3:
	movsd	(%rdi,%rax,8), %xmm0
	movsd	(%rsi,%rax,8), %xmm2
	movhpd	8(%rdi,%rax,8), %xmm0
	movhpd	8(%rsi,%rax,8), %xmm2
	addq	$2, %rax
	cmpq	%rdx, %rax
	mulpd	%xmm2, %xmm0
	addpd	%xmm0, %xmm1
	jb	.L3

while the non-unrolled loop by @juliantaylor becomes
.L3:
	movupd	(%rdi), %xmm1
	addq	$2, %rax
	addq	$16, %rdi
	addq	$16, %rsi
	movupd	-16(%rsi), %xmm2
	cmpq	%rdx, %rax
	mulpd	%xmm2, %xmm1
	addpd	%xmm1, %xmm0
	jb	.L3

so it's just the loads that are not optimized by GCC. Clang is smarter and compiles both to
.LBB0_2:
	movupd	(%rdi,%rax,8), %xmm0
	movupd	(%rsi,%rax,8), %xmm2
	mulpd	%xmm0, %xmm2
	addpd	%xmm2, %xmm1
	addq	$2, %rax
	cmpq	%rdx, %rax
	jb	.LBB0_2

so this seems to be a reasonable option (but I still have to do timings).

The nice thing about this is that we can also set the vector size to a larger value and unroll the loops twice; Clang at least is smart enough to turn unrolled SSE2 loops into AVX instructions when given -mavx.

yes vector extensions are a bit cleaner, and as you already noticed, the intrinsics in gcc and clang are actually implemented in terms of vector extensions.
While the code is a bit cleaner, the drawback is possibly worse portability.
clang and gcc work, but I do not know if ICC or MSVC support them. But I know for sure that those two do support intrinsics (actually msdn has the best available docs for this stuff).
are you sure clang changes SSE to AVX for you? that is a feature I'd like but never saw in any compiler (including clang), usually what it does is just change the encoding to VEX but still works on the 128 bit xmm registers instead of the larger ymm ones.

I'd prefer keeping it as intrinsics as it gives you better control and better googleability about what it does.
E.g. figuring out what a vector extension comparison does it not so easily found and may even depend on the compiler and hardware, while _mm_cmpeq_pd is easy to google and gives a well defined result.

Clang output uses the ymm registers, though not in all instructions.
ICC apparently has broken support for these extensions (but is good at vectorizing anyway). MSVC probably doesn't have any of this, so it should be wrapped in some ifdefs (and maybe split out to a common header file; I've seen custom vector operations in spatial, sparse and optimize, and there might be more of them).

intrinsics work just fine in MSVC.
let me know when you have made up your mind, my recommendation stays that the method here is the most reliable and simplest option, it works well in numpy and hundreds of other non-gcc specific projects.
Using gcc/clang specific -funsafe-math-optimizations is my second place recommendation as it allows simple reliable transformation to AVX or other hardware but is less reliable (e.g. hamming won't work) and needs distutils hackery.
A third option would be adding a vector class library like agner fog's one. But at this time that seems overkill for this one use.

Sorry for being late to the party.  (And be warned that future responses may be similarly non-prompt.)
I'm not against using SSE2 intrinsics in scipy code, but I suspect I'm not the only one with some tutorial-level questions.  (Eventually I might be able to answer the following myself--I'll be experimenting with the code over the next few days.)
Are there potential problems with passing in arrays that are less than ideally aligned?
If this PR is merged, and I build scipy on a machine with SSE2 capability, how do I disable the use of this SSE2 code?  Packagers of binary distributions (e.g. Enthought's Canopy, Continuum's Anaconda) might want to build non-sse versions for general use.
If we merge this, we'll need to modify the Travis CI configuration to run the tests with and without SSE2 enabled.

unaligned memory does not matter as the code uses alignment safe instructions which are on machines newer than the core2 have pretty much the same speed.
the sse2 code is only enabled on amd64. sse2 is mandatory for all x86 64 bit cpus so no generic configuration is required. 32 bit builds will not use the code unless explicitly requested via compiler flags (-msse2).
if you want to test the scalar loops beyond the peeling parts required also with sse2 you do need a second configuration explicitly disabling sse2 (or a 32 bit build). I think the loops are so trivial this is not necessary, the scalar loops are still covered and should one wants to change them it is easy to disable the vector loop temporarily (rename the ifdef macro).

if you want to test the scalar loops beyond the peeling parts

"peeling parts"?  Remember, tutorial level... :)
Trivial code still needs tests.  We have two cases: SSE2 and non-SSE2.  We should be able to run the tests on Travis for these two cases.  I don't have a proposal for how to do that at the moment.

vectorized loops work on multiple elements in per iteration, the remainder is handled in a scalar peeled loop. Here the peeling loop, the last iteration for odd number of elements, is the same as loop that would be used for disabled SSE2.
If one has to deal with alignment one sometimes also peels the first few iterations of the loop to archive alignment for the main loop.

#4437 is an alternative with GCC vector extension syntax.

if you prefer that, I'll update this pr to use them, though then I'll add alignment peeling to not penalize gcc which seems to have trouble with the (Double2){a, b} syntax

I'm somewhat opposed to requiring this kind of optimization leave MSVC out
in the cold. We have something that is the standard, cross platform
hardware vendor recomended method and we want to move to something that
doesn't work with the default compiler on the worlds most popular
platform?  I think this needs a little more justification.
On Monday, January 19, 2015, Julian Taylor<EMAIL_ADDRESS>wrote:

if you prefer that, I'll update this pr to use them, though then I'll add
alignment peeling to not penalize gcc which seems to have trouble with the
(Double2){a, b} syntax
—
Reply to this email directly or view it on GitHub
https://github.com/scipy/scipy/pull/4379#issuecomment-70569397.

I am +1 on @ewmoore's comment: we Windows users may not be the coolest kids on the block, but it wouldn't be nice to not invite us to the party!

Given the current state of CI (no Windows tests) and limited amount of testing by MSVC users I'd be very worried about breaking MSVC when enabling advanced features like this for it. Half the time master has failures for MSVC even for plainer C changes.

these aren't exactly new features, MSVC has them since at the very least 2005

Maybe now is a good time to try setting up testing with buildbots e.g at http://nipy.bic.berkeley.edu/builders ?   You can now add extra build status entries to commits on Github: https://github.com/blog/1935-see-results-from-all-pull-request-status-checks

I thought MinGW was the recommended compiler on Windows? Also, can someone check if MSVC doesn't vectorize these loops? The reason for targeting GCC is not only that it's the default on Linux, but also that it's rather bad at autovectorization.

fwiw its not bad it just decides to implement the C standard and making performance optimizations configurable. A decision commercial compilers usually don't make so they can win benchmarks (but to be fair the C standard is probably too strict in many cases).

I did something similar to cKDTree in #4374, based on @larsmans PR #4437
ICC could accelerate the loop if it were manually unrolled, but the resulting code was not as fast as using GNU SIMD syntax with clang 3.5.
// XXX earlier versions of GCC and Clang might work
#ifndef __INTEL_COMPILER
#if ((defined(__GNUC__) && (__GNUC__ > 4))\
    || (defined(__clang__) && ((__clang_major__ >= 3) && (__clang_minor >= 4)))\
    || defined(__APPLE__)) // FIXME: clang defines don't work for clang 3.5 in Xcode
#define SCIPY_SIMD
#endif
#endif // __INTEL_COMPILER

inline npy_float64
sqeuclidean_distance_double(const npy_float64 *u, const npy_float64 *v, npy_intp n)
{
    npy_float64 s;
    npy_intp i;
#ifdef SCIPY_SIMD
    // GCC SIMD extension, will be vectorized
    typedef npy_float64 Double4 __attribute__((vector_size(4 * sizeof(npy_float64))));
    Double4 acc = {0, 0, 0, 0};
    for (i = 0; i < n/4; i += 4) {
        Double4 d = (Double4){u[i], u[i + 1], u[i + 2], u[i + 3]} -
            (Double4){v[i], v[i + 1], v[i + 2], v[i + 3]};
        acc += d * d;
    }
    s = acc[0] + acc[1] + acc[2] + acc[3];
    if (i < n) {
        for(; i<n; ++i) {
            npy_float64 d = u[i] - v[i];
            s += d * d;
        }
    }
#else
    // manually unrolled loop, might be vectorized
    npy_float64 acc[4] = {0, 0, 0, 0};
    for (i = 0; i < n/4; i += 4) {
        npy_float64 _u[4] = {u[i], u[i + 1], u[i + 2], u[i + 3]};
        npy_float64 _v[4] = {v[i], v[i + 1], v[i + 2], v[i + 3]};
        npy_float64 diff[4] = {_u[0] - _v[0],
                               _u[1] - _v[1],
                               _u[2] - _v[2],
                               _u[3] - _v[3]};
        acc[0] += diff[0] * diff[0];
        acc[1] += diff[1] * diff[1];
        acc[2] += diff[2] * diff[2];
        acc[3] += diff[3] * diff[3];
    }
    s = acc[0] + acc[1] + acc[2] + acc[3];
    if (i < n) {
        for(; i<n; ++i) {
            npy_float64 d = u[i] - v[i];
            s += d * d;
        }
    }
#endif
    return s;
}

I could not make the code with GNU vector extensions compile with ICC 14.0.2, so at least with this compiler it is not supported. ICC is however so good at autovectorization that manually unrolling worked surprisingly well.
I am not sure we should worry too much about MSVC. It cannot build SciPy anyway. But if someone insists on using it anyway there should be plain ANSI C fallback code.

@larsmans we build our official binaries with MinGW (32-bit only until now, 64-bit still in progress), but MSVC is more commonly used. It's what Python itself is compiled with and what is used for Canopy & Anaconda.

I believe Anacoda and Canopy are built with ICC.

More in general: we care about performance for common compilers on Windows, OS X and Linux, and care about not breaking any exotic platforms. Just got a numpy build error report for AIX for example....

@sturlamolden MSVC + ifort can definitely build Scipy. I'm not 100% sure about Canopy & Anaconda, but the popular binaries from Christoph Gohlke are definitely built with MSVC. We should care.

Ok, that is good to know.

How well does autovectorization work with MSVC?

Another option is to use Fortran and just let the Fortran compiler take care of the SIMD vectorization. The Fortran subroutine can then be exposed to C through an inline function.

For example, if I write the obvious Fortran 2003 code
subroutine sqeuclidean_distance_double(u, v, n, r)
    use iso_c_binding
    implicit none
    integer(c_intptr_t) :: n
    real(c_double) :: u(n), v(n), r
    real(c_double) :: tmp, acc
    integer(c_intptr_t) :: i
    acc = 0
    do i = 1,n
        tmp = u(i) - v(i)
        acc = acc + tmp*tmp
    end do
    r = acc
end subroutine

then gfortran 4.8.2 produces this loop:
L3:
	vmovsd	-8(%rdi,%rax,8), %xmm0
	vsubsd	-8(%rsi,%rax,8), %xmm0, %xmm0
	addq	$1, %rax
	cmpq	%rdx, %rax
	vmulsd	%xmm0, %xmm0, %xmm0
	vaddsd	%xmm0, %xmm1, %xmm1
	jne	L3

:smile:

Oh yes, and with Fortran 2003 we can also produce a C callable function directly:
function sqeuclidean_distance_double(u, v, n) &
    bind(C, name="sqeuclidean_distance_double")
    use iso_c_binding
    implicit none
    real(c_double) :: sqeuclidean_distance_double
    integer(c_intptr_t), value, intent(in) :: n
    real(c_double), intent(in) :: u(n), v(n)
    real(c_double) :: tmp, acc
    integer(c_intptr_t) :: i
    acc = 0
    do i = 1,n
        tmp = u(i) - v(i)
        acc = acc + tmp*tmp
    end do
    sqeuclidean_distance_double = acc
end function

This one has the C signature:
extern double
sqeuclidean_distance_double(const double *u, const double *v, npy_intp n);

Fortran is still the king of number crunching :smile:

how is all this crap more readable than the code that is here right now?

as this does not look there is going to be a consensus, its probably best I change it to my option 2, keep code unchanged and use gcc's -funsafe-math-optimizations.
I'd still like to keep the intrinsics for hamming but that should be less contentious as there is only one available option.
But one last note on portability, numpy uses intrinsics since a while and there have been no issues (besides a minor mingw3 issue that was actually caused by being too careful). And numpy is probably built on more obscure platforms than scipy.

I guess readability is a matter of taste :-)
Personally I think it is wonderful that this loop is compiled to the most optimized AVX code:
    do i = 1, n
        tmp = u(i) - v(i)
        acc = acc + tmp*tmp
    end do

To me Fortran is more readable than the SIMD intrinsics because I have used it a lot. SIMD intrinsics are not very readable to me, because I am unfamiliar with them. But that is just my personal perspective.
But regardless of perspective this shows that we sometimes have to beat C with a stick to get the best numerical performance. Fortran compiles to the fastest SIMD-code without any abuse. It is easier to just focus on the code, rather than also worry about the binary code produced by the compiler. There is a reason many scientists love Fortran [even though is is loathed by CS folks].

the assembly code you posted shows no sign of vectorization or using AVX besides VEX encoding, all scalar instructions (sd vs pd)

As for releasing the GIL, it might not be an advantage as these functions are potentially execute in a very short time. So it might be that some sort of conditional GIL-release depending on n should be used.

The GIL release has already been merged.

Sure, but that doesn't mean its static, and it does not mean it cannot be discussed. I am not against it, I just think there is a valid objection for small values of n.

Of course. NumPy actually has a macro for this, NPY_BEGIN_THREADS_THRESHOLDED(loop_size).

Using BLAS might alo be an option. Something like this (not tested):
double
sqeuclidean_distance_double(const double *u, const double *v, npy_intp n)
{
    const int c = 4096; /* magic number */
    double tmp[c];
    double r = 0.0;
    npy_intp i = 0;
    for (i=0; i<n/c; i++) {
        cblas_dcopy(c, &u[i*c], 1, tmp, 1);
        cblas_daxpy(c, -1.0, &v[i*c], 1, tmp, 1);
        r += cblas_ddot(c, tmp, 1, tmp, 1);
    }
    for (i = (n/c)*c; i<n; i++) {
        double d = u[i] - v[i];
        r += d*d;
    }
    return r;
}

The BLAS code works, but at least with Accelerate it is not faster than a simple C loop.

And with MKL I only got half the performance I got with Accelerate. So no, BLAS is no good here.


Question about this package

Hi, I am confused about this file when I using it. Is there any information about the detail description of API?

@ZhihuaZhang  have you checked this other issue?
https://github.com/openai/imitation/issues/3

here is a good usage help: https://danieltakeshi.github.io/2017/06/15/openais-generative-adversarial-imitation-learning-code/


SDK meeting type should take into account the Release plan type

When a user links a Release plan to an SDK review meeting that is getting created, the meeting type can be automatically selected to match the type of release plan. For example, if the release plan is for beta sdk, then the type of meeting will be Beta.
The scheduler should still let the user select the other option just in case. (although I can't think of a valid scenario for this).
@ronniegeraghty and @ladonnaq what do you think?

This is a great idea. Will certainly help with a lot of teams not choosing the right type.
This might need to be its own issue, but we should also either not allow or warn users who are trying to link a release plan for mgmt libraries to an Azure SDK Review, that Azure SDK Reviews are for data plane only.

warn users who are trying to link a release plan for mgmt libraries to an Azure SDK Review, that Azure SDK Reviews are for data plane only.

At the very least we can filter the release plans to only show data plane release plans. Also, the release plans and our documentation for ARM never mentions the SDK meeting so hopefully we don't have those cases often. Are you seeing a lot of cases?
FYI for API Review meetings we do check the PR labels and if it is not data plane then we don't let them create the meeting. I don't think we have something similar here

Are you seeing a lot of cases?

Only two instances so far. So not a lot.

FYI for API Review meetings we do check the PR labels and if it is not data plane then we don't let them create the meeting. I don't think we have something similar here

No, we don't really have an equivalent here since we don't require teams have an Open PR before scheduling an Azure SDK Review.

This might need to be its own issue, but we should also either not allow or warn users who are trying to link a release plan for mgmt libraries to an Azure SDK Review, that Azure SDK Reviews are for data plane only.

https://github.com/Azure/azure-sdk-tools/issues/9535

Done in dev:
https://github.com/user-attachments/assets/65cfdbf2-81c6-489a-8fec-1f2663bdaaa4


macOS only: VK_ERROR_INITIALIZATION_FAILED: Render pipeline compile failed (error code 1)

I have the following vertex shader:
layout (std140, set = 0, binding = 1) uniform modelViewMatrixBuf
{
	mat4 modelViewMat;
} matArry[4];

layout(push_constant) uniform pushConstansBuf
{
	mat4 projMat;		//Projection Matrix (64-bytes)
	uint matIndex;		//Matrix array index (4-bytes)
};

void main()
{
	uint index = matIndex;
	gl_Position  = pos3D * matArray[index].modelViewMat * projMat;
	...
}

Where I have one uniform buffer array matArry[4] to host model-view-matrix; a push constants buffer pushConstansBuf that has a field matIndex used to address the matrix from the uniform buffer array.
This shader caused [***MoltenVK ERROR***] VK_ERROR_INITIALIZATION_FAILED: Render pipeline compile failed (error code 1): Compilation failed. when app runs on macOS but runs well on iOS.
When hard-coding the array index by either one of the following code, the render pipeline compilation will succeed:
Hard coding 1 : uint index = 0;
Hard coding 2 : pos3D * matArray[0].modelViewMat * projMat
It seems like as long as the shader reference the push constants field matIndex, the render pipeline compilation will fail.
My app runs well on all other platforms (Windows, Android) and MoltenVK iOS.
Any suggestions?
The full XCode Log
Shader Texture3D.frag
shader Texture3D.vert

Update: This VK_ERROR_INITIALIZATION_FAILED problem also happens on iOS.
the error message includes "Internal error during vertex / fragment function compilation".
It has more chance to happen if the shader (vertex or fragment) has uniform buffer or sampler array and the shader uses a push constant to choose which uniform buffer or sampler to use.

@HansKristian-Work
Would you mind having a look at this, please?
I'm wondering if this has arisen as a side-effect of recent changes to matrices/arrays/structs handling.
The  matArray[4] in the vertex shader above becomes in MSL:
struct modelViewMatrixBuffer
{
    float4x4 modelViewMat;
};

struct per_frame_PC
{
    float4x4 projMat;
    uint modelVewMatBufIndex;
};

vertex main0_out main0(main0_in in [[stage_in]], constant modelViewMatrixBuffer* UB00_0 [[buffer(0)]], constant modelViewMatrixBuffer* UB00_1 [[buffer(1)]], constant modelViewMatrixBuffer* UB00_2 [[buffer(2)]], constant modelViewMatrixBuffer* UB00_3 [[buffer(3)]], constant per_frame_PC& _37 [[buffer(12)]])
{
    constant modelViewMatrixBuffer* UB00[] =
    {
        UB00_0,
        UB00_1,
        UB00_2,
        UB00_3,
    };

    main0_out out = {};
    out.outUV = in.texUV;
    out.gl_Position = (float4(in.pos2D, 0.0, 1.0) * UB00[_37.modelVewMatBufIndex]->modelViewMat) * _37.projMat;

Although we don't get a clear error message back from Metal...I suspect that one issue is that the contents of the UB00 array get smeared across several actual buffers [[buffer(i)]] in the arguments to main0().
That shouldn't be necessary on a uniform buffer array...and won't match the content that MoltenVK will be setting into buffers.
Any thoughts on what is going on here?

I'll have a look.

Did some more digging by making a test case. FWIW, I got this shader to compile and run correctly with a push-constant driven index: https://github.com/Themaister/Granite/blob/master/tests/assets/shaders/fill_flat.frag.
I suspect this is actually more of a driver bug than anything else. I ran this on MacBook Pro 13" 2015 model on macOS 10.14.

While reproing, I ran into a related but different bug: https://github.com/KhronosGroup/SPIRV-Cross/issues/878. Optimized variants of these shaders could fail if the names were stripped, but it doesn't seem like the case we're hitting here.

I'm traveling now, if needed, I can upload my whole project for testing.

@HongkunWang Thanks. That would be helpful.

I just got a chance to see if I can upload the whole project for debugging, it turns out not that easy since there are some source code under IP protection involved. I'll find a time to make a stripped version then upload it.
We also noticed that in-shader descriptor array is not supported well by few other platforms, so we decided that use CPU-side descriptor array, this also can skip using push constants to choose the array elements. It works pretty well.


Inconsistent behaviour with .as_slice()

Aim
The double_verify_proof was recently not working as expected for barretenberg.
The code that panics in barretenberg:
use dep::std;

fn main(
    verification_key : [Field; 114],
    proof : [Field; 94],
    public_inputs : [Field; 1],
    key_hash : Field,
    input_aggregation_object : [Field; 16],
    proof_b : [Field; 94],
) -> pub [Field; 16] {
    let output_aggregation_object_a = std::verify_proof(
        verification_key.as_slice(),
        proof.as_slice(),
        public_inputs.as_slice(),
        key_hash,
        input_aggregation_object
    );

    let output_aggregation_object = std::verify_proof(
        verification_key.as_slice(),
        proof_b.as_slice(),
        public_inputs.as_slice(),
        key_hash,
        output_aggregation_object_a
    );

    let mut output = [0; 16];
    for i in 0..16 {
        output[i] = output_aggregation_object[i];
    }
    output
}

The code that works in barretenberg:
use dep::std;

fn main(
    verification_key : [Field; 114],
    proof : [Field; 94],
    public_inputs : [Field; 1],
    key_hash : Field,
    input_aggregation_object : [Field; 16],
    proof_b : [Field; 94],
) -> pub [Field; 16] {

    let verification_key : [Field] = verification_key;
    let proof : [Field] = proof;
    let proof_b : [Field] = proof_b;
    let public_inputs : [Field] = public_inputs;

    let output_aggregation_object_a = std::verify_proof(
        verification_key,
        proof,
        public_inputs,
        key_hash,
        input_aggregation_object
    );

    let output_aggregation_object = std::verify_proof(
        verification_key,
        proof_b,
        public_inputs,
        key_hash,
        output_aggregation_object_a
    );

    let mut output = [0; 16];
    for i in 0..16 {
        output[i] = output_aggregation_object[i];
    }
    output
}

Expected Behavior
Both of these codepaths should work
Bug
We get a panic in barretenberg and barretenberg when deserializing says that input aggregation object has 1 value instead of 16. It is the witness with index 342.
To Reproduce

Installation Method
None
Nargo Version
No response
Additional Context
No response
Would you like to submit a PR for this Issue?
No
Support Needs
No response

Note that both of these pass execution, so it may be a bug in serde-reflect

Retroactive questions so that we can spot this earlier:

Why did this not pop up on any other test?
Why do both of those pass execution, but only fail in barretenberg?


[Docs] Add hardware test matrix to InstructLab repo

Description: Adding a hardware test matrix to the docs to show hardware "support" and expectations

@nathan-weinberg Clarifying question, based on what you mentioned. The only section that would be the " 🟢 Supported, regularly tested by CI" would be for the NVIDIA L4s and the NVIDIA L40s x4. And the others would mostly be 🟡 Supported in theory but not regularly tested by CI or obviously not tested. Is that right, or am I not understanding something?

That's correct! With the goal being to expand our CI coverage :smile: this could be a good basis to expand our portfolio of upstream NVIDIA hw testing, for example

I think this is an absolutely great  addition. Please add!

@kelbrown20 can we add the NVIDIA L40S x8 as a CI-tested system now that we have the XL job?


How to set Terminus as default terminal app on mac?

Just wondering if this is posssible and how to do it?

There's no concept of 'default terminal app' in macOS - what effect do you expect changing it to have? When other apps are trying to invoke the terminal, they are executing stock Terminal.app directly.


Update to non code-block URLS (addresses #939 )

@sanderson This randomly failed circleci? Not sure if that's anything I need to worry about or if I can just merge.

@noramullen1 I'll look into why it's failing.


PHP Library

Hey @masajiro, thanks for all the continued work on this!
Just wanted to share there are now PHP bindings as well 🎉

Thanks!!

No problem!


Upgrade dependencies

@aalmada Could you add a Github tag for the new 2.0.4 release?

@xtqqczze Sure! I forgot to do that. Thanks for reminding me. Done!


Abseil 2d2a8ae and later does not build against glibc 2.32 and later

Describe the bug
Compiling Abseil as a whole, or a target which transitively depends on the absl::base_internal::StrError, fails with the following report:
FAILED: absl/base/CMakeFiles/strerror.dir/internal/strerror.cc.o
/usr/bin/c++  -I../ -Wall -Wextra -Wcast-qual -Wconversion-null -Wmissing-declarations -Woverlength-strings -Wpointer-arith -Wunused-local-typedefs -Wunused-result -Wvarargs -Wvla -Wwrite-strings -Wno-missing-field-initializers -Wno-sign-compare -std=gnu++11 -MD -MT absl/base/CMakeFiles/strerror.dir/internal/strerror.cc.o -MF absl/base/CMakeFiles/strerror.dir/internal/strerror.cc.o.d -o absl/base/CMakeFiles/strerror.dir/internal/strerror.cc.o -c ../absl/base/internal/strerror.cc
../absl/base/internal/strerror.cc: In function ‘const char* absl::base_internal::{anonymous}::StrErrorAdaptor(int, char*, size_t)’:
../absl/base/internal/strerror.cc:41:31: error: ‘sys_nerr’ was not declared in this scope
   41 |   if (0 <= errnum && errnum < sys_nerr) {
      |                               ^~~~~~~~
../absl/base/internal/strerror.cc:42:25: error: ‘sys_errlist’ was not declared in this scope
   42 |     if (const char* p = sys_errlist[errnum]) {
      |                         ^~~~~~~~~~~
[13/155] Building CXX object absl/base/CMakeFiles/base.dir/internal/sysinfo.cc.
ninja: build stopped: subcommand failed.

Steps to reproduce the bug
In the abseil source directory, with a system glibc of 2.32 or later:
cmake -S . -B build -GNinja -DCMAKE_CXX_STANDARD=11
cmake --build build

What version of Abseil are you using?
Any including commit 2d2a8aea291c4877e75c7991a61e57d7e12b5373
What operating system and version are you using
Arch Linux (rolling release), with glibc installed at package version 2.32-3
What compiler and version are you using?
% g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-libunwind-exceptions --disable-werror gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.0 (GCC)

What build system are you using?
cmake version 3.18.2, with ninja version 1.10.1
Additional context
The release announcement for glibc 2.32 includes the following:

The deprecated symbols sys_errlist, _sys_errlist, sys_nerr, and _sys_nerr
are no longer available to newly linked binaries, and their declarations
have been removed from from <stdio.h>.  They are exported solely as
compatibility symbols to support old binaries.  All programs should use
strerror or strerror_r instead.

absl/base/internal/strerror.cc, the file causing the build failure, references the removed names sys_errlist and sys_nerr.

I was actually in the process of preparing a patch for this, you've beat me to it haha!

A fix is submitted. It will be pushed to GitHub tomorrow hopefully.

sj

من: Xenhat<EMAIL_ADDRESS>تاريخ الإرسال: الأربعاء, سبتمبر 2, 2020 10:21 م
إلى: abseil/abseil-cpp
نسخة: Subscribed
الموضوع: Re: [abseil/abseil-cpp] Abseil 2d2a8ae and later does not build against glibc 2.32 and later (#774)
I was actually in the process of preparing a patch for this, you've beat me to it haha!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/abseil/abseil-cpp/issues/774#issuecomment-685945654, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AOJUIOXABALOJS7DUU4W6HDSD2LLFANCNFSM4QSMLUMQ.

I've tested my own patches and they work. I'll be using them until an official fix is pushed as it blocks our development cycle.

This is fixed.


Small fixes

This PR addresses a variety of small visual issues.

the beta label has a tooltip if the user is not in testnet mode.
the superfluous info icon next to the coupon label in purchase was removed
a placeholder was added for the coupon input in purchase
the coupon input being blank is now handled separately from an invalid code
the ... button on the user page was removed
the windows controls were updated to look more like Mac controls and be centered properly
other nav bar icons that were off center vertically were fixed

Closes #789, 790, 791, 788, and 786

The middle icon gets an underline when you hover over it. I'm assuming it shouldn't since the others don't and it arguably looks cleaner without.

Noticed the same issue that @rmisio reported above too. Otherwise, looks good to me.

Huh. Good catch. I'm not sure how that happened. Will investigate and update later tonight.

@rmisio underline removed.


Try to diagnose more misspellings of the swift-tools-version comment

Previously we only considered misspellings if we at least matched
'// swift-tools-version:', with this change we will consider a tools
version comment a misspelling if the first line starts with // and
contains the string 'swift-tools-version' (but doesn't match our regex).

https://bugs.swift.org/browse/SR-4134

@swift-ci please test

Approved for the Swift 3.1 branch.


Is a guideline for coding XAML really necessary?

I stumbled upon this site while looking for a XAML UI styling guidelines.  At first, it makes sense, but after further thought, I wonder if it is necessary.  XAML is more like HTML and XML in that it is often generated and  is structurally and syntactically simple enough not to become hard to understand.
The main issue with XAML is the large amount of code needed that can be unwieldy to navigate and work with, but its based more on its markup nature, not on how it was written.  You guidelines would, however, make an excellent set of rules for formatting XAML in Visual Studio or Resharper.  Implementing these guidelines for strictly coded XAML may have limited utility.

I feel that having guidelines is extremely helpful at my job. We write XAML and do not generate it, and not following a guideline will result in poorly maintainable code.  Large amount can often be solved by breaking it up into smaller files, this helps a lot.

Haavamoa - I could not agree more.  Maintainability is a significant issue with large volumes of XAML.  One of the most common complaints is that finding all data sources for a XAML UI frequently involves more than looking at the view-model.  A good deal of time is spent locating the data sources.  This is especially true when developers who are new to the project are pulled in.  Clear (but not excessive) documentation that lists all data sources could save significant time.  Why go on code-safari to find something that you should have at your finger tips?

I guess I'm looking at XAML from a completely different point of view. I see XAML like object code. You would never write it unless your Torvalds (he boasted about hand assembling code), but you may want to inspect it visually during a debugging session. Likewise, XAML should be generated automatically by drawing and connecting UI items. This was done way back in the 1980s. Here we are in 2020 and we can't do better?
WYSIWYG editors have never worked for HTML and almost worked for XAML using Blend, but it doesn't mean we should pull the plug on it. XAML can be made more machinable while still being human readable and editable. Back in the 80s you could create UIs either by editing the .RC files or creating them in a resource editor. HTML and our experiences with XAML have ingrained a distrust for WYSIWYG. Many believe they inherently produce suboptimal code that's inefficient.
WYSIWYG editors can and do excellent code. PostScript is an excellent example. When was the last time you even seen its code? There's a good chance you have use it daily whenever you hit the print button. You didn't care about the code, so long as the print out looks like what you see on the screen. MacOS uses Quartz, a derivative of Display Postscript which essentially did the same thing for the screen.


Step 10 needs more beer.

https://github.com/Azure/blackbelt-aks-hackfest/blob/master/linux-container-workshop/hol-content/10-cluster-upgrading.md
This step says to use az aks get-versions which doesn't work..
$ az aks get-versions
az aks get-versions: error: the following arguments are required: --location/-l
usage: az aks get-versions [-h] [--verbose] [--debug]
                           [--output {json,jsonc,table,tsv}]
                           [--query JMESPATH] --location LOCATION

I suspect it wants us to use az aks get-upgrades except it never explains how to set $AKS_CLUSTER_NAME or $RESOURCE_GROUP_NAME
Reusing the vars from the earlier steps.. I guessed at..
NAME=$(az group list | jq '.[0]."name"' -r)
CLUSTER_NAME="${NAME//_}"
AKS_CLUSTER_NAME=$CLUSTER_NAME
RESOURCE_GROUP_NAME=$NAME

Either the page needs to use the old vars and explain how to set them, or it should show how to set the new vars used on that page.
Page also needs more beer. Amount consumed while writing this page was insufficient leading to inconsistencies.

Thanks @BarDweller for the feedback! Like discussed, this PR #64 is tackling these feedback for more consistency across all the labs. Thanks!

Please take a look chzbrgr71@7ba8d51
This change was made yesterday

@jschluchter , interesting one, why it's not in master? Furthermore, we are tackling the feedback documented by this issue here: PR #64 .

PR #64 closed and merged into master, we could close this issue.

merged


Fix missing function in README sample

LGTM, but I don't see the CLA being signed. Just a technical formality. I don't see the popup for that though.

LGTM, but I don't see the CLA being signed. Just a technical formality. I don't see the popup for that though.

LGTM, but I don't see the CLA being signed. Just a technical formality. I don't see the popup for that though.

It should be signed now.


remove H2 header normalisation runtime guard

Commit Message: Remove header guards for H3 header normalisation that were introduced during the CONNECT UDP implementation
Additional Description:  It has been well over 6 months since this was introduced so this cleanup is overdue
Risk Level: Low
Testing:
Docs Changes:
Release Notes: Removed runtime guard envoy_reloadable_features_use_http3_header_normalisation and legacy code paths
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #3768 Fixes https://github.com/envoyproxy/envoy/issues/30428
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

could you check the CI? Thanks.


Bump fortran-curl version to 0.6.0

Should fix #58.
We should add macos workflow to CI in a separate pR.

LGTM

Thank you


How to tell if filtering and saving a video has finished

I have a video file that I am applying a filter to first , and then saving it. I am able to save the file, but  I am trying to figure out when exactly the file is saved completely so like a completion handler or something where I can do cleanup etc and next steps. Any clues as to what I need to do?
`
       movie = try MovieInput(asset: AVAsset(url: movieURL!), playAtActualSpeed: false)

       output = try MovieOutput(URL: newURL, size: Size(width: 1920, height: 1080))

        movie --> filter --> output

        output.startRecording()

        movie.start()`

I can't find a delegate method or notification or some sort to tell me the video processing has been completed. Any help would be greatly appreciate.. Thanks

If you manually finish recording, you can use the finishRecording method on your MovieOutput to provide a callback block for when that has completed.
Unfortunately, in the case of playing from a static movie file, it looks like I haven't yet brought across the delegate I had in the original GPUImage that informs you about when the movie playback has finished. Let me see about adding that.

Thanks for looking into it. I also noticed that looping for video playback hasn't been fully implemented.

Is there any update on this?

@BradLarson @real19 Hi, try to use the same code:
`            let movie = try MovieInput(asset: AVAsset(url: sourceURL!), playAtActualSpeed: false)
        let output = try MovieOutput(URL: outputURL, size: Size(width: 720, height: 1280))

        movie --> output

        output.startRecording()
        movie.start()`

but get crash
Fatal error: Unexpectedly found nil while unwrapping an Optional value
in MovieOutput line 83
CVPixelBufferPoolCreatePixelBuffer(nil, self.assetWriterPixelBufferInput.pixelBufferPool!, &self.pixelBuffer)
Could you please, help to find my mistake


Mixer config API GETs should support pagination

Mixer config api GETs should support pagination when it makes sense.

Irrelevant given current config story.


[cluster-utilization] change the get jobs limit to 50000

The job list should be filtered by completed time, we will fix this after the support in rest api #5347.

Coverage remained the same at 34.07% when pulling 814ee234b38aa15ccc4b5af50373df52b9e2549e on suiguoxin:get-jobs-limit into 86a092444d6eb5d6ec44a49414d32887d9f4466e on microsoft:master.


chore: temporary branch for IOx update (12-10-2023 try 2)

⚠ This draft PR is not intend to merge. This is a temporary branch for the purpose of updating DataFusion in InfluxData IOx, and help with https://github.com/apache/arrow-datafusion/pull/8722
The head of this branch is at:

Dec. 9 https://github.com/apache/arrow-datafusion/commit/d091b55be6a4ce552023ef162b5d081136d3ff6d / https://github.com/apache/arrow-datafusion/pull/8446

Cherry-picked bug fixes:

Dec. 14 https://github.com/apache/arrow-datafusion/commit/5909866bba3e23e5f807972b84de526a4eb16c4c / https://github.com/apache/arrow-datafusion/pull/8520
Dec. 14 https://github.com/apache/arrow-datafusion/commit/974d49c907c5ddb250895efaef0952ed063f1831 / https://github.com/apache/arrow-datafusion/pull/8533
Dec. 26 https://github.com/apache/arrow-datafusion/commit/26a8000fe2343e6a187dcd6e4e8fc037d55e213f / https://github.com/apache/arrow-datafusion/pull/8629

(btw you can make PRs in your own fork of DataFusion if you want, there is no need to make them in the apache repo -- not that there is anything wrong with creating them here)

Thank you @alamb! Good to know that I can make PRs in my own fork of DataFusion 👍 I'll do that in the future
Closing this one as it is no longer needed


⚠ Bofrost.es has degraded performance

In d616162, Bofrost.es (https://www.bofrost.es) experienced degraded performance:

HTTP code: 200
Response time: 1641 ms

Resolved: Bofrost.es performance has improved in d7d59cf after 6 minutes.


CycleFinderTask and TranslateTask Unit Tests

Testing Improvements:

Dependency injection for Project.exec {…} method
MockProjectExec testing utility class
First use of the Groovy MockFor system
CycleFinderTaskTest good coverage
TranslateTaskTest only basic coverage

Other Changes:

exec args to have proper iteration for adding as args
J2objcHome() standardize capitalization

@brunobowden - this is a large change to merge into a release branch without code review.
was that what you intended?
(i'll be able to review it thoroughly tomorrow...)

This was already reviewed in PR #249. I commented in that PR that I was moving it but I should've added a more explicit comment here as well. Here's my comment from the old PR:

My apologies @advayDev1 - this was my mistake and I didn't get it reviewed properly first. My confusion. I'll make sure that I'm careful about not doing this again.

I might just be missing something - I don't think anyone actually reviewed #249 at all.
Do you still want us to review these changes?  Or do you just want to release them?

They should still have review - my mistake at not getting that. This is a significant change when it comes to adding test coverage to the execution of command line tools. Important to have your review here.

@advayDev1 - start with this review first... the other PR is still in progress

@brunobowden , my overall comments for this CL:
Having a separate projectExec vs. project variable and using both of them in the VisibleForTesting methods you have introduced makes the code much harder to understand.  I'd instead just wrap the thing we need to mock instead of introducing two projects that can get out of sync.  For example: a utility class ProcessExecutor.  The production implementation takes in a Project and its own exec method merely calls the configurable exec DSL method on the Project.  The test implementation mocks the exec method on that ProcessExecutor.
Since this wasn't reviewed anyway, I'd prefer reverting this PR and using that method instead or discussing an alternative.

Happy to revert this and fix it another way. This is getting too complex to work on a branch. So let's punt this to a 0.4 release. I'm leaving on vacation in a couple of days time, so I'd at least like to get a proper fix merged in to master.

Sounds good.  Let's do the revert and get 0.3 out without this.


fix a link - display name

pipelines.md has a incorrect link in a section where with optional configruation.
displayName in multiple places should point to https://github.com/tektoncd/pipeline/blob/main/docs/pipelines.md#specifying-a-display-name instead it is pointing to https://github.com/tektoncd/pipeline/blob/main/docs/pipelines.md#adding-tasks-to-the-pipeline and https://github.com/tektoncd/pipeline/blob/main/docs/pipelines.md#adding-finally-to-the-pipeline.
optional:
  tasks:
    displayName

optional:
  finally:
    displayName:

/kind bug

Please assign me this issue

Please assign me this issue

hi @pranav-jadhav , you can comment /assign it should assign yourself to the issue (it just needs you to have a comment on the issue)
/assign @pranav-jadhav

Hi, I think I  can fix this

/assign @vavrajosef


Take/return scalar

https://github.com/alexander-wise/RvLineList/blob/6f57cd6572fb8678bb252fe64019d1e76394317a/src/empirical_line_lists.jl#L292-L293
The caller can broadcast over multiple dates if they want to.

note: commit c2e24acebcbb94396c2965b8ef6500c9813c1062 to reduce memory allocations originally mistakenly referenced this issue, but was renamed


Consistent GKE number of nodes

fixes https://github.com/istio/istio.github.io/issues/2571

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: rcaballeromx
If they are not already assigned, you can assign the PR to them by writing /assign @rcaballeromx in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

content/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Hi @medyagh. Thanks for your PR.
I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
I understand the commands that are listed here.

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.

@salrashid123

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: hklai, sdake
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

content/OWNERS [sdake]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Cleanup NetBeans license header for module java.platform.ui

Review and cleanup the license header in java.platform.ui
Oracle donated NetBeans to the Apache Software Foundation.
Your task now is to replace the old license header that has Oracle (and/or Sun Microsystems
and/or NetBeans) in it with the standard Apache Software Foundation license header.
For an empty file that supports headers you must add the Apache license header.
Note that you have to use the proper license header for Java, .properties or HTML files.
Look at the nearby files for templates and copy-paste the license header.
When done commit the changes with a commit message that starts with first line
"[NETBEANS-54] Module Review " and a message body describing your review.
See a longer explanation about what we are doing here: https://cwiki.apache.org/confluence/display/NETBEANS/List+of+Modules+to+Review
Please announce in a comment when you have started work.
Files that need to be looked at in java.platform.ui:
java.platform.ui/src/org/netbeans/modules/java/platform/resources/templates/javaplatform.xml

There is no header for this file java.platform.ui/src/org/netbeans/modules/java/platform/resources/templates/javaplatform.xml

A header could still be added. Unless it's a user-visible template in which case we exclude it from Rat.

Taken upstream.


cmd/compile: CSE some function calls args/results

package p

var b bool

func f(x, y int) int {
	var r int
	if b {
		r = g(x, y)
	} else {
		r = h(x, y)
	}
	return r
}

//go:noinline
func g(x, y int) int { return 0 }

//go:noinline
func h(x, y int) int { return 0 }

This kind of code ("call either g or h with the same args") is not uncommon. It is compiled suboptimally; there is lots of duplicate code to set up and read the stack:
"".f STEXT size=122 args=0x18 locals=0x20
	0x0000 00000 (x.go:5)	TEXT	"".f(SB), $32-24
	0x0000 00000 (x.go:5)	MOVQ	(TLS), CX
	0x0009 00009 (x.go:5)	CMPQ	SP, 16(CX)
	0x000d 00013 (x.go:5)	JLS	115
	0x000f 00015 (x.go:5)	SUBQ	$32, SP
	0x0013 00019 (x.go:5)	MOVQ	BP, 24(SP)
	0x0018 00024 (x.go:5)	LEAQ	24(SP), BP
	0x001d 00029 (x.go:5)	FUNCDATA	$0, gclocals·54241e171da8af6ae173d69da0236748(SB)
	0x001d 00029 (x.go:5)	FUNCDATA	$1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
	0x001d 00029 (x.go:7)	MOVBLZX	"".b(SB), AX
	0x0024 00036 (x.go:7)	TESTB	AL, AL
	0x0026 00038 (x.go:7)	JEQ	84
	0x0028 00040 (x.go:7)	MOVQ	"".x+40(SP), AX
	0x002d 00045 (x.go:8)	MOVQ	AX, (SP)
	0x0031 00049 (x.go:8)	MOVQ	"".y+48(SP), AX
	0x0036 00054 (x.go:8)	MOVQ	AX, 8(SP)
	0x003b 00059 (x.go:8)	PCDATA	$0, $0
	0x003b 00059 (x.go:8)	CALL	"".g(SB)
	0x0040 00064 (x.go:8)	MOVQ	16(SP), AX
	0x0045 00069 (x.go:12)	MOVQ	AX, "".~r2+56(SP)
	0x004a 00074 (x.go:12)	MOVQ	24(SP), BP
	0x004f 00079 (x.go:12)	ADDQ	$32, SP
	0x0053 00083 (x.go:12)	RET
	0x0054 00084 (x.go:12)	MOVQ	"".x+40(SP), AX
	0x0059 00089 (x.go:10)	MOVQ	AX, (SP)
	0x005d 00093 (x.go:10)	MOVQ	"".y+48(SP), AX
	0x0062 00098 (x.go:10)	MOVQ	AX, 8(SP)
	0x0067 00103 (x.go:10)	PCDATA	$0, $0
	0x0067 00103 (x.go:10)	CALL	"".h(SB)
	0x006c 00108 (x.go:10)	MOVQ	16(SP), AX
	0x0071 00113 (x.go:7)	JMP	69
	0x0073 00115 (x.go:7)	NOP
	0x0073 00115 (x.go:5)	PCDATA	$0, $-1
	0x0073 00115 (x.go:5)	CALL	runtime.morestack_noctxt(SB)
	0x0078 00120 (x.go:5)	JMP	0

Setting up the stack for the call and processing the return could be CSE'd to dominating and post-dominating blocks. In pseudo code:
func f(x, y int) int {
	var r int
        arg0 = x
        arg1 = y
	if b {
		call g
	} else {
		call h
	}
        r = ret0
	return r
}

I suspect that at least for function arguments, our current CSE pass would work, but for the prohibition on CSEing values of memory type.
At the end of the generic cse pass, the code above looks like:
f <T>
  b1:
    v1 = InitMem <mem>
    v2 = SP <uintptr>
    v3 = SB <uintptr>
    v6 = Addr <*int> {~r2} v2
    v7 = Arg <int> {x}
    v8 = Arg <int> {y}
    v10 = Addr <*bool> {"".b} v3
    v11 = Load <bool> v10 v1
    v13 = OffPtr <*int> [0] v2
    v17 = OffPtr <*int> [8] v2
    v20 = OffPtr <*int> [16] v2
    If v11 -> b2 b4
  b2: <- b1
    v15 = Store <mem> {int} v13 v7 v1
    v18 = Store <mem> {int} v17 v8 v15
    v19 = StaticCall <mem> {"".g} [24] v18
    v21 = Load <int> v20 v19
    Plain -> b3
  b3: <- b2 b4
    v29 = Phi <int> v21 v28
    v30 = Phi <mem> v19 v27
    v31 = VarDef <mem> {~r2} v30
    v32 = Store <mem> {int} v6 v29 v31
    Ret v32
  b4: <- b1
    v24 = Store <mem> {int} v13 v7 v1
    v26 = Store <mem> {int} v17 v8 v24
    v27 = StaticCall <mem> {"".h} [24] v26
    v28 = Load <int> v20 v27
    Plain -> b3

Observe that v15/v24 and v18/v26 certainly look ripe for CSE.
Rolling back the prohibition on CSEing memory values would require care, though, since that helped a lot with CSE toolspeed problems. Continuing to prohibit CSE of calls might be a workable middle ground.
cc @randall77 @tzneal @dr2chase

Our calling convention allows callees to modify their input args on the stack.  So I don't think you can CSE v15 & v24, as the first call may modify what v15 put on the stack.
We could change the calling convention, of course.  I don't think many callees rely on this ability.  But nonetheless it's not a trivial change.

So I don't think you can CSE v15 & v24, as the first call may modify what v15 put on the stack.

Can you explain a bit more? I still don't see how this could cause trouble, at least as long as the sequence of CSE'd writes are all setting up the stack before a call.

Sorry, I was misinterpreting what you were suggesting. The calls are in different branches, not in serial.
Yes, we could CSE those writes.  We haven't been CSEing any pair where one instance does not dominate the other (memory type or otherwise).  In general, this is to avoid putting work at the dominator that doesn't need to be done on some path out of the dominator.  But when that work needs to be done on every path out of that dominator, we could move the values up with no chance of doing unneeded work.

For a simpler example, try
	if b {
		*p = x * 5
	} else {
		*p = x * 5
	}
}

Currently we don't CSE the x*5 computation.  It would be nice if we could, and such an optimization is probably a prerequisite for the optimization you're talking about in this issue.

In doing the "all dominated paths share expression" CSE, we should exclude panic edges.


listen to the size only if the logo exists

listen to the size only if the logo exists

The PR and the branch are bad named.

the validation within the function was added so as not to generate errors in other places where the logoelement does not exist


No such file or directory (os error 2)

Hello, thanks for the great tool!
I'm trying to make it work in CI. And I can give a lot of feedback in future.
Tried with many images and repositories, manually for starters.
cargo-chef v0.1.6

Error:
root@e893dc1d44bf:/builds/cargo-contract# cargo chef prepare  --recipe-path recipe.json
Error: Failed to compute recipe

Caused by:
    0: No such file or directory (os error 2)
    1: No such file or directory (os error 2)

Stack backtrace:
   0: chef::skeleton::Skeleton::derive
   1: chef::recipe::Recipe::prepare
   2: cargo_chef::main
   3: std::sys_common::backtrace::__rust_begin_short_backtrace
   4: std::rt::lang_start::{{closure}}
   5: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once
             at /rustc/ef663a8a48ea6b98b43cbfaefd99316b36b16825/library/core/src/ops/function.rs:259
      std::panicking::try::do_call
             at /rustc/ef663a8a48ea6b98b43cbfaefd99316b36b16825/library/std/src/panicking.rs:381
      std::panicking::try
             at /rustc/ef663a8a48ea6b98b43cbfaefd99316b36b16825/library/std/src/panicking.rs:345
      std::panic::catch_unwind
             at /rustc/ef663a8a48ea6b98b43cbfaefd99316b36b16825/library/std/src/panic.rs:382
      std::rt::lang_start_internal
             at /rustc/ef663a8a48ea6b98b43cbfaefd99316b36b16825/library/std/src/rt.rs:51
   6: main
   7: __libc_start_main
   8: _start

Repro:
run an image
docker run -it paritytech/contracts-ci-linux:4e476221-20201029

and there
git clone https://github.com/paritytech/cargo-contract .
cargo install cargo-chef
cargo chef prepare  --recipe-path recipe.json

The similar stuff happened to the paritytech/ink-ci-linux:65ef4994-20201008 image with https://github.com/paritytech/ink repo
and paritytech/ci-linux:2773c6ea-20201028 with https://github.com/paritytech/substrate. Except the latter is on stable toolchain and didn't show the unwind in the error.
Tried both with docker and podman.

I had the same error when not having set a WORKDIR. Setting it solved it for me.

Just tried and it didn't help :/

Bit busy these days, I'll try to have a look before next week :+1:

@TriplEight can you try this one cargo install --git https://github.com/NathanHowell/cargo-chef --branch with-manifest-fixes? I hit a few issues with my workspace project including this one.

@NathanHowell this works, and it is a huge improvement!
Tested with 3 workspace repositories I've mentioned here.
I've faced some other problems, will file them in the other issues.

The fix for this is in master - thanks @NathanHowell!


Respect Cache-Control: max-age=<seconds> when scheduling feed updates

Don’t schedule updates of feeds until after max-age or the user-configure update value; whichever is later. No need to pull in feeds more often if the feed response header says the cached feed will remain fresh until at least max-age seconds into the future from the time it was last fetched.
There is also the Expires: <date> header which specifies an exact date when the feed is expected to be outdated and needs to be refreshed. I do believe this has fallen somewhat out off fashion in favor of Cache-Control but there is no harm in supporting it too.
The goal is of course to save network bandwidth by not performing unneeded requests, and improve device battery by not chatting unnecessarily on the network.

I do believe this has fallen somewhat out off fashion in favor of Cache-Control but there is no harm in supporting it too.

@da2x Cache-Control doesn't even appear to be respected. This ticket should be reopened.


[Cache] Cache folders should only be created for valid libraries.

Why does the cache contains strange libraries like "j" and "[LibraryName]" ?
Cache folders should only be created for valid libraries.

Let's at least understand what's going on here.

I don't see this behavior, cache only contains resolved library names.


ng-messages broken

I copy pasted an example from the Angular API reference page
Using the latest version of angular and ngMessages the messages never disappear. Codepen demonstrating the issue:
http://codepen.io/anon/pen/zradKz

I foolishly forgot to include the dependency on ngMessages, don't mind me


Update README for how to deploy on local

Hi communities! :wave:
I'm very interested in this project, so I tried to deploy Blixt on my local Kind cluster today.
However, I got errors about pulling images from ghcr.io/kubernetes-sigs:
Warning  Failed     31s (x3 over 76s)  kubelet            Failed to pull image "ghcr.io/kubernetes-sigs/blixt-dataplane:latest": rpc error: code = Unknown desc = failed to pull and unpack image "ghcr.io/kubernetes-sigs/blixt-dataplane:latest": failed to resolve reference "ghcr.io/kubernetes-sigs/blixt-dataplane:latest": failed to authorize: failed to fetch anonymous token: unexpected status from GET request to https://ghcr.io/token?scope=repository%3Akubernetes-sigs%2Fblixt-dataplane%3Apull&service=ghcr.io: 401 Unauthorized

After several research, I found a way to solve the problem at https://github.com/kubernetes-sigs/blixt/issues/47.
Now I can deploy Blixt on my cluster by following the steps:

make build.all.images (as described in https://github.com/kubernetes-sigs/blixt/issues/47#issuecomment-1838654890)
make load.all.images
kubectl apply -k ./config/tests/integration (because those built images have a tag integration-tests)

I think we should add those steps to README.
I understand that the current situation (using ghcr.io) is temporary, but at the moment, writing the current deployment steps is very user-friendly, especially for newbies.
If those make sense for you, I will make a PR to modify README!

Thanks @Shunpoco,
Very glad to see your interest in the project, please do reach out to us if there's anything specific you're interested in, if you get stuck and need help, e.t.c.
Good call on the README, it's true that presently the ghcr.io images are not public due to policies about images in kubernetes-sigs, and we have an issue (#106) that tracks getting us moved over to an accepted registry. Please do feel free to update the README and add steps to the # Usage section, and thanks for taking the time to work through that and identify the problem!
Also note that the tag can be easily overridden, for instance:
$ make build.all.images TAG=latest
$ make load.all.images TAG=latest

And then the standard $ kubectl apply -f ./config/default should then work.

@shaneutt
Thanks!
I will make a PR soon.

Also note that the tag can be easily overridden, for instance:

I didn't know that. I will use it for my PR :smile:


feature: adds extra data on state message to brokers

What type of PR is this?

Uncomment only one  /kind <> line, hit enter to put that in a new line, and remove leading whitespace from that line:
/kind bug
/kind cleanup
/kind deprecation
/kind design
/kind documentation
/kind failing-test
/kind feature

What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

Additional documentation e.g., usage docs, etc.:

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Allow configuration of redis using a url property instead of host/port/etc

I added a commit that for an "allowOverwrite" config option. This is useful for now since we don't have an activate capability yet.

Thanks @lukemelia


Http Webhook_Http webhook option is not present as trigger and action.

Describe the Bug with repro steps
1.Create a LA in standard portal and add http webhook as a trigger and option.
Expected: Http webhook option should be present.
Actual: Http webhook option is not present.

What type of Logic App Is this happening in?
Standard (Portal)
Are you using Preview Designer or GA Designer
Preview
Workflow JSON
No response
Screenshots or Videos
No response
Browser
Edge
Additional context
Environment Details:
URL: https://aka.ms/emastaging-flowstip1
Version: 2.30508.1.2

@ccastrotrejo duplicate of @https://github.com/Azure/LogicAppsUX/issues/2230 i.e. Closed.

Talked with Prashant, and it seems to only happen with his Logic App

There was a timing issue here and it is taken care of now, should make it to prod by EOD next week

@Eric-B-Wu @preetriti1 Issue resolved. Version :  2.30529.1.1


Make “crunch bangs” use /usr/bin/env to support NixOS

Hey, this project is really cool!
I tried compiling it on NixOS, but due to the way NixOS works, the crunchbangs can't reference /bin/bash.
Doing it this way however, I was able to build the project without issues.
It would probably (but I haven't tested) be fine to change them to /bin/sh as well, but this pattern is maybe better?

Thanks! Happy to know that you enjoyed it. It's great to have support for more platforms, I appreciate your PR!
On make-latex.sh, I just confirmed that #!/bin/sh works as well.
For compile-prelude.sh, it seems that [[ ... ]] is incompatible with /bin/sh, so that needs to be changed if we're using #!/bin/sh.
The CI passed so using env is perfectly fine, so I'll be merging this PR!


is this bug?

here is a example:
<?xml version="1.0" encoding="utf-8" ?>
<webcast id="f35e1dc">
    <question id="715da0d" time="1400470679" uid="9934592202" uname="admin">qustion
        <answer id="0e9a009" time="1400470699" uid="1" uname="admin">answer</answer>
    </question>
</webcast>

use the function xml, then get the following result: [the 'question' is missing]
Array
(
    [@id] => f35e1dc
    [question] => Array
        (
            [@id] => 715da0d
            [@time] =><PHONE_NUMBER>
            [@uid] =><PHONE_NUMBER>
            [@uname] => admin
            [answer] => Array
                (
                    [#text] => answer
                    [@id] => 0e9a009
                    [@time] =><PHONE_NUMBER>
                    [@uid] => 1
                    [@uname] => admin
                )
        )
)

creator doesnt give a damn

@Tommixoft - That's quite an accusation. I can see that you're very upset about something, but all you're doing about it is complaining about the documentation (which, yes, could be improved) and accusing someone you've never met of apathy, as though they owe you or anyone else here their time. To my knowledge, this is an open source project created on the side, not a product anyone is paying to use or maintain. That means the project's creator has to have work elsewhere to pay bills and basically survive, which doesn't often leave much time to review side projects, especially older ones. You may well be justified in being upset. But don't expect anyone else to understand it, or to instantly jump to make you feel better.
That said.
@dyike - I'm not certain why the #text entry isn't being set, here. I'm not sure how many XML parsers allow mixing text and tag contents (SGML does, and both HTML and XML are based on it, but XML is more restrictive, so many parsers skip supporting mixed content). This might be a bug, yes. I'd have to look at the code to see what's going on there.
You'll have the most success with the most XML libraries if you avoid mixing text and tags. That's not an answer to your question, but it is a general guideline to follow if you want to interact with other projects.


Incorrect Asset folder resources path when deployed inside war

Versions.
@angular/cli: 1.0.0-rc.4
node: 7.2.0
os: win32 x64
@angular/common: 2.4.10
@angular/compiler: 2.4.10
@angular/core: 2.4.10
@angular/forms: 2.4.10
@angular/http: 2.4.10
@angular/platform-browser: 2.4.10
@angular/platform-browser-dynamic: 2.4.10
@angular/router: 3.4.10
@angular/cli: 1.0.0-rc.4
@angular/compiler-cli: 2.4.10
I have deployed Angular 2 inside War file in tomcat. I have changed base href to "/AngularSpring" in index.html.
using command : ng build --prod --aot=false -bh /AngularSpring  -d /AngularSpring
http://localhost:8080/AngularSpring/---- . Application URL.
The application is loading fine but resources which are inside asset folder gives 404.
http://localhost:8080/assets/env.json 404.
Following line in TS file  is giving issue at runtime
this.getConfigFile('./assets/env.json');
Is there any way which automatically appends ./AngularSpring before the './assets/env.json as inside war file asset folder in inside /AngularSpring.
please help I have N number of the solution but none of them worked. I don't want to change the path in the file manually.

getConfigFile is a method to dynamically the file at runtime, right? The CLI itself doesn't do anything about those, but there might be a way to figure out the base url on an app at runtime.

Yes, that way I am searching for but not able to find any.

Heya, there haven't been any other answers here so I'm closing this issue. Stack Overflow would be a good place to ask as well.


Designtime Exception when mixing .NET Standard project libraries with WPF .NET Framework application

I've discovered a potential bug when mixing .NET Standard library projects with a .NET Framework WPF project.
Scenario
Two projects:

.NET Standard class library project (targeting .Net Standard 2.0)

No other dependencies or implementations. Just an empty project.

WPF Front end project (targeting .NET 4.7)

References the above .NET standard project
Nuget package management format set to 'PackageReference'
References nuget package: MvvmLightLibs

Symptoms
The app runs as expected at runtime, but during design time a FileLoadException is thrown whenever ViewModelBase.IsInDesignModeStatic is called:

NOTE: this exception does not show up immediately on the first build, but usually kicks in once VS has been restarted - or 'Disable Project Code' is toggled in the XAML editor.
Source of the error
The exception is being thrown within the GetCurrentPlatform() of the Designer Library (Line 47)
Steps to reproduce
MvvmLightDesignModeBug.zip
This simple project implements the bare minimum to reproduce the error. Note that on first build the designtime view may appear to work. Try toggling the Disable Project Code button on and off:

Notes
This exception appears whether using the MvvmLightLibs or MvvmLightLibsStd10 packages.
Removing the WPF project's reference to the .NET standard class library will fix this error.
Potential Fix
Wrapping the calls to Type.GetType() in the DesignerLibrary with a try-catch so that failures here fall through.
UPDATE: Pull request #42 submitted.

Hello, thanks for your investigations. I just hit the same error and confirm this behaviour. That stole me two days. Would you be so kind and tell me, how I can modify the source of mvvmlight like you suggested? I haven't done this before. And, @lbugnion why isn't that pull request merged? I really appreciate your work, but this is a bug that should be fixed as soon as possible. Thanks to both of you for yours works and sharings.
btw: my setup is a solution with many projects. Most of the dependencies come from my own nuget-feed, but the Logic is only an assembly of that solution (it is a .netstandard2.0 assembly) and the UI-Project is .net 4.6.2, referencing the logic.dll. The case is, that I also have xamarin(forms) projects that have to reference the logic. So the logic has to be / should be .netstandard.

I was trying to make an issue and good thing I found this one. The issue still exists in <IP_ADDRESS>
I took the DesignerLibrary and added a try_catch block for Silverlight and that worked well. I actually made a git repo with this one that can be found here
https://github.com/Nullstr1ng/MVVMLightIssueInNETStandard
as well as the modification I made
https://github.com/Nullstr1ng/MVVMLightIssueInNETStandard/blob/251af789a8bc819ba1acd906dfd000cad22ecf90/BugInMvvmForWPF.Lib/Helpers/DesignerLibrary.cs#L46

Hello again. I know, that you are busy. But I'm begging you... please.. can you publish a nuget package with that current fix? Since the purpose is to have one codebase for all platforms, it is an usual scenario to mix .netstandard and wpf. You would make the crowd very happy, I think. And I'm also relying on the ability to use design time data. Compiling and executing for creating UI is a very slow process. I would be happy, when you give me/us a small feedback. Thanks in advance - many, many times.

I have a fix if you like
On Fri, Sep 6, 2019, 12:17 AM TheMiller2015<EMAIL_ADDRESS>wrote:

Hello again. I know, that you are busy. But I'm begging you... please..
can you publish a nuget package with that current fix? Since the purpose is
to have one codebase for all platforms, it is an usual scenario to mix
.netstandard and wpf. You would make the crowd very happy, I think. And I'm
also relying on the ability to use design time data. Compiling and
executing for creating UI is a very slow process. I would be happy, when
you give me/us a small feedback. Thanks in advance - many, many times.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/lbugnion/mvvmlight/issues/41?email_source=notifications&email_token=AAB7UGKS3YT2NBSMO4FKN3TQIEWKRA5CNFSM4FKKCTB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD57XAFQ#issuecomment-528445462,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAB7UGOCOU3SAERRT47GZKDQIEWKRANCNFSM4FKKCTBQ
.

In the meantime this is the way to go, I thank. I'm very thankful and just checked out your repo. It's just building and referencing it from logic and UI project, right?

Sorry, I don't get your solution to run, @Nullstr1ng . I checked out the branch "hacked_designerlibrary_class" and build your solution. But how to implement your fix into my solution? Can leave leave some explaining words here, please? ;) thanks.

If you'd prefer to stick with the published packages for now, and add in a workaround, I'm currently using this helper utility in my original app (the app I filed this issue from):
public static class DesignTime
    {
        private static bool? _isInDesignMode = null;
        public static bool IsInDesignMode => _isInDesignMode ?? (_isInDesignMode = GetIsInDesignMode()).Value;

        private static bool GetIsInDesignMode()
        {
            var isInDesignMode = (bool?)null;
            var prop = DesignerProperties.IsInDesignModeProperty;
            isInDesignMode
                = (bool)DependencyPropertyDescriptor
                    .FromProperty(prop, typeof(FrameworkElement))
                    .Metadata.DefaultValue;

            // Just to be sure
            if (!isInDesignMode.Value
                && Process.GetCurrentProcess().ProcessName.StartsWith("devenv", StringComparison.Ordinal))
            {
                isInDesignMode = true;
            }

            return isInDesignMode ?? false;
        }
    }

How you use it is up to you - but I've just created my own viewmodel baseclass that inherits from MVVMLight's ViewModelBase class, and then just overrides this logic. I'm happy with this workaround, as I often create my own viewmodel baseclasss in my projects anyway, so this feels fairly light in terms of a hack.
@lbugnion I'm sure is a busy man :)
Also, don't forget the fix in the MVVMLight source is very simple, and detailed in PR #42 in case you just want to pull the source, and fix it yourself.

Yes well done. I used the master branch of the mvvmlight sources, since your static class "DesignTime" won't compile in my .netstandard2.0 project (compiler can't find "DesignerProperties"). So I compiled the master branch and also added "System.Windows.Interactivity" and "...mvvmlight.Platform" as reference. I initially forgot these two extra references in the UI project and couldn't compile.  As a result, everthing is working fine and I want to say "thanks@all" for your quick help.


zpool status is not parsing log devices.

Parser fails to parse outputs like this:

  pool: tests-12420843063280352273
 state: ONLINE
  scan: none requested
config:

        NAME            STATE     READ WRITE CKSUM
        tests-12420843063280352273  ONLINE       0     0     0
          /vdevs/vdev1  ONLINE       0     0     0
        logs
          /vdevs/vdev2  ONLINE       0     0     0

errors: No known data errors

Probably can't parse cache devices too.

Full example:
  pool: test-123
 state: ONLINE
  scan: none requested
config:

        NAME              STATE     READ WRITE CKSUM
        test-123          ONLINE       0     0     0
          /vdevs/vdev0    ONLINE       0     0     0
        logs
          mirror-1        ONLINE       0     0     0
            /vdevs/vdev1  ONLINE       0     0     0
            /vdevs/vdev2  ONLINE       0     0     0
        cache
          md1             ONLINE       0     0     0

errors: No known data errors


[NumPy] Wrap unravel_index backend implementation instead of fallback

Description
Changes the unravel_index interface to wrap over C++ implementation instead of falling back to offcial NumPy.
Solve https://github.com/apache/incubator-mxnet/issues/20636#issuecomment-962128214
Checklist
Essentials

[x] PR's title starts with a category (e.g. [BUGFIX], [MODEL], [TUTORIAL], [FEATURE], [DOC], etc)
[x] Changes are complete (i.e. I finished coding on this PR)
[x] All changes have test coverage
[x] Code is well-documented

Changes

[ ] Feature1, tests, (and when applicable, API doc)
[ ] Feature2, tests, (and when applicable, API doc)

Comments

If this change is a backward incompatible change, why must this change be made.
Interesting edge cases to note here

@mxnet-bot run ci [centos-cpu, centos-gpu, clang, edge, miscellaneous, unix-cpu, unix-gpu, website]

@mxnet-bot run ci [centos-gpu, unix-cpu]

@mxnet-bot run ci [centos-gpu, unix-cpu]


Make run_in_transaction w/ timeout test deterministic.

Closes #3080.

I've gonna somewhat agree with @dhermes - the mock stuff is way more readable. I understand the DRY concerns, but you've also reinventing a very well-designed wheel by writing a custom class. I generally dislike running into these things in tests, as it requires me to break context to go and understand what the class is doing.
I also am nowhere near as opinionated on testing as you are, @tseaver. You might hate me if you saw the tests in google-auth.


PD: feedback

Very good and clear https://github.com/openclimatefix/pvsite-datamodel/blob/main/sdk/pvsite-python/write.py#L92

would be good to pass the forecast_version as an optional variable
should we add a row make sure there is only one target time per forecast, or at list a logger warning

Is it the case then that one forecast is for a single site at a single target time? If that is the case, surely better than passing a dataframe where two columns contain the same data in every row is just passing a list of forecast values, along with an individual target time and a pv_uuid?

So this
# Filter the forecasted values by target_time

needs to happen before I create the forecast?

nah could just happen just before 103. Just to make sure all target_times_utc are unique.

Sorry I'm not keeping up here:
Is what you're saying:

Split the table up by sites
Create a new forecast object for that site
(New) Check that all the forecast value entries the table for that site have the same target_time_utc
(Change) Make a datetime interval if not exists for this site (instead of one datetime interval per unique target time in this site's dataframe subset, as they should all have the same target time) OR print a log if there is more than one unique target_time
Create a forecast value for each entry in the subset

Does that seem right?

(New) Check that all the forecast value entries for that site have a unique target_time_utc

SOmehting like
assert len(df_site) == len(df_site["target_datetime_utc"].unique())

Or it could just be a warning, if this is not true

Ah so you're saying there shouldn't be any duplicate target times per forecast per site?

Like this https://github.com/openclimatefix/pvsite-datamodel/commit/224ce40fcffd1cfbbe40d0806a3933ff2e9c68d3

perfect

Like this 224ce40

perfect

Ah sorry, missed that - updated in https://github.com/openclimatefix/pvsite-datamodel/commit/85a9b3da9104fcf2085b07b709ea362274337079


[dx12] fix support for alpha-enabled BC1 compressed textures

Sibling of #3405 for master (part of this code has already been in master)

bors r+


Network policy docs clarifications

Add "Pod lifecycle" section to the network policy docs.
Clarify network policy behaviour for hostNetwork pods
Clarify network policy behaviour for L2/L3 protocols

New sections should clarify some confusing aspect for the users, and become the base to build better-defined API for AdminNetworkPolicy.
The current version is intended for content reviews, and may not completely follow style guidelines, which will be fixed once we agree on the content.

/cc @danwinship @astoycos

/retest

/recheck

@npinaeva This looks like it needs to build again.
git commit --allow-empty -m "empty commit to rerun tests"

I'll trigger a build in Netlify (we haven't got that hooked up to /retest in Prow - sorry about that)

@sftim thanks for your feedback! I made some changes and left some questions, ptal :)

/easycla

👋 @npinaeva .
Should I close this pull request or are you actively working on it?

hey @kbhawkey , thanks for asking! Yes I am still working on it, just waiting for some feedback :)

(left some other comments up above in earlier threads too)

so do you want me to add another commit to remove SCTP support section? This PR doesn't touch SCTP yet, so maybe it would be a better option to have it as another PR (knowing for how ling we've been discussing this one)?

You must fix the mandatory corrctive feedback about undefined behavior and get that update tech-reviewed. You can also address the optional feedback about SCTP if you'd like to.

@danwinship can you please tal at the hostNetwork section?
@sftim can you please check the sctp changes?

/lgtm

I'd like a technical review from @kubernetes/sig-network-misc

Sure, that's what I was doing all along. I declare this PR to be technically accurate!

This is good to publish.
/approve


Redundant error messages when running multiple editor panels

Description of your problem
What steps will reproduce the problem?

Open a file with code warnings in the editor with more than one panel
Hover over the code warning

What is the expected output? What do you see instead?
Instead of seeing one error message, I'm seeing multiple messages.

Please provide any additional information below
The number of error messages is related to the number of panels that are open plus the number of panels with the file being shown. In the example, the same file is shown on two panels at the time it was edited.
This is NOT new with 3.2.3
Versions and main components

Spyder Version: 3.2.3
Python Version: 3.6.2
Qt Version: 5.7.1
PyQt Version: 5.8.1
Operating system: Fedora 26

Dependencies
IPython >=4.0    :  6.1.0 (OK)
cython >=0.21    :  None (NOK)
jedi >=0.9.0     :  0.10.2 (OK)
nbconvert >=4.0  :  5.3.1 (OK)
numpy >=1.7      :  1.12.1 (OK)
pandas >=0.13.1  :  0.20.1 (OK)
psutil >=0.3     :  5.3.1 (OK)
pycodestyle >=2.3:  2.3.1 (OK)
pyflakes >=0.6.0 :  1.6.0 (OK)
pygments >=2.0   :  2.2.0 (OK)
pylint >=0.25    :  1.7.2 (OK)
qtconsole >=4.2.0:  4.3.1 (OK)
rope >=0.9.4     :  0.10.7 (OK)
sphinx >=0.6.6   :  1.6.3 (OK)
sympy >=0.7.3    :  None (NOK)

Thanks for reporting. It's very annoying indeed.
We'll take a look at it in a future release.

EditorStack.data has a FileInfo for each editor open, but different finfos with the same file open share the same editor(CodeEditor); then each finfo call the codeanalisis, and set the results to the editor, that results in many finfos assigning results to the same CodeEditor
I think the solution for this issue could be to move code_analisis calling and workers creation to CodeEditor

I cannot reproduce this issue. Closing.


Fix support for torch Module type hints in LightningCLI

What does this PR do?
Fixes a problem mentioned in https://github.com/PyTorchLightning/pytorch-lightning/issues/7774#issuecomment-851813825. It does not resolve the whole issue, only that single comment.
Before submitting

[X] Was this discussed/approved via a GitHub issue? (not for typos and docs)
[X] Did you read the contributor guideline, Pull Request section?
[X] Did you make sure your PR does only one thing, instead of bundling different changes together?
[X] Did you make sure to update the documentation with your changes? (if necessary)
[X] Did you write any new necessary tests? (not for typos and docs)
[ ] Did you verify new and existing tests pass locally with your changes?
[X] Did you update the CHANGELOG? (not for typos, docs, test updates, or internal minor changes/refactorings)

PR review
Anyone in the community is free to review the PR once the tests have passed.
Before you start reviewing make sure you have read Review guidelines. In short, see the following bullet-list:

[x] Is this pull request ready for review? (if not, please submit in draft mode)
[ ] Check that all items from Before submitting are resolved
[x] Make sure the title is self-explanatory and the description concisely explains the PR
[x] Add labels and milestones (and optionally projects) to the PR so it can be classified

Did you have fun?
Make sure you had fun coding 🙃

I did verify that the tests were successful locally. Not sure why it is failing.

I can reproduce the failure locally

I guess torchvision has changed a log between versions. In https://github.com/PyTorchLightning/pytorch-lightning/pull/7807/checks?check_run_id=2728907218 the error is "torchvision.transforms.Resize" is not a subclass of Module. I upgraded torchvision in my venv and now it does fail but the error is different ('cannot represent an object', <InterpolationMode.BILINEAR: 'bilinear'>). I don't know with which version it was successful for me.
I will look into this last error and probably also change the test to use something a bit more stable.


docs: add installation guide using rpm, deb, apk

Closes #202
📑 Description
Added installation guide using rpm, deb, apk in the README.md
A preview can be seen over here.
✅ Checks

[x] My pull request adheres to the code style of this project
[ ] My code requires changes to the documentation
[ ] I have updated the documentation as required
[ ] All the tests have passed

Looking at the preview, it's a bit excessive, can we have these things in a drop down or some other link to "additional installation options" in the docs?

Yes! We can make these changes to this file and then have something like Installation redirecting to this file. But if to move the installation guide to some other file then I think we should also consider moving the Quick start, Usage, and other stuff to the docs too.

You could hide this in details blocks for deb, apk and rpm, think the primary installation method should stay brew, therefore it’s ok to not have the others there prominently…

Please also add a curl/wget command to download the respective package. Furthermore, please add the release-please annotations to update the version in the scripts, e.g. automatically:
<!---x-release-please-start-version-->
  - Download package: [k8sgpt_amd64.rpm](https://github.com/k8sgpt-ai/k8sgpt/releases/download/v0.1.8/k8sgpt_amd64.rpm)
<!---x-release-please-end-->

Do you mean something like this?
<!---x-release-please-start-version-->

curl -LO https://github.com/k8sgpt-ai/k8sgpt/releases/download/v0.1.8/k8sgpt_amd64.rpm

<!---x-release-please-end-->

Thank you for the merge!


New-PnPSite command isn't setting the sensitivity label

I am challenged in creating SensitivityLabel for my new modern sites. I used New-PnPSite as below but it is not creating a sensitivity label for my site (where $sensLabel holds a GUID/ID of my sensitivity label):
New-PnPSite -Type CommunicationSite -Title $siteTitle -Url $siteURL -Owner $owner -SensitivityLabel $sensLabel
Besides I cannot use Set-PnPSite to set site's sensitivity label as it seems to be not taking sentivitylabel as an argument.
FYI, I am using PnP.PowerShell version 1.6.1 with my PnP PowerShell script connecting to SharePoint Online using App Permission as described here.
Below is how I connect to SharePoint online:
Connect-PnPOnline -Url $configSiteUrl -ClientId $clientID -Tenant $tenantName -Thumbprint $thumbPrint
Your help is appreciated.

We have observed that this only works if you connect using delegated permissions.
Can you try this approach and let us know ?

Thank you @gautamdsheth for responding to my issue.
Unless you mean something else, I thought Delegated Permissions were meant to serve a signed in user. In my case, I want the script to run via a scheduled task i.e. without a user signing into to the M365 tenant interactively.  If I misunderstood your response, please let me know.

It turns out there is a PnP cmdlet called Set-PnPTenantSite that I was able to use to set the Sensitivity label i.e. after creating the new site.
Set-PnPTenantSite -Identity $newSiteURL -SensitivityLabel $sensLabel -Connection $adminURLConnection
Not sure how it evaded me in the first place.

@astatke - Hi, I wanted to follow up on this issue, as we are facing the same challenge at the moment.
Can you share how your connection looks like, and which permissions you were using?
We are currently trying the same command as you provided above, but without success.
The command executes without error, but the sensitivity label is NOT set.
Thanks!