Compile error in Linux Anaconda installation

I'm trying to install in an Anaconda environment using anaconda3/bin/pip install glove-python
I installed gcc and Cython via conda install -c anaconda and also tried following the steps set out in issue #96 [https://github.com/maciejkula/glove-python/issues/96#issuecomment-499840851]. In this case, running python3 setup.py install or make returns the following:
running install running bdist_egg running egg_info writing glove_python.egg-info/PKG-INFO writing dependency_links to glove_python.egg-info/dependency_links.txt writing requirements to glove_python.egg-info/requires.txt writing top-level names to glove_python.egg-info/top_level.txt reading manifest file 'glove_python.egg-info/SOURCES.txt' writing manifest file 'glove_python.egg-info/SOURCES.txt' installing library code to build/bdist.linux-x86_64/egg running install_lib running build_py running build_ext building 'glove.glove_cython' extension gcc -pthread -B /home/mrim/manniona/anaconda3/compiler_compat -Wl,--sysroot=/ -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/home/mrim/manniona/anaconda3/include/python3.7m -c glove/glove_cython.c -o build/temp.linux-x86_64-3.7/glove/glove_cython.o -fopenmp -ffast-math -march=native glove/glove_cython.c: In function ‘__pyx_pf_5glove_12glove_cython_fit_vectors._omp_fn.0’: glove/glove_cython.c:2447:29: warning: ‘__pyx_v_word_b’ may be used uninitialized in this function [-Wmaybe-uninitialized]                      #pragma omp for lastprivate(__pyx_v_count) lastprivate(__pyx_v_entry_weight) lastprivate(__pyx_v_gradient) lastprivate(__pyx_v_i) firstprivate(__pyx_v_j) lastprivate(__pyx_v_j) lastprivate(__pyx_v_learning_rate) lastprivate(__pyx_v_loss) lastprivate(__pyx_v_prediction) lastprivate(__pyx_v_shuffle_index) lastprivate(__pyx_v_word_a) lastprivate(__pyx_v_word_b) schedule(dynamic)                              ^ glove/glove_cython.c:2333:7: note: ‘__pyx_v_word_b’ was declared here    int __pyx_v_word_b;        ^ glove/glove_cython.c:2447:29: warning: ‘__pyx_v_word_a’ may be used uninitialized in this function [-Wmaybe-uninitialized]                      #pragma omp for lastprivate(__pyx_v_count) lastprivate(__pyx_v_entry_weight) lastprivate(__pyx_v_gradient) lastprivate(__pyx_v_i) firstprivate(__pyx_v_j) lastprivate(__pyx_v_j) lastprivate(__pyx_v_learning_rate) lastprivate(__pyx_v_loss) lastprivate(__pyx_v_prediction) lastprivate(__pyx_v_shuffle_index) lastprivate(__pyx_v_word_a) lastprivate(__pyx_v_word_b) schedule(dynamic)                              ^ glove/glove_cython.c:2332:7: note: ‘__pyx_v_word_a’ was declared here    int __pyx_v_word_a;        ^ glove/glove_cython.c:2447:29: warning: ‘__pyx_v_shuffle_index’ may be used uninitialized in this function [-Wmaybe-uninitialized]                      #pragma omp for lastprivate(__pyx_v_count) lastprivate(__pyx_v_entry_weight) lastprivate(__pyx_v_gradient) lastprivate(__pyx_v_i) firstprivate(__pyx_v_j) lastprivate(__pyx_v_j) lastprivate(__pyx_v_learning_rate) lastprivate(__pyx_v_loss) lastprivate(__pyx_v_prediction) lastprivate(__pyx_v_shuffle_index) lastprivate(__pyx_v_word_a) lastprivate(__pyx_v_word_b) schedule(dynamic)                              ^ glove/glove_cython.c:2342:7: note: ‘__pyx_v_shuffle_index’ was declared here    int __pyx_v_shuffle_index;        ^ glove/glove_cython.c:2447:29: warning: ‘__pyx_v_prediction’ may be used uninitialized in this function [-Wmaybe-uninitialized]                      #pragma omp for lastprivate(__pyx_v_count) lastprivate(__pyx_v_entry_weight) lastprivate(__pyx_v_gradient) lastprivate(__pyx_v_i) firstprivate(__pyx_v_j) lastprivate(__pyx_v_j) lastprivate(__pyx_v_learning_rate) lastprivate(__pyx_v_loss) lastprivate(__pyx_v_prediction) lastprivate(__pyx_v_shuffle_index) lastprivate(__pyx_v_word_a) lastprivate(__pyx_v_word_b) schedule(dynamic)                              ^ glove/glove_cython.c:2337:10: note: ‘__pyx_v_prediction’ was declared here    double __pyx_v_prediction;           ^ glove/glove_cython.c:2447:29: warning: ‘__pyx_v_loss’ may be used uninitialized in this function [-Wmaybe-uninitialized]                      #pragma omp for lastprivate(__pyx_v_count) lastprivate(__pyx_v_entry_weight) lastprivate(__pyx_v_gradient) lastprivate(__pyx_v_i) firstprivate(__pyx_v_j) lastprivate(__pyx_v_j) lastprivate(__pyx_v_learning_rate) lastprivate(__pyx_v_loss) lastprivate(__pyx_v_prediction) lastprivate(__pyx_v_shuffle_index) lastprivate(__pyx_v_word_a) lastprivate(__pyx_v_word_b) schedule(dynamic)                              ^ glove/glove_cython.c:2339:10: note: ‘__pyx_v_loss’ was declared here    double __pyx_v_loss;           ^ glove/glove_cython.c:2447:29: warning: ‘__pyx_v_learning_rate’ may be used uninitialized in this function [-Wmaybe-uninitialized]                      #pragma omp for lastprivate(__pyx_v_count) lastprivate(__pyx_v_entry_weight) lastprivate(__pyx_v_gradient) lastprivate(__pyx_v_i) firstprivate(__pyx_v_j) lastprivate(__pyx_v_j) lastprivate(__pyx_v_learning_rate) lastprivate(__pyx_v_loss) lastprivate(__pyx_v_prediction) lastprivate(__pyx_v_shuffle_index) lastprivate(__pyx_v_word_a) lastprivate(__pyx_v_word_b) schedule(dynamic)                              ^ glove/glove_cython.c:2335:10: note: ‘__pyx_v_learning_rate’ was declared here    double __pyx_v_learning_rate;           ^ glove/glove_cython.c:2447:29: warning: ‘__pyx_v_i’ may be used uninitialized in this function [-Wmaybe-uninitialized]                      #pragma omp for lastprivate(__pyx_v_count) lastprivate(__pyx_v_entry_weight) lastprivate(__pyx_v_gradient) lastprivate(__pyx_v_i) firstprivate(__pyx_v_j) lastprivate(__pyx_v_j) lastprivate(__pyx_v_learning_rate) lastprivate(__pyx_v_loss) lastprivate(__pyx_v_prediction) lastprivate(__pyx_v_shuffle_index) lastprivate(__pyx_v_word_a) lastprivate(__pyx_v_word_b) schedule(dynamic)                              ^ glove/glove_cython.c:2340:7: note: ‘__pyx_v_i’ was declared here    int __pyx_v_i;        ^ glove/glove_cython.c:2447:29: warning: ‘__pyx_v_gradient’ may be used uninitialized in this function [-Wmaybe-uninitialized]                      #pragma omp for lastprivate(__pyx_v_count) lastprivate(__pyx_v_entry_weight) lastprivate(__pyx_v_gradient) lastprivate(__pyx_v_i) firstprivate(__pyx_v_j) lastprivate(__pyx_v_j) lastprivate(__pyx_v_learning_rate) lastprivate(__pyx_v_loss) lastprivate(__pyx_v_prediction) lastprivate(__pyx_v_shuffle_index) lastprivate(__pyx_v_word_a) lastprivate(__pyx_v_word_b) schedule(dynamic)                              ^ glove/glove_cython.c:2336:10: note: ‘__pyx_v_gradient’ was declared here    double __pyx_v_gradient;           ^ glove/glove_cython.c:2447:29: warning: ‘__pyx_v_entry_weight’ may be used uninitialized in this function [-Wmaybe-uninitialized]                      #pragma omp for lastprivate(__pyx_v_count) lastprivate(__pyx_v_entry_weight) lastprivate(__pyx_v_gradient) lastprivate(__pyx_v_i) firstprivate(__pyx_v_j) lastprivate(__pyx_v_j) lastprivate(__pyx_v_learning_rate) lastprivate(__pyx_v_loss) lastprivate(__pyx_v_prediction) lastprivate(__pyx_v_shuffle_index) lastprivate(__pyx_v_word_a) lastprivate(__pyx_v_word_b) schedule(dynamic)                              ^ glove/glove_cython.c:2338:10: note: ‘__pyx_v_entry_weight’ was declared here    double __pyx_v_entry_weight;           ^ glove/glove_cython.c:2447:29: warning: ‘__pyx_v_count’ may be used uninitialized in this function [-Wmaybe-uninitialized]                      #pragma omp for lastprivate(__pyx_v_count) lastprivate(__pyx_v_entry_weight) lastprivate(__pyx_v_gradient) lastprivate(__pyx_v_i) firstprivate(__pyx_v_j) lastprivate(__pyx_v_j) lastprivate(__pyx_v_learning_rate) lastprivate(__pyx_v_loss) lastprivate(__pyx_v_prediction) lastprivate(__pyx_v_shuffle_index) lastprivate(__pyx_v_word_a) lastprivate(__pyx_v_word_b) schedule(dynamic)                              ^ glove/glove_cython.c:2334:10: note: ‘__pyx_v_count’ was declared here    double __pyx_v_count;           ^ gcc -pthread -shared -B /home/mrim/manniona/anaconda3/compiler_compat -L/home/mrim/manniona/anaconda3/lib -Wl,-rpath=/home/mrim/manniona/anaconda3/lib -Wl,--no-as-needed -Wl,--sysroot=/ build/temp.linux-x86_64-3.7/glove/glove_cython.o -o build/lib.linux-x86_64-3.7/glove/glove_cython.cpython-37m-x86_64-linux-gnu.so -fopenmp /home/mrim/manniona/anaconda3/compiler_compat/ld: cannot find -lpthread /home/mrim/manniona/anaconda3/compiler_compat/ld: cannot find -lc collect2: error: ld returned 1 exit status error: command 'gcc' failed with exit status 1
And I still get the following error from anaconda3/bin/pip install glove-python:
`Collecting glove-python
Using cached https://files.pythonhosted.org/packages/3e/79/7e7e548dd9dcb741935d031117f4bed133276c2a047aadad42f1552d1771/glove_python-0.1.0.tar.gz
Requirement already satisfied: numpy in ./anaconda3/lib/python3.7/site-packages (from glove-python) (1.17.2)
Requirement already satisfied: scipy in ./anaconda3/lib/python3.7/site-packages (from glove-python) (1.3.1)
Building wheels for collected packages: glove-python
Building wheel for glove-python (setup.py) ... error
ERROR: Command errored out with exit status 1:
command: /home/mrim/manniona/anaconda3/bin/python -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-xqc8h49a/glove-python/setup.py'"'"'; file='"'"'/tmp/pip-install-xqc8h49a/glove-python/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(file);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, file, '"'"'exec'"'"'))' bdist_wheel -d /tmp/pip-wheel-fskh814v --python-tag cp37
cwd: /tmp/pip-install-xqc8h49a/glove-python/
Complete output (82 lines):
running bdist_wheel
running build
running build_py
creating build
creating build/lib.linux-x86_64-3.7
creating build/lib.linux-x86_64-3.7/glove
copying glove/corpus.py -> build/lib.linux-x86_64-3.7/glove
copying glove/init.py -> build/lib.linux-x86_64-3.7/glove
copying glove/glove.py -> build/lib.linux-x86_64-3.7/glove
running build_ext
building 'glove.glove_cython' extension
creating build/temp.linux-x86_64-3.7
creating build/temp.linux-x86_64-3.7/glove
gcc -pthread -B /home/mrim/manniona/anaconda3/compiler_compat -Wl,--sysroot=/ -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/home/mrim/manniona/anaconda3/include/python3.7m -c glove/glove_cython.c -o build/temp.linux-x86_64-3.7/glove/glove_cython.o -fopenmp -ffast-math -march=native
glove/glove_cython.c: In function ‘__Pyx_ExceptionSave’:
glove/glove_cython.c:16753:19: error: ‘PyThreadState’ has no member named ‘exc_type’
*type = tstate->exc_type;
^
glove/glove_cython.c:16754:20: error: ‘PyThreadState’ has no member named ‘exc_value’
*value = tstate->exc_value;
^
glove/glove_cython.c:16755:17: error: ‘PyThreadState’ has no member named ‘exc_traceback’
*tb = tstate->exc_traceback;
^
glove/glove_cython.c: In function ‘__Pyx_ExceptionReset’:
glove/glove_cython.c:16767:22: error: ‘PyThreadState’ has no member named ‘exc_type’
tmp_type = tstate->exc_type;
^
glove/glove_cython.c:16768:23: error: ‘PyThreadState’ has no member named ‘exc_value’
tmp_value = tstate->exc_value;
^
glove/glove_cython.c:16769:20: error: ‘PyThreadState’ has no member named ‘exc_traceback’
tmp_tb = tstate->exc_traceback;
^
glove/glove_cython.c:16770:11: error: ‘PyThreadState’ has no member named ‘exc_type’
tstate->exc_type = type;
^
glove/glove_cython.c:16771:11: error: ‘PyThreadState’ has no member named ‘exc_value’
tstate->exc_value = value;
^
glove/glove_cython.c:16772:11: error: ‘PyThreadState’ has no member named ‘exc_traceback’
tstate->exc_traceback = tb;
^
glove/glove_cython.c: In function ‘__Pyx_GetException’:
glove/glove_cython.c:16815:22: error: ‘PyThreadState’ has no member named ‘exc_type’
tmp_type = tstate->exc_type;
^
glove/glove_cython.c:16816:23: error: ‘PyThreadState’ has no member named ‘exc_value’
tmp_value = tstate->exc_value;
^
glove/glove_cython.c:16817:20: error: ‘PyThreadState’ has no member named ‘exc_traceback’
tmp_tb = tstate->exc_traceback;
^
glove/glove_cython.c:16818:11: error: ‘PyThreadState’ has no member named ‘exc_type’
tstate->exc_type = local_type;
^
glove/glove_cython.c:16819:11: error: ‘PyThreadState’ has no member named ‘exc_value’
tstate->exc_value = local_value;
^
glove/glove_cython.c:16820:11: error: ‘PyThreadState’ has no member named ‘exc_traceback’
tstate->exc_traceback = local_tb;
^
glove/glove_cython.c: In function ‘__Pyx_ExceptionSwap’:
glove/glove_cython.c:16842:22: error: ‘PyThreadState’ has no member named ‘exc_type’
tmp_type = tstate->exc_type;
^
glove/glove_cython.c:16843:23: error: ‘PyThreadState’ has no member named ‘exc_value’
tmp_value = tstate->exc_value;
^
glove/glove_cython.c:16844:20: error: ‘PyThreadState’ has no member named ‘exc_traceback’
tmp_tb = tstate->exc_traceback;
^
glove/glove_cython.c:16845:11: error: ‘PyThreadState’ has no member named ‘exc_type’
tstate->exc_type = *type;
^
glove/glove_cython.c:16846:11: error: ‘PyThreadState’ has no member named ‘exc_value’
tstate->exc_value = *value;
^
glove/glove_cython.c:16847:11: error: ‘PyThreadState’ has no member named ‘exc_traceback’
tstate->exc_traceback = *tb;
^
error: command 'gcc' failed with exit status 1
ERROR: Failed building wheel for glove-python
Running setup.py clean for glove-python
ERROR: Command errored out with exit status 1:
command: /home/mrim/manniona/anaconda3/bin/python -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-xqc8h49a/glove-python/setup.py'"'"'; file='"'"'/tmp/pip-install-xqc8h49a/glove-python/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(file);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, file, '"'"'exec'"'"'))' clean --all
cwd: /tmp/pip-install-xqc8h49a/glove-python
Complete output (6 lines):
usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
or: setup.py --help [cmd1 cmd2 ...]
or: setup.py --help-commands
or: setup.py cmd --help
error: option --all not recognized
ERROR: Failed cleaning build dir for glove-python
Failed to build glove-python
Installing collected packages: glove-python
Running setup.py install for glove-python ... error
ERROR: Command errored out with exit status 1:
command: /home/mrim/manniona/anaconda3/bin/python -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-xqc8h49a/glove-python/setup.py'"'"'; file='"'"'/tmp/pip-install-xqc8h49a/glove-python/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(file);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, file, '"'"'exec'"'"'))' install --record /tmp/pip-record-orwjmsvp/install-record.txt --single-version-externally-managed --compile
cwd: /tmp/pip-install-xqc8h49a/glove-python/
Complete output (74 lines):
running install
running build
running build_py
running build_ext
building 'glove.glove_cython' extension
gcc -pthread -B /home/mrim/manniona/anaconda3/compiler_compat -Wl,--sysroot=/ -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/home/mrim/manniona/anaconda3/include/python3.7m -c glove/glove_cython.c -o build/temp.linux-x86_64-3.7/glove/glove_cython.o -fopenmp -ffast-math -march=native
glove/glove_cython.c: In function ‘__Pyx_ExceptionSave’:
glove/glove_cython.c:16753:19: error: ‘PyThreadState’ has no member named ‘exc_type’
*type = tstate->exc_type;
^
glove/glove_cython.c:16754:20: error: ‘PyThreadState’ has no member named ‘exc_value’
*value = tstate->exc_value;
^
glove/glove_cython.c:16755:17: error: ‘PyThreadState’ has no member named ‘exc_traceback’
*tb = tstate->exc_traceback;
^
glove/glove_cython.c: In function ‘__Pyx_ExceptionReset’:
glove/glove_cython.c:16767:22: error: ‘PyThreadState’ has no member named ‘exc_type’
tmp_type = tstate->exc_type;
^
glove/glove_cython.c:16768:23: error: ‘PyThreadState’ has no member named ‘exc_value’
tmp_value = tstate->exc_value;
^
glove/glove_cython.c:16769:20: error: ‘PyThreadState’ has no member named ‘exc_traceback’
tmp_tb = tstate->exc_traceback;
^
glove/glove_cython.c:16770:11: error: ‘PyThreadState’ has no member named ‘exc_type’
tstate->exc_type = type;
^
glove/glove_cython.c:16771:11: error: ‘PyThreadState’ has no member named ‘exc_value’
tstate->exc_value = value;
^
glove/glove_cython.c:16772:11: error: ‘PyThreadState’ has no member named ‘exc_traceback’
tstate->exc_traceback = tb;
^
glove/glove_cython.c: In function ‘__Pyx_GetException’:
glove/glove_cython.c:16815:22: error: ‘PyThreadState’ has no member named ‘exc_type’
tmp_type = tstate->exc_type;
^
glove/glove_cython.c:16816:23: error: ‘PyThreadState’ has no member named ‘exc_value’
tmp_value = tstate->exc_value;
^
glove/glove_cython.c:16817:20: error: ‘PyThreadState’ has no member named ‘exc_traceback’
tmp_tb = tstate->exc_traceback;
^
glove/glove_cython.c:16818:11: error: ‘PyThreadState’ has no member named ‘exc_type’
tstate->exc_type = local_type;
^
glove/glove_cython.c:16819:11: error: ‘PyThreadState’ has no member named ‘exc_value’
tstate->exc_value = local_value;
^
glove/glove_cython.c:16820:11: error: ‘PyThreadState’ has no member named ‘exc_traceback’
tstate->exc_traceback = local_tb;
^
glove/glove_cython.c: In function ‘__Pyx_ExceptionSwap’:
glove/glove_cython.c:16842:22: error: ‘PyThreadState’ has no member named ‘exc_type’
tmp_type = tstate->exc_type;
^
glove/glove_cython.c:16843:23: error: ‘PyThreadState’ has no member named ‘exc_value’
tmp_value = tstate->exc_value;
^
glove/glove_cython.c:16844:20: error: ‘PyThreadState’ has no member named ‘exc_traceback’
tmp_tb = tstate->exc_traceback;
^
glove/glove_cython.c:16845:11: error: ‘PyThreadState’ has no member named ‘exc_type’
tstate->exc_type = *type;
^
glove/glove_cython.c:16846:11: error: ‘PyThreadState’ has no member named ‘exc_value’
tstate->exc_value = *value;
^
glove/glove_cython.c:16847:11: error: ‘PyThreadState’ has no member named ‘exc_traceback’
tstate->exc_traceback = *tb;
^
error: command 'gcc' failed with exit status 1
----------------------------------------
ERROR: Command errored out with exit status 1: /home/mrim/manniona/anaconda3/bin/python -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-xqc8h49a/glove-python/setup.py'"'"'; file='"'"'/tmp/pip-install-xqc8h49a/glove-python/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(file);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, file, '"'"'exec'"'"'))' install --record /tmp/pip-record-orwjmsvp/install-record.txt --single-version-externally-managed --compile Check the logs for full command output.`

