bug: If device layers requested exceed model layers, host layers overflow

Describe the bug
If they number of device layers exceed the models, then the host layers to assign seems to wrap/overflow instead of the expected 0.
NOTE: With llama-cpp you can configure a larger number of layers and host layers will remain 0 while only the needed layers are used as device layers.
RUST_BACKTRACE=1 ./mistralrs-bench --num-device-layers 33 gguf -m . -t . -f Hermes-2-Pro-Mistral-7B.Q4_K_M.gguf
# ...
INFO mistralrs_core::device_map: Using 33 layers on device and<PHONE_NUMBER>3709551615 on host.

thread 'main' panicked at library/alloc/src/raw_vec.rs:25:5:
capacity overflow
stack backtrace:
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
   2: alloc::raw_vec::capacity_overflow
   3: <T as alloc::vec::spec_from_elem::SpecFromElem>::from_elem
   4: mistralrs_core::device_map::DeviceMapMetadata::into_mapper
   5: mistralrs_core::models::quantized_llama::ModelWeights::from_gguf
   6: <mistralrs_core::pipeline::gguf::GGUFLoader as mistralrs_core::pipeline::Loader>::load_model_from_path
   7: <mistralrs_core::pipeline::gguf::GGUFLoader as mistralrs_core::pipeline::Loader>::load_model_from_hf
   8: mistralrs_bench::main

Context:

Q4_KM GGUF model used, but this applies to any model where the layers is exact.
Since mistral.rs seems to enforce loading first through HuggingFace API calls, I've worked around that by allowing 401 (Unauthorized) panic as described here, while unlike llama-cpp additional config files is enforced... I sourced those from here, but it lacked a tokenizer.json file so I gave it one from another model (this has no relevance on the error encountered).

Additional feedback
mistral.rs output doesn't information like layers as clear to me as llama-cpp, and I don't know if there's some sort of inspect command to output/query the metadata?
I had thought it was 33 layers, but looking over the llama-cpp output again I see it's 32 with an extra layer appended afterwards:
ggml_cuda_init: CUDA_USE_TENSOR_CORES: yes
ggml_cuda_init: found 1 CUDA devices:
  Device 0: NVIDIA GeForce RTX 4060 Laptop GPU, compute capability 8.9, VMM: yes
llm_load_tensors: ggml ctx size =    0.30 MiB
llm_load_tensors: offloading 32 repeating layers to GPU
llm_load_tensors: offloading non-repeating layers to GPU
llm_load_tensors: offloaded 33/33 layers to GPU
llm_load_tensors:        CPU buffer size =    70.38 MiB
llm_load_tensors:      CUDA0 buffer size =  4095.16 MiB

I find this sort of information quite helpful, so if mistral.rs could communicate that better too that'd be nice 👍
Better communicating the device/GPU like above would also be nice vs what it currently displays:
mistralrs_bench: Loading model `.` on Cuda(CudaDevice(DeviceId(1)))...

Latest commit
v0.1.8: https://github.com/EricLBuehler/mistral.rs/commit/ca9bf7d1a8a67bd69a3eed89841a106d2e518c45

Bench OOMs (while llama-cpp doesn't)
Additionally, when trying with exact layer count, while these models had no issue with llama-cpp, they would OOM with mistral.rs. I was able to avoid that with lower layer count but the performance suffers notably? (anything from 28 layers or above was OOM for mistral.rs).
With 32 layers:
ERROR mistralrs_core::engine: prompt step - Model failed with error: WithBacktrace { inner: Cuda(Cuda(DriverError(CUDA_ERROR_OUT_OF_MEMORY, "out of memory"))), backtrace: Backtrace [{ fn: "candle_core::error::Error::bt" }, { fn: "candle_core::quantized::cuda::QCudaStorage::dequantize_f16" }, { fn: "candle_core::quantized::QTensor::dequantize_f16" }, { fn: "candle_core::quantized::QMatMul::dequantize_f16" }, { fn: "candle_core::quantized::QMatMul::forward_via_f16" }, { fn: "mistralrs_core::layers::MatMul::qmatmul" }, { fn: "mistralrs_core::models::quantized_llama::ModelWeights::forward" }, { fn: "<mistralrs_core::pipeline::gguf::GGUFPipeline as mistralrs_core::pipeline::Pipeline>::forward_inputs" }, { fn: "mistralrs_core::pipeline::Pipeline::step::{{closure}}" }, { fn: "mistralrs_core::engine::Engine::run::{{closure}}" }, { fn: "tokio::runtime::runtime::Runtime::block_on" }, { fn: "std::sys_common::backtrace::__rust_begin_short_backtrace" }, { fn: "core::ops::function::FnOnce::call_once{{vtable.shim}}" }, { fn: "std::sys::pal::unix::thread::Thread::new::thread_start" }] }
thread 'main' panicked at mistralrs-bench/src/main.rs:107:61:
internal error: entered unreachable code
stack backtrace:
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::panicking::panic
   3: mistralrs_bench::run_bench
   4: mistralrs_bench::main

Might be partially due to lack of batch? (-p 4096 is OOM on lower layers too, llama-cpp had no issue with -p 4096 -b 512 but it could also handle -b 4096 with 32 GPU layers too)
Performance vs llama-cpp
$ ./mistralrs-bench -p 512 -g 0 -r 1 -c 1 --num-device-layers 24 gguf -m . -t . -f model.gguf

+-------+---------+--------+--------------+--------------+-------------+--------------+
| model | backend | test   | t/s          | ms/t         | concurrency | throughput/s |
+-------+---------+--------+--------------+--------------+-------------+--------------+
| .     | CUDA    | pp 512 | 39.129±0.000 | 25.557±0.000 |           1 |    39.128773 |
+-------+---------+--------+--------------+--------------+-------------+--------------+

vs llama-cpp:
$ ./llama-bench -m ./model.gguf -r 1 -n 0 -p 512 -b 512

| model                          |       size |     params | backend    | ngl |    n_batch |          test |              t/s |
| ------------------------------ | ---------: | ---------: | ---------- | --: | ---------: | ------------: | ---------------: |
| llama 8B Q4_K - Medium         |   4.58 GiB |     8.03 B | CUDA       |  99 |        512 |         pp512 |   1248.13 ± 0.00 |
| llama 8B Q4_K - Medium         |   4.58 GiB |     8.03 B | CUDA       |  99 |        512 |   pp512+tg128 |    169.45 ± 0.00 |

# With matching GPU layers (default is 99):
$ ./llama-bench -m ./model.gguf -r 1 -n 0 -p 512 -b 512 --n-gpu-layers 24

| model                          |       size |     params | backend    | ngl |    n_batch |          test |              t/s |
| ------------------------------ | ---------: | ---------: | ---------- | --: | ---------: | ------------: | ---------------: |
| llama 8B Q4_K - Medium         |   4.58 GiB |     8.03 B | CUDA       |  24 |        512 |         pp512 |    940.59 ± 0.00 |
| llama 8B Q4_K - Medium         |   4.58 GiB |     8.03 B | CUDA       |  24 |        512 |   pp512+tg128 |     81.55 ± 0.00 |

mistral.rs was built in the same Dockerfile as llama-cpp provides, only the cuda feature was enabled when building mistral.rs as flash attention was failing for some reason and cudnn wasn't part of the image.
No idea why performance is so vastly different, although it gets somewhat closer with pp512+tg128 (I have no clue what that is or why it's significantly slower vs pp512).
Not sure if the bench settings are equivalent, I referenced this example which used the above to compare and I only added the explicit GPU layers since this model OOMs with mistral.rs otherwise.
UPDATE: I observed that during the bench mistral.rs after warmup had 0% GPU usage. The memory was allocated according to nvidia-smi but it wasn't putting the GPU to work like llama-cpp was 🤔

Additional failure for Hermes-2-Pro-Mistral-7B.Q4_K_M.gguf
In this case, the model encountered another failure, but I assume it's because of the unrelated tokenizer.json I added, or one of the files from the transformers/fp16 model? (I didn't encounter this when trying other GGUF models like llama 8B above):
INFO mistralrs_core::device_map: Using 32 layers on device and 0 on host.
thread 'main' panicked at mistralrs-core/src/pipeline/gguf.rs:458:41:
called `Result::unwrap()` on an `Err` value: Error("duplicate field `clean_up_tokenization_spaces`", line: 290, column: 32)
stack backtrace:
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::result::unwrap_failed
   3: <mistralrs_core::pipeline::gguf::GGUFLoader as mistralrs_core::pipeline::Loader>::load_model_from_path
   4: <mistralrs_core::pipeline::gguf::GGUFLoader as mistralrs_core::pipeline::Loader>::load_model_from_hf
   5: mistralrs_bench::main

Hi @polarathene!
Thank you for reporting this bug. I think that the UX part of device mapping isn't great currently, and hopefully #332 will improve that. Additionally, device mapping is not really optimized, and essentially consists of loading layers on different devices and then running them there. We copy the hidden states from device to host, which is probably the bottleneck as it requires a GPU-CPU synchronization.

mistral.rs was built in the same Dockerfile as llama-cpp provides, only the cuda feature was enabled when building mistral.rs as flash attention was failing for some reason and cudnn wasn't part of the image.

Can you please confirm that it prints it is loading on device and host (so we know it is loading on the GPU)? #332 should make that clearer.

Not sure if the bench settings are equivalent, I referenced https://github.com/EricLBuehler/mistral.rs/issues/153#issuecomment-2081251008 which used the above to compare and I only added the explicit GPU layers since this model OOMs with mistral.rs otherwise.

I think it should be. We don't have prompt chunking yet, and that's something I want to implement. The infrastructure is there, it was implemented by #242.

I observed that during the bench mistral.rs after warmup had 0% GPU usage. The memory was allocated according to nvidia-smi but it wasn't putting the GPU to work like llama-cpp was 🤔

I'm not sure why this is happening. If you use device mapping, it definitely uses the GPU for calculations, though. I'll take a look.

In this case, the model encountered another failure, but I assume it's because of the unrelated tokenizer.json I added, or one of the files from the transformers/fp16 model? (I didn't encounter this when trying other GGUF models like llama 8B above):

I checked the tokenizer_config.json file, and there is actually a mistake in there. It may be best to raise an issue with their repo, because they do indeed define it twice. In the meantime, if you download it locally, you can just remove one of them.

@polarathene , this should be fixed now.

Thanks, I'll give it a try within the next few days 👍

Can you please confirm that it prints it is loading on device and host (so we know it is loading on the GPU)? #332 should make that clearer.

I did share above this log line at the end of my last response:
INFO mistralrs_core::device_map: Using 32 layers on device and 0 on host.

This will need to wait until later, but I do know that my vRAM went up notably while the bench command was running, and as per the logs it had found the GPU just fine so that was all working. It just wasn't utilizing the GPU for the benching for some reason.

I'm not sure why this is happening. If you use device mapping, it definitely uses the GPU for calculations, though. I'll take a look.

It may have been something specific to the Docker or WSL2 environment, when I have the time I'll look into better reproducing and can verify with builds on WSL2 and the Windows 11 host to see if it still occurs in those environments too.

I checked the tokenizer_config.json file, and there is actually a mistake in there.

Oh ok, well if it hasn't already been tackled a more helpful error about that might be better UX? It wasn't clear that it was referring to a single file input.

If you don't need a response and consider this solved feel free to close, otherwise I'll do that later this week.

Oh ok, well if it hasn't already been tackled a more helpful error about that might be better UX? It wasn't clear that it was referring to a single file input.

Yes, this error can be improved. Generally, we should start to remove some of the .unwrap()s related to serialization.
I'll wait until you think it's good to close this issue.

