text:
[CPP Graph] KV-Update Optimization

Type of Change: feature
API not changed
Description

The FLASH_ATTN_KV_UPDATE op now uses JIT implementations for first token inference
Update jblas to 21757a4

Expected Behavior & Potential Risk
N/A
How has this PR been tested?

Interference result:
set -ex
#main branch
rm -rf bin && cmake .. -GNinja -DNE_BUILD_TESTS=ON -DNE_PROFILING=ON -DCMAKE_BUILD_TYPE=Release && ninja run_gptj && env ENGINE_PROFILING=1 numactl -m 1 -C 56-111 bin/run_gptj -m /home_local/dingyi/data/gpt-j-6B-pr347-q4j-sym-int8-fp32-g128.bin --seed 1234 -t 48 -b 2048 -c 2048 -n 1 -p "$LUOYU_PROMPT"
rm -rf bin && cmake .. -GNinja -DNE_BUILD_TESTS=ON -DNE_PROFILING=ON -DCMAKE_BUILD_TYPE=Release && ninja run_gptj && env ENGINE_PROFILING=1 numactl -m 1 -C 56-111 bin/run_gptj -m /home_local/dingyi/data/gpt-j-6B-pr347-q4j-sym-int8-fp32-g128.bin --seed 1234 -t 56 -b 2048 -c 2048 -n 1 -p "$LUOYU_PROMPT"
rm -rf bin && cmake .. -GNinja -DNE_BUILD_TESTS=OFF -DNE_PROFILING=OFF -DCMAKE_BUILD_TYPE=Release && ninja run_gptj && env --unset ENGINE_PROFILING numactl -m 1 -C 56-111 bin/run_gptj -m /home_local/dingyi/data/gpt-j-6B-pr347-q4j-sym-int8-fp32-g128.bin --seed 1234 -t 56 -b 2048 -c 2048 -n 32 -p "$GIRL_PROMPT"
#llama has different tokenizer and can only process a slightly shorter prompt
rm -rf bin && cmake .. -GNinja -DNE_BUILD_TESTS=ON -DNE_PROFILING=ON -DCMAKE_BUILD_TYPE=Release && ninja run_llama && env ENGINE_PROFILING=1 numactl -m 1 -C 56-111 bin/run_llama -m /home_local/dingyi/data/llama-7b-hf-pr347-q4j-sym-int8-fp32-g128.bin --seed 1234 -t 56 -b 2048 -c 2048 -n 1 -p "$(echo "$LUOYU_PROMPT" | cut -d' ' -f 1-1500)"
rm -rf bin && cmake .. -GNinja -DNE_BUILD_TESTS=OFF -DNE_PROFILING=OFF -DCMAKE_BUILD_TYPE=Release && ninja run_llama && env --unset ENGINE_PROFILING numactl -m 1 -C 56-111 bin/run_llama -m /home_local/dingyi/data/llama-7b-hf-pr347-q4j-sym-int8-fp32-g128.bin --seed 1234 -t 56 -b 2048 -c 2048 -n 32 -p "$GIRL_PROMPT"

#this branch
rm -rf bin && cmake .. -GNinja -DNE_BUILD_TESTS=ON -DNE_PROFILING=ON -DCMAKE_BUILD_TYPE=Release && ninja run_gptj && env ENGINE_PROFILING=1 numactl -m 1 -C 56-111 bin/run_gptj -m /home_local/dingyi/data/gpt-j-6B-pr347-q4j-sym-int8-fp32-g128.bin --seed 1234 -t 48 -b 2048 -c 2048 -n 1 -p "$LUOYU_PROMPT"
rm -rf bin && cmake .. -GNinja -DNE_BUILD_TESTS=ON -DNE_PROFILING=ON -DCMAKE_BUILD_TYPE=Release && ninja run_gptj && env ENGINE_PROFILING=1 numactl -m 1 -C 56-111 bin/run_gptj -m /home_local/dingyi/data/gpt-j-6B-pr347-q4j-sym-int8-fp32-g128.bin --seed 1234 -t 56 -b 2048 -c 2048 -n 1 -p "$LUOYU_PROMPT"
rm -rf bin && cmake .. -GNinja -DNE_BUILD_TESTS=OFF -DNE_PROFILING=OFF -DCMAKE_BUILD_TYPE=Release && ninja run_gptj && env --unset ENGINE_PROFILING numactl -m 1 -C 56-111 bin/run_gptj -m /home_local/dingyi/data/gpt-j-6B-pr347-q4j-sym-int8-fp32-g128.bin --seed 1234 -t 56 -b 2048 -c 2048 -n 32 -p "$GIRL_PROMPT"
#llama has different tokenizer and can only process a slightly shorter prompt
rm -rf bin && cmake .. -GNinja -DNE_BUILD_TESTS=ON -DNE_PROFILING=ON -DCMAKE_BUILD_TYPE=Release && ninja run_llama && env ENGINE_PROFILING=1 numactl -m 1 -C 56-111 bin/run_llama -m /home_local/dingyi/data/llama-7b-hf-pr347-q4j-sym-int8-fp32-g128.bin --seed 1234 -t 56 -b 2048 -c 2048 -n 1 -p "$(echo "$LUOYU_PROMPT" | cut -d' ' -f 1-1500)"
rm -rf bin && cmake .. -GNinja -DNE_BUILD_TESTS=OFF -DNE_PROFILING=OFF -DCMAKE_BUILD_TYPE=Release && ninja run_llama && env --unset ENGINE_PROFILING numactl -m 1 -C 56-111 bin/run_llama -m /home_local/dingyi/data/llama-7b-hf-pr347-q4j-sym-int8-fp32-g128.bin --seed 1234 -t 56 -b 2048 -c 2048 -n 32 -p "$GIRL_PROMPT"

Main branch

env ENGINE_PROFILING=1 numactl -m 1 -C 56-111 bin/run_gptj -m /home_local/dingyi/data/gpt-j-6B-pr347-q4j-sym-int8-fp32-g128.bin --seed 1234 -t 48 -b 2048 -c 2048 -n 1 -p "$LUOYU_PROMPT"

=== GRAPH Profiling ===
perf_total_per_op_us[                     ADD] =  55.135 ms
perf_total_per_op_us[                     MUL] =  15.932 ms
perf_total_per_op_us[                    NORM] =  25.274 ms
perf_total_per_op_us[                 MUL_MAT] =  81.835 ms
perf_total_per_op_us[       MUL_MAT_WITH_BIAS] =  59.493 ms
perf_total_per_op_us[                 RESHAPE] =   0.285 ms
perf_total_per_op_us[                    VIEW] =   0.750 ms
perf_total_per_op_us[                 PERMUTE] =   0.115 ms
perf_total_per_op_us[                GET_ROWS] =   7.722 ms
perf_total_per_op_us[                    ROPE] =  30.034 ms
perf_total_per_op_us[                 MUL_QKV] = 221.504 ms
perf_total_per_op_us[            FFN_ADD_GeLU] = 600.671 ms
perf_total_per_op_us[              FLASH_ATTN] = 209.671 ms
perf_total_per_op_us[    FLASH_ATTN_KV_UPDATE] =  94.790 ms
perf_total_per_op_us[           INNER PRODUCT] =   0.000 ms
========================================

env ENGINE_PROFILING=1 numactl -m 1 -C 56-111 bin/run_gptj -m /home_local/dingyi/data/gpt-j-6B-pr347-q4j-sym-int8-fp32-g128.bin --seed 1234 -t 56 -b 2048 -c 2048 -n 1 -p "$LUOYU_PROMPT"

=== GRAPH Profiling ===
perf_total_per_op_us[                     ADD] =  43.585 ms
perf_total_per_op_us[                     MUL] =  11.440 ms
perf_total_per_op_us[                    NORM] =  22.630 ms
perf_total_per_op_us[                 MUL_MAT] =  72.616 ms
perf_total_per_op_us[       MUL_MAT_WITH_BIAS] =  63.080 ms
perf_total_per_op_us[                 RESHAPE] =   0.320 ms
perf_total_per_op_us[                    VIEW] =   0.709 ms
perf_total_per_op_us[                 PERMUTE] =   0.098 ms
perf_total_per_op_us[                GET_ROWS] =   8.266 ms
perf_total_per_op_us[                    ROPE] =  33.194 ms
perf_total_per_op_us[                 MUL_QKV] = 207.260 ms
perf_total_per_op_us[            FFN_ADD_GeLU] = 584.771 ms
perf_total_per_op_us[              FLASH_ATTN] = 194.659 ms
perf_total_per_op_us[    FLASH_ATTN_KV_UPDATE] =  90.783 ms
perf_total_per_op_us[           INNER PRODUCT] =   0.000 ms
========================================

env --unset ENGINE_PROFILING numactl -m 1 -C 56-111 bin/run_gptj -m /home_local/dingyi/data/gpt-j-6B-pr347-q4j-sym-int8-fp32-g128.bin --seed 1234 -t 56 -b 2048 -c 2048 -n 32 -p "$GIRL_PROMPT"

Once upon a time, there existed a little girl, who liked to have adventures. She wanted to go to places and meet new people, and have fun. This girl went by the name of LittleRed Riding Hood.
One day Little Red Riding Hood was walking through the forest when she noticed someone following her. She
model_print_timings:        load time =  1083.34 ms
model_print_timings:      sample time =    28.25 ms /    32 runs   (    0.88 ms per token)
model_print_timings: prompt eval time =    89.23 ms /    32 tokens (    2.79 ms per token)
model_print_timings:        eval time =   716.09 ms /    31 runs   (   23.10 ms per token)
model_print_timings:       total time =  1842.00 ms
========== eval time log of each prediction ==========
prediction   0, time: 89.23ms
prediction   1, time: 28.39ms
prediction   2, time: 26.08ms
prediction   3, time: 23.91ms
prediction   4, time: 23.78ms
prediction   5, time: 24.07ms
prediction   6, time: 24.24ms
prediction   7, time: 23.89ms
prediction   8, time: 23.18ms
prediction   9, time: 22.95ms
prediction  10, time: 22.72ms
prediction  11, time: 22.56ms
prediction  12, time: 22.70ms
prediction  13, time: 22.48ms
prediction  14, time: 22.42ms
prediction  15, time: 22.27ms
prediction  16, time: 22.65ms
prediction  17, time: 22.93ms
prediction  18, time: 22.40ms
prediction  19, time: 22.64ms
prediction  20, time: 22.42ms
prediction  21, time: 22.71ms
prediction  22, time: 22.46ms
prediction  23, time: 22.66ms
prediction  24, time: 22.50ms
prediction  25, time: 22.40ms
prediction  26, time: 22.33ms
prediction  27, time: 22.53ms
prediction  28, time: 22.52ms
prediction  29, time: 22.74ms
prediction  30, time: 22.16ms
prediction  31, time: 22.38ms

env ENGINE_PROFILING=1 numactl -m 1 -C 56-111 bin/run_llama -m /home_local/dingyi/data/llama-7b-hf-pr347-q4j-sym-int8-fp32-g128.bin --seed 1234 -t 56 -b 2048 -c 2048 -n 1 -p "$(echo "$LUOYU_PROMPT" | cut -d' ' -f 1-1500)"

=== GRAPH Profiling ===
perf_total_per_op_us[                     ADD] =  61.765 ms
perf_total_per_op_us[                     MUL] =  40.942 ms
perf_total_per_op_us[                RMS_NORM] =  60.443 ms
perf_total_per_op_us[                 MUL_MAT] = 149.868 ms
perf_total_per_op_us[                 RESHAPE] =   0.450 ms
perf_total_per_op_us[                    VIEW] =   0.980 ms
perf_total_per_op_us[                 PERMUTE] =   0.115 ms
perf_total_per_op_us[               TRANSPOSE] =   0.103 ms
perf_total_per_op_us[                GET_ROWS] =   7.885 ms
perf_total_per_op_us[                    ROPE] =  50.016 ms
perf_total_per_op_us[                 MUL_QKV] = 285.974 ms
perf_total_per_op_us[                FFN_SILU] = 769.070 ms
perf_total_per_op_us[              FLASH_ATTN] = 223.920 ms
perf_total_per_op_us[    FLASH_ATTN_KV_UPDATE] = 100.957 ms
perf_total_per_op_us[           INNER PRODUCT] =   0.000 ms
========================================

