llama 70b takes 5.5 min to load on A100

What is the issue?
I've installed the model in the Ollama Docker pod successfully. However, when attempting to execute a query, there seems to be an issue. I've tried running "ollama run llama3:instruct," but the spinner just keeps spinning.
Here's a breakdown of the steps I've taken:

Executed the command to install the llama3 model:

ollama run llama3:instruct

After the installation completed, I immediately tried asking a question, but received no response. I waited for a considerable amount of time, but nothing changed.
I also attempted to run a curl command inside the pod, but encountered the same issue. The command seemed to get stuck, with no response.

curl http://localhost:11434/api/generate -d '{
  "model": "llama3",
  "prompt": "What color is the sky at different times of the day?"
}'

I even checked the logs of the pod, but unfortunately, I didn't come across any helpful information.

Note: The server appeared to be up and listening on port 11434.
OS
Linux
GPU
No response
CPU
No response
Ollama version
llama3:instruct

Can you share your server log?  Do you have a GPU, or is this running in CPU mode?

@dhiltgen,
Logs:

Pod Metrics:

Hello,
I am facing the exact same issue from today. For me this is present in the Docker images of Ollama, both v0.1.32 and v0.1.33. I am running images inside VastAI instances.
I can successfully pull the model, but if I try to run it it hangs. It doesn't matter if it is through CLI or via HTTP API, the result is the same.
However I noticed some differences.
For example, the above never happens on the Vast instances with RTX 4090 GPU, there it works as expected.
But it hangs on more powerful ones, for example A100 or H100. Canceling and repeating run command doesn't change anything.
I have recorder the logs from the Ollama server when I run the ollama run command.
Good response on RTX 4090 with gemma:7b-instruct-v1.1-q4_0
root@C.10747901:~$ ollama run gemma:7b-instruct-v1.1-q4_0
time=2024-05-03T19:50:19.301Z level=INFO source=gpu.go:96 msg="Detecting GPUs"
time=2024-05-03T19:50:19.303Z level=INFO source=gpu.go:101 msg="detected GPUs" library=/tmp/ollama3318894424/runners/cuda_v11/libcudart.so.11.0 count=2
time=2024-05-03T19:50:19.303Z level=INFO source=cpu_common.go:11 msg="CPU has AVX2"
_ time=2024-05-03T19:50:21.101Z level=INFO source=memory.go:152 msg="offload to gpu" layers.real=-1 layers.estimate=29 memory.available="23823.2 MiB" memory.required.full="6408.9 MiB" memory.required.partial=
"6408.9 MiB" memory.required.kv="672.0 MiB" memory.weights.total="4773.9 MiB" memory.weights.repeating="4158.7 MiB" memory.weights.nonrepeating="615.2 MiB" memory.graph.full="506.0 MiB" memory.graph.partial="
1127.2 MiB"
time=2024-05-03T19:50:21.102Z level=INFO source=memory.go:152 msg="offload to gpu" layers.real=-1 layers.estimate=29 memory.available="23823.2 MiB" memory.required.full="6408.9 MiB" memory.required.partial="6
408.9 MiB" memory.required.kv="672.0 MiB" memory.weights.total="4773.9 MiB" memory.weights.repeating="4158.7 MiB" memory.weights.nonrepeating="615.2 MiB" memory.graph.full="506.0 MiB" memory.graph.partial="11
27.2 MiB"
time=2024-05-03T19:50:21.102Z level=INFO source=cpu_common.go:11 msg="CPU has AVX2"
time=2024-05-03T19:50:21.102Z level=INFO source=server.go:289 msg="starting llama server" cmd="/tmp/ollama3318894424/runners/cuda_v11/ollama_llama_server --model /root/.ollama/models/blobs/sha256-ef311de6af9d
b043d51ca4b1e766c28e0a1ac41d60420fed5e001dc470c64b77 --ctx-size 2048 --batch-size 512 --embedding --log-disable --n-gpu-layers 29 --parallel 1 --port 40769"
time=2024-05-03T19:50:21.103Z level=INFO source=sched.go:340 msg="loaded runners" count=1
time=2024-05-03T19:50:21.103Z level=INFO source=server.go:432 msg="waiting for llama runner to start responding" {"function":"server_params_parse","level":"INFO","line":2606,"msg":"logging to file is disabled.","tid":"140553671749632","timestamp":1714765821}
{"build":1,"commit":"952d03d","function":"main","level":"INFO","line":2822,"msg":"build info","tid":"140553671749632","timestamp":1714765821}
{"function":"main","level":"INFO","line":2825,"msg":"system info","n_threads":127,"n_threads_batch":-1,"system_info":"AVX = 1 | AVX_VNNI = 0 | AVX2 = 0 | AVX512 = 0 | AVX512_VBMI = 0 | AVX512_VNNI = 0 | FMA =
 0 | NEON = 0 | ARM_FMA = 0 | F16C = 0 | FP16_VA = 0 | WASM_SIMD = 0 | BLAS = 1 | SSE3 = 1 | SSSE3 = 1 | VSX = 0 | MATMUL_INT8 = 0 | LLAMAFILE = 1 | ","tid":"140553671749632","timestamp":1714765821,"total_thr
eads":255}
llama_model_loader: loaded meta data with 24 key-value pairs and 254 tensors from /root/.ollama/models/blobs/sha256-ef311de6af9db043d51ca4b1e766c28e0a1ac41d60420fed5e001dc470c64b77 (version GGUF V3 (latest))
llama_model_loader: Dumping metadata keys/values. Note: KV overrides do not apply in this output.
llama_model_loader: - kv   0:                       general.architecture str              = gemma
llama_model_loader: - kv   1:                               general.name str              = gemma-1.1-7b-it
llama_model_loader: - kv   2:                       gemma.context_length u32              = 8192
llama_model_loader: - kv   3:                     gemma.embedding_length u32              = 3072
llama_model_loader: - kv   4:                          gemma.block_count u32              = 28
llama_model_loader: - kv   5:                  gemma.feed_forward_length u32              = 24576
llama_model_loader: - kv   6:                 gemma.attention.head_count u32              = 16
llama_model_loader: - kv   7:              gemma.attention.head_count_kv u32              = 16
llama_model_loader: - kv   8:     gemma.attention.layer_norm_rms_epsilon f32              = 0.000001
llama_model_loader: - kv   9:                 gemma.attention.key_length u32              = 256
llama_model_loader: - kv  10:               gemma.attention.value_length u32              = 256
llama_model_loader: - kv  11:                          general.file_type u32              = 2
llama_model_loader: - kv  12:                       tokenizer.ggml.model str              = llama
_ llama_model_loader: - kv  13:                      tokenizer.ggml.tokens arr[str,256000]  = ["<pad>", "<eos>", "<bos>", "<unk>", ...
_ llama_model_loader: - kv  14:                      tokenizer.ggml.scores arr[f32,256000]  = [0.000000, 0.000000, 0.000000, 0.0000...
llama_model_loader: - kv  15:                  tokenizer.ggml.token_type arr[i32,256000]  = [3, 3, 3, 2, 1, 1, 1, 1, 1, 1, 1, 1, ...
llama_model_loader: - kv  16:                tokenizer.ggml.bos_token_id u32              = 2
llama_model_loader: - kv  17:                tokenizer.ggml.eos_token_id u32              = 1
llama_model_loader: - kv  18:            tokenizer.ggml.unknown_token_id u32              = 3
llama_model_loader: - kv  19:            tokenizer.ggml.padding_token_id u32              = 0
llama_model_loader: - kv  20:               tokenizer.ggml.add_bos_token bool             = true
llama_model_loader: - kv  21:               tokenizer.ggml.add_eos_token bool             = false
llama_model_loader: - kv  22:                    tokenizer.chat_template str              = {{ bos_token }}{% if messages[0]['rol...
llama_model_loader: - kv  23:               general.quantization_version u32              = 2
llama_model_loader: - type  f32:   57 tensors
llama_model_loader: - type q4_0:  196 tensors
llama_model_loader: - type q6_K:    1 tensors
_ llm_load_vocab: mismatch in special tokens definition ( 416/256000 vs 260/256000 ).
llm_load_print_meta: format           = GGUF V3 (latest)
llm_load_print_meta: arch             = gemma
llm_load_print_meta: vocab type       = SPM
llm_load_print_meta: n_vocab          = 256000
llm_load_print_meta: n_merges         = 0
llm_load_print_meta: n_ctx_train      = 8192
llm_load_print_meta: n_embd           = 3072
llm_load_print_meta: n_head           = 16
llm_load_print_meta: n_head_kv        = 16
llm_load_print_meta: n_layer          = 28
llm_load_print_meta: n_rot            = 192
llm_load_print_meta: n_embd_head_k    = 256
llm_load_print_meta: n_embd_head_v    = 256
llm_load_print_meta: n_gqa            = 1
llm_load_print_meta: n_embd_k_gqa     = 4096
llm_load_print_meta: n_embd_v_gqa     = 4096
llm_load_print_meta: f_norm_eps       = 0.0e+00
llm_load_print_meta: f_norm_rms_eps   = 1.0e-06
llm_load_print_meta: f_clamp_kqv      = 0.0e+00
llm_load_print_meta: f_max_alibi_bias = 0.0e+00
llm_load_print_meta: f_logit_scale    = 0.0e+00
llm_load_print_meta: n_ff             = 24576
llm_load_print_meta: n_expert         = 0
llm_load_print_meta: n_expert_used    = 0
llm_load_print_meta: causal attn      = 1
llm_load_print_meta: pooling type     = 0
llm_load_print_meta: rope type        = 2
llm_load_print_meta: rope scaling     = linear
llm_load_print_meta: freq_base_train  = 10000.0
llm_load_print_meta: freq_scale_train = 1
llm_load_print_meta: n_yarn_orig_ctx  = 8192
llm_load_print_meta: rope_finetuned   = unknown
llm_load_print_meta: ssm_d_conv       = 0
llm_load_print_meta: ssm_d_inner      = 0
llm_load_print_meta: ssm_d_state      = 0
llm_load_print_meta: ssm_dt_rank      = 0
llm_load_print_meta: model type       = 7B
llm_load_print_meta: model ftype      = Q4_0
llm_load_print_meta: model params     = 8.54 B
llm_load_print_meta: model size       = 4.66 GiB (4.69 BPW)
llm_load_print_meta: general.name     = gemma-1.1-7b-it
llm_load_print_meta: BOS token        = 2 '<bos>'
llm_load_print_meta: EOS token        = 1 '<eos>'
llm_load_print_meta: UNK token        = 3 '<unk>'
llm_load_print_meta: PAD token        = 0 '<pad>'
llm_load_print_meta: LF token         = 227 '<0x0A>'
llm_load_print_meta: EOT token        = 107 '<end_of_turn>'
ggml_cuda_init: GGML_CUDA_FORCE_MMQ:   yes
ggml_cuda_init: CUDA_USE_TENSOR_CORES: no
ggml_cuda_init: found 1 CUDA devices:
  Device 0: NVIDIA GeForce RTX 4090, compute capability 8.9, VMM: yes
_ llm_load_tensors: ggml ctx size =    0.26 MiB
_ llm_load_tensors: offloading 28 repeating layers to GPU
llm_load_tensors: offloading non-repeating layers to GPU
llm_load_tensors: offloaded 29/29 layers to GPU
llm_load_tensors:        CPU buffer size =   615.23 MiB
llm_load_tensors:      CUDA0 buffer size =  4773.90 MiB
_ .
llama_new_context_with_model: n_ctx      = 2048
llama_new_context_with_model: n_batch    = 512
llama_new_context_with_model: n_ubatch   = 512
llama_new_context_with_model: freq_base  = 10000.0
llama_new_context_with_model: freq_scale = 1
llama_kv_cache_init:      CUDA0 KV buffer size =   896.00 MiB
llama_new_context_with_model: KV self size  =  896.00 MiB, K (f16):  448.00 MiB, V (f16):  448.00 MiB
llama_new_context_with_model:  CUDA_Host  output buffer size =     0.99 MiB
llama_new_context_with_model:      CUDA0 compute buffer size =   506.00 MiB
llama_new_context_with_model:  CUDA_Host compute buffer size =    10.01 MiB
llama_new_context_with_model: graph nodes  = 931
llama_new_context_with_model: graph splits = 2
_ {"function":"initialize","level":"INFO","line":448,"msg":"initializing slots","n_slots":1,"tid":"140553671749632","timestamp":1714765823}
{"function":"initialize","level":"INFO","line":457,"msg":"new slot","n_ctx_slot":2048,"slot_id":0,"tid":"140553671749632","timestamp":1714765823}
{"function":"main","level":"INFO","line":3067,"msg":"model loaded","tid":"140553671749632","timestamp":1714765823}
{"function":"main","hostname":"<IP_ADDRESS>","level":"INFO","line":3270,"msg":"HTTP server listening","n_threads_http":"254","port":"40769","tid":"140553671749632","timestamp":1714765823}
{"function":"update_slots","level":"INFO","line":1581,"msg":"all slots are idle and system prompt is empty, clear the KV cache","tid":"140553671749632","timestamp":1714765823}
{"function":"process_single_task","level":"INFO","line":1509,"msg":"slot data","n_idle_slots":1,"n_processing_slots":0,"task_id":0,"tid":"140553671749632","timestamp":1714765823}
{"function":"log_server_request","level":"INFO","line":2737,"method":"GET","msg":"request","params":{},"path":"/health","remote_addr":"<IP_ADDRESS>","remote_port":36898,"status":200,"tid":"140550372052992","time
stamp":1714765823}

I have cut the end of the above log, it successfully ends with a ready to use prompt line.
But on the other hand the below two hang indefinitely:
Bad run on H100 with gemma:7b-instruct-v1.1-q4_0
root@C.10747901:~$ ollama run gemma:7b-instruct-v1.1-q4_0
[GIN] 2024/05/03 - 20:02:19 | 200 |      25.739_s |       <IP_ADDRESS> | HEAD     "/"
[GIN] 2024/05/03 - 20:02:19 | 200 |     519.066_s |       <IP_ADDRESS> | POST     "/api/show"
[GIN] 2024/05/03 - 20:02:19 | 200 |     821.282_s |       <IP_ADDRESS> | POST     "/api/show"
time=2024-05-03T20:02:19.037Z level=INFO source=gpu.go:96 msg="Detecting GPUs"
time=2024-05-03T20:02:19.043Z level=INFO source=gpu.go:101 msg="detected GPUs" library=/tmp/ollama1224074478/runners/cuda_v11/libcudart.so.11.0 count=2
time=2024-05-03T20:02:19.043Z level=INFO source=cpu_common.go:11 msg="CPU has AVX2"
_ time=2024-05-03T20:02:20.616Z level=INFO source=memory.go:152 msg="offload to gpu" layers.real=-1 layers.estimate=29 memory.available="80482.9 MiB" memory.required.full="6408.9 MiB" memory.required.partial=
"6408.9 MiB" memory.required.kv="672.0 MiB" memory.weights.total="4773.9 MiB" memory.weights.repeating="4158.7 MiB" memory.weights.nonrepeating="615.2 MiB" memory.graph.full="506.0 MiB" memory.graph.partial="
1127.2 MiB"
time=2024-05-03T20:02:20.617Z level=INFO source=memory.go:152 msg="offload to gpu" layers.real=-1 layers.estimate=29 memory.available="80482.9 MiB" memory.required.full="6408.9 MiB" memory.required.partial="6
408.9 MiB" memory.required.kv="672.0 MiB" memory.weights.total="4773.9 MiB" memory.weights.repeating="4158.7 MiB" memory.weights.nonrepeating="615.2 MiB" memory.graph.full="506.0 MiB" memory.graph.partial="11
27.2 MiB"
time=2024-05-03T20:02:20.617Z level=INFO source=cpu_common.go:11 msg="CPU has AVX2"
time=2024-05-03T20:02:20.617Z level=INFO source=server.go:289 msg="starting llama server" cmd="/tmp/ollama1224074478/runners/cuda_v11/ollama_llama_server --model /root/.ollama/models/blobs/sha256-ef311de6af9d
b043d51ca4b1e766c28e0a1ac41d60420fed5e001dc470c64b77 --ctx-size 2048 --batch-size 512 --embedding --log-disable --n-gpu-layers 29 --parallel 1 --port 46235"
time=2024-05-03T20:02:20.618Z level=INFO source=sched.go:340 msg="loaded runners" count=1
time=2024-05-03T20:02:20.618Z level=INFO source=server.go:432 msg="waiting for llama runner to start responding"
{"function":"server_params_parse","level":"INFO","line":2606,"msg":"logging to file is disabled.","tid":"140132691918848","timestamp":1714766540}
{"build":1,"commit":"952d03d","function":"main","level":"INFO","line":2822,"msg":"build info","tid":"140132691918848","timestamp":1714766540}
{"function":"main","level":"INFO","line":2825,"msg":"system info","n_threads":112,"n_threads_batch":-1,"system_info":"AVX = 1 | AVX_VNNI = 0 | AVX2 = 0 | AVX512 = 0 | AVX512_VBMI = 0 | AVX512_VNNI = 0 | FMA =
 0 | NEON = 0 | ARM_FMA = 0 | F16C = 0 | FP16_VA = 0 | WASM_SIMD = 0 | BLAS = 1 | SSE3 = 1 | SSSE3 = 1 | VSX = 0 | MATMUL_INT8 = 0 | LLAMAFILE = 1 | ","tid":"140132691918848","timestamp":1714766540,"total_thr
eads":224}
_ llama_model_loader: loaded meta data with 24 key-value pairs and 254 tensors from /root/.ollama/models/blobs/sha256-ef311de6af9db043d51ca4b1e766c28e0a1ac41d60420fed5e001dc470c64b77 (version GGUF V3 (latest)
)
llama_model_loader: Dumping metadata keys/values. Note: KV overrides do not apply in this output.
llama_model_loader: - kv   0:                       general.architecture str              = gemma
llama_model_loader: - kv   1:                               general.name str              = gemma-1.1-7b-it
llama_model_loader: - kv   2:                       gemma.context_length u32              = 8192
llama_model_loader: - kv   3:                     gemma.embedding_length u32              = 3072
llama_model_loader: - kv   4:                          gemma.block_count u32              = 28
llama_model_loader: - kv   5:                  gemma.feed_forward_length u32              = 24576
llama_model_loader: - kv   6:                 gemma.attention.head_count u32              = 16
llama_model_loader: - kv   7:              gemma.attention.head_count_kv u32              = 16
llama_model_loader: - kv   8:     gemma.attention.layer_norm_rms_epsilon f32              = 0.000001
llama_model_loader: - kv   9:                 gemma.attention.key_length u32              = 256
llama_model_loader: - kv  10:               gemma.attention.value_length u32              = 256
llama_model_loader: - kv  11:                          general.file_type u32              = 2
llama_model_loader: - kv  12:                       tokenizer.ggml.model str              = llama
llama_model_loader: - kv  13:                      tokenizer.ggml.tokens arr[str,256000]  = ["<pad>", "<eos>", "<bos>", "<unk>", ...
_ llama_model_loader: - kv  14:                      tokenizer.ggml.scores arr[f32,256000]  = [0.000000, 0.000000, 0.000000, 0.0000...
_ llama_model_loader: - kv  15:                  tokenizer.ggml.token_type arr[i32,256000]  = [3, 3, 3, 2, 1, 1, 1, 1, 1, 1, 1, 1, ...
llama_model_loader: - kv  16:                tokenizer.ggml.bos_token_id u32              = 2
llama_model_loader: - kv  17:                tokenizer.ggml.eos_token_id u32              = 1
llama_model_loader: - kv  18:            tokenizer.ggml.unknown_token_id u32              = 3
llama_model_loader: - kv  19:            tokenizer.ggml.padding_token_id u32              = 0
llama_model_loader: - kv  20:               tokenizer.ggml.add_bos_token bool             = true
llama_model_loader: - kv  21:               tokenizer.ggml.add_eos_token bool             = false
llama_model_loader: - kv  22:                    tokenizer.chat_template str              = {{ bos_token }}{% if messages[0]['rol...
llama_model_loader: - kv  23:               general.quantization_version u32              = 2
llama_model_loader: - type  f32:   57 tensors
llama_model_loader: - type q4_0:  196 tensors
llama_model_loader: - type q6_K:    1 tensors
_ llm_load_vocab: mismatch in special tokens definition ( 416/256000 vs 260/256000 ).
llm_load_print_meta: format           = GGUF V3 (latest)
llm_load_print_meta: arch             = gemma
llm_load_print_meta: vocab type       = SPM
llm_load_print_meta: n_vocab          = 256000
llm_load_print_meta: n_merges         = 0
llm_load_print_meta: n_ctx_train      = 8192
llm_load_print_meta: n_embd           = 3072
llm_load_print_meta: n_head           = 16
llm_load_print_meta: n_head_kv        = 16
llm_load_print_meta: n_layer          = 28
llm_load_print_meta: n_rot            = 192
llm_load_print_meta: n_embd_head_k    = 256
llm_load_print_meta: n_embd_head_v    = 256
llm_load_print_meta: n_gqa            = 1
llm_load_print_meta: n_embd_k_gqa     = 4096
llm_load_print_meta: n_embd_v_gqa     = 4096
llm_load_print_meta: f_norm_eps       = 0.0e+00
llm_load_print_meta: f_norm_rms_eps   = 1.0e-06
llm_load_print_meta: f_clamp_kqv      = 0.0e+00
llm_load_print_meta: f_max_alibi_bias = 0.0e+00
llm_load_print_meta: f_logit_scale    = 0.0e+00
llm_load_print_meta: n_ff             = 24576
llm_load_print_meta: n_expert         = 0
llm_load_print_meta: n_expert_used    = 0
llm_load_print_meta: causal attn      = 1
llm_load_print_meta: pooling type     = 0
llm_load_print_meta: rope type        = 2
llm_load_print_meta: rope scaling     = linear
llm_load_print_meta: freq_base_train  = 10000.0
llm_load_print_meta: freq_scale_train = 1
llm_load_print_meta: n_yarn_orig_ctx  = 8192
llm_load_print_meta: rope_finetuned   = unknown
llm_load_print_meta: ssm_d_conv       = 0
llm_load_print_meta: ssm_d_inner      = 0
llm_load_print_meta: ssm_d_state      = 0
llm_load_print_meta: ssm_dt_rank      = 0
llm_load_print_meta: model type       = 7B
llm_load_print_meta: model ftype      = Q4_0
llm_load_print_meta: model params     = 8.54 B
llm_load_print_meta: model size       = 4.66 GiB (4.69 BPW)
llm_load_print_meta: general.name     = gemma-1.1-7b-it
llm_load_print_meta: BOS token        = 2 '<bos>'
llm_load_print_meta: EOS token        = 1 '<eos>'
llm_load_print_meta: UNK token        = 3 '<unk>'
llm_load_print_meta: PAD token        = 0 '<pad>'
llm_load_print_meta: LF token         = 227 '<0x0A>'
llm_load_print_meta: EOT token        = 107 '<end_of_turn>'
ggml_cuda_init: GGML_CUDA_FORCE_MMQ:   yes
ggml_cuda_init: CUDA_USE_TENSOR_CORES: no
ggml_cuda_init: found 1 CUDA devices:
  Device 0: NVIDIA H100 80GB HBM3, compute capability 9.0, VMM: yes

Bad run on H100 with llama2:70b-chat-q4_0
root@C.10747901:~$ ollama run llama2:70b-chat-q4_0
[GIN] 2024/05/03 - 20:11:07 | 200 |      25.188_s |       <IP_ADDRESS> | HEAD     "/"
[GIN] 2024/05/03 - 20:11:07 | 200 |     478.553_s |       <IP_ADDRESS> | POST     "/api/show"
[GIN] 2024/05/03 - 20:11:07 | 200 |     262.277_s |       <IP_ADDRESS> | POST     "/api/show"
time=2024-05-03T20:11:07.545Z level=INFO source=gpu.go:96 msg="Detecting GPUs"
time=2024-05-03T20:11:07.553Z level=INFO source=gpu.go:101 msg="detected GPUs" library=/tmp/ollama1224074478/runners/cuda_v11/libcudart.so.11.0 count=2
time=2024-05-03T20:11:07.553Z level=INFO source=cpu_common.go:11 msg="CPU has AVX2"
_ time=2024-05-03T20:11:08.354Z level=INFO source=memory.go:152 msg="offload to gpu" layers.real=-1 layers.estimate=81 memory.available="80482.9 MiB" memory.required.full="38351.1 MiB" memory.required.partial
="38351.1 MiB" memory.required.kv="640.0 MiB" memory.weights.total="36930.1 MiB" memory.weights.repeating="36725.0 MiB" memory.weights.nonrepeating="205.1 MiB" memory.graph.full="324.0 MiB" memory.graph.parti
al="348.0 MiB"
time=2024-05-03T20:11:08.356Z level=INFO source=memory.go:152 msg="offload to gpu" layers.real=-1 layers.estimate=81 memory.available="80482.9 MiB" memory.required.full="38351.1 MiB" memory.required.partial="
38351.1 MiB" memory.required.kv="640.0 MiB" memory.weights.total="36930.1 MiB" memory.weights.repeating="36725.0 MiB" memory.weights.nonrepeating="205.1 MiB" memory.graph.full="324.0 MiB" memory.graph.partial
="348.0 MiB"
time=2024-05-03T20:11:08.356Z level=INFO source=cpu_common.go:11 msg="CPU has AVX2"
time=2024-05-03T20:11:08.357Z level=INFO source=server.go:289 msg="starting llama server" cmd="/tmp/ollama1224074478/runners/cuda_v11/ollama_llama_server --model /root/.ollama/models/blobs/sha256-68bbe6dc9cf4
2eb60c9a7f96137fb8d472f752de6ebf53e9942f267f1a1e2577 --ctx-size 2048 --batch-size 512 --embedding --log-disable --n-gpu-layers 81 --parallel 1 --port 44497"
time=2024-05-03T20:11:08.357Z level=INFO source=sched.go:340 msg="loaded runners" count=1
time=2024-05-03T20:11:08.357Z level=INFO source=server.go:432 msg="waiting for llama runner to start responding"
{"function":"server_params_parse","level":"INFO","line":2606,"msg":"logging to file is disabled.","tid":"140574146117632","timestamp":1714767068}
{"build":1,"commit":"952d03d","function":"main","level":"INFO","line":2822,"msg":"build info","tid":"140574146117632","timestamp":1714767068}
{"function":"main","level":"INFO","line":2825,"msg":"system info","n_threads":112,"n_threads_batch":-1,"system_info":"AVX = 1 | AVX_VNNI = 0 | AVX2 = 0 | AVX512 = 0 | AVX512_VBMI = 0 | AVX512_VNNI = 0 | FMA =
 0 | NEON = 0 | ARM_FMA = 0 | F16C = 0 | FP16_VA = 0 | WASM_SIMD = 0 | BLAS = 1 | SSE3 = 1 | SSSE3 = 1 | VSX = 0 | MATMUL_INT8 = 0 | LLAMAFILE = 1 | ","tid":"140574146117632","timestamp":1714767068,"total_thr
eads":224}
llama_model_loader: loaded meta data with 23 key-value pairs and 723 tensors from /root/.ollama/models/blobs/sha256-68bbe6dc9cf42eb60c9a7f96137fb8d472f752de6ebf53e9942f267f1a1e2577 (version GGUF V3 (latest))
llama_model_loader: Dumping metadata keys/values. Note: KV overrides do not apply in this output.
llama_model_loader: - kv   0:                       general.architecture str              = llama
llama_model_loader: - kv   1:                               general.name str              = LLaMA v2
llama_model_loader: - kv   2:                       llama.context_length u32              = 4096
llama_model_loader: - kv   3:                     llama.embedding_length u32              = 8192
llama_model_loader: - kv   4:                          llama.block_count u32              = 80
llama_model_loader: - kv   5:                  llama.feed_forward_length u32              = 28672
llama_model_loader: - kv   6:                 llama.rope.dimension_count u32              = 128
llama_model_loader: - kv   7:                 llama.attention.head_count u32              = 64
llama_model_loader: - kv   8:              llama.attention.head_count_kv u32              = 8
llama_model_loader: - kv   9:     llama.attention.layer_norm_rms_epsilon f32              = 0.000010
llama_model_loader: - kv  10:                          general.file_type u32              = 2
llama_model_loader: - kv  11:                       tokenizer.ggml.model str              = llama
llama_model_loader: - kv  12:                      tokenizer.ggml.tokens arr[str,32000]   = ["<unk>", "<s>", "</s>", "<0x00>", "<...
llama_model_loader: - kv  13:                      tokenizer.ggml.scores arr[f32,32000]   = [0.000000, 0.000000, 0.000000, 0.0000...
llama_model_loader: - kv  14:                  tokenizer.ggml.token_type arr[i32,32000]   = [2, 3, 3, 6, 6, 6, 6, 6, 6, 6, 6, 6, ...
llama_model_loader: - kv  15:                      tokenizer.ggml.merges arr[str,61249]   = ["_ t", "e r", "i n", "_ a", "e n...
llama_model_loader: - kv  16:                tokenizer.ggml.bos_token_id u32              = 1
llama_model_loader: - kv  17:                tokenizer.ggml.eos_token_id u32              = 2
llama_model_loader: - kv  18:            tokenizer.ggml.unknown_token_id u32              = 0
llama_model_loader: - kv  19:               tokenizer.ggml.add_bos_token bool             = true
llama_model_loader: - kv  20:               tokenizer.ggml.add_eos_token bool             = false
llama_model_loader: - kv  21:                    tokenizer.chat_template str              = {% if messages[0]['role'] == 'system'...
llama_model_loader: - kv  22:               general.quantization_version u32              = 2
llama_model_loader: - type  f32:  161 tensors
llama_model_loader: - type q4_0:  561 tensors
llama_model_loader: - type q6_K:    1 tensors
_ llm_load_vocab: special tokens definition check successful ( 259/32000 ).
llm_load_print_meta: format           = GGUF V3 (latest)
llm_load_print_meta: arch             = llama
llm_load_print_meta: vocab type       = SPM
llm_load_print_meta: n_vocab          = 32000
llm_load_print_meta: n_merges         = 0
llm_load_print_meta: n_ctx_train      = 4096
llm_load_print_meta: n_embd           = 8192
llm_load_print_meta: n_head           = 64
llm_load_print_meta: n_head_kv        = 8
llm_load_print_meta: n_layer          = 80
llm_load_print_meta: n_rot            = 128
llm_load_print_meta: n_embd_head_k    = 128
llm_load_print_meta: n_embd_head_v    = 128
llm_load_print_meta: n_gqa            = 8
llm_load_print_meta: n_embd_k_gqa     = 1024
llm_load_print_meta: n_embd_v_gqa     = 1024
llm_load_print_meta: f_norm_eps       = 0.0e+00
llm_load_print_meta: f_norm_rms_eps   = 1.0e-05
llm_load_print_meta: f_clamp_kqv      = 0.0e+00
llm_load_print_meta: f_max_alibi_bias = 0.0e+00
llm_load_print_meta: f_logit_scale    = 0.0e+00
llm_load_print_meta: n_ff             = 28672
llm_load_print_meta: n_expert         = 0
llm_load_print_meta: n_expert_used    = 0
llm_load_print_meta: causal attn      = 1
llm_load_print_meta: pooling type     = 0
llm_load_print_meta: rope type        = 0
llm_load_print_meta: rope scaling     = linear
llm_load_print_meta: freq_base_train  = 10000.0
llm_load_print_meta: freq_scale_train = 1
llm_load_print_meta: n_yarn_orig_ctx  = 4096
llm_load_print_meta: rope_finetuned   = unknown
llm_load_print_meta: ssm_d_conv       = 0
llm_load_print_meta: ssm_d_inner      = 0
llm_load_print_meta: ssm_d_state      = 0
llm_load_print_meta: ssm_dt_rank      = 0
llm_load_print_meta: model type       = 70B
llm_load_print_meta: model ftype      = Q4_0
llm_load_print_meta: model params     = 68.98 B
llm_load_print_meta: model size       = 36.20 GiB (4.51 BPW)
llm_load_print_meta: general.name     = LLaMA v2
llm_load_print_meta: BOS token        = 1 '<s>'
llm_load_print_meta: EOS token        = 2 '</s>'
llm_load_print_meta: UNK token        = 0 '<unk>'
llm_load_print_meta: LF token         = 13 '<0x0A>'
ggml_cuda_init: GGML_CUDA_FORCE_MMQ:   yes
ggml_cuda_init: CUDA_USE_TENSOR_CORES: no
ggml_cuda_init: found 1 CUDA devices:
  Device 0: NVIDIA H100 80GB HBM3, compute capability 9.0, VMM: yes
_ llm_load_tensors: ggml ctx size =    0.74 MiB
_ llm_load_tensors: offloading 80 repeating layers to GPU
llm_load_tensors: offloading non-repeating layers to GPU
llm_load_tensors: offloaded 81/81 layers to GPU
llm_load_tensors:        CPU buffer size =   140.62 MiB
llm_load_tensors:      CUDA0 buffer size = 36930.11 MiB
_ .
llama_new_context_with_model: n_ctx      = 2048
llama_new_context_with_model: n_batch    = 512
llama_new_context_with_model: n_ubatch   = 512
llama_new_context_with_model: freq_base  = 10000.0
llama_new_context_with_model: freq_scale = 1
llama_kv_cache_init:      CUDA0 KV buffer size =   640.00 MiB
llama_new_context_with_model: KV self size  =  640.00 MiB, K (f16):  320.00 MiB, V (f16):  320.00 MiB
_ llama_new_context_with_model:  CUDA_Host  output buffer size =     0.15 MiB
llama_new_context_with_model:      CUDA0 compute buffer size =   324.00 MiB
llama_new_context_with_model:  CUDA_Host compute buffer size =    20.01 MiB
llama_new_context_with_model: graph nodes  = 2566
llama_new_context_with_model: graph splits = 2

@MarkoSagadin when you say "hang indefinitely" can you clarify how long we're talking?  We've seen some cloud instances have quite slow I/O and can take a very long time to load models.  Some users are reporting our default timeout of 10m isn't sufficient to load models on some setups.  Does it eventually hit a model load timeout error at 10m?

@dhiltgen it hung for at least 3 minutes, I had timeout for httpx requests inside my program set to this.
Longer I can't say (and it will be a while before I can test this, since I will be out of the office for next week).
For me it is weird that on RTX 4090 GPU running models seems to function, but not on H100 GPU, and that actually worked fine two days ago.

I got that same problem too, but after i executed the below cmds from "https://hub.docker.com/r/ollama/ollama", it works.
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey \
    | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list \
    | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' \
    | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update

My linux environment is WSL2, GPU is 1080ti.  docker ollama version is v0.1.34

Resolved the issue by transitioning from CPU to GPU processing, significantly improving response time within Docker. However, encountering delays when retrieving the same data from the API("/api/chat).

Sorry for offtop. @rk-spirinova You'd better hide your public and unprotected ip from your screenshot.

@dhiltgen I have made some new discoveries on this issue.

The issue is present on the H100, while using docker versions 0.1.38, 0.1.37, 0.1.30 and 0.1.28 (I was interested to see how back I would need to go for this to work).
The issue is not present on RTX 4090 with above versions.

I let the /api/generate command (using llama3 model) to hang, to see if I would get to the 10 min timeout that you mentioned. To my surprise the model actually executed my request after 5 minutes and 30 seconds. Subsequent runs with the same model or the different one (phi3) were instantaneous.
This is a workaround that I can work with, if the hanging delays don't come back after using some other models, as I am evaluating many of them...
Is there any extra information/logs that I can provide? Such as instance information, nvidia driver versions, ollama logs, ect. to help solving this issue?

@MarkoSagadin that's great to hear it did actually load and wasn't hung.
Now that we know it's not stuck, and is more a performance problem, the question is if there's a bug in the ollama code leading this to be unnecessarily inefficient, or if your cloud instance needs optimization perhaps.  You can try adjusting the storage device where the models are being stored to make sure it is high performance storage.  Also try different instance types (CPUs, memory) - perhaps you're using an instance type that is getting "starved" for some resource at the hypervisor level resulting in slow I/O transfers into the GPU.

Is there any extra information that I can provide? Such as instance information, nvidia driver versions, Ollama logs, etc. to help solving this issue?

You might want to try to explore some metrics on your node to see if there's an obvious bottleneck leading to this slow performance.    For example iostat -dmx 5
If none of that helps you find a good combination, can you share what cloud provider you're using, and the VM configuration details so we can try to repro?

I just tried this with a 2xA100 and everything is working correctly:
$ ollama ps
NAME           	ID          	SIZE  	PROCESSOR	UNTIL
llama3:instruct	a6990ed6be41	5.4 GB	100% GPU 	4 minutes from now

and the output from verbose:
total duration:       6.791328594s
load duration:        4.626741228s
prompt eval count:    189 token(s)
prompt eval duration: 180.487ms
prompt eval rate:     1047.17 tokens/s
eval count:           177 token(s)
eval duration:        1.839261s
eval rate:            96.23 tokens/s

This is w/ ollama 0.1.38.
 Also, what version of Linux are you running?

I had the same issue:

working great on a 3090
big performance issue on a H100

5min30 too to load a model (even a small embeddings model)
inference was painfully slow (between 1s and 8s)

I decided to try to a local build thanks to https://github.com/ollama/ollama/issues/4131#issuecomment-2097813973 :

updated CUDA toolkit from 12.4 to 12.5 (driver to 555)
checked out the v0.1.39 prerelease version
build ollama with the machine own updated CUDA
started ollama with the new OLLAMA_FLASH_ATTENTION=1 (this might not have to do anything with resolution but as I set it up, I report it anyway)

Everything is running super smooth now. My guess is that there is some issue for the A100/H100 cards with the CUDA version used by ollama for the official builds (binary and docker).

@hekmon what version of Linux are you using and are you using this in the cloud somewhere? I just want to see if I can duplicate the issue.

This is a baremetal server unfortunatly, not a cloud instance. But I am confident that the issue lies within the A100/H100 and the CUDA version used to compile ollama, therfore any Ubuntu 22.04 with a A100/H100 should be able to replicate the issue.
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.4 LTS
Release:        22.04
Codename:       jammy

Edit: just saw your previous comments where you told you tested it on Ubuntu 22.04 and 2xA100. That's a bummer. May be on on the model side then ? The 2 models I was using (with the experimental env var for multiples models to 4 and requests concurrency to 10) were:

mxbai for embeddings
deepseekcoder 6.7b (tried both quantized and fp16)

Edit: just saw your previous comments where you told you tested it on Ubuntu 22.04 and 2xA100. That's a bummer. May be on on the model side then ? The 2 models I was using (with the experimental env var for multiples models to 4 and requests concurrency to 10) were:

mxbai for embeddings
deepseekcoder 6.7b (tried both quantized and fp16)

It still can be a driver issue. I just used whatever drivers were available in the "ML-in-a-box" Ubuntu 22.04 image on Paperspace. I didn't try from scratch. I'll give that a shot soon.

OK, this turns out to be an an nVidia problem where they updated the driver and it no longer loads the correct kernel modules.
#4652 fixes this, but the workaround is to run:
sudo modprobe nvidia
sudo modprobe nvidia_uvm

I'll go ahead and close out the issue.

Note, this is specifically w/ driver version 555. @hekmon if you do an ollama ps you can see that everything is loaded onto the CPU instead of the GPU, so it's not really the same problem that was initially reported (which I think was fixed before).

That's odd.
I used to have driver 550 (updated my original post) and had the issue. I do have the 555 now but my localy compiled ollama correctly report GPU usage with ollama ps.
I will try to launch the original docker container of ollama 0.1.38 that I might still have unmodified to double check/confirm that it had the issue even with 555 while locally compiled ollama does not and report asap.

So I restarted my original ollama v0.1.38 container with the new CUDA/driver version. I do not have the 5min30 load time any more but it still does not work properly:

Starting is ok
Then I try to load the mxbai embeddings model with the following curl : curl "http://<IP_ADDRESS>:11434/api/embeddings" -d '{"model": "mxbai-embed-large", "keep_alive": -1}'
The curl them blocks for 1min52 and then returns {"error":"timed out waiting for llama runner to start - progress 1.00 - "}
During that time, a ollama ps clearly shows that GPU is in use (not CPU):

NAME                            ID              SIZE    PROCESSOR       UNTIL
mxbai-embed-large:latest        468836162de7    1.3 GB  100% GPU        Forever

After the error the model does not appear in ollama ps any more

ollama_v0.1.38.log
TL;DR
After the CUDA/driver upgrade, the symptoms changed (5min30 load time with an available model at the end -> model load timeout after ~2min) but ollama still does not work as expected. While a locally compiled ollama does work. In my opinion this has nothing to do with https://github.com/ollama/ollama/pull/4652.

Wow this thread is spot on !
Just had this issue today running ollama on openshift with gpu
I’ll update when I get to test this tomorrow morning!

Unfortunately after further testing today this does not seem to resolve the issue in my case
No further logs or information is given after the 5m timeout
Still waiting for the llama runner to start :(

@alonilon can you set OLLAMA_DEBUG=1 and share the logs leading up to the timeout?  I'm curious if it was stalled at 0%, 100% or some other behavior.

Unfortunately I cannot share the logs as the machine is disconnected from the internet
I can see the logs of the model being loaded all the way up to 1.00
Are there any other debug options I could/would try ?
Is there any way to debug the status of the runner itself ?


Fix link in non-openai model doc

Why are these changes needed?

Related issue number

Checks

[ ] I've included any doc changes needed for https://microsoft.github.io/autogen/. See https://microsoft.github.io/autogen/docs/Contribute#documentation to build and test documentation locally.
[ ] I've added tests (if relevant) corresponding to the changes introduced in this PR.
[ ] I've made sure all auto checks have passed.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 36.85%. Comparing base (88a71d5) to head (bb86d17).

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2106      +/-   ##
==========================================
- Coverage   36.90%   36.85%   -0.06%
==========================================
  Files          68       68
  Lines        7061     7061
  Branches     1541     1541
==========================================
- Hits         2606     2602       -4
- Misses       4225     4228       +3
- Partials      230      231       +1

Flag
Coverage Δ

unittests
36.85% <ø> (-0.06%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

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

Thanks guys


Firebase Cloud Messaging is not working

If you use the Firebase Cloud Messaging (FCM) function, you will not get a response from the client.
I made the following change in the FirebaseESP8266 file:
The instructions
7359 httpcode = net.sendRequest (header, "");
7360 httpcode = net.sendRequest (msg, "");
by the following replacement
httpcode = net.sendRequest (header, msg);
Then runs.

Thanks for inform but the return value is not actually httpcode (returns true for success or false for failed) and need to change.
This is not bug or affected to the operation as if the header success to send, the payload should success too.
The esp8266 code need to be rewrite in the same way as esp32 which handles better header and payload.


Spanish translations for Intro to Jupyter Notebooks

This issue is for translating Jupyter Notebooks workshop intro Spanish

Assigned to @jesscobedo9 ! Thanks so much for helping out 💯


Authentication issue when updating value, not when creating.

[x] Log in and get access token
[x] use access token to create/find thing
[x] use access token to create property on the thing
[ ] use access token to update property

That's where it's falling apart. I receive the following response from the server (with error code 500):
DCD Hub Error: Access denied - Authentication information missing, malformed or invalid
    at new DCDError (/usr/app/node_modules/@datacentricdesign/types/DCDError.ts:26:9)
    at AuthService.<anonymous> (/usr/app/src/auth/AuthService.ts:115:11)
    at step (/usr/app/src/auth/AuthService.ts:33:23)
    at Object.next (/usr/app/src/auth/AuthService.ts:14:53)
    at fulfilled (/usr/app/src/auth/AuthService.ts:5:58)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)

This error is the same when using a version of ioSense that was confirmed to be working, I will poke around at the python SDK and try and reflect changes in the Dart version, but I would love to double check in case the server is misbehaving.

Hi @WoMeijerPhD, I role out a new release on the production server last week. Top of my head it included a fix on the property scope which was not checked properly before. Your app scope must include dcd:properties if your app uses the properties API.
Note that if you change your scope you need to sign out and sign up again to generate a token with this new scope.

Beautiful! It works now! Thanks for the quick reply!
Just for anyone who would happen to read this, I have scopes set as:
    'openid',
    'offline',
    'email',
    'profile',
    'dcd:public',
    'dcd:things',
    'dcd:properties'


Package anyio has not ExceptionGroup on Python >= 3.11

Description
Run into some issues while dockering my application, it particularly triggered the exception at line following line except anyio.ExceptionGroup as e:
How to reproduce
Throw an error on startup.
from faststream import FastStream
...

Expected behavior
Explain what you expected to happen clearly and concisely.
Observed behavior
Describe what is actually happening clearly and concisely.
Screenshots
If applicable, attach screenshots to help illustrate the problem.
Environment
Include the output of the faststream -v command to display your current project and system environment.
Additional context
Provide any other relevant context or information about the problem here.

Can you please tell us what versions of faststream and anyio are you using?

Hi, I'm sorry, I wrote the ticket in a rush, forgot to give more details.
Packages versions are:

Faststream: 0.3.3
Anyio: 4.10

As mentioned, in app.py it's trying to use anyio.ExceptionGroup which is only available for versions under 3.12, and the imports in anyio on that version exclude that exception based on the python version. e.g.: _trio.py:65

The problem was AnyIO upgraded to 4.x version. They introduced the following breaking change (https://anyio.readthedocs.io/en/stable/versionhistory.html):
BACKWARDS INCOMPATIBLE Replaced AnyIO’s own ExceptionGroup class with the PEP 654 BaseExceptionGroup and ExceptionGroup
It is fixed now, we'll release a new version in a few minutes.


replace embedding iterator by embedding reader package

I extracted and improved the embedding iterator into a new package https://github.com/rom1504/embedding-reader
embedding reader is much faster than the previous embedding iterator thanks to reading pieces of files in parallel
it can also be reused for other embedding reading use cases

works well, but I'm still running some benchmarks, let's not merge right now

Thanks ! This looks like that it would have a very big speed up.
One minor issue that I notice is:
https://github.com/rom1504/embedding-reader/blob/main/embedding_reader/piece_builder.py#L43-L45
count = items[header_i].count
piece_start = batch_start + read_current_batch - count_before
piece_length = min(count - piece_start, batch_length - read_current_batch, max_piece_size)

when count is 0, piece_length could be negative.

empty files are skipped at https://github.com/rom1504/embedding-reader/blob/main/embedding_reader/numpy_reader.py#L51
(your test in autofaiss caught this already and made me add this case!)

Ah, yes, indeed,  I didn't check the numpy reader just now, but should it be if c[] == 0:` ?
And, this check is not done in parquet reader: https://github.com/rom1504/embedding-reader/blob/main/embedding_reader/parquet_reader.py#L44-L47

Ah, yes, indeed, I didn't check the numpy reader just now, but should it be if c[1] == 0: ?

no it's coming from the read_numpy_header function above, the count is the first element

And, this check is not done in parquet reader: https://github.com/rom1504/embedding-reader/blob/main/embedding_reader/parquet_reader.py#L44-L47

good catch, I added a check in parquet reader and in piece builder
https://github.com/rom1504/embedding-reader/commit/0b44eec454d5cee48f7b91301bc24cca2fd553a1

fyi with this pr and https://github.com/criteo/autofaiss/pull/93 it takes only 40h to build a 5B embeddings (dimension 768) index with a single 16 core node reading from aws s3 (18TB of embeddings)
I bet the same speed up will be observed when reading from hdfs!

no it's coming from the read_numpy_header function above, the count is the first element

the count is the first element of read_numpy_header, but in the function file_to_header, it is the second element, no ?
https://github.com/rom1504/embedding-reader/blob/main/embedding_reader/numpy_reader.py#L43-L45

yes you are right, I fixed it

ok I confirm this is working, generated a large (110GB) index using only 20GB of ram
here's one of the result when looking for a turtle in the index https://chairish-prod.global.ssl.fastly.net/image/product/sized/5ca842ce-18de-43d9-a58b-46157cc89a51?aspect=fit&width=320&height=320
I've got more runs to do with the code but I believe this can be merged
would appreciate if you can review @hitchhicker @victor-paltz
btw having https://github.com/criteo/autofaiss/issues/5 would really increase the confidence in all autofaiss results. I might give it a look. It would provide us with recall metrics for almost free at the end of the run but also even during the run would provide us partial recalls (on the collection computed until that point)

Good to know it is working well ! I'll take some time to review it.

I went through the embedding-reader, it looks good and it is well written. Good job ! There are just some edge cases not handled, I did a PR for this.
For the code of integration into autofaiss, I didn't have time to read it. There is one thing that might be a concern.
For the parqeut reader, there is line where we write "i" into the meta data column (https://github.com/rom1504/embedding-reader/blob/8dc073ac8b3711f80df5d2bb14f53fdb3f3b6b4f/embedding_reader/parquet_reader.py#L138) , do we want this information in autofaiss ?

Thanks for the PR, looking at it!
For the autofaiss integration, i kept that i because it was there in autofaiss.
There was however a discrepancy in autofaiss between sequential and distributed mode. In sequential mode the i was included in the metadata, in distributed mode it was not. I made it consistent by adding the i in all cases
A benefit of that i is that it allows users to process the metadata files in non-ordered way.
This is an use case that is used for example in buyer index but in general it can be useful to build kv/store with the metadata in non ordered processing.
It's pretty small so it doesn't hurt to always have it in my opinion.
However it's a good point that all downstream jobs should use only the keys they need.

There is indeed an i in autofaiss, I did miss it.
So let's keep it for autofaiss, no problem with that. It will be helpful in mamy cases like you said.

Your PR at embedding reader is merged now
This is ready for reviews/merging whenever you have time :)

I think we can merge this one then


Integrated first draft of survey response design

What
A first pass of integration of survey response designs, need to sort out thanks.html
next and mobile test this, but looking in a good state, ready for test.
How to test

Deploy a new environement using eq-terraform, editing the branch to be deployed to digeq-80-admin-first-draft
Check that a rendered questionnaire is presented correctly.

Who can test
Anyone but @dhilton

Just as an FYI the mobile styles are a little borked. I will fix over the weekend and we can do a hotfix monday morning

Also - this is very, very much WIP. Need to reconsider usage of ONS style guide for presentation for starters

There's a few minor issues with text alignment and the ONS logo is in the wrong place. However it looks a lot better than the bare bones version, so I suggest we merge this and fix later.

:+1:


Plug-in is unnecessarily case sensitive when it comes to the folder name

Starting with a fixed folder name makes sense, but the plug-in should not care about whether the folder name is upper case, lower case, etc.
It works if the folder is called definitions but it immediately stops working if it's called Definitions.

Thanks for the feedback, I'll add an option to customise the folder name in subsequent release.


polysemy-plugin: fix build

This needs a slightly older version of ghc-tcplugins-extra.
Include that, too.

Motivation for this change
Configuring polysemy-plugin-<IP_ADDRESS>...
CallStack (from HasCallStack):
  die', called at libraries/Cabal/Cabal/Distribution/Simple/Configure.hs:1022:20 in Cabal-<IP_ADDRESS>:Distribution.Simple.Configure
  configureFinalizedPackage, called at libraries/Cabal/Cabal/Distribution/Simple/Configure.hs:475:12 in Cabal-<IP_ADDRESS>:Distribution.Simple.Configure
  configure, called at libraries/Cabal/Cabal/Distribution/Simple.hs:625:20 in Cabal-<IP_ADDRESS>:Distribution.Simple
  confHook, called at libraries/Cabal/Cabal/Distribution/Simple/UserHooks.hs:65:5 in Cabal-<IP_ADDRESS>:Distribution.Simple.UserHooks
  confHook, called at libraries/Cabal/Cabal/Distribution/Simple/UserHooks.hs:65:5 in Cabal-<IP_ADDRESS>:Distribution.Simple.UserHooks
  configureAction, called at libraries/Cabal/Cabal/Distribution/Simple.hs:180:19 in Cabal-<IP_ADDRESS>:Distribution.Simple
  defaultMainHelper, called at libraries/Cabal/Cabal/Distribution/Simple.hs:125:42 in Cabal-<IP_ADDRESS>:Distribution.Simple
  defaultMainWithHooks, called at src/Distribution/Extra/Doctest.hs:170:27 in cabal-doctest-1.0.8-2wQRz9ec1yB5lMDRmEgBWB:Distribution.Extra.Doctest
Setup: Encountered missing or private dependencies:
ghc-tcplugins-extra ==0.3.

Things done

[X] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[X] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[X] Determined the impact on package closure size (by running nix path-info -S before and after)
[X] Ensured that relevant documentation is up to date
[X] Fits CONTRIBUTING.md.

Thanks for the feedback!
As per this discussion on Discourse, I'm initially including the patch to include the required version of ghc-tcplugins-extra, in the hope that hackage-packages.nix will be automatically updated tomorrow. I'll then do the second part of actually getting polysemy-plugin to use that version.

Ah, thanks - done.
It was already rebased on top of haskell-updates, though.

Please change the base branch of the PR to be haskell-updates, not master.

It is branched off haskell-updates:
sperber@valmont ~/b/nixpkgs (unbreak-polysemy-plugin)> git log
commit 3fe55e10b39497c6df3b79883a3a25a5109cb21a (HEAD -> unbreak-polysemy-plugin, mikesperber/unbreak-polysemy-plugin)
Author: Mike Sperber<EMAIL_ADDRESS>Date:   Tue Mar 24 15:37:55 2020 +0100

    ghc-tcplugins-extra: include version 0.3.2

    This is slightly outdated, required by polysemy-plugin, the actual fix
    for this will be forthcoming as soon as hackage-packages.nix is
    updated.

commit 218a3b3651cff1c830927beb504c78f992c08d35 (origin/haskell-updates, haskell-updates)
Author: Peter Simons<EMAIL_ADDRESS>Date:   Thu Mar 26 02:30:38 2020 +0100

    hackage-packages.nix: automatic Haskell package set update

    This update was generated by hackage2nix v2.15.1 from Hackage revision
    https://github.com/commercialhaskell/all-cabal-hashes/commit/69adf93bec1ae46d9a8d9f964897237d565109fa.

Is there some confusion?

@mikesperber
Right under the title of this PR, there is a line that says:

mikesperber wants to merge 17 commits into NixOS:master from mikesperber:unbreak-polysemy-plugin

You need to click the Edit button next to that line, and change the base branch from NixOS:master to NixOS:haskell-updates.

Ah, sorry. Done.

@mikesperber Looks good! Thanks for working through this with me.

@cdepillabout I appreciate your patience!


VMware 6.7 GuestOS is incorrect

What kind of request is this (question/bug/enhancement/feature request):
bug
Steps to reproduce (least amount of steps as possible):

Create a new vanilla vSphere node template.
Create a new cluster based on the above template.
Open the vSphere web console.
Select the new cluster node.

Result:
You will see the following warning.
The configured guest OS (Other Linux (64-bit)) for this virtual machine does not match the guest that is currently running (Other 4.x or later Linux (64-bit)). You should specify the correct guest OS to allow for guest-specific optimizations
Other details that may be helpful:
vSphere 6.7 U1
The correct guestOS type should be other4xlinux-64
Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI): 2.1.8
Installation option (single install/HA): single install

Cluster information

Cluster type (Hosted/Infrastructure Provider/Custom/Imported): Infrastructure Provider (vSphere)
Machine type (cloud/VM/metal) and specifications (CPU/memory): VM 2 CPU, 4096 MB
Kubernetes version (use kubectl version):

N/A

Docker version (use docker version):

Client:
 Version:      17.03.2-ce
 API version:  1.27
 Go version:   go1.7.5
 Git commit:   f5ec1e2
 Built:        Tue Jun 27 01:35:00 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.03.2-ce
 API version:  1.27 (minimum version 1.12)
 Go version:   go1.7.5
 Git commit:   f5ec1e2
 Built:        Tue Jun 27 01:35:00 2017
 OS/Arch:      linux/amd64
 Experimental: false

gz#14772

@dbason this is an old issue and should be avoided now with the template cloning process and is only still a thing today in the legacy boot2docker setup: https://github.com/rancher/machine/blob/b14d204b923fdfbdc17be0ff5ef949f8b0601fd9/drivers/vmwarevsphere/create.go#L98
could you check your vmxt file and see if it's explicitly defining the guest os? if you can just post that file we can take a look but the clones i did from say nodes imported from the ubuntu ova all came with Ubuntu Linux 64-bit and if you look at the clone process you can see no code we have to overwrite that guestid.

found it... we USED to do this: https://github.com/rancher/machine/commit/722ccc7d81bf56d2b094aea8cf3457071a3b638a
it's been fixed in later versions.

Closing seeing as this is fixed in later versions.


Unable to install

Since the last update i get an error while installing from gnome extensions

Same.
Workaround:
Remove the old version.
Install new one.
Log out and log in.
Enable extension.

Since the issue is fixed I will close this.


Add license (GPLv3) - towards #9

needed for getting it on f-droid to close #9

ping @cmile

sorry I left the comment in another issue: is it alternativlos to use GPLv3? I had licensed c-beam under WTFPL and would like to keep it that way if possible. I could not find any information about GPLv3 being mandatory.

No it is not alternativlos - there are some apps on f-droid licensed WTFPL - but it needs to have a license - currently there is none at all ..
Can you add the license?

done


parentheses warning I can't figure out

/home/pgruenbacher/Code/cpp/entsim/thirdparty/entt/src/entt/entity/registry.hpp:168:67: warning: suggest parentheses around ‘&&’ within ‘||’ [-Wparentheses]
                         && !((!std::is_same_v<Exclude, Component> && reg.pool<Exclude>()->has(entt)) || ...))

but the code in registry.hpp looks fine when I look at it...

It seems it gets confused by the pack unrolling. What compiler is it? The CI doesn't show the same warning in any case, but it could be a matter of a flag or so.

gcc-8

Oh, ok, Travis runs up to GCC 7 actually. This explains why it doesn't return from the CI.
Btw it seems a wrong warning emitted by the compiler, I'm not that sure how I could suppress it.
I mean, it's valid code and there alreadya lot of parentheses!! :smile:

actually i'm doing gcc 7.3.0 , but i have almost all warnings turned on...
I'll just do -Wno-logical-op-parentheses in my cmake, that gets rid of the warning...
i really don't get why it's complaining, the parentheses are correct...

Well, this isn't the first time I encounter wrong warnings emitted by compilers. The idea is that more is better in this case. A warning isn't an hard error after all and compilers prefer to emit them if in doubts because of bugs or so.

correction -Wno-parentheses fixes the warning

yea I wouldn't mind as much if there were a way to turn the warning off inline in the code instead of the cmakelists, cause then it wouldn't have to involve globally turning off a valid warning

actually this does the trick, i'll reopen for discussion if we want GCC diagnostics littering...
// gcc-7 with -Wall throws an invalid warning regarding parentheses...
#pragma GCC diagnostic ignored "-Wparentheses"
if((std::get<pool_type *>(cpools)->has(entt) && ...)
&& (reg.pool()->has(entt) && ...)
&& !((!std::is_same_v<Exclude, Component> && reg.pool()->has(entt)) || ...))
{
construct();
}
#pragma GCC diagnostic pop

this code is only throwing warnings when entt::exclude<> has more than two types in it when building a group I think, due to a if constexpr wrapping this code... but all the travis tests have only excludes of one type, so that may also be the reason for no warnings by travis...

Wow, I didn't even know such a pragma existed!!
Is it ignored by the other compilers? Btw tell me how to get the same warning, what you've enabled, I'm curious to see where it gets wrong now!

yea I'll make a PR with a test that will actulally replicate it. we didn't have any unittests for >1 exclude components!

Good. I'll look into this when I'm back home. I'm curious to know if there exists a way to suppress the warning other than by using a pragma.
Thanks for the time spent on it so far. :+1:

I'm closing this as a duplicate of #227 - I've just pushed a workaround on branch experimental that doesn't make use of pragmas. :+1:
Thanks for the PR, I've used your test with the CI to reproduce and get rid of the warning.


vcpkg install fails in CI build

CMake Error at /h/vcpkg-1b1ae50e1a69f7c659bd7d731e80b358d21c86ad/scripts/buildsystems/vcpkg.cmake:816 (message):
  vcpkg install failed.  See logs for more information:
  /workspace/cmake-out/build/vcpkg-manifest-install.log
Call Stack (most recent call first):
  /usr/share/cmake-3.16/Modules/CMakeDetermineSystem.cmake:93 (include)
  CMakeLists.txt:26 (project)

Note that the last message is a red herring:
CMake Error: CMake was unable to find a build program corresponding to "Ninja".  CMAKE_MAKE_PROGRAM is not set.  You probably need to select a different build tool.
CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage

GCB: https://console.cloud.google.com/cloud-build/builds;region=us-east1/3608e79b-c10b-4f0d-9ce6-e282d011941d;tab=detail?project=cloud-cpp-testing-resources
Raw: https://storage.googleapis.com/cloud-cpp-community-publiclogs/logs/google-cloud-cpp/main/770a9806694458a3400c575e0f0f351bf8fa9493/ubuntu-focal-cmake-oldest-deps/log-3608e79b-c10b-4f0d-9ce6-e282d011941d.txt

I think this is the same, on mac this time: https://source.cloud.google.com/results/invocations/c6ed9ba1-0453-4beb-9b6c-ff1b16b79959
CMake Error at scripts/cmake/vcpkg_execute_required_process.cmake:128 (message):
    Command failed: /Users/kbuilder/vcpkg-quickstart/downloads/tools/cmake-3.22.2-osx/cmake-3.22.2-macos-universal/CMake.app/Contents/bin/cmake /Users/kbuilder/vcpkg-quickstart/scripts/detect_compiler -DCMAKE_MAKE_PROGRAM=/Users/kbuilder/vcpkg-quickstart/downloads/tools/ninja-1.10.2-osx/ninja -DCMAKE_SYSTEM_NAME=Darwin -DBUILD_SHARED_LIBS=OFF -DVCPKG_CHAINLOAD_TOOLCHAIN_FILE=/Users/kbuilder/vcpkg-quickstart/scripts/toolchains/osx.cmake  ... (etc) ... -DCMAKE_INSTALL_PREFIX=/Users/kbuilder/vcpkg-quickstart/packages/detect_compiler_x64-osx

Call Stack (most recent call first):
  scripts/cmake/vcpkg_configure_cmake.cmake:371 (vcpkg_execute_required_process)
  scripts/detect_compiler/portfile.cmake:18 (vcpkg_configure_cmake)
  scripts/ports.cmake:145 (include)

windows this time: https://source.cloud.google.com/results/invocations/1d506706-f528-4ec8-aa40-a342eb4a7b34

No repeats in 90d, closing.


fix: email as username

:tada: This PR is included in version 0.118.5 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Graph scaling isn't readable

The example recording is just the most notible example of how the graph scales on the highest figure.
The graphs should also default to the Spending being selected and the rest un-selected so the label listing doesn't overflow on expenses/totals.
https://user-images.githubusercontent.com/26049947/217432641-712ce9ae-7007-40fa-99d0-31955acd9263.mov

The example recording is just the most notible example of how the graph scales on the highest figure.

Okay so we have a primary income and some smaller possible incomes. I'm not sure the best way to make the graph scale in a way its easy to read. Logarithmic will make the graph pointless, I think. Any ideas?

The graphs should also default to the Spending being selected and the rest un-selected so the label listing doesn't overflow on expenses/totals.

Are you talking about the total graph, that it should show the transactional accounts by default?

It's a weird balance.. I think overall the graphs are good to look at but I'm not sure if they are good at showing the incoming v. outgoing.
Might be purely because I haven't quite got it where I want it in terms of plotting what I expect to be spending each week (like properly calculating coffee spend as an example). Probably a hard one to fix because it relies so heavily on knowing what you're spending.
Probably absolutely zero way to make it 'better', might just be the learning curve for me to know what I'm looking at.

Is it possible to have the list of savers or expenses more condensed? I think if it was tailored landscape it makes more sense e.g. 5 per column or something? Once you have a lot of Savers (bizzare I know) it becomes a bit long.


Fixed crashing on new versions of VS Code

closes: #66 and #67

fixed using includes on a map
changed the way joining path to node_modules is handled

This saved the day, but sometimes the module is in the asar folder, so my take on it:
private getNodeModulePath(moduleName: string) {
  return ["node_modules.asar", "node_modules"]
    .map(pth=>path.join(vscode.env.appRoot, pth, moduleName))
    .find(pth => fs.existsSync(pth))
}


Rewrite golang project pass-policy-service in java

Part of epic #194

See https://github.com/eclipse-pass/pass-policy-service/tree/205-java-impl for the refactored code

Changes in the code have been made to accommodate the switch to Long from URI for PassEntityIDs, and the Policy repositories field containing a collection of Repositories instear of just their IDs. Changes also made to move from Elide from Fedora, but there is still something wrong with the test setup - lots of NPEs related to this I think, haven't found the cause yet. Hoping it's something simple which I have missed.

Unit tests pass, but integration tests need to be completes to verify that the translation to Java faithfully preserved the rewuired functionality. This is proceeding, but many cases still need to be checked.


Allow punishment types to be translated. FIX for #12

in database.php variable $typeLabels you can translate punishment type names to anything you want(should be in plural), index.php will use those names instead types defined by plugin.
Maybe not most ellegant way, but it works.

I will be creating a language file in the next update.

Fixed in latest update.


Share with 1List

I have the following Intent frrom F-Droid with which I would like to create an entry in 1List:
URI	intent:#Intent;action=android.intent.action.SEND;type=text/plain;launchFlags=0x1b080001;S.android.intent.extra.SUBJECT=kMeet;S.android.intent.extra.TEXT=kMeet%20(Kostenlose%20und%20sichere%20L%C3%B6sung%20f%C3%BCr%20Videokonferenzen)%20-%20https%3A%2F%2Ff-droid.org%2Fapp%2Fcom.infomaniak.meet;end

VERSION	1
ACTION	android.intent.action.SEND
TYPE	text/plain
FLAGS	0x1b080001
EXTRA	android.intent.extra.SUBJECT	12	kMeet
EXTRA	android.intent.extra.TEXT	12	kMeet (Kostenlose und sichere Lösung für Videokonferenzen) - https://f-droid.org/app/com.infomaniak.meet

MATCHING ACTIVITIES	22
0	LABEL  	SMS/MMS
  	NAME   	com.android.mms.ui.ComposeMessageActivity
  	PACKAGE	com.android.mms
1	LABEL  	Bluetooth
  	NAME   	com.android.bluetooth.opp.BluetoothOppLauncherActivity
  	PACKAGE	com.android.bluetooth
2	LABEL  	Firefox
  	NAME   	org.mozilla.fenix.IntentReceiverActivity
  	PACKAGE	org.mozilla.firefox
3	LABEL  	Man Man
  	NAME   	com.adonai.manman.MainPagerActivity
  	PACKAGE	com.adonai.manman
4	LABEL  	F-Droid Build Status
  	NAME   	de.storchp.fdroidbuildstatus.MainActivity
  	PACKAGE	de.storchp.fdroidbuildstatus
5	LABEL  	Book Reader
  	NAME   	com.github.axet.bookreader.activities.MainActivity
  	PACKAGE	com.github.axet.bookreader
6	LABEL  	NewPipe
  	NAME   	org.schabi.newpipe.RouterActivity
  	PACKAGE	org.schabi.newpipe
7	LABEL  	Nekogram X
  	NAME   	org.telegram.ui.LaunchActivity
  	PACKAGE	nekox.messenger
8	LABEL  	OsmAnd~
  	NAME   	net.osmand.plus.activities.MapActivity
  	PACKAGE	net.osmand.plus
9	LABEL  	QuickDic
  	NAME   	com.hughes.android.dictionary.DictionaryActivity
  	PACKAGE	de.reimardoeffinger.quickdic
10	LABEL  	Fennec
  	NAME   	org.mozilla.fenix.IntentReceiverActivity
  	PACKAGE	org.mozilla.fennec_fdroid
11	LABEL  	Quillnote
  	NAME   	org.qosp.notes.ui.MainActivity
  	PACKAGE	org.qosp.notes
12	LABEL  	Desktop Shortcut
  	NAME   	ru.gelin.android.browser.open.ShortcutActivity
  	PACKAGE	ru.gelin.android.browser.open
13	LABEL  	Bitwarden
  	NAME   	com.x8bit.bitwarden.MainActivity
  	PACKAGE	com.x8bit.bitwarden
14	LABEL  	Speichern unter
  	NAME   	org.primftpd.share.ReceiveSaveAsActivity
  	PACKAGE	org.primftpd
15	LABEL  	Share via HTTP
  	NAME   	com.MarcosDiez.shareviahttp.activities.SendFileActivity
  	PACKAGE	com.MarcosDiez.shareviahttp
16	LABEL  	VLC
  	NAME   	org.videolan.vlc.StartActivity
  	PACKAGE	org.videolan.vlc
17	LABEL  	Lauschangriff
  	NAME   	io.github.muntashirakon.AppManager.intercept.ActivityInterceptor
  	PACKAGE	io.github.muntashirakon.AppManager
18	LABEL  	K-9 Mail
  	NAME   	com.fsck.k9.activity.MessageCompose
  	PACKAGE	com.fsck.k9
19	LABEL  	Speichern unter
  	NAME   	com.simplemobiletools.filemanager.pro.activities.SaveAsActivity
  	PACKAGE	com.simplemobiletools.filemanager.pro
20	LABEL  	Snapdrop
  	NAME   	com.fmsys.snapdrop.MainActivity
  	PACKAGE	com.fmsys.snapdrop
21	LABEL  	Nextcloud dev
  	NAME   	com.owncloud.android.ui.activity.ReceiveExternalFilesActivity
  	PACKAGE	com.nextcloud.android.beta

1List does not turn up but I would like it to.
This intent was intercepted using "Laushangriff" from F-Droid.

Where does this intent come from ?

If I open F-Droid, open the page of the mentioned app and then I click on share. Then, this is an intent that is created.

This intent above is probably generated by an app that is not installed. Then, the description is shared with the text. It has this in it:

EXTRA	android.intent.extra.SUBJECT	12	kMeet
EXTRA	android.intent.extra.TEXT	12	kMeet (Kostenlose und sichere Lösung für Videokonferenzen) - https://f-droid.org/app/com.infomaniak.meet

I would like to add this somehow as an entry to a list. Sharing text adding it to a TODO-list.

I'm sorry but I don't understand what you are trying to do. Is it a bug you found or a feature request? What about those intents ? What's about Fdroid share button? Does it have something related to 1List ?

They want to share the URL address of the app they are on the page of inside fDroid.
It's likely the same thing I want. The ability to save links and selected text by using share and selecting 1list from the share sheet that pops up. Currently there is no way to do that.


Sharp as a dependency of Ghost, require('sharp') causes a full process crash

We're seeing several people reporting this same issue, all on systems where sharp was previously installed OK.
I don't have access to servers, I can't guarantee prerequisites match and I also haven't yet managed to reproduce, but we've had enough reports and enough detail now that I am fairly stuck and need some insider knowledge.
Relevant issue in Ghost is here: https://github.com/TryGhost/Ghost/issues/11129
Ghost has sharp as an optional dependency, as we know the binary install could fail.
To further mitigate this, we wrap require in a try-catch block:
const makeSafe = fn => (...args) => {
    try {
        require('sharp');
    } catch (err) {
       ...
    }

One of the affected users tried adding console logs to this code:
const makeSafe = fn => (...args) => {
    common.logging.info('log 1');
    try {
        common.logging.info('log 2');
        require('sharp');
    }
    ...

On their system, every time this code is executed, "log 1" is output and then the process crashes with no further logs or errors.
We're trying to get more information about what state their system is in, and add more debug info to both Ghost and Ghost-CLI to help find the problem, but we're stabbing in the dark.
The point of the try/catch should be that the require is safe. Sharp is present on these machines, and so I don't understand in what case require could cause a full process crash, but I assume that sharp must be installed but in a bad state?

Please can you try setting the npm_config_loglevel=verbose environment variable at https://github.com/TryGhost/Ghost-CLI/blob/master/lib/tasks/yarn-install.js#L67 , which will make prebuild-install output more of its decision making about prebuilt binaries.

It looks like the yarn wrapper logic in https://github.com/TryGhost/Ghost-CLI/blob/master/lib/utils/yarn.js is missing support for the stderr Stream, so some install-time error message will be lost.

Not arguing at all that we need to improve the CLI output so that errors are visible, and we are working on that 👍
The problem here is that we have sharp as an optional dependency and wrapped in a try-catch to account for install failures, because we can’t guarantee the environment, but requiring sharp crashes the whole process instantly.
There’s nothing more we can do to account for this than we are already doing. If the install fails, we’re OK with that (even if we don’t show it), if require throws an exception, we’re OK with that, but this a full process crash which is coming from sharp.

I notice there have been some new details/discussion on https://github.com/TryGhost/Ghost/issues/11129 so I've asked a few questions there in the hope we can narrow down what's causing the crash.
I've also submitted an improvement to prebuild-install, which sharp uses at install time, to add support for the yarn --verbose flag (it already supports npm --verbose) - see https://github.com/prebuild/prebuild-install/pull/111

It looks like the upstream issue at https://github.com/TryGhost/Ghost/issues/11129 has now been closed, with people reporting via :tada: emoji that upgrading sharp to the latest version has fixed this.
Even though we never quite found out exactly what was causing this, there were a number of improvements to install-time logging added to both prebuild-install and Ghost, so should something similar come up again we're in a better place to find it.
If you hadn't already seen #1282, the next v0.25.0 release of sharp is migrating to N-API internally, which should remove a whole class of common upgrade problems.
I'll close this but please feel free to re-open if people keep reporting this problem against Ghost with the latest version of sharp.

Was a super weird and nigh-impossible to reproduce issue, thanks for your time & 🤞 it's def resolved now.

Unfortunately, I am still seeing this bug. I am running Ghost on Ubuntu 20.04.3 LTS, I followed the instructions at https://ghost.org/docs/install/ubuntu/ to install Ghost. It looks like anytime Ghost tries to use Sharp to resize images, Ghost crashes with an error like this:
traps: node[190951] trap invalid opcode ip:7f51fe938dfb sp:7ffcdffdfd60 error:0 in libvips-cpp.so.42[7f51fe62b000+aac000]
This is with Sharp 0.29.3 on amd64.

@idmacdonald Please can you open a new issue, additionally providing the output of cat /proc/cpuinfo


More compact front page

Suggestion from community member:
"This leads me to my second point, which is if the markets were to load at a reasonable speed, they should be much more visible on page landing. Why hide the most relevant content? As much as I like the cool hero graphic - I quickly have to 'ignore' it every time I land on the page and scroll to what I'm really looking for - the markets.
This point also perhaps stands for the "popular topics" and how much size they take up/how much further down they push the markets
forgive my crude mockup, but to illustrate.."

It's already here https://github.com/zeitgeistpm/ui/issues/320

It's already here #320

Doesn't that one just delete the Popular topics? This suggestion seems different


Appveyor environment missing required OpenGL version

Appveyor, which is doing our windows testing, is giving the following error:
"ERROR: Failure: MissingFunctionException (glCreateProgram is not exported by the available OpenGL driver.  VERSION_2_0 is required for this functionality.)"
While I can confirm that the package does work on Windows (our experimental setup is windows-based, although development is done on Linux), it would be good if we could include Windows in our automated testing toolchain.

The Appveyor problem has now been solved, simply by not loading OpenGL-requiring tests or objects if OpenGL isn't available.  See commit 98c20ed707504565d17e00fe50de0f4f8582552c


Laravel 9.x Compatibility

This is an automated pull request from Shift to update your package code and dependencies to be compatible with Laravel 9.x.
Before merging, you need to:

Checkout the l9-compatibility branch
Review all comments for additional changes
Thoroughly test your package

If you do find an issue, please report it by commenting on this PR to help improve future automation.

:alembic: Using this package? If you would like to help test these changes or believe them to be compatible, you may update your project to reference this branch.
To do so, temporarily add Shift's fork to the repositories property of your composer.json:
{
    "repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/laravel-shift/unobserve.git"
        }
    ]
}

Then update your dependency constraint to reference this branch:
{
    "require": {
        "monooso/unobserve": "dev-l9-compatibility",
    }
}

Finally, run: composer update

@monooso Any update on this?

@laravel-shift Can you update the composer.lock file, please? I don't even have PHP installed any more.

@denisdulici See above.

Your requirements could not be resolved to an installable set of packages.
Problem 1
- Root composer.json requires laravel/framework ^9.9 -> satisfiable by laravel/framework[v9.9.0].
- monooso/unobserve 5.x-dev requires illuminate/support ^8.22.1 -> satisfiable by illuminate/support[v8.22.1, ..., v8.83.9].
- Only one of these can be installed: illuminate/support[v5.0.0, ..., v5.8.36, v6.0.0, ..., v6.20.44, v7.0.0, ..., v7.30.6, v8.0.0, ..., v8.83.9, v9.0.0, ..., v9.9.0], laravel/framework[v9.9.0]. laravel/framework replaces illuminate/support and thus cannot coexist with it.
- Root composer.json requires monooso/unobserve 5.x-dev -> satisfiable by monooso/unobserve[5.x-dev].

Closed in favour of #22.


Check for existence of tests as possible extension.

Tests templates were being ignored with expected .tests.js style extension.

@deldreth thanks a lot for your contribution !


README python code rendered with erroneous underlining

I recently noticed that the python code in the README is now formatted with every character underlined when viewed on GitHub, which is incorrect/buggy and impacts readability. I'm guessing that GitHub made a styling change that inadvertently clashes with RST rendering; we'll have to either figure out if GitHub is planning to fix this or we will have to tweak the README to work around.

This appears to be fixed now - presumably addressed by GitHub fixing their styling.


Add ES to Collector Service

Coverage remained the same at 100.0% when pulling 8d825c37513f9b4122707d8ac22943f3cdd000b8 on es-collector into 94350ea002e84ad474c36b3811c2d15c02619c11 on master.

Coverage remained the same at 100.0% when pulling 726901c06614a27aca49aade92df336accb8cc2b on es-collector into 94350ea002e84ad474c36b3811c2d15c02619c11 on master.

Coverage remained the same at 100.0% when pulling 67169f3d12f3e55211b1574eab9ad9a9c761870e on es-collector into 94350ea002e84ad474c36b3811c2d15c02619c11 on master.


Add types to ecmascript.ts

Make ecmascript.ts type-safe:

Improves types for slots and intrinsics
ecmascript.ts now has types throughout and compiles with  noImplicitAny
Fixes BigInt errors in a few places to fix compiler errors and test failures. Will be replaced by James's work on JSBI.
Found and fixed a few index.d.ts bugs in the public types.
Overhauled how plural units are handled in TS types.
Some initial work in calendar.ts, but I paused that while James does work on that file.
Otherwise, only a few few changes outside ecmascript.ts that were required to fix compiler errors.
A new internal types file for non-public shared types.

BTW, this is part of a larger roadmap. Here's the tentative plan:

Merge #72 (preventing overwriting parameters in all files except ecmascript.ts (to prevent merge conflicts with this file)
Merge this PR after rebasing on top of #72
Prevent rewriting parameters in ecmascript.ts, just like #72 does for all other files. I'll plan to do this in another PR because this PR is already big enough!
Add parameter type annotations on non-ecmascript files. I have a regex search-n-replace solution in mind for this.
@12wrigja's big JSBI PR #77. Probably makes sense to merge this one after the all the PRs above so we can get maximum TS safety for such a large runtime change.

Not sure why Test262 shows as failed given that the output doesn't report any failures. Trying to re-run.

Seems like the GH UI is doing something weird - I can't seem to respond to any of the open conversations unless I click "into" them, and even then the comments don't seem to propagate back.
I have no objections to merging this as-is and following up on my comments later, especially given some of them might be fixed by compiler flag changes (e.g. strictNullChecks).


Castling with the move method

I can't seem to castle with the move method. Neither 0-0 or Kg1 works.

OK I realised it was O-O not 0-0.


🎉 wip: implemented error state for backend socket connection and othe…

The spinner on the home page keeps rolling in case there is a fault from the backend.
🚨 Problem:

If the backend is not running
If there is some error in the connection.

🪜 Steps to reproduce:

Clone the repository.
Run the front end withoug the backend.
Or do not give proper Opne AI API key.
Sometimes the problem persists due to mi configurations in the local storage. In this case if we run even both front end as well as backend even then the issue persists.

✅ Solution:
I have introduced another state hasError which keeps track of whether there is any error in the conection. In case there is erro UI will display error message along with the toast. So backend won't be blocker.

@ItzCrazyKns

@ItzCrazyKns
Hey I am making a new pull request here. Let  me know what is required for it to merge.


Bump Knative dependencies to 0.18

Related to https://github.com/knative-sandbox/kperf/issues/6.

@zhanggbj I've bump Knative dependencies to 0.18 and tested well locally. Cloud you pls have a review?

/lgtm
@gyohuangxin Looks great and thanks for your PR! Merging it.


关于Drop的一个想法

是否可以将edge浏览器内置的drop功能，做成独立的windows应用，使它不仅支持在线发送文档，还能支持局域网传输，同时还具有云存储功能

Translation using Google Translate:
Is it possible to make the built-in drop function of the edge browser into an independent windows application, so that it not only supports online sending of documents, but also supports LAN transmission, and also has cloud storage function

Thank you for your question. However, this repository is specific to DevTools. DevTools is a developer feature in Edge which is unrelated to Drop.
Can you please send your feedback again by using the browser's feedback mechanism instead? Here's how:

Click Settings and more (the ... button in the top-right corner of the browser).
Click Help and feedback.
Click Send feedback.

Thank you for your understanding.

Translation using Google Translate:
谢谢你的问题。 但是，此存储库特定于 DevTools。 DevTools 是 Edge 中的开发人员功能，与 Drop 无关。
您能否改用浏览器的反馈机制再次发送您的反馈？ 就是这样：

单击设置和更多（浏览器右上角的“...”按钮）。
单击帮助和反馈。
单击发送反馈。

感谢您的理解。


Switch Artifact Names to use BuildNumber

It's still unclear what caused this issue: a build failed with the error
"Artifact .. already exists for build $(Build.BuildId)".
The documentation for AZP is not clear how BuildId is set or calculated,
but we can have more confidence that the artifact names will be unique
when using BuildName which might stop this from occuring in the future.
Resolves #1703
Signed-off-by: Trevor Bramwell<EMAIL_ADDRESS>

Yep; Thanks!


Sequences Table - Show Parcel Name

Add a new column representing the parcel name in the sequences table

Implemented in #1275.


Expo - Android Upgrading to Expo SDK 50 leads to ERROR - "Super expression must either be null or a function"

Base code was a fully working Android App using Expo SDK 49 & Expo Router V2 that uses Daily successfully. There has been no change to the working code.
Issue happened on upgrade to Expo SDK 50 & Expo Router V3.
Expected Behaviour:
Successful build & loading of App
Bug / Unexpected Behaviour
ISSUE 1: Instead of a successful build & loading of app, I am getting an error when I load the app using 'npx expo start' :

LOG MediaDevices _registerEvents invoked
ERROR  TypeError: Super expression must either be null or a function, js engine: hermes
at ContextNavigator (http://:8081/appEntry.bundle//&platform=android&dev=true&hot=false&lazy=true&transform.engine=hermes&transform.bytecode=true&transform.routerRoot=app:157441:24)
at ExpoRoot (http://:8081/appEntry.bundle//&platform=android&dev=true&hot=false&lazy=true&transform.engine=hermes&transform.bytecode=true&transform.routerRoot=app:157397:28)
at appEntry
at withDevTools(appEntry) (http://:8081/appEntry.bundle//&platform=android&dev=true&hot=false&lazy=true&transform.engine=hermes&transform.bytecode=true&transform.routerRoot=app:136391:27)
at RCTView
at View (http://:8081/appEntry.bundle//&platform=android&dev=true&hot=false&lazy=true&transform.engine=hermes&transform.bytecode=true&transform.routerRoot=app:70438:43)
at RCTView
at View (http://<IP_ADDRESS>:8081/appEntry.bundle//&platform=android&dev=true&hot=false&lazy=true&transform.engine=hermes&transform.bytecode=true&transform.routerRoot=app:70438:43)
at AppContainer (http://:8081/appEntry.bundle//&platform=android&dev=true&hot=false&lazy=true&transform.engine=hermes&transform.bytecode=true&transform.routerRoot=app:70249:36)
at main(RootComponent) (http://:8081/appEntry.bundle//&platform=android&dev=true&hot=false&lazy=true&transform.engine=hermes&transform.bytecode=true&transform.routerRoot=app:117888:28)

RELATED ISSUE 2: Further, any component (even a dummy component with no logic) that imports Daily or DailyMediaView results in WARNING :

[Layout children]: No route named MyDailyComponent exists in nested children".

Both the Issue 1 (Error) & Issue 2 (Warning) go away if we remove the Import statement of Daily & DailyMediaView from the component.
My import statement of Daily looks like this:

import Daily, { DailyMediaView } from '@daily-co/react-native-daily-js';

The above import statement worked without any issues in Expo SDK 49 and Expo Router V2.
System information

Using Expo SDK 50.0.15, Expo Router 3.4.8.
Windows 10
Following dependencies used:
"@config-plugins/react-native-webrtc": "^8.0.0",
"@daily-co/config-plugin-rn-daily-js": "^0.0.5",
"@daily-co/react-native-daily-js": "^0.59.0",
"@daily-co/react-native-webrtc": "^118.0.3-daily.2",
Test device was on Android version 14

Tried to use the<EMAIL_ADDRESS>but same issue happens

Hi @badhrin,
It looks like one of our user has already faced this same issue while migrating to Expo 50. More details here.
And to solve this, they needed to upgrade the event-target-shim version to match the same one requested by react-native-webrtc, version 6.0.2. More details here.
Let me know if this will fix your issue as well.
You can also take a look in our demo app, which is already using Expo 50.

@filipi87  - Thank you for the response. Fixed the issue. To help others in the future, please see if you can update the documentation at https://www.npmjs.com/package/@daily-co/config-plugin-rn-daily-js to include this 'event-target-shim' version  check.
NEW ISSUE
However, I am not able to make calls using Daily now. The error that I have is:

TypeError: Cannot read property 'getRandomBase64String' of undefined

Error: ENOENT: no such file or directory, open MY/LOCAL/PATH
errno: -4058,
code: 'ENOENT',
syscall: 'open',

I thought this could be due to the new dependencies of expo-random & react-native-get-random-values. I installed both as instructed in https://www.npmjs.com/package/@daily-co/config-plugin-rn-daily-js?activeTab=readme. Then I checked the Demo App and found that there was no expo-random dependency. So I uninstalled expo-random & also upgraded the react-native-get-random-values to the same version as in the Demo App, but this error persists.
I searched the closed issues, but did not find anything. Please let me know what I am missing.

@filipi87  - Thank you for the response. Fixed the issue. To help others in the future, please see if you can update the documentation at https://www.npmjs.com/package/@daily-co/config-plugin-rn-daily-js to include this 'event-target-shim' version  check.
I will rebuild completely, test & then close this issue if all works. Please give me a day. Thanks.

@filipi87  - Thank you. Tested it & updating 'event-target-shim' fixed the issue.

That is great to hear @badhrin.
And thanks for your suggestion, I will add a troubleshooting session inside our plugin. 🙂


In notebooks, record an interrupt as a terminated run

Currently when the kernel is interrupted (eg: a few epochs into a training run) the run status is set to error, an UnboundLocalError is raised with the following stack trace, and no run object is returned:
KeyboardInterrupt                         Traceback (most recent call last)
~/.virtualenvs/actrain/lib/python3.6/site-packages/guild/ipy.py in _run(op, flags, opts)
    354             with util.Chdir(run.path):
--> 355                 result = op(**flags)
    356     except Exception as e:
<timed exec> in train()
~/.virtualenvs/actrain/lib/python3.6/site-packages/allennlp/training/trainer.py in train(self)
    477             epoch_start_time = time.time()
--> 478             train_metrics = self._train_epoch(epoch)
    479
~/.virtualenvs/actrain/lib/python3.6/site-packages/allennlp/training/trainer.py in _train_epoch(self, epoch)
    326
--> 327             train_loss += loss.item()
    328
KeyboardInterrupt:
During handling of the above exception, another exception occurred:
UnboundLocalError                         Traceback (most recent call last)
<timed exec> in <module>
~/.virtualenvs/actrain/lib/python3.6/site-packages/guild/ipy.py in run(op, *args, **kw)
    278     flags = _init_flags(op, args, kw)
    279     run = _init_runner(op, flags, opts)
--> 280     return run()
    281
    282 def _pop_opts(kw):
~/.virtualenvs/actrain/lib/python3.6/site-packages/guild/ipy.py in <lambda>()
    344
    345 def _single_runner(op, flags, opts):
--> 346     return lambda: _run(op, flags, opts)
    347
    348 def _run(op, flags, opts):
~/.virtualenvs/actrain/lib/python3.6/site-packages/guild/ipy.py in _run(op, flags, opts)
    361         return run, result
    362     finally:
--> 363         _finalize_run_attrs(run, exit_status)
    364
    365 def _init_run():
UnboundLocalError: local variable 'exit_status' referenced before assignment

This PR captures the interrupt, sets the run status to terminated and returns the run object. No exceptions are raised.

I went ahead and merged this, but made some changes in 42ee9e5f.
We don't want to eat any exceptions by logging and returning some guessed-at-value for a response. Exceptions should be explicitly handled by the called - including termination exceptions.
Logging the right exit status so that the run shows up as terminated is the right change here. We're using -15 for the CLI based runs so I changed that as well for consistency.
I also modified the exception generating logic to preserve the original traceback for the run error and terminated exceptions.
You can see the behavior in the tests here.
Thanks a lot for the PR!


Assertion failed Only one-byte varints are supported!

Only one-byte varints are supported!

Do you have "Reveal votes" enabled?
Do you have a knife equipped from inventory changer?

Do you have "Reveal votes" enabled?
Do you have a knife equipped from inventory changer?

Yes
Yes

Have the same issue but I had only knife  equipped  from inventory changer

And if you press ignore and then play, you can do it untill you get a knife in your hand and you will get the same error @danielkrupinski

Thread 1 "csgo_linux64" received signal SIGABRT, Aborted. 0x00007f6c2228cd22 in raise () from /usr/lib/libc.so.6 (gdb) #0  0x00007f6c2228cd22 in raise () from /usr/lib/libc.so.6 #1  0x00007f6c22276862 in abort () from /usr/lib/libc.so.6 #2  0x00007f6c22276747 in __assert_fail_base.cold () from /usr/lib/libc.so.6 #3  0x00007f6c22285616 in __assert_fail () from /usr/lib/libc.so.6 #4  0x00007f6be7aecdab in ProtobufReader::readVarint (this=0x7ffe019ec5b0, offset=1) at /home/michael/Development/C++/Cheats/Psyris/src/Hacks/../ProtobufReader.h:44 #5  0x00007f6be7aea6c0 in ProtobufReader::readInt32 (this=0x7ffe019ec5b0, index=2 '\002') at /home/michael/Development/C++/Cheats/Psyris/src/Hacks/../ProtobufReader.h:19 #6  0x00007f6be7ae2a54 in Misc::onVoteStart (data=0x7f6b86a2d7f8, size=86) at /home/michael/Development/C++/Cheats/Psyris/src/Hacks/Misc.cpp:1315 #7  0x00007f6be7b1071b in dispatchUserMessage (thisptr=0x7f6c01e2afc0, type=UserMessageType::VoteStart, passthroughFlags=0, size=86, data=0x7f6b86a2d7f8)     at /home/michael/Development/C++/Cheats/Psyris/src/Hooks.cpp:458

Thread 1 "csgo_linux64" received signal SIGABRT, Aborted.
0x00007f6c2228cd22 in raise () from /usr/lib/libc.so.6
(gdb) #0  0x00007f6c2228cd22 in raise () from /usr/lib/libc.so.6
#1  0x00007f6c22276862 in abort () from /usr/lib/libc.so.6
#2  0x00007f6c22276747 in __assert_fail_base.cold () from /usr/lib/libc.so.6
#3  0x00007f6c22285616 in __assert_fail () from /usr/lib/libc.so.6
#4  0x00007f6be7aecdab in ProtobufReader::readVarint (this=0x7ffe019ec5b0, offset=1) at /home/michael/Development/C++/Cheats/Psyris/src/Hacks/../ProtobufReader.h:44
#5  0x00007f6be7aea6c0 in ProtobufReader::readInt32 (this=0x7ffe019ec5b0, index=2 '\002') at /home/michael/Development/C++/Cheats/Psyris/src/Hacks/../ProtobufReader.h:19
#6  0x00007f6be7ae2a54 in Misc::onVoteStart (data=0x7f6b86a2d7f8, size=86) at /home/michael/Development/C++/Cheats/Psyris/src/Hacks/Misc.cpp:1315
#7  0x00007f6be7b1071b in dispatchUserMessage (thisptr=0x7f6c01e2afc0, type=UserMessageType::VoteStart, passthroughFlags=0, size=86, data=0x7f6b86a2d7f8)
    at /home/michael/Development/C++/Cheats/Psyris/src/Hooks.cpp:458


How is 'data/musescore_fingers.pickle' created?

@PRamoneda
In file loader.py, lines 431-435 there is loading binary file that is not created and I haven't found code that creates it.
It there missing a piece of code that creates those pickles? Also, I don't see Thumbset folder being used anywhere in the code.
def musescore_dataset(set_name, hand='right', w_type='w11'):     if w_type == 'w11':         windows = load_binary('data/musescore_fingers.pickle')[hand][set_name]     elif w_type == 'random':         windows = load_binary('data/musescore_fingers_w_up64.pickle')[hand][set_name]
Thanks. Dominik.

Did you find the solution?


Add the ability to set default HTTPoison options

It would be helpful to specify the HTTPoison options to avoid timeouts, etc.

Added HTTPoison options in https://github.com/mgallo/openai.ex/releases/tag/v0.2.0


Further expand tests around referential actions, referential integrity and relationMode

Follow up for https://github.com/prisma/prisma/issues/10806 and https://github.com/prisma/prisma-private/issues/197
Details see internal document:
https://www.notion.so/prismaio/Phase-2-prepare-for-GA-fe01774a66a74d64a495ec89fad11e17#91024db079a54ceba2a96cacfaee591e
https://www.notion.so/prismaio/Phase-2-5-sprint-4-6-0-prepare-for-GA-189bbdf542a64bbf96ca07dd196f26c4#1cd9b00ac6d845dab7a7fd842f6a27ca

Hi there,
As part of our effort to clean up our GitHub repo, we’re closing this issue to help focus on features and improvements that align with our focus areas and those of our community.
This issue was originally created for internal tracking purposes, but if you feel this is important to you, feel free to reopen the issue and get like-minded users to upvote as we will prioritize fixing issues based on community interest.
For more insight into our priorities and how we’re thinking about the future of Prisma, please see our blog post: https://www.prisma.io/blog/prisma-orm-manifesto.
Thank you for your understanding and support!


Pr/v1.2.1

This is the Ambassador 1.2.1 release.

Closing because this should've been named rel/v1.2.1.


Implement the BufferIntrospective operator

We need a new operator with this signature:
trait Observable[+T] {
  def bufferIntrospective(os: OverflowStrategy): Observable[Seq[T]]
}

What this will do is to buffer signals for as long as the downstream subscriber is busy. And after the downstream subscriber is available again for onNext, then it sends the buffered signals as a Seq.
Implementation sample: https://gist.github.com/dvtomas/e47bce4f8849da9721dc

As I've commented on gist, perhaps these signatures would be more appropriate:
trait Observable[+T] {
  def bufferIntrospective: Observable[Seq[T]]

  def bufferIntrospective(maxSize: Int): Observable[Seq[T]]
}

They resemble the signatures of Observable.buffer, as does the principle of operation

I've updated bufferIntrospective implementation in the gist, I believe it is correct now. I also have some (two :) unit tests, but it is difficult to present them here as they use some custom helpers, and I also use Li Haoyi's µTest for testing. If there's interest, though, I can try to port them somehow..
Anyway, I now have in mind an even more general "introspective" operator, that bufferIntrospective could be implemented in terms of, but I need to think about it more.

This is already on master, closing.


Matplotlib issues with "thin" font styles and .ttc font files

With Helvetica Neue as the preferred font, the "thin" style can overwrite regular styles on macOS (matplotlib/matplotlib#8788). The next version of proplot will no longer try to use Helvetica Neue -- it will just try to use Helvetica.

There is also evidently an issue when trying to save figures with .ttc fonts as PDFs (matplotlib/matplotlib#3135). Perhaps the next version of proplot should remove all .ttc font files from font_manager.fontManager.ttflist.

I have also added sections to colors_fonts.ipynb that describes how to add your own fonts & add your own colors.

Closed by #95


Pinned query

Is your feature request related to a problem? Please describe.
We need to promote a list of documents, for example 240.
And at the same time all filters should be applied, so we make sure that this documents are searchable and match criteria's.
What we need already implemented in X-Pack https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-pinned-query.html#query-dsl-pinned-query

Hi Hronom, thanks for your feature request with your use case! 😁 We will consider it and there is also an old issue (https://github.com/opensearch-project/OpenSearch/issues/72) for tracking the feature of "Pinned Query".
In the meanwhile, we are also glad to see people in the community can drive it.

I guess we can keep just one of them open as a tracking issue and resolve the other as a duplicate, since both are around supporting Pinned queries as a feature

Let's close this as a duplicate. Thanks @tlfeng and @Bukhtawar!


Enable on spilling test on left/right semi projection types

Also fix a spilling document alignment

@xiaoxmeng Thank you for increasing test coverage.

@mbasmanova  Thanks for the quick review!


[ISSUE #3000] Optimize the code and fix a comment

What is the purpose of the change
Optimize and simplify the code
Brief changelog

Use java built-in functions to simplify the code

Fixed wrong words in comments

Coverage decreased (-0.3%) to 53.82% when pulling 2aa0672651173f06da984caf4a7cf3444b41545a on IntroDrop:develop into df1d93fc8859377b92ba87c6947911281656f355 on apache:develop.