Deadlock in threaded dgemv

I've compiled OpenBLAS dfe1eef and I'm linking to it from a JNI interface and calling it from the JVM. It was compiled using USE_THREAD=1 and NO_AFFINITY=0 using gcc 4.4.7. After approximately 5 days of processing between 5 and 10 dgemv calls per second, I saw a deadlock occurring with a thread consuming 100% usage of a CPU core.
I grabbed this backtrace; this was the only thread with symbols in libblas.so:
Thread 1 (process 60961):
#0  0x00007fde1dce2287 in sched_yield () from /lib64/libc.so.6
#1  0x00007fdcca2f5ba5 in exec_blas_async_wait () from ./libblas.so.3
#2  0x00007fdcca2f6272 in exec_blas () from ./libblas.so.3
#3  0x00007fdcca132a74 in dgemv_thread_n () from ./libblas.so.3
#4  0x00007fdcca0f4934 in cblas_dgemv () from ./libblas.so.3
#5  0x00007fdccb31dafb in Java_com_github_fommil_netlib_NativeSystemBLAS_dgemv_1offsets () from /tmp/jniloader5273540829126619406netlib-native_system-linux-x86_64.so
#6  0x00007fde094c04a9 in ?? ()
#7  0x0000000000000000 in ?? ()
./libblas.so.3 is
lrwxrwxrwx 1 wgood users        35 Sep 23 15:16 libblas.so.3 -> libopenblas_sandybridgep-r0.2.14.so
make output looks like this:
OpenBLAS build complete. (BLAS CBLAS LAPACK LAPACKE)
OS               ... Linux
Architecture     ... x86_64
BINARY           ... 64bit
C compiler       ... GCC  (command line : gcc)
Fortran compiler ... GFORTRAN  (command line : gfortran)
Library Name     ... libopenblas_sandybridgep-r0.2.14.a (Multi threaded; Max num-threads is 24)
The JVM is only calling dgemv from a single thread at any given point in time.
I will continue to watch for this; I suspect it will happen again in the next day or so although not all JVM processes failed after 5 days. My long term plan was to migrate to a single-threaded BLAS and do my own threading and that will fix this issue as well, but I'll try to see if I can learn anything more about this issue in the meanwhile.

Do you know what is the input size for dgemv? On the machine, is there only one JVM process calling OpenBLAS?

The matrix is approx 50k rows x 10k cols (row count is ~49k and col count is precisely 10k) and there's a single thread in a single process calling OpenBLAS.

If sched_yield uses 100% of CPU something is badly broken with your system's process scheduler and timers
Can you post to gist
gdb> attach
gdb >thread apply all backtrace
gdb> detach
gdb> quit

I have the exact same problem with OpenBLAS called from numpy, same backtrace.
Here's the full backtrace as suggested by @brada4: https://gist.github.com/jbaiter/8dd11939bedfa9d9bf7e417c86f02bd9
The version is 0.2.18-1ubuntu1 running on Linux 4.4.0-38-generic.

Could be related to races like
==7085== Possible data race during write of size 8 at 0x641C00 by thread #2
==7085== Locks held: none
==7085==    at 0x432F91: blas_thread_server (blas_server.c:438)
==7085==    by 0x4C2F736: mythread_wrapper (hg_intercepts.c:234)
==7085==    by 0x54680A3: start_thread (pthread_create.c:309)
==7085==
==7085== This conflicts with a previous read of size 8 by thread #1
==7085== Locks held: none
==7085==    at 0x4333F2: exec_blas_async_wait (blas_server.c:726)
==7085==    by 0x4335A5: exec_blas (blas_server.c:795)
==7085==    by 0x42C3DE: sgbmv_thread_n (gbmv_thread.c:260)
==7085==    by 0x416480: sgbmv_ (gbmv.c:240)
==7085==    by 0x40D3A1: schk1_ (sblat2.f:592)
==7085==    by 0x413F6F: MAIN__ (sblat2.f:305)
==7085==    by 0x4148FE: main (sblat2.f:390)
==7085==  Address 0x641c00 is 0 bytes inside data symbol "thread_status"
seen in #995 - I am a bit unsure how to (sanely) put a lock around or into the "while" loop at 726

while(thread_status[queue -> assigned].queue) {
  YIELDING;
 };

at the moment (and it may all be a red herring)

Had the same problem, via Lapack, using libopenblas 0.2.19-1 on Debian, on Intel(R) Xeon(R) CPU E5-2687W v3 @ 3.10GHz with 20 cores.  The main thread got stuck after a few hours on exec_blas_async_wait called from dsytri from Lapack.  Kernel was 4.5.0-2-amd64 #1 SMP Debian 4.5.3-2 (2016-05-08) x86_64 GNU/Linux.  The other threads were all in pthread_cond_destroy.
(gdb) bt
#0  0x00007f2c9704b308 in exec_blas_async_wait () from /usr/lib/libopenblas.so.0
#1  0x00007f2c9704b3a7 in exec_blas () from /usr/lib/libopenblas.so.0
#2  0x00007f2c96e7a2ee in dsymv_thread_U () from /usr/lib/libopenblas.so.0
#3  0x00007f2c9a6cb043 in dsymv_ () from /usr/lib/libblas.so.3
#4  0x00007f2c9a12e3ff in dsytri_ () from /usr/lib/liblapack.so.3

I am making extremely slow progress, if any, as thread programming is not exactly my forte. Part of the problem now seems to be that blas_thread_server appears to be "thinking" in terms of cpus while exec_blas_async_wait is iterating over threads so I have a hard time putting mutex locks in the latter on the right item to achieve anything.

Would either of you be willing to retest with the changed blas_server.c and memory.c linked from #995 (or point me to some self-contained test to check this myself) please ?

I think I just ran into this problem too. I'd be very happy for a workaround ..
I have a very simple test case with numpy 1.12.0  in Python 3.6.
It hangs at the call to  dot.
from numpy import *
from numpy.random import normal,uniform

A = normal(size=(350,35))
b = uniform(size=350)

for i in range(1000000):
    for _ in range(1000):
        x = normal(size=35)
        y = dot(A,x) + b
    print(f"[{i:6d}] {y[0]:10.4f}")

Here's the backtrace:
GNU gdb (Ubuntu <IP_ADDRESS>61005-0ubuntu1) <IP_ADDRESS>61005-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from python...done.
(gdb) r testdot.py
Starting program: /home/peter/python36/bin/python testdot.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff3c17700 (LWP 16527)]
[New Thread 0x7ffff3416700 (LWP 16528)]
[New Thread 0x7fffeec15700 (LWP 16529)]
[New Thread 0x7fffee414700 (LWP 16530)]
[New Thread 0x7fffe9c13700 (LWP 16531)]
[New Thread 0x7fffe7412700 (LWP 16532)]
[New Thread 0x7fffe4c11700 (LWP 16533)]
[New Thread 0x7fffe2410700 (LWP 16534)]
[New Thread 0x7fffdfc0f700 (LWP 16535)]
[New Thread 0x7fffdd40e700 (LWP 16536)]
[New Thread 0x7fffdac0d700 (LWP 16537)]
[     0]     7.0992
[     1]    10.2106
[     2]   -14.5927
[     3]    10.9267
[     4]     0.8033
[     5]     8.1307
[     6]     9.4003
[     7]    -2.9214
[     8]     3.1963
[     9]    -4.4260
[    10]    -8.6859
[    11]    -1.5888
[    12]     2.4825
[    13]    -3.8991
[    14]     2.1277
[    15]   -14.3231
[    16]     6.9087
[    17]     2.6755
[    18]    -3.1991
[    19]     7.4059
^C
Thread 1 "python" received signal SIGINT, Interrupt.
0x00007ffff71ce4e7 in sched_yield () at ../sysdeps/unix/syscall-template.S:84
84      ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) bt
#0  0x00007ffff71ce4e7 in sched_yield () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007ffff4249e75 in exec_blas_async_wait ()
   from /home/peter/python36/lib/python3.6/site-packages/numpy/core/../.libs/libopenblasp-r0-39a31c03.2.18.so
#2  0x00007ffff4249f66 in exec_blas () from /home/peter/python36/lib/python3.6/site-packages/numpy/core/../.libs/libopenblasp-r0-39a31c03.2.18.so
#3  0x00007ffff40789f5 in dgemv_thread_t () from /home/peter/python36/lib/python3.6/site-packages/numpy/core/../.libs/libopenblasp-r0-39a31c03.2.18.so
#4  0x00007ffff4038d97 in cblas_dgemv () from /home/peter/python36/lib/python3.6/site-packages/numpy/core/../.libs/libopenblasp-r0-39a31c03.2.18.so
#5  0x00007ffff66700a3 in gemv (typenum=typenum@entry=12, order=<optimized out>, trans=trans@entry=CblasNoTrans, A=A@entry=0x7ffff6df3350,
    lda=<optimized out>, X=X@entry=0x7ffff7ed5bc0, incX=1, R=R@entry=0x7fffd5207c60) at numpy/core/src/multiarray/cblasfuncs.c:95
#6  0x00007ffff6670e9c in cblas_matrixproduct (typenum=typenum@entry=12, ap1=ap1@entry=0x7ffff6df3350, ap2=ap2@entry=0x7ffff7ed5bc0, out=out@entry=0x0)
    at numpy/core/src/multiarray/cblasfuncs.c:623
#7  0x00007ffff663ac5c in PyArray_MatrixProduct2 (op1=<optimized out>, op2=0x7ffff7ed5bc0, out=0x0) at numpy/core/src/multiarray/multiarraymodule.c:938
#8  0x00007ffff663c08a in array_matrixproduct (__NPY_UNUSED_TAGGEDdummy=<optimized out>, args=0x7ffff7e0bec8, kwds=0x0)
    at numpy/core/src/multiarray/multiarraymodule.c:2180
#9  0x0000555555685363 in _PyCFunction_FastCallDict (kwargs=<optimized out>, nargs=<optimized out>, args=<optimized out>, func_obj=0x7ffff6b30f78)
    at Objects/methodobject.c:231
#10 _PyCFunction_FastCallKeywords () at Objects/methodobject.c:295
#11 0x00005555556dea1d in call_function () at Python/ceval.c:4788
#12 0x00005555556d702f in _PyEval_EvalFrameDefault () at Python/ceval.c:3275
#13 0x00005555556d6187 in PyEval_EvalFrameEx (throwflag=0, f=0x7ffff7f6ba20) at Python/ceval.c:718
#14 _PyEval_EvalCodeWithName () at Python/ceval.c:4119
#15 0x00005555556d5f03 in PyEval_EvalCodeEx (closure=0x0, kwdefs=0x0, defcount=0, defs=0x0, kwcount=0, kws=0x0, argcount=0, args=0x0,
    locals=locals@entry=0x7ffff7f3d288, globals=globals@entry=0x7ffff7f3d288, _co=_co@entry=0x7ffff7ef7930) at Python/ceval.c:4140
#16 PyEval_EvalCode (co=co@entry=0x7ffff7ef7930, globals=globals@entry=0x7ffff7f3d288, locals=locals@entry=0x7ffff7f3d288) at Python/ceval.c:695
#17 0x0000555555727712 in run_mod () at Python/pythonrun.c:980
#18 0x0000555555727b6d in PyRun_FileExFlags () at Python/pythonrun.c:933
#19 0x000055555572794e in PyRun_SimpleFileExFlags () at Python/pythonrun.c:396
#20 0x000055555572d631 in run_file (p_cf=0x7fffffffda30, filename=0x555555ab72c0 L"testdot.py", fp=0x555555b41f00) at Modules/main.c:320
#21 Py_Main () at Modules/main.c:780
#22 0x00005555556395ad in main () at ./Programs/python.c:69
#23 0x00007ffff71033f1 in __libc_start_main (main=0x5555556394c0 <main>, argc=2, argv=0x7fffffffdc48, init=<optimized out>, fini=<optimized out>,
    rtld_fini=<optimized out>, stack_end=0x7fffffffdc38) at ../csu/libc-start.c:291