/home/mrim/manniona/anaconda3/compiler_compat/ld: cannot find -lpthread /home/mrim/manniona/anaconda3/compiler_compat/ld: cannot find -lc

You seem to be missing libpthread and libc. Try installing them using your Linux distro's package manager.

I've the exact same error and I've no luck with installing these two packages on ubuntu:

libpthread-stubs0-dev
libc6-dev

Any other packages needed to be installed?

@jk does compilation still not work with those libs installed?
Which ubuntu version? Which python version?

@jk does compilation still not work with those libs installed?
Sadly yes, I doesn't work

Which ubuntu version? Which python version?
Ubuntu: 18.04
Python 2.7.17 und 3.7.6

I'm building a Docker Image here, so you can take a look: https://gist.github.com/jk/dbdd67adb4e703f7f6d89587bbcee73a

@jk your anaconda installation is python 3.7 so some of the glove-python files need to be re-compiled.

Remove glove_python from your environment.yaml
Add these lines to your Dockerfile immediately after creating the conda env:

# Download glove
RUN curl -o glove_python.zip -OL https://github.com/maciejkula/glove-python/archive/master.zip
RUN unzip glove_python.zip
# Re-compile cython code
WORKDIR /glove-python-master
RUN /opt/conda/envs/wiki/bin/cythonize -X language_level=3 -f -i glove/corpus_cython.pyx
RUN /opt/conda/envs/wiki/bin/cythonize -X language_level=3 -f -i glove/glove_cython.pyx
RUN /opt/conda/envs/wiki/bin/cythonize -X language_level=3 -f -i glove/metrics/accuracy_cython.pyx
# Install glove-python
RUN /opt/conda/envs/wiki/bin/pip install .

@IronFarm I really appreciate your quick response. It now works, thanks a lot.
A short remark, if someone else also wants to use this:
I've updated the gist: https://gist.github.com/jk/dbdd67adb4e703f7f6d89587bbcee73a#file-dockerfile-L40-L50
RUN cd /tmp \
  && curl -o glove_python.zip -OL https://github.com/maciejkula/glove-python/archive/master.zip \
  && unzip glove_python.zip \
  && rm -f glove_python.zip \
  && cd glove-python-master \
  && /opt/conda/envs/wiki/bin/cythonize -X language_level=3 -f -i glove/corpus_cython.pyx \
  && /opt/conda/envs/wiki/bin/cythonize -X language_level=3 -f -i glove/glove_cython.pyx \
  && /opt/conda/envs/wiki/bin/cythonize -X language_level=3 -f -i glove/metrics/accuracy_cython.pyx \
  && /opt/conda/envs/wiki/bin/pip install . \
  && cd .. \
  && rm -rf glove-python-master

