[Fix #5188] Add --no-auto-gen-timestamp option

An option to generate a .rubocop_todo.yml file that does not change unless there are substantive changes to its content.
With this option and --no-offence-counts combined the .rubocop_todo.yml config should not change from run to run unless there are differences in the offences detected. This will allow developers to use automated git diff tests to check that the .rubocop_todo.yml is up-to-date.
In options.rb the verification of the presence of --auto-gen-config when any of the three associated options is supplied has been consolidated. This ensures that handling of these parameters is consistent, and as a nice side-effect it allows us to remove the args parameter from a chain of methods right up to define_options.

Before submitting the PR make sure the following are checked:

[x] Wrote good commit messages.
[x] Commit message starts with [Fix #issue-number] (if the related issue exists).
[x] Feature branch is up-to-date with master (if not - rebase it).
[x] Squashed related commits together.
[x] Added tests.
[x] Added an entry to the Changelog if the new code introduces user-observable changes. See changelog entry format.
[x] The PR relates to only one subject with a clear title
and description in grammatically correct, complete sentences.
[x] Run rake default or rake parallel. It executes all tests and RuboCop for itself, and generates the documentation.

Apart from the failed build, the changes look good to me.

👍


x86_64 arch binaries support

We should remind users to download the latest k8s component(kubelet, kubectl, kube-apiserver,kube-controller-manager,  kube-scheduler) binaries from https://www.downloadkubernetes.com/ based on their os and arch.
For the rest of tools: cri, runc, etcd, cni-plugins, containerd, we can download from github release:
https://github.com/kubernetes-sigs/cri-tools/releases
https://github.com/opencontainers/runc/releases
https://github.com/containernetworking/plugins/releases
https://github.com/etcd-io/etcd/releases
https://github.com/containerd/containerd/releases/
BTW, If you are doing it via x86_64 arch vms, use below for downloads.txt:
https://dl.k8s.io/release/v1.29.3/bin/linux/amd64/kubectl
https://dl.k8s.io/v1.29.3/bin/linux/amd64/kube-apiserver
https://dl.k8s.io/v1.29.3/bin/linux/amd64/kube-controller-manager
https://dl.k8s.io/v1.29.3/bin/linux/amd64/kube-scheduler
https://github.com/kubernetes-sigs/cri-tools/releases/download/v1.29.0/crictl-v1.29.0-linux-amd64.tar.gz
https://github.com/opencontainers/runc/releases/download/v1.1.12/runc.amd64
https://github.com/containernetworking/plugins/releases/download/v1.4.0/cni-plugins-linux-amd64-v1.4.0.tgz
https://github.com/containerd/containerd/releases/download/v1.7.15/containerd-1.7.15-linux-amd64.tar.gz
https://dl.k8s.io/v1.29.3/bin/linux/amd64/kube-proxy
https://dl.k8s.io/v1.29.3/bin/linux/amd64/kubelet
https://github.com/etcd-io/etcd/releases/download/v3.5.13/etcd-v3.5.13-linux-amd64.tar.gz

I would like to ask, have you successfully implemented it using x86_64 arch vm?

This has worked for me and I was able to confirm the version going through the Jumpbox setup
SMP PREEMPT_DYNAMIC Debian 6.1.106-3 (2024-08-26) x86_64 GNU/Linux
Client Version: v1.29.3
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3

I would like to ask, have you successfully implemented it using x86_64 arch vm?

Yes I have


fix: fixes refreshing expired credentials by preventing DefaultCredentialsProvider from being autoclosed

Fixes #494
Pulls the client instantiation out of the try-with-resource block to stop it being closed and therefore not usable when refreshing expired credentials.

No worries! Any chance I could get this and #499 in a new release?


v2.6.6 & v2.6.7 x64 on windows 10, crashed without doing anything

What happened?
Crashed when transcribing wav file, https://github.com/thewh1teagle/vibe/raw/main/samples/single.wav.
Still crashed when selecting the language to English.
whisper main.exe is fine, following DEBUG.md:
D:\soft\语音识别\whisper-bin-x64>main.exe -m "%localappdata%\github.com.thewh1teagle.vibe\ggml-medium.bin" -f "samples_single.wav"
whisper_init_from_file_with_params_no_state: loading model from 'C:\Users\slj\AppData\Local\github.com.thewh1teagle.vibe\ggml-medium.bin'
whisper_init_with_params_no_state: use gpu    = 1
whisper_init_with_params_no_state: flash attn = 0
whisper_init_with_params_no_state: gpu_device = 0
whisper_init_with_params_no_state: dtw        = 0
whisper_model_load: loading model
whisper_model_load: n_vocab       = 51865
whisper_model_load: n_audio_ctx   = 1500
whisper_model_load: n_audio_state = 1024
whisper_model_load: n_audio_head  = 16
whisper_model_load: n_audio_layer = 24
whisper_model_load: n_text_ctx    = 448
whisper_model_load: n_text_state  = 1024
whisper_model_load: n_text_head   = 16
whisper_model_load: n_text_layer  = 24
whisper_model_load: n_mels        = 80
whisper_model_load: ftype         = 1
whisper_model_load: qntvr         = 0
whisper_model_load: type          = 4 (medium)
whisper_model_load: adding 1608 extra tokens
whisper_model_load: n_langs       = 99
whisper_model_load:      CPU total size =  1533.14 MB
whisper_model_load: model size    = 1533.14 MB
whisper_init_state: kv self size  =  150.99 MB
whisper_init_state: kv cross size =  150.99 MB
whisper_init_state: kv pad  size  =    6.29 MB
whisper_init_state: compute buffer (conv)   =   28.68 MB
whisper_init_state: compute buffer (encode) =  594.22 MB
whisper_init_state: compute buffer (cross)  =    7.85 MB
whisper_init_state: compute buffer (decode) =  142.09 MB

system_info: n_threads = 4 / 8 | AVX = 1 | AVX2 = 1 | AVX512 = 0 | FMA = 1 | NEON = 0 | ARM_FMA = 0 | METAL = 0 | F16C = 1 | FP16_VA = 0 | WASM_SIMD = 0 | BLAS = 0 | SSE3 = 1 | SSSE3 = 1 | VSX = 0 | CUDA = 0 | COREML = 0 | OPENVINO = 0

main: processing 'samples_single.wav' (176000 samples, 11.0 sec), 4 threads, 1 processors, 5 beams + best of 5, lang = en, task = transcribe, timestamps = 1 ...

[00:00:00.000 --> 00:00:11.000]   And so my fellow Americans, ask not what your country can do for you, ask what you can do for your country.

whisper_print_timings:     load time =  1365.07 ms
whisper_print_timings:     fallbacks =   0 p /   0 h
whisper_print_timings:      mel time =    13.70 ms
whisper_print_timings:   sample time =   109.81 ms /   140 runs (    0.78 ms per run)
whisper_print_timings:   encode time = 22000.97 ms /     1 runs (22000.97 ms per run)
whisper_print_timings:   decode time =    78.02 ms /     2 runs (   39.01 ms per run)
whisper_print_timings:   batchd time =  2593.34 ms /   136 runs (   19.07 ms per run)
whisper_print_timings:   prompt time =     0.00 ms /     1 runs (    0.00 ms per run)
whisper_print_timings:    total time = 26219.97 ms

D:\soft\语音识别\whisper-bin-x64>

Steps to reproduce
PS D:\Program Files\vibe> set RUST_BACKTRACE=1
PS D:\Program Files\vibe> set RUST_LOG=vibe=debug,whisper_rs=debug
PS D:\Program Files\vibe> .\vibe.exe
PS D:\Program Files\vibe> ggml_vulkan: Compiling shaders..............................Done!
thread 'tokio-runtime-worker' panicked at core\src\panicking.rs:221:5:
panic in a function that cannot unwind
COMMIT: c6f139e
2024-12-01T09:52:29.248490Z ERROR vibe::panic_hook: desktop\src-tauri\src\panic_hook.rs:22: thread 'tokio-runtime-worker' panicked at core\src\panicking.rs:221:5:
panic in a function that cannot unwind
COMMIT: c6f139e
thread caused non-unwinding panic. aborting.

### What OS are you seeing the problem on?

Window

C:\Users\xxx>neofetch
..,
....,,:;+ccllll            xxx@LAPTOP-SS
...,,+:;  cllllllllllllllllll            --------------
,cclllllllllll  lllllllllllllllllll            OS: Windows 10 Home China
llllllllllllll  lllllllllllllllllll            Build: 22H2 (19045)
llllllllllllll  lllllllllllllllllll            Uptime: 3 days, 2 hours, 45 minutes
llllllllllllll  lllllllllllllllllll            Resolution: 1920x1080 @60Hz
llllllllllllll  lllllllllllllllllll            Terminal: 命令提示符 - neofetch
llllllllllllll  lllllllllllllllllll            CPU: Intel(R) Core(TM) i5-9300H CPU @ 2.40GHz
GPU: Intel(R) UHD Graphics 630
llllllllllllll  lllllllllllllllllll            Memory: 12346 MB / 16226 MB (76% in use)
llllllllllllll  lllllllllllllllllll            Disk: C:\ 243.62 GB (121.97 GB free)
llllllllllllll  lllllllllllllllllll
llllllllllllll  lllllllllllllllllll            Mem%:  -=[ //////////////////// ]=-
llllllllllllll  lllllllllllllllllll
llllllllllllll  lllllllllllllllllll            Disk%: -=[ //////////////////// ]=-
'ccllllllllll  lllllllllllllllllll       ' \::  :ccllllllllllllllll
````''::cll
``

### Relevant log output

```shell
{"timestamp":"2024-12-01T09:52:18.240166Z","level":"DEBUG","fields":{"message":"LEVEL vibe=DEBUG,vibe_core=DEBUG,whisper_rs=INFO"},"target":"vibe::logging"}
{"timestamp":"2024-12-01T09:52:18.240266Z","level":"DEBUG","fields":{"message":"Setup logging to file at C:\\Users\\xxxxx\\AppData\\Roaming\\github.com.thewh1teagle.vibe\\log_2024-12-01.txt"},"target":"vibe::logging"}
{"timestamp":"2024-12-01T09:52:18.240287Z","level":"DEBUG","fields":{"message":"clean old logs"},"target":"vibe::cleaner"}
{"timestamp":"2024-12-01T09:52:18.240321Z","level":"DEBUG","fields":{"message":"searching old logs in C:\\Users\\xxxxx\\AppData\\Roaming\\github.com.thewh1teagle.vibe/log*.txt"},"target":"vibe::cleaner"}
{"timestamp":"2024-12-01T09:52:18.241063Z","level":"DEBUG","fields":{"message":"Skip clean of current log path C:\\Users\\xxxxx\\AppData\\Roaming\\github.com.thewh1teagle.vibe\\log_2024-12-01.txt"},"target":"vibe::cleaner"}
{"timestamp":"2024-12-01T09:52:18.241189Z","level":"DEBUG","fields":{"message":"searching old files in C:\\Users\\xxxxx\\AppData\\Local\\Temp/vibe_temp*"},"target":"vibe::cleaner"}
{"timestamp":"2024-12-01T09:52:18.243231Z","level":"DEBUG","fields":{"message":"Skip deletion of C:\\Users\\xxxxx\\AppData\\Local\\Temp\\vibe_temp_2024-12-01"},"target":"vibe::cleaner"}
{"timestamp":"2024-12-01T09:52:18.243261Z","level":"DEBUG","fields":{"message":"Vibe App Running"},"target":"vibe::setup"}
{"timestamp":"2024-12-01T09:52:18.243643Z","level":"DEBUG","fields":{"message":"webview version: 131.0.2903.70"},"target":"vibe::setup"}
{"timestamp":"2024-12-01T09:52:18.243857Z","level":"DEBUG","fields":{"message":"Protocol handler registered successfully."},"target":"vibe::custom_protocol"}
{"timestamp":"2024-12-01T09:52:18.243880Z","level":"DEBUG","fields":{"message":"Cargo features: vulkan"},"target":"vibe::setup"}
{"timestamp":"2024-12-01T09:52:18.243897Z","level":"DEBUG","fields":{"message":"CPU Features\n{\"avx\":{\"enabled\":true,\"support\":true},\"avx2\":{\"enabled\":true,\"support\":true},\"f16c\":{\"enabled\":true,\"support\":true},\"fma\":{\"enabled\":true,\"support\":true}}"},"target":"vibe::setup"}
{"timestamp":"2024-12-01T09:52:18.243904Z","level":"DEBUG","fields":{"message":"Executable Architecture: x86_64"},"target":"vibe::setup"}
{"timestamp":"2024-12-01T09:52:18.243909Z","level":"DEBUG","fields":{"message":"APP VERSION: 2.6.7"},"target":"vibe::setup"}
{"timestamp":"2024-12-01T09:52:18.243913Z","level":"DEBUG","fields":{"message":"COMMIT HASH: c6f139e"},"target":"vibe::setup"}
{"timestamp":"2024-12-01T09:52:18.243921Z","level":"DEBUG","fields":{"message":"Non CLI mode"},"target":"vibe::setup"}
{"timestamp":"2024-12-01T09:52:19.330703Z","level":"DEBUG","fields":{"message":"Vulkan support is successfully checked and working."},"target":"vibe::cmd"}
{"timestamp":"2024-12-01T09:52:19.348955Z","level":"DEBUG","fields":{"message":"Default Input Device:\nOk(\"麦克风阵列 (Realtek(R) Audio)\")"},"target":"vibe::cmd::audio"}
{"timestamp":"2024-12-01T09:52:19.349020Z","level":"DEBUG","fields":{"message":"Default Output Device:\nOk(\"扬声器 (Realtek(R) Audio)\")"},"target":"vibe::cmd::audio"}
{"timestamp":"2024-12-01T09:52:19.349786Z","level":"DEBUG","fields":{"message":"Devices: "},"target":"vibe::cmd::audio"}
{"timestamp":"2024-12-01T09:52:24.019322Z","level":"DEBUG","fields":{"message":"loading model first time"},"target":"vibe::cmd"}
{"timestamp":"2024-12-01T09:52:24.019371Z","level":"DEBUG","fields":{"message":"open model..."},"target":"vibe_core::transcribe"}
{"timestamp":"2024-12-01T09:52:24.019464Z","level":"DEBUG","fields":{"message":"gpu device: 0"},"target":"vibe_core::transcribe"}
{"timestamp":"2024-12-01T09:52:24.019473Z","level":"DEBUG","fields":{"message":"use gpu: true"},"target":"vibe_core::transcribe"}
{"timestamp":"2024-12-01T09:52:24.019480Z","level":"DEBUG","fields":{"message":"creating whisper context with model path C:\\Users\\xxxxx\\AppData\\Local\\github.com.thewh1teagle.vibe\\ggml-medium.bin"},"target":"vibe_core::transcribe"}
{"timestamp":"2024-12-01T09:52:24.019495Z","level":"INFO","fields":{"message":"whisper_init_from_file_with_params_no_state: loading model from 'C:\\Users\\xxxxx\\AppData\\Local\\github.com.thewh1teagle.vibe\\ggml-medium.bin'"},"target":"whisper_rs::whisper_sys_tracing"}
{"timestamp":"2024-12-01T09:52:24.019780Z","level":"INFO","fields":{"message":"whisper_init_with_params_no_state: use gpu    = 1"},"target":"whisper_rs::whisper_sys_tracing"}
{"timestamp":"2024-12-01T09:52:24.019793Z","level":"INFO","fields":{"message":"whisper_init_with_params_no_state: flash attn = 0"},"target":"whisper_rs::whisper_sys_tracing"}
{"timestamp":"2024-12-01T09:52:24.019798Z","level":"INFO","fields":{"message":"whisper_init_with_params_no_state: gpu_device = 0"},"target":"whisper_rs::whisper_sys_tracing"}
{"timestamp":"2024-12-01T09:52:24.019803Z","level":"INFO","fields":{"message":"whisper_init_with_params_no_state: dtw        = 0"},"target":"whisper_rs::whisper_sys_tracing"}
{"timestamp":"2024-12-01T09:52:24.040570Z","level":"INFO","fields":{"message":"whisper_init_with_params_no_state: devices    = 2"},"target":"whisper_rs::whisper_sys_tracing"}
{"timestamp":"2024-12-01T09:52:24.040593Z","level":"INFO","fields":{"message":"whisper_init_with_params_no_state: backends   = 2"},"target":"whisper_rs::whisper_sys_tracing"}
{"timestamp":"2024-12-01T09:52:24.040606Z","level":"INFO","fields":{"message":"whisper_model_load: loading model"},"target":"whisper_rs::whisper_sys_tracing"}
{"timestamp":"2024-12-01T09:52:24.040647Z","level":"INFO","fields":{"message":"whisper_model_load: n_vocab       = 51865"},"target":"whisper_rs::whisper_sys_tracing"}
{"timestamp":"2024-12-01T09:52:24.040654Z","level":"INFO","fields":{"message":"whisper_model_load: n_audio_ctx   = 1500"},"target":"whisper_rs::whisper_sys_tracing"}
{"timestamp":"2024-12-01T09:52:24.040659Z","level":"INFO","fields":{"message":"whisper_model_load: n_audio_state = 1024"},"target":"whisper_rs::whisper_sys_tracing"}
{"timestamp":"2024-12-01T09:52:24.040664Z","level":"INFO","fields":{"message":"whisper_model_load: n_audio_head  = 16"},"target":"whisper_rs::whisper_sys_tracing"}
{"timestamp":"2024-12-01T09:52:24.040669Z","level":"INFO","fields":{"message":"whisper_model_load: n_audio_layer = 24"},"target":"whisper_rs::whisper_sys_tracing"}
{"timestamp":"2024-12-01T09:52:24.040674Z","level":"INFO","fields":{"message":"whisper_model_load: n_text_ctx    = 448"},"target":"whisper_rs::whisper_sys_tracing"}
{"timestamp":"2024-12-01T09:52:24.040678Z","level":"INFO","fields":{"message":"whisper_model_load: n_text_state  = 1024"},"target":"whisper_rs::whisper_sys_tracing"}
{"timestamp":"2024-12-01T09:52:24.040683Z","level":"INFO","fields":{"message":"whisper_model_load: n_text_head   = 16"},"target":"whisper_rs::whisper_sys_tracing"}
{"timestamp":"2024-12-01T09:52:24.040687Z","level":"INFO","fields":{"message":"whisper_model_load: n_text_layer  = 24"},"target":"whisper_rs::whisper_sys_tracing"}
{"timestamp":"2024-12-01T09:52:24.040692Z","level":"INFO","fields":{"message":"whisper_model_load: n_mels        = 80"},"target":"whisper_rs::whisper_sys_tracing"}
{"timestamp":"2024-12-01T09:52:24.040696Z","level":"INFO","fields":{"message":"whisper_model_load: ftype         = 1"},"target":"whisper_rs::whisper_sys_tracing"}
{"timestamp":"2024-12-01T09:52:24.040701Z","level":"INFO","fields":{"message":"whisper_model_load: qntvr         = 0"},"target":"whisper_rs::whisper_sys_tracing"}
{"timestamp":"2024-12-01T09:52:24.040707Z","level":"INFO","fields":{"message":"whisper_model_load: type          = 4 (medium)"},"target":"whisper_rs::whisper_sys_tracing"}
{"timestamp":"2024-12-01T09:52:24.106774Z","level":"INFO","fields":{"message":"whisper_model_load: adding 1608 extra tokens"},"target":"whisper_rs::whisper_sys_tracing"}
{"timestamp":"2024-12-01T09:52:24.108366Z","level":"INFO","fields":{"message":"whisper_model_load: n_langs       = 99"},"target":"whisper_rs::whisper_sys_tracing"}
{"timestamp":"2024-12-01T09:52:24.109145Z","level":"INFO","fields":{"message":"whisper_default_buffer_type: using device Vulkan0 (GeForce GTX 1650)"},"target":"whisper_rs::whisper_sys_tracing"}
{"timestamp":"2024-12-01T09:52:24.263772Z","level":"INFO","fields":{"message":"whisper_model_load:  Vulkan0 total size =  1533.14 MB"},"target":"whisper_rs::whisper_sys_tracing"}
{"timestamp":"2024-12-01T09:52:25.948615Z","level":"INFO","fields":{"message":"whisper_model_load: model size    = 1533.14 MB"},"target":"whisper_rs::whisper_sys_tracing"}
{"timestamp":"2024-12-01T09:52:25.955619Z","level":"DEBUG","fields":{"message":"created context successfuly"},"target":"vibe_core::transcribe"}
{"timestamp":"2024-12-01T09:52:25.958667Z","level":"DEBUG","fields":{"message":"ffmpeg additiona options: []"},"target":"vibe::cmd"}
{"timestamp":"2024-12-01T09:52:25.958698Z","level":"DEBUG","fields":{"message":"Transcribe called with {\n  \"path\": \"D:\\\\soft\\\\语音识别\\\\whisper-bin-x64\\\\samples_single.wav\",\n  \"lang\": \"zh\",\n  \"verbose\": false,\n  \"n_threads\": 4,\n  \"init_prompt\": \"\",\n  \"temperature\": 0.4,\n  \"translate\": null,\n  \"max_text_ctx\": null,\n  \"word_timestamps\": false,\n  \"max_sentence_len\": 1\n}"},"target":"vibe_core::transcribe"}
{"timestamp":"2024-12-01T09:52:25.958894Z","level":"DEBUG","fields":{"message":"wav spec: WavSpec { channels: 1, sample_rate: 16000, bits_per_sample: 16, sample_format: Int }"},"target":"vibe_core::transcribe"}
{"timestamp":"2024-12-01T09:52:25.958917Z","level":"DEBUG","fields":{"message":"Skip normalize"},"target":"vibe_core::transcribe"}
{"timestamp":"2024-12-01T09:52:25.958923Z","level":"DEBUG","fields":{"message":"out path is D:\\soft\\语音识别\\whisper-bin-x64\\samples_single.wav"},"target":"vibe_core::transcribe"}
{"timestamp":"2024-12-01T09:52:25.958928Z","level":"DEBUG","fields":{"message":"wav reader read from \"D:\\\\soft\\\\语音识别\\\\whisper-bin-x64\\\\samples_single.wav\""},"target":"vibe_core::audio"}
{"timestamp":"2024-12-01T09:52:25.958998Z","level":"DEBUG","fields":{"message":"parsing D:\\soft\\语音识别\\whisper-bin-x64\\samples_single.wav"},"target":"vibe_core::audio"}
{"timestamp":"2024-12-01T09:52:25.960767Z","level":"INFO","fields":{"message":"whisper_backend_init_gpu: using Vulkan0 backend"},"target":"whisper_rs::whisper_sys_tracing"}
{"timestamp":"2024-12-01T09:52:25.983785Z","level":"INFO","fields":{"message":"whisper_init_state: kv self size  =   50.33 MB"},"target":"whisper_rs::whisper_sys_tracing"}
{"timestamp":"2024-12-01T09:52:26.050685Z","level":"INFO","fields":{"message":"whisper_init_state: kv cross size =  150.99 MB"},"target":"whisper_rs::whisper_sys_tracing"}
{"timestamp":"2024-12-01T09:52:26.054155Z","level":"INFO","fields":{"message":"whisper_init_state: kv pad  size  =    6.29 MB"},"target":"whisper_rs::whisper_sys_tracing"}
{"timestamp":"2024-12-01T09:52:26.058598Z","level":"INFO","fields":{"message":"whisper_init_state: compute buffer (conv)   =   29.51 MB"},"target":"whisper_rs::whisper_sys_tracing"}
{"timestamp":"2024-12-01T09:52:26.070468Z","level":"INFO","fields":{"message":"whisper_init_state: compute buffer (encode) =  170.15 MB"},"target":"whisper_rs::whisper_sys_tracing"}
{"timestamp":"2024-12-01T09:52:26.095460Z","level":"INFO","fields":{"message":"whisper_init_state: compute buffer (cross)  =    7.72 MB"},"target":"whisper_rs::whisper_sys_tracing"}
{"timestamp":"2024-12-01T09:52:26.098330Z","level":"INFO","fields":{"message":"whisper_init_state: compute buffer (decode) =   99.11 MB"},"target":"whisper_rs::whisper_sys_tracing"}
{"timestamp":"2024-12-01T09:52:26.098366Z","level":"DEBUG","fields":{"message":"set language to Some(\"zh\")"},"target":"vibe_core::transcribe"}
{"timestamp":"2024-12-01T09:52:26.098376Z","level":"DEBUG","fields":{"message":"setting temperature to 0.4"},"target":"vibe_core::transcribe"}
{"timestamp":"2024-12-01T09:52:26.098388Z","level":"DEBUG","fields":{"message":"setting init prompt to "},"target":"vibe_core::transcribe"}
{"timestamp":"2024-12-01T09:52:26.098393Z","level":"DEBUG","fields":{"message":"setting n threads to 4"},"target":"vibe_core::transcribe"}
{"timestamp":"2024-12-01T09:52:26.098399Z","level":"DEBUG","fields":{"message":"Diarize enabled DiarizeOptions { segment_model_path: \"C:\\\\Users\\\\xxxxx\\\\AppData\\\\Local\\\\github.com.thewh1teagle.vibe\\\\segmentation-3.0.onnx\", embedding_model_path: \"C:\\\\Users\\\\xxxxx\\\\AppData\\\\Local\\\\github.com.thewh1teagle.vibe\\\\wespeaker_en_voxceleb_CAM++.onnx\", threshold: 0.5, max_speakers: 5 }"},"target":"vibe_core::transcribe"}
{"timestamp":"2024-12-01T09:52:29.248574Z","level":"ERROR","fields":{"message":"thread 'tokio-runtime-worker' panicked at core\\src\\panicking.rs:221:5:\npanic in a function that cannot unwind\nCOMMIT: c6f139e"},"target":"vibe::panic_hook"}

PS D:\Program Files\vibe> set RUST_BACKTRACE=1
PS D:\Program Files\vibe> set RUST_LOG=vibe=debug,whisper_rs=debug

Can you run it from cmd.exe (not powershell)

Let's continue discuss here
https://github.com/thewh1teagle/vibe/issues/370

Vibe 2.6.7.
Er, terribly strange, vibe works fine now!!! Yesterday it crashed on samples_single.wav.
With this in cmd, or just start vibe from the start menu:
set RUST_BACKTRACE=1
set RUST_LOG=vibe=debug,whisper_rs=debug
vibe

Just don't understand.
00:00 --> 00:13
发言者 1:
010, 011, 012, 013, 0014. 0016, 0017, 0018, 0020. (counting in Chinese)

Oh, I got it, I wanted to use whisper on linux, but my linux machine was a little too old, I could not run whisper.cpp on it, the docker container just crashed.
Later I'd like to run the whisper py on my windows device (after compare py-whisper & main from whisper-bin-x64.zip), with the help of powerful, incomparably chatgpt 4o, at long last, I installed torch -cu121, then it said my cuda driver was too old, asked me to update it, then I updated the cuda driver, then py-whisper worked.
And then vibe worked, too. OMG. Maybe we should provide more understandable and clear error messages.


OpenFileModal: Shows protected system files

The file modal shows system files and folders which are normally hidden. Crashes when trying to access them, I guess this is the same for normal files and folders that the user don't have access to.
I've only tested it on Windows.

Can you tell a file or folder so i can use them for testing

There's no specific folder, it's all of them. The problem isn't really that they are showing, it's that it crashes when you try to open them,

the folder which are in the c drive like system32??

Those aren't protected folders, but the user might not have access to them.
"System Volume Information" is a folder that is normally hidden.


Prevent self.resource_moniker == None

self.resource_moniker is initialized None by AbstractPreparer. ResourceGroupPreparer.__init__ reassigns it only when random_name_enabled == True. Therefore when not random_name_enabled we call register_name_pair(some_string, None) and later, str.replace(some_string, None), raising an error.
self.moniker prevents this by ensuring self.resource_moniker is not None.

Can one of the admins verify this patch?


[BUG] ThetaGPU installation and run instructions

Describe the bug
I will start building up a list of problems I encounter when attempting to run through the new Ray-based installation guide and tutorial for ThetaGPU:

https://deephyper.readthedocs.io/en/latest/install/thetagpu.html
https://deephyper.readthedocs.io/en/latest/user_guides/thetagpu.html

Issues
Installation

[x] source /lus/theta-fs0/software/thetagpu/conda/tf_master/2020-11-11/mconda3/setup.sh should probably be replaced with module load conda/tensorflow, unless you specifically need this older version of TensorFlow, in which case you could do conda/tensorflow/2020-11-11. This is more portable (especially for non-Bash shells).
[ ] New users might not know that $PROJECTNAME is by default unset in cd /lus/theta-fs0/projects/$PROJECTNAME

Running

[x] Same comment about replacing source ... with module load conda/tensorflow in SetUp.sh
[ ] For SingleNodeRayCluster.sh, maybe specify that GPUS_PER_TASK=8 must be set to 1 if the single-gpu queue is used
[x] Both scripts call SetUpEnv.sh, but the doc says to name the script SetUp.sh earlier
[x] Add / to ACTIVATE_PYTHON_ENV="${CURRENT_DIR}SetUpEnv.sh"
[ ] Are the following warnings and diagnostics harmless and expected? Might want to note that, if so

➜  fusiondl_aesp ./SingleNodeRayCluster.sh
Script to activate Python env: /lus/theta-fs0/projects/fusiondl_aesp/SetUp.sh
IP Head: <IP_ADDRESS>:6379
Starting HEAD at thetagpu05
➜  fusiondl_aesp /lus/theta-fs0/projects/fusiondl_aesp/dhgpu/lib/python3.8/site-packages/ray/autoscaler/_private/cli_logger.py:57: FutureWarning:
Not all Ray CLI dependencies were found. In Ray 1.4+, the Ray CLI, autoscaler, and dashboard will only be usable via `pip install 'ray[default]'`.
 Please update your install command.
  warnings.warn(
Local node IP: <IP_ADDRESS>
2021-06-08 15:33:32,560 INFO services.py:1272 -- View the Ray dashboard at http://<IP_ADDRESS>:8265
2021-06-08 15:33:32,561 WARNING services.py:1730 -- WARNING: The object store is using /tmp instead of /dev/shm because /dev/shm has only 85899345
92 bytes available. This will harm performance! You may be able to free up space by deleting files in /dev/shm. If you are inside a Docker contain
er, you can increase /dev/shm size by passing '--shm-size=10.24gb' to 'docker run' (or add it to the run_options list in a Ray cluster config). Ma
ke sure to set this to more than 30% of available RAM.

--------------------
Ray runtime started.
--------------------

Next steps
  To connect to this Ray runtime from another node, run
    ray start --address='<IP_ADDRESS>:6379' --redis-password='5241590000000000'

  Alternatively, use the following Python code:
    import ray
    ray.init(address='auto', _redis_password='5241590000000000')

  If connection fails, check your firewall settings and network configuration.

  To terminate the Ray runtime, run
    ray stop

--block
  This command will now block until terminated by a signal.
  Running subprocesses are monitored and a message will be printed if any of them terminate unexpectedly.

Just noticed that I was reading the latest/, not develop/ version of the docs, but I think all of my problems still exist in https://deephyper.readthedocs.io/en/develop/user_guides/thetagpu.html etc.

Hello @felker and thank you for these great feedback.
corrections/updates performed
A new set of installation instruction are available here which uses module load ... instead of source. For now I decided to keep conda/tensorflow/2020-11-11 because the other versions were not tested yet. Also the [default] extra dependency of Ray was added to the setup.py of DeepHyper (corresponding to the first warning of your logs).
The user guide for ThetaGPU was modified according to the new installation procedure (link here).
Then GPUS_PER_TASK and CPUS_PER_TASK were replaced by GPUS_PER_NODE and CPUS_PER_NODE to improve clarity.
questions

What do you mean when saying (see following quote) because when I am doing echo $PROJECTNAME the variable is empty for me.

$PROJECTNAME is by default unset in cd /lus/theta-fs0/projects/$PROJECTNAME"

I am not sure about the behaviour of the single-gpu queue yet because when using it I noticed that nvidia-smi shows 8 GPUS and the /dev/shm looks much smaller than expected. This small size of the memory is related to the second warning and can harm performance.

The single-gpu queue is not handled yet by our ray-submit command line (for example to adapt GPUS_PER_NODE as you described), I contacted the support to have more information about this queue.

What do you mean when saying (see following quote) because when I am doing echo $PROJECTNAME the variable is empty for me.

Yes it is by default empty; that is what I thought might be worth warning users about. E.g. add
"where you set $PROJECTNAME to the the short name of your ALCF project"
Did you hear back from ALCF support about /dev/shm? Would be good to get everything working on single-gpu.

I agree, we can add this comment for $PROJECTNAME.
I am sharing with you the answer from ALCF support on Slack.


Pre-Launch: Rebranding

Make sure to handle any of the UI rebranding details with new assets right before launch.

[ ] Stable Loader Logo
[ ] Main UI Logo

Closing in lieu of https://github.com/AugurProject/augur/issues/8175


Correct the typo of RestulfulServerConfiguration. Fixes #584.

Coverage increased (+0.02%) to 74.797% when pulling d413ac02d3dfd8b4430ea173b2775ad97054399b on nerdydrew:typo into 37fc432fed7f40c26b4ffa4282eed7d3ae913902 on jamesagnew:master.

This is hilarious :)
Thanks for catching and fixing, will review and merge soon.

@jamesagnew Sorry to bother you, but any updates on this?

This was fixed in https://github.com/hapifhir/hapi-fhir/commit/34f7d4ddbde8c145c51a32ae5f675d9e41c358f2#diff-c3166266bde753366e9d5bbb071eb3d11cde558799e92a75275d27b718f5a4b4.


Create insertionSort.java

Summary by Sourcery
New Features:

Implement insertion sort algorithm in Java.

Insertion sort in java


Rewrite aborted on System.Runtime.CompilerServices.ExtensionAttribute

I can't build my project after updating SharePoint Online CSOM through Nuget. Build fails on ccrewrite with the following error.
Reading assembly 'Microsoft.SharePoint.Client.Runtime' from ...\packages\Microsoft.SharePointOnline.CSOM.16.1.3912.1204\lib\net40-full\Microsoft.SharePoint.Client.Runtime.dll' resulted in errors.
Could not resolve type reference: [mscorlib]System.Runtime.CompilerServices.ExtensionAttribute.
Could not resolve member reference: System.Runtime.CompilerServices.ExtensionAttribute::.ctor.
ccrewrite : error : Rewrite aborted due to metadata errors. Check output window
I use Code Contracts extension v.1.9.10714.2 and Visual Studio 2015.

Sorry for the late reply, but can you provide content from the output window?
This issue could be related to #340, but I would like to be sure.

It doesn't have any specific tab in the output window.
1>------ Rebuild All started: Project: Common, Configuration: Debug Any CPU ------
1>  elapsed time: 1615,0429ms
1>  Common -> C:\...\Dev\Common\bin\Debug\HarePoint.WorkflowMigrator.Common.dll
2>------ Rebuild All started: Project: WorkflowManagement, Configuration: Debug Any CPU ------
2>  elapsed time: 2872,0634ms
2>  Reading assembly 'Microsoft.SharePoint.Client.Runtime' from 'C:\...\OnlineCsom\Microsoft.SharePoint.Client.Runtime.dll' resulted in errors.
2>  	Could not resolve type reference: [mscorlib]System.Runtime.CompilerServices.ExtensionAttribute.
2>  	Could not resolve member reference: System.Runtime.CompilerServices.ExtensionAttribute::.ctor.
2>ccrewrite : error : Rewrite aborted due to metadata errors. Check output window
2>  elapsed time: 1844,1887ms
2>C:\Program Files (x86)\Microsoft\Contracts\MsBuild\v14.0\Microsoft.CodeContracts.targets(265,5): error MSB3073: The command ""C:\Program Files (x86)\Microsoft\Contracts\Bin\ccrewrite.exe"<EMAIL_ADDRESS>exited with code -1.
========== Rebuild All: 1 succeeded, 1 failed, 0 skipped ==========

This new message already has additional information. The error is: Could not resolve type reference....
Some bug fixes with very similar behavior were already fixed.
I'm going to create new beta release tomorrow, so I would ask you to test the same code with latest version of ccrewrite.

Installed v.1.10.10126.2-rc1, the issue still remains:
1>  Reading assembly 'Microsoft.SharePoint.Client.Runtime' from 'C:\...\Microsoft.SharePoint.Client.Runtime.dll' resulted in errors.
1>  	Could not resolve type reference: [mscorlib]System.Runtime.CompilerServices.ExtensionAttribute.
1>  	Could not resolve member reference: System.Runtime.CompilerServices.ExtensionAttribute::.ctor.
1>ccrewrite : error : Rewrite aborted due to metadata errors. Check output window
1>  elapsed time: 3691,3747ms
1>C:\Program Files (x86)\Microsoft\Contracts\MsBuild\v14.0\Microsoft.CodeContracts.targets(265,5): error MSB3073: The command ""C:\Program Files (x86)\Microsoft\Contracts\Bin\ccrewrite.exe"<EMAIL_ADDRESS>exited with code -1.
========== Build: 0 succeeded, 1 failed, 1 up-to-date, 0 skipped ==========


Switching to a lower-latency microphone recording method

The current Unity standard microphone has a delay, so switch to a Native Plugin microphone with lower delay to reduce the delay.


Updated the code to work with ESX_legacy

I've updated the base code on this framework so that the code works with ESX_Legacy as I know there are a few people saying that this is not working etc.. (thought I'd help)

i linked your version on the readme.md


⚠ Bofrost.es has degraded performance

In 54a4f42, Bofrost.es (https://www.bofrost.es) experienced degraded performance:

HTTP code: 200
Response time: 1779 ms

Resolved: Bofrost.es performance has improved in 9f748f3 after 11 minutes.


Simpler search

The default fuzzy search does not work well with search strings, this replaces it with a trivial substring "search".
Also replaced node-sass with sass to make this build properly on node lts.

@corrigancd please try using this branch in kibi-internal's package.json, it should work more precisely than the default fuzzy search.

LGTM:


Updating the version to <IP_ADDRESS> for release.

@jterry75 @jstarks
This also updates the appveyor build number, and cleans up the appveyor build a bit.

Also get project.json

That is far to many places to update the version each time and not miss them. How can we simplify this?

Well, only the appveyor update is strictly necessary since it overwrites the version everywhere else. But for local builds, we don't currently have a mechanism.
If you can get rid of the nuspec and use dotnet pack, that would eliminate one update. And maybe we could have appveyor pull the version prefix from the project.json and just append the build number; that would eliminate another. Unfortunately the psd1 and the nuget version have to remain in sync, though.

(The assembly version doesn't really matter since it's never GACed, but it's nice to have it in sync.)


[Bug]: Modal widget getting hidden in split screen view

Is there an existing issue for this?

[X] I have searched the existing issues

Description
When the user switches from canvas to JS/Query pane and then minimises the window to see split screen, the modal widget is getting hidden by half.
Steps To Reproduce

Goto release.app.appsmith.com
Login with ide-design
Goto any app
Open modal widget in cavas
Switch to JS
Click on the minimize button in the top right corner

Public Sample App
No response
Environment
Release
Issue video log
No response
Version
Appsmith 6b84cfbc

Creating a separate issue since this somehow converted to epic


Ubuntu 22.04 (1.0.0) benchmark released

Heya,
Thank you very much for your work!
Just an FYI in case you weren't aware, it looks like the 22.04 benchmark has been released (1.0.0), unsure if anything needs updating.
Thanks again!

Thank you very much!
The work is sincerely appreciated!


Clean up scheduler job informations when stop

What changes are proposed in this pull request?
Clean up scheduler job information when stop.
And when it start, we use jobMetaStore as the source of truth.
This avoids the job metadata is not consistent when transfer master.
Why are the changes needed?
bug fix
Does this PR introduce any user facing changes?
na

alluxio-bot, merge this please

alluxio-bot, merge this please


Improve 2fa UI on mobile

Ensure long buttons wrap

Wrap table

Looks like this'll need to be rebased now that #6084 is merged, but otherwise LGTM!


vue-cli · [.babelrc] Missing helper: "testing"

Found an issue or bug with electron-vue? Tell me all about it!
Questions regarding how to use electron or vue are likely to be closed as they are not direct issues with this boilerplate. Please seek solutions from official documentation or their respective communities.
Describe the issue / bug.
Receive this message when trying to run vue init simulatedgreg/electron-vue project-name
vue-cli · [.babelrc] Missing helper: "testing"
#
How can I reproduce this problem?
Follow the installation guide and receive the error.
#
If visual, provide a screenshot.
#
Tell me about your development environment.

Node version: v9.1.0
NPM version: 5.5.1
vue-cli version: 2.9.6
Operating System: MacOS HighSierra

If you are looking to suggest an enhancement or feature, then feel free to remove everything above.

Got the same issue more than a year later.
Using MacOS Catalina

Please use vue-cli instead of @vue/cli.
I got this issue while I'm use @vue/cli, but when I remove it and install vue-cli instead, it works.

Please use vue-cli instead of @vue/cli.
I got this issue while I'm use @vue/cli, but when I remove it and install vue-cli instead, it works.

how do？


legacyBackgroundBlur disrupts Compose's recomposition

@iZakirSheikh
Elements in LazyColumn get stretched.
Is there a way to fix the damage caused by legacyBackgroundBlur to Compose?
The image below is a reproduction of the issue using the Toolkit app.

Thanks for reporting.
I am aware of this issue, dont know why this happened. It was working perfectly before, this happened after update compose version of library. I think this is related to the edge effect. It need tests to fix it.
Ideas, fixes are welcome. Anyone interested in fixing this issue can send me the pull request. Currently I am too busy to address this issue.

It was because I guess from version 1.5 compose started using hardware bitmap. I update the library to latest version (current 2.2.4) to fix this issue.


TypeError: Cannot set properties of undefined (setting 'integratePrettier')

Fixed in v1.3.1 - https://github.com/danilovilhena/kickstart-it/pull/27


[experiment] gumbo using a malloc arena

What problem is this PR intended to solve?
I've been staring at performance profiling for HTML5 document parsing and can't get past the whopping 26% of time we're spending in pthread_attr_setschedparam because of the many calls to malloc and free.
Thinking about how we use libgumbo in Nokogiri:

we build a gumbo document structure, allocating many small strings and structures along the way
we convert that into a libxml2 document structure
we free all the memory making up the gumbo data structure, making many calls to free along the way

But: we essentially throw away the gumbo data structure immediately every time. What if we used an ephemeral arena for each gumbo document (or fragment) and just reset the entire arena after use?
This PR is an attempt to see how much time we might save, so it's the simplest thing that could work to let me benchmark:

it allocates a big chunk of memory up front (a real implementation would grow the arena)
it does not support multi-threaded use (for that we'll need to pass the Arena struct around everywhere which will add significant complexity)

The result: a 20% overall improvement on a large (681kb) real-world doc. Juxtaposed with HTML4 timings for context:
# 656 bytes, 8.5% speedup
Comparison:
malloc html4 parse 656:    18760.2 i/s
arena html5 parse 656:    15995.3 i/s - same-ish: difference falls within error
malloc html5 parse 656:    14731.6 i/s - same-ish: difference falls within error

# 70kb, 30% speedup (?)
Comparison:
malloc html4 parse 70095:      360.7 i/s
arena html5 parse 70095:      290.3 i/s - same-ish: difference falls within error
malloc html5 parse 70095:      223.5 i/s - 1.61x  (± 0.00) slower

# 681kb, 20% speedup
Comparison:
malloc html4 parse 681406:       41.5 i/s
arena html5 parse 681406:       31.7 i/s - same-ish: difference falls within error
malloc html5 parse 681406:       26.2 i/s - same-ish: difference falls within error

# 1.9mb, 15% speedup
Comparison:
malloc html4 parse 1929522:       32.8 i/s
arena html5 parse 1929522:       16.0 i/s - 2.05x  (± 0.00) slower
malloc html5 parse 1929522:       13.9 i/s - 2.36x  (± 0.00) slower

Time spent in pthread_attr_setschedparam drops from 26.3% to 18% in the 681kb document benchmark.

@stevecheckoway Do you have any strong feelings about this approach? It feels like it may be worth the additional complexity to try to finish this work up, but don't want to do it if you're horrified. :smile:

I didn't read the commits in detail, but the approach of using an arena allocator makes sense. I'm still confused by the pthread_attr_setschedparam calls though.
Are you sure that's caused by malloc and not the profiling tool getting confused? A cursory glance at glibc's malloc doesn't reveal any direct calls to that function and I can't imagine what thread scheduling would have to do with memory allocation, even in the presence of threads. Not that this matters in the end. If you're getting a real performance improvement, moving to an arena seems reasonable.

@stevecheckoway You may be right about the profiler being confused about the particular function, but the profiler is consistent in saying that children of memory-allocation routines take up a lot of time. Here's the stack profile:

@stevecheckoway I ran the HTML5 parser under cachegrind and did get similar percentages rolled up under malloc-and-friends (but notably the pthread function is not mentioned, that must be a perftools bug).

Here's the top exclusive time functions
I've marked the malloc-related functions with **.

--------------------------------------------------------------------------------
Ir                    file:function
--------------------------------------------------------------------------------
390,423,514 ( 7.83%)  gumbo-parser/utf8.c:read_char [/home/flavorjones/code/oss/nokogiri/lib/nokogiri/nokogiri.so]
366,486,405 ( 7.35%)  ** glibc-2.31/malloc/malloc.c:_int_malloc [/usr/lib/x86_64-linux-gnu/libc-2.31.so]
270,510,622 ( 5.43%)  ** glibc-2.31/malloc/malloc.c:_int_free [/usr/lib/x86_64-linux-gnu/libc-2.31.so]
214,266,390 ( 4.30%)  gumbo-parser/tokenizer.c:gumbo_lex [/home/flavorjones/code/oss/nokogiri/lib/nokogiri/nokogiri.so]
174,424,705 ( 3.50%)  gumbo-parser/string_buffer.c:gumbo_string_buffer_append_codepoint [/home/flavorjones/code/oss/nokogiri/lib/nokogiri/nokogiri.so]
146,082,668 ( 2.93%)  ** glibc-2.31/malloc/malloc.c:malloc [/usr/lib/x86_64-linux-gnu/libc-2.31.so]
141,637,769 ( 2.84%)  gumbo-parser/parser.c:handle_in_body [/home/flavorjones/code/oss/nokogiri/lib/nokogiri/nokogiri.so]
137,864,597 ( 2.77%)  gumbo-parser/parser.c:gumbo_parse_with_options [/home/flavorjones/code/oss/nokogiri/lib/nokogiri/nokogiri.so]
125,220,415 ( 2.51%)  ruby-3.1.2/parse.c:ruby_yyparse [/home/flavorjones/.rbenv/versions/3.1.2/lib/libruby.so.3.1.2]
115,254,958 ( 2.31%)  gumbo-parser/utf8.c:utf8iterator_next [/home/flavorjones/code/oss/nokogiri/lib/nokogiri/nokogiri.so]
 90,970,620 ( 1.83%)  gumbo-parser/tokenizer.c:handle_attr_value_double_quoted_state [/home/flavorjones/code/oss/nokogiri/lib/nokogiri/nokogiri.so]
 81,276,039 ( 1.63%)  gumbo-parser/parser.c:reconstruct_active_formatting_elements [/home/flavorjones/code/oss/nokogiri/lib/nokogiri/nokogiri.so]
 80,979,775 ( 1.62%)  ** glibc-2.31/malloc/malloc.c:malloc_consolidate [/usr/lib/x86_64-linux-gnu/libc-2.31.so]
 79,724,502 ( 1.60%)  gumbo-parser/utf8.h:read_char
 70,040,521 ( 1.41%)  ** glibc-2.31/malloc/malloc.c:free [/usr/lib/x86_64-linux-gnu/libc-2.31.so]
 64,521,678 ( 1.29%)  gumbo-parser/tokenizer.c:finish_token.isra.0 [/home/flavorjones/code/oss/nokogiri/lib/nokogiri/nokogiri.so]
 63,285,175 ( 1.27%)  ruby-3.1.2/parse.y:ruby_yyparse
 53,476,387 ( 1.07%)  ruby-3.1.2/gc.c:objspace_xmalloc0 [/home/flavorjones/.rbenv/versions/3.1.2/lib/libruby.so.3.1.2]
 53,351,571 ( 1.07%)  gumbo-parser/parser.c:get_current_node.isra.0 [/home/flavorjones/code/oss/nokogiri/lib/nokogiri/nokogiri.so]
 48,078,332 ( 0.96%)  ruby-3.1.2/gc.c:ruby_sized_xfree [/home/flavorjones/.rbenv/versions/3.1.2/lib/libruby.so.3.1.2]
 47,606,972 ( 0.96%)  ** glibc-2.31/malloc/malloc.c:malloc_usable_size [/usr/lib/x86_64-linux-gnu/libc-2.31.so]
 44,631,418 ( 0.90%)  gumbo-parser/string_buffer.c:maybe_resize_string_buffer [/home/flavorjones/code/oss/nokogiri/lib/nokogiri/nokogiri.so]
 43,778,475 ( 0.88%)  gumbo-parser/parser.c:insert_text_token.isra.0 [/home/flavorjones/code/oss/nokogiri/lib/nokogiri/nokogiri.so]
 42,218,715 ( 0.85%)  ruby-3.1.2/st.c:find_table_entry_ind [/home/flavorjones/.rbenv/versions/3.1.2/lib/libruby.so.3.1.2]
 42,189,298 ( 0.85%)  ** glibc-2.31/malloc/malloc.c:unlink_chunk.isra.0 [/usr/lib/x86_64-linux-gnu/libc-2.31.so]
 41,857,797 ( 0.84%)  ruby-3.1.2/st.c:rb_st_lookup [/home/flavorjones/.rbenv/versions/3.1.2/lib/libruby.so.3.1.2]
 41,302,563 ( 0.83%)  ruby-3.1.2/gc.c:rgengc_check_relation.part.0 [/home/flavorjones/.rbenv/versions/3.1.2/lib/libruby.so.3.1.2]
 40,823,473 ( 0.82%)  ruby-3.1.2/gc.c:gc_mark_ptr [/home/flavorjones/.rbenv/versions/3.1.2/lib/libruby.so.3.1.2]
 40,756,430 ( 0.82%)  gumbo-parser/tokenizer.c:append_char_to_tag_buffer [/home/flavorjones/code/oss/nokogiri/lib/nokogiri/nokogiri.so]
 37,432,874 ( 0.75%)  ** glibc-2.31/malloc/malloc.c:realloc [/usr/lib/x86_64-linux-gnu/libc-2.31.so]
 36,069,384 ( 0.72%)  gumbo-parser/tokenizer.c:emit_char [/home/flavorjones/code/oss/nokogiri/lib/nokogiri/nokogiri.so]
 32,630,299 ( 0.65%)  gumbo-parser/tokenizer.c:handle_data_state [/home/flavorjones/code/oss/nokogiri/lib/nokogiri/nokogiri.so]
 28,598,943 ( 0.57%)  ** glibc-2.31/malloc/malloc.c:_int_realloc [/usr/lib/x86_64-linux-gnu/libc-2.31.so]
 28,511,268 ( 0.57%)  tmp/x86_64-linux/nokogiri/3.2.1/tmp/x86_64-pc-linux/ports/libxml2/2.10.3/libxml2-2.10.3/xmlstring.c:xmlStrdup [/home/flavorjones/code/oss/nokogiri/lib/nokogiri/nokogiri.so]
 27,633,613 ( 0.55%)  ruby-3.1.2/compile.c:iseq_setup [/home/flavorjones/.rbenv/versions/3.1.2/lib/libruby.so.3.1.2]
 25,140,201 ( 0.50%)  ** glibc-2.31/string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:__memcpy_avx_unaligned_erms [/usr/lib/x86_64-linux-gnu/libc-2.31.so]

Great! I'm glad there's not some bizarre pthread call happening somewhere.
As I mentioned, using an arena allocator makes a lot of sense here.
Another possibility would be to try to directly produce an xmlDoc from gumbo's parser. On the one hand, that'd be a bit of a shame for gumbo since it'd be tied down to libxml. On the other, cutting out all of those allocations (plus the whole additional tree walk) is probably a big win.


Add ThankU

https://www.thanku.social

Thanks for your submission!
BTW. The better option would have been to rebase onto master. That keeps the git history clean.

Thanks for your submission!
BTW. The better option would have been to rebase onto master. That keeps the git history clean.

I quickly resolved the conflict directly on GitHub. Thanks for merging it anyway.


sysctl: error setting key 'vm.max_map_count': Read-only file system

When I try to start elasticsearch-kibana only kibana pod is running and elasticsearch goes in Init Crash Loop Back-off.
I read the pod logs
kubectl logs elasticsearch-7fc6f9b9bb-8ffgg --all-containers=true
and this is the content
sysctl: error setting key 'vm.max_map_count': Read-only file system Error from server (BadRequest): container "elasticsearch" in pod "elasticsearch-7fc6f9b9bb-8ffgg" is waiting to start: PodInitializing
Any idea?
thx

looks like elastic search related, did you try to resolve following this solution: https://github.com/spujadas/elk-docker/issues/99

Hi sp1d3rino,
Can you please try to add the block below to your elk yaml file?
   spec:
  initContainers:
  - name: set-vm-max-map-count
    image: busybox
    imagePullPolicy: IfNotPresent
    command: ['sysctl', '-w', 'vm.max_map_count=262144']
    securityContext:
      privileged: true
  containers:
  - name: "elasticsearch"
  .....

@hzhao-github, I believe that @sp1d3rino needs to make these changes on the host machines.  This initContainer will make the change in that container and then exit without persisting the changes to host machine configuration.

@rjeberhard sure, based on @sp1d3rino, either way should work

@hzhao-github  the code block is already present in the elk yaml.

@sp1d3rino and it still not working?

Have you tried the solution  Marina found, https://github.com/spujadas/elk-docker/issues/99?

@hzhao-github yes I just tried also to set vm.max_map_count=262144 on the hosting OS but it doen't work yet

@sp1d3rino I didn't do it on machine, but from the config in the container, "command: ['sysctl', '-w', 'vm.max_map_count=262144']", try giving a write permission when setting it

@hzhao-github how to give write permission?
I needed to change this
securityContext:
          privileged: true

setting to false because I get this
Error creating: pods "elasticsearch-6f4d6b7b4c-" is forbidden: unable to validate against any security context constraint: [spec.initContainers[0].securityContext.privileged: Invalid value: true: Privileged containers are not allowed]

@sp1d3rino do you need to make changes on the host machines or in the container?

@hzhao-github In the container. but as I notice at the beginning of this thread this seems not possible due to read only file system error...

I solved.

from the host I ran
sudo sysctl -w vm.max_map_count=262144

from the elk yaml I removed this line
decommand: ['sysctl', '-w', 'vm.max_map_count=262144']
and I put privileged: false

deleted the elasticsearch deployment and applied one more time.

I am on macOS and i cant do sudo sysctl -w vm.max_map_count=262144,
even the solution on docker on mac here is not working for me (says tty file not found)
I am running on docker engine v19.03.13 and Catalina 10.15.7 if anyone could help

I solved.

from the host I ran
sudo sysctl -w vm.max_map_count=262144
from the elk yaml I removed this line
decommand: ['sysctl', '-w', 'vm.max_map_count=262144']
and I put privileged: false

deleted the elasticsearch deployment and applied one more time.

Thanks for help!

"max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]" am facing this issue in windows 10 ,
is that elassandra is working in windows 10 perfectly ??????

facing same issue in GKE auto-pilot mode
max virtual memory areas vm.max_map_count [65530] likely too low, increase to at least [262144]
[2021-03-04T14:27:36,294][INFO ][o.e.n.Node               ] [VNeWui4] stopping ...
[2021-03-04T14:27:36,317][INFO ][o.e.n.Node               ] [VNeWui4] stopped
[2021-03-04T14:27:36,317][INFO ][o.e.n.Node               ] [VNeWui4] closing ...
[2021-03-04T14:27:36,382][INFO ][o.e.n.Node               ] [VNeWui4] closed


Responsive banner

Closes https://github.com/ethyca/fides/issues/3444
Code Changes

[x] Add breakpoints for banner width and borders at different sizes
[x] Slightly edit the banner DOM to have a "container" element so that it's easy to center the banner when it isn't full width

Steps to Confirm

Spin up the privacy center and visit localhost:3000/fides-js-demo.html and resize your browser

Pre-Merge Checklist

[ ] All CI Pipelines Succeeded
Documentation:

[ ] documentation complete, PR opened in fidesdocs
[ ] documentation issue created in fidesdocs

[ ] Issue Requirements are Met
[ ] Relevant Follow-Up Issues Created
[ ] Update CHANGELOG.md
[ ] For API changes, the Postman collection has been updated

Description Of Changes
https://github.com/ethyca/fides/assets/24641006/f25e157a-f819-478f-b192-af28fc818c55

Oh, nice! The designs for this actually show that, when not full-width, there should be some spacing between the bottom of the page and the banner. Mockups vary between 51px and 66px which is confusing but we could pick 48px and use that?

Oh, nice! The designs for this actually show that, when not full-width, there should be some spacing between the bottom of the page and the banner. Mockups vary between 51px and 66px which is confusing but we could pick 48px and use that?

whoops good catch, didn't notice that!

Added 48px spacing between bottom and the banner:
https://github.com/ethyca/fides/assets/24641006/394de60d-d7fe-4232-b86a-bd453e942c2a


Change behaviour of get_data plugin RPC

Working around the plugin lib right now, and have some thoughts about this API.

get_data should allow chunk position to be specified as an offset or a line number; because plugin clients are generally going to be line oriented, I think this would simplify things on the client side with very little cost. Where a line number is used, it would be converted to an offset internally. We would not guarantee that whole lines are returned.

Augment return value with line info: get_data should return line information in addition to a chunk of the document. In particular, it should return the offset of the chunk, the position in the chunk of newlines (as an array of offsets) and the line number of the first newline in the chunk. It might also be useful to include the number of newlines that exist after the chunk, or the total number of lines in the document, which are informationally equivalent.

Making this change would go along way to simplifying writing a plugin library.
Earlier, I had been imaging augmenting plugin updates to include, with deltas, the number of newlines in any deleted regions. This is only useful when deletions occur outside of the plugin's cache, though; and it might be simpler in that case to just blow away the cache, and know that the next get_data request will include the correct line info? This would only be bad in some use case where a plugin was primarily working in one part of a (very) large document, and deletions were occurring frequently in another part of the document, which seems like maybe not a case we need to be too defensive about.
@raphlinus does this make sense?

First point sounds good. I am definitely swayed by the argument of having one round-trip rather than having two separate ones for resolving line number to offset and then getting the data.
Second point I'm partly convinced. Returning both line number and offset of the returned chunk sounds great, no problem (this is consistent with the way RopeInfo is implemented). Adding data for newlines within the chunk does not sound great to me - it seems likely to me that the cost of serializing, sending, and deserializing this info is more than finding the newlines on the plugin side.
And, for total number of lines in the document, it feels like this should be sent in delta rather than get_data. That way, we avoid states where we have partial information about the number of lines (ie not konwing whether a reference to a particular line is valid). I'd lean toward sending absolute line count, it feels less stateful.
Absolutely agree with the goal of simplification and not trying to optimize for the validity of line number to offset correspondence in the face of large document changes. As you point out, the cache in those cases is probably lukewarm at best.

Okay, good point. As long as we know what the starting line in a chunk is, finding the rest of the offsets is trivial.
Implementation plan:

get_data has fields { offset: Option<usize>, line: Option<usize>, rev: usize, max_size: usize }

get_data returns {chunk: String, offset: usize, first_line: usize, first_line_offset: usize }, where offset is the byte offset of the chunk, first_line is the line number of the line containing the start of the chunk, and first_line_offset is the offset of the chunk from the start of first_line.

update will now include num_lines in addition to delta, buf_size, rev.

This should give us enough to significantly simplify the implementation of a plugin lib. It also lets us remove the get_num_lines plugin -> core RPC request.

Sounds good. I think the double-Option pattern is ok, but it would be nicer to express a true sum type. To spitball an alternative, how about start: usize and units: Enum(utf8, line)? Part of that thinking is that other units, such as utf16 or codepoint, would become possible.

I like that, will update my earlier comment.

For what it’s worth this is where CapNproto is supposed to shine.  The perf
optimization of rolling everything into 1 RPC to reduce round trips is
orthogonal to composable fundamental APIs that require multiple RPCs:
capnproto transforms this so you can reference prior results without
waiting for the result.  Not 100% as efficient as rolling into 1 API but
still roughly 1 round trip latency even though you may have made multiple
RPC calls.  So for now I agree this is the right move but at some point we
should put some thought into going back to composable RPC calls if we
switch to capnproto or just adopt the time travel mechanism to JSON.
On Mon, Mar 19, 2018 at 11:06 AM Colin Rofls<EMAIL_ADDRESS>wrote:

I like that, will update my earlier comment.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/google/xi-editor/issues/562#issuecomment-374310450,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAMSRwE8oMJwU6fW9D8sEePZrv9dssMrks5tf_OpgaJpZM4SwVJM
.

@vlovich Interesting - I had looked at Cap'n Proto and would still consider it.
Here I think there are two overlapping concerns. One is efficiency, primarily measured as reducing the number of roundtrips to service a request from the plug-in. The other is trying to define access to the document state in the simplest possible way. If you weren't at all concerned about RPC efficiency, it would make sense to break that down into orthogonal primitives - some calls to translate between line and byte offset, other calls (denumerated in bytes) to get access to the data. But I think @cmyr's proposal is a good compromise - given that the one of the primary plugin-side tasks is "get data for line", being able to ask that directly compares favorably to having two separate calls, and the proposal also avoids the need for fiddly tracking of line number info across deltas.

Yup.  I’m 100% agreeing that this is currently the most reasonable
solution.  CapNproto doesn’t yet have swift bindings and it’s unclear when
it will get it so I wouldn’t press for it unless we don’t need it in swift
(maybe we can hide it in xilib?)
I might dig into the how of the time travel works (I’m mainly unclear how
the server knows when to discard the result it computed - I’m hoping Kenton
had some interesting insights here ).
Maybe it’s possible to adapt to jsonrpc in some way to add promise
pipelining. It won’t be as good as capnproto though because it’s free to
deserialize whereas there’s a large non0 cost to deserialize Json which we
won’t be able to completely recover if we have a lot of primitives; so the
question will be having to measure if the cost is negligible enough .
Using grpc + FlatBuffer + adding promise pipelining to grpc might be
another option.  I’ve heard mixed online stuff about grpc performance but
it’s unclear to me if that’s a consequence of protobuf being the
serialization layer or if there’s additional overhead within grpc itself.
On Tue, Mar 20, 2018 at 11:19 AM Raph Levien<EMAIL_ADDRESS>wrote:

@vlovich https://github.com/vlovich Interesting - I had looked at Cap'n
Proto and would still consider it.
Here I think there are two overlapping concerns. One is efficiency,
primarily measured as reducing the number of roundtrips to service a
request from the plug-in. The other is trying to define access to the
document state in the simplest possible way. If you weren't at all
concerned about RPC efficiency, it would make sense to break that down into
orthogonal primitives - some calls to translate between line and byte
offset, other calls (denumerated in bytes) to get access to the data. But I
think @cmyr https://github.com/cmyr's proposal is a good compromise -
given that the one of the primary plugin-side tasks is "get data for line",
being able to ask that directly compares favorably to having two separate
calls, and the proposal also avoids the need for fiddly tracking of line
number info across deltas.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/google/xi-editor/issues/562#issuecomment-374704462,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAMSR-LGZIC1t7M80TC6dO7GJDeG3Ajeks5tgUg-gaJpZM4SwVJM
.

I'm also curious about the time travel stuff, but it seems like implementation would be tricky. I can see how that would be a clear win when there's a network involved, but given that we're dealing with much smaller latencies and also that we have the flexibility to evolve our protocol to suit our needs, I'm not sure it would be solving a problem we have, right now? Open to having my mind changed, though.
I'm trying to think of other places where we regularly perform some RPC and then immediately perform another with the result, and I can't really think of any (although I can think of some that could exist around vim-mode).


WIP master <- develop

Merge the develop branch into the master branch and deploy

Build log
Preview build with this PR (d67cc4731fc2a05bc09f11b0f3e80d31d73c9c41)

more info:cloud: Storage Free space   6.00 GiB    40.03%:open_file_folder: 148.29 MiB  CI_WORK/GitHubActions/roki-web


Added initial connection middleware pipeline

Implemented IConnectionBuilder on ListenOptions. Kept IConnectionAdapter for now.
Delay the configure callback for ListenOptions until the server has started.
Added ConnectionLimitMiddleware and HttpConnectionMiddleware
Expose ConnectionAborted and ConnectionClosed on ConnectionContext and IConnectionTransportFeature
Updated the tests

Progress on #1980
Fixes #1772

🆙 📅


Unable to Switch Channels while in LiveTV

Changing the values for channel does not change the current channel.
Current WebOS: 2.2.0-15505 (beehive-biscayne)
TV: LG 55LF652V

Same here, only can't change the channel on:
TV: LG 60UF7709-ZL
WebOS: 2.2.1-134101
I have two lg tvs with webos. The Problem occurse only on this one.

testet channel up and down from version 1.0.4, both works, thx. don't know what lg changes in there last firmware update for my tv, i'm realy sure channel object works before the last update in december 2017 (04.25.56). Maybe this helps you finding the reason... :)
LG 60 UF 7709, WebOS 2

Can you please reinstall the adapter here from github?
I've added a new object named "channelid".
Can you please test the following:
1.) Reinstall the adapter here from Github, configure and start it
2.) Wait till the Poll intervall expires then the should be values in the objects "channel" and "channelId"
3.) notice the value in "channelId"
4.) now change at the TV (!!!) to another channel
5.) now enter the under pooint 3 noticed value into the object "channel"
Is  there something happen?!

I can see the channel ID but unfortunately it does not change the channel when entered in the channel object.

**So, test is done. Tested a little bit with both TVs (WebOS 1.0 and WebOS 2.0)
Problem TV (WebOS 2.0):

Reinstalled the LG-TV Adapter -> ChannelID and Channel are shown.
Noticed Channel: 5 + ID: 3_12_5_5_321_32102_9999
Changed to Channel 6 on TV (Channel: 6 || ID: 3_13_6_6_331_33103_9999 shown in objects)
Entered Channel from point 2 in object "channel" -> nothing happended, after next refresh it changed back to Channel from 3.**

Debug Log:

_lgtv.2
2018-04-10 10:20:17.085
debug
Sending switch to channel 3_12_5_5_321_32102_9999 command to WebOS TV: <IP_ADDRESS>

lgtv.2
2018-04-10 10:20:15.304
debug
Current Input and/or App: com.webos.app.livetv

lgtv.2
2018-04-10 10:20:15.304
debug
pollVolumeLevel: {"returnValue":true,"scenario":"mastervolume_ext_speaker_optical","volume":-1,"muted":false}

lgtv.2
2018-04-10 10:20:15.288
debug
DEBUGGING CHANNEL POLLING PROBLEM:  {"channelId":"3_43_2_2_1079_11110_102","signalChannelId":"1079_11110_102","channelModeId":1,"channelModeName":"Cable","channelTypeId":4,"channelTypeName":"Cable  Dig_

**WebOS 1.0:

Reinstalled the LG-TV Adapter -> ChannelID and Channel are shown.
Noticed Channel: 305 + ID: 3_37_305_305_161_12103_9999
Changed to Channel 306 on TV (Channel: 306 || ID: 3_37_306_306_161_12104_9999 shown in objects)
Entered Channel from point 2 in object "channel" -> nothing happended, after next refresh it changed back to Channel from 3.

Found something out on this tv, don't know if this has something to do with the first problem:
5. Type 305 in "channel" -> channel changed to 305 and also on tv
6. Type 5 in "channel" -> channel changed to 5 || ID: 2_6_5_0_0_524_0 (Analog TV?)
7. Changed to channel 5 on TV -> TV changed to Digital TV channel 5 (ID: 3_21_5_5_321_32102_9999)
Every number lower 100 changes the tv to analog channels... Analog is already disabled in germany, so i'll get a white screen.**

Debug Log:

_lgtv.3
2018-04-10 10:24:59.290
debug
Sending switch to channel 3_37_305_305_161_12103_9999 command to WebOS TV: <IP_ADDRESS>

lgtv.3
2018-04-10 10:24:57.305
debug
DEBUGGING CHANNEL POLLING PROBLEM:  {"channelId":"3_37_305_305_161_12103_9999","signalChannelId":"161_12103_9999","channelModeId":1,"channelModeName":"Cable","channelTypeId":4,"channelTypeName":"Cable

lgtv.3
2018-04-10 10:24:57.305
debug
Current Input and/or App: com.webos.app.livetv

lgtv.3
2018-04-10 10:37:46.784
debug
Connecting to WebOS TV: ws://<IP_ADDRESS>:3000

lgtv.3
2018-04-10 10:37:46.784
debug
Sending switch to channel 5 command to WebOS TV: <IP_ADDRESS>

lgtv.3
2018-04-10 10:37:42.799
debug
Current Input and/or App: com.webos.app.livetv

lgtv.3
2018-04-10 10:37:42.784
debug
pollVolumeLevel: {"returnValue":true,"scenario":"mastervolume_ext_speaker_arc","volume":0,"muted":false}

lgtv.3
2018-04-10 10:37:42.768
debug
DEBUGGING CHANNEL POLLING PROBLEM:  {"channelId":"3_37_305_305_161_12103_9999","signalChannelId":"161_12103_9999","channelModeId":1,"channelModeNa_

Hi,
same Problem as above also for me. I have been working with older version of WebOS. And I have found, that after new installation of LGTV there is no write allowed in the channel object.
Will you be fixing that?
Greetings
Matthias

Hi Sebastian,
I did a new Install directly from your Git Project URL, and the object is now writable.
Sorry for having the delay.

But even after new install that same problem. When channel_id is changed, nothing happens

I'm sorry but this might be a WebOS issue. On my webOS 1.0 TV it works fine. :(
And I didn't found any changes in the webOS SDK command set for changing channel.


Allow the supervised base class to accept external test dataset

Feature Description
In supervised.py:
fit(self, x_train=None, y_train=None, time_limit=None):
to
fit(self, x_train=None, y_train=None, x_test=None, y_test=None, time_limit=None):
And then update the implemented task modules to use the test subset (if provided) instead of splitting the train.
Reason
In some cases the automatic split of 80:20 (in the case of ImageSupervised) is not good enough and the model has to be evaluated on a specific subset which is already available.
Solution
I can submit a pull request if you consider this as a needed feature. I'd argue that it doesn't increase the complexity of using the project in its simplest form since the old automatic splitting is also preserved.
Alternative Solutions
Leave it as it is.

Hi @Zvezdin,
Thanks for the idea. It's indeed needed for maximum flexibility. However, we're trying to refactor the whole structure now, so we may have to wait a little bit.


Result from macro is coerced into token while it should be a list node

Repro:
(defmacro let+ [local-name binding & body]
  `(let [~local-name ~binding]
     ~@body))

(require '[rewrite-clj.node :as node])

(node/coerce (macroexpand '(let+ y 1 (+ 1 2 y))))
<token: (let* [y 1] (+ 1 2 y))>

I'll make a PR to fix it.

Fixed by f395a23735cf92fae7f3f8802e98b36839066ae8


Add test to enforce expected result levels

Changes
Created test to reproduce bug observed in feature testing, where the FailureLevel for static analysis results was overridden to always return FailureLevel.Note unless dynamic analysis was also completed.
Removed the single line causing this bug and observed the new test passed with expected SARIF results generated.
This is a breaking change because it is likely to result in new findings, as demonstrated by the need to rebaseline.

[x] ReleaseHistory.md updated for non-trivial changes
[x] Added unit tests

There is a significant amount of churn with this PR. Key changes have been highlighted with comments. A number of sarif files were rebaselined and at least one unit test required updating to account for a change from "note" for static analysis only to the default level found in the corresponding json.

          " (no validation occurred as it was not enabled. Pass '--dynamic-validation' on the command-line to validate this match)",

Something looks wrong here. This message appears to indicate there is a dynamic validator available but it wasn't enabled. This case should never return an 'error', that case should return a 'warning'. ?

Refers to: Src/Plugins/Tests.AzureDevOpsConfiguration/TestData/ServiceConnectionSecurity/ExpectedOutputs/AZC102_190.serviceconnection.DoNotShareWithAllPipelines.sarif:59 in 0ba90a7. [](commit_id = 0ba90a73dfc00af3d4f2b60b0a6dc9d99f8de955, deletion_comment = False)

          " (no validation occurred as it was not enabled. Pass '--dynamic-validation' on the command-line to validate this match)",

This matches the configuration in the AZC102.ServiceConnectionSecurity.json:
"Id": "AZC102",
"Name": "ServiceConnectionShouldBeSecure",
"Level": "Error",

In reply to:<PHONE_NUMBER>

Refers to: Src/Plugins/Tests.AzureDevOpsConfiguration/TestData/ServiceConnectionSecurity/ExpectedOutputs/AZC102_190.serviceconnection.DoNotShareWithAllPipelines.sarif:59 in 0ba90a7. [](commit_id = 0ba90a73dfc00af3d4f2b60b0a6dc9d99f8de955, deletion_comment = False)

                        validatorMessage += " " + DynamicValidationNotEnabled;

In this code path, I believe you need to set the failure level explicitly to 'Warning'. If I'm correct, that raises the question, why didn't your test uncover this problem?

test gap?
matrix not correct?
@michaelcfanning is wrong in his analysis.

Refers to: Src/Sarif.PatternMatcher/SearchSkimmer.cs:377 in 0ba90a7. [](commit_id = 0ba90a73dfc00af3d4f2b60b0a6dc9d99f8de955, deletion_comment = False)

          " (no validation occurred as it was not enabled. Pass '--dynamic-validation' on the command-line to validate this match)",

There is a dynamic validator for this class.

In reply to:<PHONE_NUMBER>

Refers to: Src/Plugins/Tests.AzureDevOpsConfiguration/TestData/ServiceConnectionSecurity/ExpectedOutputs/AZC102_190.serviceconnection.DoNotShareWithAllPipelines.sarif:59 in 0ba90a7. [](commit_id = 0ba90a73dfc00af3d4f2b60b0a6dc9d99f8de955, deletion_comment = False)

                        validatorMessage += " " + DynamicValidationNotEnabled;

test gap

In reply to:<PHONE_NUMBER>

Refers to: Src/Sarif.PatternMatcher/SearchSkimmer.cs:377 in 0ba90a7. [](commit_id = 0ba90a73dfc00af3d4f2b60b0a6dc9d99f8de955, deletion_comment = False)


BAU Fix stripe account success template business name

The Stripe account API was updated over a number of major version
numbers. JS references were updated to the new format, update this
template reference to the Stripe account object.
Reference https://github.com/alphagov/pay-toolbox/pull/1255

Superseded by https://github.com/alphagov/pay-toolbox/pull/1261


Stop app from closing when user uses back button.

When the user uses the phone's back button the app closes. Is there a way to using fragments backstack, or another way to handle the onBackPressed logic.

Isn't this standard behaviour? Trying a few other apps and they all do it. Unless I misunderstand your question?

Sorry for not clarifying, since I thought that pressing the back button in certain fragments like the tutorials will lead back to tutorialsHome, or home page etc., instead of closing the app straight away.

Ah yes ok I see what you mean!
Yes I do think there should be a way to customize that behaviour. I'm not actually sure how off the top of my head, but we should definitely keep this issue open. If you're interested in it feel free to look into it! No pressure. Otherwise we can also just keep it open to have it in mind for later.


Dash in snippets prefix broken

Since the May or the June release, the snippets containing a dash (-) inside cannot be used when fully typed.

VSCode Version: 1.25.0
OS Version: MacOS 10.13.5

Steps to Reproduce:

Create a user snippet with a prefix containing a dash (-) inside
Try to use it
(Define "editor.snippetSuggestions": "top" in your settings to show it on top)

Nice find @Yago. This is a regression from #37166 - we now re-compute snippets when a trigger character is hit and in css, dash (-) seems to be such a character. The issue is that in the presence of a trigger character selecting snippets is more strict.

Ok nice to know. Happy to help 😄

Ok, I have pushed a bigger change is how snippets are computed. That change fixes this issue and should make snippet suggestions be more stable in general. Tho, there might be some oversights and I would really appreciate more feedback. You can try my fix and change with next insiders (in ~24hr from now): https://code.visualstudio.com/insiders/


Update in Merkle Trees

We are working on a project in which we need Merkle tree leaves to be updatable (which should propagate to the root and update the root hash). Is there support for such updates in the hacl-star implementation?
Can flush and retract functions be used to achieve this? I checked out the documentation but their use-cases were not clear to me.

My understanding is that you can remove nodes from the beginning of the tree but not at arbitrary positions. Maybe @wintersteiger or @fournet could confirm.

Thanks for the response @msprotz! We are currently updating a node by

Retracting the tree to the point before the target node is added,
Updating the target node,
Inserting previously removed nodes to the tree.

Unfortunately, this is hacky and more importantly not optimal. It would be nice to have this feature in future releases.
Please let me know if I need to do anything else to suggest this feature to the developers (and possibly help with development).

Sorry for having missed this issue before. Your use of retraction is as expected; flushing is used to remove the left side of the tree, e.g. in blockchain applications you may not need to remember the entire tree, but only recent parts.
You're right, updating arbitrary nodes is not currently supported. I think that, as long as the updated nodes fit into the same memory, it shouldn't be too hard to proof preservation of the invariants. I'm not sure I'll have enough time to actually implement it anytime soon though.

We had some plans to compress the past in the tree up to a point, maybe we could use flush for that then. Thanks @wintersteiger !
We are using the hash values in the nodes -- if I understand correctly -- updates should not change the size of the nodes.
We are using the Merkle tree in another project as well -- which also requires updates. I think updates would be a nice feature to have. Static nodes seems to be a good fit for blockchain type of applications, but I believe there are many applications who would need dynamic nodes.


Add temperature and depth to most probable track

We can add timestamps on temperature and depth data from a csv file for each track.
We could make this an attribute on the points of the geojson we create for the most probable track, this should probably be integrated in the simplification script
We can draw inspiration from an example notebook  that pulls from this csv file.

Closing as its a duplicate of #86


Conda.jl use an already installed version of mini/ana-conda

I already have conda as my default python, will Conda.jl find this? If not, could it?
Either way it would be great to mention this in the documentation/README.
Perhaps also useful would be the example of how to install ipython/pycall.

Conda.jl will not find it, and I do not think it should. This package is not made for an alternative Python installation, but rather to be used by other julia packages as a dependency provider. It happens to use conda internally, but this is only an implementation detail.

Either way it would be great to mention this in the documentation/README.

Perhaps also useful would be the example of how to install ipython/pycall.

Why not. PyCall can not be installed with Conda.jl, but iPython can, and IJulia will use it. See JuliaLang/IJulia.jl#357

Thanks, that would be great!

This package is not made for an alternative Python installation, but rather to be used by other julia packages as a dependency provider.

One thing I've found frustrating in the past is having multiple python/conda installations kicking around. If I pip/conda install something, I might be confused if it's unavailable from julia... Although this would also be the case if Conda.jl used an environment in my ~/.miniconda install.... So maybe I haven't quite yet understood how this fits...

PyCall can now be installed with Conda.jl, and also PyPlot.

PyCall can now be installed with Conda.jl, and also PyPlot.

What I meant is that you will never run Conda.add("PyPlot"), but uses Pkg.add("PyPlot"). Then, internally, PyPlot can (and do now) uses Conda to get its own dependencies.

Closing this, feel free to reopen if you still have questions.

I don't think this is mentioned in the README (yet).
Specifically IIUC suppose I already have a miniconda installation (say at ~/anaconda), Conda.jl downloads another version of miniconda and install ipython/whatever into a single conda environment (the default)?
The original issue was whether this could happen as a special conda environment in ~/anaconda.

I don't think this is mentioned in the README (yet).

Yes, I forgot this part.
For conda environments, also see #19.

It's still unclear why using system conda if available (using a "_jlconda" or similarly named environment to install/use), would be a bad idea. Note: this is different from the system python, I'm not suggesting that.
I can see how it is easier that Conda.jl has complete ownership over it's own miniconda installation but it seems to me like there is a lot of unnecessary duplication in doing so.

Having our own private miniconda installation gives us much more reliable installation of dependencies.   If we use the user's conda installation, they could have mucked it up in almost any conceivable way.  This is the whole point of Conda.
If you want to use your own Anaconda installation, the right place to do it is in the packages that use Conda.   For example, IJulia, PyCall (and PyPlot, and SymPy) only use Conda if they don't find a working jupyter or python executable already installed, and both allow you choose a specific jupyter or python on your system via environment variables.   If you do that, then the Conda package may never install miniconda at all (unless Conda.add is called by some other package).

user's conda installation, they could have mucked it up in almost any conceivable way.

I thought the whole point of using/creating an environment is they can't.

If the separate conda environment uses its own Python and its own set of packages, then there's not much advantage over just doing a private miniconda installation.  Any shared resource could be mucked up by the user.  Even their conda program itself might be out of date.

(Never underestimate the ability of users to creatively muck up their system. :wink:)

Even their conda program itself might be out of date.

The conda program automatically update itself at every package installation.

I thought the whole point of using/creating an environment is they can't.

I do not think we can lock an environment using Conda, and I do no know what happen if __jlconda uses libfoo==4.3.5 and the root environment uses libfoo==6.9.3.

You can't lock it, but nor can you stop a user from mucking about with the current miniconda installed by Conda.jl.

I do no know what happen if __jlconda uses libfoo==4.3.5 and the root environment uses libfoo==6.9.3.

That's what conda environments are for!

I very strongly concur with @stevengj on this: this package should leave any existing conda install entirely alone and just operate on the private miniconda install.  As a user I would be VERY annoyed if a Pkg.add("ExcelReaders") messed around with my existing conda setup in any way, depended on that or anything else. Much cleaner if this is kept completely separate.

I think that there may be some misunderstanding about conda environments, nevertheless the consensus seems to be not to do this.

As a user, I wouldn't want Pkg.add("ExcelReaders") to add an environment to conda. This is just weird for users: something about Excel files adds something to their conda environment list, why? Plus, conda environments have the notion of an active environment, and again, I wouldn't want some random julia pacakge to change what is the current active environment.

This could be nice to have as an opt-in behaviour (the default being using the private local conda installation), but I do not see much use cases for it. The only one I can think of is for users with a quota on the number of files/the size of there /home directory, and with a pre-existing conda installation. Any other uses cases worth the work of making this work together with the current implementation?


Added tests and lowercased enums

Added test and lowercased enums
https://bugs.swift.org/browse/SR-1187

@mattt Do you have an opinion on extending these repos by adding tests? I would rather not invest very much time in the maintenance of them, but tests are also a best practice.

@ddunbar Because this is code used in a tutorial, the only thing that really matters is that the example works as intended. I think it'd only really make sense to add tests if 1) automated testing were something covered by the tutorial and 2) all packages in the example were tested. If you're interested in expanding the scope of the tutorial, I'd be happy to coordinate with you.

There are patches for tests for all packages, and expanding the tutorial to cover this would probably make sense. I'll go ahead and plan to iterate and merge these and we can figure out how/when to update the tutorial.

The lesson here is: keep PRs focussed, since we can't merge the lowercase enums until the stuff Daniel wants is done.

@mxcl noted. I am happy to change those back to upper case and/or help update the tutorial.


Using setcookie headers

Hello! Your app is very helpful for developers and very good looking!
What do you think about set cookies from response?
For example, I try authenticate to my service and in response I get headers with set cookies which contains my token. And after I could to request any data for me as authenticating user.
Thanks

Hi @iamsimakov thanks for using the app and providing the feedback!
Will the authentication token you receive in the response be attached to later requests as a header or a cookie?
I have a list of improvements I would like to make to the app and one of them is to add the ability in the settings to add a list of common key/value pairs often used in requests so that you can quickly load them in on later requests.  Does that sound like it would help your situation or do you have something else in mind?  I'm open to your suggestion on how to accomplish what you are asking.

Thank you.

Will the authentication token you receive in the response be attached to later requests as a header or a cookie?

Yes, it would be great that the Application could set cookie from response without my manual manipulation and send it on later requests.

@iamsimakov I am going to start working on this.  Can you please give me a real example of a request and response and which header you would like translated to what cookie?
I am trying to decide the best way to accomplish what you are asking and have it work for most people and not just in a very specific case.  It may be better to give the option of setting it once manually and then having it work on later requests.  Doing it automatically would probably need you to manually enter which header you want to map to what cookie anyway.
So after you send me your example I may decide to just give the option of adding a cookie manually for the first version and then give you a test build to try.

hello, i'm sorry but i don't have real example of request, beacuse it's project on my work and we have NDA rules and corporate politics about it. but i'm trying to find real request from any services with fake API such as https://jsonplaceholder.typicode.com/. if i will find it then i write it below. thank you

for example you can use https://reqres.in/ on this page there is method POST - LOGIN SUCCESSFUL
curl 'https://reqres.in/api/login' -H 'content-type: application/json' -H 'accept: */*' -H 'authority: reqres.in' --data-bi","password":"cityslicka"}' --compressed -v
and after this command you can find Set-Cookie string


v0.25 RC - QA API Keys

Hi folks 👋
After a first QA session, here are some feedbacks.
/keys access

The endpoints /keys are accessible without a master key defined for the instance, this API resource should not be accessible without it for security reasons.

API Key Format

The formats of the createdAt and updateAt fields should be displayed with a precision in seconds (It facilitates reading while the microseconds precision is not needed here). For example, createdAt: "2021-11-12T10:00:00Z" instead of "createdAt": "2021-12-07T14:30:22.633153Z".
If an API key does not have a description, the field should be displayed with a null value.

GET /keys

API Key objects should be ordered by createdAt in desc order. (Most recent first)

POST /keys

expiresAt should be a mandatory field, null should be specified for no expiration date.
Setting expiresAt with null throw a validation error
expiresAt if specified should throw an error if it's a past datetime from now. (This behavior is also found on the patch method).
Omitting the timezone part of the ISO-8601 format  at the end of the expiresAt field throws an error of format validation. An omitted timezone should default to Z automatically. e.g. Sending "2021-11-12T10:00:00", result in 2021-11-12T10:00:00Z (This behavior is also found on the patch method).

DELETE /keys/:key

Deleting a key returns a "Parse Error: The server returned a malformed response" on an HTTP client. (Postman in this case). The API key is however well deleted.

Creating an index does not propagate the newly created index in the indexes array
When using this API Key:
{
        "description": "My API Key",
        "key": "AIcjX0aG56a0c73984fa2f2b7ac93eb3e33b1e227eb304aa8cfe89d3f25aba1f9c0c781b",
        "actions": [
            "*"
        ],
        "indexes": [
            "test"
        ],
        "expiresAt": "2021-12-07T15:05:00Z",
        "createdAt": "2021-12-07T15:10:42.861041Z",
        "updatedAt": "2021-12-07T17:43:26.936329Z"
}

I created an index new_index since I have the authorization given by actions = *. I expected to find it in the indexes array of the API Key. Also, access to the newly created index is not given.
{
        "description": "My API Key",
        "key": "AIcjX0aG56a0c73984fa2f2b7ac93eb3e33b1e227eb304aa8cfe89d3f25aba1f9c0c781b",
        "actions": [
            "*"
        ],
        "indexes": [
            "test",
            "newindex"
        ],
        "expiresAt": "2021-12-07T15:05:00Z",
        "createdAt": "2021-12-07T15:10:42.861041Z",
        "updatedAt": "2021-12-07T17:43:26.936329Z"
}

Regarding
Creating an index does not propagate the newly created index in the indexes array
When using this API Key:
{
"description": "My API Key",
"key": "AIcjX0aG56a0c73984fa2f2b7ac93eb3e33b1e227eb304aa8cfe89d3f25aba1f9c0c781b",
"actions": [
"*"
],
"indexes": [
"test"
],
"expiresAt": "2021-12-07T15:05:00Z",
"createdAt": "2021-12-07T15:10:42.861041Z",
"updatedAt": "2021-12-07T17:43:26.936329Z"
}
I created an index new_index since I have the authorization given by actions = *. I expected to find it in the indexes array of the API Key. Also, access to the newly created index is not given.
{
"description": "My API Key",
"key": "AIcjX0aG56a0c73984fa2f2b7ac93eb3e33b1e227eb304aa8cfe89d3f25aba1f9c0c781b",
"actions": [
"*"
],
"indexes": [
"test",
"newindex"
],
"expiresAt": "2021-12-07T15:05:00Z",
"createdAt": "2021-12-07T15:10:42.861041Z",
"updatedAt": "2021-12-07T17:43:26.936329Z"
}
We decided to not handle it for now.
We are waiting for user feedback on this very particular case as we expect that the majority of indexes may be created with an admin key or for by key with indexes=["*"].

Closed by #1989


VIM and GVIM window titles are all upper case

If i start Vim or gVim the window title is VIM and GVIM.
I'm not sure but is Vim and gVim not the correct way to write it?

The program names are vim and gvim (both in lowercase, except maybe in DOS-like 8.3 notation, where I suppose they are VIM.EXE and GVIM.EXE respectively. (On Unix-like OSes including Linux, binary executables usually have no extension to their filename, and Vim is no exception).
When talking about the editor, I usually use "Vim" when both the console utility and the GUI are meant, "gvim" for the GUI only, or "Console Vim" for the console utility only. Other people may have some slightly different customs, but IMHO as long as we understand each other's meaning, the rest is secondary. However I notice that both :intro and :version say VIM - Vi IMproved with VIM in all caps.
For the purposes of the +clientserver feature, server names' case is ignored, i.e. "gvim" and "GVIM" are considered equal. There has long been the following snippet in my vimrc:
if has('gui_running')
  au GUIEnter *
    \ if has('clientserver') && v:servername == '' && serverlist() == ''
      \ | silent! call remote_startserver('GVIM') | endif
endif

As you can see, I use all caps in this case; but of course, YMMV. I think that this also sets the title for the gvim titlebar but it's been so long, I'm not sure anymore.
Best regards,
Tony.

Ok so its the servername with all caps in the title.
Seems --servername teST becomes all upper case "TEST" even though i did not write it like that.
I would just expect it to be the program name in the title.

So let's amend the documentation:
diff --git a/runtime/doc/remote.txt b/runtime/doc/remote.txt
index f856c98fc..b477ca77d 100644
--- a/runtime/doc/remote.txt
+++ b/runtime/doc/remote.txt
@@ -63,7 +63,7 @@ The following command line arguments are available:
    --servername {name}         Become the server {name}.  When used together
                                with one of the --remote commands: connect to
                                server {name} instead of the default (see
-                               below).
+                               below).  The {name} will be used in upper case.
                                                                *--remote-send*
    --remote-send {keys}                Send {keys} to server and exit.  The {keys}
                                are not mapped.  Special key names are

closed by https://github.com/vim/vim/commit/675e8d6adb88d5b38087870dfda51c0205070741


Added a unique key to every interview listing.

After reading up on the datastore api (this took me a painfully long amount of time to understand lol), turns out it automatically creates a unique key for every entity. I have added a new field to the InterviewRequest class: String key.
This will be useful for Alex to create the site that displays listing information, because we can pass this key to the url parameter*. As an example, it could look something like this sitename.com/?key=samplekeystring where samplekeystring would be the generated key that I stored. I'll add the part where it'll redirect to Alex's page and pass the parameter once he has his code up. Alex will have to create a site that'll take in a url parameter key, find the entity in datastore**, and display its information.
*Here is a good site I found that explains url parameters and how to use them. https://easyautotagging.com/javascript-get-url-parameter/
**To find the entity in datastore in constant time, do the following:
Key interviewKey = KeyFactory.stringToKey(samplekeystring);
Entity interviewRequest = datastore.get(interviewKey);

Thanks so much, and I'll look into that link you supplied to better understand using URL parameters. Looks like you just need to take care of those merge conflicts before merging.


how to make a 4:3 image not zoom but just put white on the left and right for a 16:9 monitor?

sorry if this is a duplicate issue i am just having trouble finding how to do this

wal doesn't have a way to do this.  Use wal to generate the colorscheme and apply it, then use feh to set your background how you want it.


question about jsonb_init()

Hello,
I could not find a better way to ask a question about some implementation details in jsonb_init(), from jason-build.
What is the purpose of the following code:
void
jsonb_init(jsonb *b)
{
static jsonb empty_builder;
*b = empty_builder;
....
Thanks in advance.
Volodimir

Hello, its just a "quick hack" to initialize all of jsonb members to zero.
When you create a static or global variable, it is automatically initialized to zero. This:
void
jsonb_init(jsonb *b)
{
  static jsonb empty_builder;
  *b = empty_builder;
...

Is analogous to doing

void
jsonb_init(jsonb *b)
{
  b->pos = 0;
  b->top = NULL;
...

Or
void
jsonb_init(jsonb *b)
{
  memset(b, 0, sizeof(jsonb));
...

Oh, thanks for answering so quickly. and the next line, *b = empty_builder;?
are copying the empty structure into b?

Yup thats precisely whats happening! empty_builder has all of its members set to zero, and thats being passed over to *b

I was confused about *b. It is like double pointer because b is already pointer.
Thanks for the library, i am trying to use it.
By the way, what do you thing about moving "jsonb b" inside of the header and adding to it the pointer to the buffer and the length? In this case jsonb_init will become
void
jsonb_init(jsonb *bb, char * ptr, int len)
{
static jsonb empty_builder;
*bb = empty_builder;
bb->top = bb->stack;
bb->buf_len = len;   // Length of the buffer
bb->buf_ptr = ptr;  // pointer to the buffer

}
and we could avoid passing the buffer and its length to all the functions?

Glad to to hear you are finding some use to it :)
Your suggestion is doable but it can be a little awkward if you need to resize the buffer in case its not large enough, you would need to update the jsonb fields everytime that happens. Nevertheless the library should be simple enough for you to wrap your custom logic to it, so you could do something like:
typedef struct myjsonb {
  jsonb builder;
  char *buf;
  size_t buflen;
} myjsonb;

And then,
jsonbcode
myjsonb_push_string(myjsonb *b,
                    const char buf[],
                    size_t len)
{
  return jsonb_push_string(&b->builder, b->buf, buf->bufsize, str, len);
}

}

Thanks for suggestion. With myjsonb_push_string we still pass the buffer and the length to every "push" function. What we initialize the builder with the address of the buffer and its length, and then only pass to the "push" functions the actual needed data?

Sorry that was a typo, it should be passing only the string that will be pushed to the JSON and its length

No worries, if you got more questions you can open another issue!


Fixed 039 Mad Libs

This PR fixes the code in 039 Mad Libs Generator.
Because of some changes in Google Sheets tabletop.js has been deprecated since 2020. But something similar is possible to do with the Papa Parse library. I have made changes as per that.
Tagging @shiffman to change the web editor version as well

Wonderful, thank you for adding the documentation comments!


"Valea lui Enache" is listed in the drop-down menu

Description:
"Valea lui Enache" is listed in the drop-down menu alongside its corresponding county and commune, according to the law
Precondition:
The website is up an running.

Step 1
Type "Valea lui Enache" in the search bar.

Expected results
The location is listed in the drop-down menu as "Valea lui Enache, Argeș (Băiculești)".


[WFCORE-2898] realm-mapper and principal rewritter into server-ssl-context

https://issues.jboss.org/browse/WFCORE-2898
https://issues.jboss.org/browse/JBEAP-11177
Depends on https://github.com/wildfly-security/wildfly-elytron/pull/853 (required for green build)

Core - Full Integration Build 5126 outcome was FAILURE using a merge of 2357564d766bf973576e46db7a29d16a654be3d4
Summary: Compilation error: Compiler (new) Build time: 00:00:36

Full integration - Windows Build 3538 outcome was FAILURE using a merge of 2357564d766bf973576e46db7a29d16a654be3d4
Summary: Compilation error: Compiler (new) Build time: 00:02:21

Retest this please

Core - Full Integration Build 5154 outcome was FAILURE using a merge of 2357564d766bf973576e46db7a29d16a654be3d4
Summary: Compilation error: Compiler (new) Build time: 00:00:39

Full integration - Windows Build 3565 outcome was FAILURE using a merge of 2357564d766bf973576e46db7a29d16a654be3d4
Summary: Compilation error: Compiler (new) Build time: 00:02:37


Add LegacyServiceAccountTokenCleanUp feature in beta

PR: https://github.com/kubernetes/kubernetes/pull/120682
Issue: https://github.com/kubernetes/enhancements/issues/2799

/sig auth

LGTM

@yt2985, The LegacyServiceAccountTokenCleanUp feature gate will be in beta in the k8s v1.29 release, so this PR will be for the dev-1.29 branch not for the main branch.

Adding hold label, as upstream PR not merged.
Please remove the hold label once the upstream PR merges.
/hold

cc @sftim

Did you perhaps rebase against main by mistake? I'd expect to see 1 commit that only covers the files you want to actually change.

hmmm, hold on for the review. I messed it up. Let me fix the commit first.

@zshihang, @tengqm, @sftim, thank you all for your great comments and suggestions! I have revised my PR. Please review it again.

/remove-area blog release-eng
/remove-committee security-response
/remove-language de es fr id it ja ko pl pt uk zh
/remove-sig auth release security

/sig authg

/assign

Hi, @yt2985! Kubernetes v1.29 Docs Lead here. Just a reminder that the deadline to have this PR reviewed and merged is Tuesday, 28 November. Let me know if you need any help!
CCing KEP owners: @liggitt @zshihang

/lgtm
@sftim could you review again so that we can get it merged in time?

/lgtm

/approve

/unhold