env --unset ENGINE_PROFILING numactl -m 1 -C 56-111 bin/run_llama -m /home_local/dingyi/data/llama-7b-hf-pr347-q4j-sym-int8-fp32-g128.bin --seed 1234 -t 56 -b 2048 -c 2048 -n 32 -p "$GIRL_PROMPT"

Once upon a time, there existed a little girl, who liked to have adventures. She wanted to go to places and meet new people, and have fun.
Then one day, that little girl grew up. And she became a woman. A woman with a job, who travelled overseas for work,
model_print_timings:        load time =  1267.53 ms
model_print_timings:      sample time =    18.97 ms /    32 runs   (    0.59 ms per token)
model_print_timings: prompt eval time =   105.54 ms /    34 tokens (    3.10 ms per token)
model_print_timings:        eval time =   783.36 ms /    31 runs   (   25.27 ms per token)
model_print_timings:       total time =  2079.16 ms
========== eval time log of each prediction ==========
prediction   0, time: 105.54ms
prediction   1, time: 26.41ms
prediction   2, time: 25.19ms
prediction   3, time: 25.41ms
prediction   4, time: 25.37ms
prediction   5, time: 25.21ms
prediction   6, time: 25.17ms
prediction   7, time: 25.18ms
prediction   8, time: 25.28ms
prediction   9, time: 25.41ms
prediction  10, time: 25.21ms
prediction  11, time: 25.12ms
prediction  12, time: 25.15ms
prediction  13, time: 25.11ms
prediction  14, time: 25.07ms
prediction  15, time: 25.54ms
prediction  16, time: 25.32ms
prediction  17, time: 24.97ms
prediction  18, time: 25.49ms
prediction  19, time: 25.07ms
prediction  20, time: 25.04ms
prediction  21, time: 25.07ms
prediction  22, time: 25.33ms
prediction  23, time: 25.16ms
prediction  24, time: 25.20ms
prediction  25, time: 25.42ms
prediction  26, time: 25.51ms
prediction  27, time: 25.27ms
prediction  28, time: 25.41ms
prediction  29, time: 25.02ms
prediction  30, time: 25.28ms
prediction  31, time: 25.00ms

This branch

env ENGINE_PROFILING=1 numactl -m 1 -C 56-111 bin/run_gptj -m /home_local/dingyi/data/gpt-j-6B-pr347-q4j-sym-int8-fp32-g128.bin --seed 1234 -t 48 -b 2048 -c 2048 -n 1 -p "$LUOYU_PROMPT"

=== GRAPH Profiling ===
perf_total_per_op_us[                     ADD] =  49.759 ms
perf_total_per_op_us[                     MUL] =  14.224 ms
perf_total_per_op_us[                    NORM] =  22.228 ms
perf_total_per_op_us[                 MUL_MAT] =  81.711 ms
perf_total_per_op_us[       MUL_MAT_WITH_BIAS] =  59.821 ms
perf_total_per_op_us[                 RESHAPE] =   0.300 ms
perf_total_per_op_us[                    VIEW] =   0.700 ms
perf_total_per_op_us[                 PERMUTE] =   0.093 ms
perf_total_per_op_us[                GET_ROWS] =   7.708 ms
perf_total_per_op_us[                    ROPE] =  30.821 ms
perf_total_per_op_us[                 MUL_QKV] = 226.942 ms
perf_total_per_op_us[            FFN_ADD_GeLU] = 599.899 ms
perf_total_per_op_us[              FLASH_ATTN] = 146.544 ms
perf_total_per_op_us[    FLASH_ATTN_KV_UPDATE] =  56.004 ms
perf_total_per_op_us[           INNER PRODUCT] =   0.000 ms
========================================

env ENGINE_PROFILING=1 numactl -m 1 -C 56-111 bin/run_gptj -m /home_local/dingyi/data/gpt-j-6B-pr347-q4j-sym-int8-fp32-g128.bin --seed 1234 -t 56 -b 2048 -c 2048 -n 1 -p "$LUOYU_PROMPT"

=== GRAPH Profiling ===
perf_total_per_op_us[                     ADD] =  44.710 ms
perf_total_per_op_us[                     MUL] =  11.468 ms
perf_total_per_op_us[                    NORM] =  21.851 ms
perf_total_per_op_us[                 MUL_MAT] =  79.625 ms
perf_total_per_op_us[       MUL_MAT_WITH_BIAS] =  66.223 ms
perf_total_per_op_us[                 RESHAPE] =   0.334 ms
perf_total_per_op_us[                    VIEW] =   0.708 ms
perf_total_per_op_us[                 PERMUTE] =   0.118 ms
perf_total_per_op_us[                GET_ROWS] =   8.470 ms
perf_total_per_op_us[                    ROPE] =  42.760 ms
perf_total_per_op_us[                 MUL_QKV] = 215.438 ms
perf_total_per_op_us[            FFN_ADD_GeLU] = 592.271 ms
perf_total_per_op_us[              FLASH_ATTN] = 154.700 ms
perf_total_per_op_us[    FLASH_ATTN_KV_UPDATE] =  58.654 ms
perf_total_per_op_us[           INNER PRODUCT] =   0.000 ms
========================================

env --unset ENGINE_PROFILING numactl -m 1 -C 56-111 bin/run_gptj -m /home_local/dingyi/data/gpt-j-6B-pr347-q4j-sym-int8-fp32-g128.bin --seed 1234 -t 56 -b 2048 -c 2048 -n 32 -p "$GIRL_PROMPT"

Once upon a time, there existed a little girl, who liked to have adventures. She wanted to go to places and meet new people, and have fun. This girl went by the name of LittleRed Riding Hood.
One day Little Red Riding Hood was walking through the forest when she noticed someone following her. She
model_print_timings:        load time =  1040.85 ms
model_print_timings:      sample time =    32.42 ms /    32 runs   (    1.01 ms per token)
model_print_timings: prompt eval time =    88.35 ms /    32 tokens (    2.76 ms per token)
model_print_timings:        eval time =   724.59 ms /    31 runs   (   23.37 ms per token)
model_print_timings:       total time =  1812.39 ms
========== eval time log of each prediction ==========
prediction   0, time: 88.35ms
prediction   1, time: 26.03ms
prediction   2, time: 24.79ms
prediction   3, time: 24.79ms
prediction   4, time: 25.17ms
prediction   5, time: 25.08ms
prediction   6, time: 24.60ms
prediction   7, time: 23.21ms
prediction   8, time: 22.98ms
prediction   9, time: 23.08ms
prediction  10, time: 23.43ms
prediction  11, time: 23.05ms
prediction  12, time: 22.79ms
prediction  13, time: 23.11ms
prediction  14, time: 22.85ms
prediction  15, time: 22.78ms
prediction  16, time: 23.10ms
prediction  17, time: 23.08ms
prediction  18, time: 22.82ms
prediction  19, time: 23.02ms
prediction  20, time: 22.91ms
prediction  21, time: 23.00ms
prediction  22, time: 22.64ms
prediction  23, time: 22.92ms
prediction  24, time: 22.91ms
prediction  25, time: 22.67ms
prediction  26, time: 23.11ms
prediction  27, time: 22.85ms
prediction  28, time: 23.03ms
prediction  29, time: 22.81ms
prediction  30, time: 23.05ms
prediction  31, time: 22.96ms

env ENGINE_PROFILING=1 numactl -m 1 -C 56-111 bin/run_llama -m /home_local/dingyi/data/llama-7b-hf-pr347-q4j-sym-int8-fp32-g128.bin --seed 1234 -t 56 -b 2048 -c 2048 -n 1 -p "$(echo "$LUOYU_PROMPT" | cut -d' ' -f 1-1500)"

=== GRAPH Profiling ===
perf_total_per_op_us[                     ADD] =  45.444 ms
perf_total_per_op_us[                     MUL] =  25.363 ms
perf_total_per_op_us[                RMS_NORM] =  47.991 ms
perf_total_per_op_us[                 MUL_MAT] = 135.003 ms
perf_total_per_op_us[                 RESHAPE] =   0.427 ms
perf_total_per_op_us[                    VIEW] =   0.984 ms
perf_total_per_op_us[                 PERMUTE] =   0.108 ms
perf_total_per_op_us[               TRANSPOSE] =   0.102 ms
perf_total_per_op_us[                GET_ROWS] =   8.830 ms
perf_total_per_op_us[                    ROPE] =  50.482 ms
perf_total_per_op_us[                 MUL_QKV] = 277.234 ms
perf_total_per_op_us[                FFN_SILU] = 707.648 ms
perf_total_per_op_us[              FLASH_ATTN] = 187.805 ms
perf_total_per_op_us[    FLASH_ATTN_KV_UPDATE] =  72.886 ms
perf_total_per_op_us[           INNER PRODUCT] =   0.000 ms
========================================

env --unset ENGINE_PROFILING numactl -m 1 -C 56-111 bin/run_llama -m /home_local/dingyi/data/llama-7b-hf-pr347-q4j-sym-int8-fp32-g128.bin --seed 1234 -t 56 -b 2048 -c 2048 -n 32 -p "$GIRL_PROMPT"

Once upon a time, there existed a little girl, who liked to have adventures. She wanted to go to places and meet new people, and have fun.
Then one day, that little girl grew up. And she became a woman. A woman with a job, who travelled overseas for work,
model_print_timings:        load time =  1308.79 ms
model_print_timings:      sample time =    18.67 ms /    32 runs   (    0.58 ms per token)
model_print_timings: prompt eval time =   103.91 ms /    34 tokens (    3.06 ms per token)
model_print_timings:        eval time =   822.86 ms /    31 runs   (   26.54 ms per token)
model_print_timings:       total time =  2160.33 ms
========== eval time log of each prediction ==========
prediction   0, time: 103.91ms
prediction   1, time: 29.13ms
prediction   2, time: 28.06ms
prediction   3, time: 27.99ms
prediction   4, time: 28.03ms
prediction   5, time: 28.10ms
prediction   6, time: 27.85ms
prediction   7, time: 28.10ms
prediction   8, time: 27.98ms
prediction   9, time: 27.91ms
prediction  10, time: 27.99ms
prediction  11, time: 27.92ms
prediction  12, time: 27.93ms
prediction  13, time: 28.07ms
prediction  14, time: 28.06ms
prediction  15, time: 26.11ms
prediction  16, time: 27.22ms
prediction  17, time: 24.95ms
prediction  18, time: 25.32ms
prediction  19, time: 24.98ms
prediction  20, time: 25.28ms
prediction  21, time: 25.05ms
prediction  22, time: 24.94ms
prediction  23, time: 24.98ms
prediction  24, time: 25.09ms
prediction  25, time: 24.97ms
prediction  26, time: 25.02ms
prediction  27, time: 25.34ms
prediction  28, time: 25.38ms
prediction  29, time: 24.99ms
prediction  30, time: 24.75ms
prediction  31, time: 25.36ms

In conclusion, this PR should brings ~40% OP level performance for first-token inference in large scale problems for models that with fused MHA enabled, while not bringing any accuracy compromise. Next token optimization will be investigated later.
Dependency Change?
N/A

can you try more models to verify the performance gain?

can you try more models to verify the performance gain?

This improvement will only benefits models with fused MHA enabled (i.e. gptj & llama only by now).
I have added some test result for llama in the PR description. Looks that the result is similar with that of gptj.

ext test: https://inteltf-jenk.sh.intel.com/view/nlp-toolkit-validation/job/ITREX-cpp-graph-extension/97/

https://inteltf-jenk.sh.intel.com/job/ITREX-cpp-graph-extension/99/

authors: DDEle VincyZhang airMeng

repo: intel/intel-extension-for-transformers


text:
Root: Update Readme

Added Release Information table for better readability for users
Signed-off-by: chaitanya1731 chaitanya.kulkarni@intel.com

Done

source: gharchive/pull-request

license_type: permissive

license_source: github-api


text:
Remove capability from Intel lowering passes

This PR is for https://github.com/intel/intel-xpu-backend-for-triton/issues/764
These features controlled by capability are copied from NV passes and are not applicable for Intel GPUs, so simply remove them for now.

Please fix the below failures:
FAILED language/test_conversions.py::test_typeconvert_downcast[float32-float8e5-rtne-1197473792]
FAILED language/test_conversions.py::test_typeconvert_downcast[float32-float8e4nv-rtne-1138753536]
= 2 failed, 9861 passed, 187 skipped, 947 xfailed, 194 warnings in 673.75s (0:11:13) =