Better write it like that. It only adds one layer to the docker image and saves some disk space, when removing unnecessary files within the same layer (files can't be removed in following layers).

Glad to have helped and thanks for the mini-docker tutorial in return 😄


Release files tidy up

On a full version release there are 19 files published on the draft GitHub release:

alpha-linux.yml
alpha-mac.yml
alpha.yml
beta-linux.yml
beta-mac.yml
beta.yml
latest-linux.yml
latest-mac.yml
latest.yml
com.electron.safe-browser.plist
safe-browser-v0.15.4-beta.2-linux-x64.AppImage
safe-browser-v0.15.4-beta.2-linux-x64.zip
safe-browser-v0.15.4-beta.2-mac-x64.dmg
safe-browser-v0.15.4-beta.2-mac-x64.dmg.blockmap
safe-browser-v0.15.4-beta.2-mac-x64.pkg
safe-browser-v0.15.4-beta.2-mac-x64.zip
safe-browser-v0.15.4-beta.2-win-x64.exe
safe-browser-v0.15.4-beta.2-win-x64.exe.blockmap
safe-browser-v0.15.4-beta.2-win-x64.msi

From what I can see looking at the previous release (0.15.3) there are a couple of files produced here that are not used - numbers 10 and 19.
Any need to publish either of these?
Going by previous releases, once the 17 files are copied to S3, the GitHub release can be cut to only contain 3 release files:

safe-browser-v0.15.4-beta.2-linux-x64.AppImage
safe-browser-v0.15.4-beta.2-mac-x64.dmg
safe-browser-v0.15.4-beta.2-win-x64.exe
Can this be done as part of CI?

Another tidy up task on S3 would be to remove all previous Alpha & Beta files - once this new version is available they are no longer required.
One last request on this card is to ensure that all the files published to S3 are actually required. E.g. is the safe-browser-v0.15.4-beta.2-mac-x64.zip file ever used? If there are any that are now surplus, as the .msi file appears to be, let's take the opportunity to remove them.

zip files are used as part of autoupdate aye  👍

Above PR does most of this.
Missing things:

Mac e2e on GHA. We still use travis for this only.
Any s3 management of files (ie deleting old things). I'm unsure what sort of margin we should give. But maybe just delete anything older than a couple months maybe? I'd opt for that in another PR though @S-Coyle

@joshuef

Happy to stick with macOS e2e in Travis for now, hopefully come across a resolution for this in future - worth switching the rest over anyway for the numerous benefits that provides.
Agree about anything older than a couple of months being deleted, though need to be careful with this as can't just delete everything in the folder older that a certain time frame, e.g. that could delete a .yml files as they could well be older than that, or another example is that it could delete the latest full release files if it's only been Alpha & Beta releases in that time frame.

Closing legacy issues - Current released files are adequate


Feature management

Description
Adds Feature Management to spring-cloud-azure. There are two packages being added spring-cloud-azure-feature-management and spring-cloud-azure-feature-management-web.

Codecov Report

Merging #539 into master will increase coverage by 0.87%.
The diff coverage is 84.88%.

@@             Coverage Diff              @@
##             master     #539      +/-   ##
============================================
+ Coverage     54.78%   55.66%   +0.87%
- Complexity      673      711      +38
============================================
  Files           162      169       +7
  Lines          2970     3056      +86
  Branches        172      184      +12
============================================
+ Hits           1627     1701      +74
- Misses         1224     1232       +8
- Partials        119      123       +4

Impacted Files
Coverage Δ
Complexity Δ

...re/spring/cloud/feature/manager/FeatureConfig.java
0% <0%> (ø)
0 <0> (?)

.../cloud/feature/manager/FeatureManagerSnapshot.java
100% <100%> (ø)
3 <3> (?)

...nager/entities/FeatureFilterEvaluationContext.java
100% <100%> (ø)
5 <5> (?)

...spring/cloud/feature/manager/entities/Feature.java
100% <100%> (ø)
7 <7> (?)

...e/spring/cloud/feature/manager/FeatureManager.java
80.76% <80.76%> (ø)
10 <10> (?)

...e/spring/cloud/feature/manager/FeatureHandler.java
86.95% <86.95%> (ø)
9 <9> (?)

...ing/cloud/feature/manager/entities/FeatureSet.java
87.5% <87.5%> (ø)
4 <4> (?)

... and 5 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 cc4a1b8...35b946d. Read the comment docs.


emqttd_cm and emqttd_sm demonitor

In emqttd_cm:erase_monitor/2 and emqttd_sm:erase_monitor/2
erase_monitor(MRef, State = #state{monitors = Monitors}) ->
    State#state{monitors = dict:erase(MRef, Monitors)}.

I think it better if demonitor MRef before dict:erase, like this:
erase_monitor(MRef, State = #state{monitors = Monitors}) ->
    erlang:demonitor(MRef),
    State#state{monitors = dict:erase(MRef, Monitors)}.

Hi @congleetea, the 'erase_monitor/2' function is usually called after the process received {'DOWN', MonitorRef, _, _, _} message. So is it necessary to erlang:demonitor/1 the reference?

I think it is more standard when  erlang:demonitor/1.

@congleetea Fixed in 2.3.0 release. Close the issue now.


Feature request - Support for symlinks

Hi,
I would like to propose a feature request. My project structure looks as following:
/module-a
    pom.xml
    Dockerfile
/module-...
    ...
/scripts
    /postgres
    /rabbitmq
    /redis
    /elasticsearch
    /...
pom.xml

In module-a, I am using spotify/dockerfile-maven to build a Docker image. I would like to include resources from /scripts, so I can copy them to the docker image. More concrete, it would be useful if I could create a symlink from module-a/postgres to ../scripts/postgres (for example) and add COPY postgres / to the Dockerfile.
I know this is by default not supported by Docker, for various reasons. But still, it would  be useful if this could be supported by spotify/dockerfile-maven. There is an approach to achieve this quite easily. You could build the image as following:
tar -czh . | docker build -t <image:tag> - (instead of docker build -t <image:tag> .)
This resolves all links, packages the working directory and then pipes this directory to the Docker build target. In the Dockerfile, you can then do COPY postgres /.
What do you think?
Thank you!

Thanks for the suggestion. I would be wary of adding something that isn’t supported by Docker or that would mean that a docker build from the command-line on the same Dockerfile and context directory wouldn’t function.

Closing: as an afterthought, I agree with @mattnworb!


Adding a version label to controller and webhook 🏋

Changes
According to Istio guidelines1, deployments should have an app and
version label. Adding a version label to the Tekton Pipelines
deployments would make it easy to verify what version of Tekton
Pipelines is running.
This only adds version to follow istio's guideline :wink:
Closes #1919
Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:

[ ] Includes tests (if functionality changed/added)
[ ] Includes docs (if user facing)
[x] Commit messages follow commit message best practices

See the contribution guide for more details.
Double check this list of stuff that's easy to miss:

If you are adding a new binary/image to the cmd dir, please update
the release Task to build and release this image.

Reviewer Notes
If API changes are included, additive changes must be approved by at least two OWNERS and backwards incompatible changes must be approved by more than 50% of the OWNERS, and they must first be added in a backwards compatible way.

/lgtm


[Network Application Gateway] loadDistributionPolicies cannot be set by default

When creating a new Application Gateway with loadDistributionPolicies, I got the following error.
Since this property is already used in the example of MS-DOC, can it be configurable by public users by default?
Kindly help confirm this issue. Thanks.
{
    "error": {
        "code": "SubscriptionNotRegisteredForFeature",
        "message": "Subscription /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups//providers/Microsoft.Network/subscriptions/ is not registered for feature LoadDistributionPolicy required to carry out the requested operation.",
        "details": []
    }
}

LoadDisctibutionPolicy (LDP) feature of ApplicationGateway is not publicly available as of now. At this point of time, this feature can only be used by subscriptions which are registered for this feature. Subscription used in this case is not registered for this feature and therefore, getting this error.

LoadDisctibutionPolicy (LDP) feature of ApplicationGateway is not publicly available as of now.

Some feedback that I have provided to Microsoft via different channels is that "active-passive" load balancing is a missing feature in Application Gateway. Some legacy applications require this, and is also often used with licensed applications that provide "free" HA/DR passive secondary licenses.
This feature is very close to what would be required for active-passive support. It just needs the "1..100" weight per server range changed to "0..100", which would direct all traffic to the primary backend pool unless it is down completely.
Alternatively, it would be even better to have a priority+weight type of configuration, similarly to how Azure Front Door does it.


Export all save directory

When you use the command Export all and choose the save directory.
The Map images do not get exported to chosen save directory. They get copied into the Export folder.

The "choose where to save" option was supposed to go away a long time ago
On Sat, Feb 9, 2019 at 1:40 PM Lucky<EMAIL_ADDRESS>wrote:

When you use the command Export all and choose the save directory.
The Map images do not get exported to chosen save directory. They get
copied into the Export folder.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/GrapeshotGames/ServerGridEditor/issues/62, or mute
the thread
https://github.com/notifications/unsubscribe-auth/Ah5OQxXeV0Vk-ft0ztQjRXzzfC9ygEJQks5vLyQ3gaJpZM4aytDV
.

Why would that be the case?


Create - task_messenger

todo

[ ] Create task_messenger

@input :package: serapath_discord_msg
[x] Project setup
[x] Task messenger base code
@output :package: task_messenger_v0.0.1 from comment

[ ] Update task_messenger_v0.0.1

@input :package: task_messenger_v0.0.1 from comment
@input :package: david_mobile_v0.0.4
[x] Added chat log
[x] Improved create operation
[x] Added open chat operation
[x] Added task communication between users
[x] Added chat communication between users
[x] Improved UX
@output :package: task_messenger_v0.0.2 from comment

[ ] Update task_messenger_v0.0.2

@input :package: task_explorer_v0.0.1 from comment
@input :package: task_messenger_v0.0.2 from comment
[x] Divided into subcomponent task_explorer
[x] Improved UX - '35min`
[x] Added custom access to data
[x] Added sharing on invite
@output :package: task_messenger_v0.0.3 from comment

[ ] Update task_messenger_v0.0.3

@input :package: task_messenger_v0.0.3 from comment
[x] Updated chat log data structure
[x] Eliminating duplication
[x] Update naming
[x] Refactoring
[x] Repeated above for list architecture
@output :package: task_messenger_v0.0.4 from comment

tasks - 2024.04.04

Create task_messenger(https://discord.com/channels/859134561018839060/1225189537534447668/1225201366318846075)

Project setup - 30min
Task messenger base code - 1h20min
Logged tasks - 10min
Record worklog - 10min
@output :package: task_messenger_v0.0.1]

worklog

feedback 2024.04.04
good job :-)
i think all these tasks you mention are great, but i would start with the "addition of chat log" and "communication between users" and then "CRUD for task" :-)
The communication probably needs a link to be copy/pasted for other users to join. I would say clicking a task should display that link in the or task room title bar or something like that.
The level or depths of task tree can be infinite.
As deep as a user likes.
Important task is that a single "task" in the tree can have multiple parents. There are examples of that sketched in the old issue 56 https://github.com/wizardamigos/wizardamigos.github.io/issues/56
For example towards the end of this feedback comment
https://github.com/wizardamigos/wizardamigos.github.io/issues/56#issuecomment-1193397302
and again here
https://github.com/wizardamigos/wizardamigos.github.io/issues/56#issuecomment-1207523567
I do think we will need to go through these old worklogs and feedback comments a lot.
Please try to read through it over time top to bottom, as it will likely answer many questions about many details and then we can still discuss :-)