#24 0x0000555555724c8a in _start ()
(gdb)

@martin-frbg I don't have an easy-to-reproduce case as it happened after a very long computation launched by someone else, and the code has evolved since so that it make that many calls.  If the fix works on @sparseinference's case I would like to start using it on a development machine to catch some regressions but there are no guarantees that I would have run into the bug.

I can sacrifice some performance but still make stuff work with:
export OPENBLAS_NUM_THREADS=1

Same here, we've been running with OPENBLAS_NUM_THREADS=1 since November and had no issues.  I parallelize at the process level.

@sparceinference which version of OpenBLAS do you see this with - one of the releases (including latest 0.2.19) or with current git develop tree ? The fix (if it is one) is only in the latter so far.

@martin-frbg - I think it's 2.18 . The library loaded is libopenblasp-r0.2.18.so .

I had the same problem with version 0.2.18. That is, my process was deadlocked at 100% use of one core. In addition,  #0 through #3 of the backtrace are identical to that reported by @bkgood . The long and repetitive calculation I was running was getting deadlocked in a small fraction of calls, but in effect multiple times a day. Based on the information on this Issues thread, I have then compiled OpenBLAS from the develop branch on github (commit 1acfc78c8f8c19dc876e8c859bd1c55619b64205, 4/3/2017). Then compiled the latest numpy (1.12.1) and scipy using this version of OpenBLAS. The calculation has since be running uninterrupted for more than a day. Thus, for me, the newest github revision most likely fixes this deadlock. I will report should the problem reappear, or appear with much lower likelyhood.

We seem to be running into a similar deadlock, but interestingly it is hit when we have multiple processes on the same machine both using BLAS at the same time. Setting OPENBLAS_NUM_THREADS=1 for both processes seems to fix the issue, but I'm still left with a couple questions.

How is it that we hit the deadlock only when we run two independent processes using BLAS? Is BLAS sharing resources between these two processes, and if so, what resources?
If BLAS is sharing resources between the two processes somehow, then how does setting OPENBLAS_NUM_THREADS=1 on each of the processes change this relationship?
Based on experimentation, it appears that the BLAS computations from the two processes are happening in parallel, when each one is set with OPENBLAS_NUM_THREADS=1. Can you confirm that this is actually the case?
What are the implications of setting OPENBLAS_NUM_THREADS=1? Obviously it changes how many threads OpenBLAS uses :-) . But threads for what? Is BLAS using multiple threads for say, a single matrix multiplication, or is the parallelism at the job level (ex: I can ask BLAS to do 2 matrix multiplications at once and it will do each one on a separate thread). How does this relate to whatever cross-process interaction is going on? Is there anything else I should be aware of?

Sorry for the long text, just trying to dig in deep. Perhaps this is actually a separate issue- if so, I'd be happy to open another ticket.

What makes you think the situation is similar, and what hardware are you seeing this on ? (From your comment, the OpenBLAS version you use is probably something like 0.2.20, but it might help to know that as well).  Sharing resources between two independent processes would I believe be entirely unexpected and unwanted. While both may use the same in-memory copy of the library, the operating system should clone any memory pages that receive process-specific writes to some flag value.

The thing that makes me think it's similar is that we're showing multiple threads stuck at #0  0x00007fa1aeb3ae47 in sched_yield () from /lib64/libc.so.6 #1 0x00007fa1a19d47c5 in exec_blas_async (), which is similar to what @sparseinference posted, and also setting OPENBLAS_NUM_THREADS=1 resolves it, as suggested by him. Here's a full backtrace of the hung process in a gist.
As for hardware, it's an Amazon EC2 instance. We've got 2 cores, x86 64 bit. The os is RHEL 7, using the kernel 3.10.0-693.17.1.el7.x86_64. We're using OpenBLAS 0.2.20 .
I share your confusion about any sharing between processes, yet the fact remains we can reproduce the deadlock when running two processes, but not with one. It's possible it's some indirect interaction is going on (ex, having the CPUs tied up with one process changes the way the threads interleave for the other process in such a way that causes conditions to be just right for the deadlock)... but I hope for our sake and for the maintainer's that the answer is more straightforward than that!

Two cores only does not sound quite right ? How many threads are you trying to run on this ? Any chance to reproduce this on non-virtual hardware ?

Yes, it's only 2 cores. So far we've only seen this on a somewhat dinky machine we use for building and testing. Reproducing it on non-virtual hardware will be difficult because our build at present only supports RHEL 7, and we don't have any physical hardware running that.

How many threads are you expecting to run on that poor thing - I see nine in that snippet of the backtrace from just one your concurrent processes alone ? Maybe you just see threads fighting for a bit of cpu time. I take it your code is proprietary and/or hard to port to different environments, or is this just some scipy ?