@polarathene, does this overflow error still occur?

@polarathene, does this overflow error still occur?

The CLI still won't load files locally atm, I'd have to do a build again that bypasses the 401, but I think I'll confirm when the CLI works without that workaround, which is probably more meaningful 😅

@polarathene, does this overflow error still occur?

It fails when the given value exceeds the layers still, whereas it should just know it has enough and clip it to the amount needed? llama-cpp seems to take that approach I think.
$ /mist/target/release/mistralrs-bench -p 512 -g 0 -r 1 -c 1 --num-device-layers 40 gguf -m . -f Hermes-2-Pro-Mistral-7B.Q4_K_M.gguf

2024-05-31T00:27:10.222222Z  INFO mistralrs_core::pipeline::gguf: Model config:
general.architecture: llama
general.file_type: 15
general.name: jeffq
general.quantization_version: 2
llama.attention.head_count: 32
llama.attention.head_count_kv: 8
llama.attention.layer_norm_rms_epsilon: 0.00001
llama.block_count: 32
llama.context_length: 32768
llama.embedding_length: 4096
llama.feed_forward_length: 14336
llama.rope.dimension_count: 128
llama.rope.freq_base: 10000
2024-05-31T00:27:10.259228Z  INFO mistralrs_core::pipeline::gguf_tokenizer: GGUF tokenizer model is `llama`, kind: `unigram`, num tokens: 32032, num added tokens: 0, num merges: 0, num scores: 32032
Error: Expected the number of GPU (40) and host layers (0) to sum to the number of model hidden layers (32)
   0: candle_core::error::Error::bt
   1: mistralrs_core::device_map::DeviceMapMetadata::into_mapper
   2: mistralrs_core::models::quantized_llama::ModelWeights::from_gguf
   3: <mistralrs_core::pipeline::gguf::GGUFLoader as mistralrs_core::pipeline::Loader>::load_model_from_path
   4: <mistralrs_core::pipeline::gguf::GGUFLoader as mistralrs_core::pipeline::Loader>::load_model_from_hf
   5: mistralrs_bench::main
   6: std::sys_common::backtrace::__rust_begin_short_backtrace
   7: std::rt::lang_start::{{closure}}
   8: std::rt::lang_start_internal
   9: main
  10: <unknown>
  11: __libc_start_main
  12: _start

Stack backtrace:
   0: anyhow::error::<impl core::convert::From<E> for anyhow::Error>::from
   1: <mistralrs_core::pipeline::gguf::GGUFLoader as mistralrs_core::pipeline::Loader>::load_model_from_path
   2: <mistralrs_core::pipeline::gguf::GGUFLoader as mistralrs_core::pipeline::Loader>::load_model_from_hf
   3: mistralrs_bench::main
   4: std::sys_common::backtrace::__rust_begin_short_backtrace
   5: std::rt::lang_start::{{closure}}
   6: std::rt::lang_start_internal
   7: main
   8: <unknown>
   9: __libc_start_main
  10: _start

It also seems to complain about the tokenizer_config.json, followed by tokenizer.json unless I use ... gguf -t /models/Hermes-2-Pro-Mistral-7B.Q4_K_M/?
Is the bench utility not in sync with the server command for local GGUF loading with the tokenizer?
$ RUST_BACKTRACE=1 target/release/mistralrs-bench -p 512 -g 0 -r 1 -c 1 --num-device-layers 40 gguf -m . -f /models/Hermes-2-Pro-Mistral-7B.Q4_K_M/Hermes-2-Pro-Mistral-7B.Q4_K_M.gguf

thread 'main' panicked at mistralrs-core/src/pipeline/gguf.rs:282:58:
File "tokenizer_config.json" not found at model id "."
stack backtrace:
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
   2: <mistralrs_core::pipeline::gguf::GGUFLoader as mistralrs_core::pipeline::Loader>::load_model_from_hf
   3: mistralrs_bench::main

When providing exact layers it loads into vRAM, but then fails after hitting the earlier mentioned duplicate field for this model:
$ RUST_BACKTRACE=1 /mist/target/release/mistralrs-bench -p 512 -g 0 -r 1 -c 1 --num-device-layers 32 gguf -m . -f Hermes-2-Pro-Mistral-7B.Q4_K_M.gguf

2024-05-31T00:32:56.871358Z  INFO mistralrs_core::pipeline::gguf: Model config:
general.architecture: llama
general.file_type: 15
general.name: jeffq
general.quantization_version: 2
llama.attention.head_count: 32
llama.attention.head_count_kv: 8
llama.attention.layer_norm_rms_epsilon: 0.00001
llama.block_count: 32
llama.context_length: 32768
llama.embedding_length: 4096
llama.feed_forward_length: 14336
llama.rope.dimension_count: 128
llama.rope.freq_base: 10000
2024-05-31T00:32:56.909242Z  INFO mistralrs_core::pipeline::gguf_tokenizer: GGUF tokenizer model is `llama`, kind: `unigram`, num tokens: 32032, num added tokens: 0, num merges: 0, num scores: 32032
2024-05-31T00:32:57.056662Z  INFO mistralrs_core::device_map: Model has 32 repeating layers.
2024-05-31T00:32:57.056724Z  INFO mistralrs_core::device_map: Using 32 repeating layers on GPU and 0 repeating layers on host.
thread 'main' panicked at mistralrs-core/src/pipeline/mod.rs:1323:80:
called `Result::unwrap()` on an `Err` value: Error("duplicate field `clean_up_tokenization_spaces`", line: 290, column: 32)
stack backtrace:
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::result::unwrap_failed
   3: mistralrs_core::pipeline::get_chat_template
   4: <mistralrs_core::pipeline::gguf::GGUFLoader as mistralrs_core::pipeline::Loader>::load_model_from_path
   5: <mistralrs_core::pipeline::gguf::GGUFLoader as mistralrs_core::pipeline::Loader>::load_model_from_hf
   6: mistralrs_bench::main

After editing tokenizer_config.json to remove the 2nd occurence ("clean_up_tokenization_spaces": false,)  it'll run:
$ /mist/target/release/mistralrs-bench -p 512 -g 0 -r 1 -c 1 --num-device-layers 32 gguf -m . -f Hermes-2-Pro-Mistral-7B.Q4_K_M.gguf

2024-05-31T01:08:36.913971Z  INFO mistralrs_core::pipeline::gguf: Model config:
general.architecture: llama
general.file_type: 15
general.name: jeffq
general.quantization_version: 2
llama.attention.head_count: 32
llama.attention.head_count_kv: 8
llama.attention.layer_norm_rms_epsilon: 0.00001
llama.block_count: 32
llama.context_length: 32768
llama.embedding_length: 4096
llama.feed_forward_length: 14336
llama.rope.dimension_count: 128
llama.rope.freq_base: 10000
2024-05-31T01:08:36.942180Z  INFO mistralrs_core::pipeline::gguf_tokenizer: GGUF tokenizer model is `llama`, kind: `unigram`, num tokens: 32032, num added tokens: 0, num merges: 0, num scores: 32032
2024-05-31T01:08:37.062847Z  INFO mistralrs_core::device_map: Model has 32 repeating layers.
2024-05-31T01:08:37.062905Z  INFO mistralrs_core::device_map: Using 32 repeating layers on GPU and 0 repeating layers on host.
2024-05-31T01:08:38.552757Z  INFO mistralrs_core::pipeline::chat_template: bos_toks = "<s>", eos_toks = "<|im_end|>", "<|im_end|>", unk_tok = <unk>
2024-05-31T01:08:38.558662Z  INFO mistralrs_bench: Model loaded.
2024-05-31T01:08:38.575306Z  INFO mistralrs_core::cublaslt: Initialized cuBLASlt handle
2024-05-31T01:08:38.575453Z  INFO mistralrs_bench: Starting warmup run.
2024-05-31T01:08:38.876483Z  INFO mistralrs_bench: Finished warmup run.
2024-05-31T01:08:38.876528Z  INFO mistralrs_bench: Starting benchmarks.
+-------+---------+--------+----------------+-------------+-------------+--------------+
| model | backend | test   | t/s            | ms/t        | concurrency | throughput/s |
+-------+---------+--------+----------------+-------------+-------------+--------------+
| .     | CUDA    | pp 512 | 1064.449±0.000 | 0.939±0.000 |           1 |    1064.4491 |
+-------+---------+--------+----------------+-------------+-------------+--------------+

Result: 1064.44 (mistral-rs) vs 1248.13 (llama-cpp) token/sec 👍
The bench went quite quickly, I'm not quite sure how to compare it against a longer llama-cpp bench I did, but I think that's due to mistral.rs not being able to match some of these options:
llama-bench -m /tmp/model.gguf -r 1 -fa 0,1 -n 0 -pg 0,0 -p 4096 -b 64,128,256,512,1024,2048,4096

@polarathene I just merged #367 which clamps the number of device layers to the number of model layers. I think the functionality should work fully now?

I think the functionality should work fully now?

Yes, I can provide a higher number than needed and no failures now 👍

I did go down a rabbit hole thinking a regression was introduced due to performance being halved, but that seems to be a WSL2 quirk with weird memory management from when I tested models that my system couldn't handle 😓
NOTE: mistralrs-bench seems to still require the additional files for GGUF to load, unlike mistralrs-server?