authors: LiyangLingIntel whitneywhtsang

repo: intel/intel-xpu-backend-for-triton

license: MIT


text:
Repeated test_e2e degrades cluster ability and leaves leftover LV volumes

I tried to repeat findings of https://github.com/intel/pmem-CSI/pull/278#issuecomment-492104594 but leaving out version change impact.
With code from current head of branch=devel, Clear VM cluster with make start,
using devicemode=LVM, repeated make test_e2e:

runs 1..7 PASS
run 8 FAIL "should fail when no volume capabilities are provided"
run 9 FAIL "sanity Node Service [It] should work"
run 10 FAIL "should fail when no volume capabilities are provided"
run 11 FAIL "should return appropriate values (no optional values added)"

seems repeated e2e runs degrade ability seriously, with errors varying.
Another finding: after 11 rounds, all nodes have leftover LV volumes with 4MB sizes
(so small not affecting provision ability via space exhaustion at least)

host-1: 63 volumes
host-2: 42 volumes
host-3: 7 volumes

We can suspect recent change to clear-based containers, but we don't have documented results of repeated e2e from times before container base change. That can be retested taking older code, I think

Olev Kartau notifications@github.com writes:

I tried to repeat findings of https://github.com/intel/pmem-CSI/pull/278#issuecomment-492104594 but leaving out version change impact.
With code from current head of branch=devel, Clear VM cluster with make start,
using devicemode=LVM, repeated make test_e2e:

runs 1..7 PASS
run 8 FAIL "should fail when no volume capabilities are provided"
run 9 FAIL "sanity Node Service [It] should work"
run 10 FAIL "should fail when no volume capabilities are provided"
run 11 FAIL "should return appropriate values (no optional values
added)"

Is that perhaps because of the volume leak that @avalluri found in
csi-sanity? The fix has been merged, but to get it, one currently has to
update to csi-test master.

seems repeated e2e runs degrade ability seriously, with errors varying.
Another finding: after 11 rounds, all nodes have leftover LV volumes with 4MB sizes
(so small not affecting provision ability via space exhaustion at least)

host-1: 63 volumes
host-2: 42 volumes
host-3: 7 volumes

That looks like the leak. However, as there is space left, why are tests
failing?
It sounds like we hit a scalability issue somewhere.