tasks - 2024.04.05

Update task_messenger_v0.0.1

Added chat log - 45min
Improved create operation - 20min
Added open chat operation - 20min
Added task communication between users - 1h
Added chat communication between users - 30min
Improved UX - 10min
Logged tasks - 5min
Created worklog - 10min
@outpu :package: task_messenger_v0.0.2

worklog

feedback

feedback 2024.04.05
Looks good. It's a bit buggy for me, but i see the progress.
I personally would prefer action buttons and task tree below the chat window (basically next to the input window.
In fact - the task tree could collapse to the currently selected task and when clicked, expands like a dropdown/dropup menu to show the whole task tree.
The action buttons are also on the bottom next to the input field and change or adapt based on the selected task.
Regarding multiple parents, this is already drawn in the comments i linked. I will link them here again, but you have to read them to the end and see the emoji-asci drawings.

have in mind it tries to model out "github issue task management system"

Have you checked those specific linked feedback comments from my last feedback? Here they are again - especially towards the end of each long feedback comment

https://github.com/wizardamigos/wizardamigos.github.io/issues/56#issuecomment-1193397302
https://github.com/wizardamigos/wizardamigos.github.io/issues/56#issuecomment-1207523567

Your proposal tasks sound good. let's do them, but let's also take extra care for having the things you already implenmented "bug free" :-)

todo - 2024.04.08

Update task_messenger_v0.0.2

Divided into subcomponent task_explorer - 1h
Improved UX - '35min`
Added custom access to data - 25min
Added sharing on invite - 1h
Logged tasks - 7min
Record worklog - 13min
@output :package: task_messenger_v0.0.3

worklog
worklog-203

feedback 2024.04.13
The feedback for this worklog is part of this comment:
https://github.com/serapath/task-messenger/issues/4#issuecomment-2053739842

tasks - 2024.05.02

Update task_messenger_v0.0.3

Updated chat log data structure - 1h20min
Eliminating duplication - 20min
Update naming - 30min
Refactoring - 30min
Repeated above for list architecture - 1h
Logged tasks - 10min
Recorded worklog - 20min
@output :package: task_messenger_v0.0.4

worklog
worklog-208

feedback 2024.05.05 (1/2)
First the refactoring feedback.
refactoring
1. data structure
+1 for generating a separate file for each peer (e.g. data_bob.json, data_ana.json)
todo: these files should later be generated from the DB module instances peers use. The DB module stores in localStorage and if we clear localStorage, we can import the data from an exported json file to restore it.

{
  rooms: {
    '': [{ head: '', type: '', data: 'hello', meta: { date:<PHONE_NUMBER>5235 }}]
    'bob': [{ head: '', type: '', data: 'hi', meta: { date:<PHONE_NUMBER>5289 }}]
  }
}

todo: it should be called message.meta.date not "data". This was my mistake in the old feedback. sorry :-)
todo: great that it sorts by date, but it should also respect message.refs.cause. A reply to m0 "hello" might say "hi" in m1 and have m1.refs.cause pointing to m0.head
old feedback:
message.refs[name] = head

It might be good to be able to e.g. "highlight" other messages in the log,
if they were contained by a message via "message.refs" heads.
Think of normal messenger when you "reply" to a message.
Or maybe it just highlights previous messages when you click a specific message
Or maybe you can press a button to "collapse" all message which are not in the
"message.refs" chain of a particular message (directly or indirectly).
SORTING: based on topological sorting + date based + red markers when date + topological dont agree

old feedback:

TASKS[273].room = { '': [m0], [ana_ID]: [] }
m0 is message0 when bob creates task 273 and contains infos
e.g. m0.data contains the arguments passed to creating task 273 initially

this seems to be missing. When a fresh task is created, it should have at least one message in the chat log of the person who created the task, which is a system message with the parameter arguments which were used when creating the task.
todo: add missing first message when creating a room
2. container for elements
3. code deduplication

thank you for explaining.
my feedback on that would be what i did with "render" message function
-> there were 2 different functions which had the same code
--> so i copied that same code into render function and replaced
the code in those 2 different function with a call to render instead
In the screenshot you see line 163-166 of add_node_sub
is almost identically with line 137-140 of add_node_root
const space = ''
const grand_last = last ? 'a' : ''
const prefix = last ? '' : ''
const opts = { space, prefix, grand_last }
const element = html_template(opts) // for example

The idea is to make a function, e.g. html_template where everything that is the same goes inside that function and everything that is different goes inside of the parameters which are passed to the function
Anyway, one thing that would be good if we at least turn event handler into functions:
// e.g.
 inp.onclick = () => {
    if(inp_open){
      inp.innerHTML = '🗃'
      out_open ? out.innerHTML =
      //...
    }
 }
// becomes
 inp.onclick = inp_onclick
 return
 function inp_onclick (event) {
   if (inp_open) {
     inp.innerHTML = '🗃'
     out_open ? out.innerHTML =
     // ...
   }
 }
// that way reading becomes a bit easier

opts refactoring
https://github.com/serapath/task-messenger/blob/062c3b8fb439ca871e2440503360d39699e028b8/src/index.js#L75-L93
The opts variable is also still the same as it was, even though it was mentioned in the feedback.

@alyhxn could you at the end of your work and before recording the next worklog always double check the last feedback to see if anything is missing or was forgotten? that would be sweet :-)

feedback 2024.05.05 (2/2)
I watched the tree vs list architecture as well.
I understand the differences.
The issue is, that based on this we would pick the tree architecture for sure, but the thing is having not just many nodes (e.g. 100 tasks each with 100 sub tasks, each with 10 subtasks, etc... let's say 4 levels deep.)
That's 1000 * 100 * 10 * 10 = 10_000_000 tasks
On my computer, a loop with so many tasks
{
  var t0 = performance.now()
  var x = 0
  for (var i = 10_000_000; i--;) {
    x += i
  }
  console.log(x)
  var t1 = performance.now()
  console.log(t1 - t0)
}

Takes ~300ms to run.
So we can increase some task levels to make it take 2-3 seconds or even 30 seconds.
And then we can benchmark our task messenger structure to see that completly removing and adding tasks nodes to the DOM keeps constant performance, regardless of the amount of tasks. And it also keeps constant memory footprint.
These things can also be inspected in the developer tools and i can share some resources how that is being done.

about architecture list vs tree
When it comes to removing nodes from the dom and adding them back in while lazy loading them on scrolling, the architecture might become more relevant and it might be more easy with a list - so comparing that and also measuring the real performance difference should be our indicator for choosing architecture :-)
In order to perfectly support loading and unloading requires task infos from the database based on scroll position, we need to optimize our infrastructure IO and DB, because those might need to be restored as well and performance will only be smooth if IO and DB are optimized for these requirements, so this will take some little "detour" before we can get back into the task messenger and continue the actually "task explorer" and "task messenge" work, but it will pay off in the long run and we are here for highest quality standards and the long run, so no need to rush it, but rather to be really really thorough to get the "best in class" quality :-)

tasks - 2024.05.07

Update task_messenger_v0.0.4

Added reply feature in chat - 1h15min
Added first message when creating a room - 30min
Deduplication - 15min
Logged tasks - 5min
Recorded worklog - 15min
@output :package: task_messenger_v0.0.5

worklogs
worklog-210

feedback 2024.05.07
Thanks. Looks like a good worklog. Here some additional feedback:
1. later todos
it would be good if all the tasks you spot that are for "some time later" would be added as todos in the top level comment of the issue, so we wont forget them :slight_smile:
that way, the top level issue can slowly collect tasks and sub tasks to represent our future plans and roadmap for where we wanna get to :slight_smile:
e.g. a task to remind us of: data_bob.json, data_ana.json, etc... should be exported directly from DB module and later imported into DB module as well
Basically, when processing feedback, ...either it should be included into the work for the next worklog, or if it cant be done right away, it should be added as a todo for later so we will for sure not forget it
e.g.
same for the "reply" feature ...if it cant be done immediately, at least it should be added as a task to the top level comment.
if that feature depends on some other task, that should be indicated by using the output of that other task as input to the "reply" feature task
...same goes for exporting data from DB module.
that requires having a DB module first, so the DB module as output should be an input to that export/import task for the future :slight_smile:
2. message format
Regarding message format, it has a very specific and very strict format, which looks like this:
on(message => {
  const by = `<address of sender>`
  const to = `<address of receiver>`
  const mid = `<message ID counter>`
  // `mid` indicates how many messages have been sent from "by" to "to".
  // -> if there was a DB book append only log to store the sent messages from "by" to "to", then `mid` would be `.length` of that append only log
  const head = [by, to, mid]
  const refs = {}
  const type = 'text'
  const data = 'Hello back'
  const meta = { date: Date.now() }
  const msg = {
    head,
    refs,
    type,
    data,
    meta,
  }
  // `msg.refs` is an object
  // every key, e.g. `msg.refs.cause` value is a `head` of another message
  msg.refs.cause = message.head
  console.log(msg)
  book.add(msg)
  const {
    send
  } = state.net[message.head[0]]
  send(msg)
})

every message has exactly that structure and not any different structure.
we should probably write a function to verify that structure.
3. derived append only logs
I do think this is also supposed to be true for chatroom array.
Ideally, the chatroom would only consist of an ordered list of heads and then when rendering, it would look up the actual message content and other data in based on those heads :slight_smile:
That way we dont have to duplicate data for now and keep things more systematic.
Things is also, the chatroom.sort in the end is only based on "date" and not yet on any dependencies expressed through message.refs...
4. some old feeddback
https://imgur.com/rwGhZrJ.png
maybe you missed one tiny old feedback, the old feedback about the json data structure and you jumped directly to the
"first message" in the room.
But it also shows the key should not be the "nickname" of a peer (e.g. "ana") but it should be the peer's address
TASKS[273].room = { '': [m0], [ana_ID]: [] }
the ana_ID is not "ana"

otherwise, thanks for the worklog.
looks good.
Agree with not touching the list architecture branch until we completed the other refactoring parts :slight_smile:

tasks - 2024-05-08

Update task_messenger_v0.0.5

Logged next todos - 2min
Updated message format - 20min
Updated chatroom structure to array of heads - 1h10min
Mapped chatlogs with IDs instead of usernames - 15min
Logged tasks - 5min
@output :package: task_messenger_v0.0.5

feedback
There was not much to explain. Just I wanted to say that these updates may become useless when those new modules are implemented.

Tasks - 2024-05-25

Create a presentation video for Cypher

Recorded a worklog with task messenger explanation - 25min
@output :package: video


Update select.html from "var" to "const"

Changed from "var" to "const" in line 157 und 162. Var ist outdated for Javascript const variables.
Proposed changes
In current JavaScript, only const is used to create const variables. Var is outdated. Maybe you can change all var s into const for example in "Forms -> Select -> Initialization" or "Forms -> Select -> Methods".
Screenshots (if appropriate) or codepen:
Types of changes

[ x] Bug fix (non-breaking change which fixes an issue).
[ ] New feature (non-breaking change which adds functionality).
[ ] Breaking change (fix or feature that would cause existing functionality to change).

Checklist:

[x ] I have read the CONTRIBUTING document.
[x ] My commit messages follows the conventional commit format
[ x] My change requires a change to the documentation, and updated it accordingly.
[ x] I have added tests to cover my changes.
[x ] All new and existing tests passed.

Hi, thanks for your contribution. Please use commitlint format next time in the commit messages as suggested by @ChildishGiant. For example "docs: change var to const". Unfortunately the files you have changed have no effect on the documentation and have to be moved to materialize-docs. The PR will be added nevertheless.