I thought to try plain safetensors model, but this gave the 401 unauthorized, despite having other config files it tried to access HF for the local model name which was output.safetensors
I also noticed an issue with -m . that might need to be better documented (although technically shouldn't be relevant for local GGUF support, once this is addressed?):
A recent change introduced prevents using models from a read-only volume. mistral.rs will attempt to write a tokenizer.json file.

-m value needs to be absolute/relative path to the model location referenced in -f? (EDIT: Doesn't affect mistralrs-server, thus mistralrs-bench just needs the same local GGUF support):
$ target/release/mistralrs-bench -p 512 -g 0 -r 1 -c 1 --num-device-layers 40 gguf -m . -f /models/Hermes-2-Pro-Mistral-7B.Q4_K_M/Hermes-2-Pro-Mistral-7B.Q4_K_M.gguf

thread 'main' panicked at mistralrs-core/src/pipeline/gguf.rs:294:58:
File "tokenizer_config.json" not found at model id "."

# File does exist:
$ ls /models/Hermes-2-Pro-Mistral-7B.Q4_K_M/

Hermes-2-Pro-Mistral-7B.Q4_K_M.gguf  added_tokens.json  config.json  generation_config.json  special_tokens_map.json  tokenizer.model  tokenizer_config.json

Required:
# `-m` must point to directory of `-f`:
target/release/mistralrs-bench -p 512 -g 0 -r 1 -c 1 --num-device-layers 40 gguf -m /models/Hermes-2-Pro-Mistral-7B.Q4_K_M/ -f Hermes-2-Pro-Mistral-7B.Q4_K_M.gguf

# Unless you run the command from that location:
cd /models/Hermes-2-Pro-Mistral-7B.Q4_K_M
/app/target/release/mistralrs-bench -p 512 -g 0 -r 1 -c 1 --num-device-layers 40 gguf -m . -f /models/Hermes-2-Pro-Mistral-7B.Q4_K_M/Hermes-2-Pro-Mistral-7B.Q4_K_M.gguf

Probably the same for -t if not using the new GGUF support that permits omitting -t.

Collapsed - Resolved temporary regression
UPDATE: While writing this response, I've no idea what changed but bench performance is back in line with prior results.

I can only assume it's due to WSL2 and Windows memory management, since prior to running this bench I had the system under 99% memory load a few minutes earlier.
I've noticed WSL2 reading any file data will actually keep memory allocated for a while even though it's only the file cache/buffer, and Windows seems to additional write to disk a similar amount of data that isn't released until it's free within WSL2 (but it's released slowly). Thus probably the cause of the performance skew..

Original response follows.
Additionally I'm not sure why, but the performance of the bench is half of what I reported previously:
$ mistralrs-bench -f Hermes-2-Pro-Mistral-7B.Q4_K_M.gguf \
  -r 1 -c 1 -p 512 -g 0 gguf -m . -t .

+-------+---------+--------+-----------------+-------------+-------------+--------------+
| model | backend | test   | t/s             | ms/t        | concurrency | throughput/s |
+-------+---------+--------+-----------------+-------------+-------------+--------------+
| .     | CUDA    | pp 512 | 614.646±0.000   | 1.627±0.000 |           1 |     614.6458 |
+-------+---------+--------+-----------------+-------------+-------------+--------------+

$ llama-bench -m Hermes-2-Pro-Mistral-7B.Q4_K_M.gguf  \
  -r 1 -p 512 -n 0 -b 512 -pg 0,0 -fa 0,1

ggml_cuda_init: GGML_CUDA_FORCE_MMQ:   no
ggml_cuda_init: CUDA_USE_TENSOR_CORES: yes
ggml_cuda_init: found 1 CUDA devices:
  Device 0: NVIDIA GeForce RTX 4060 Laptop GPU, compute capability 8.9, VMM: yes
| model                          |       size |     params | backend    | ngl |    n_batch |         fa |          test |              t/s |
| ------------------------------ | ---------: | ---------: | ---------- | --: | ---------: | ---------: | ------------: | ---------------: |
| llama 7B Q4_K - Medium         |   4.07 GiB |     7.24 B | CUDA       |  99 |        512 |          0 |         pp512 |   1313.10 ± 0.00 |
| llama 7B Q4_K - Medium         |   4.07 GiB |     7.24 B | CUDA       |  99 |        512 |          1 |         pp512 |   1344.06 ± 0.00 |

For reference llama-bench options and defaults (in case any implicit config is relevant):
options:
  -h, --help
  -m, --model <filename>              (default: models/7B/ggml-model-q4_0.gguf)
  -p, --n-prompt <n>                  (default: 512)
  -n, --n-gen <n>                     (default: 128)
  -pg <pp,tg>                         (default: 512,128)
  -b, --batch-size <n>                (default: 2048)
  -ub, --ubatch-size <n>              (default: 512)
  -ctk, --cache-type-k <t>            (default: f16)
  -ctv, --cache-type-v <t>            (default: f16)
  -t, --threads <n>                   (default: 8)
  -ngl, --n-gpu-layers <n>            (default: 99)
  -sm, --split-mode <none|layer|row>  (default: layer)
  -mg, --main-gpu <i>                 (default: 0)
  -nkvo, --no-kv-offload <0|1>        (default: 0)
  -fa, --flash-attn <0|1>             (default: 0)
  -mmp, --mmap <0|1>                  (default: 1)
  --numa <distribute|isolate|numactl> (default: disabled)
  -embd, --embeddings <0|1>           (default: 0)
  -ts, --tensor-split <ts0/ts1/..>    (default: 0)
  -r, --repetitions <n>               (default: 5)
  -o, --output <csv|json|md|sql>      (default: md)
  -v, --verbose                       (default: 0)

vs current options for mistralrs-bench:
Options:
  -p, --n-prompt <N_PROMPT>
          Number of prompt tokens to run [default: 512]
  -g, --n-gen <N_GEN>
          Number of generations tokens to run [default: 128]
  -c, --concurrency <CONCURRENCY>
          Number of concurrent requests to run. Default is 1
  -r, --repetitions <REPETITIONS>
          Number of times to repeat each test [default: 5]
  -n, --num-device-layers <NUM_DEVICE_LAYERS>
          Number of device layers to load and run on the device. All others will be on the CPU

I tried to see if this was a regression by reverting back to an earlier commit, but prior to your commit for the GGUF tokenizer, I cannot load that Hermes model with tokenizer.json, or rather I had already discarded that and can't recall where I sourced a tokenizer.json that may have worked 🤷♂
Author of the model states they don't know how to create tokenizer.json

It can apparently be done with the HF python-based transformers lib, but there is no instructions/guidance as apparently it's not straight-forward?
Similar discussion that you were involved in for the HF rust-based tokenizers lib mentions converter support is only available via third-party python libs? But writing a CLI in rust should be straight-forward? 🤷♂

Command + Additional info
All commands output the same model config lines, so I'll omit that from the output examples:
INFO mistralrs_core::pipeline::gguf: Model config:
general.architecture: llama
general.file_type: 15
general.name: jeffq
general.quantization_version: 2
llama.attention.head_count: 32
llama.attention.head_count_kv: 8
llama.attention.layer_norm_rms_epsilon: 0.00001
llama.block_count: 32
llama.context_length: 32768
llama.embedding_length: 4096
llama.feed_forward_length: 14336
llama.rope.dimension_count: 128
llama.rope.freq_base: 10000

The command is the same for each with the exception of appending the -t . for a 2nd run. I use the absolute path to the command, and run the command from the model directory.
# Short version:
mistralrs-bench -n 32 -p 512 -g 0 -r 1 -c 1 gguf -m . -t . -f Hermes-2-Pro-Mistral-7B.Q4_K_M.gguf

# Options expanded for clarity:
/app/target/release/mistralrs-bench \
    --num-device-layers 32 \
    --n-prompt 512 \
    --n-gen 0 \
    --repetitions 1 \
    --concurrency 1 \
    gguf -f Hermes-2-Pro-Mistral-7B.Q4_K_M.gguf -m . -t .

Master branch (currently commit: Prepare to accept multiple model types)
Without -t:
INFO mistralrs_core::pipeline::gguf_tokenizer: GGUF tokenizer model is `llama`, kind: `unigram`, num tokens: 32032, num added tokens: 0, num merges: 0, num scores: 32032

INFO mistralrs_core::device_map: Model has 32 repeating layers.
INFO mistralrs_core::device_map: Using 32 repeating layers on GPU and 0 repeating layers on host.
INFO mistralrs_core::pipeline::paths: `tokenizer_config.json` does not contain a chat template, attempting to use specified JINJA chat template.
INFO mistralrs_core::pipeline::paths: No specified chat template. No chat template will be used. Only prompts will be accepted, not messages.
INFO mistralrs_core::pipeline::chat_template: bos_toks = "<s>", eos_toks = "<|im_end|>", "<|im_end|>", unk_tok = <unk>
INFO mistralrs_bench: Model loaded.
INFO mistralrs_core: GEMM reduced precision in BF16 not supported.
INFO mistralrs_core::cublaslt: Initialized cuBLASlt handle
INFO mistralrs_bench: Starting warmup run.
INFO mistralrs_bench: Finished warmup run.
INFO mistralrs_bench: Starting benchmarks.

With -t .:
INFO mistralrs_core::device_map: Model has 32 repeating layers.
INFO mistralrs_core::device_map: Using 32 repeating layers on GPU and 0 repeating layers on host.
INFO mistralrs_core::pipeline::paths: `tokenizer_config.json` does not contain a chat template, attempting to use specified JINJA chat template.
INFO mistralrs_core::pipeline::paths: No specified chat template. No chat template will be used. Only prompts will be accepted, not messages.
INFO mistralrs_core::pipeline::chat_template: bos_toks = "<s>", eos_toks = "<|im_end|>", "<|eot_id|>", unk_tok = <unk>

thread 'main' panicked at mistralrs-core/src/pipeline/chat_template.rs:157:36:
Unable to extract `<|im_end|>` EOS token.

Slight difference on log line eos_toks = "<|im_end|>", "<|eot_id|>", also missing initial log line before "Model has 32 repeating layers" which I assume came from the default GGUF tokenizer commit.
tokenizer_config.json does contain a chat template though.. (the same content as what you had suggested previously to provide as a separate file for mistralrs-server --chat-template):
$ grep chat_template tokenizer_config.json

  "chat_template": "{{bos_token}}{% for message in messages %}{{'<|im_start|>' + message['role'] + '\n' + message['content'] + '<|im_end|>' + '\n'}}{% endfor %}{% if add_generation_prompt %}{{ '<|im_start|>assistant\n' }}{% endif %}",

Before commit Allow default unigram unk token for GGUF
Built with commit Fix unauth check (#362).
Without -t:
thread 'main' panicked at mistralrs-core/src/pipeline/gguf_tokenizer.rs:65:31:
no entry found for key

stack backtrace:
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::panicking::panic_display
   3: core::option::expect_failed
   4: <mistralrs_core::pipeline::gguf::GGUFLoader as mistralrs_core::pipeline::Loader>::load_model_from_path
   5: <mistralrs_core::pipeline::gguf::GGUFLoader as mistralrs_core::pipeline::Loader>::load_model_from_hf
   6: mistralrs_bench::main

With -t .:
INFO mistralrs_core::device_map: Model has 32 repeating layers.
INFO mistralrs_core::device_map: Using 32 repeating layers on GPU and 0 repeating layers on host.
INFO mistralrs_core::pipeline::chat_template: bos_toks = "<s>", eos_toks = "<|im_end|>", "<|eot_id|>", unk_tok = <unk>

thread 'main' panicked at mistralrs-core/src/pipeline/chat_template.rs:155:36:
Unable to extract `<|im_end|>` EOS token.

Same failure as master branch, but no log about chat_template raised.
Side-note - Not compatible with read-only locations
I also noticed it does not like running from my docker read-only volume I used to access my models, as it apparently wants to try write something...? (EDIT: Detailed below)
For these reproductions, I thus made a copy of the model within the container since I can't opt-out of the enforced write operation.
# This is from master branch

thread 'main' panicked at mistralrs-core/src/utils/tokenizer.rs:40:47:
called `Result::unwrap()` on an `Err` value: Os { code: 30, kind: ReadOnlyFilesystem, message: "Read-only file system" }
stack backtrace:
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::result::unwrap_failed
   3: mistralrs_core::utils::tokenizer::get_tokenizer
   4: <mistralrs_core::pipeline::gguf::GGUFLoader as mistralrs_core::pipeline::Loader>::load_model_from_path
   5: <mistralrs_core::pipeline::gguf::GGUFLoader as mistralrs_core::pipeline::Loader>::load_model_from_hf
   6: mistralrs_bench::main

Figured out the why (`added_tokens[].content` as a vocab mapping to it's associated `id`)
https://github.com/EricLBuehler/mistral.rs/blob/24b33b17e3e56aed0934f1d54c1bd29ccb853e57/mistralrs-core/src/utils/tokenizer.rs#L39-L40
https://github.com/EricLBuehler/mistral.rs/blob/24b33b17e3e56aed0934f1d54c1bd29ccb853e57/mistralrs-core/src/utils/tokenizer.rs#L19-L20
Seems to be applied unconditionally to satisfy a potential problem: https://github.com/huggingface/tokenizers/issues/1528
Should probably be a CLI option, or even a subcommand to fix a local config if necessary?

I see that it's not run again if the file exists already (not sure how compatible that is when a model updates though?).
The filename is not handled properly, .json should be the extension, but presently it's tokenizer.json_mistralrs_fixed when it should instead be more like tokenizer.patched_by_mistralrs.json, or tokenizer.json_mistralrs_fixed.json (if you must keep the tokenizer.json prefix).

head -n 30 tokenizer.json:
{
  "version": "1.0",
  "truncation": null,
  "padding": null,
  "added_tokens": [
    {
      "id": 0,
      "content": "<unk>",
      "single_word": false,
      "lstrip": false,
      "rstrip": false,
      "normalized": false,
      "special": true
    },
    {
      "id": 1,
      "content": "<s>",
      "single_word": false,
      "lstrip": false,
      "rstrip": false,
      "normalized": false,
      "special": true
    },
    {
      "id": 2,
      "content": "</s>",
      "single_word": false,
      "lstrip": false,
      "rstrip": false,
      "normalized": false,

head -n 30 tokenizer.json_mistralrs_fixed:
{
  "added_tokens": [
    {
      "content": "<|begin_of_text|>",
      "id": 128000,
      "lstrip": false,
      "normalized": false,
      "rstrip": false,
      "single_word": false,
      "special": true
    },
    {
      "content": "<|end_of_text|>",
      "id": 128001,
      "lstrip": false,
      "normalized": false,
      "rstrip": false,
      "single_word": false,
      "special": true
    },
    {
      "content": "<|reserved_special_token_0|>",
      "id": 128002,
      "lstrip": false,
      "normalized": false,
      "rstrip": false,
      "single_word": false,
      "special": true
    },
    {

$ wc -l tokenizer.json tokenizer.json_mistralrs_fixed
   91121 tokenizer.json
  410759 tokenizer.json_mistralrs_fixed

$ jq '.added_tokens[].id' tokenizer.json
0
1
2

# Original ID not present:
$ jq '.added_tokens[].id' tokenizer.json_mistralrs_fixed
128000
128001
# ...
128255

# ID of the token with content '<unk>':
$ jq '.added_tokens[] | select(.content == "<unk>") | .id' tokenizer.json
0
# References:
$ grep '<unk>' tokenizer.json
      "content": "<unk>",
    "unk_token": "<unk>",
      "<unk>": 0,

# Token doesn't exist anymore (neither produce output):
$ jq '.added_tokens[] | select(.content == "<unk>") | .id' tokenizer.json_mistralrs_fixed
$ grep '<unk>' tokenizer.json_mistralrs_fixed

So I'm not quite sure what this file with similar name is doing, is it intended to remove data that was there?
I tried a tokenizer.json from a llama 3 based model with an older commit before the logic above was implemented, even though it was not compatible with the Hermes model and resulted in the same failure, it did output the warning log lines:
WARN tokenizers::tokenizer::serialization: Warning: Token '<|begin_of_text|>' was expected to have ID '128000' but was given ID 'None'
WARN tokenizers::tokenizer::serialization: Warning: Token '<|end_of_text|>' was expected to have ID '128001' but was given ID 'None'
WARN tokenizers::tokenizer::serialization: Warning: Token '<|reserved_special_token_0|>' was expected to have ID '128002' but was given ID 'None'
WARN tokenizers::tokenizer::serialization: Warning: Token '<|reserved_special_token_1|>' was expected to have ID '128003' but was given ID 'None'
WARN tokenizers::tokenizer::serialization: Warning: Token '<|reserved_special_token_2|>' was expected to have ID '128004' but was given ID 'None'
WARN tokenizers::tokenizer::serialization: Warning: Token '<|reserved_special_token_3|>' was expected to have ID '128005' but was given ID 'None'
WARN tokenizers::tokenizer::serialization: Warning: Token '<|start_header_id|>' was expected to have ID '128006' but was given ID 'None'
WARN tokenizers::tokenizer::serialization: Warning: Token '<|end_header_id|>' was expected to have ID '128007' but was given ID 'None'
WARN tokenizers::tokenizer::serialization: Warning: Token '<|reserved_special_token_4|>' was expected to have ID '128008' but was given ID 'None'
WARN tokenizers::tokenizer::serialization: Warning: Token '<|eot_id|>' was expected to have ID '128009' but was given ID 'None'

Which makes sense for the error now I guess 😅 The tokenizer.json files I've been randomly trying from HF had the other mentioned tokens (bos_tokens / unk_token) but since im_end wasn't present the failure shouldn't be a surprise 😑
# No output
$ grep 'im_end' tokenizer.json

So on the tokenizer.json that was emitting those errors we can lookup that entry for the last warning of <|eot_id|>, the id field is what was expected, not sure why the warning says it got None 🤔
$ jq '.added_tokens[] | select(.content == "<|eot_id|>") | .' tokenizer.json
{
  "id": 128009,
  "content": "<|eot_id|>",
  "single_word": false,
  "lstrip": false,
  "rstrip": false,
  "normalized": false,
  "special": true
}

EDIT: I should have read the utils/tokenizer.rs code, mapping of vocab keys as added_tokens[].content to their respective id was missing:
https://github.com/EricLBuehler/mistral.rs/blob/24b33b17e3e56aed0934f1d54c1bd29ccb853e57/mistralrs-core/src/utils/tokenizer.rs#L29-L38

I still don't think it should be needing to enforce the write as a way to cache though?
The token in this case perhaps due to different layout with tokenizer.model instead of tokenizer.json had the required tokens defined in a separate added_tokens.json file. Presumably when constructing a tokenizer.json it'd get the tokens from that?
{
  "<|im_end|>": 32000,
  "<|im_start|>": 32001,
  // ...
}

Git history on master branch
I went back a bit further to when I would get the 401 unauth issue, and applied my single line opt-out workaround I shared at the end of this comment.
At this point I realized that I was selecting a commit that wasn't technically part of the master branch, it was interleaved with commits from other branches that were merged into master. So navigating the branch history via Github's web UI to select commits isn't that helpful 😓
So the main branch history has stuff like this (commits that are noisy in history, rather than meaningful):

EDIT: Seems like you've recently switched to using squash merge since #362 😎
Anyway, I went further back before gguf_tokenizer.rs was introduced and still had issues with tokenizer.json, so I must have found a some-what compatible one somewhere on HF previously, but I can't recall where I got it from 🤦♂

@polarathene sorry that it doesn't work out of the box yet! I responded to some of your comments:

I thought to try plain safetensors model, but this gave the 401 unauthorized, despite having other config files it tried to access HF for the local model name which was output.safetensors

Perhaps your HF token is not set? If it is set, though, this is strange and I cannot reproduce this.

NOTE: mistralrs-bench seems to still require the additional files for GGUF to load, unlike mistralrs-server?

No, it uses the same internal API. As documented here, you should provide a chat template with --chat-template (I'll try to improve those docs...). There was a bug though which I fixed which affected the chat templates, maybe you ran the commands while the bug was still active?

I also noticed an issue with -m . that might need to be better documented (although technically shouldn't be relevant for local GGUF support, once this is addressed?):

Hmm, can you please open an issue for that? -m should be a relative or absolute path.

A recent change introduced prevents using models from a read-only volume. mistral.rs will attempt to write a tokenizer.json file.

Ah, ok. I'll fix that.

Even when using -t . for local tokenizer_config.json, if a chat_template is defined this is no longer detected and logged that one doesn't exist (at least when run via mistralrs-bench).

That was indeed a bug and should be fixed now.

Perhaps your HF token is not set? If it is set, though, this is strange and I cannot reproduce this.

I did not have an HF account at the time. I'm still new to this domain so I'd only been trying popular models that didn't require an account to login.
I'm not sure why an HF token would be required when the HF repo for a model is publicly accessible? You can git clone without such a token so it seems a little odd to encounter a 401.
Personally that's not a great UX, if no token is present but one is required for the API, yet I have the files locally why is HF required? I don't know if I'd ever train my own model as a learning experience, but it gives the impression that I'd have to redundantly upload to HF (or make a GGUF). I don't know the correct term, that hermes one is apparently based of mistral, but that sort of thing I guess where using the existing support for model architectures in mistral.rs.

you should provide a chat template with --chat-template

The tokenizer_config.json had a chat template? I've since discarded the container, but shared output in the collapsed details block. Something changed over the past week or so on master branch where it states it cannot find the chat template.

There was a bug though which I fixed which affected the chat templates, maybe you ran the commands while the bug was still active?

Possibly.

Even when using -t . for local tokenizer_config.json, if a chat_template is defined this is no longer detected and logged that one doesn't exist (at least when run via mistralrs-bench).

That was indeed a bug and should be fixed now.

🎉 (I have not had time to verify this yet, but great news!)

Hmm, can you please open an issue for that? -m should be a relative or absolute path.

?
-m value as relative/absolute path was the observation. I had provided -f to a GGUF as an absolute path and thought that -m . was just a workaround / opt-out.
It only seemed relevant for mistralrs-bench to be able to find tokenizer_config.json, but didn't seem necessary for mistralrs-server (presumably because of the local GGUF support? 🤷♂ )

NOTE: mistralrs-bench seems to still require the additional files for GGUF to load, unlike mistralrs-server?
No, it uses the same internal API.

I'll need to run a new build again to verify I guess 😅
If I need more than the GGUF file itself, is there a public HF repo you can refer me to for those files to go with the GGUF? Or do I need to create an HF account just to get access to such content for GGUF? (which AFAIK the local GGUF support is meant to remove the dependency on supplementary files)

Hi @polarathene! Since the bug here is fixed, I'll close this issue. Please feel free to reopen though!

I'm not sure why an HF token would be required when the HF repo for a model is publicly accessible? You can git clone without such a token so it seems a little odd to encounter a 401.

We have made a few changes in that area of the code since, and that behavior is handled now.

I don't know the correct term, that hermes one is apparently based of mistral, but that sort of thing I guess where using the existing support for model architectures in mistral.rs.

We typically use the term "fine tuning" to describe creating a new, better model based on an, aptly named, base model :).

If I need more than the GGUF file itself, is there a public HF repo you can refer me to for those files to go with the GGUF? Or do I need to create an HF account just to get access to such content for GGUF? (which AFAIK the local GGUF support is meant to remove the dependency on supplementary files)

To use HF Hub you need to create an account, I think. We have had fully local GGUF support for a bit now, though.


OpenCL 1.2 causes low performance in GTX970

On GTX970 using CUDA isn't working, have to use openCL.
Most people suggest to run 347.88, for some reason I couldn't run it daily. After some grinding I found that when using the old driver it uses OpenCL 1.1, while new driver using OpenCL 1.2, the results (mh/s) for 1.1 is like 19, 20, 19, 20 and for 1.2 is like 0, 4, 5, 0, 0, 4, 5. I wonder is there anyway to force it to run as OpenCL 1.1 without downgrading drivers? Thanks for your awesome work!

Have you found a solution yet?

No relation with OpenCL version, a thread on reddit says need to enable Optimize for Compute Performance in nvidia settings (latest drivers).


Increase Minimum Supported Java Version To 11

Java 8 was released a long time ago in 2014. Java 17 is approaching soon #675. Once Java 17 is available, there will be three LTS versions Java 8, 11 and 17. SecHub want's to support two Java LTS versions at any time.

Interested help me to do this

Interested help me to do this

This is a decision, rather than an issue to actively work on.
To understand the context. Currently, we still write code which is compatible with Java 8. There are some nice improvements which were introduced in Java 11 and 17. For example, multi-line strings. Currently, we cannot make use of those nice improvements.
The future plan is to set the minimum Java version to Java 11. However, SpringBoot decided to go beyond Java 11 and increase the minimum supported version for SpringBoot 3 (+Spring Framework 6) to Java 17. We probably adopt Java 17 as minimal version the moment we switch to SpringBoot 3. SecHub and the community has to decide when and how we want to switch to SpringBoot 3.
Before SpringBoot 3 we have to implement a couple of changes:

Test running and building SecHub with Java 17 (see: #675)
Upgrade to SpringBoot 2.6 (see: #691)
Upgrade to Gradle 7.0 (see: #495)
Upgrade to SpringBoot 2.7 (see: #915)


[BI-1283] Improve Left Hand Menu

Description
Story: BI-1283 - Improve Left Hand Menu

Removed submenus
Switched menu order to move admin menu below program menu
Removed unused TraitFavorites.vue

Dependencies
taf/BI-1283
bi-api/develop
Testing
Log in as admin and select system administration

Only system admin menus visible
Select program, program menus appear above admin menu
Log in as admin and select program
Program menus visible and listed before admin menu in order specified by card
Submenus not visible
Log in as non-admin
Admin menu not visible
Program menus visible in order specified by card
Submenus not visible

Test pages can be navigated to by menu and tab
Checklist:

[X] I have performed a self-review of my own code
[X] I have tested my code and ensured it meets the acceptance criteria of the story
[X] I have create/modified unit tests to cover this change
[X] I have commented my code, particularly in hard-to-understand areas
[X] I have made corresponding changes to documentation
[ ] I have run TAF: <link to TAF run>

happy-path test passed


Error messages are being printed twice

❯ crc start -b ~/Downloads/crc_archives/crc_hyperkit_4.1.3.tar.xz
ERRO Error occurred: crc_hyperkit_4.1.3.tar.xz bundle is not supported for this release use updated one (crc_<hypervisor>_4.1.6.crcbundle)
ERRO Error occurred: crc_hyperkit_4.1.3.tar.xz bundle is not supported for this release use updated one (crc_<hypervisor>_4.1.6.crcbundle)

Fixed in #353


Add dynamic table name support

This commit adds a new "dyntablename" metadata tag in the model scope that
causes gorma to generate an extra tableName parameter in function signatures.

Oops.  Merge conflicts with latest master.  Let me clean that up and rebase...

Rebased and ready to merge.


can't load weight from hdf5 using mxnet as backend

Description
Train the u-net keras model using mxnet as backend. Everything works fine during the training and model, weights are saved successfully.
But when I try to load weights from hdf5, it returns the traceback.
Environment info (Required)
win10, python3.6, pip version 9.0.1,
keras-2.1.1, mxnet-cu80-0.12.1b20171201, keras-mxnet-1.2.2

Error Message:
Traceback (most recent call last):
  File "D:/fbl/unet/sc_road.py", line 198, in <module>
    model.load_weights('weights/w_debug.hdf5')
  File "C:\Users\123\Anaconda3\lib\site-packages\keras\engine\topology.py", line 2720, in load_weights
    self.load_weights_from_hdf5_group(f)
  File "C:\Users\123\Anaconda3\lib\site-packages\keras\engine\topology.py", line 2806, in load_weights_from_hdf5_group
    K.batch_set_value(weight_value_tuples)
  File "C:\Users\123\Anaconda3\lib\site-packages\keras\backend\mxnet_backend.py", line 2207, in batch_set_value
    set_value(p, w)
  File "C:\Users\123\Anaconda3\lib\site-packages\keras\backend\mxnet_backend.py", line 2195, in set_value
    x.bind(mx.nd.array(value))
  File "C:\Users\123\Anaconda3\lib\site-packages\mxnet\ndarray\utils.py", line 146, in array
    return _array(source_array, ctx=ctx, dtype=dtype)
  File "C:\Users\123\Anaconda3\lib\site-packages\mxnet\ndarray\ndarray.py", line 2245, in array
    arr[:] = source_array
  File "C:\Users\123\Anaconda3\lib\site-packages\mxnet\ndarray\ndarray.py", line 437, in __setitem__
    self._set_nd_basic_indexing(key, value)
  File "C:\Users\123\Anaconda3\lib\site-packages\mxnet\ndarray\ndarray.py", line 698, in _set_nd_basic_indexing
    self._sync_copyfrom(value)
  File "C:\Users\123\Anaconda3\lib\site-packages\mxnet\ndarray\ndarray.py", line 859, in _sync_copyfrom
    str(self.shape), str(source_array.shape)))
ValueError: Shape inconsistent: expected () vs got (1,)

Minimum reproducible example
At the last layer of the model
conv10 = Convolution2D(N_CLS, 1, 1, activation='sigmoid')(conv9)

where N_CLS=1, so the shape of bias=(1,).
I use this code to save model and weights during traing:
model_checkpoint = ModelCheckpoint('weights/sc_road.hdf5', monitor='loss', save_best_only=True,
                                       save_weights_only=False)

And also try model.save_weights('weights/w_debug.hdf5') to save model, model.load_weights('weights/w_debug.hdf5') or model = load_model('weights/w_debug.hdf5') to load weights from the hdf5 file, but error is the same.
What have you tried to solve it?

I debuged and found the value of bias at the last layer is -0.15, but the shape in hdf5 is () (which is not correct), so the error occurs.
I found the same issue on stackoverflow but it seems unsolved.
https://stackoverflow.com/questions/46698701/keras-fails-to-load-model-weights-when-using-mxnet-backend

@R1ncy - This issue is fixed in this PR for Keras2 with MXNet backend - https://github.com/deep-learning-tools/keras/pull/36

wow thank you. I will try it again


How to pass flag and how to ingore lint

Hi Guys
Thanks for the great works, I have two questions

for some checks, e.g. ST1003, it allow pass custom flags, https://staticcheck.io/docs/configuration/options/#initialisms, I tried:

  "ST1003": {
    "analyzer_flags": {
      "initialisms": "GCS"
    }
  }

but it reports:
compilepkg: nogo: error running analyzers: ST1003: unrecognized flag: initialisms
``
2. there are some situation the lint give false positive and I would need to ignore it, follow this https://staticcheck.io/docs/configuration/#line-based-linter-directives wouldn't work, could please advise?

It's unclear to me how staticcheck set this config. Unless it's passed via Analyzer.Flags, it would not work nicely with nogo. In such case, some additional manual wiring is required. 🤔


Dockerize Anserini for replicating a particular experiment

Thread for discussion - if we wanted to dockerize Anserini in order to make a particular experiment replicable [1], how would we do it? A number of questions -

In the docker file, would we git clone the repo and mvn build? Or would we just curl a jar from Maven central? (Maven builds can be non-deterministic, so I'm thinking the latter?)
If we do the latter, our regression scripts aren't placed in Maven central... so we would still need to fetch them from the git repo?
Our regression scripts are currently hard coded to either tuna or damiano... so we'd need to generalize it?

Ideally, the replication should be as follows:

start docker image
copy in collection
trigger command in docker image to do evaluation (e.g., build index, do retrieval run).
examine eval results

[1] replicability, in the ACM sense - https://www.acm.org/publications/policies/artifact-review-badging

Closing this issue. We've already figured this out in the context of the The Open-Source IR Replicability Challenge (OSIRRC 2019).
Anserini docker image here: https://github.com/osirrc2019/anserini-docker


compatible with java11+

// Describe your PR here; eg. Fixes #issueNo

Make sure that:

[ ] You have read the contribution guidelines.
[ ] You submit test cases (unit or integration tests) that back your changes.
[ ] Your local test passed mvn clean install -Dmaven.javadoc.skip=true.

Codecov Report

Merging #1870 (90642a6) into master (17ea79c) will decrease coverage by 0.40%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master    #1870      +/-   ##
============================================
- Coverage     67.83%   67.42%   -0.41%
+ Complexity     2646     2634      -12
============================================
  Files           489      489
  Lines         10973    10973
  Branches       1076     1076
============================================
- Hits           7443     7399      -44
- Misses         2967     3012      +45
+ Partials        563      562       -1

Impacted Files
Coverage Δ

...enyu/client/tars/TarsServiceBeanPostProcessor.java
25.67% <0.00%> (-33.79%)
:arrow_down:

...ache/shenyu/plugin/grpc/cache/GrpcClientCache.java
66.66% <0.00%> (-27.78%)
:arrow_down:

...henyu/plugin/grpc/resolver/ShenyuNameResolver.java
56.84% <0.00%> (-6.32%)
:arrow_down:

...che/shenyu/sync/data/http/HttpSyncDataService.java
69.90% <0.00%> (-4.86%)
:arrow_down:

...henyu/plugin/httpclient/NettyHttpClientPlugin.java
57.14% <0.00%> (-2.05%)
:arrow_down:

...t/zookeeper/ZookeeperClientRegisterRepository.java
70.90% <0.00%> (-1.82%)
:arrow_down:

...elimiter/handler/RateLimiterPluginDataHandler.java
69.69% <0.00%> (-1.52%)
:arrow_down:

Continue to review full report at Codecov.

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


Userspace errno

Request for Comments
Background
The user errno value is currently kept in the TCB and can be accesses via an OS system call called __errno().
# define errno *__errno()

The errno valud is kept in the thread's TCB in the pterrno field.  The __errno() function finds the TCB associated with the thread and returns a pointer to the errno storage location.
This works in the FLAT build mode in because it dereferences the address of the errno in TCB as both an RVALUE:
 errcode == errno;

And as an LVALUE:
  errno = errode;

That works, however, it is rather inefficient.
However, that will not work at all in the PROTECTED or KERNEL build modes because the memory holding the TCB is protected and cannot be directly accessed from the user mode application.  Instead, it is accessed through accessor functions:
void set_errno(int errcode);
int  get_errno(void);

Accessing the errno via these functions in PROTECTED or KERNEL mode is a huge performance hit, because the calls must go system call which is implemented as a software interrupt.
And in this case, the errno is defined to be:
# define errno get_errno()

This works fine as an RVALUE:
 errcode == errno;

But will cause a compilation error if used as an LVALUE:
  errno = errode;

Instead user code must explicitly call set_errno(errcode).  This a a violation of the accepted usage of the POSIX errno variable.
TLS
The proposed solution is to move the errno storage location out of the proctected TCB memory and into the unprotected application thread stack memory.  Then it can be access with the appropriate TLS (Thread Local Storage) interfaces.
NOTE:  The errno value must still be retained in the TCB because it is also used for other purpose, such as informing sem_wait() that it was awakened by a a signal.
What has been done?
Historically, TLS works by aligning the stack base address then simplying AND'ing the current stack pointer to obtain the base address of the stack where the TLS data can be found (as struct tls_info_s).  This works well in the KERNEL build mode where is the resides at highly aligned virtual address, but does not work well in FLAT and PROTECTED modes:

The alignment must be large.  That is because it also determine the maximum size of the thread's stack.  If the size of the thread's stack exceeds that maximum value then the AND operation will result in the wrong address.
If all of the addresses are highly aligned then (1) you need to have much more memory available for stack allocation.  This is because (2) the large alignment cause bad memory fragmentation and degraded use of memory.

An alternative way to get the stack base address address is to call into the OS to get the unaligned stack base address.  This involves a system call, but is more usable that other alernatives in the FLAT and PROTECTED modes.
We have implemented a new configuration:  CONFIG_TLS_ALIGNED that selects the legacy aligned stack for TLS access.  If this is not defined, then the new unaligned stack TLS logic is used.  We have also implemented aligned and unaligned TLS support for every architecture.
What else do we have to do?
The next steps are:

Move the errno storage location out of the TCB and in TLS (into the struct tls_info_s).
Modify the errno access definitions and logic in sched/errno to use the TLS logic in user space.  This probably belongs in libs/libc/tls or perhaps libs/libc/errno.
Enable TLS be default.
Remove the errno-related system calls.

pthread-specific data
pthread-specific data is another mechanism for accessing thread-specific data.  It consists of these POSIX standard interfaces:
int pthread_key_create(FAR pthread_key_t *key,
                       CODE void (*destructor)(FAR void *));
int pthread_setspecific(pthread_key_t key, FAR const void *value);
FAR void *pthread_getspecific(pthread_key_t key);
int pthread_key_delete(pthread_key_t key);

This is a natural extension of the TLS logic would be natural to move into the TLS data as well.  This would amount to:

Moving the pthread-specific storage out of the TCB and into the TLS data.
Moving the pthread-specific data accessors out of sched/pthread and into libs/libc/pthread
Remove the pthread-specific data system calls.

TLS interfaces
TLS is a non-standard, but more general interface.  It differs from pthread-specific data only in that is semantics are general; the semantics of the pthread-specific data interfaces are focused on pthreads.  But they really should shared the same common underly logic.
Currently, there are two TLS interfaces:
uintptr_t tls_get_element(int elem);
void tls_set_element(int elem, uintptr_t value);

I propose that we extend these TLS interfaces so that they can coexit with the pthread interfaces.  Linux (actual GDB) does not provide a good mechanism; it relies on a storage class that is specific to ELF binaries.  That is not useful in an embedded system.
Instead, I think we should adapt from the Windows TLS interfaces which are directly anlagous to the POSIC pthread-specific data interfaces.  Here is such an adaption (following NuttX coding standards.  See https://en.wikipedia.org/wiki/Thread-local_storage#Windows_implementation):
int tls_alloc(void);
FAR void *tls_get_value(int tlsindex);
bool tls_set_value(int tlsindex, uinptr_t tlsvalue);
bool tls_free(int tlsindex);

The Windows prototypes can be found from links on this page: https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-tlsalloc
Accessing the errno from kernel space.
We should never access the errno from kernel space.  This is especially dangerous from kernel space because we can't be certain which user address environment is in effect or which stack is being used (if we were to use separate kernel mode stacks in the future as Linux does ... for security reasons).
Most OS interfaces have to parts:

A user callable function, say osapi() that sets the errno value is necessary (and may implement cancellation points) and
An internal OS version which might then be nx_osapi() which does not modify the errno value.

Ideally, all of the user callable OS interfaces (the osapi()) should be moved to the location in libs/libc the system call (sycall/) should be redirected to nx_osapi().  A complication to doing this is that the OS interfaces which are also cancellation points call special internal interfaces, enter_cancellation_point() and leave_cancellation_point() that are not available from user space.  So some addition partitioning would be need to accomplish this.
Code References
Things to look at:
include/errno.h        - Defines current errno access
include/nuttx/tls.h    - Defines the tls_info_s structure
include/nuttx/sched.h  - The errno and pthread-specific data
sched/errno/*          - The old errno access logic.  Move to libs/libc/errno or tls
libs/libc/tls          - The new TLS and possible errno access logic
sched/pthread          -  pthread_key*.c, pthread_*specific.c - Move to libs/libc/pthread

Linux (actual GDB) does not provide a good mechanism; it relies on a storage class that is specific to ELF binaries. That is not useful in an embedded system.

This thing did bite me when I was trying to get Linux ELF running on Nuttx.
That's a horrible implementation, relaying perfect cooperation of the toolchain and kernel, IMHO.

Linux (actual GDB) does not provide a good mechanism; it relies on a storage class that is specific to ELF binaries. That is not useful in an embedded system.

This thing did bite me when I was trying to get Linux ELF running on Nuttx.
That's a horrible implementation, relaying perfect cooperation of the toolchain and kernel, IMHO.

It is an easy trap to fall into in doing system software to exploit the tool environment that you work in as part of the implementation of the software.  That is usually disastrous because it ties the implementation to the tools and that tool environment.
This is one of the reasons that in NuttX we forbid any tool-specific dependencies in the common OS code.

TLS interfaces
TLS is a non-standard, but more general interface. It differs from pthread-specific data only in that is semantics are general; the semantics of the pthread-specific data interfaces are focused on pthreads. But they really should shared the same common underly logic.

But we already use pthread API across the code base which is only portable C API we can use for the  thread creation. The tls_* exist just because we can't move phread TLS storage to the start of the stack because the old implmentation require the very huge stack alignment which isn't suitable for FLAT/PROTECTED build. Since we remove the alignment requirement from the new TLS implmentation, we can move all per thread data(include errno and pthread TLS) into the stack. I prefer that pthread TLS API is implemented directly on top of sched_get_stackinfo and remove all private tls_* API.

Currently, there are two TLS interfaces:
uintptr_t tls_get_element(int elem);
void tls_set_element(int elem, uintptr_t value);

I propose that we extend these TLS interfaces so that they can coexit with the pthread interfaces. Linux (actual GLIBC) does not provide a good mechanism; it relies on a storage class that is specific to ELF binaries. That is not useful in an embedded system where no ELF information is present.
[This is a case of the bad decision to let specific tools environment drive a design. Good designs should be independent of tools].
Instead, I think we should adapt from the Windows TLS interfaces which are directly anlagous to the POSIC pthread-specific data interfaces. Here is such an adaption (following NuttX coding standards. See https://en.wikipedia.org/wiki/Thread-local_storage#Windows_implementation):
int tls_alloc(void);
FAR void *tls_get_value(int tlsindex);
bool tls_set_value(int tlsindex, uinptr_t tlsvalue);
bool tls_free(int tlsindex);

The Windows prototypes can be found from links on this page: https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-tlsalloc

Why we can't directly use pthread TLS API here? I don't see there is any benefit to define a new set of interface and forward pthread API to them, which just:
1.Increase the code size
2.Increase the document effort
3.Make people confusion which API he/she should use
4.The mix usage will spread in the code base and inroduce the inconsistence

Accessing the errno from kernel space.
We should never access the errno from kernel space. This is especially dangerous from kernel space because we can't be certain which user address environment is in effect or which stack is being used (if we were to use separate kernel mode stacks in the future as Linux does ... for security reasons).
Most OS interfaces have two parts:

A user callable function, say osapi() that sets the errno value is necessary (and may implement cancellation points) and
An internal OS version which might then be nx_osapi() which does not modify the errno value.

This design isn't perfect, most people don't understand the difference between osapi and nx_osapi. Even he/she know the difference but often forget in coding. I have fixed more than thousound of this type of bug(e.g. driver call osapi) and find that the same issue appear in the new code.

Ideally, all of the user callable OS interfaces (the osapi()) should be moved to the location in libs/libc the system call (sycall/) should be redirected to nx_osapi(). A complication to doing this is that the OS interfaces which are also cancellation points call special internal interfaces, enter_cancellation_point() and leave_cancellation_point() that are not available from user space. So some addition partitioning would be need to accomplish this.

Ideally, we just need to:
1.Implement osapi which return error code instead modifing errno
Then the difference can be done by the tool automatically:
2.STUB_xxx can add cancel point for us
3.The PROXY_xxx can modify errno for us
For FLAT build, since we don't separate userspace and kernel space, some hack need to be taken:
1.Redefine osapi to nx_osapi when KERNEL is defined
2.Rename osapi to nx_osapi by toolchain like simulator
Maybe we can find better method after more dissussing. But at least we definitely can find a way to do this thing automatically.

Code References
Things to look at:
include/errno.h        - Defines current errno access
include/nuttx/tls.h    - Defines the tls_info_s structure
include/nuttx/sched.h  - The errno and pthread-specific data
sched/errno/*          - The old errno access logic.  Move to libs/libc/errno or tls
libs/libc/tls          - The new TLS and possible errno access logic
sched/pthread          -  pthread_key*.c, pthread_*specific.c - Move to libs/libc/pthread

@xiaoxiang781216 I have created an errno feature branch.  Feel free to contribute to this branch via PRs.

@patacongo Ok. I will look at the change in that branch.

Discussion moved to https://cwiki.apache.org/confluence/display/NUTTX/Userspace+errno+and+TLS


[podnapisi] ProviderError: More than one file to unzip

I'm running latest subliminal from git develop (22c5a9e), on Xubuntu 18.04.
I've just tried to download English subtitles for Next.Stop,.Greenwich.Village.1976.720p.BluRay.x264-[YTS.AM].mp4 using this command line (I've omitted login information)
subliminal --debug download --refiner metadata --refiner tvdb -l en -m 0 -s Next.Stop,.Greenwich.Village.1976.720p.BluRay.x264-[YTS.AM].mp4

and got this error:
INFO:subliminal.score:Computed score 91 with final matches {'hearing_impaired', 'year', 'title'}
INFO:subliminal.core:Downloading subtitle <PodnapisiSubtitle 'lDIC' [en]>
INFO:subliminal.providers.podnapisi:Downloading subtitle <PodnapisiSubtitle 'lDIC' [en]>
ERROR:subliminal.core:Unexpected error in provider 'podnapisi', discarding it
Traceback (most recent call last):
  File "/home/paulo/.local/lib/python3.6/site-packages/subliminal-2.1.0.dev0-py3.6.egg/subliminal/core.py", line 199, in download_subtitle
    self[subtitle.provider_name].download_subtitle(subtitle)
  File "/home/paulo/.local/lib/python3.6/site-packages/subliminal-2.1.0.dev0-py3.6.egg/subliminal/providers/podnapisi.py", line 195, in download_subtitle
    raise ProviderError('More than one file to unzip')
subliminal.exceptions.ProviderError: More than one file to unzip

The full output is here.

I tried the same command with latest development 3f32e8a5734876ae373c2c5614db77a03ae5d391, and I was able to properly download the subtitle.
Could you confirm that's not an issue anymore?

I'm seeing this same error with 160ea63.


Github markdown support for readme

Correct broken links in public facing readme before zenodo publication

@rccreswell @I-Bouros I wanted to tidy up this repo before adding to zenodo for the current paper, however there seem to be more issues with the tests and doc hosting that I can fix now (or have access to fix in the case of the docs). Would you be able to look at this and then we can issue a release with the updated fixes?


Fixed Err "Cannot read property 'destruct' of null"

Fixed Err "Cannot read property 'destruct' of null"

any reason this can't be merged? This error is pretty annoying with SSR/HMR

@MrStLouis was wondering the same, still waiting for them to merge, maybe they're slow or busy something !!

Any news on this?

Any news on this?

Any news on this?

I guess I will have to revert back to Suneditor until this branch is merged. I can't use the main branch.

Any news on this?

I guess I will have to revert back to Suneditor until this branch is merged. I can't use the main branch.

Any news on this?

Sadly no

Any news on this?

Sadly no

build new version?

build new version?

still a problem with is while changing the page it says
TypeError: Cannot read property 'destruct' of null

Needs to be merged.


allow standalone usage

Problem
I would like to use this lsp in sublime. I think I would really only need to be able to start it standalone, then sublimes lsp package could connect to it. But I cant find out how to just start this server.
Solution
provide a way to start this server "standalone", i.e. not as part of some other extentsion, but on its own, on some ansible project, so sublimes lsp plugin (or that of any other ecditor like emacs/vi etc) can just connect to it to use it
Alternatives
No response
Additional context
No response

I believe this is already supported. I use this server with neovim via nvim-lspconfig, the configuration necessary for that can be found here.

And how do you get the ansible lsp built? Couldn't find instructions for that

As the docs section of the page I linked mentions:
ansible-language-server can be installed via npm:
npm install -g @ansible/ansible-language-server

If you want to build it from source, checking the scripts in the package.json is a good place to start, I haven't done it though, so you might have to ask someone more involved in the project.

ah, there, at the bottom of it :). yes, ok. Guess I will leave this open though as I don't find it easy to find this out at all.
thanks for the pointer!

Happy to help, and you’re right, documentation about standalone usage should probably be included somewhere in this repo. Do you want to change the title to something like “Include Standalone Usage Documentation”?

@mtoohey31 @maddanio PR on document update is welcomed.


Fix the arguments type for on_read and destroy callbacks in iomgr

The functions definition must match grpc_iomgr_cb_func.

Can one of the admins verify this patch?

Can one of the admins verify this patch?


fix: docker composer to run BDJUNO with AGORIC node rpc and grpc

Description
Closes: #XXXX

Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...

[x] included the correct type prefix in the PR title
[ ] added ! to the type prefix if API or client breaking change
[x] targeted the correct branch
[ ] provided a link to the relevant issue or specification
[x] added a changelog entry to CHANGELOG.md
[ ] included comments for documenting Go code
[ ] updated the relevant documentation or specification
[x] reviewed "Files changed" and left comments if necessary
[ ] confirmed all CI checks have passed

Reviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...

[x] confirmed the correct type prefix in the PR title
[ ] confirmed ! in the type prefix if API or client breaking change
[ ] confirmed all author checklist items have been addressed
[ ] reviewed API design and naming
[x] reviewed documentation is accurate
[ ] reviewed tests and test coverage
[x] manually tested (if applicable)

In hasura there is the possibility to apply directly metadata and migrations using the another hasura image, I think this one named v2.39.1-ce.cli-migrations-v2:
https://hub.docker.com/layers/hasura/graphql-engine/v2.39.1-ce.cli-migrations-v2/images/sha256-6f1284b1c8933915672a41793dec6a8ded11cff076da5495ea695fdb12205270?context=explore
So we can remove the script.

I tried it at the first moment, and didn't work.

I don't see the configs folder, so we don't have:

genesis file
config file for agoric
hasura metadata
alpha.sql

I'm not sure about the last 2 if we still need, but I'm sure we need the first 2.

there is a gitigore, fixed mate.

I don't see the configs folder, so we don't have:

genesis file
config file for agoric
hasura metadata
alpha.sql

I'm not sure about the last 2 if we still need, but I'm sure we need the first 2.

we don't need the alpha.sql and the hasura metadata files

I think genesis file should have the agoric suffix or this is not needed because anyway we need to change branch for each chain?

In hasura there is the possibility to apply directly metadata and migrations using the another hasura image, I think this one named v2.39.1-ce.cli-migrations-v2:
hub.docker.com/layers/hasura/graphql-engine/v2.39.1-ce.cli-migrations-v2/images/sha256-6f1284b1c8933915672a41793dec6a8ded11cff076da5495ea695fdb12205270?context=explore
So we can remove the script.

I tried it at the first moment, and didn't work.

What does it mean that it didn't work? What exactly doesn't work, metadata, the whole hasura, something else? I've seen video tutorials where people use this images and they work.


ReturnUrl is mangled/corrupted by ToString call

The fix for #27 changed a line from .AbsoluteUri to .ToString(). The ToString() method for Uri does a multi-level unescape on the query string which essentially corrupts the Uri.
As an example, WIF redirects embed escaped values in a query string parameter to read on return, .ToString() unescapes recursively into plain text, and terminates the string when it sees a "bad" query string (extra =).
We haven't noticed any issues with changing it back to AbsoluteUri, and #27 still seems to be fixed.

send a PR please.

yes or no?

Sorry, can't right now

done and published.


Documentation for retained message support

References https://github.com/rabbitmq/rabbitmq-mqtt/issues/16.

Hi, What is the default store for retained messages ? Disk Based or RAM Based ?
Are there any limitations / configuration settings ?

@sachinmunot please post your questions to rabbitmq-users (the mailing list).


Implement Enumerable#none? without block

Returns `true` if all of the elements of the collection is `false` or `nil`.

I think you mean are `false` ?

Do you mean

Returns true if all of the elements of the collection are false or nil.

?

@yui-knk Yes.

thx!

Thanks!


fixed wrapping, added saving chat after closing game functionality, simplifying a code a little, russian letters fix, added chat tutorial that will appear like a message in the chat once.

ill update it to to master and fix issues with msgs not changing when their sender changes its nick/color and change file location that week

i meant that month


Revert #20329 which cuts details when Status::OK is received in C++

PR #20329 never populates details and message when
the RPC terminates successfully causing a regression, but the spec
does not disallow sending details alongside OK status (does it?)
In fact, other languages such as Python provide such
API and have tests for it and not propagating details
properly is a potential interop issue.

For the record, I am in favor of codifying this behavior (allow libraries to drop details when StatusCode==OK) if the spec is silent on it, but should require a gRFC.

In the c++ API for grpc::Status, it says very clearly that it is an error to construct an ok status with non-empty error message. I believe this has been true since the beginning of the project and also believe that this is a valid interpretation of the spec.

+1 to Vijay's comment.  error_message() and error_details() were always considered an error for OK status in C++:
https://github.com/grpc/grpc/blob/master/include/grpcpp/impl/codegen/status.h#L90

Go has the same requirement as c++.

I am in favor of this interpretation--for the sake of consistency: cc @lidizheng @gnossen; this is an area that Python differs (see the linked test in my OP which verifies details is transmitted intact even if the status is OK).

@mehrdada When I was working on rich error detail, I also found this difference. I discussed it with @ericgribkoff back then and felt it is more correct to be consistent with other languages.
Do you have a case that OK with details are useful?

@lidizheng No, I don't--to be clear, I am in favor of allowing OK to discard messages as well. I just got bitten by this due to interop tests between my C++-based Python implementation and the upstream Cython implementation failing on upgrade.

@mehrdada If the test case is not legit, you can propose another PR to remove the test case. So, the new implementation can be correct.

@lidizheng will do -- just wanted to bring you in the loop


The module does not support ESM correctly

Reproduce Steps

Install the package:

$ yarn add headers-polyfill

Put the following code into index.mjs:

import { Headers } from 'headers-polyfill';

Execute index.mjs:

$ node index.mjs

Get the following error:
file:///Users/chentsulin/oss/test-headers-polyfill/index.mjs:1
import { Headers } from 'headers-polyfill'
         ^^^^^^^
SyntaxError: Named export 'Headers' not found. The requested module 'headers-polyfill' is a CommonJS module, which may not support all module.exports as named exports.
CommonJS modules can always be imported via the default export, for example using:

import pkg from 'headers-polyfill';
const { Headers } = pkg;

    at ModuleJob._instantiate (node:internal/modules/esm/module_job:128:21)
    at async ModuleJob.run (node:internal/modules/esm/module_job:194:5)
    at async Promise.all (index 0)
    at async ESMLoader.import (node:internal/modules/esm/loader:385:24)
    at async loadESM (node:internal/process/esm_loader:88:5)
    at async handleMainPromise (node:internal/modules/run_main:61:12)

This should be fixed by #47


Duplicate class com.afollestad.materialdialogs.simplelist

Please consider making a Pull Request if you are capable of doing so.
Library Version:
2.x.x
Affected Device(s):
Google Pixel 3 XL with Android 9.0
Describe the Bug:
A clear description of what is the bug is.
To Reproduce:
1.
2.
3.
Expected Behavior:
A clear description of what you expected to happen.

What about version 3.3.0? Have you tried it?


added effective_url support

Context
@hannesl and I encountered this issue https://github.com/php-vcr/php-vcr/issues/227. @hannesl's solution was to change elasticsearch codebase. However, I thought it is best to add the change to php-vcr.
What has been done

439a96d Added effective_url field in the Response object

How to test

Please see https://github.com/php-vcr/php-vcr/issues/227
Run tests

@renatomefi ping? :)

Any ideas if this will be merged?

Ha, browsing for a new issue I totally missed this PR and the associated ticket when I ran into the same problem and  opened issue #363 and PR #364.
As your PR has been wasting for 4 years, I'll assume this isn't getting fixed.

Since we're persisting the whole curl info array starting with #300 this should be redundant.


Batch Update method pass wrong DateTime.Now param.

Here is what to include in your request to make sure we implement a solution as quickly as possible.
1. Description
My Batch Update code is like this:
await _context.StudyVideos.Where(w => listIds.Contains(w.Id)).UpdateAsync(c =>
                            new StudyVideo()
                            {
                                Status = status,
                                UpdateTime = DateTime.Now,
                                PublishTime = status == PublishStatus.Publish ? DateTime.Now : c.PublishTime,
                                UpdateUserId = userId
                            })

It will get the follow SQL
UPDATE "studyvideo"
SET "status" = @zzz_BatchUpdate_0,
"updatetime" = @zzz_BatchUpdate_1,
"publishtime" = now(),--error
"updateuserid" = @zzz_BatchUpdate_3
WHERE EXISTS ( SELECT 1 FROM (SELECT xxxx
FROM studyvideo AS s
WHERE s.id = ANY (@__listIds_0)) B
               WHERE "studyvideo"."id" = B."id"
           )

2. Exception
The error is all my date in database is not UTC.
so @zzz_BatchUpdate_1 is not equals now()
I have to write more code like this
if (status == PublishStatus.Publish)
{
//...
PublishTime = DateTime.Now,
}
else
{
//...
PublishTime = c.PublishTime,
}

4. Any further technical details
My DLL is Z.EntityFramework.Plus.EFCore version 5.15.0

Hello @wangshuai-007 ,
If I understand correctly, to solve this issue, you should declare a date variable outside of the expression such as:
var publishTime = DateTime.Now; // or the exact way you want it to be saved in your database

await _context.StudyVideos.Where(w => listIds.Contains(w.Id)).UpdateAsync(c =>
                            new StudyVideo()
                            {
                                Status = status,
                                UpdateTime = DateTime.Now,
                                PublishTime = status == PublishStatus.Publish ? publishTime : c.PublishTime,
                                UpdateUserId = userId
                            })

The SQL will now take directly the value from the publishTime instead of using Now
Let me know if that solved your issue.
Best Regards,
Jon

Sponsorship
Help us improve this library
Performance Libraries
context.BulkInsert(list, options => options.BatchSize = 1000);
Entity Framework Extensions • Dapper Plus
Runtime Evaluation
Eval.Execute("x + y", new {x = 1, y = 2}); // return 3
C# Eval Function


HTTP2: add error details on some NGHTTP2 errors.

Add wiring to propagate error details from the http2 codec to the
access log.  Such wiring inserts a DownstreamProtocolError response
flag (appearing as "DPE" in the log) and a string with details of the
error.  Currently, this mechanism is only triggered by the
onInvalidFrame callback.
Before this change, DownstreamProtocolError was handled
inconsistently.  If stream_error_on_invalid_http_messaging, we closed
the stream but did not log a DPE.  Otherwise, we closed all streams
and logged a DPE.  The current code reports a DPE in all cases.
Signed-off-by: Matteo Frigo<EMAIL_ADDRESS>For an explanation of how to fill out the fields, please see the relevant section
in PULL_REQUESTS.md
Description: add error details on some NGHTTP2 errors
Risk Level: low
Testing: unit tests for specific expected errors, integration tests to verify that the access log has the expected output
Docs Changes: none
Release Notes: none
[Optional Fixes #Issue]
[Optional Deprecated:]

@matteof-google please avoid force pushing as it hides previous review comments.

Needs DCO fix for some commits.

Thanks @yanavlasov .  I have fixed the DCO issue and squashed the somewhat messy history into one commit.  The patch should be ready for merging now.


Failed to apply plugin 'dev.flutter.flutter-gradle-plugin', Could not get unknown property 'usesUnsupportedDependencyVersions' for project ':app' of type org.gradle.api.Project.

Steps to reproduce

melos clean && melos bootstrap
fvm flutter pub get
fvm flutter pub upgrade
fvm flutter pub run build_runner clean
fvm flutter pub run build_runner build --delete-conflicting-outputs
running project

Expected results
Success running
Actual results
Failed to compile
Logs
Logs
FAILURE: Build failed with an exception.

* Where:
Build file '/Users/herisarwanto/AndroidStudioProjects/FREELANCE/99Group/NEW-Rumah123-Pro/rumah123-pro-apps/packages/app/android/app/build.gradle' line: 4

* What went wrong:
An exception occurred applying plugin request [id: 'dev.flutter.flutter-gradle-plugin']
> Failed to apply plugin 'dev.flutter.flutter-gradle-plugin'.
   > Could not get unknown property 'usesUnsupportedDependencyVersions' for project ':app' of type org.gradle.api.Project.

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 2s
Error: Gradle task assembleDevDebug failed with exit code 1

Flutter Doctor output
`[✓] Flutter (Channel stable, 3.24.0, on macOS 14.5 23F79 darwin-arm64, locale en-ID)
• Flutter version 3.24.0 on channel stable at /Users/herisarwanto/fvm/versions/3.24.0
• Upstream repository https://github.com/flutter/flutter.git
• Framework revision 80c2e84975 (8 weeks ago), 2024-07-30 23:06:49 +0700
• Engine revision b8800d88be
• Dart version 3.5.0
• DevTools version 2.37.2
[✓] Android toolchain - develop for Android devices (Android SDK version 33.0.2)
• Android SDK at /Users/herisarwanto/Library/Android/sdk
• Platform android-34, build-tools 33.0.2
• Java binary at: /Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/java
• Java version OpenJDK Runtime Environment (build 17.0.10+0-17.0.10b1087.21-11609105)
• All Android licenses accepted.
[✓] Xcode - develop for iOS and macOS (Xcode 15.1)
• Xcode at /Applications/Xcode.app/Contents/Developer
• Build 15C65
• CocoaPods version 1.14.3
[✓] Chrome - develop for the web
• Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome
[✓] Android Studio (version 2024.1)
• Android Studio at /Applications/Android Studio.app/Contents
• Flutter plugin can be installed from:
🔨 https://plugins.jetbrains.com/plugin/9212-flutter
• Dart plugin can be installed from:
🔨 https://plugins.jetbrains.com/plugin/6351-dart
• Java version OpenJDK Runtime Environment (build 17.0.10+0-17.0.10b1087.21-11609105)
[✓] VS Code (version 1.91.1)
• VS Code at /Applications/Visual Studio Code.app/Contents
• Flutter extension version 3.90.0
[✓] Connected device (4 available)
• SM A528B (mobile)               • RRCT2007KEX           • android-arm64  • Android 14 (API 34)
• macOS (desktop)                 • macos                 • darwin-arm64   • macOS 14.5 23F79 darwin-arm64
• Mac Designed for iPad (desktop) • mac-designed-for-ipad • darwin         • macOS 14.5 23F79 darwin-arm64
• Chrome (web)                    • chrome                • web-javascript • Google Chrome 118.0.5993.117
! Error: Browsing on the local area network for iPhone 13 Pro Max. Ensure the device is unlocked and attached with a cable or associated with the same local area network as this Mac.
The device must be opted into Developer Mode to connect wirelessly. (code -27)
[✓] Network resources
• All expected network resources are available.
• No issues found!
`

@herisarwanto99 Hello have you try clean gradle? ./gradlew clean

@herisarwanto99
Check this issue with underlying comments and see if it helps to resolve your issue or not.

This issue has been resolved in my monorepo project by following these steps:

Delete Gradle cache
In the android directory, clean the project:
./gradlew clean
In the /app directory, delete the .dart_tool folder, then run:
fvm flutter pub get fvm flutter pub upgrade fvm flutter pub run build_runner clean fvm flutter pub run build_runner build --delete-conflicting-outputs
In the root project directory, run:
melos clean && melos bootstrap


Update 502.5 Common Errors and VC++ redist information

Fixes #2858
Adds a blurb to 502.5 errors in the Common Errors section calling out first that the dev should run the app locally to make sure that the process failure in IIS isn't actually caused by a problem within the app itself.
Add a line to help ward off the missing VC++ redist for servers that are offline.
Also modifies the name from Microsoft Visual C++ 2015 Redistributable (x64) to Microsoft Visual C++ 2015 Redistributable.

@GuardRex,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by .NET Foundation. We will now review your pull request.
Thanks,
.NET Foundation Pull Request Bot

@GuardRex  is this ready for review/merge?

@Rick-Anderson Yes, Sir. It's ready for a :eye: look see and "mergeola:tm:."

@GuardRex  we're using xref:UID in lieu of relative links; looks good.

I know. This doc needs another one of my treatments. I only touched it for the one thing here. I'd like to come back later and do a number on it.

@Rick-Anderson I fixed the little merge conflict.
Is it ok if I come back to the doc in a few days and do The Full Monty on a new PR? I'll fix those xref probs and anything else I find.

@GuardRex  no hurry.

@Rick-Anderson Ok, in that case, this one is ready for review/merge.


[6.0] Don’t add a space between private and (

Explanation: BasicFormat was adding a space between private and ( in private(set), which started raising a warning with recent compilers: Extraneous whitespace between attribute name and '('; this is an error in Swift 6
Scope: Formatting of private(set)
Risk: Very low, very targeted fix
Testing: Added a test case
Issue: rdar://124569733
Reviewer:  @bnbarham on https://github.com/apple/swift-syntax/pull/2590

@swift-ci Please test

Closing in favor of https://github.com/apple/swift-syntax/pull/2592


Investigate cause of segfaults

We're seeing some segfaults in our logs. There's some logging in place now to start tracking when these happen, but we're not getting very much information from them at the moment. Each occurrence does seem to share the same library offset in libgeos though.
Nov 16 22:19:20 tilequeue24 kernel: [2196859.797264] tilequeue[17743]: segfault at 0 ip 00007f09b1905f80 sp 00007ffdfebf8d18 error 4 in libgeos-3.4.2.so[7f09b1831000+176000]

Ooops, this would have been a more appropriate place to write this comment.

Great idea! I'll look into what it takes to make this happen for the future.
Luckily though, getting down to the bottom of the queue ended up revealing a few tiles that reliably reproduce the issue, at least on a production machine.

13/4241/2797
15/9177/11925
15/16963/11189
15/16964/11189
15/16964/11190

All but one of those tiles are near Apach, France, which is a pretty strong indication that there's a bit of geometry there which is causing GEOS to choke. More specifically, it seems to be around the railway station (but it's along the river, too, so no clues yet as to which bit of geometry might be causing it). But if we can reproduce it, we can debug it :smile:

Are we seeing any more segfaults in production after fixing that snapped geoms issue?

I didn't push out a fix to production for this yet. There's a couple of updates to fix other issues too, maybe it makes sense to roll all those out at once.


identifiers: add pmcid

:heart: Thank you for your contribution!
Description
PMCID is a critical identifier for US institutions who need manage NIH compliance. It's already available in idutils, but didn't make it into the default RDM list. PMID did make the list, but unfortunately PMID and PMCID are different identifiers for the metadata and article content respectively. Most articles will have both, and they will be different (see https://pubmed.ncbi.nlm.nih.gov/36092012/).
If we're only supporting one identifier, PMCID would actually be preferred as it's more useful. But it seemed less disruptive to just add PMCID instead of swapping.
Checklist
Ticks in all boxes and 🟢 on all GitHub actions status checks are required to merge:

[ ] I'm aware of the code of conduct.
[ ] I've created logical separate commits and followed the commit message format.
[ ] I've added relevant test cases.
[ ] I've added relevant documentation.
[ ] I've marked translation strings (for relevant code).
[ ] I've followed the CSS/JS and React guidelines (for relevant code).
[ ] I've followed the web accessibility guidelines (for relevant code).
[ ] I've followed the user interface guidelines (for relevant code).
[ ] I've identified the copyright holder(s) and updated copyright headers for touched files (>15 lines contributions).
[ ] I've NOT included third-party code (copy/pasted source code or new dependencies).

Third-party code
If you've added third-party code (copy/pasted or new dependencies), please reach out to an architect.
Reminder
By using GitHub, you have already agreed to the GitHub’s Terms of Service including that:

You license your contribution under the same terms as the current repository’s license.
You agree that you have the right to license your contribution under the current repository’s license.

Yup, this isn't so much of a technical pull request as a policy pull request.

I've done some more testing, and because identifier types are shared between alternative and related this change breaks the DataCite submission pipeline. I'm going to think about better approaches for this.

I'm closing this for now. There is odd behavior with DOI minting and non-standard identifier types. It looks like there is a validation step that uses non-serialized metadata. I'm tracking the issue https://github.com/caltechlibrary/caltechauthors/issues/6


About certificate signing for distribution

This page mentions that "it's recommended to sign your app package with a certificate from a certificate authority" to distribute an APPX or MSIX out of the Store, but if I distribute my app in the Store and outside the Store using MSIX, do I really need to purchase a certificate or I can get my MSIX signed by Microsoft for distribution outside the Store?

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

ID: 715b34c6-c615-4614-5263-c7ecca7c2151
Version Independent ID: 5788dfe2-0396-40ae-24c0-c640e5e6d1c9
Content: Hosting UWP app packages on AWS for web install - UWP app developer
Content Source: windows-apps-src/packaging/web-install-aws.md
Product: uwp
GitHub Login: @laurenhughes
Microsoft Alias: cdon

Also, if I need to purchase a certificate, would I need to sign every binary file in the package or just signing the MSIX will be fine? What if my app wants admin, will the signature from the MSIX show up? Or does signing the MSIX also signs all binaries inside?

Thanks for your feedback, and I apologize for the delay in responding. Please see our main packaging signing article for info about signing in general. If your questions are not answered by that article, please submit your feedback using the "Feedback" control at the bottom of the article.
You can also try the following support options to get help with your questions:

Microsoft Q&A offers relevant and timely answers to your technical problems from a community of experts and Microsoft engineers.
For community assistance with development questions, there are our forums, and StackOverflow.
The Windows developer support site explains other support options.


Provide example for AdoptedResource

What is the URL of the document?
Which section(s) is the issue in?
Likely "Tutorials"
What needs fixing?
There is no example for how to use AdoptedResource in the documentation, which may be affecting its adoption.
Additional context
Provide some examples with how it works with one or more services.

Design proposal has some good examples at https://github.com/aws-controllers-k8s/community/blob/main/docs/design/proposals/adoption/resource-adoption.md
But not sure if it matches with implementation. Adding it in the official documentation will definitely help the adopters.

@jeesmon I have more examples, if anyone needs them. Thankfully the implementation does actually match the proposal, except that the apiVersion of the resource is not service specific - that is, the apiVersion is services.k8s.aws/v1alpha1
Here's one example with an S3 bucket
apiVersion: services.k8s.aws/v1alpha1
kind: AdoptedResource
metadata:
  name: adopt-boring-bucket
spec:
  aws:
    nameOrID: boring-old-normal-bucket
  kubernetes:
    group: s3.services.k8s.aws
    kind: Bucket
    metadata:
      name: my-adopted-bucket

Ideally we should provide examples in the examples repository
/lifecycle frozen


Cleanup code with correct usage of $err and errmsg

Mongo has $err and errmsg in response from the server. Usually, $err is for the error code and errmsg is for error description. Our error handling is not consistent. At least it is less consistent than Mongo.

@apkar please assign this to me.
Will cleanup and make them uniform using seterror function


vp9_lp enc: enable vp9_lp encoding for gst-vaapi

enable vp9 8bit encoding(vdenc) test for gst-vaapi
Signed-off-by: Yuankun Zhang<EMAIL_ADDRESS>

Thanks for the patch, merging it.


Non-responsive

is it possible to disable the responsiveness of the template made by materialize ? and how ?

If you read the documentation you should be able to edit the template to remove the responsive items: grid, nav bar.