I repeated e2e tests 20 times with code at commit c1f09ba2d358124449d6734a5852cf50eb9c6858 i.e. last point before clear-based container was introduced.
1st round failed with
      ^[[91m[mktemp -d /var/lib/kubelet/plugins/kubernetes.io/csi/pv/pmem-sanity-target.XXXXXX] in socat container, stderr:
      Unexpected error:
          <exec.CodeExitError>: {
                  s: "command terminated with exit code 126",
          }

but next 19 rounds ran error-free.
After 20 rounds, the leftover LV counts:
host-1: 0
host-2: 0
host-3: 6

Olev Kartau notifications@github.com writes:

I repeated e2e tests 20 times with code at commit c1f09ba2d358124449d6734a5852cf50eb9c6858 i.e. last point before clear-based container was introduced.
1st round failed with
      ^[[91m[mktemp -d /var/lib/kubelet/plugins/kubernetes.io/csi/pv/pmem-sanity-target.XXXXXX] in socat container, stderr:
      Unexpected error:
          <exec.CodeExitError>: {
                  s: "command terminated with exit code 126",
          }

The command took too long. I was discussing this with @avalluri a few
days ago, we should increase the values in the csi-sanity test configuration.

good news for this issue: result is much better if tested with changes of #277 applied:
20 x repeated test_e2e with SUCCESS;
after test, leftover LV volumes:
host-1: 0 volumes
host-2: 1 volumes
host-3: 4 volumes
The repeated failures of "stat: no LV device" are not happening, I think that's because of "wait for device to appear" change, alse mutex change may have contributed. The leftover volumes amount dropped a lot.

degraded state and LVM-specific errors (including many-leftover-LVM-volumes) are mixed in this issue with few-leftover-volumes issue, but these seem to have different root causes, and few-leftover-volumes is not LVM specific but also can be seen in direct mode. So I will detach few- leftover-volumes issue from current issue by creating a new one. Then we can handle current issue as LVM-mode specific and get it covered by #277

source: gharchive/issue

authors: okartau pohly

repo: intel/pmem-CSI


text:
Variability in results using sklearnex with ExtraTrees and RandomForest classifiers

Describe the bug
Getting different results by turning on/off sklearnex with ExtraTrees and RandomForest algorithms.
This issue occurs starting with version 2024.1. I found it with my own dataset, and it's also reproducible with the breast_cancerdataset, but not with the iris dataset.
To Reproduce

Setup 'scikit-learn==1.5.1' (any version from 1.2.1)
Setup 'scikit-learn-intelex==2024.1' (any version from 2024.1)
Run the following test code:

import pandas as pd

from sklearnex import patch_sklearn
patch_sklearn()

from xgboost import XGBClassifier
from sklearn.ensemble import ExtraTreesClassifier, RandomForestClassifier
from sklearn.metrics import multilabel_confusion_matrix, confusion_matrix

from sklearn.model_selection import  cross_val_predict, train_test_split
from sklearn.preprocessing import LabelEncoder, StandardScaler, label_binarize
from sklearn.metrics import matthews_corrcoef, confusion_matrix
N_CORES = 16

# IN-HOUSE Data
# training_data = pd.read_csv('train_share.csv', header=None)
# test_data = pd.read_csv('test_share.csv',header=None)

# X_train = training_data.iloc[:,:2].to_numpy()
# y_train = training_data.iloc[:,2].to_numpy()

# X_test = test_data.iloc[:,:2].to_numpy()
# y_test = test_data.iloc[:,2].to_numpy()
# X_train, X_test, y_train, y_test = train_test_split(X_train,y_train, test_size=0.3, random_state=1)

# Toy Data

from sklearn.datasets import load_iris,load_breast_cancer
# data = load_iris()
data = load_breast_cancer()
X = data['data']
y = data['target']
X_train, X_test, y_train, y_test = train_test_split(X,y, test_size=0.3, random_state=1)

# Label Encoding
# le = LabelEncoder()
# le.fit(y_train)
# num_of_class = len(le.classes_)
# y_train = le.transform(y_train)
# y_test = le.transform(y_test)

# Feature Scaling
# sc = StandardScaler()
# X_train = sc.fit_transform(X_train)
# X_test = sc.transform(X_test)

# XGBOOST
# classifier_cv = XGBClassifier(n_estimators=300, random_state=1, n_jobs=N_CORES)
# classifier_test = XGBClassifier(n_estimators=300, random_state=1, n_jobs=N_CORES)

# RF
# classifier_cv = RandomForestClassifier(n_estimators=300, random_state=1, n_jobs=N_CORES)
# classifier_test = RandomForestClassifier(n_estimators=300, random_state=1, n_jobs=N_CORES)

# ExtraTrees
classifier_cv = ExtraTreesClassifier(n_estimators=300, random_state=1, n_jobs=N_CORES)
classifier_test = ExtraTreesClassifier(n_estimators=300, random_state=1, n_jobs=N_CORES)

cv_results = cross_val_predict(classifier_cv, X_train, y_train, cv=10)
classifier_test.fit(X_train, y_train)

test_results = classifier_test.predict(X_test)
print("###CV###")
print(matthews_corrcoef(y_train, cv_results))
print(confusion_matrix(y_train,cv_results).ravel())

print("###TEST###")
print(matthews_corrcoef(y_test, test_results))
print(confusion_matrix(y_test,test_results).ravel())

Expected behavior
Same results between using sklearnex and original sklearn.
Output/Screenshots
Before patching sklearnex with ExtraTrees
###CV###
0.935861738490973
[144   5   7 242]
###TEST###
0.9247930594534806
[ 58   5   1 107]

After patching sklearnex with ExtraTrees
Intel(R) Extension for Scikit-learn* enabled (https://github.com/intel/scikit-learn-intelex)
###CV###
0.9409328452526324
[143   6   5 244]
###TEST###
0.8992907835033845
[ 57   6   2 106]

Environment:

OS: Ubuntu 22.04.04 LTS
Scikit-learn==1.5.1 but I tested on 1.2.1, 1.3.x, 1.4.x.. etc.

Not sure whether it's related but if I use Intelex, I got a warning UserWarning: X does not have valid feature names, but ExtraTreesClassifier was fitted with feature names. Maybe there is a glitch in terms of handling the feature names or their orders by Intelex?

repo: intel/scikit-learn-intelex


text:
Design T6.5 conceputal achitecture diagrams

Design T6.5 arch conceptual diagrams including input from requirements analysis and interfaces with workflow composition and "quality and validation" modules.

Moved to Jira


text:
Make MDX2JSON web app as a parameter

Now /MDX2JSON is hardcoded. Make it configurable from some config.json in /dsw folder

Introduced config.json support in configs folder. Structure:
{
    "endpoints": {
        "mdx2json": "mdx2json"
    }
}

@TsvetkovAV maybe move tileserver here?

I think it is OK as a application-wide parameter. I doubt that there would
be cases with different tile servers on same ISC server.
But even if it would you can setup different DSW apps with different
/MDX2JSON and/or TILE servers
чт, 22 марта 2018 г. в 13:44, Aleksandr notifications@github.com:

If I'll do so then tileserver url will be set for application but as I
understood - it should be used only for specific namespace
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/intersystems-ru/DeepSeeWeb/issues/108#issuecomment-375259537,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACpyP7WXeLObfrUa1Jg3sBe3xo6j_VOJks5tg4CHgaJpZM4SvK3K
.

authors: eduard93 evshvarov gnibeda

repo: intersystems-ru/DeepSeeWeb

license: mit

license_source: bigquery


text:
🛑 Teylers Museum is down

In 334ea45, Teylers Museum (https://www.teylersmuseum.nl) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Teylers Museum is back up in 6c60e6a.

repo: intk/intk-upptime


text:
🛑 INU API is down

In 75c87fb, INU API (https://api.inuappcenter.kr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: INU API is back up in 711e5df after 1 minute.

repo: inu-appcenter/cafeteria-status


text:
Would it seem reasonable to add all SPDX licenses?

The SPDX License List is a list of commonly found licenses and exceptions used in free and open source and other collaborative software or documentation.
It also defines a standard short hand license identifier (which differs from your scheme).
Would you welcome a pull request where all licenses from the SPDX license list are added?
This would imply that there are two copies of "GPL-2.0+" since the same license is called "GPL-2.0-or-later" by SPDX and in the current file based scheme there is no way to have two identifiers for the same license.

It does seem reasonable, but there are... a lot of licenses in that list. And many of them will definitely never be used. So I feel like it would perhaps be a waste.
Maybe something more practical would be a SPDXLicense(id::AbstractString) plugin that allowed users to choose a license to be downloaded for them?

I am considering moving all these licenses into a another repository. I am sure other projects depend on Licenses too. Sometime this year i plan to create Licenses.jl or something like that.
I am not sure if the overhead if adding a downloader (and parsing) is worth the complexity for a few kilobytes of text.

FYI there'll eventually be an HTTP dependency for #113, so the dependency at least is not an issue.


text:
docs: MAINTAINERS file and LGTM configuration

Signed-off-by: Tibor Simko tibor.simko@cern.ch

LGTM

LGTM

authors: jirikuncar tiborsimko

repo: inveniosoftware/invenio-pidstore


text:
api: record dump fix

Record.dumps method returns a deep-copied dictionary.

Signed-off-by: Krzysztof Nowak k.nowak@cern.ch

It was a shallow copy before, and could lead to errors here: https://github.com/inveniosoftware/invenio-deposit/blob/master/invenio_deposit/api.py#L270-L274
Also, I think the method should be called dump or dump_dict as I believe the dumpS from json and alike was a reference to dump string.

Also, I think the method should be called dump or dump_dict as I believe the dumpS from json and alike was a reference to dump string.

Or maybe record.to_dict() like in elasticsearch_dsl

Coverage increased (+0.006%) to 97.994% when pulling ae2836c9e29b7c01a5fa342c4571b42e365212e5 on krzysztof:dumps_fix into 0be308b1f1c49675d3f06d2f1e47a3a46844ce4c on inveniosoftware:master.

Coverage increased (+0.006%) to 97.994% when pulling 512c76b7b0e6c3734260bbea884d00fce44d8879 on krzysztof:dumps_fix into 0be308b1f1c49675d3f06d2f1e47a3a46844ce4c on inveniosoftware:master.

authors: coveralls jmartinm krzysztof

repo: inveniosoftware/invenio-records


text:
[BUG] Build Order creating parts out of thin air

Hi,
Today I noticed what I consider to be a bug in the Build Orders, but I'm not so sure. I've searched a bit in past issues containing the word 'build order' but I could not find this reported yet. Btw my Build Order only contains Optional BOM's as I haven't found out how to make a BOM with at least one of the optional requirement.
Describe the bug
Build Output can be created without allocating stock, which (when people don't read carefully) results in parts created from thin air.
Steps to Reproduce
NOTE: If you refresh the page after creating a Build Output, confirming works again. Still I don't think this is expected behavior and in my opinion it would make sense to check for allocated stock before completing a Build Output so the allocated stock can actually be subtracted to reduce human errors.

Create a Build Order for a part.

Go to Build Output and create a new Build Output.

Confirm the creation of Build Output

Stock Item gets created already, with no source of parts
NOTE: If you want the to complete the Build Order now, there will be an error because there's no allocated stock, so that's as expected. Confirming the build as complete fails however as when clicking on Complete Build; nothing happens. (No forms get submitted)

Go to Build Order -> Allocate Stock

Click Auto Allocate

Click Confirm

Nothing happens (No forms get submitted)

Go to Build Order -> Allocate Stock

Click on a BOM Line Item -> Allocate Stock

Click Confirm

Nothing happens (No forms get submitted)

Expected behavior
Somewhere along the way I would expect an error. I think the best way to solve this is at the root, and check for allocated stock when creating a Build Output.
Deployment Method

[x] Bare Metal

Version Information
0.5.3 (Haven't gotten around to updating yet)

Hi,
So I'm not really sure what to do about this. I think it makes sense to check for allocated stock before creating Item Stock but ofcourse there's a feature in first completing 10 ouputs and then allocating stock afterwards... I'm conflicted. Please tell me what you think about this.
Kind regards,

@Guusggg thanks for raising this point. When I first implemented the build order process, I wanted to allow some flexibility.
By "flexibility", here I mean not forcing the user to fully complete every line to complete the build. Perhaps there is stock being allocated but has not been consolidated into the system, or maybe the build output has been completed "without" those items (maybe they're delivered late and will be allocated later)?
In any case, I think that the "build completion" process definitely needs to offer a more obvious warning that the build has not had all required parts allocated. An extra "are you sure" message, or something like that?

Maybe not allowing the build to complete before all stock is allocated?

Currently, a "warning message" is displayed but that does not actually stop the user from completing the build. I think some extra confirmation dialog which needs explicit consent from the user if the build has not been fully completed.
I agree that this is worthy of some attention and needs improving.

@SchrodingersGat Thank you so much for your comment. It's nice to know it's a valid concern, but I definitely understand that there hasn't been any need to change it yet. An extra "are you sure message" would more than solve my problem, as I know the Confirm dialog is there, but it is ignored.
(Just a side note, I"m really excited for 0.6.0 man, amazing work all you guys did. I don't want to upgrade to the latest yet as I know that 0.6.0 will blow me away lol)

authors: Guusggg SchrodingersGat

repo: inventree/InvenTree


text:
Fix completeSalesOrderShipment typo in sales_order.js

Fixes #4906

Nice catch @martonmiklos - we really need to get some CI testing on the front end code ASAP

Nice catch @martonmiklos -

Credits goes to @jelgersma

we really need to get some CI testing on the front end code ASAP

What is the plan for that (what technology do you prefer)?

What is the plan for that (what technology do you prefer)?

I don't really have enough knowledge about the unit testing frameworks available to make a call on that! Have to read some more. Can you make any recommendations?

I would say some linting would be enough for the first, as there is anyway the plan to switch to react with typescript?
Linting, eg with eslint would cover the undefined function references.

We already do run eslint - https://github.com/inventree/InvenTree/blob/master/.eslintrc.yml - so we should look into why it did not catch this incorrect function

authors: SchrodingersGat martonmiklos wolflu05


text:
feat: support --update-goldens

hello,
I have added support for --update-golden option. It works for --watch mode too, however, I had to filter some files from an observer.
I have added 'g' keyboard shortcut to toggling update goldens mode.

temporary I've pinned riverpod to 2.0.0-dev.3.
Closes #8
PS. It's my first contribution ever so sorry if I did something wrong.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

It'd be great if you could write a test that uses --update-goldens

Sure! I'll try to add something.

Awesome. I'll wait for it then. Otherwise your PR looks great, thanks for your work!

it's my pleasure

@rrousselGit I've added one test. Let me know if it is enough.
if you don't mind, I would like to add tests for the --watch too (I could do it not only for --update-goldens). However I think it's much more complex topic. Have you thought about it?

It's looking good
Watch mode is a bit tricky indeed. I haven't thought about it too much. I'm open to suggestions

To be honest I don't have idea yet ;) but I’ll think about it

Sorry for the delay. Thanks for this!

authors: CLAassistant rrousselGit trejdych

repo: invertase/spec


text:
What is "KEY" and No query results for model [App\Models\Company

When following documentation:
InvoiceNinja.configure(
  'KEY', // Set your company key or use 'KEY' to test
  url: 'https://demo.invoiceninja.com', // Set your selfhost app URL
  debugEnabled: true,
);

Where can I find the 'KEY'?  Nothing in the self-hosted installation is called a 'key'.  Is this supposed to say API Token?
If I assumed the API Token is what you meant, and my self hosted install is at mydomain.com/payments/public, when using the following:
InvoiceNinja.configure(
  'My API Token', // Set your company key or use 'KEY' to test
  url: 'https://mydomain.com/payments/public', // Set your selfhost app URL
  debugEnabled: true,
);

and I execute:
final products = await InvoiceNinja.products.load();
I end up with the following error:
{"message":"No query results for model [App\\Models\\Company]."}

However, if I run the following, the product list is returned in json as expected.
Future<List<InvoiceNinjaProduct>> _loadProductsByGet() async {
    String url = 'https://carlinehound.com/payments/public/api/v1/products';

    List data;
    List<InvoiceNinjaProduct> productList = [];

    var response = await http.get(Uri.encodeFull(url), headers: {
      'Content-Type': 'application/json',
      'X-Api-Secret': 'secret',
      'X-Api-Token': 'My API Token',
      'X-Requested-With': 'XMLHttpRequest'
    });

    var resBody = json.decode(response.body);

    data = resBody['data'];

    data.forEach((productJson) {
      InvoiceNinjaProduct product = InvoiceNinjaProduct.fromJson(productJson);
      productList.add(product);
    });

    print(productList[0].name);

    return productList;
  }

So the question is what is the "KEY"?

Hi,
I believe you're seeing the error b/c you're using v4

repo: invoiceninja/flutter-package


text:
[system crash]: startup crashes windows

Is there an existing issue for this?

[X] I have searched the existing issues

OS
Windows
GPU
cuda
VRAM
24
What version did you experience this issue on?
3.0.2 Post1
What happened?
installed with the installer package. after that is the configuration/downloads.
if i start invoke via the bat and chose the web option the script came to "Starting the InvokeAI browser-based UI.." then the the window froze. after a few seconds the whole system freezes completly. and a few seconds after that windows produces a blue screen. "DPC_Watchdog_Violation"
edit:
an older version of invoke v2.3.5P2 still works. have tryed v3.0.2 same crash result
anybody any idea where this came from ? everything other works fine so far. A1111/Comfy
Screenshots
No response
Additional context
No response
Contact Details
No response

From my searching, this error is typically related to corrupted or outdated drivers. Please update your GPU drivers, restart, and try again.

interesting idea ...the driver´s ...problem is ...theyre not to old.
had confirmed that on a other system. same driver version and it´s running. after that i asumed some hardware incompatibility with my main system. so i installed a full fresh windows on a secondary disk. installed the minimalist stuff to run invoke. drivers, (still old one) chipset driver, python, win runtime stuff and then invoke. and it works. there was a slightly issue with a missing packet. invoke wont download at startup. telling me something about certificates. turns out "certifi" has to be updated. done that and after that invoke get it´s last files and runs. no crash nothing. on the same hardware where it crashes with the other windows.
then on the "faulty" windows i cleaned the nvidia drivers. Display Driver Uninstaller DDU tool. then installed the same drivers again ...and tested invoke ...still crashing with the same behavior. so ...it´s still windows. thinking of it i deinstalled another tool which may be could have something todo with that. it´s an multi monitor manager. but this thing has ton´s of stuff inside which i dont need. it´s not starting with windows ...but it can potentially change a lot of stuff. all nearly related to gpu stuff. the only reason i have this is to change the monitor configuration (one off or on). but it turn´s out this was also not the problem candidate. and at the moment i have no other idea.
the only way seems to be install windows new. maybe i do that in a while. but if i do so ...and installed all the stuff again iam using ...maybe i reinstall some problem candidate again. and i dont know which one it is.
b.t.w. invoke 3.1.0 crashes also

It's related to some configuration or whatever is installed with the affected install of windows. I know you said the drivers are not old, but a driver update and/or reinstall is as much help as we can give you.

okay ...i give it a try. installed the newest ...and that is v537.13 ...make a reboot and try invoke ...aaaaaaaaanddd ...no. it still crashes happily.
and if i already wasting my time with this annoying issue i got into the cleaner windows and try´ed to install a few "things" which might cause this issue because on my working windows i use them. aaaaaaaand ....no. nothing brings the same crash. invoke starts and it runs as it should be. it´s not everything i could install if i fully reinstall windows and everything i want to use.
is there no log function which i can activate and maybe see what exactly invoke try´s todo at the crash moment ?
was the question i would like to ask ...but google was a little bit faster ...even if this seems not to work.
if found https://invoke-ai.github.io/InvokeAI/features/LOGGING/ this one. sounds nice ...but dont work ...or iam not able to bring it to work.
if i try this on my working windows (the crashy one) ...putting  "--log_handlers console syslog=/dev/log file=C:\temp\invokeai.log" to the start parameters ...i got ...a crash ...like all the other too. but thats interesting. sooooo ....i asking myself. what would a written log look like if invoke startup and dont crashes ? so i go to my testing windows (the working one) and try´ed that again. this time it vomit a bunch of errors an getting back to the startup choise. but theres some line that say´s syslog is not aviable on my system. yeah ...whatever. would be toooooo easy hmm ? but ...if invoke exited AND telling me theres an problem ...and not crashing to bluescreen ...why did the working pc version of invoke dont tells me that syslog is not aviable ? this one crashes and say nothing ? what did he even doing to crash "before" he is able to tell me syslog is not an option and exiting without crashing ?
so ...logging seems to be no help ? what now ? ...now. if invoke startup´s it tells me some "patchmatch" is loaded. one the crashing windows i never saw this message. so ...did it fail at loading patchmacht ? ahh ...okay ...and ...hey google ...what is patchmatch ?
https://invoke-ai.github.io/InvokeAI/installation/060_INSTALL_PATCHMATCH/
interesting ...so ...what would invoke do if i delete the folder calles patchmatch ? vomit a bunch of errors again ? yeah ...ok. that was not nice. but ...on the invoke doku it say´s "It is not needed to run InvokeAI" ...ohh okay. and why it exitet happily with a bunch of errors ? now ...whatever.
i try´ed this on my crashing windows. delete that folder and hoping invoke would produce the same. exiting with a bunch of errors. but not crashing because it cant load it. but noooo ...invoke crashes as if nothing happened. but that tells me two thing. one ...it´s not the load of patchmatch which caused the crash. two ...it´s not the state where the invoke exe is able to exit correctly because it´s finaly noticed that it cant go on because syslog is not aviable.
so ...what try´es invoke todo before the loading of patchmatch ? and before the syslog fail exiting ?

okay ...i give it a try. installed the newest ...and that is v537.13 ...make a reboot and try invoke ...aaaaaaaaanddd ...no. it still crashes happily.
and if i already wasting my time with this annoying issue i got into the cleaner windows and try´ed to install a few "things" which might cause this issue because on my working windows i use them. aaaaaaaand ....no. nothing brings the same crash. invoke starts and it runs as it should be. it´s not everything i could install if i fully reinstall windows and everything i want to use.
is there no log function which i can activate and maybe see what exactly invoke try´s todo at the crash moment ?
was the question i would like to ask ...but google was a little bit faster ...even if this seems not to work.
if found https://invoke-ai.github.io/InvokeAI/features/LOGGING/ this one. sounds nice ...but dont work ...or iam not able to bring it to work.
if i try this on my working windows (the crashy one) ...putting  "--log_handlers console syslog=/dev/log file=C:\temp\invokeai.log" to the start parameters ...i got ...a crash ...like all the other too. but thats interesting. sooooo ....i asking myself. what would a written log look like if invoke startup and dont crashes ? so i go to my testing windows (the working one) and try´ed that again. this time it vomit a bunch of errors an getting back to the startup choise. but theres some line that say´s syslog is not aviable on my system. yeah ...whatever. would be toooooo easy hmm ? but ...if invoke exited AND telling me theres an problem ...and not crashing to bluescreen ...why did the working pc version of invoke dont tells me that syslog is not aviable ? this one crashes and say nothing ? what did he even doing to crash "before" he is able to tell me syslog is not an option and exiting without crashing ?
so ...logging seems to be no help ? what now ? ...now. if invoke startup´s it tells me some "patchmatch" is loaded. one the crashing windows i never saw this message. so ...did it fail at loading patchmacht ? ahh ...okay ...and ...hey google ...what is patchmatch ?
https://invoke-ai.github.io/InvokeAI/installation/060_INSTALL_PATCHMATCH/
interesting ...so ...what would invoke do if i delete the folder calles patchmatch ? vomit a bunch of errors again ? yeah ...ok. that was not nice. but ...on the invoke doku it say´s "It is not needed to run InvokeAI" ...ohh okay. and why it exitet happily with a bunch of errors ? now ...whatever.
i try´ed this on my crashing windows. delete that folder and hoping invoke would produce the same. exiting with a bunch of errors. but not crashing because it cant load it. but noooo ...invoke crashes as if nothing happened. but that tells me two thing. one ...it´s not the load of patchmatch which caused the crash. two ...it´s not the state where the invoke exe is able to exit correctly because it´s finaly noticed that it cant go on because syslog is not aviable.
so ...what try´es invoke todo before the loading of patchmatch ? and before the syslog fail exiting ?

I'm sorry, that's a lot of text and it's not clear what is being asked. Can you please sum it up in a sentence or two?

at the startup of invoke web mode. what is the exe doing before the console is typing that he loads patchmatch ?

If I understand your question, the application is attempting to compile the PatchMatch library, which is used for outpainting. There is no exe, it's a python script.
You've mentioned some errors. Please copy and paste any errors here so we can review them.

Sorry for the late reply. The exe simply runs the python application. If you still have this same problem on the latest release (v4.1.0), please copy the terminal output including error messages and comment on this issue. We can investigate further with more information.

repo: invoke-ai/InvokeAI


text:
[bug]: Inpainting with SDXL at low denoising strength produces blocky results

Is there an existing issue for this?

[x] I have searched the existing issues

OS
Windows
GPU
cuda
VRAM
8GB
What version did you experience this issue on?
3.1.1
What happened?
When I tried inpainting an image with SDXL at 0.3 denoising strength, only 3-4 iterations are executed instead of the specified 20 steps. This results in a blocky result.
Screenshots

Additional context
No response
Contact Details
No response

This isn’t a bug! :)
When you use a denoising strength, you’re specifically setting a % of your input steps to be used. In the case of a .3 strength, you’d want to ensure you set your steps to something like 30 or 40 so that you have sufficient steps to avoid the noise artifacts.

authors: filiptrplan hipsterusername


text:
🛑 Bitwage API (Sandbox) is down

In ce048f0, Bitwage API (Sandbox) (https://api.sandbox.bitwage.com) was down:

HTTP code: 403
Response time: 271 ms

Resolved: Bitwage API (Sandbox) is back up in 8072f13 after 6 minutes.


text:
🛑 Bitwage API (Sandbox) is down

In ad35e8c, Bitwage API (Sandbox) (https://api.sandbox.bitwage.com) was down:

HTTP code: 403
Response time: 96 ms

Resolved: Bitwage API (Sandbox) is back up in 26d864f after 13 minutes.


text:
🛑 Bitwage API (Sandbox) is down

In 893a135, Bitwage API (Sandbox) (https://api.sandbox.bitwage.com) was down:

HTTP code: 403
Response time: 175 ms

Resolved: Bitwage API (Sandbox) is back up in 8ab581d after 13 minutes.


text:
🛑 Bitwage API (Sandbox) is down

In e1c46d8, Bitwage API (Sandbox) (https://api.sandbox.bitwage.com) was down:

HTTP code: 403
Response time: 331 ms

Resolved: Bitwage API (Sandbox) is back up in f483add after 27 minutes.


text:
🛑 Bitwage API (Sandbox) is down

In 190bcff, Bitwage API (Sandbox) (https://api.sandbox.bitwage.com) was down:

HTTP code: 403
Response time: 55 ms

Resolved: Bitwage API (Sandbox) is back up in 3ae6c3a after 32 minutes.


text:
Update image data alignment implementation

The spec now requires that the image data start on an offset that's a multiple of 16, and requires that the total serialized size of data be padded up to a multiple of 16.

Nope, this is gone from the spec now.

Actually, the spec does still say this, but the spec is wrong.

license: ISC


text:
Add support for unsorted NdMappings

In theory there is no reason why all our NdMapping types have to be sorted. Early on we thought it would be simpler forcing them to always be sorted but they use an OrderedDict internally and if we just gave them a sorted parameter the sorting order would persist when you clone the NdMappings. My suggestion would be to have a sort parameter on NdMappings, which is True by default maintaining backwards compatibility but if you want to create an NdMapping explicitly you can just set the parameter to False in the constructor and that ordering would be maintained even if you apply various methods or operations to the object.

Sounds good but I'm not sure sort=False makes sense with vanilla dictionaries as they have an undefined order anyway. Maybe it could warn if sort=False and the dictionary isn't an ordered dictionary.

Sure, could check that, valid constructors are dicts, lists of key, value tuples and OrderedDict. The latter two would behave correctly while dicts would warn.
I've assigned this to the 2.0 milestone, but as far as I can tell this requires nothing more than adding the parameter, adding one conditional check on the sorting, and the warning for dicts. Should we just do it now?

Given that the default behavior would be backwards compatible, I don't see why not!

Implemented in #1217.

authors: jlstevens philippjfr

repo: ioam/holoviews


text:
Driverv don't work after update js-controller: 4.0.23->4.0.24

Hello.
Driverv don't work after update js-controller: 4.0.23->4.0.24
`

telegram.0
2023-01-16 19:16:39.298
error
getMe (reconnect #10) Error:Error: EFATAL: Error: getaddrinfo EAI_AGAIN api.telegram.org

telegram.0
2023-01-16 19:14:49.106
error
getMe (reconnect #0) Error:Error: EFATAL: Error: getaddrinfo EAI_AGAIN api.telegram.org

telegram.0
2023-01-16 19:14:39.085
error
getMe Error:Error: EFATAL: Error: getaddrinfo EAI_AGAIN api.telegram.org

telegram.0
2023-01-16 19:14:29.086
error
setWebHook Error:Error: EFATAL: Error: getaddrinfo EAI_AGAIN api.telegram.org

telegram.0
2023-01-16 19:14:19.028
debug
Start polling with: 300(number) ms interval

telegram.0
2023-01-16 19:14:18.807
debug
Schedule restart: * */12 * * *

telegram.0
2023-01-16 19:14:18.759
info
starting. Version 1.15.2 in /opt/iobroker/node_modules/iobroker.telegram, node: v14.21.2, js-controller: 4.0.24

telegram.0
2023-01-16 19:14:18.473
debug
Plugin sentry Initialize Plugin (enabled=true)

telegram.0
2023-01-16 19:14:11.775
info
Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason

telegram.0
2023-01-16 19:14:11.774
debug
Plugin sentry destroyed

telegram.0
2023-01-16 19:14:11.773
info
terminating

telegram.0
2023-01-16 19:14:11.271
info
Got terminate signal TERMINATE_YOURSELF

telegram.0
2023-01-16 19:14:10.769
error
getMe (reconnect #0) Error:Error: EFATAL: Error: getaddrinfo EAI_AGAIN api.telegram.org

`

Thiserror has nothing to do with the js-controller upgrade normally ... The error means that there is a DNS issue with resolving the given domainnname!
Error: getaddrinfo EAI_AGAIN api.telegram.org
Please check your DNS

I execte ping on a iobroker server
ping api.telegram.org
PING api.telegram.org (149.154.167.220) 56(84) bytes of data.
64 bytes from 149.154.167.220 (149.154.167.220): icmp_seq=1 ttl=55 time=67.6 ms
64 bytes from 149.154.167.220 (149.154.167.220): icmp_seq=2 ttl=55 time=73.3 ms

I can only state what the error message is about ... it means that the nodejs process was not able to lookup the IP for the domainname


text:
cannot find start file

cannot find start file
Iobroker Fix Script laufen lassen (Danke @Apollon77 !)
Habe den Adapter über das Github Symbol installiert, danach keine Instanz gefunden, aber in der Repository den Adapter gefunden und von dort dann installiert.
Nach dem Eingeben der FB-Verbindungsdaten Auszug im Log:
host.raspberrypi	2019-05-31 11:37:21.909	error	startInstance tr-064-community.0: cannot find start file!
host.raspberrypi	2019-05-31 11:37:21.905	info	"system.adapter.tr-064-community.0" enabled
Alter Adapter von Soef ist noch installiert aber Instanz gestoppt.

Nochmals alles installiert, keine Änderungen vorgenommen. Jetzt wird die Instanz gestartet.


text:
Fix mouse wheel scroll

I've noticed that mouse wheel scroll event didn't work for me for some reason.
Apparently update_mouse() was overwriting the value to 0.0
Also needed to update the dependencies to get rid of #17.
[dependencies]
ggez = "0.5.1"

gfx_core = "0.9.2"
gfx_device_gl = "0.16.2"

imgui = "0.4"
imgui-gfx-renderer = "0.4"

Looks like cargo update is required to finally avoid the #17. It was performed, so Cargo.lock is updated.
Probably solves #15, though I didn't test every little thing of imgui's test window, so 'it just works'

System: Ubuntu 18.04
Rust: rustc 1.46.0-nightly

this is great, thank you! 🚀

authors: iolivia qezz

repo: iolivia/imgui-ggez-starter


text:
API is not reachable - MacOS

Hi,
Podman commands are running fine, a podman machine is started but I can't connect using podman-desktop-companion.
I get 'API not reachable' when I test the connection (the socket file in the connection string exists on my disk). From the logs, the query of the socket is going in timeout.
How can I determine the connection string for my podman machine ?

Can you copy paste that curl command to your terminal and reply with the
output? Thanks
On Fri, 29 Jul 2022, 18:10 Destrais, @.***> wrote:

Hi,
Podman commands are running fine, a podman machine is started but I can't
connect using podman-desktop-companion.
I get 'API not reachable' when I test the connection (the socket file in
the connection string exists on my disk). From the logs, the query of the
socket is going in timeout.
How can I determine the connection string for my podman machine ?
[image: image]
https://user-images.githubusercontent.com/11016696/181794535-d1642dff-0c34-40dd-a67a-36782ba5e68e.png
—
Reply to this email directly, view it on GitHub
https://github.com/iongion/podman-desktop-companion/issues/100, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGT2GKQQJ4EKMSPYFJDAVLVWP7AXANCNFSM55BHYM4A
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Here is the output :
curl -v -X GET --unix-socket "/Users/pdestrais/.local/share/containers/podman/machine/podman-machine-default/podman.sock" "http://d/v3.0.0/libpod/_ping" -H "Accept: application/json" -H "Content-Type: application/json"
Note: Unnecessary use of -X or --request, GET is already inferred.

Trying /Users/pdestrais/.local/share/containers/podm:0...
Connected to d (/Users/pdestrais/.local/share/containers/podm) port 80 (#0)

GET /v3.0.0/libpod/_ping HTTP/1.1
Host: d
User-Agent: curl/7.79.1
Accept: application/json
Content-Type: application/json

Empty reply from server
Closing connection 0
curl: (52) Empty reply from server

Thanks, what about this:
curl -i -v --unix-socket "/Users/pdestrais/.local/share/containers/podman/machine/podman-machine-default/podman.sock" "http://d/v3.0.0/libpod/_ping" -H "Accept: application/json" -H "Content-Type: application/json"

Same result :-(

Can you take a screenshot ? I want to see the status codes and headers please

This is how it looks for me on linux (using podman machine)
curl -i -v --unix-socket "/home/istoica/.local/share/containers/podman/machine/podman-machine-default/podman.sock" "http://d/v3.0.0/libpod/_ping" -H "Accept: application/json" -H "Content-Type: application/json"
*   Trying /home/istoica/.local/share/containers/podman/:0...
* Connected to d (/home/istoica/.local/share/containers/podman/) port 80 (#0)
> GET /v3.0.0/libpod/_ping HTTP/1.1
> Host: d
> User-Agent: curl/7.84.0
> Accept: application/json
> Content-Type: application/json
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Api-Version: 1.40
Api-Version: 1.40
< Builder-Version:
Builder-Version:
< Buildkit-Version:
Buildkit-Version:
< Cache-Control: no-cache
Cache-Control: no-cache
< Docker-Experimental: true
Docker-Experimental: true
< Libpod-Api-Version: 4.1.0
Libpod-Api-Version: 4.1.0
< Libpod-Buildah-Version: 1.26.1
Libpod-Buildah-Version: 1.26.1
< Pragma: no-cache
Pragma: no-cache
< Server: Libpod/4.1.0 (linux)
Server: Libpod/4.1.0 (linux)
< X-Reference-Id: 0xc000bc2640
X-Reference-Id: 0xc000bc2640
< Date: Mon, 01 Aug 2022 06:27:39 GMT
Date: Mon, 01 Aug 2022 06:27:39 GMT
< Content-Length: 2
Content-Length: 2
< Content-Type: text/plain; charset=utf-8
Content-Type: text/plain; charset=utf-8

<
* Connection #0 to host d left intact
OK

Seem you might have some trouble with the podman machine.
You can try to re-create and update the podman machine for maybe different outcome
podman machine stop
podman machine rm
podman machine init

You were right, my podman machine had an issue. After removing and creating a new one, everything is fine now. Thank you for your quick support !!

Glad it helped, closing the issue.

authors: iongion pdestrais

repo: iongion/podman-desktop-companion


text:
fix(core): change 'OpaqueToken' to 'InjectionToken'

BREAKING CHANGE: OpaqueToken has been removed as it was deprecated since v4. Use InjectionToken instead.
fixed #63 #13385

@dwieeb could you please merge this pull requests ?

When is this being merged? I'd like to use this fix  :)

does it works like a drop in replacement?  InjectionToken needs type...
class OpaqueToken {
  constructor(_desc: string)
  protected _desc: string
  toString(): string
}

class InjectionToken<T> {
  constructor(_desc: string)
  protected _desc: string
  toString(): string
}

Please merge this PR!

authors: dtaalbers minusf wilgert yemenifree youssmak

repo: ionic-team/ionic-cloud-angular


text:
Tunnel.Consumer does not work with stencil version 0.16

The only way I could continue to use Tunnel was to use injectProps
basically the following code doesnt work anymore with the latest version:
render () {
  return (<Tunnel.Consumer>{(props) => {
        // props is now always an empty object :(
        ...
     })
  </Tunnel.Consumer>)
}

@MattMcFarland for what I've seen, it's working OK on 0.16.0. Did you try to upgrade?

We have tried the upgrade and it still is not working.  Will continue to investigate.

Yea 0.16 the props are an empty object.  I'm going to create a brand new project and see if I can reproduce this outside of my work project.  Just to be certain its a stencil-state-tunnel problem or not.

@MattMcFarland can you share how are you using the Tunnel.Provider side?

authors: MattMcFarland joelalejandro

repo: ionic-team/stencil-state-tunnel


text:
New varible for SiteContents to determine build type

This gives a cleaner way to test whether the refresh js socket should be injected or not

Hey,
I’ve been thinking about something like that for a while and I think I’d prefer to use #WATCH define  when it watch-mode rather than passing bool around.

I think this would be easier to implement:
#if WATCH
#endif

Does that look okay?

Oh, that's exactly what I've meant.  I shouldn't write messages on GitHub before first tea ;-)

I've implemented this in b8fffa974d43a99744a65e75a1ff44a89bbc83e4

authors: Krzysztof-Cieslak robertpi

repo: ionide/Fornax


text:
add ionosctl as snap

What does this fix or implement?
Allows ionosctl to be built as a snap.
Checklist

[X] PR name added as appropriate (e.g. feat:/fix:/doc:/test:/refactor:)
[ ] Tests added or updated
[ ] Documentation updated
[ ] Sonar Cloud Scan
[ ] Changelog updated and version incremented (label: upcoming release)
[ ] Github Issue linked if any
[ ] Jira task updated

Looks good to me. +1
My only suggestion would be to update the documentation (README files) with the installation steps for snap support. This can also be added later on, with the other package managers support, but just have it in mind.

Will be added, but the snap needs to be first published and accepted to a stable channel.

repo: ionos-cloud/ionosctl


text:
implement remove_neighbors serialization

#876
implement cclient/serializer/json:remove_neighbors - serialize response & deserialize request

Hi @HowJMay please fix conflicts, thanks.

authors: HowJMay oopsmonk

repo: iotaledger/entangled


text:
feat: adds update stronghold logic

Summary
Same in https://github.com/iotaledger/firefly/pull/6123 just with a different base branch
Testing
Platforms

Desktop

[ ] MacOS
[ ] Linux
[x] Windows

Mobile

[ ] iOS
[ ] Android

Checklist

[x] I have followed the contribution guidelines for this project
[x] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[x] I have added or modified tests that prove my changes work as intended
[x] I have verified that new and existing unit tests pass locally with my changes
[x] I have verified that my latest changes pass CI workflows for testing and linting
[ ] I have made corresponding changes to the documentation

Closing so we review it once into develop and create a new release branch

authors: jeeanribeiro nicole-obrien

repo: iotaledger/firefly


text:
Update wiki cli 0.6

Description of change
With the update of the wiki from GitHub Pages to vercel we broke all relative links that don't use file extensions.
So I updated the cli (which from now on should detect those broken links again) and fixed already existing broken links.
Sorry for the inconvenience.
Type of change

Documentation Fix

How the change has been tested
Tested locally and the docs test workflow should succeed too
Change checklist

[x] My code follows the contribution guidelines for this project
[x] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes

Should the overview links all contain the .md extension as well?

Same as https://github.com/iotaledger/identity.rs/pull/1153#issuecomment-1510418972

authors: Dr-Electron eike-hass


text:
block_parents_index is too big

Bug description
On the shimmer beta chronicle instance, this index is almost 8GB. This is much too large. We must find a way to provide the benefits of an index without trying to keep all of that in memory. Perhaps a materialized view?
Chronicle version

Chronicle version: 1.0.0-beta.36

This may be an unfixable issue, simply a fact of life for big data storage. However, eventually we may need to consider options for managing the size of our data.

repo: iotaledger/inx-chronicle


text:
Add Windows requirements

Description of change
Refactored the Rust getting started page in regards to the windows requirements
Type of change

Documentation Fix

Change checklist

[x] I have followed the contribution guidelines for this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have checked that new and existing unit tests pass locally with my changes

I added the prerequisites to the rust page.
Removed the openssl and cmake guide as it wasn't needed for me to install those.
Added a one liner for windows to install everything needed.
Added tokio to the example Cargo.toml as it is needed in the example afterwards. (Highlighted the iota-wallet line).
Fixed the example code

Are cmake and openssl still required to be installed? I now tested on macOS too and it doesn't seem to be needed there either. (Openssl was there by default)

Are cmake and openssl still required to be installed? I now tested on macOS too and it doesn't seem to be needed there either. (Openssl was there by default)

I think it's still required

Hmm. I definitively didn’t have cmake installed. 🤔

Hmm. I definitively didn’t have cmake installed. thinking

Hm maybe it just needs a C compiler, in the workflow we just install clang for windows https://github.com/iotaledger/wallet.rs/blob/develop/.github/workflows/build-and-test.yml

authors: Dr-Electron Thoralf-M


text:
Restore presence on AMO

IPFS Companion got temporarily hidden from addons.mozilla.org due to manual review.
We are working on complying with requests and suggestions from AMO reviewers.
Updates will be published below.
cc  https://github.com/ipfs-shipyard/ipfs-companion/issues/306
Timeline (continued in comments)
2019-01-31
Manual review triggered due to build issue, we replied on the same day providing build steps:

[ Click to expand conversation ]

This version contains obfuscated, minified, concatenated or otherwise machine-generated code. Please provide the original sources, together with instructions on how to generate the final XPI. Source code must be provided as an archive and uploaded using the source code upload field, which can be done during submission or on the version page in the developer hub.
Please read through the instructions at https://developer.mozilla.org/en-US/Add-ons/Source_Code_Submission.

Are you able to provide more details? Which specific part (files, paths) of extension triggered this action?
We had similar request in past (for v2.4.2) and since then we always attach .zip with sources for every release and did the same for this one. The file included README with reproducible build instructions (copy below).
Reproducible build (requires Docker): npm run release-build
Regular build (no Docker): npm run dev-build
"release-build" is an alias for running build script inside of an immutable Docker image with specific version of Node, yarn and crypto toolkit, which guarantees the same node version and minified output on all platforms.
Related docs:
https://github.com/ipfs-shipyard/ipfs-companion#development
https://github.com/ipfs-shipyard/ipfs-companion#reproducible-build-in-docker
https://github.com/ipfs/ipfs-companion/issues/306 (reproducible build issue – please comment if we do something wrong or could do better in this area)

2019-01-01
Reply from Reviewer suggesting the issue is resolved

Thank you for the prompt response. It seems I was looking at an older version. The source code for this one was provided correctly.

2019-01-01
Reply from Reviewer suggesting the webui is still missing
Replied on the same day:

[ Click to expand conversation ]

I've built your add-on on Ubuntu 18.04 using npm i, npm run release-build, but webui folder is missing from the build.

Interesting! Current build pipeline downloads prebuilt  webui (sources at https://github.com/ipfs-shipyard/ipfs-webui) from IPFS instead of NPM. I assume your VM did not have IPFS installed, but it should fallback to  fetching dependency from public HTTP gateway. Did your VM block HTTP GET from: https://ipfs.io/api/v0/get?arg=QmXc9raDM1M5G5fpBnVyQ71vR4gbnskwnB9iMEzBuLgvoZ&archive=true&compress=true ? Are you able to retry?

2019-02-08
Reply from Reviewer being unable to reproduce:

I tried it again but it got stuck at:
$ ./ci/update-manifest.sh ; npx yarn@1.12.3 build ; chmod -R ugo+rwX build/ add-on/
fatal: Not a git repository (or any of the parent directories): .git

Mentioned error should not break the build and in the following two days we were trying to reproduce issues with the build locally without any success.
2019-02-10
Extension hidden due to reproducibility issues:

This version didn't pass review because of the following problems:
1) We couldn't reproduce the build.
Please submit a new version and provide all requested information at your convenience.

Due to the lack of better ideas I tracked down the issue with missing ".git" in .zip file and added a fix to make 'npm run release-build' work again without that error message.
Uploaded new version (v2.7.2) - ready for review again.
2019-02-11
Reviewer is still unable to reproduce and sends build log:

I tried it again on Ubuntu 18.04 and ran npm run release-build, but I'm getting some errors. I'm pasting here the build log:

[ Click to expand build log ]
npm run release-build

> ipfs-companion@ release-build /home/ralli/Downloads/ipfs-companion-2.7.2-src/ipfs-companion-2.7.2

> docker build -t ipfs-companion . && docker run -it -e RELEASE_CHANNEL=stable -v $(pwd)/build:/usr/src/app/build ipfs-companion yarn ci:build

Sending build context to Docker daemon  2.593MB

Step 1/9 : FROM node:10.11.0

 ---> 8672b25e842c

Step 2/9 : RUN mkdir -p /usr/src/app

 ---> Using cache

 ---> 4786f66115c5

Step 3/9 : WORKDIR /usr/src/app

 ---> Using cache

 ---> cd7705735ebc

Step 4/9 : ENV PATH="/usr/src/app/node_modules/.bin:${PATH}"

 ---> Using cache

 ---> bec1a88c69a7

Step 5/9 : RUN curl -s https://ipfs.io/ipfs/QmbukYcmtyU6ZEKt6fepnvrTNa9F6VqsUPMUgNxQjEmphH > /usr/local/bin/jq && chmod +x /usr/local/bin/jq

 ---> Using cache

 ---> 008ebd78a635

Step 6/9 : COPY package.json /usr/src/app/package.json

 ---> b15bbf53362c

Step 7/9 : COPY yarn.lock /usr/src/app/yarn.lock

 ---> 6cc27c19c99a

Step 8/9 : RUN npm run ci:install

 ---> Running in ed0d901155c0

> ipfs-companion@ ci:install /usr/src/app

> npx yarn@1.12.3 install --frozen-lockfile || npx yarn@1.12.3 install --frozen-lockfile

npx: installed 1 in 4.532s

yarn install v1.12.3

[1/4] Resolving packages...

warning Resolution field "multiaddr@6.0.3" is incompatible with requested version "multiaddr@^5.0.2"

warning Resolution field "multiaddr@6.0.3" is incompatible with requested version "multiaddr@^5.0.2"

warning Resolution field "multiaddr@6.0.3" is incompatible with requested version "multiaddr@^5.0.0"

warning Resolution field "multiaddr@6.0.3" is incompatible with requested version "multiaddr@^5.0.2"

warning Resolution field "multiaddr@6.0.3" is incompatible with requested version "multiaddr@^5.0.0"

warning Resolution field "multiaddr@6.0.3" is incompatible with requested version "multiaddr@^5.0.2"

warning Resolution field "multiaddr@6.0.3" is incompatible with requested version "multiaddr@^4.0.0"

warning Resolution field "multiaddr@6.0.3" is incompatible with requested version "multiaddr@^5.0.2"

warning Resolution field "multiaddr@6.0.3" is incompatible with requested version "multiaddr@^5.0.0"

warning Resolution field "stream-http@3.0.0" is incompatible with requested version "stream-http@^2.7.2"

[2/4] Fetching packages...

Removing intermediate container ed0d901155c0

 ---> dea203892a52

Step 9/9 : COPY . /usr/src/app

 ---> 4ad5bec12418

Successfully built 4ad5bec12418

Successfully tagged ipfs-companion:latest

yarn run v1.9.4

$ ./ci/update-manifest.sh ; npx yarn@1.12.3 build ; chmod -R ugo+rwX build/ add-on/

Skipping manifest modification (RELEASE_CHANNEL=stable)

npx: installed 1 in 2.014s

$ run-s clean build:*

/bin/sh: 1: run-s: not found

error Command failed with exit code 127.

Please test your build steps on a virtual machine with a clean setup and update the instructions for us.

Turns out the build process was trying to fetch packages from registry.js.ipfs.io and failed silently because server was down.   It worked on our end because we had cached docker image built when server was online.
I reported issue to our internal infra team but to save time switched to registry.yarnpkg.com (https://github.com/ipfs-shipyard/ipfs-companion/commit/bf9a69ed9dbc36d56e165c2dfaa83e833cd462ec) and made a new release (v2.7.3) and asked for a fresh look.

(continued in comments)

2019-02-12
Review of (v2.7.3) starts.
The build issue seems to be resolved on Reviewer's machine (:tada:), but Web UI itself becomes an issue:

From what I'm see the webui code is downloaded from https://ipfs.io/api and appended to the build. Please provide the original source code for it and attach it to this version on AMO.

Our reply:

Web UI is just a dependency, like NPM ones.
The only difference is that instead of fetching it from NPM servers it is fetched from IPFS.
Sources of used webui can be found at: https://github.com/ipfs-shipyard/ipfs-webui/releases/tag/v2.3.3
Let us know if that is enough to move forward, or what are required steps to restore extension's availability in AMO.
There are multiple dependencies fetched from NPM and we are not being asked to attach sources of them.  How can we improve things for dependencies fetched from IPFS to be equally "valid"?

(waiting)

2019-02-13
Reached out on #addon-reviewers @ irc.mozilla.org to clarify any issues around what our extension does. Around the same time got review feedback regarding webui:

To answer your question: if you have private packages you can upload them along with the rest of the source code, so we can review them.

I've built webui branch https://github.com/ipfs-shipyard/ipfs-webui/releases/tag/v2.3.3 using node 8.12.0 and npm 6.4.1, but the resulting code is different from the webui folder in the xpi. Please see the attached build https://drive.google.com/open?id=1Ba9kvMhSUZM0KMQMhP7ebYmGX8CCAUAh
Please test your build steps on a virtual machine with a clean setup and update the instructions for us.

I compared

build_webui provided by reviewer
and one from QmXc9raDM1M5G5fpBnVyQ71vR4gbnskwnB9iMEzBuLgvoZ (ipfs-webui/releases/tag/v2.3.3)

Indeed, minified content differs:
$ diff --brief -r build_webui webui_QmXc9raDM1M5G5fpBnVyQ71vR4gbnskwnB9iMEzBuLgvoZ
Files build_webui/asset-manifest.json and webui_QmXc9raDM1M5G5fpBnVyQ71vR4gbnskwnB9iMEzBuLgvoZ/asset-manifest.json differ
Files build_webui/index.html and webui_QmXc9raDM1M5G5fpBnVyQ71vR4gbnskwnB9iMEzBuLgvoZ/index.html differ
Only in build_webui: manifest.json
Only in webui_QmXc9raDM1M5G5fpBnVyQ71vR4gbnskwnB9iMEzBuLgvoZ: _previous-versions
Files build_webui/service-worker.js and webui_QmXc9raDM1M5G5fpBnVyQ71vR4gbnskwnB9iMEzBuLgvoZ/service-worker.js differ
Only in build_webui/static/css: main.ace3c083.css.map
Only in build_webui/static/js: 0.45d2ea26.chunk.js
Only in build_webui/static/js: 0.45d2ea26.chunk.js.map
Only in webui_QmXc9raDM1M5G5fpBnVyQ71vR4gbnskwnB9iMEzBuLgvoZ/static/js: 0.f150ccdd.chunk.js
Only in webui_QmXc9raDM1M5G5fpBnVyQ71vR4gbnskwnB9iMEzBuLgvoZ/static/js: 1.61c650c3.chunk.js
Only in build_webui/static/js: 1.6bbfba19.chunk.js
Only in build_webui/static/js: 1.6bbfba19.chunk.js.map
Only in build_webui/static/js: 2.bc355859.chunk.js
Only in build_webui/static/js: 2.bc355859.chunk.js.map
Only in webui_QmXc9raDM1M5G5fpBnVyQ71vR4gbnskwnB9iMEzBuLgvoZ/static/js: 2.d164b02b.chunk.js
Only in build_webui/static/js: 3.52556504.chunk.js
Only in build_webui/static/js: 3.52556504.chunk.js.map
Only in webui_QmXc9raDM1M5G5fpBnVyQ71vR4gbnskwnB9iMEzBuLgvoZ/static/js: 3.c371693f.chunk.js
Only in webui_QmXc9raDM1M5G5fpBnVyQ71vR4gbnskwnB9iMEzBuLgvoZ/static/js: 4.2f4edf06.chunk.js
Only in build_webui/static/js: 4.cdb20f5c.chunk.js
Only in build_webui/static/js: 4.cdb20f5c.chunk.js.map
Only in webui_QmXc9raDM1M5G5fpBnVyQ71vR4gbnskwnB9iMEzBuLgvoZ/static/js: 5.5fd1145b.chunk.js
Only in build_webui/static/js: 5.e171992c.chunk.js
Only in build_webui/static/js: 5.e171992c.chunk.js.map
Only in build_webui/static/js: 6.6b80439c.chunk.js
Only in build_webui/static/js: 6.6b80439c.chunk.js.map
Only in webui_QmXc9raDM1M5G5fpBnVyQ71vR4gbnskwnB9iMEzBuLgvoZ/static/js: 6.e9a35513.chunk.js
Only in webui_QmXc9raDM1M5G5fpBnVyQ71vR4gbnskwnB9iMEzBuLgvoZ/static/js: 7.9c60492f.chunk.js
Only in build_webui/static/js: 7.ee081174.chunk.js
Only in build_webui/static/js: 7.ee081174.chunk.js.map
Only in build_webui/static/js: main.2b881fc1.js
Only in build_webui/static/js: main.2b881fc1.js.map
Only in webui_QmXc9raDM1M5G5fpBnVyQ71vR4gbnskwnB9iMEzBuLgvoZ/static/js: main.bf82967b.js

(will create issue in webui repo to resolve it upstream)

2019-02-13
Spent a lot of time debugging differences between Firefox and Chrome, namely  handling CORS in webRequest API.  In the end, managed to get it work in both browsers and removed webui in #680.
Companion is now able to load Web UI from IPFS (it's a feature!)  and ensure it can access API set in Companion's Preferences screen without any additional configuration of go-ipfs  (seamless user experience) :ok_hand:
2019-02-14
Submitted v2.7.4 to http://addons.mozilla.org, waiting for review.

2019-02-15
We are back to business!

IPFS Companion got restored at: https://addons.mozilla.org/en-US/firefox/addon/ipfs-companion/

AMO asked us to provide Privacy Policy. I published a draft here and will track it in  #681.

repo: ipfs-shipyard/ipfs-companion


text:
Adding a revert policy

This comes directly from ipfs/go-ipfs#3166, and @Kubuxu. I have added it here and edited it slightly for language.

@Kubuxu Approve changes?

Yup LGTM.

authors: Kubuxu RichardLitt

repo: ipfs/community


text:
[gui error report] Error: multiaddr "https://ipfs.io" must start with a "/"

Desktop: 0.37.0
OS: win32 10.0.19045 x64
Electron: 31.0.1
Chrome: 126.0.6478.36

Error: multiaddr "https://ipfs.io" must start with a "/"
    at new Multiaddr (G:\IPFS\IPFS Desktop\resources\app.asar\node_modules\multiaddr\src\index.js:54:15)
    at multiaddr (G:\IPFS\IPFS Desktop\resources\app.asar\node_modules\multiaddr\src\index.js:621:10)
    at parseMultiaddr (G:\IPFS\IPFS Desktop\resources\app.asar\src\daemon\config.js:115:7)
    at getHttpPort (G:\IPFS\IPFS Desktop\resources\app.asar\src\daemon\config.js:133:14)
    at getGatewayPort (G:\IPFS\IPFS Desktop\resources\app.asar\src\daemon\config.js:143:36)
    at migrateConfig (G:\IPFS\IPFS Desktop\resources\app.asar\src\daemon\config.js:194:67)
    at getIpfsd (G:\IPFS\IPFS Desktop\resources\app.asar\src\daemon\daemon.js:56:5)
    at async startDaemon (G:\IPFS\IPFS Desktop\resources\app.asar\src\daemon\daemon.js:210:17)
    at async startIpfs (G:\IPFS\IPFS Desktop\resources\app.asar\src\daemon\index.js:49:17)
    at async setupDaemon (G:\IPFS\IPFS Desktop\resources\app.asar\src\daemon\index.js:116:3)

@BIOHac9D3 you seem to have misconfigure your node by setting https://ipfs.io in a place which expects a multiaddrs. Please revert that change.

repo: ipfs/ipfs-desktop


text:
chore(release-please/bootstrap/default): release 0.31.1

:robot: I have created a release beep boop
0.31.1 (2023-10-12)
Full Changelog: https://github.com/ipfs/ipfs-desktop/compare/v0.31.0...v0.31.1

This PR was generated with Release Please. See documentation.

This PR was created using the plugin at https://github.com/ipfs-shipyard/release-please-ipfs-plugin, from npm at https://www.npmjs.com/package/@ipfs-shipyard/release-please-ipfs-plugin
using the command
release-please release-pr --token=$GH_TOKEN --plugin '@ipfs-shipyard/release-please-ipfs-plugin' --repo-url=ipfs/ipfs-desktop --target-branch=release-please/bootstrap/default --trace --debug --release-as=v0.31.1 --latest-tag-version=v0.28.0 --draft-pull-request

closing and re-trying to create a new one after some edits.


text:
Rabin chunker not working in the browser

Uncaught (in promise) TypeError: this.asModule.newArray is not a function
    at Rabin.fingerprint (rabin.js:32)
    at rabin.js:60
    at async rabinChunker (rabin.js:39)
    at async buildFile (index.js:22)
    at async batch (index.js:6)
    at async reduceToParents (balanced.js:12)
    at async balanced (balanced.js:6)
    at async toArray (index.js:6)
    at async fileBuilder (index.js:135)
    at async dagBuilder (index.js:36)

Reproduce it here: https://github.com/ipfs-shipyard/ipfs-dag-builder-vis/pull/17
Clone, npm i, npm start, open http://localhost:1234, select "Rabin" chunking and then drop a file.

fixed in https://github.com/hugomrdias/rabin-wasm/releases/tag/v0.0.5

authors: alanshaw hugomrdias

repo: ipfs/js-ipfs-unixfs-importer


text:
feat: create a DAG from a list of CID’s and sizes

This definitely needs a thorough review since this is a bit of a hack and I’m not all that familiar with this code.
This is a feature we need in order to generate custom file data structures from a pre-parsed array of parts. It’s a pretty unique use case and I’m not even sure we should document it as part of the public API.
This implementation seemed like the simplest way to accomplish the goal, but there may be a simpler way I missed.

Please note that this branch relies on another PR https://github.com/ipfs/js-ipfs-unixfs-importer/pull/45


text:
Cannot compile Crow on Windows

I’m trying just to build sample from Wiki:
#include "crow_all.h"

int main()
{
    crow::SimpleApp app;

    CROW_ROUTE(app, "/")
        ([]{
        return "Hello, world!";
    });

    app
        .port(8080)
        .run();
}

First method – VS 2013 (VC++ version: 18.00.21005.1 for x86)
I get the following compilation error:
1>------ Build started: Project: CrowTest, Configuration: Debug Win32 ------
1>  helloworld.cpp
1>c:\temp\crow\crowtest\crowtest\crow_all.h(7924): fatal error C1001: An internal error has occurred in the compiler.
1>  (compiler file 'msc1.cpp', line 1325)

Ok may be VC++ compiler is incompatible with some C++ features used in the project. Let’s try GCC environment.
Second method MinGW-w64 (version: 6.2.0 platform: x86_64-w64-mingw32)
Compilation error:
In file included from helloworld.cpp:1:0:
crow_all.h: In static member function 'static std::__cxx11::string crow::logger::timestamp()':
crow_all.h:5458:36: **error: 'gmtime_r' was not declared in this scope**
                 gmtime_r(&t, &my_tm);
                                    ^
In file included from helloworld.cpp:1:0:
crow_all.h: In lambda function:
crow_all.h:9212:62: error: there are no arguments to 'gmtime_r' that depend on a template parameter, so a declaration of 'gmtime_r' must be available [-fpermissive]
                                 gmtime_r(&last_time_t, &my_tm);
                                                              ^
crow_all.h:9212:62: note: (if you use '-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated)
crow_all.h: In member function 'void crow::Server<Handler, Adaptor, Middlewares>::run()':
crow_all.h:9276:22: **error: 'std::this_thread' has not been declared**
                 std::this_thread::yield();
                      ^~~~~~~~~~~
crow_all.h:9280:13: error: 'thread' is not a member of 'std'
             std::thread([this]{
             ^~~
crow_all.h:9280:13: note: suggested alternative:
In file included from C:\Boost\include\boost-1_62/boost/asio/detail/win_iocp_io_service.hpp:29:0,
                 from C:\Boost\include\boost-1_62/boost/asio/impl/io_service.hpp:69,
                 from C:\Boost\include\boost-1_62/boost/asio/io_service.hpp:767,
                 from C:\Boost\include\boost-1_62/boost/asio/basic_io_object.hpp:19,
                 from C:\Boost\include\boost-1_62/boost/asio/basic_socket.hpp:20,
                 from C:\Boost\include\boost-1_62/boost/asio/basic_datagram_socket.hpp:20,
                 from C:\Boost\include\boost-1_62/boost/asio.hpp:21,
                 from crow_all.h:3267,
                 from helloworld.cpp:1:
C:\Boost\include\boost-1_62/boost/asio/detail/thread.hpp:46:20: note:   'boost::asio::detail::thread'
 typedef win_thread thread;
                    ^~~~~~
In file included from helloworld.cpp:1:0:
crow_all.h: In member function 'crow::Crow<Middlewares>::self_t& crow::Crow<Middlewares>::multithreaded()':
crow_all.h:9443:37: error: 'std::thread' has not been declared
             return concurrency(std::thread::hardware_concurrency());
                                     ^~~~~~
…

First error occurs because gmtime_s/gmtime_r functions are not defined in c/c++ standard headers. This problem can be solved by replacing the function with gmtime wrapper.
I don’t understand why the std::this_thread error occurred .
Has anyone managed to build the project on Windows? How?

please use vs2015 crow use multi c++11 grammars!

Yes gggin you are right. Finally, I succeeded to build crow sample only with VS2015 and Boost 1.58
Even the latest previous version of VS (2013 Update 5) won’t compile the sample code above. With VS2013 problem occurs not in crow_all.h itself, but in Boost headers. Actually, VS2013 can build crow with older versions of Boost (e.g. Boost 1.52).
PS Maybe it would be better to mention VS2015 requirement in project Wiki

JetBrains CLion 2017.1.3 + MinGW   how build the project?
Here is the compile error
`"E:\CLion 2017.1.3\bin\cmake\bin\cmake.exe" -DCMAKE_BUILD_TYPE=Debug -G "CodeBlocks - MinGW Makefiles" C:\Users\sa\Desktop\crow-master
-- Not Found Tcmalloc: Tcmalloc_LIBRARY-NOTFOUND
-- Could NOT find OpenSSL, try to set the path to OpenSSL root folder in the system variable OPENSSL_ROOT_DIR (missing:  OPENSSL_INCLUDE_DIR)
CMake Warning at E:/CLion 2017.1.3/bin/cmake/share/cmake-3.7/Modules/FindBoost.cmake:761 (message):
Imported targets not available for Boost version
Call Stack (most recent call first):
E:/CLion 2017.1.3/bin/cmake/share/cmake-3.7/Modules/FindBoost.cmake:865 (_Boost_COMPONENT_DEPENDENCIES)
E:/CLion 2017.1.3/bin/cmake/share/cmake-3.7/Modules/FindBoost.cmake:1454 (_Boost_MISSING_DEPENDENCIES)
CMakeLists.txt:22 (find_package)
CMake Warning at E:/CLion 2017.1.3/bin/cmake/share/cmake-3.7/Modules/FindBoost.cmake:761 (message):
Imported targets not available for Boost version
Call Stack (most recent call first):
E:/CLion 2017.1.3/bin/cmake/share/cmake-3.7/Modules/FindBoost.cmake:865 (_Boost_COMPONENT_DEPENDENCIES)
E:/CLion 2017.1.3/bin/cmake/share/cmake-3.7/Modules/FindBoost.cmake:1454 (_Boost_MISSING_DEPENDENCIES)
CMakeLists.txt:22 (find_package)
CMake Error at E:/CLion 2017.1.3/bin/cmake/share/cmake-3.7/Modules/FindBoost.cmake:1812 (message):
Unable to find the requested Boost libraries.
Unable to find the Boost header files.  Please set BOOST_ROOT to the root
directory containing Boost or BOOST_INCLUDEDIR to the directory containing
Boost's headers.
Call Stack (most recent call first):
CMakeLists.txt:22 (find_package)
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
Boost_INCLUDE_DIR (ADVANCED)
used as include directory in directory C:/Users/sa/Desktop/crow-master
used as include directory in directory C:/Users/sa/Desktop/crow-master
used as include directory in directory C:/Users/sa/Desktop/crow-master
used as include directory in directory C:/Users/sa/Desktop/crow-master
used as include directory in directory C:/Users/sa/Desktop/crow-master/examples
used as include directory in directory C:/Users/sa/Desktop/crow-master/examples
used as include directory in directory C:/Users/sa/Desktop/crow-master/examples
used as include directory in directory C:/Users/sa/Desktop/crow-master/examples
used as include directory in directory C:/Users/sa/Desktop/crow-master/examples
used as include directory in directory C:/Users/sa/Desktop/crow-master/examples
used as include directory in directory C:/Users/sa/Desktop/crow-master/examples
used as include directory in directory C:/Users/sa/Desktop/crow-master/examples
used as include directory in directory C:/Users/sa/Desktop/crow-master/examples
used as include directory in directory C:/Users/sa/Desktop/crow-master/examples
used as include directory in directory C:/Users/sa/Desktop/crow-master/tests
used as include directory in directory C:/Users/sa/Desktop/crow-master/tests
used as include directory in directory C:/Users/sa/Desktop/crow-master/tests
used as include directory in directory C:/Users/sa/Desktop/crow-master/tests
used as include directory in directory C:/Users/sa/Desktop/crow-master/tests/template
used as include directory in directory C:/Users/sa/Desktop/crow-master/tests/template
used as include directory in directory C:/Users/sa/Desktop/crow-master/tests/template
used as include directory in directory C:/Users/sa/Desktop/crow-master/tests/template
used as include directory in directory C:/Users/sa/Desktop/crow-master/tests/template
-- Configuring incomplete, errors occurred!
See also "C:/Users/sa/Desktop/crow-master/cmake-build-debug/CMakeFiles/CMakeOutput.log".
See also "C:/Users/sa/Desktop/crow-master/cmake-build-debug/CMakeFiles/CMakeError.log".
`

authors: 984958198 gggin philave

repo: ipkn/crow


text:
Filter Life Max Value Issue

This is mostly working for me however filter life is showing "unknown" and I see this in the debug logs:
2023-08-12 00:02:49.604 WARNING (MainThread) [custom_components.winix.sensor] Reported filter life '8033' is more than max value '6480'.
The device is a Winix AM90 and the app shows the filter life at 7%.

I see now where sensor.py had "TOTAL_FILTER_LIFE" set to 9 months of hours in it whereas I was assuming 12 months.  I was able to change to 8760 and it's working now.

repo: iprak/winix


text:
Add a link to examples

This addresses some feedback recently received - lack of examples.
To have CI validating the correctness of examples with least hassle, the examples sit in the evmone repo, as linked in here.

Note an alternative visual layout of the example bytecodes given in a comment https://github.com/ethereum/evmone/commit/a9cde50b42a3eb4dee12c1c6acbd6cc4572d6738#r139971529

repo: ipsilon/eof


text:
Fix: EPG Not Updating

Describe your issue
Hello,
I am using a few epg sources from different countries, but none of them are updating and have no epg info, is there an issue, could you please fix?

all good it has updated

repo: iptv-org/epg

license: Unlicense


text:
Update digiturk.com.tr_tr.channels.xml

Adding line as per #1137

Invalid xml id


text:
Hello , Two Event Fire at a time when using this lib and sample code

Using your sample code
Step to Reproduce
Desc: In main cent

er screen there have a lots of Option : Left, right, Switch Central , Nav ..... etc
When user click Left and Nav button on same time , then both the button are taking action , Means Display the Sliding screen and also the Push new screen.
Please look at the screen shot for More Detail,  same thing is happening in my App.  Please help me how to handle this?

Probably using one of the piece of code to disable the center view while opened

repo: ipup/PPRevealSideViewController


text:
'Select' widget does not support empty list in options any more

Previously Select widget supported empty list in the options. Now it throws a TraitError saying "'options' must not be empty"!
Please enable Select to get initialized with an empty list (and have value attribute initialized to None). We have use cases where the Select list has no options initially and later gets populated based on some event.

The design constraint we're up against here is that None could be a valid option as well as signifying no option selected (e.g., s=Select(options=[None]) is perfectly valid, and s.value is then None). Instead, we suggest that you create your own sentinel value for no option selected, such as Select(options=['']).

(I talked with @ChakriCherukuri about this and he agreed that closing was fine)

We talked a bit more about this, after @ChakriCherukuri kept running into corner cases, and decided that it was fine to implement an empty options list. If the options list is empty, then the value is set to None as a convention. If the options list has things in it, then value should be one of the things in the list (which could possibly be None).

I wonder what would be the semantic of that.

I have a WIP PR coming up.

repo: ipython/ipywidgets