/opt/grappa/include/Grappa/Tasking.hpp:234:3: error: use of undeclared identifier 'on_exit'

Excerpt
In file included from nstream.cpp:40:
In file included from /opt/grappa/include/Grappa/Grappa.hpp:51:
/opt/grappa/include/Grappa/Tasking.hpp:234:3: error: use of undeclared identifier 'on_exit'
  on_exit( [] ( int retval, void * payload) { _exit(retval); }, nullptr );
  ^

Full error
$ make allgrappa
cd GRAPPA/Nstream;         /Applications/Xcode.app/Contents/Developer/usr/bin/make nstream    "DEFAULT_OPT_FLAGS   = -O3"
/opt/mpich/dev/clang/default/bin/mpicxx -O3 -DGRAPPA    -DENABLE_RDMA_AGGREGATOR -D__extern_always_inline=inline  -std=c++11 -Winline -Wno-inline -mno-red-zone   -I/opt/grappa/include -I/opt/grappa/include/Grappa -I/opt/grappa/include/Grappa/tasks -I/opt/mpich/dev/intel/default/include -I/usr/local/include  -I../../include -c nstream.cpp
In file included from nstream.cpp:40:
In file included from /opt/grappa/include/Grappa/Grappa.hpp:59:
/opt/grappa/include/Grappa/ParallelLoop.hpp:416:38: warning: address of 'local_gce' will always evaluate to 'true'
      [-Wpointer-bool-conversion]
      if (S == SyncMode::Blocking && GCE) GCE->wait();
                                  ~~ ^~~
/opt/grappa/include/Grappa/ParallelLoop.hpp:453:13: note: in instantiation of function template specialization
      'Grappa::impl::forall<Grappa::TaskMode::Bound, Grappa::SyncMode::Blocking, &Grappa::impl::local_gce, 0, double, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:448:16)>' requested here
      impl::forall<B,S,GCE,Threshold>(base, nelems, f, &decltype(f)::operator());
            ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:510:11: note: in instantiation of function template specialization
      'Grappa::impl::forall<Grappa::TaskMode::Bound, Grappa::SyncMode::Blocking, &Grappa::impl::local_gce, 0, double,
      (lambda at nstream.cpp:133:20)>' requested here
    impl::forall<B,S,GCE,Threshold>(base, nelems, loop_body, &F::operator());
          ^