We aren't directly controlling the number of threads in the python application. Our stack is a flask app which accesses BLAS through numpy/scipy. So basically, the server spawns off threads when requests come in.
I don't think it's just fighting for CPU time. When run in series, the workload we're hitting it with takes less than a minute. When it hangs, we've left it for probably close to half an hour without any progress.
The code is unfortunately proprietary. We only use OpenBLAS on RHEL (that's a whole other story), and so we can't easily compare on other environments.
I should say that at this point we may be fine just using a workaround of OPENBLAS_NUM_THREADS=1, provided we feel comfortable that we understand how exactly that changes OpenBLAS's behavior. In other words, if you can confirm that there's no direct resource sharing going on, just answering 3 & 4 from my earlier post would go a long way for us. Btw, Thanks for the time you've already spent looking at this!

I just rechecked this situation using the same python example that I posted above.
I have removed the restriction on OpenBlas threads and I ran the test in two terminal sessions concurrently.
The CPU has 6 hyper-threading cores.
Kernel: 4.13.0-19
numpy: 1.14.1
openblas: 0.2.20
As expected, 24 threads were created and all cores were running at 100%.
I let the test run for about 5 minutes with no problems.
@augray, perhaps a test using Flask would reproduce your problem?

I've been trying to reproduce using a sharable example, but no luck so far :-( . Perhaps I would be better served to just ask for a detailed explanation of how behavior changes when OPENBLAS_NUM_THREADS=1 is set. I can open this as a docs ticket if that would be preferable?

With OPENBLAS_NUM_THREADS=1 the code should behave the same as if it was built without multithreading. Any crosstalk or synchronization between separate programs using OpenBLAS at the same time is unexpected to say the least. (Though perhaps some kind of resource contention (cpu or cach) may slow down both programs at the same expensive task in your "hopelessly overcommitted" case. BTW do things improve a little when you run with only 2 threads each ?)

Thanks, that's helpful confirmation! We don't directly control the number of threads (that's determined by the server our app is running in). However, we haven't noticed any performance degradation except when there's a complete deadlock. For instance, submitting 6 jobs at once to two separate processes doesn't take much longer than submitting a job to a single process 3 times in serial. For the other, non-blas threads in our app, they're not CPU bound, so I don't think they should affect CPU contention too much. I'm thinking we'll probably go with OPENBLAS_NUM_THREADS=1 for each process. Since there's no sharing going on between the two processes, there's definitely no chance for any kind of deadlock in single-threaded processes, and the performance as we've tested it so far using this setting is sufficient. I guess we'll just have to assume the explanation for the reproducibility being restricted to the case of two processes must be something nebulous like "non-deterministic thread ordering behavior that's influenced by increased cpu contention happens to make conditions amenable for deadlock on our os and hardware with our particular workload". I appreciate the info!

I am encountering the same kind of bug. I tried to compile OpenBLAS with thread sanitizer enabled to see what happens with the test. Actually, something has been found:
==================
WARNING: ThreadSanitizer: data race (pid=13862)
  Read of size 8 at 0x000000650200 by thread T1 (mutexes: write M12):
    #0 blas_thread_server ~/src/OpenBLAS/driver/others/blas_server.c:343 (sblat2+0x00000042e737)

  Previous write of size 8 at 0x000000650200 by main thread (mutexes: write M11):
    #0 blas_thread_shutdown_ ~/src/OpenBLAS/driver/others/blas_server.c:965 (sblat2+0x000000430e17)
    #1 blas_shutdown ~/src/OpenBLAS/driver/others/memory.c:1252 (sblat2+0x00000042d675)
    #2 gotoblas_quit ~/src/OpenBLAS/driver/others/memory.c:1455 (sblat2+0x00000042d8df)
    #3 _dl_fini <null> (ld-linux-x86-64.so.2+0x0000000104e6)

  Location is global 'thread_status' of size 8192 at 0x000000650200 (sblat2+0x000000650200)

  Mutex M12 (0x000000650218) created at:
    #0 pthread_mutex_init ../../../../gcc-7.3.0/libsanitizer/tsan/tsan_interceptors.cc:1117 (libtsan.so.0+0x000000028a6e)
    #1 blas_thread_init ~/src/OpenBLAS/driver/others/blas_server.c:572 (sblat2+0x00000042e1a0)
    #2 gotoblas_init ~/src/OpenBLAS/driver/others/memory.c:1435 (sblat2+0x00000042d87a)
    #3 __libc_csu_init <null> (sblat2+0x000000444b6c)

  Mutex M11 (0x000000650188) created at:
    #0 pthread_mutex_lock ../../../../gcc-7.3.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:3608 (libtsan.so.0+0x00000003872f)
    #1 blas_thread_init ~/src/OpenBLAS/driver/others/blas_server.c:556 (sblat2+0x00000042e067)
    #2 gotoblas_init ~/src/OpenBLAS/driver/others/memory.c:1435 (sblat2+0x00000042d87a)
    #3 __libc_csu_init <null> (sblat2+0x000000444b6c)

  Thread T1 (tid=13864, running) created by main thread at:
    #0 pthread_create ../../../../gcc-7.3.0/libsanitizer/tsan/tsan_interceptors.cc:900 (libtsan.so.0+0x000000028260)
    #1 blas_thread_init ~/src/OpenBLAS/driver/others/blas_server.c:579 (sblat2+0x00000042e1f9)
    #2 gotoblas_init ~/src/OpenBLAS/driver/others/memory.c:1435 (sblat2+0x00000042d87a)
    #3 __libc_csu_init <null> (sblat2+0x000000444b6c)

SUMMARY: ThreadSanitizer: data race ~/src/OpenBLAS/driver/others/blas_server.c:343 in blas_thread_server
==================
==================
WARNING: ThreadSanitizer: data race (pid=13862)
  Read of size 8 at 0x000000650200 by thread T1 (mutexes: write M12):
    #0 blas_thread_server ~/src/OpenBLAS/driver/others/blas_server.c:343 (sblat2+0x00000042e737)

  Previous write of size 8 at 0x000000650200 by main thread (mutexes: write M11):
    #0 blas_thread_shutdown_ ~/src/OpenBLAS/driver/others/blas_server.c:965 (sblat2+0x000000430e17)
    #1 blas_shutdown ~/src/OpenBLAS/driver/others/memory.c:1252 (sblat2+0x00000042d675)
    #2 gotoblas_quit ~/src/OpenBLAS/driver/others/memory.c:1455 (sblat2+0x00000042d8df)
    #3 _dl_fini <null> (ld-linux-x86-64.so.2+0x0000000104e6)

  Location is global 'thread_status' of size 8192 at 0x000000650200 (sblat2+0x000000650200)

  Mutex M12 (0x000000650218) created at:
    #0 pthread_mutex_init ../../../../gcc-7.3.0/libsanitizer/tsan/tsan_interceptors.cc:1117 (libtsan.so.0+0x000000028a6e)
    #1 blas_thread_init ~/src/OpenBLAS/driver/others/blas_server.c:572 (sblat2+0x00000042e1a0)
    #2 gotoblas_init ~/src/OpenBLAS/driver/others/memory.c:1435 (sblat2+0x00000042d87a)
    #3 __libc_csu_init <null> (sblat2+0x000000444b6c)

  Mutex M11 (0x000000650188) created at:
    #0 pthread_mutex_lock ../../../../gcc-7.3.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:3608 (libtsan.so.0+0x00000003872f)
    #1 blas_thread_init ~/src/OpenBLAS/driver/others/blas_server.c:556 (sblat2+0x00000042e067)
    #2 gotoblas_init ~/src/OpenBLAS/driver/others/memory.c:1435 (sblat2+0x00000042d87a)
    #3 __libc_csu_init <null> (sblat2+0x000000444b6c)

  Thread T1 (tid=13864, running) created by main thread at:
    #0 pthread_create ../../../../gcc-7.3.0/libsanitizer/tsan/tsan_interceptors.cc:900 (libtsan.so.0+0x000000028260)
    #1 blas_thread_init ~/src/OpenBLAS/driver/others/blas_server.c:579 (sblat2+0x00000042e1f9)
    #2 gotoblas_init ~/src/OpenBLAS/driver/others/memory.c:1435 (sblat2+0x00000042d87a)
    #3 __libc_csu_init <null> (sblat2+0x000000444b6c)

SUMMARY: ThreadSanitizer: data race ~/src/OpenBLAS/driver/others/blas_server.c:343 in blas_thread_server
==================

I am not sure that these two data races are directly related to this issue, but it looks like that compiling with sanitizers is very helpful for testing, and maybe the same approach could be used to track down the problem.

I just wanted to track down at least these two.
The first one is related to the misuse of volatile. Please, use _Atomic keyword or any related atomic type, volatile is not meant to avoid data races.
A possible patch is the following:
diff --git a/driver/level3/level3_thread.c b/driver/level3/level3_thread.c
index fec873e..da87a98 100644
--- a/driver/level3/level3_thread.c
+++ b/driver/level3/level3_thread.c
@@ -91,7 +91,7 @@
 #endif

 typedef struct {
-  volatile BLASLONG working[MAX_CPU_NUMBER][CACHE_LINE_SIZE * DIVIDE_RATE];
+  _Atomic BLASLONG working[MAX_CPU_NUMBER][CACHE_LINE_SIZE * DIVIDE_RATE];
 } job_t;

The other seems to be related to a wrong mutex. Unfortunately, it is the first time I looked at OpenBLAS code, and I can really hypothesize how things should work. Nevertheless, at line 965 of blas_server.c, thread_status[i].queue is locked through blas_lock(&exec_queue_lock), but in many other cases, the lock is performed through pthread_mutex_lock(&thread_status[i].lock). Actually, this is exactly the lock performed in the following lines. I cannot be sure, but a possible fix that seems to work is the following:
diff --git a/driver/others/blas_server.c b/driver/others/blas_server.c
index 9debe17..5abb362 100644
--- a/driver/others/blas_server.c
+++ b/driver/others/blas_server.c
@@ -960,14 +960,9 @@ int BLASFUNC(blas_thread_shutdown)(void){

   for (i = 0; i < blas_num_threads - 1; i++) {

-    blas_lock(&exec_queue_lock);
-
-    thread_status[i].queue = (blas_queue_t *)-1;
-
-    blas_unlock(&exec_queue_lock);
-
     pthread_mutex_lock  (&thread_status[i].lock);

+    thread_status[i].queue = (blas_queue_t *)-1;
     thread_status[i].status = THREAD_STATUS_WAKEUP;

     pthread_cond_signal (&thread_status[i].wakeup);

As I said, I never hacked OpenBLAS, so I could be completely wrong about the patches. I just hope that this could help somehow.

Second one should actually be fixed by #1299 since september, unfortunately this is only in the develop branch as there has not been a release in the meantime. First one I would never have been able to find, with some luck this will finally fix the long-standing thread safety issues in the multithreaded level3 BLAS.

I created this fork to track down the issues I am finding. I will need to write code to conditionally use _Atomic in case of C11 support, but this is a minor issue for now.
The big problem I am encountering is related to node mapping, in particular I have two different issues, and I am not sure they could be related or not. The problem is triggered by the safety utest; sometimes I get a deadlock, sometimes the node_mapping is written more than one time at the same index. I created (this commit)[https://github.com/dodomorandi/OpenBLAS/commit/3e713b040e92174220fc4ed2a7d32aa492c2b3ef] to help me (or anyone else, obviously) to track down the issue, but for now I am quite stuck.

Thanks, I will hold off on my partial PR then.
Do you see the duplicate mapping also without thread sanitizer ? (Though it would not surprise me if that phtread_atfork hack of stopping and re-initializing threads around a fork were a bit fragile)

Possibly the cpuid instruction used in the x86_64 "WhereAmI()" is unsuitable for "modern" big Intel systems. https://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration
discusses means to enumerate processor topology but I do not have time to look into this right now.

Can you provide more details about the platform you are using, and can you exclude any hardware/firmware/OS issues with that particular system ?

I can show you as much information as possible, but I don't any idea of how I could find possible issue with OS (nevertheless, the machine works flawlessly, I just do not know what to search for to discover anomalous behaviours).
This is from lscpu:
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                64
On-line CPU(s) list:   0-63
Thread(s) per core:    2
Core(s) per socket:    8
Socket(s):             4
NUMA node(s):          8
Vendor ID:             AuthenticAMD
CPU family:            21
Model:                 1
Model name:            AMD Opteron(TM) Processor 6274
Stepping:              2
CPU MHz:               2200.052
BogoMIPS:              4399.74
Virtualization:        AMD-V
L1d cache:             16K
L1i cache:             64K
L2 cache:              2048K
L3 cache:              6144K
NUMA node0 CPU(s):     0,4,8,12,16,20,24,28
NUMA node1 CPU(s):     32,36,40,44,48,52,56,60
NUMA node2 CPU(s):     2,6,10,14,18,22,26,30
NUMA node3 CPU(s):     34,38,42,46,50,54,58,62
NUMA node4 CPU(s):     3,7,11,15,19,23,27,31
NUMA node5 CPU(s):     35,39,43,47,51,55,59,63
NUMA node6 CPU(s):     1,5,9,13,17,21,25,29
NUMA node7 CPU(s):     33,37,41,45,49,53,57,61

Feel free to ask me any specific information.
However, to discover a bit the behaviour of my machine, I wrote a simple program in C++. It creates a pool of threads and every thread get the cpu index and the acpi id from sched_getcpu and the cpuid instruction and stores them. As soon I spawned the thread, I use the pthread_setaffinity_np to set the thread affinity. Then I join the threads and I check if the ids (both CPU and ACPI) are unique or not.
What I found is that this was leading to spurious id collisions, for both types of ids. After a bit I understood the problem: the main thread was not set as affine. As soon as I set the main thread affine using the same procedure, I stopped having id collisions.
The question is: could be exactly this the problem we are encountering?

Possibly the cpuid instruction used in the x86_64 "WhereAmI()" is unsuitable for "modern" big Intel systems. https://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration
discusses means to enumerate processor topology but I do not have time to look into this right now.

Sorry, it took me some time to write down the previous reply. Maybe we don't need to touch the WhereAmI function, for now. But I will wait for your opinion to have a better idea.

(Un?)fortunately it seems to me that you may well be more experienced with multithreading in general and NUMA architectures in particular than me. As far as I can tell, gotoblas_affinity_init() in init.c does a sched_setaffinity() for itself before enumerating the cores with whereAmI(), and I assume this should be equivalent to what your test code is doing with the non- (or less-)portable pthread_setaffinity_np() function that appears to be a GNU extension

can you add "numactl -H" output? I have not seen out of order core numbering recently.
Initial report is on small systems, nothing to do with NUMA.
IMO trying to override OpenMP thread placement is wrong.

can you add "numactl -H" output?

Sure!
available: 8 nodes (0-7)
node 0 cpus: 0 4 8 12 16 20 24 28
node 0 size: 32166 MB
node 0 free: 29854 MB
node 1 cpus: 32 36 40 44 48 52 56 60
node 1 size: 32254 MB
node 1 free: 31911 MB
node 2 cpus: 2 6 10 14 18 22 26 30
node 2 size: 32254 MB
node 2 free: 31786 MB
node 3 cpus: 34 38 42 46 50 54 58 62
node 3 size: 32254 MB
node 3 free: 31936 MB
node 4 cpus: 3 7 11 15 19 23 27 31
node 4 size: 32254 MB
node 4 free: 30836 MB
node 5 cpus: 35 39 43 47 51 55 59 63
node 5 size: 32254 MB
node 5 free: 31727 MB
node 6 cpus: 1 5 9 13 17 21 25 29
node 6 size: 32254 MB
node 6 free: 32004 MB
node 7 cpus: 33 37 41 45 49 53 57 61
node 7 size: 32237 MB
node 7 free: 31628 MB
node distances:
node   0   1   2   3   4   5   6   7
  0:  10  16  16  22  16  22  16  22
  1:  16  10  22  16  16  22  22  16
  2:  16  22  10  16  16  16  16  16
  3:  22  16  16  10  16  16  22  22
  4:  16  16  16  16  10  16  16  22
  5:  22  22  16  16  16  10  22  16
  6:  16  22  16  22  16  22  10  16
  7:  22  16  16  22  22  16  16  10

I assume this should be equivalent to what your test code is doing with the non- (or less-)portable pthread_setaffinity_np() function that appears to be a GNU extension

You are absolutely right, i just took the first one in my test... just because ;) I replaced it with the sched_setaffinity for coherence.
Nevertheless, I want to update you on my tests: I started thinking that the problem was about thread switching in critical sections (not the one the could create a data race, but something like a couple of instruction one expects to be executed without an interruption), but now I am not sure. The test I have got now is much more similar to what is going on inside OpenBLAS -- a sched_setaffinity is called inside the thread. I tried to perform the following things inside the spawned thread, in order:

The ACPI ID is colllected
sched_setaffinity is called to make the thread affine to the CPU equal to the thread index
ACPI ID is collected again
The thread is explicitly yielded
Again, the ACPI ID is collected

I see that it is always true that the first ID is (generally) different from the second, which in turn is always equal to the third. This means that, at least in this machine with this OS, the rescheduling happens as soon as the sched_setaffinity is called. I just wanted to be sure that something unexpected could happen in this context.
Oh, the test written in this way never leads to ACPI ID collisions. Probably I am going toward the wrong direction :disappointed:

Thanks for the detailed explanation - in retrospect it makes sense that a misbehaviour in the mapping would be related to the dubious nature of the hyperthreading semi-cores. (Which would also prevent
its showing up on other big systems that use a different architecture)
In my defense, I had looked at your fork but did not see a commit that contained the initializing of common->cpu_info that you had mentioned, then I had a look at the code paths that read or write this variable and became confused rather quickly... still after reading your patch I am unsure of dropping the cpu_sub_mapping would let the code still work as intended when hyperthreading is enabled (but I would take your word for it). Maybe I should just read what you wrote aloud three more times to get it.
As an alternative to thread sanitizer, perhaps helgrind from the valgrind package can provide additional insight (but there too, the environmental changes necessary for observing may change the system under observation)

In my defense, I had looked at your fork but did not see a commit that contained the initializing of common->cpu_info that you had mentioned

Actually, this is my fault: I did not include the initialization and the assertions in the commit of the patch, just to focus on the fix. But you are right, it is useful to have a commit with these, I will make one.

As an alternative to thread sanitizer, perhaps helgrind from the valgrind package can provide additional insight (but there too, the environmental changes necessary for observing may change the system under observation)

After I wrote the previous comment, I remembered I can use valgrind with helgrind. And the result is different from the thread sanitizer (which lead to a strange deadlock during the destruction phase), but it still involves issues. In details, the openblas_utest aborts on the check I put inside gotoblas_set_affinity to avoid node remapping. But I am not able to reproduce this situation without valgrind (until now).
Even if changing the mapping behaviour seems to solve the deadlock problem, I want to be sure I did not introduce other issues, or, if there are other related bugs left, I would like to fix them. The problems with the thread sanitizer and valgrind leave me very suspicious.

I made some real case tests, and I find that the issues are still there :cry:. I am going to continue searching for bugs.

Ouch, too bad. Still the same symptoms though, and are you testing with dgemv (as was the original issue here) ? It is possible that the bug I tracked down in #1497 (using the return value from blas_quickdivide to calculate blocksizes without checking that it is non-zero ) may be present in some of the level3 BLAS files as well.

Hopefilly this is now resolved with PR #1865, the fix for #1844 (where it was found that an old optimization for inputs with small M and large N had introduced local static storage that broke reentrancy)


Language specific unit tests

Allow to run language specific unit test with jest.
Adds debugging support to jest test in VSCode.
Builds upon langium-config support.

FYI I took over this PR, due to vacation.

Instead of createTestEnvironment we could have three functions that return functions for expectSymbols, expectCompletion and expectGoToDefinition.

This would require us to always pass our LangiumServices as well as our assertion function into each call. That would make these functions quite unwieldy. Or how would you expect to call them?

@spoenemann In addition to index markers <|>, I added range markers starting with <| and ending with |>.


[BUG] player not visible in AR page

[ ] The player should be visible

[ ] Only one song should be played at a time.

Can I work on this issue as part of GSSOC?

assigning u

Seems like the bug is already fixed with the new changes. Maybe we close the issue.

Yes you can close it.


Add description_file param

Adding description_file param to put step, and updating the documentation accordingly.

for some reason the tests are failing even though I have not change them.. any help with this? 🤔
task: Failed to run task "ci": exit status 1
The command "go get -u -v github.com/go-task/task/cmd/task && task ci" exited with 1.

oh.. that's strange. I think the CI build failures were related the fact that i indented with spaces instead of  tabs. Just glad it's working now 😁

Thanks so much!!


Add a Gitter chat badge to README.md

mgramin/sql-boot now has a Chat Room on Gitter
@mgramin has just created a chat room. You can visit it here: https://gitter.im/sqlboot/Lobby.
This pull-request adds this badge to your README.md:

If my aim is a little off, please let me know.
Happy chatting.
PS: Click here if you would prefer not to receive automatic pull-requests from Gitter in future.

Coverage remained the same at 73.913% when pulling bf49ad15efbcaab831beeb97a4ed175a99d80cfc on gitter-badger:gitter-badge into 90a66c54d632ddc472285dfebd64472cff311015 on mgramin:master.


webRequest.filterResponseData instead of monkey patching

Thanks for your work on THA!
I was wondering, would it maybe be possible to use webRequest.filterResponseData on the m3u8 playlist urls and filter out the SCTE-35 flags from the response that way, instead of monkey patching?

FWIW, I've tried the following, but what happens is that the Ad starts playing and after 1-2 seconds it stops and only shows the buffering circle.
browser.webRequest.onBeforeRequest.addListener(details => {
  const filter = browser.webRequest.filterResponseData(details.requestId);
  const decoder = new TextDecoder('utf-8');
  const encoder = new TextEncoder();

  filter.ondata = event => {
    let str = decoder.decode(event.data, {stream: true});
    if (str.includes('#EXT-X-SCTE35-OUT')) {
      str = str.replace(/#EXT-X-SCTE35-OUT(.|\s)*#EXT-X-SCTE35-IN/gmi, '');
      str = str.replace(/#EXT-X-SCTE35-OUT(.|\s)*/gmi, '');
      str = str.replace(/#EXT-X-DISCONTINUITY/gi, '');
      str = str.replace(/#EXT-X-DATERANGE:ID="stitched-ad.*/gi, '');
    }
    filter.write(encoder.encode(str));
    filter.disconnect();
  };
}, {urls: ['https://*.hls.ttvnw.net/*.m3u8'], types: ['xmlhttprequest']}, ['blocking']);

Very exciting stuff, I like this idea a lot. At least for Firefox it would make the code much cleaner. Especially if Chrome ever adds this functionality this would simplify things a lot, so I think this is a good general idea to which direction this extension should evolve to.
Regarding your code snippet, I think fixing the media sequence is still mandatory.
I'll look at this a bit more closely when I get the time (or actually get some preroll ads again), or of course welcome any PR.

Glad you like it.

I think fixing the media sequence is still mandatory.

Could you elaborate on how fixing the sequence should work? Currently what happens, as I see it in the code (and limited tests with console.log):

Enter a stream
Ads start playing
First non-Ad playlist with e.g. sequence 100
self._seq is set to 99 (100-1)
sequence in the playlist is overwritten with 1 (100-99)
next non-Ad playlist request is set to sequence 2
following non-Ad requests keep counting up

So, is it expected to start at 1 again after an Ad, even for Midrolls? If that's the case, I guess it wouldn't work for multiple Ads since self._seq keeps its value.

Honestly, I'm not sure anymore, especially with midroll ads.
I've been testing on https://www.twitch.tv/twitchpresents yesterday and today, and it seems this way seems most stable.
So we take the delta between the sequence number when ad starts and the sequence number when it stops and add it to the latest sequence number.
This makes it so we only buffer like 10-15 seconds instead of the full 30 seconds.
However I haven't had the chance to really test it with preroll ads yet.
I am sure that sequence numbers are important however. Subtract too much, you get constant buffering, add too much, the stream starts glitching heavily. When ads appear and we leave the sequence number as is afterwards, we get a lot of buffering.
Btw, the code didn't work for midroll ads, only for preroll ads, it was buggy. I reworked it today (linked above).

This idea seems like a generally good technique that could apply to other sites using m3u8 players that feed adds into the m3u8 playlist.  It may help to allow the user to edit and add filter rules along the lines of AdBlock+ URL patterns, or simply Regular Expression pattern matching.  Seems that this could translate well to make this plugin work as a more generic m3u8 ad blocker.


Improve explanation of deploy command

This PR elaborates the explanation of the command function deploy in the main README. Apart from that it shows the available runtimes when executing function deploy|update --help.
Fixes #281

/lgtm


remove unused files

CATEGORY
Choose one

[X] Build / Development Environment

SUMMARY
These files were migrated to @superset-ui and no longer used.
TEST PLAN
npm run build
REVIEWERS

Codecov Report

Merging #8140 into master will decrease coverage by 7.5%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           master   #8140      +/-   ##
=========================================
- Coverage   73.71%   66.2%   -7.51%
=========================================
  Files         115     479     +364
  Lines       12059   22947   +10888
  Branches        0    2527    +2527
=========================================
+ Hits         8889   15192    +6303
- Misses       3170    7621    +4451
- Partials        0     134     +134

Impacted Files
Coverage Δ

superset/assets/src/components/Checkbox.jsx
100% <0%> (ø)

...ations/deckgl/layers/Polygon/PolygonChartPlugin.js
0% <0%> (ø)

.../assets/src/dashboard/reducers/dashboardFilters.js
88.23% <0%> (ø)

...ets/src/dashboard/components/dnd/DragDroppable.jsx
94.59% <0%> (ø)

...c/visualizations/deckgl/layers/Polygon/Polygon.jsx
0% <0%> (ø)

superset/assets/src/components/EditableTitle.jsx
81.81% <0%> (ø)

superset/assets/src/setup/setupPlugins.js
0% <0%> (ø)

...t/assets/src/components/InfoTooltipWithTrigger.jsx
41.66% <0%> (ø)

.../src/dashboard/components/UndoRedoKeylisteners.jsx
9.52% <0%> (ø)

...ts/src/explore/components/ExploreActionButtons.jsx
100% <0%> (ø)

... and 355 more

Continue to review full report at Codecov.

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


Validation Destination

Worked on notes from last week.
Noticed that it only runs overlap function for 50 meters, not both 10 and 50 meters

@gboeing @DRosasMoctezuma
Ready to be merged. Fixed buffer print message and intersect proportion issue


Updated derivation test recipe

Updated the derivation test recipe with new variables and CMIP6 data for testing of ESMValGroup/ESMValCore#754.

Tasks

[x] Create an issue to discuss what you are going to do, if you haven't done so already (and add the link at the bottom)
[x] Give this pull request a descriptive title that can be used as a one line summary in a changelog
[x] Make sure your code is composed of functions of no more than 50 lines and uses meaningful names for variables
[x] Circle/CI tests pass. Status can be seen below your pull request. If the tests are failing, click the link to find out why.
[x] Preferably Codacy code quality checks pass, however a few remaining hard to solve Codacy issues are still acceptable. Status can be seen below your pull request. If there is an error, click the link to find out why. If you suspect Codacy may be wrong, please ask by commenting.
[x] Please use yamllint to check that your YAML files do not contain mistakes
[x] (Only if really necessary) Add any additional dependencies needed for the diagnostic script to setup.py, esmvaltool/install/R/r_requirements.txt or esmvaltool/install/Julia/Project.toml (depending on the language of your script) and also to package/meta.yaml for conda dependencies (includes Python and others, but not R/Julia)
[x] If new dependencies are introduced, check that the license is compatible with Apache2.0

Related to ESMValGroup/ESMValCore#754

I am running this recipe now and will take a look at the output.

I ran the recipe_preprocessor_derive_test.yml and as far as I can tell the output looks fine. But I noticed 2 things that look like bugs to me. These two bugs are not related to this PR or ESMValGroup/ESMValCore#754, but would probably be best addressed in ESMValGroup/ESMValCore#754 as it contains already several fixes to other derivation scripts. The 2 bugs are:

vegfrac: the derivation script calculates "vegfrac = 1. - baresoilfrac" with baresoilfrac given in % (according to CMIP5/6 CMOR tables). This seems wrong and should be "vegfrac = 100. - baresoilfrac" instead.
ohc: in CMIP5, the input variable thetao is given in K while in CMIP6 it is given in degC (according to the CMOR tables). Given how oc is calculated, I think a conversion from degC to K is needed for CMIP6 data before calculating the heat content.

@schlunma : Maybe you could briefly look into those two bugs?
Other than that, thumbs up for this PR and ESMValGroup/ESMValCore#754!

Thanks for testing @axel-lauer! I will include the small changes into ESMValGroup/ESMValCore#754.

This was reviewed/tested as part of ESMValGroup/ESMValCore#754.

@axel-lauer I think this can be merged, right? If so, can you please approve?


Support  Swift 6 language mode

Swift 6 language mode
:recycle: Current situation & Problem
SpeziSpeech didn't support the Swift 6 language mode yet.
See https://github.com/StanfordSpezi/SpeziSpeech/issues/6
:gear: Release Notes

Support Swift 6 language mode

:books: Documentation
Documented why a retroactive Sendable conformance is fine.
:white_check_mark: Testing
--
:pencil: Code of Conduct & Contributing Guidelines
By submitting creating this pull request, you agree to follow our Code of Conduct and Contributing Guidelines:

[x] I agree to follow the Code of Conduct and Contributing Guidelines.

Interesting! I wasn't aware about retroactive.
https://github.com/swiftlang/swift-evolution/blob/main/proposals/0364-retroactive-conformance-warning.md

Interesting! I wasn't aware about retroactive.
https://github.com/swiftlang/swift-evolution/blob/main/proposals/0364-retroactive-conformance-warning.md


[CLOSES #181] Add Rush to travis CI testing

[CLOSES #181] Matrix the langauges to allow testing of all web projects using Gradle/Jar/Docker and native Node/Rush environment
Provides better test coverage for breaking builds in web projects until [#7] is fixed

Going to fix the broken build in the immediately following PR so the git history is easier to understand.


Compile without exceptions, without run-time type information

This is more of a question than an issue, but...  Is there a way to compile OpenEXR without exceptions and/or without run-time type information?
It would be useful for potential users of the library that don't support these features.

It's not currently feasible to compile without exceptions.  They're used extensively for error handling.
There is a limited C API implemented in ImfCRgbaFile.cpp/h, which catches all exceptions internally and does not use any C++ classes in its API, but it is quite limited, lacking access to a lot of modern OpenEXR features, and not well exercised by unit tests, so I would only recommend using it if absolutely necessary.


refactor delete some non-vec exec node

Proposed changes
Issue Number: close #xxx
Problem summary
Describe your changes.
Checklist(Required)

Does it affect the original behavior:

[ ] Yes
[ ] No
[ ] I don't know

Has unit tests been added:

[ ] Yes
[ ] No
[ ] No Need

Has document been added or modified:

[ ] Yes
[ ] No
[ ] No Need

Does it need to update dependencies:

[ ] Yes
[ ] No

Are there any changes that cannot be rolled back:

[ ] Yes (If Yes, please explain WHY)
[ ] No

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

TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 34.94 seconds
load time: 626 seconds
storage size:<PHONE_NUMBER>3 Bytes
https://doris-community-test-1308700295.cos.ap-hongkong.myqcloud.com/tmp/20221221112145_clickbench_pr_66297.html


Numba backend returns wrong statevector

from blueqat import Circuit

c = Circuit()
c.h[0]
c.cx[0, 1];
c.z[2];

import numpy as np

v1 = c.run_with_numpy()
v2 = c.run_with_numba()
v3 = c.run_with_qgate()

print('numpy')
print(v1)
print('numba')
print(v2)
print('qgate')
print(v3)

Expected: All backends return same result
Actual:
numpy
[0.70710678+0.j 0.        +0.j 0.        +0.j 0.70710678+0.j
 0.        +0.j 0.        +0.j 0.        +0.j 0.        +0.j]
numba
[ 0.70710678+0.j  0.70710678+0.j  0.        +0.j  0.        +0.j
 -0.        +0.j -0.        +0.j -0.        +0.j -0.        +0.j]
qgate
[0.70710678+0.j 0.        +0.j 0.        +0.j 0.70710678+0.j
 0.        +0.j 0.        +0.j 0.        +0.j 0.        +0.j]

Easier case: c = Circuit().x[0].cx[0, 1].z[2]

c = Circuit().i[2].x[0].cx[0, 1] is easiest case.
Maybe, when n_qubit is 3, cx is not worked properly.


[Enhancement] Add detail message for random distribution table rollback to older version

Fixes #issue
What type of PR is this:

[ ] BugFix
[ ] Feature
[x] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Does this PR entail a change in behavior?

[ ] Yes, this PR will result in a change in behavior.
[x] No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

[ ] Interface/UI changes: syntax, type conversion, expression evaluation, display information
[ ] Parameter changes: default values, similar parameters but with different default values
[ ] Policy changes: use new policy to replace old one, functionality automatically enabled
[ ] Feature removed
[ ] Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

[x] I have checked the version labels which the pr will be auto-backported to the target branch

[ ] 3.2
[ ] 3.1
[ ] 3.0
[x] 2.5

[BE Incremental Coverage Report]
:heart_eyes: pass : 0 / 0 (0%)

[FE Incremental Coverage Report]
:disappointed: fail : 1 / 2 (50.00%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/sql/optimizer/transformer/RelationTransformer.java
1
2
50.00%
[451]

@Mergifyio backport branch-2.5


[1.1.1] Uniquify FK and index names if there's another FK or index with the same name configured explicitly.

This will still result in a validation error if the conflicting name is configured by convention as in this case the uniquification would be dependent on the convention order.
Fixes #7082

@AndriySvyryd Can you explain what is happening in this bug? What is it that reverse engineering is doing that is then causing, at some point, duplicate indexes? Or what is it that is causing conventions to build an index with the same name as one from reverse engineering but is a different index? Or what...

@ajcvickers RevEng is doing what is supposed to: it generates an index and names it "IX_ApplicationKey_ApplicationId". By convention we create an index for the FK on ApplicationKey.ApplicationId and also name it "IX_ApplicationKey_ApplicationId".


Spec phone number types

I want to improve speccing in my project and it would be good to have this.


UI dark, Photo crop, images input and output show, scenario commented

Conflict after merging Bart’s branch I think

Resolved


Many errors trying to trace with instrument gql functions using actix-web and it's example code

Expected Behavior
I would like to trace functions.
Actual Behavior
Copying the starwars example for actix-web I'm having issues understanding these errors when trying to instrument:
#[derive(Debug)] // adding this
struct AppState {
  gql_schema: Schema<QueryRoot, EmptyMutation, EmptySubscription>, // errors here (description below)
  // other fields here...
}

async fn main() -> std::io::Result<()> {
  let schema = Schema::build(QueryRoot, EmptyMutation, EmptySubscription)
    .data(StarWars::new())
    .finish();

  println!("Playground: http://localhost:8000");

  HttpServer::new(move || {
    App::new()
      .app_data(Data::new(AppState {
        gql_schema: gql_schema.clone(), // using it here
      }))
      .service(web::resource("/").guard(guard::Post()).to(index))
      .service(web::resource("/").guard(guard::Get()).to(index_playground))
  })
  .bind("<IP_ADDRESS>:8000")?
  .run()
  .await
}

#[tracing::instrument()] // here another error
async fn index(app_state: web::Data<AppState>, req: GraphQLRequest) -> GraphQLResponse {
    app_state.gql_schema.execute(req.into_inner()).await.into()
}

the errors are:
`async_graphql::Schema<starwars::QueryRoot, async_graphql::EmptyMutation, async_graphql::EmptySubscription>` doesn't implement `std::fmt::Debug`
the trait `std::fmt::Debug` is not implemented for `async_graphql::Schema<starwars::QueryRoot, async_graphql::EmptyMutation, async_graphql::EmptySubscription>` rustc E0277

server.rs(13, 10): Error originated from macro call here

and
`async_graphql_actix_web::GraphQLRequest` doesn't implement `std::fmt::Debug`
the trait `std::fmt::Debug` is not implemented for `async_graphql_actix_web::GraphQLRequest`
the trait `tracing::Value` is implemented for `tracing::field::DebugValue<T>`
required because of the requirements on the impl of `std::fmt::Debug` for `&async_graphql_actix_web::GraphQLRequest`
required because of the requirements on the impl of `tracing::Value` for `tracing::field::DebugValue<&async_graphql_actix_web::GraphQLRequest>`
required for the cast to the object type `dyn tracing::Value` rustc E0277

How can I fix?
I tried to add tracing feature too in Cargo.toml, but it's the same:
async-graphql = { version = "4.0.6", features = ["tracing"] }

Specifications

Version: async-graphql = "4.0.6"
Platform: Windows 10 64

It seems like you forgot to add the extension to the schema, as is described in this doc. Does that help?
use async_graphql::{extensions::Tracing, *};

let schema = Schema::build(QueryRoot, EmptyMutation, EmptySubscription)
    .extension(Tracing)  // <-- Add this
    .data(StarWars::new())
    .finish();

Thanks.


provide an 'openshift override' enricher

its common to have to wire things up differently on openshift versus kubernetes; we've found this on the fabric8 platform project; we've been making a fair use of the annotations:
fabric8.io/target-platform: "kubernetes" and fabric8.io/target-platform: "openshift"  then copy/pasting entire YAMLs.
It would be nice to make the markup much more DRY and easier to reason about the differences between the kubernetes and openshift flavours.
e.g. what would be cooler would be to leave the src/main/fabric8 folder as the default kubernetes markup; then have YAML fragments that get applied to override values for the openshift platform flavour. e.g. files in, say, src/main/fabric8/openshift or src/main/fabric8/platform/openshift would then override the contents of src/main/fabric8.
here are 2 simple examples

https://github.com/fabric8io/fabric8-platform/blob/master/apps/forge/src/main/fabric8/cm.yml
https://github.com/fabric8io/fabric8-platform/blob/master/apps/forge/src/main/fabric8/openshift-cm.yml

what would be nice would be just to provide the overrides for openshift without having to copy/paste it all:
e.g. instead of
apiVersion: v1
kind: ConfigMap
metadata:
  name: forge
  annotations:
    fabric8.io/target-platform: "openshift"
    expose.config.fabric8.io/apiserver-url-key: apiserver.url
    #expose.service-key.config.fabric8.io/sso: keycloak.url
data:
  keycloak.url: http://keycloak
  apiserver.url: http://kubernetes

we could just define the overrides:
metadata:
  name: forge
  annotations:
    expose.service-key.config.fabric8.io/sso:
data:
  keycloak.url: http://keycloak

(where the empty annotation removes the annotation for the openshfit.yml)
e.g. here's 2 files we're using for the console which are mostly the same apart from an environment variable (I think)

https://github.com/fabric8io/fabric8-platform/blob/master/apps/fabric8/src/main/fabric8/deployment.yml
https://github.com/fabric8io/fabric8-platform/blob/master/apps/fabric8/src/main/fabric8/dc.yml

but its kinda hard to grok the delta really; they should be mostly the same

Makes much sense, especially when we combine it with the new enricher architecture where kubernetes.yml and openshift.yml are created in two passes through the enricher pipeline, which each enricher knowing for what platform it should enrich (in contrast to the current way where we only call enrichers once and the do conversion from kubernetes.yml to openshift.yml which never will be perfect).
One problem though: Every directory ins src/main/fabric8 is supposed is taken as a profile name and the fragments within this directory are enriched with the enrichers defined in the specified profile (e.g. if you add a raw directory, then every fragment with in this directory will be enriched with the profile raw which effectively mean no enrichment at all).
However there is already an issue open that for fmp 4 the semantics of this should change, itroducing an addition layer src/main/fabric8/profile/... so that the leve on src/main/fabric8/ would be free again for other specialized directories.

@rhuss @jstrachan
Few points to discuss (may be naive as well)

"new enricher architecture" is present in 3.5 version or its part of f8-m-p v.4 (fmp 4) release?
Apart from overriding, how to treat if OpenShift overriding fragment contains additional annotation properties?

"new enricher architecture" is present in 3.5 version or its part of f8-m-p v.4 (fmp 4) release?

It's part of fmp v4 (at least as I envision it ;-). See also https://github.com/fabric8io/fabric8-build for some more information about the refactoring and https://github.com/fabric8io/fabric8-maven-plugin/issues/678

Apart from overriding, how to treat if OpenShift overriding fragment contains additional annotation properties?

I would say, that they were simply added.

@rhuss I could really use this feature before we find time to implement 4.x - its desperately required for fabric8 upstream to avoid copy/paste hell :)
For now where would you suggest we put the override files? src/main/fabric8-openshift maybe? Then any partials in that folder would be used to override anything in the kubernetes-centric stuff in src/main/fabric8?
Whenever 4.x comes along we can refactor this to load the relevant files in the right pass through the enrichers and whatnot

Will take this up.

@hrishin have a PR ready - wonder if you fancy reviewing it?

@jstrachan sure

here you go @hrishin
fancy taking a look too @nicolaferraro @rhuss am gagging to use this on fabric8-platform ;)

the main requirements I've got so far from fabric8-platform is to add/edit/remove an annotation (either top level or in a Deployment's template) or  add/edit/remove an env var which all get covered in the main test case:  https://github.com/jstrachan/fabric8-maven-plugin/blob/d02027f84743c9e31a487b0c26b545d26513e3c6/core/src/test/java/io/fabric8/maven/core/util/MergeResourceTest.java#L45

Unfortunately, I'm too loaded with other works right now ;-(, but would love if @nicolaferraro could have a look, too.
In principle, I agree with having urgent fixes now if they can be easily migrated later to a 'cleaner' architecture without too much of backwards compatibility chains.

@rhuss no worries, I understand.
Forget the code really, its pretty straightforward stuff (hopefully!)-  but what do you think about the name of the directory that contains the openshift override YAML files. I've gone with src/main/fabric8-openshift for now - got any better ideas? Based on the profile stuff I didn't want to put it inside src/main/fabric8 as that'd just cause confusion/work/issues etc.

BTW I've ported fabric8-platform to use this new mechanism and its made things so much simpler; its way less confusing than having multiple copies of resources for kubernetes + openshift with the platform annotations (though sometimes we do need that to include/exclude certain resources - its more rare though really now there's this cleaner mechanism for overrides)

@jstrachan wdyt about e.g. src/main/fabric8-openshift-override to make it clear that it is not about the full configuration ? A bit lengthy maybe, but I think it matches the intention a bit better.
Agreed that we shouldn't put it (yet) below src/main/fabric8.

@rhuss yes - much better - lets go with src/main/fabric8-openshift-override


Add Visual.GetTransformedBounds extension method.

What does the pull request do?
Changes to the renderer have made it so that the TransformedBounds property is no longer feasible to do with decent performance, however if one needs to just calculate the TransformedBounds for a control without listening for changes to these bounds, this new method can do that!
Fixes #9569.

You can test this PR using the following package version. 11.0.999-cibuild0031826-beta. (feed url: https://pkgs.dev.azure.com/AvaloniaUI/AvaloniaUI/_packaging/avalonia-all/nuget/v3/index.json) [PRBUILDID]


all command available through busybox [command] in shell

I believe the point of the harden.sh script was to remove access to all the usual commands. But these commands are available as extensions to busybox.
But I may have misunderstood the point of the harden.sh script.

Actually an example might heip. The harden.sh does:
find -name su -delete
but you can do:
busybox su
to have the same effect.

The goal of this project is to prevent users from doing harmful things to the bastion, eg. adding new keys to authorized_keys or replacing the ssh command with backdoors.
Although it's possible to call commands like busybox ls, users cannot do anything meaningful.

ok thanks for the clarification,
it is just that most of the harden.sh commands are not useful:
it just makes most commands slightly more difficult to access
I have tried to workaround this problem by adding a custom dash shell and make busybox available to root only, but a static nc would also be required.
So I cannot provide a better solution for now.

If a user can login to the bastion and make it any different than the way it was, then it's a real problem.


Loader doesn't handle wrapping debug report callbacks

The dispatch chain for CreateDebugReportCallback goes from application → debug_report_CreateDebugReportCallback → layers... → terminator_CreateDebugReportCallback which calls into the ICD.
Inside debug_report_CreateDebugReportCallback on successful return, the callback is inserted into a linked list of live callbacks, with the function from the matching VkDebugReportCallbackCreateInfoEXT as the function to call. This is used for internal messages the loader sends off, as well as anything that calls vkDebugReportMessageEXT (which is implemented by the loader).
The problem is that this doesn't account for layers potentially changing and wrapping debug report callbacks. E.g. If a layer wants to add some annotation to all messages before passing them back to the application, or in my case my layer will suppress and discard all messages to prevent them from reaching the application.
So what happens is my layer and anything downstream (including ICD, if such messages exist) will go through the right callback function, but the loader will go directly to the unwrapped application's callback. This is an inconsistency - a minor one for the loader, but a more significant one for messages inserted by vkDebugReportMessageEXT.
I'm not sure exactly what the fix would be - you need to have the VkDebugReportCallbackCreateInfoEXT that is specified in the terminator to get the 'fully wrapped' callback function. But the resulting VkDebugReportCallbackEXT and VkResult needs to come from debug_report_CreateDebugReportCallback. Perhaps the new node could be created temporarily in the terminator, and upon successful return it could be filled out with the resulting callback object and enqueued - otherwise if there's a failure, it's deleted. Or maybe just a temporary member of the struct loader_instance so there's no need for allocation.

Can you try the code I put in marky_gh851_debugreport?  I believe I've made the changes you desire.

That branch seems to do the trick from my quick testing :+1:.

Pushed up in commit 4b0c7df3980851c6e872437860ac88a98b34c8c5


NEEW

NEEW

Why do you request a pull with only a name change?

Every pull request on this repo does this. These people are really sad...


[beta] signup on the website throws cloudflare login

after hitting "Join the Beta":

this shouldn't happen:

I inadvertently applied CF Access Protection to the signup API (was supposed to be limited to the Hub portal). Now removed.


Add validation to wiki form

The ID and Type fields should have validation to restrict entry to letters, numbers and dashes. This validation should be applied with the same module on frontend and backend.

I'm on it


Cannot ignore a terminology rule on a line of a markdown file that references a specific header name of an excel file

What version of textlint are you using?
$ textlint -v
v14.4.0

What file type (Markdown, plain text, etc.) are you using?
Markdown
What did you do? Please include the actual source code causing the issue.
Lines 70-72 of the file in question:
    <!-- textlint-disable terminology -->
    "mzXML File Name", "Sequence", and "Skip" values (the only way to determine
    <!-- textlint-enable -->

The occurrence of mzXML File Name is a reference to the name of an excel sheet header.  Changing it to "filename" would be invalid, so I'm trying to make textlint ignore it, but nothing I try eliminates the following reported error when I run:
$ textlint .github/pull_request_template.md

What did you expect to happen?
The filename error should be ignored, given the in-line ignore directive.
What actually happened? Please include the actual, raw output from textlint.
/Users/rleach/PROJECT-local/TRACEBASE/tracebase-rabinowitz-data/.github/pull_request_template.md
  71:12  ✓ error  Incorrect term: “File Name”, use “filename” instead  terminology

✖ 1 problem (1 error, 0 warnings)
✓ 1 fixable problem.
Try to run: $ textlint --fix [file]

I also tried <!-- textlint-disable -->

Can you create reproduce repository?

I'm not sure I understand your question. It is in a private GitHub repository and this error turned up when I updated superlinter from slim v4 to slim v6.x. I reproduced it on the command line.
Are you asking for a link to the repo?

It is helpful to have a minimum reproduction repository to debug.
Perhaps a blank line break is needed between the comment and the text.
<!-- textlint-disable terminology -->

"mzXML File Name", "Sequence", and "Skip" values (the only way to determine

<!-- textlint-enable -->

Also, HTML comments written in code blocks cannot be treated as comments.
If there is a minimal repository to reproduce, it can be investigated.


Possibility to add youtube channel, instagram, etc

About this issue
I think it could be a nice feature to being able to add social media links

Briefly describe the issue
How can the issue be reproduced / sample code

Details

[ ] Used library version
[ ] Used support library version
[ ] Used gradle build tools version
[ ] Used tooling / Android Studio version
[ ] Other used libraries, potential conflicting libraries

Checklist

[ ] Searched for similar issues
[ ] Checked out the sample application
[ ] Read the README
[ ] Checked out the CHANGELOG
[ ] Read the MIGRATION GUIDE

@manuelarte if you want to change the UI from what is offered, just use the core library and use the information provided by the library inside your own UI :)
there are currently no plans to adjust beyond the very minimalistic About this app screen integrated.

Btw. theoretically if you do not want special there are APIs and ways to also modify the header provided.
copy the xml for the header from the org project, and modify it (make sure original layouts and IDs stay the same)
You can also look into the LibsConfiguration which allows to intercept various aspects of the provided UI and modify things for your usecase

Thanks @mikepenz


results when use ResNet50 as backbone

Hello, the existing text detection backbone is generally ResNet50, but the results given in the paper are the results of ResNet101. What are the results of  TextFuseNET on several datasets when using ResNet50 as the backbone?

read carefully, please.


[Style] Remove "should" not related to conformance

The style.md file includes the word "should" which may unintentionally be confused with "SHOULD" as used to identify a conformance/certification requirement.
This pull request removes the word "should" so there is not confusion
Signed-off-by: Rob Dolin<EMAIL_ADDRESS>

On Mon, Aug 22, 2016 at 12:28:23PM -0700, Rob Dolin (MSFT) wrote:

The style.md file includes the word "should" which may
unintentionally be confused with "SHOULD" as used to identify a
conformance/certification requirement.

ALL CAPS are pretty striking.  And style.md is fairly clearly
targetting runtime-spec authors, although it will explicitly not be
included in the protocol listing that's in flight with #527.  So I
don't think these changes are particularly critical, but they
shouldn't hurt either ;).

On Mon, Aug 22, 2016 at 12:28:23PM -0700, Rob Dolin (MSFT) wrote:

[Style] Remove "should" not realted to conformance

“realted” → “related”

I believe all of the issues @wking raised have now been addressed (including my typo in the PR title)

Everything through 6d500fbb looks good to me.  Maybe squash down to a
single commit, but that's not a big deal.

LGTM

LGTM

There is still a signed off missing on a commit, it would be better to just squash them all.

LGTM, and appears to be all-signed-off to me (and Travis agrees) :+1:

It's pullapprove which disagrees! What!

Not seeing any issues here, pullapprove...

Interesting, I wonder what emails @RobDolinMS has associated with this github account.
Is it<EMAIL_ADDRESS>

@caniszczyk did we ever figure out what's causing @RobDolinMS to be shafted by PullApprove? :cry:

On Fri, Nov 04, 2016 at 03:56:53PM -0700, Tianon Gravi wrote:

@caniszczyk did we ever figure out what's causing @RobDolinMS to be
shafted by PullApprove? :cry:

My random guess is that he has (MSFT) in his author field but not in
his s-o-b:
$ git show origin/pr/536 | head -n 7
commit 6d500fbb70eb5071eef78197e013641ce5215609
Author: Rob Dolin (MSFT<EMAIL_ADDRESS>Date:   Wed Aug 31 14:29:31 2016 -0700
  [Style] Update sentence about example headers

  Signed-off-by: Rob Dolin<EMAIL_ADDRESS>

@RobDolinMS could you try matching the Author and Signed-off-by name?

@RobDolinMS when you have time please rebase your PRs and make sure your sign off is correct.  Feel free to reopen when they have been updated.


Updated 'createshipment' action for Zenkraft Connector

Please check the following conditions for your PR.

[ ] apiDefinition.swagger.json is validated using paconn validate command.
[ ] apiProperties.json has a valid brand color. Invalid brand colors are #007ee5 and #ffffff.

@waelelzahr Please resolve the branch conflicts by syncing your branch with remote or dev branch to get this PR merged.

@waelelzahr Please resolve the branch conflicts by syncing your branch with remote or dev branch to get this PR merged.

@sriyen-msft  I have fixed the conflicts.


Add long-read-mngs step descriptions

Modifies long read mngs workflow to output a markdown file describing the step. The markdown files are later visualized by the PipelineViz
Descriptions can be found here: https://docs.google.com/spreadsheets/d/1oXui5Ory2wg9GJvEVciKu8GEoqCI62zVbMoaj3sWzzA/edit#gid=1477420657

Closing as this is done!


Update and rename chapter 4 to chapter_4.md

Didn't make sense for it to stand out from the others.

@CatFishing4Guyz Thank you for the update!


Update The Professor to work with MWL 1.2

Fix for Issue #110

@Alsciende I just realized there's a bug with this implementation, give me a sec to fix it up.


Evaluate performance improvements on big datasets on the js rendering step

Rather than focusing on big datasets, I removed a few unnecessary rendering on all datasets, which affects big datasets greater:

Removed bezier curves - https://github.com/marianogappa/chart/issues/20
Disabled animations


Fixes #1. Complete review and update of appledoc documentation.

Added and updated documentation for the two main external classes, CDTIncrementalStore and CDTReplicator.  Also removed markup on internal methods so that these are not picked up by appledocs.

The updated appledoc can be viewed at http://crazymike.mybluemix.net.

@tfrank64 please review these changes and the new doc and ack or suggest changes.


[Enhancement] Support mv_rewrite_staleness param for mv rewrite

What type of PR is this：

[ ] BugFix
[ ] Feature
[x] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Problem Summary(Required) ：

add a configuration setting to reduce the frequency of partition checks.

   // max delay duration to check which partitions to refresh, in this duration we use last
    // `needToRefreshPartitionNamesCache` as the current `needToRefreshPartitionNames` result.
    // NOTE: unit second.
    private int maxMVRewriteStaleness = 0;

Checklist:

[x] I have added test cases for my bug fix or my new feature
[ ] This pr will affect users' behaviors
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

[x] I have checked the version labels which the pr will be auto backported to target branch

[x] 3.0
[ ] 2.5
[ ] 2.4
[ ] 2.3

[FE PR Coverage Check]
:heart_eyes: pass : 60 / 73 (82.19%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/catalog/MaterializedView.java
14
17
82.35%
[852, 853, 854]

:large_blue_circle:
com/starrocks/server/LocalMetastore.java
46
56
82.14%
[2814, 2818, 2822, 2823, 2824, 2825, 2826, 2827, 2830, 2831]

[FE PR Coverage Check]
:heart_eyes: pass : 75 / 89 (84.27%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/server/LocalMetastore.java
44
54
81.48%
[2812, 2816, 2820, 2821, 2822, 2823, 2824, 2825, 2828, 2829]

:large_blue_circle:
com/starrocks/catalog/MaterializedView.java
14
17
82.35%
[852, 853, 854]

:large_blue_circle:
com/starrocks/common/util/PropertyAnalyzer.java
9
10
90.00%
[361]

:large_blue_circle:
com/starrocks/alter/Alter.java
8
8
100.00%
[]

[FE PR Coverage Check]
:heart_eyes: pass : 95 / 112 (84.82%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/sql/optimizer/MaterializedViewOptimizer.java
2
3
66.67%
[38]

:large_blue_circle:
com/starrocks/catalog/MaterializedView.java
22
27
81.48%
[346, 870, 871, 872, 1130]

:large_blue_circle:
com/starrocks/server/LocalMetastore.java
44
54
81.48%
[2816, 2820, 2824, 2825, 2826, 2827, 2828, 2829, 2832, 2833]

:large_blue_circle:
com/starrocks/common/util/PropertyAnalyzer.java
9
10
90.00%
[354]

:large_blue_circle:
com/starrocks/sql/optimizer/MvRewritePreprocessor.java
9
9
100.00%
[]

:large_blue_circle:
com/starrocks/alter/Alter.java
8
8
100.00%
[]

:large_blue_circle:
com/starrocks/scheduler/PartitionBasedMaterializedViewRefreshProcessor.java
1
1
100.00%
[]

[FE PR Coverage Check]
:heart_eyes: pass : 95 / 112 (84.82%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/sql/optimizer/MaterializedViewOptimizer.java
2
3
66.67%
[38]

:large_blue_circle:
com/starrocks/catalog/MaterializedView.java
22
27
81.48%
[346, 870, 871, 872, 1130]

:large_blue_circle:
com/starrocks/server/LocalMetastore.java
44
54
81.48%
[2816, 2820, 2824, 2825, 2826, 2827, 2828, 2829, 2832, 2833]

:large_blue_circle:
com/starrocks/common/util/PropertyAnalyzer.java
9
10
90.00%
[354]

:large_blue_circle:
com/starrocks/sql/optimizer/MvRewritePreprocessor.java
9
9
100.00%
[]

:large_blue_circle:
com/starrocks/alter/Alter.java
8
8
100.00%
[]

:large_blue_circle:
com/starrocks/scheduler/PartitionBasedMaterializedViewRefreshProcessor.java
1
1
100.00%
[]

[FE PR Coverage Check]
:heart_eyes: pass : 123 / 144 (85.42%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/sql/optimizer/MaterializedViewOptimizer.java
2
3
66.67%
[38]

:large_blue_circle:
com/starrocks/server/LocalMetastore.java
44
54
81.48%
[2816, 2820, 2824, 2825, 2826, 2827, 2828, 2829, 2832, 2833]

:large_blue_circle:
com/starrocks/catalog/MaterializedView.java
41
50
82.00%
[345, 513, 535, 570, 578, 891, 892, 893, 1138]

:large_blue_circle:
com/starrocks/common/util/PropertyAnalyzer.java
9
10
90.00%
[354]

:large_blue_circle:
com/starrocks/sql/optimizer/MvRewritePreprocessor.java
9
9
100.00%
[]

:large_blue_circle:
com/starrocks/alter/Alter.java
8
8
100.00%
[]

:large_blue_circle:
com/starrocks/scheduler/PartitionBasedMaterializedViewRefreshProcessor.java
10
10
100.00%
[]

[FE PR Coverage Check]
:heart_eyes: pass : 127 / 150 (84.67%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/sql/optimizer/MaterializedViewOptimizer.java
2
3
66.67%
[38]

:large_blue_circle:
com/starrocks/catalog/MaterializedView.java
45
56
80.36%
[345, 513, 517, 542, 577, 583, 591, 904, 905, 906, 1151]

:large_blue_circle:
com/starrocks/server/LocalMetastore.java
44
54
81.48%
[2838, 2842, 2846, 2847, 2848, 2849, 2850, 2851, 2854, 2855]

:large_blue_circle:
com/starrocks/common/util/PropertyAnalyzer.java
9
10
90.00%
[354]

:large_blue_circle:
com/starrocks/sql/optimizer/MvRewritePreprocessor.java
9
9
100.00%
[]

:large_blue_circle:
com/starrocks/alter/Alter.java
8
8
100.00%
[]

:large_blue_circle:
com/starrocks/scheduler/PartitionBasedMaterializedViewRefreshProcessor.java
10
10
100.00%
[]

[FE PR Coverage Check]
:heart_eyes: pass : 127 / 150 (84.67%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/sql/optimizer/MaterializedViewOptimizer.java
2
3
66.67%
[38]

:large_blue_circle:
com/starrocks/catalog/MaterializedView.java
45
56
80.36%
[127, 339, 508, 512, 574, 580, 588, 901, 902, 903, 1148]

:large_blue_circle:
com/starrocks/server/LocalMetastore.java
44
54
81.48%
[2838, 2842, 2846, 2847, 2848, 2849, 2850, 2851, 2854, 2855]

:large_blue_circle:
com/starrocks/common/util/PropertyAnalyzer.java
9
10
90.00%
[354]

:large_blue_circle:
com/starrocks/sql/optimizer/MvRewritePreprocessor.java
9
9
100.00%
[]

:large_blue_circle:
com/starrocks/alter/Alter.java
8
8
100.00%
[]

:large_blue_circle:
com/starrocks/scheduler/PartitionBasedMaterializedViewRefreshProcessor.java
10
10
100.00%
[]

[FE PR Coverage Check]
:heart_eyes: pass : 132 / 153 (86.27%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/sql/optimizer/MaterializedViewOptimizer.java
2
3
66.67%
[38]

:large_blue_circle:
com/starrocks/server/LocalMetastore.java
44
54
81.48%
[2838, 2842, 2846, 2847, 2848, 2849, 2850, 2851, 2854, 2855]

:large_blue_circle:
com/starrocks/catalog/MaterializedView.java
43
52
82.69%
[335, 504, 508, 570, 576, 584, 897, 898, 899]

:large_blue_circle:
com/starrocks/common/util/PropertyAnalyzer.java
9
10
90.00%
[354]

:large_blue_circle:
com/starrocks/sql/optimizer/MvRewritePreprocessor.java
9
9
100.00%
[]

:large_blue_circle:
com/starrocks/alter/Alter.java
8
8
100.00%
[]

:large_blue_circle:
com/starrocks/scheduler/PartitionBasedMaterializedViewRefreshProcessor.java
17
17
100.00%
[]

[FE PR Coverage Check]
:heart_eyes: pass : 130 / 151 (86.09%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/sql/optimizer/MaterializedViewOptimizer.java
2
3
66.67%
[38]

:large_blue_circle:
com/starrocks/server/LocalMetastore.java
44
54
81.48%
[2838, 2842, 2846, 2847, 2848, 2849, 2850, 2851, 2854, 2855]

:large_blue_circle:
com/starrocks/catalog/MaterializedView.java
43
52
82.69%
[340, 509, 513, 575, 581, 589, 902, 903, 904]

:large_blue_circle:
com/starrocks/common/util/PropertyAnalyzer.java
9
10
90.00%
[354]

:large_blue_circle:
com/starrocks/sql/optimizer/MvRewritePreprocessor.java
9
9
100.00%
[]

:large_blue_circle:
com/starrocks/alter/Alter.java
8
8
100.00%
[]

:large_blue_circle:
com/starrocks/scheduler/PartitionBasedMaterializedViewRefreshProcessor.java
15
15
100.00%
[]

[FE PR Coverage Check]
:heart_eyes: pass : 130 / 151 (86.09%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/sql/optimizer/MaterializedViewOptimizer.java
2
3
66.67%
[38]

:large_blue_circle:
com/starrocks/server/LocalMetastore.java
44
54
81.48%
[2840, 2844, 2848, 2849, 2850, 2851, 2852, 2853, 2856, 2857]

:large_blue_circle:
com/starrocks/catalog/MaterializedView.java
43
52
82.69%
[341, 510, 514, 576, 582, 590, 914, 915, 916]

:large_blue_circle:
com/starrocks/common/util/PropertyAnalyzer.java
9
10
90.00%
[354]

:large_blue_circle:
com/starrocks/sql/optimizer/MvRewritePreprocessor.java
9
9
100.00%
[]

:large_blue_circle:
com/starrocks/alter/Alter.java
8
8
100.00%
[]

:large_blue_circle:
com/starrocks/scheduler/PartitionBasedMaterializedViewRefreshProcessor.java
15
15
100.00%
[]

it deserves writing a document to explain this feature

[FE PR Coverage Check]
:heart_eyes: pass : 129 / 151 (85.43%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/sql/optimizer/MaterializedViewOptimizer.java
2
3
66.67%
[38]

:large_blue_circle:
com/starrocks/server/LocalMetastore.java
44
54
81.48%
[2864, 2868, 2872, 2873, 2874, 2875, 2876, 2877, 2880, 2881]

:large_blue_circle:
com/starrocks/catalog/MaterializedView.java
43
52
82.69%
[341, 514, 518, 558, 581, 587, 915, 916, 917]

:large_blue_circle:
com/starrocks/alter/Alter.java
7
8
87.50%
[331]

:large_blue_circle:
com/starrocks/common/util/PropertyAnalyzer.java
9
10
90.00%
[354]

:large_blue_circle:
com/starrocks/sql/optimizer/MvRewritePreprocessor.java
9
9
100.00%
[]

:large_blue_circle:
com/starrocks/scheduler/PartitionBasedMaterializedViewRefreshProcessor.java
15
15
100.00%
[]

@Mergifyio backport branch-3.0


Polish Bundles

Added Polish Bundle files. Internationalization.

Hey :)
I appreciate your effort in translating the SDK to Polish!
However, there are some minor problems regarding the form of it: The files in branding are re-written by gradle/ant upon build time, so we might want a better solution (so when we change the splash screen resolution, it is changed in all translations).
I don't know if netbeans has something for this (like just a different folder), but for the modules themselves, the localization can definitely happen in that form (different bundle files).
So we will have to figure out how to make the branding internationalized first


Udev and dbus overrides

Two simple overrides and one drive-by override fixup.
Use of $RUSTC will fail if we ever switch how it's provided to the build env.  Recommend a followup PR to always provide rustc on the $PATH for other creative build.rs scripts which attempt to invoke it directly

@psionic-k I think the PR is failing due to #145. We should open a separate PR upgrading the Cargo.lock for cargo2nix and the included examples so it's compatible with Rust 1.47+.

Blocked on #148.

@psionic-k Okay, #148 is now merged! Try rebasing against master and give it another shot.

After this PR gets merged, let's try to get #137 over the finish line. Or perhaps restart work on it with a new branch and an even newer cargo version, if possible. If we can successfully complete that task, we will be able to resolve both #110 and #145 in one go, and we will be able to support the latest stable Rust again.


HttpWebRequest instead of httpclient

hi
Thanx for your work,
Is there any way to use HttpWebRequest instead of httpclient?
could you provide sample?

Sorry, but I'm not aware of a simple method to use this library together with HttpWebRequest. You basically have to manually do all the steps that happen inside the ClearanceHandler.

Add a CookieContainer to your request
Add a Client-Header to your request
Get the response and check if the JS-challenge is present
Solve the JS-challenge using the ChallengeSolver-class
Build the clearance URL using the solution and request it
Add the cookies provided by the clearance page to your original request
Repeat your original request

This list is maybe not complete, but that is more or less, what the ClearanceHandler normally would to for you. At least you can make use of the ChallengeSolver.

thanx for your tips, I willl give it a try :)

hi
It worked, i just make _cookie field ,"Public", and replace my own cookie container
I'm so Happy :))
Thanx dude


[Batch] Portfolio

Tables for Stocks and Portfolios have been created and I'm refining the models we have created for them.
I am currently working on functionality to add and remove stocks from a portfolio, once that is done, I can integrate the work I have on a draft branch to pull the stock info form the Alpha Vantage API
My goal is to have this done, as well as a Portfolio UI by the time we meet on Thursday.

Closing in favor of https://github.com/rubyforgood/stocks-in-the-future/issues/146


feat(vmss)!: add autoscaling

Changes to vmss module
For module vmss the changes are drastic:

Add public_backend_pool_id input.

Migrate to azurerm_linux_virtual_machine implementation.

Use the azurerm_linux_virtual_machine_scale_set, which is now preferred over the old azurerm_virtual_machine_scale_set.

Add App Insights for metrics collection.

Add the code to grow/shrink the size of the VMSS.

Add new metric-related outputs.

Change name-related input defaults.

Swap priv and pub interface. Users generally expect us to keep the tradition of having public interface first, private second.

The example for the vmss module

Add autoscaling variables.
Default to pan-os 10.0.6.
Separate inbound/outbound subnets from each other.
Add natgw in the transit VPC.
Allow pre-existing RG.
Upgrde provider version to 2.64. On previous provider 2.58 each run wanted to add:

  module.inbound_lb.azurerm_lb.lb will be updated in-place:
  private_ip_address_version    = "IPv4"

Bumping to >= 2.64 removes that annoying modification.
Add create_virtual_network conditional.
Add input enable_zones.

How Has This Been Tested?
cd examples/vmseries_scaleset
terraform apply

Types of changes

Breaking change (fix or feature that would cause existing functionality to change) - break the behavior of the old vmss module only

Checklist

[x] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[x] I have added tests to cover my changes if appropriate.
[x] All new and existing tests passed.

This is EXCELLENT and I am excited to try it out!
Looking forward to when this gets merged!

Merged it is, thank you for the kind words. It's not that excellent but simply a big change in functionality that took (too) much time to implement correctly.


Allow clear deletes the model completely

When using  allow-clear="true" upon clearing the whole model gets deleted completely see plunker http://plnkr.co/edit/G3f7ox2suhUNM8e86jOb?p=preview
Is there any way to connect to the on-clear event and simply set the model to null ?

Have you tried an on-select event handler, checking for undefined?
And out of curiosity, how does your app break if model value equals to undefined?
Source: https://github.com/angular-ui/ui-select/blob/master/dist/select.js#L562


Jobs sent to ibmq_qasm_simulator never leave the "queued" state

Information

qiskit-ibm-provider version: latest
Python version:
Operating system:

What is the current behavior?

from qiskit_ibm_provider import IBMProvider
provider = IBMProvider()
backend = provider.get_backend('ibmq_qasm_simulator')

qc = QuantumCircuit(1)
qc.h(0)
qc.measure_all()

res = backend.run(qc).result()

never leaves the queued state.  E.g. cfnu6d7nsad1pn87tli0
Steps to reproduce the problem
Run above
What is the expected behavior?
Results should be returned.
Suggested solutions

The reason why this specific job ID has been stuck in queued state is that it was really queued for a very long time, as there were ~21,000 job before it in the internal queue. When it finally ran, the cached parameters weren't available in the cache anymore, that's why it went into failed state. The caching issues are addressed by issues in Qiskit Runtime.
I'm closing this issue as it's not a qiskit-ibm-provider issue, but one further down the stack.

the original issue has been resolved, closing this now


wave-folder VCA CV biasing is not ideal

Adjust the CV biasing so that the manual controls and CV input "feel good". Currently there are some dead zones in the pot travel and cramped sweet spots.

Improved the feel of the CV biasing by changing R12 to do-not-fit(dnf).


Widget Setting is not retained

Jenkins 2.176.2
Build Monitor View 1.12+build.201809061734
Build Failure Analyzer 1.25.1
If I set "Failure Analyzer Plugin: Field to display" to "Description" and Save, the Jenkins config.xml file is updated correctly:
      <config>         <displayCommitters>false</displayCommitters>         <buildFailureAnalyzerDisplayedField>Description</buildFailureAnalyzerDisplayedField>         <order class="com.smartcodeltd.jenkinsci.plugins.buildmonitor.order.ByName"/>       </config>
But next time I open the Build Monitor Config, the "Field to display" is back to the default; "Name".
So it seems like it's not reading the config.xml properly.

Seems to be the same problem as #491. Do you also use JCasC plugin?


Torch said no "ERROR: Could not find a version that satisfies the requirement torch (from versions: none) ERROR: No matching distribution found for torch"

ERROR: Could not find a version that satisfies the requirement torch (from versions: none)
ERROR: No matching distribution found for torch

G:-AI>git clone https://github.com/litagin02/rvc-tts-webui.git
Cloning into 'rvc-tts-webui'...
remote: Enumerating objects: 100, done.
remote: Counting objects: 100% (50/50), done.
remote: Compressing objects: 100% (6/6), done.
Receiving objects:  49% (49/100)used 44 (delta 44), pack-reused 50
Receiving objects: 100% (100/100), 227.49 KiB | 3.20 MiB/s, done.
Resolving deltas: 100% (50/50), done.
G:-AI>cd rvc-tts-webui
G:-AI\rvc-tts-webui>python -m venv venv
G:-AI\rvc-tts-webui>venv\Scripts\activate
(venv) G:-AI\rvc-tts-webui>pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu11
Looking in indexes: https://download.pytorch.org/whl/cu11
ERROR: Could not find a version that satisfies the requirement torch (from versions: none)
ERROR: No matching distribution found for torch
(venv) G:-AI\rvc-tts-webui>

I did have the same trouble with RVC-web-UI repo, this can either be because you are using a 32-bit version of python, or the version of python itself, did have this error with pyhton 3.8.0 on 32 and 64, switched to 3.8.6 64 and it resolved itself


Not found: Resource localhost/Embedding-Token/embeddings/N10tensorflow3VarE does not exist

问题已经解决

问题已经解决

请问是怎么解决的呀


How to use the macro

how to use the macro, like laravel.
laravel`s router  use Illuminate\Support\Traits\Macroable, to use macro.
how to use the macro in dingo api

has solved ?


Barrows plugin improvements: highlights

I would like the barrows plugin to highlight two things: The region on the mound where you can dig and then the doors with with "Open" option in the tunnels. The former can be achieved with tile markers, but object markers apparently do not work on the later.

Duplicate of #4668
Duplicate of #2588


/data/ChallengeData2017/annotations_instance.tar is not found

I can not download dataset from server. Is the server under maintenance？

Thanks, we should be able to resolve it soon. @zhoubolei


sort case-insensitively and maintain pre-existing header classes

Maybe it would make sense to define a separate sort function for case-insensitive sorting. The current solution will break backwards compatibility and that might be something we want to avoid.
About that eslint error... Looks like it's due to ESLint 2.3.0. More info: https://github.com/babel/babel-eslint/issues/267 .

I fixed the master. It should lint correctly now. Do you want to rebase and force push the changes (feature branch so ok)?

What do you want to do with this?
My current thinking is that we should extract the sorting logic to a little npm package of its own and manage it there. That would be a good chance to sharpen the sort API.

Sorry I haven't had a chance to look at it yet. I think that is a good idea.

On 7 Jun 2016, at 23:39, Juho Vepsäläinen<EMAIL_ADDRESS>wrote:
What do you want to do with this?
My current thinking is that we should extract the sorting logic to a little npm package of its own and manage it there. That would be a good chance to sharpen the sort API.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.


add gpu resource driver helm chart

image: intel/intel-gpu-resource-driver:v0.2.0
crds files are added under crds folder

According to your previous pull request in this repo (#43 ), a License file is needed in this chart ?

@tkatila, @poussa do we need to add licenses for all Intel helm charts?

Most of the charts do not have it. But I don't think it hurts to have it.

Looks fine, but I wonder why YAML file contents are split differently from the project this is installing:
https://github.com/intel/intel-resource-drivers-for-kubernetes/tree/main/deployments/
Here class + parameters, defaults, and daemonset+deployment are in same file, although in driver repo they are all 3 in separate YAML files.  Whereas RBAC stuff is here in separate files but in driver repo in same file with deployments.
Wouldn't it be easier to check for changes and sync them, if k8s objects would be split similarly to separate files (and be in same order in them)?

Looks fine, but I wonder why YAML file contents are split differently from the project this is installing: https://github.com/intel/intel-resource-drivers-for-kubernetes/tree/main/deployments/
Here class + parameters, defaults, and daemonset+deployment are in same file, although in driver repo they are all 3 in separate YAML files. Whereas RBAC stuff is here in separate files but in driver repo in same file with deployments.
Wouldn't it be easier to check for changes and sync them, if k8s objects would be split similarly to separate files (and be in same order in them)?

I've been relying on the Helm chart available at dra-example-driver, which separates RBAC files and separately manages the deployments of the controller and kubelet-plugin.
I'm flexible and open to adapting to any upcoming changes. If the preference is to maintain all files individually, I'm ready to align with that approach.

I've been relying on the Helm chart available at dra-example-driver, which separates RBAC files and separately manages the deployments of the controller and kubelet-plugin.
I'm flexible and open to adapting to any upcoming changes. If the preference is to maintain all files individually, I'm ready to align with that approach.

I would think diffing / updating them would be easier if k8s objects in them are in same order and split to files with same names as in the original deployments for the driver it's installing.  That could be separate PR though.
@byako, any comments on what you prefer?


Fixed a race condition problem in migrations howto.

edited howto chapter "Migrations that add unique fields", how they are split to 3 migrations.

The first commit will fix the mentioned race condition. It is also more similar to a normal migration  that only value None is replaced by the default value, not overwritten if an existing field is migrated to null=False.

The second commit requires a discussion if it should be also applied:

pros: This method is easier memorable, linear without jumping back and forth. Model migrations are created automatically. Only the data migration is edited.

cons: It the problem was recognized late, this method requires to delete the migration file, not to edit it. That is controversial.

If you have created an invalid migration yet for that field then remove it. It will be replaced by three smaller migrations.

The migrations are finally the same, only the steps differs.
Number of non empty lines in howto is the same, but most of it is descriptive now and can be massively simplified, eventually by removing the two file snippets that are created automatically now.

My texts require language adjustment, please.

@carltongibson

Closing due to lack of follow up.


Feature request: mesh decimation

Some meshes output from IFermi have a very large number of triangles due to the resolution of the input, even if the resulting surface is actually not that complicated. For long-term storage of Fermi surfaces or retrieval over a web API, it would be helpful to be able to reduce the sizes of the meshes.
I've had a look what's out there and it looks like it's a common feature request in trimesh and is actively being worked on in sk-image: https://github.com/scikit-image/scikit-image/issues/4537
In the mean time, perhaps using the methods from vtk would be suitable, see here and here.
I might take a look at implementing this myself if there was interest in including this, but I don't have a lot of vtk experience so would have to see how IFermi is using vtk currently. I was imagining some sort of method on FermiSurface like decimate_mesh(factor).

Closed by #9 (thanks!)


glow chams

if you enable the glow chams and put the alpha 0, you will see a white model with the glow material

Yeah, someone guy already pm me this, at first this is base, so it shouldn't be very hard to fix it yourself!? (literally 1 line)
Ofc i'll push fix soon