nstream.cpp:133:2: note: in instantiation of function template specialization 'Grappa::forall<Grappa::TaskMode::Bound,
      Grappa::SyncMode::Blocking, &Grappa::impl::local_gce, 0, double, (lambda at nstream.cpp:133:20)>' requested here
        forall(a, length, [=](double& aref) {
        ^
In file included from nstream.cpp:40:
In file included from /opt/grappa/include/Grappa/Grappa.hpp:59:
/opt/grappa/include/Grappa/ParallelLoop.hpp:158:18: warning: address of 'local_gce' will always evaluate to 'true'
      [-Wpointer-bool-conversion]
      } else if (C && S == SyncMode::Async && B == TaskMode::Bound
                 ^ ~~
/opt/grappa/include/Grappa/ParallelLoop.hpp:187:7: note: in instantiation of function template specialization
      'Grappa::impl::forall_here<Grappa::TaskMode::Bound, Grappa::SyncMode::Async, &Grappa::impl::local_gce, 0, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:411:13)>' requested here
      forall_here<B,S,C,Threshold>(start, iters, loop_body, &F::operator());
      ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:208:3: note: in instantiation of function template specialization
      'Grappa::impl::forall_here<Grappa::TaskMode::Bound, Grappa::SyncMode::Async, &Grappa::impl::local_gce, 0, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:411:13)>' requested here
  FORALL_HERE_OVERLOAD(TaskMode B,
  ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:205:11: note: expanded from macro 'FORALL_HERE_OVERLOAD'
    impl::forall_here<B,S,GCE,Threshold>(start, iters, loop_body); \
          ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:410:17: note: in instantiation of function template specialization
      'Grappa::forall_here<Grappa::TaskMode::Bound, Grappa::SyncMode::Async, &Grappa::impl::local_gce, 0, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:411:13)>' requested here
        Grappa::forall_here<B,SyncMode::Async,GCE,Threshold>(0, nlocal,
                ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:453:13: note: in instantiation of function template specialization
      'Grappa::impl::forall<Grappa::TaskMode::Bound, Grappa::SyncMode::Blocking, &Grappa::impl::local_gce, 0, double, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:448:16)>' requested here
      impl::forall<B,S,GCE,Threshold>(base, nelems, f, &decltype(f)::operator());
            ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:510:11: note: in instantiation of function template specialization
      'Grappa::impl::forall<Grappa::TaskMode::Bound, Grappa::SyncMode::Blocking, &Grappa::impl::local_gce, 0, double,
      (lambda at nstream.cpp:133:20)>' requested here
    impl::forall<B,S,GCE,Threshold>(base, nelems, loop_body, &F::operator());
          ^
nstream.cpp:133:2: note: in instantiation of function template specialization 'Grappa::forall<Grappa::TaskMode::Bound,
      Grappa::SyncMode::Blocking, &Grappa::impl::local_gce, 0, double, (lambda at nstream.cpp:133:20)>' requested here
        forall(a, length, [=](double& aref) {
        ^
In file included from nstream.cpp:40:
In file included from /opt/grappa/include/Grappa/Grappa.hpp:59:
/opt/grappa/include/Grappa/ParallelLoop.hpp:169:40: warning: address of 'local_gce' will always evaluate to 'true'
      [-Wpointer-bool-conversion]
        if (S == SyncMode::Blocking && C) C->wait();
                                    ~~ ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:110:13: warning: address of 'local_gce' will always evaluate to 'true'
      [-Wpointer-bool-conversion]
        if (C) C->enroll();
            ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:149:17: note: in instantiation of function template specialization
      'Grappa::impl::loop_decomposition<Grappa::TaskMode::Bound, &Grappa::impl::local_gce, 0, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:150:11)>' requested here
          impl::loop_decomposition<B,C,Threshold>(start, iters,
                ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:187:7: note: in instantiation of function template specialization
      'Grappa::impl::forall_here<Grappa::TaskMode::Bound, Grappa::SyncMode::Async, &Grappa::impl::local_gce, 0, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:411:13)>' requested here
      forall_here<B,S,C,Threshold>(start, iters, loop_body, &F::operator());
      ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:208:3: note: in instantiation of function template specialization
      'Grappa::impl::forall_here<Grappa::TaskMode::Bound, Grappa::SyncMode::Async, &Grappa::impl::local_gce, 0, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:411:13)>' requested here
  FORALL_HERE_OVERLOAD(TaskMode B,
  ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:205:11: note: expanded from macro 'FORALL_HERE_OVERLOAD'
    impl::forall_here<B,S,GCE,Threshold>(start, iters, loop_body); \
          ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:410:17: note: in instantiation of function template specialization
      'Grappa::forall_here<Grappa::TaskMode::Bound, Grappa::SyncMode::Async, &Grappa::impl::local_gce, 0, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:411:13)>' requested here
        Grappa::forall_here<B,SyncMode::Async,GCE,Threshold>(0, nlocal,
                ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:453:13: note: in instantiation of function template specialization
      'Grappa::impl::forall<Grappa::TaskMode::Bound, Grappa::SyncMode::Blocking, &Grappa::impl::local_gce, 0, double, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:448:16)>' requested here
      impl::forall<B,S,GCE,Threshold>(base, nelems, f, &decltype(f)::operator());
            ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:510:11: note: in instantiation of function template specialization
      'Grappa::impl::forall<Grappa::TaskMode::Bound, Grappa::SyncMode::Blocking, &Grappa::impl::local_gce, 0, double,
      (lambda at nstream.cpp:133:20)>' requested here
    impl::forall<B,S,GCE,Threshold>(base, nelems, loop_body, &F::operator());
          ^
nstream.cpp:133:2: note: in instantiation of function template specialization 'Grappa::forall<Grappa::TaskMode::Bound,
      Grappa::SyncMode::Blocking, &Grappa::impl::local_gce, 0, double, (lambda at nstream.cpp:133:20)>' requested here
        forall(a, length, [=](double& aref) {
        ^
In file included from nstream.cpp:40:
In file included from /opt/grappa/include/Grappa/Grappa.hpp:59:
/opt/grappa/include/Grappa/ParallelLoop.hpp:113:15: warning: address of 'local_gce' will always evaluate to 'true'
      [-Wpointer-bool-conversion]
          if (C) C->send_completion(packed.origin);
              ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:110:13: warning: address of 'local_gce' will always evaluate to 'true'
      [-Wpointer-bool-conversion]
        if (C) C->enroll();
            ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:162:15: note: in instantiation of function template specialization
      'Grappa::impl::loop_decomposition<Grappa::TaskMode::Bound, &Grappa::impl::local_gce, 0, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:163:13)>' requested here
        impl::loop_decomposition<B,C,Threshold>(start, iters,
              ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:187:7: note: in instantiation of function template specialization
      'Grappa::impl::forall_here<Grappa::TaskMode::Bound, Grappa::SyncMode::Async, &Grappa::impl::local_gce, 0, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:411:13)>' requested here
      forall_here<B,S,C,Threshold>(start, iters, loop_body, &F::operator());
      ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:208:3: note: in instantiation of function template specialization
      'Grappa::impl::forall_here<Grappa::TaskMode::Bound, Grappa::SyncMode::Async, &Grappa::impl::local_gce, 0, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:411:13)>' requested here
  FORALL_HERE_OVERLOAD(TaskMode B,
  ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:205:11: note: expanded from macro 'FORALL_HERE_OVERLOAD'
    impl::forall_here<B,S,GCE,Threshold>(start, iters, loop_body); \
          ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:410:17: note: in instantiation of function template specialization
      'Grappa::forall_here<Grappa::TaskMode::Bound, Grappa::SyncMode::Async, &Grappa::impl::local_gce, 0, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:411:13)>' requested here
        Grappa::forall_here<B,SyncMode::Async,GCE,Threshold>(0, nlocal,
                ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:453:13: note: in instantiation of function template specialization
      'Grappa::impl::forall<Grappa::TaskMode::Bound, Grappa::SyncMode::Blocking, &Grappa::impl::local_gce, 0, double, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:448:16)>' requested here
      impl::forall<B,S,GCE,Threshold>(base, nelems, f, &decltype(f)::operator());
            ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:510:11: note: in instantiation of function template specialization
      'Grappa::impl::forall<Grappa::TaskMode::Bound, Grappa::SyncMode::Blocking, &Grappa::impl::local_gce, 0, double,
      (lambda at nstream.cpp:133:20)>' requested here
    impl::forall<B,S,GCE,Threshold>(base, nelems, loop_body, &F::operator());
          ^
nstream.cpp:133:2: note: in instantiation of function template specialization 'Grappa::forall<Grappa::TaskMode::Bound,
      Grappa::SyncMode::Blocking, &Grappa::impl::local_gce, 0, double, (lambda at nstream.cpp:133:20)>' requested here
        forall(a, length, [=](double& aref) {
        ^
In file included from nstream.cpp:40:
In file included from /opt/grappa/include/Grappa/Grappa.hpp:59:
/opt/grappa/include/Grappa/ParallelLoop.hpp:113:15: warning: address of 'local_gce' will always evaluate to 'true'
      [-Wpointer-bool-conversion]
          if (C) C->send_completion(packed.origin);
              ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:110:13: warning: address of 'local_gce' will always evaluate to 'true'
      [-Wpointer-bool-conversion]
        if (C) C->enroll();
            ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:168:15: note: in instantiation of function template specialization
      'Grappa::impl::loop_decomposition<Grappa::TaskMode::Bound, &Grappa::impl::local_gce, 0, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:411:13)>' requested here
        impl::loop_decomposition<B,C,Threshold>(start, iters, loop_body);
              ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:187:7: note: in instantiation of function template specialization
      'Grappa::impl::forall_here<Grappa::TaskMode::Bound, Grappa::SyncMode::Async, &Grappa::impl::local_gce, 0, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:411:13)>' requested here
      forall_here<B,S,C,Threshold>(start, iters, loop_body, &F::operator());
      ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:208:3: note: in instantiation of function template specialization
      'Grappa::impl::forall_here<Grappa::TaskMode::Bound, Grappa::SyncMode::Async, &Grappa::impl::local_gce, 0, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:411:13)>' requested here
  FORALL_HERE_OVERLOAD(TaskMode B,
  ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:205:11: note: expanded from macro 'FORALL_HERE_OVERLOAD'
    impl::forall_here<B,S,GCE,Threshold>(start, iters, loop_body); \
          ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:410:17: note: in instantiation of function template specialization
      'Grappa::forall_here<Grappa::TaskMode::Bound, Grappa::SyncMode::Async, &Grappa::impl::local_gce, 0, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:411:13)>' requested here
        Grappa::forall_here<B,SyncMode::Async,GCE,Threshold>(0, nlocal,
                ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:453:13: note: in instantiation of function template specialization
      'Grappa::impl::forall<Grappa::TaskMode::Bound, Grappa::SyncMode::Blocking, &Grappa::impl::local_gce, 0, double, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:448:16)>' requested here
      impl::forall<B,S,GCE,Threshold>(base, nelems, f, &decltype(f)::operator());
            ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:510:11: note: in instantiation of function template specialization
      'Grappa::impl::forall<Grappa::TaskMode::Bound, Grappa::SyncMode::Blocking, &Grappa::impl::local_gce, 0, double,
      (lambda at nstream.cpp:133:20)>' requested here
    impl::forall<B,S,GCE,Threshold>(base, nelems, loop_body, &F::operator());
          ^
nstream.cpp:133:2: note: in instantiation of function template specialization 'Grappa::forall<Grappa::TaskMode::Bound,
      Grappa::SyncMode::Blocking, &Grappa::impl::local_gce, 0, double, (lambda at nstream.cpp:133:20)>' requested here
        forall(a, length, [=](double& aref) {
        ^
In file included from nstream.cpp:40:
In file included from /opt/grappa/include/Grappa/Grappa.hpp:59:
/opt/grappa/include/Grappa/ParallelLoop.hpp:113:15: warning: address of 'local_gce' will always evaluate to 'true'
      [-Wpointer-bool-conversion]
          if (C) C->send_completion(packed.origin);
              ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:382:9: warning: address of 'local_gce' will always evaluate to 'true'
      [-Wpointer-bool-conversion]
    if (GCE) GCE->enroll(fc);
        ^~~
/opt/grappa/include/Grappa/ParallelLoop.hpp:408:7: note: in instantiation of function template specialization
      'Grappa::on_cores_localized_async<&Grappa::impl::local_gce, 0, double, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:409:7)>' requested here
      on_cores_localized_async<GCE,Threshold>(base, nelems,
      ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:453:13: note: in instantiation of function template specialization
      'Grappa::impl::forall<Grappa::TaskMode::Bound, Grappa::SyncMode::Blocking, &Grappa::impl::local_gce, 0, double, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:448:16)>' requested here
      impl::forall<B,S,GCE,Threshold>(base, nelems, f, &decltype(f)::operator());
            ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:510:11: note: in instantiation of function template specialization
      'Grappa::impl::forall<Grappa::TaskMode::Bound, Grappa::SyncMode::Blocking, &Grappa::impl::local_gce, 0, double,
      (lambda at nstream.cpp:133:20)>' requested here
    impl::forall<B,S,GCE,Threshold>(base, nelems, loop_body, &F::operator());
          ^
nstream.cpp:133:2: note: in instantiation of function template specialization 'Grappa::forall<Grappa::TaskMode::Bound,
      Grappa::SyncMode::Blocking, &Grappa::impl::local_gce, 0, double, (lambda at nstream.cpp:133:20)>' requested here
        forall(a, length, [=](double& aref) {
        ^
In file included from nstream.cpp:40:
In file included from /opt/grappa/include/Grappa/Grappa.hpp:59:
/opt/grappa/include/Grappa/ParallelLoop.hpp:392:15: warning: address of 'local_gce' will always evaluate to 'true'
      [-Wpointer-bool-conversion]
          if (GCE) complete(make_global(GCE,packed.origin));
              ^~~
In file included from nstream.cpp:40:
In file included from /opt/grappa/include/Grappa/Grappa.hpp:51:
/opt/grappa/include/Grappa/Tasking.hpp:234:3: error: use of undeclared identifier 'on_exit'
  on_exit( [] ( int retval, void * payload) { _exit(retval); }, nullptr );
  ^
nstream.cpp:85:11: note: in instantiation of function template specialization 'Grappa::run<(lambda at nstream.cpp:85:15)>'
      requested here
  Grappa::run([=] {
          ^
In file included from nstream.cpp:40:
In file included from /opt/grappa/include/Grappa/Grappa.hpp:59:
/opt/grappa/include/Grappa/ParallelLoop.hpp:416:38: warning: address of 'local_gce' will always evaluate to 'true'
      [-Wpointer-bool-conversion]
      if (S == SyncMode::Blocking && GCE) GCE->wait();
                                  ~~ ^~~
/opt/grappa/include/Grappa/ParallelLoop.hpp:453:13: note: in instantiation of function template specialization
      'Grappa::impl::forall<Grappa::TaskMode::Bound, Grappa::SyncMode::Blocking, &Grappa::impl::local_gce, 0, double, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:448:16)>' requested here
      impl::forall<B,S,GCE,Threshold>(base, nelems, f, &decltype(f)::operator());
            ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:510:11: note: in instantiation of function template specialization
      'Grappa::impl::forall<Grappa::TaskMode::Bound, Grappa::SyncMode::Blocking, &Grappa::impl::local_gce, 0, double,
      (lambda at nstream.cpp:181:22)>' requested here
    impl::forall<B,S,GCE,Threshold>(base, nelems, loop_body, &F::operator());
          ^
nstream.cpp:181:3: note: in instantiation of function template specialization 'Grappa::forall<Grappa::TaskMode::Bound,
      Grappa::SyncMode::Blocking, &Grappa::impl::local_gce, 0, double, (lambda at nstream.cpp:181:22)>' requested here
  forall (a, length, [=] (double& aj) {
  ^
In file included from nstream.cpp:40:
In file included from /opt/grappa/include/Grappa/Grappa.hpp:59:
/opt/grappa/include/Grappa/ParallelLoop.hpp:158:18: warning: address of 'local_gce' will always evaluate to 'true'
      [-Wpointer-bool-conversion]
      } else if (C && S == SyncMode::Async && B == TaskMode::Bound
                 ^ ~~
/opt/grappa/include/Grappa/ParallelLoop.hpp:187:7: note: in instantiation of function template specialization
      'Grappa::impl::forall_here<Grappa::TaskMode::Bound, Grappa::SyncMode::Async, &Grappa::impl::local_gce, 0, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:411:13)>' requested here
      forall_here<B,S,C,Threshold>(start, iters, loop_body, &F::operator());
      ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:208:3: note: in instantiation of function template specialization
      'Grappa::impl::forall_here<Grappa::TaskMode::Bound, Grappa::SyncMode::Async, &Grappa::impl::local_gce, 0, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:411:13)>' requested here
  FORALL_HERE_OVERLOAD(TaskMode B,
  ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:205:11: note: expanded from macro 'FORALL_HERE_OVERLOAD'
    impl::forall_here<B,S,GCE,Threshold>(start, iters, loop_body); \
          ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:410:17: note: in instantiation of function template specialization
      'Grappa::forall_here<Grappa::TaskMode::Bound, Grappa::SyncMode::Async, &Grappa::impl::local_gce, 0, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:411:13)>' requested here
        Grappa::forall_here<B,SyncMode::Async,GCE,Threshold>(0, nlocal,
                ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:453:13: note: in instantiation of function template specialization
      'Grappa::impl::forall<Grappa::TaskMode::Bound, Grappa::SyncMode::Blocking, &Grappa::impl::local_gce, 0, double, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:448:16)>' requested here
      impl::forall<B,S,GCE,Threshold>(base, nelems, f, &decltype(f)::operator());
            ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:510:11: note: in instantiation of function template specialization
      'Grappa::impl::forall<Grappa::TaskMode::Bound, Grappa::SyncMode::Blocking, &Grappa::impl::local_gce, 0, double,
      (lambda at nstream.cpp:181:22)>' requested here
    impl::forall<B,S,GCE,Threshold>(base, nelems, loop_body, &F::operator());
          ^
nstream.cpp:181:3: note: in instantiation of function template specialization 'Grappa::forall<Grappa::TaskMode::Bound,
      Grappa::SyncMode::Blocking, &Grappa::impl::local_gce, 0, double, (lambda at nstream.cpp:181:22)>' requested here
  forall (a, length, [=] (double& aj) {
  ^
In file included from nstream.cpp:40:
In file included from /opt/grappa/include/Grappa/Grappa.hpp:59:
/opt/grappa/include/Grappa/ParallelLoop.hpp:169:40: warning: address of 'local_gce' will always evaluate to 'true'
      [-Wpointer-bool-conversion]
        if (S == SyncMode::Blocking && C) C->wait();
                                    ~~ ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:110:13: warning: address of 'local_gce' will always evaluate to 'true'
      [-Wpointer-bool-conversion]
        if (C) C->enroll();
            ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:149:17: note: in instantiation of function template specialization
      'Grappa::impl::loop_decomposition<Grappa::TaskMode::Bound, &Grappa::impl::local_gce, 0, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:150:11)>' requested here
          impl::loop_decomposition<B,C,Threshold>(start, iters,
                ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:187:7: note: in instantiation of function template specialization
      'Grappa::impl::forall_here<Grappa::TaskMode::Bound, Grappa::SyncMode::Async, &Grappa::impl::local_gce, 0, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:411:13)>' requested here
      forall_here<B,S,C,Threshold>(start, iters, loop_body, &F::operator());
      ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:208:3: note: in instantiation of function template specialization
      'Grappa::impl::forall_here<Grappa::TaskMode::Bound, Grappa::SyncMode::Async, &Grappa::impl::local_gce, 0, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:411:13)>' requested here
  FORALL_HERE_OVERLOAD(TaskMode B,
  ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:205:11: note: expanded from macro 'FORALL_HERE_OVERLOAD'
    impl::forall_here<B,S,GCE,Threshold>(start, iters, loop_body); \
          ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:410:17: note: in instantiation of function template specialization
      'Grappa::forall_here<Grappa::TaskMode::Bound, Grappa::SyncMode::Async, &Grappa::impl::local_gce, 0, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:411:13)>' requested here
        Grappa::forall_here<B,SyncMode::Async,GCE,Threshold>(0, nlocal,
                ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:453:13: note: in instantiation of function template specialization
      'Grappa::impl::forall<Grappa::TaskMode::Bound, Grappa::SyncMode::Blocking, &Grappa::impl::local_gce, 0, double, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:448:16)>' requested here
      impl::forall<B,S,GCE,Threshold>(base, nelems, f, &decltype(f)::operator());
            ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:510:11: note: in instantiation of function template specialization
      'Grappa::impl::forall<Grappa::TaskMode::Bound, Grappa::SyncMode::Blocking, &Grappa::impl::local_gce, 0, double,
      (lambda at nstream.cpp:181:22)>' requested here
    impl::forall<B,S,GCE,Threshold>(base, nelems, loop_body, &F::operator());
          ^
nstream.cpp:181:3: note: in instantiation of function template specialization 'Grappa::forall<Grappa::TaskMode::Bound,
      Grappa::SyncMode::Blocking, &Grappa::impl::local_gce, 0, double, (lambda at nstream.cpp:181:22)>' requested here
  forall (a, length, [=] (double& aj) {
  ^
In file included from nstream.cpp:40:
In file included from /opt/grappa/include/Grappa/Grappa.hpp:59:
/opt/grappa/include/Grappa/ParallelLoop.hpp:113:15: warning: address of 'local_gce' will always evaluate to 'true'
      [-Wpointer-bool-conversion]
          if (C) C->send_completion(packed.origin);
              ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:110:13: warning: address of 'local_gce' will always evaluate to 'true'
      [-Wpointer-bool-conversion]
        if (C) C->enroll();
            ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:162:15: note: in instantiation of function template specialization
      'Grappa::impl::loop_decomposition<Grappa::TaskMode::Bound, &Grappa::impl::local_gce, 0, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:163:13)>' requested here
        impl::loop_decomposition<B,C,Threshold>(start, iters,
              ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:187:7: note: in instantiation of function template specialization
      'Grappa::impl::forall_here<Grappa::TaskMode::Bound, Grappa::SyncMode::Async, &Grappa::impl::local_gce, 0, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:411:13)>' requested here
      forall_here<B,S,C,Threshold>(start, iters, loop_body, &F::operator());
      ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:208:3: note: in instantiation of function template specialization
      'Grappa::impl::forall_here<Grappa::TaskMode::Bound, Grappa::SyncMode::Async, &Grappa::impl::local_gce, 0, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:411:13)>' requested here
  FORALL_HERE_OVERLOAD(TaskMode B,
  ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:205:11: note: expanded from macro 'FORALL_HERE_OVERLOAD'
    impl::forall_here<B,S,GCE,Threshold>(start, iters, loop_body); \
          ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:410:17: note: in instantiation of function template specialization
      'Grappa::forall_here<Grappa::TaskMode::Bound, Grappa::SyncMode::Async, &Grappa::impl::local_gce, 0, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:411:13)>' requested here
        Grappa::forall_here<B,SyncMode::Async,GCE,Threshold>(0, nlocal,
                ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:453:13: note: in instantiation of function template specialization
      'Grappa::impl::forall<Grappa::TaskMode::Bound, Grappa::SyncMode::Blocking, &Grappa::impl::local_gce, 0, double, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:448:16)>' requested here
      impl::forall<B,S,GCE,Threshold>(base, nelems, f, &decltype(f)::operator());
            ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:510:11: note: in instantiation of function template specialization
      'Grappa::impl::forall<Grappa::TaskMode::Bound, Grappa::SyncMode::Blocking, &Grappa::impl::local_gce, 0, double,
      (lambda at nstream.cpp:181:22)>' requested here
    impl::forall<B,S,GCE,Threshold>(base, nelems, loop_body, &F::operator());
          ^
nstream.cpp:181:3: note: in instantiation of function template specialization 'Grappa::forall<Grappa::TaskMode::Bound,
      Grappa::SyncMode::Blocking, &Grappa::impl::local_gce, 0, double, (lambda at nstream.cpp:181:22)>' requested here
  forall (a, length, [=] (double& aj) {
  ^
In file included from nstream.cpp:40:
In file included from /opt/grappa/include/Grappa/Grappa.hpp:59:
/opt/grappa/include/Grappa/ParallelLoop.hpp:113:15: warning: address of 'local_gce' will always evaluate to 'true'
      [-Wpointer-bool-conversion]
          if (C) C->send_completion(packed.origin);
              ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:110:13: warning: address of 'local_gce' will always evaluate to 'true'
      [-Wpointer-bool-conversion]
        if (C) C->enroll();
            ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:168:15: note: in instantiation of function template specialization
      'Grappa::impl::loop_decomposition<Grappa::TaskMode::Bound, &Grappa::impl::local_gce, 0, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:411:13)>' requested here
        impl::loop_decomposition<B,C,Threshold>(start, iters, loop_body);
              ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:187:7: note: in instantiation of function template specialization
      'Grappa::impl::forall_here<Grappa::TaskMode::Bound, Grappa::SyncMode::Async, &Grappa::impl::local_gce, 0, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:411:13)>' requested here
      forall_here<B,S,C,Threshold>(start, iters, loop_body, &F::operator());
      ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:208:3: note: in instantiation of function template specialization
      'Grappa::impl::forall_here<Grappa::TaskMode::Bound, Grappa::SyncMode::Async, &Grappa::impl::local_gce, 0, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:411:13)>' requested here
  FORALL_HERE_OVERLOAD(TaskMode B,
  ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:205:11: note: expanded from macro 'FORALL_HERE_OVERLOAD'
    impl::forall_here<B,S,GCE,Threshold>(start, iters, loop_body); \
          ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:410:17: note: in instantiation of function template specialization
      'Grappa::forall_here<Grappa::TaskMode::Bound, Grappa::SyncMode::Async, &Grappa::impl::local_gce, 0, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:411:13)>' requested here
        Grappa::forall_here<B,SyncMode::Async,GCE,Threshold>(0, nlocal,
                ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:453:13: note: in instantiation of function template specialization
      'Grappa::impl::forall<Grappa::TaskMode::Bound, Grappa::SyncMode::Blocking, &Grappa::impl::local_gce, 0, double, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:448:16)>' requested here
      impl::forall<B,S,GCE,Threshold>(base, nelems, f, &decltype(f)::operator());
            ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:510:11: note: in instantiation of function template specialization
      'Grappa::impl::forall<Grappa::TaskMode::Bound, Grappa::SyncMode::Blocking, &Grappa::impl::local_gce, 0, double,
      (lambda at nstream.cpp:181:22)>' requested here
    impl::forall<B,S,GCE,Threshold>(base, nelems, loop_body, &F::operator());
          ^
nstream.cpp:181:3: note: in instantiation of function template specialization 'Grappa::forall<Grappa::TaskMode::Bound,
      Grappa::SyncMode::Blocking, &Grappa::impl::local_gce, 0, double, (lambda at nstream.cpp:181:22)>' requested here
  forall (a, length, [=] (double& aj) {
  ^
In file included from nstream.cpp:40:
In file included from /opt/grappa/include/Grappa/Grappa.hpp:59:
/opt/grappa/include/Grappa/ParallelLoop.hpp:113:15: warning: address of 'local_gce' will always evaluate to 'true'
      [-Wpointer-bool-conversion]
          if (C) C->send_completion(packed.origin);
              ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:382:9: warning: address of 'local_gce' will always evaluate to 'true'
      [-Wpointer-bool-conversion]
    if (GCE) GCE->enroll(fc);
        ^~~
/opt/grappa/include/Grappa/ParallelLoop.hpp:408:7: note: in instantiation of function template specialization
      'Grappa::on_cores_localized_async<&Grappa::impl::local_gce, 0, double, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:409:7)>' requested here
      on_cores_localized_async<GCE,Threshold>(base, nelems,
      ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:453:13: note: in instantiation of function template specialization
      'Grappa::impl::forall<Grappa::TaskMode::Bound, Grappa::SyncMode::Blocking, &Grappa::impl::local_gce, 0, double, (lambda at
      /opt/grappa/include/Grappa/ParallelLoop.hpp:448:16)>' requested here
      impl::forall<B,S,GCE,Threshold>(base, nelems, f, &decltype(f)::operator());
            ^
/opt/grappa/include/Grappa/ParallelLoop.hpp:510:11: note: in instantiation of function template specialization
      'Grappa::impl::forall<Grappa::TaskMode::Bound, Grappa::SyncMode::Blocking, &Grappa::impl::local_gce, 0, double,
      (lambda at nstream.cpp:181:22)>' requested here
    impl::forall<B,S,GCE,Threshold>(base, nelems, loop_body, &F::operator());
          ^
nstream.cpp:181:3: note: in instantiation of function template specialization 'Grappa::forall<Grappa::TaskMode::Bound,
      Grappa::SyncMode::Blocking, &Grappa::impl::local_gce, 0, double, (lambda at nstream.cpp:181:22)>' requested here
  forall (a, length, [=] (double& aj) {
  ^
In file included from nstream.cpp:40:
In file included from /opt/grappa/include/Grappa/Grappa.hpp:59:
/opt/grappa/include/Grappa/ParallelLoop.hpp:392:15: warning: address of 'local_gce' will always evaluate to 'true'
      [-Wpointer-bool-conversion]
          if (GCE) complete(make_global(GCE,packed.origin));
              ^~~
22 warnings and 1 error generated.
make[1]: *** [nstream.o] Error 1
make: *** [allgrappa] Error 2

Are you building on OS X? Sorry, not supported.
Strictly speaking, you don't need the on_exit call that's causing the error; it's just an attempt to temporarily work around a deallocation race at exit that we see on some machines (Crays).

Yeah, I'm using Mac, because it's what I have on my desk.  I'll switch to my Linux machine.


Adds command tablet

About the PR
This PR creates the CO tablet, which is functionally just a mobile ground-side operations console. It is literally the exact same UI as the Console, primarily because they both do the exact same thing. Since it uses the same UI as the Console, I also renamed the UI to remove the word Console on the announcement pop-up. The new command tablet is mapped into CiC.

Why / Balance
This was added mostly because it existed in CM, but also because commanders need a way to get everyone's attention at a moments notice, even if they aren't in CiC. This is especially true given that there is currently no way to see whats going on ground side without being ground side

Technical details
No C#, just yaml and mapping

Media

[x] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Changelog

:cl:

add: Added Command Tablet
tweak: changed UI name for groundside operations console to "Groundside Operations"

isn't CIC on the second floor, as such its completely inaccessible?

isn't CIC on the second floor, as such its completely inaccessible?

We don't have a second floor. CiC(as well as the brig) is west of the hanger.

We don't have a second floor. CiC(as well as the brig) is west of the hanger.

almayer.yml that presented in the repo is not actually a Almayer, thats Savannah.

Thanks for the PR!

Thank you as well, and have an excellent day.


Pagination showing '...' when not required

Example search: http://localhost:8080/search?s=mechanical
There are 4 pages.  When on page one, the following is shown:

@sbagg I can take this one.

@sbagg I can take this one.

The "..." is only hiding one number which is completely unnecessary. We should only show ellipses if 2+ numbers are in that spot.

The "..." is only hiding one number which is completely unnecessary. We should only show ellipses if 2+ numbers are in that spot.

@wrenaria ellipses should only appear for 2+ numbers

@wrenaria ellipses should only appear for 2+ numbers


Confusions of GPU and CNN usage

1. Does gnina use GPU for docking?
When I tried the following
gnina -r receptor.pdbqt -l lig.pdbqt --autobox_ligand lig.pdbqt --autobox_add 8 --exhaustiveness 16 -o result.pdbqt --cnn --gpu

The GPU utility is 0 (monitored by nvidia-smi) until the following progress bar finishes:
0%   10   20   30   40   50   60   70   80   90   100%
|----|----|----|----|----|----|----|----|----|----|
***************************************************

Then gnina uses GPU but the program ends very quickly (<1s) after the following printed out.

mode |   affinity | dist from best mode
     | (kcal/mol) | rmsd l.b.| rmsd u.b.
-----+------------+----------+----------
1       -11.2      0.000      0.000
2       -9.6       2.448      3.302
3       -9.4       1.964      2.617
4       -9.2       4.300      7.475
5       -9.2       2.123      2.584
6       -8.9       3.152      7.097
7       -8.8       3.155      7.199
8       -8.7       4.405      6.985
9       -8.7       3.046      3.804
Refine time 27.397
Loop time 30.817

2. What is happening when only --gpu is specified, i.e. the following command:
gnina -r receptor.pdbqt -l lig.pdbqt --autobox_ligand lig.pdbqt --autobox_add 8 --exhaustiveness 16 -o result.pdbqt --gpu

The GPU utility is 99% but the program is running extremely slow (~50 times slower than above example) and the result is also weird:

0%   10   20   30   40   50   60   70   80   90   100%
|----|----|----|----|----|----|----|----|----|----|
***************************************************
 | pose 0 | ligand outside box
 | pose 0 | ligand outside box
 | pose 0 | ligand outside box
 | pose 0 | ligand outside box
 | pose 0 | ligand outside box
 | pose 0 | ligand outside box
 | pose 0 | ligand outside box
 | pose 0 | ligand outside box
 | pose 0 | ligand outside box
 | pose 0 | ligand outside box
 | pose 0 | ligand outside box
 | pose 0 | ligand outside box

mode |   affinity | dist from best mode
     | (kcal/mol) | rmsd l.b.| rmsd u.b.
-----+------------+----------+----------
1       -4.8       0.000      0.000
2       -3.4       7.630      11.349
3       -2.9       4.199      5.878
4       -2.7       7.029      9.203
5       -2.4       6.462      9.368
6       -2.1       6.103      8.684
Refine time 1440.356
Loop time 1450.621

3. What is the difference between --cnn and --cnn_model ?
Both seem to be related to default model, and specifying both with empty argument, i.e. --cnn --cnn_model --gpu will result in same slow performance as Question 2.
4. Does gnina support multi GPU?
I've tried --device 0,1 --gpu but it doesn't recognize the command.

We don't currently recommend passing --gpu unless you're using the CNN for evaluations. The arguments that are required to use a CNN are --cnn_scoring or --cnn_refinement; passing --cnn with no model name will result in an error if you pass either of those, but it doesn't in your example input because the CNN isn't actually being used (because neither --cnn_scoring nor --cnn_refinement were passed).
We have mostly done evaluations of using the CNN to rescore (--score_only) and minimize (--minimize) poses; if you want to evaluate docking exclusively with the CNN, you'll likely need to reduce the number of MC steps (--num_mc_steps) and/or the exhaustiveness (--exhaustiveness). To fix your example input to get CNN docking, just change --cnn to --cnn_scoring; that'll probably be slow, so if you're just trying to see how it works you can set e.g. --num_mc_steps 10 to speed up the evaluation. That said, we recommend using a conventional scoring function (e.g. what you get if you don't pass --cnn_scoring or --gpu) to dock and then just using --cnn_scoring with --score_only or --minimize.

This example is actually docking with a conventional scoring function (not the CNN) on the GPU, but that's currently a work in progress and we don't recommend using it. We haven't worked on this feature for a while so code rot could be at play here, but in the past there were issues with gradients not converging leading to far more evaluations happening when using the GPU for docking.

We provide several built-in models with pretrained weights. These can be accessed by name via --cnn. You can pass gnina your own model file (in prototxt format) via --cnn_model; in that case, you will also need to pass in weights with --cnn_weights. If you check the argument descriptions with --help, you'll see the model options for --cnn:

  --cnn arg                        built-in model to use: crossdock_default2018
                                   crossdock_default2018_1
                                   crossdock_default2018_2
                                   crossdock_default2018_3
                                   crossdock_default2018_4 default2017 dense
                                   dense_1 dense_2 dense_3 dense_4
                                   general_default2018 general_default2018_1
                                   general_default2018_2 general_default2018_3
                                   general_default2018_4

so e.g. you could pass --cnn_scoring --cnn dense to perform scoring using one of the ensemble of pretrained dense nets we've provided.

No. gnina uses Caffe for CNN evaluations, and Caffe doesn't support multi-GPU usage for test-phase evaluations (see e.g. https://github.com/BVLC/caffe/blob/master/docs/multigpu.md).


pinpoint-c-agent arm build

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
I want to run "ghcr.io/pinpoint-apm/pinpoint-c-agent/collector-agent:latest" this image on arm based machine, is there any arm image?
Describe the solution you'd like
Support for arm base machine
Describe alternatives you've considered
N/A
Additional context
N/A

Got it, I will check the arm.

@HJinS
please try this image

docker pull ghcr.io/pinpoint-apm/pinpoint-c-agent/collector-agent:dev

Thanks:)


Continuous Crashing every day or two requiring a manual restart

Plutonium T6 egg
LOG message:
Plutonium r3665 > 0d70:err:seh:NtRaiseException Unhandled exception code c00000fd flags 0 addr 0x7bc4ca26
and hangs indefinitely.
Message changes slightly on crashes.
I have 3 instances of this egg 1 Multiplayer 2 Zombies.
I will update with any future messages.

I generally won't be able to fix these issues but you should be restarting your server every day anyway.

Within Pterodactyl Panel, you can create schedules and make it restart every day (using cron). I'm not sure whether it's an issue on your end but likely not. It's not exactly guaranteed that everything will work since plutonium was designed to work on Windows. As far as I can see, the log you sent is telling me that Plutonium ran into an error (and the error was not handled). That could mean pretty much anything: the game or custom GSC could be causing that.

I totally understand, thank you very much for your time and help to point me in the right direction.
I will look at this scheduling system!
In hindsight, that was painfully obvious.
Thank you kindly,
Tom


Button click inside tab content is not firing with angular ui bootstrap

I have a dynamic angular uib-tabs which is working fine with scrolling tabs. it has dynamic tab content, button is one of them which is having click event. this button is not firing the event when placing inside scrolling tabs; works fine when removing this scrolling tab wrapper directive.
Anything am missing. any help is appreciated.
Here is the plunk having issue with button click event inside tab content -
http://plnkr.co/edit/FZo7R5?p=preview

Thanks for making a plunk that demonstrates the issue--that makes it a lot easier to debug.
I think the problem is with the visible .tab-content being a clone of the original .tab-content (which is hidden inside the .scrtabs-tabs-movable-container to preserve the AngularUI directive dependencies), and losing the angular hooks in the cloning process.
It's strange because the buttons still recognize the main controller on their scope, but the click handler just isn't firing, so I'm thinking it got removed from the angular digest cycle.
I'll look into it.

Sorry this took so long, and you've probably moved on by now, but v1.2.0 will hopefully fix your issue.
Here's a fork of your plunk showing it working:
http://plnkr.co/edit/U3z3Zm?p=preview

Thanks for the followup. Yes. I made some patches to make it work.
I will see if I can replace with your latest version.
I see it is working now in your plnkr. let me close this bug for now 👍


Why is the range function max inclusive?

Why is the range function in Radash max inclusive rather than max exclusive? The docs say that the function is a hat tip to the Python implementation by the same name, so why don’t they function identically? It makes it hard to iterate over an array without making the max value arr.length - 1.
Am I missing something in the docs? Any guidance would be much appreciated :)

Totally agree. This unexpected API-issue does of course apply to radash.list as well.
When a single parameter is passed, it is named size in the documentation, but the actual size / length of the iterator returned is one more than the number passed as size-parameter.

Hello @JamzOJamz and @torgesla, we'd be open to fixing this over at the Radashi fork, if either of you want to champion the effort. Of course, it's a breaking change, so please target the next branch with your PR.


Remove bitmex price feed

Atm: The bitmex price feed is used for the maker to come up with a rate when creating offers and for maker and taker for computing P/L.
A few thoughts:

Offers are created using the HTTP Api and it's unnecessary to have the binary to provide the price feed, send out the price information via SSE, and then post the price again. This extra roundtrip is not needed and was removed in our personal automation.
Hence, the maker is no longer making use of the price feed to create new offers.

The current price feed is used for computing P/L for positions: this is semi correct. The maker's P/L is calculated differently than the taker's P/L

maker's P/L: the maker has its own opinion on the price, meaning, his P/L should better be calculated from the outside.
taker's P/L: the taker has not an own opinion on the price, he either gets what the maker is willing to offer (for settlement) or what the oracle attests to (force close).

We want to show a P/L to the taker though: we have already two price feeds for the taker:

the maker's offers
the bitmex index price feed

--> For the taker's unrealized P/L we probably should make use the maker's offers as this is what he would get when settling a position.
--> We let the maker compute his P/L from the outside
Given that we can remove the bitmex price feed altogether.
Note: For a precise P/L computation we should know the payout curve, meaning, if we want to compute P/L from the outside, we will need to expose this information via the HTTP Api.

Related https://github.com/itchysats/itchysats/discussions/1108.

Note: For a precise P/L computation we should know the payout curve, meaning, if we want to compute P/L from the outside, we will need to expose this information via the HTTP Api.

We could also pass the current price into the maker, either via a parameter per endpoint or as a state in general. For creating a new order, we currently pass it in as a parameter. A solution for P/L that is consistent with this approach would be a query parameter on the /cfds endpoint that computes P/L based on this price for all currently open CFDs.

Closing in favor of the discussion https://github.com/itchysats/itchysats/discussions/1108.


fix: Update package.json version and description and regenerate yarn

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Explanation on how to execute the Spark SQL piece of code

Would be important to include a link to this other page (invoke Spark Jobs using cmdline) or to explain directly on this page how the Spark SQL code could be executed to create the "tables" requested on the python code to store the data:
section that starts with "Create the following tables by using Spark SQL."

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

ID: 7badf2b4-72c4-6cf5-6a2b-fffd51b51460
Version Independent ID: 22f11199-dc54-6526-9e04-b651c4b50ded
Content: SQL Server Big Data Clusters Spark Streaming guide - SQL Server Big Data Clusters
Content Source: docs/big-data-cluster/spark-streaming-guide.md
Product: sql
Technology: big-data-cluster
GitHub Login: @dacoelho
Microsoft Alias: dacoelho

@lcanastreiro -- Luís, thank you for your feedback.
@DaniBunny -- Daniel, please look into this issue.

#assign:williamdassafMSFT

Thanks @lcanastreiro very much for the input. Your feedback makes Microsoft Docs better. I've reviewed with the engineer and will be implementing a fix along these lines.


submitting correct code won't  work...again!

Challenge Create a Form Element has an issue.
User Agent is: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36.
Please describe how to reproduce this issue, and include links to screenshots if possible.
My code:

<link href="https://fonts.googleapis.com/css?family=Lobster" rel="stylesheet" type="text/css">

CatPhotoApp

Click here for cat photos.

Things cats love:

cat nip

laser pointers

lasagna

Top 3 things cats hate:

flea treatment

thunder

other cats

<form action="/submit-cat-photo">
  <input type="text" placeholder="cat photo URL">
</form>

Is it still breaking for you? I was able to recreate the error when I first saw this issue, but it appears to working now.

I switched from Chrome to internet explorer and it worked, thanks!


Unit tests not running

I am creating unit tests in my code and they are not being detected; see attached screenshot

In this boilerplate project, unit tests are located in test/unit directory. If you want to use .spec.js in source code directory, you should change the command in package.json.


Please cite our paper

We are happy that our dataset and paper has shown interest in the CV community. This library is by far the most similar implementation from our paper: https://ieeexplore.ieee.org/document/10285362
Also the dataset come from the paper mentioned before.

Thank you for the note and please accept my apologies for the oversight (the blog post did reference your work). I have updated the readme (https://github.com/pbeukema/wakemodel_llmassist/commit/3d9cc215082c1033589c26f8f535fad6183ba7e2) with this citation/acknowledgement but please let me know if you would like me to do anything further/or modify the citation.
Sincere thanks for doing this work and publicly releasing your dataset under a permissive license.

I kindly thank you again for using our work! Thanks!


2D IBM SHOCK

Case file for a shock wave in bubbly flow over an immersed boundary (airfoil)

is this a steady bubbly shock? if so, please name it as such.

also remove all unnecessary code/comments from the case.py file.

please address remaining comments

you need to merge with master i think