ci: run elixir actions in parallel

We're roughly in the sub 5 minute category. The All - trigger very rarely in a PR. The Elixir test with cache are in the max ~3 minute range because the software vault tests build rust in with --release and the parallelization from this PR.
✓  All - Build                                          4m57s  https://github.com/ockam-network/ockam/runs/4677793951?check_suite_focus=true
✓  All - Build                                          4m19s  https://github.com/ockam-network/ockam/runs/4677794370?check_suite_focus=true
✓  All - List Gradle Tasks (macos-10.15, 11)            29s    https://github.com/ockam-network/ockam/runs/4677794287?check_suite_focus=true
✓  All - List Gradle Tasks (macos-10.15, 11)            29s    https://github.com/ockam-network/ockam/runs/4677794537?check_suite_focus=true
✓  All - List Gradle Tasks (macos-10.15, 16)            33s    https://github.com/ockam-network/ockam/runs/4677794298?check_suite_focus=true
✓  All - List Gradle Tasks (macos-10.15, 16)            33s    https://github.com/ockam-network/ockam/runs/4677794554?check_suite_focus=true
✓  All - List Gradle Tasks (macos-10.15, 17)            31s    https://github.com/ockam-network/ockam/runs/4677794314?check_suite_focus=true
✓  All - List Gradle Tasks (macos-10.15, 17)            31s    https://github.com/ockam-network/ockam/runs/4677794565?check_suite_focus=true
✓  All - List Gradle Tasks (macos-10.15, 8)             31s    https://github.com/ockam-network/ockam/runs/4677794266?check_suite_focus=true
✓  All - List Gradle Tasks (macos-10.15, 8)             1m3s   https://github.com/ockam-network/ockam/runs/4677794517?check_suite_focus=true
✓  All - List Gradle Tasks (ubuntu-20.04, 11)           24s    https://github.com/ockam-network/ockam/runs/4677794193?check_suite_focus=true
✓  All - List Gradle Tasks (ubuntu-20.04, 11)           29s    https://github.com/ockam-network/ockam/runs/4677794467?check_suite_focus=true
✓  All - List Gradle Tasks (ubuntu-20.04, 16)           35s    https://github.com/ockam-network/ockam/runs/4677794222?check_suite_focus=true
✓  All - List Gradle Tasks (ubuntu-20.04, 16)           28s    https://github.com/ockam-network/ockam/runs/4677794486?check_suite_focus=true
✓  All - List Gradle Tasks (ubuntu-20.04, 17)           42s    https://github.com/ockam-network/ockam/runs/4677794245?check_suite_focus=true
✓  All - List Gradle Tasks (ubuntu-20.04, 17)           32s    https://github.com/ockam-network/ockam/runs/4677794502?check_suite_focus=true
✓  All - List Gradle Tasks (ubuntu-20.04, 8)            23s    https://github.com/ockam-network/ockam/runs/4677794066?check_suite_focus=true
✓  All - List Gradle Tasks (ubuntu-20.04, 8)            27s    https://github.com/ockam-network/ockam/runs/4677794450?check_suite_focus=true
✓  All - List Gradle Tasks (windows-2019, 11)           4m27s  https://github.com/ockam-network/ockam/runs/4677794342?check_suite_focus=true
✓  All - List Gradle Tasks (windows-2019, 11)           4m25s  https://github.com/ockam-network/ockam/runs/4677794591?check_suite_focus=true
✓  All - List Gradle Tasks (windows-2019, 16)           4m10s  https://github.com/ockam-network/ockam/runs/4677794359?check_suite_focus=true
✓  All - List Gradle Tasks (windows-2019, 16)           4m22s  https://github.com/ockam-network/ockam/runs/4677794604?check_suite_focus=true
✓  All - List Gradle Tasks (windows-2019, 17)           4m11s  https://github.com/ockam-network/ockam/runs/4677794371?check_suite_focus=true
✓  All - List Gradle Tasks (windows-2019, 17)           4m12s  https://github.com/ockam-network/ockam/runs/4677794615?check_suite_focus=true
✓  All - List Gradle Tasks (windows-2019, 8)            4m20s  https://github.com/ockam-network/ockam/runs/4677794327?check_suite_focus=true
✓  All - List Gradle Tasks (windows-2019, 8)            4m10s  https://github.com/ockam-network/ockam/runs/4677794582?check_suite_focus=true
✓  Commits - Check                                      21s    https://github.com/ockam-network/ockam/runs/4677794162?check_suite_focus=true
✓  Commits - Check                                      21s    https://github.com/ockam-network/ockam/runs/4677794399?check_suite_focus=true
✓  Documentation - Check Examples                       3m11s  https://github.com/ockam-network/ockam/runs/4677794094?check_suite_focus=true
✓  Documentation - Check Examples                       3m47s  https://github.com/ockam-network/ockam/runs/4677794369?check_suite_focus=true
✓  Editorconfig - Lint                                  13s    https://github.com/ockam-network/ockam/runs/4677794056?check_suite_focus=true
✓  Editorconfig - Lint                                  11s    https://github.com/ockam-network/ockam/runs/4677794361?check_suite_focus=true
✓  Elixir - build_ockam                                 1m53s  https://github.com/ockam-network/ockam/runs/4677794352?check_suite_focus=true
✓  Elixir - build_ockam                                 1m48s  https://github.com/ockam-network/ockam/runs/4677794974?check_suite_focus=true
✓  Elixir - build_ockam_hub                             2m36s  https://github.com/ockam-network/ockam/runs/4677794444?check_suite_focus=true
✓  Elixir - build_ockam_hub                             2m32s  https://github.com/ockam-network/ockam/runs/4677795054?check_suite_focus=true
✓  Elixir - build_ockam_kafka                           1m39s  https://github.com/ockam-network/ockam/runs/4677794593?check_suite_focus=true
✓  Elixir - build_ockam_kafka                           1m50s  https://github.com/ockam-network/ockam/runs/4677795127?check_suite_focus=true
✓  Elixir - build_ockam_vault_software                  1m44s  https://github.com/ockam-network/ockam/runs/4677794373?check_suite_focus=true
✓  Elixir - build_ockam_vault_software                  1m50s  https://github.com/ockam-network/ockam/runs/4677794702?check_suite_focus=true
✓  Elixir - lint_ockam                                  1m57s  https://github.com/ockam-network/ockam/runs/4677794093?check_suite_focus=true
✓  Elixir - lint_ockam                                  1m44s  https://github.com/ockam-network/ockam/runs/4677794459?check_suite_focus=true
✓  Elixir - lint_ockam_kafka                            2m2s   https://github.com/ockam-network/ockam/runs/4677794211?check_suite_focus=true
✓  Elixir - lint_ockam_kafka                            1m49s  https://github.com/ockam-network/ockam/runs/4677794279?check_suite_focus=true
✓  Elixir - lint_ockam_kafka                            1m42s  https://github.com/ockam-network/ockam/runs/4677794649?check_suite_focus=true
✓  Elixir - lint_ockam_kafka                            1m41s  https://github.com/ockam-network/ockam/runs/4677794718?check_suite_focus=true
✓  Elixir - lint_ockam_vault_software                   1m39s  https://github.com/ockam-network/ockam/runs/4677794243?check_suite_focus=true
✓  Elixir - lint_ockam_vault_software                   1m41s  https://github.com/ockam-network/ockam/runs/4677794908?check_suite_focus=true
✓  Elixir - test_ockam                                  1m57s  https://github.com/ockam-network/ockam/runs/4677794936?check_suite_focus=true
✓  Elixir - test_ockam                                  1m45s  https://github.com/ockam-network/ockam/runs/4677795180?check_suite_focus=true
✓  Elixir - test_ockam_hub                              2m45s  https://github.com/ockam-network/ockam/runs/4677794755?check_suite_focus=true
✓  Elixir - test_ockam_hub                              2m14s  https://github.com/ockam-network/ockam/runs/4677795240?check_suite_focus=true
✓  Elixir - test_ockam_kafka                            1m44s  https://github.com/ockam-network/ockam/runs/4677795009?check_suite_focus=true
✓  Elixir - test_ockam_kafka                            1m44s  https://github.com/ockam-network/ockam/runs/4677795321?check_suite_focus=true
✓  Elixir - test_ockam_vault_software                   3m9s   https://github.com/ockam-network/ockam/runs/4677795093?check_suite_focus=true
✓  Elixir - test_ockam_vault_software                   2m54s  https://github.com/ockam-network/ockam/runs/4677795397?check_suite_focus=true
✓  Rust - Build                                         1m41s  https://github.com/ockam-network/ockam/runs/4677793948?check_suite_focus=true
✓  Rust - Build                                         1m42s  https://github.com/ockam-network/ockam/runs/4677794414?check_suite_focus=true
✓  Rust - Build Documentation                           1m46s  https://github.com/ockam-network/ockam/runs/4677794062?check_suite_focus=true
✓  Rust - Build Documentation                           1m48s  https://github.com/ockam-network/ockam/runs/4677794489?check_suite_focus=true
✓  Rust - Build Examples                                3m11s  https://github.com/ockam-network/ockam/runs/4677794203?check_suite_focus=true
✓  Rust - Build Examples                                2m52s  https://github.com/ockam-network/ockam/runs/4677794658?check_suite_focus=true
✓  Rust - Check Cargo Update                            1m47s  https://github.com/ockam-network/ockam/runs/4677794238?check_suite_focus=true
✓  Rust - Check Cargo Update                            1m51s  https://github.com/ockam-network/ockam/runs/4677794722?check_suite_focus=true
✓  Rust - Check Features - no_std alloc software_vault  1m17s  https://github.com/ockam-network/ockam/runs/4677794280?check_suite_focus=true
✓  Rust - Check Features - no_std alloc software_vault  1m15s  https://github.com/ockam-network/ockam/runs/4677794916?check_suite_focus=true
✓  Rust - Lint Formatting                               1m36s  https://github.com/ockam-network/ockam/runs/4677794603?check_suite_focus=true
✓  Rust - Lint Formatting                               1m46s  https://github.com/ockam-network/ockam/runs/4677795124?check_suite_focus=true
✓  Rust - Lint with Cargo Clippy                        1m53s  https://github.com/ockam-network/ockam/runs/4677794353?check_suite_focus=true
✓  Rust - Lint with Cargo Clippy                        1m34s  https://github.com/ockam-network/ockam/runs/4677794983?check_suite_focus=true
✓  Rust - Lint with Cargo Deny                          1m20s  https://github.com/ockam-network/ockam/runs/4677794443?check_suite_focus=true
✓  Rust - Lint with Cargo Deny                          1m19s  https://github.com/ockam-network/ockam/runs/4677795058?check_suite_focus=true
✓  Rust - Test                                          6m13s  https://github.com/ockam-network/ockam/runs/4677794706?check_suite_focus=true
✓  Rust - Test                                          6m44s  https://github.com/ockam-network/ockam/runs/4677795179?check_suite_focus=true

The slowest right now is the Rust - Test job between 6 and 7 mins. Splitting the tests across multiple runners, like in elixir might be the way to go there.

We're roughly in the sub 5 minute category. The All - trigger very rarely in a PR. The Elixir test with cache are in the max ~3 minute range because the software vault tests build rust in with --release and the parallelization from this PR.
✓  All - Build                                          4m57s  https://github.com/ockam-network/ockam/runs/4677793951?check_suite_focus=true
✓  All - Build                                          4m19s  https://github.com/ockam-network/ockam/runs/4677794370?check_suite_focus=true
✓  All - List Gradle Tasks (macos-10.15, 11)            29s    https://github.com/ockam-network/ockam/runs/4677794287?check_suite_focus=true
✓  All - List Gradle Tasks (macos-10.15, 11)            29s    https://github.com/ockam-network/ockam/runs/4677794537?check_suite_focus=true
✓  All - List Gradle Tasks (macos-10.15, 16)            33s    https://github.com/ockam-network/ockam/runs/4677794298?check_suite_focus=true
✓  All - List Gradle Tasks (macos-10.15, 16)            33s    https://github.com/ockam-network/ockam/runs/4677794554?check_suite_focus=true
✓  All - List Gradle Tasks (macos-10.15, 17)            31s    https://github.com/ockam-network/ockam/runs/4677794314?check_suite_focus=true
✓  All - List Gradle Tasks (macos-10.15, 17)            31s    https://github.com/ockam-network/ockam/runs/4677794565?check_suite_focus=true
✓  All - List Gradle Tasks (macos-10.15, 8)             31s    https://github.com/ockam-network/ockam/runs/4677794266?check_suite_focus=true
✓  All - List Gradle Tasks (macos-10.15, 8)             1m3s   https://github.com/ockam-network/ockam/runs/4677794517?check_suite_focus=true
✓  All - List Gradle Tasks (ubuntu-20.04, 11)           24s    https://github.com/ockam-network/ockam/runs/4677794193?check_suite_focus=true
✓  All - List Gradle Tasks (ubuntu-20.04, 11)           29s    https://github.com/ockam-network/ockam/runs/4677794467?check_suite_focus=true
✓  All - List Gradle Tasks (ubuntu-20.04, 16)           35s    https://github.com/ockam-network/ockam/runs/4677794222?check_suite_focus=true
✓  All - List Gradle Tasks (ubuntu-20.04, 16)           28s    https://github.com/ockam-network/ockam/runs/4677794486?check_suite_focus=true
✓  All - List Gradle Tasks (ubuntu-20.04, 17)           42s    https://github.com/ockam-network/ockam/runs/4677794245?check_suite_focus=true
✓  All - List Gradle Tasks (ubuntu-20.04, 17)           32s    https://github.com/ockam-network/ockam/runs/4677794502?check_suite_focus=true
✓  All - List Gradle Tasks (ubuntu-20.04, 8)            23s    https://github.com/ockam-network/ockam/runs/4677794066?check_suite_focus=true
✓  All - List Gradle Tasks (ubuntu-20.04, 8)            27s    https://github.com/ockam-network/ockam/runs/4677794450?check_suite_focus=true
✓  All - List Gradle Tasks (windows-2019, 11)           4m27s  https://github.com/ockam-network/ockam/runs/4677794342?check_suite_focus=true
✓  All - List Gradle Tasks (windows-2019, 11)           4m25s  https://github.com/ockam-network/ockam/runs/4677794591?check_suite_focus=true
✓  All - List Gradle Tasks (windows-2019, 16)           4m10s  https://github.com/ockam-network/ockam/runs/4677794359?check_suite_focus=true
✓  All - List Gradle Tasks (windows-2019, 16)           4m22s  https://github.com/ockam-network/ockam/runs/4677794604?check_suite_focus=true
✓  All - List Gradle Tasks (windows-2019, 17)           4m11s  https://github.com/ockam-network/ockam/runs/4677794371?check_suite_focus=true
✓  All - List Gradle Tasks (windows-2019, 17)           4m12s  https://github.com/ockam-network/ockam/runs/4677794615?check_suite_focus=true
✓  All - List Gradle Tasks (windows-2019, 8)            4m20s  https://github.com/ockam-network/ockam/runs/4677794327?check_suite_focus=true
✓  All - List Gradle Tasks (windows-2019, 8)            4m10s  https://github.com/ockam-network/ockam/runs/4677794582?check_suite_focus=true
✓  Commits - Check                                      21s    https://github.com/ockam-network/ockam/runs/4677794162?check_suite_focus=true
✓  Commits - Check                                      21s    https://github.com/ockam-network/ockam/runs/4677794399?check_suite_focus=true
✓  Documentation - Check Examples                       3m11s  https://github.com/ockam-network/ockam/runs/4677794094?check_suite_focus=true
✓  Documentation - Check Examples                       3m47s  https://github.com/ockam-network/ockam/runs/4677794369?check_suite_focus=true
✓  Editorconfig - Lint                                  13s    https://github.com/ockam-network/ockam/runs/4677794056?check_suite_focus=true
✓  Editorconfig - Lint                                  11s    https://github.com/ockam-network/ockam/runs/4677794361?check_suite_focus=true
✓  Elixir - build_ockam                                 1m53s  https://github.com/ockam-network/ockam/runs/4677794352?check_suite_focus=true
✓  Elixir - build_ockam                                 1m48s  https://github.com/ockam-network/ockam/runs/4677794974?check_suite_focus=true
✓  Elixir - build_ockam_hub                             2m36s  https://github.com/ockam-network/ockam/runs/4677794444?check_suite_focus=true
✓  Elixir - build_ockam_hub                             2m32s  https://github.com/ockam-network/ockam/runs/4677795054?check_suite_focus=true
✓  Elixir - build_ockam_kafka                           1m39s  https://github.com/ockam-network/ockam/runs/4677794593?check_suite_focus=true
✓  Elixir - build_ockam_kafka                           1m50s  https://github.com/ockam-network/ockam/runs/4677795127?check_suite_focus=true
✓  Elixir - build_ockam_vault_software                  1m44s  https://github.com/ockam-network/ockam/runs/4677794373?check_suite_focus=true
✓  Elixir - build_ockam_vault_software                  1m50s  https://github.com/ockam-network/ockam/runs/4677794702?check_suite_focus=true
✓  Elixir - lint_ockam                                  1m57s  https://github.com/ockam-network/ockam/runs/4677794093?check_suite_focus=true
✓  Elixir - lint_ockam                                  1m44s  https://github.com/ockam-network/ockam/runs/4677794459?check_suite_focus=true
✓  Elixir - lint_ockam_kafka                            2m2s   https://github.com/ockam-network/ockam/runs/4677794211?check_suite_focus=true
✓  Elixir - lint_ockam_kafka                            1m49s  https://github.com/ockam-network/ockam/runs/4677794279?check_suite_focus=true
✓  Elixir - lint_ockam_kafka                            1m42s  https://github.com/ockam-network/ockam/runs/4677794649?check_suite_focus=true
✓  Elixir - lint_ockam_kafka                            1m41s  https://github.com/ockam-network/ockam/runs/4677794718?check_suite_focus=true
✓  Elixir - lint_ockam_vault_software                   1m39s  https://github.com/ockam-network/ockam/runs/4677794243?check_suite_focus=true
✓  Elixir - lint_ockam_vault_software                   1m41s  https://github.com/ockam-network/ockam/runs/4677794908?check_suite_focus=true
✓  Elixir - test_ockam                                  1m57s  https://github.com/ockam-network/ockam/runs/4677794936?check_suite_focus=true
✓  Elixir - test_ockam                                  1m45s  https://github.com/ockam-network/ockam/runs/4677795180?check_suite_focus=true
✓  Elixir - test_ockam_hub                              2m45s  https://github.com/ockam-network/ockam/runs/4677794755?check_suite_focus=true
✓  Elixir - test_ockam_hub                              2m14s  https://github.com/ockam-network/ockam/runs/4677795240?check_suite_focus=true
✓  Elixir - test_ockam_kafka                            1m44s  https://github.com/ockam-network/ockam/runs/4677795009?check_suite_focus=true
✓  Elixir - test_ockam_kafka                            1m44s  https://github.com/ockam-network/ockam/runs/4677795321?check_suite_focus=true
✓  Elixir - test_ockam_vault_software                   3m9s   https://github.com/ockam-network/ockam/runs/4677795093?check_suite_focus=true
✓  Elixir - test_ockam_vault_software                   2m54s  https://github.com/ockam-network/ockam/runs/4677795397?check_suite_focus=true
✓  Rust - Build                                         1m41s  https://github.com/ockam-network/ockam/runs/4677793948?check_suite_focus=true
✓  Rust - Build                                         1m42s  https://github.com/ockam-network/ockam/runs/4677794414?check_suite_focus=true
✓  Rust - Build Documentation                           1m46s  https://github.com/ockam-network/ockam/runs/4677794062?check_suite_focus=true
✓  Rust - Build Documentation                           1m48s  https://github.com/ockam-network/ockam/runs/4677794489?check_suite_focus=true
✓  Rust - Build Examples                                3m11s  https://github.com/ockam-network/ockam/runs/4677794203?check_suite_focus=true
✓  Rust - Build Examples                                2m52s  https://github.com/ockam-network/ockam/runs/4677794658?check_suite_focus=true
✓  Rust - Check Cargo Update                            1m47s  https://github.com/ockam-network/ockam/runs/4677794238?check_suite_focus=true
✓  Rust - Check Cargo Update                            1m51s  https://github.com/ockam-network/ockam/runs/4677794722?check_suite_focus=true
✓  Rust - Check Features - no_std alloc software_vault  1m17s  https://github.com/ockam-network/ockam/runs/4677794280?check_suite_focus=true
✓  Rust - Check Features - no_std alloc software_vault  1m15s  https://github.com/ockam-network/ockam/runs/4677794916?check_suite_focus=true
✓  Rust - Lint Formatting                               1m36s  https://github.com/ockam-network/ockam/runs/4677794603?check_suite_focus=true
✓  Rust - Lint Formatting                               1m46s  https://github.com/ockam-network/ockam/runs/4677795124?check_suite_focus=true
✓  Rust - Lint with Cargo Clippy                        1m53s  https://github.com/ockam-network/ockam/runs/4677794353?check_suite_focus=true
✓  Rust - Lint with Cargo Clippy                        1m34s  https://github.com/ockam-network/ockam/runs/4677794983?check_suite_focus=true
✓  Rust - Lint with Cargo Deny                          1m20s  https://github.com/ockam-network/ockam/runs/4677794443?check_suite_focus=true
✓  Rust - Lint with Cargo Deny                          1m19s  https://github.com/ockam-network/ockam/runs/4677795058?check_suite_focus=true
✓  Rust - Test                                          6m13s  https://github.com/ockam-network/ockam/runs/4677794706?check_suite_focus=true
✓  Rust - Test                                          6m44s  https://github.com/ockam-network/ockam/runs/4677795179?check_suite_focus=true

The slowest right now is the Rust - Test job between 6 and 7 mins. Splitting the tests across multiple runners, like in elixir might be the way to go there.


Movie card

Movie Card height set to 100% to improve it's responsiveness

Jshint config set for es2015

dark background contrast

Scroll functionality to scroll back to the top of page

@all-contributors add @silvareal for code as well


Improve scene logging

Improve the logs to show "actor: selected ACTION from SCENE using INTERACTIVE

New log: Went out through Forest Trail to Village Entrance


Question: Where is the default navbar in the code?

I am looking up and down the code, but i can't seem to find where the default navbar is defined, when nothing is specified in app.ini

Here you go: https://github.com/peachdocs/peach/blob/4354ac06bf787a940375dd7b007ad09e16b0cd88/templates/navbar.html#L3-L8


Added Docker Support And Updated README For Docker

I added a docker image the takes care of all dependencies and updated the README to be clearer and add docker support to docs.

Thanks for your contribution!


Focal length

Hi, thanks for sharing your dataset. Could you please provide additional details about the acquisition system? In particular, do you know the value of the focal length of the camera?

Unfortunately, I cannot share that information. All I can tell you is that the camera is somewhat close to the MPC2 https://www.bosch-mobility-solutions.com/media/global/products-and-services/passenger-cars-and-light-commercial-vehicles/driver-assistance-systems/lane-departure-warning/product-page-multi-purpose-camera/product-data-sheet-multi-purpose-camera.pdf


Feature request: Google Gemma support

Hi, are there any plans to add Google Gemma? Recently released versions works pretty well on LM Studio!

Gemma 2 seems to work already, about as well as LLaMa 3 (=stop token is ignored, so barely usable).

I think they were referring to gemma.cpp but ill close it anyway


Run script on alerts

⚠ Please verify that this bug has NOT been raised before.

[X] I checked and didn't find similar issue

🛡 Security Policy

[X] I agree to have read this project Security Policy

📝 Describe your problem
I have a simple web logging/alert system running on my LAN that you can access by simply pushing the message you want to log. So, in my machines running Linux I can simply run a curl command to store a log message.
Now I'd like to use that system with uptime-kuma but I haven't found anything similar to running a script in the alerts menu. Do you know if there is anything suitable option available? Otherwise I think I could try to write a run-script alert plugin myself.
Regards and thanks in advance
🐻 Uptime-Kuma Version
1.11.3
💻 Operating System and Arch
Ubuntu 20.04 x86
🌐 Browser
Firefox 96.0
🐋 Docker Version
20.10.7
🟩 NodeJS Version
No response

Don't think there's anything available like this...
Most likely you'd have to develop this yourself.

I'd love to see this integration. An alternative workaround is to somehow have an HTTP server that triggers your on-alert actions, then use the Webhook alert for triggering it.

I'd love to have this option as well. I'd like to be able to use my own webhook for sms alerting.

I'd love to see this integration. An alternative workaround is to somehow have an HTTP server that triggers your on-alert actions, then use the Webhook alert for triggering it.

Yep, I went with https://github.com/adnanh/webhook/

I'd love to see this integration. An alternative workaround is to somehow have an HTTP server that triggers your on-alert actions, then use the Webhook alert for triggering it.

Yep, I went with https://github.com/adnanh/webhook/

Thank you! Fantastic solution.

Just for linking - this duplicate for #2363


Add statusline capabilities to Terminfo

Closes #1636
@chrisduerr, @dnkl: Is it alright to just put the new capabilities at the bottom of the file or do you want it formatted a certain way?

I think that's fine. The current terminfo was constructed from many small
xterm fragments. I kept the ordering of the capabilities within each
fragment, but there is no (obvious) ordering between the fragments.
Also, if I don't say this, @chrisduerr will 🙂; we'll want to mention this
in the changelog.
On Thu, Oct 11, 2018, 03:02 RunningDroid<EMAIL_ADDRESS>wrote:

Closes #1636 https://github.com/jwilm/alacritty/issues/1636
@chrisduerr https://github.com/chrisduerr, @dnkl
https://github.com/dnkl: Is it alright to just put the new capabilities
at the bottom of the file or do you want it formatted a certain way?
You can view, comment on, or merge this pull request online at:
https://github.com/jwilm/alacritty/pull/1642
Commit Summary

Add statusline capabilities to Terminfo

File Changes

M alacritty.info
https://github.com/jwilm/alacritty/pull/1642/files#diff-0 (1)

Patch Links:

https://github.com/jwilm/alacritty/pull/1642.patch
https://github.com/jwilm/alacritty/pull/1642.diff

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jwilm/alacritty/pull/1642, or mute the thread
https://github.com/notifications/unsubscribe-auth/ANYapt9p8LzzfkdHO2citbh_fLzv2_8Nks5ujpjAgaJpZM4XWluF
.

Is it alright to add it as Added instead of Fixed?


add dist directory to .gitignore

When compiling the Haskell version, the binaries are being placed in the dist directory, leaving the repository "dirty".
By adding the dist directory to .gitignore, one could use this repo more easily in a custom dotfiles repository as a submodule.

Already proposed in #61


Create "playback" on map and chart

Feature suggestion from Seb, and Peter Brindle back in the day.
On map and chart view, it'd be nice if instead of dragging the slider, the user could click 'play' and see automatic playback of the changes.

@sebbacon closing this issue


Allow storage.options.cassandra.password to have an existingSecret reference to pick up cassandra password from

HI,
There is ability to connect Cassandra storage with username and password through jaeger-operator, but there is no way to use a kubernetes secret for the password field and the Jaeger CR would need to have it in plaintext. This is an issue since we would store the Jaeger CR definition in git.
Even with templating through helm/kustomize, it'd mean the operator needs to store the secret somewhere in their own env. A much cleaner way would be able to refer to an existing kubernetes secret.
a useExistingSecret: <kubernetes secret name> would help here, since we would spin up cassandra with either the bitnami/cassandra chart or scylla-operator (among others), both of which support the existingSecret paradigm to create the clusters.

You can mount a secret into env vars: https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets-as-environment-variables
Wouldn't that work for you?

Secret mounting would not work for the Jaeger CustomResource.
apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: jaeger-streaming
spec:
  ...
  storage:
    type: cassandra
    options:
      cassandra:
        servers: cassandra.cassandra.svc.cluster.local
        keyspace: test
        username: cassandra
        password: CASSANDRA_PASS // <- this is how the CR accepts passwords
    cassandraCreateSchema:
      datacenter: dc1
      mode: "test"
      timeout: "3m"

Secret mounting works on Standard K8S GVKs, not for CRs

Sorry, you are absolutely correct, but we actually do support building env vars from secrets in a different way:
Excerpt from the docs:
apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: simple-prod
spec:
  strategy: production
  storage:
    type: elasticsearch
    options:
      es:
        server-urls: https://quickstart-es-http.default.svc:9200
    secretName: jaeger-secret

The secret would then contain the env vars and values to be passed down to the collector/query/ingester. You can generate the secret like this:
$ kubectl create secret generic jaeger-secret --from-literal=ES_PASSWORD=changeme --from-literal=ES_USERNAME=elastic

While this shows the usage for ES, it should apply for Cassandra as well. I think we do need a better documentation for this, though.

Yes, this should work. I'll try and submit a docs patch. Thanks.

Sorry, you are absolutely correct, but we actually do support building env vars from secrets in a different way:
Excerpt from the docs:
apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: simple-prod
spec:
  strategy: production
  storage:
    type: elasticsearch
    options:
      es:
        server-urls: https://quickstart-es-http.default.svc:9200
    secretName: jaeger-secret

The secret would then contain the env vars and values to be passed down to the collector/query/ingester. You can generate the secret like this:
$ kubectl create secret generic jaeger-secret --from-literal=ES_PASSWORD=changeme --from-literal=ES_USERNAME=elastic

While this shows the usage for ES, it should apply for Cassandra as well. I think we do need a better documentation for this, though.

Unless I'm doing something wrong, it doesn't seem to be working for me with Cassandra.
I'm doing the same as above with secretName: cassandra-creds which is a secret created like: kubectl create secret generic cassandra-creds --from-literal=CASSANDRA_USER=blah --from-literal=CASSANDRA_PASSWORD=blah
Yet still the connection fails and the logs fill with (AuthenticationFailed('Remote end requires authentication.')). Any ideas?

Could you please double-check that you are using CASSANDRA_USERNAME and not CASSANDRA_USER? The CLI flag for the username is cassandra.username, which translates to the env var CASSANDRA_USERNAME.

In time: @Hashfyre, did you manage to send a documentation PR?

Yep, same issue with CASSANDRA_USERNAME too, unfortunately.

@tobypeschel if you run a local Jaeger process with CASSANDRA_USERNAME/CASSANDRA_PASSWORD as env vars, does it work? If you set the flags directly in the CR as options, does it work?

@jpkrohling It works if I supply the username and password as options, yes. Otherwise no, still it doesn't work. It looks like it simply doesn't behave in the same way as ES_PASSWORD/ES_USERNAME.

If Jaeger does accept CASSANDRA_USERNAME/CASSANDRA_PASSWORD env vars, we should support the same as we have in ES in the operator. I'm not able to work on this for the next few weeks, but I'm open to review PRs fixing this.

I've deployed a cassandra instance from the bitnami chart and a jaeger instance using the operator chart and linked them to an existing secret as described above. I can confirm that it works using CASSANDRA_USERNAME and CASSANDRA_PASSWORD 👍
@tobypeschel it's been a while since you've posted your issues here, but in case they are still present, I'd be happy to help

Due to several other issues with the helm chart (invalid CRD, CR and labels), I switched over to deploying the manifests manually and now ran into this issue again. Upon further inspection it appears to me that the schema job does not account for the secret:
https://github.com/jaegertracing/jaeger-operator/blob/5bf83e1024edb5963517d1a7419bd61184ca2c06/pkg/storage/cassandra_dependencies.go#L57-L58
Whereas the regular deployment does:
https://github.com/jaegertracing/jaeger-operator/blob/5bf83e1024edb5963517d1a7419bd61184ca2c06/pkg/deployment/all_in_one.go#L85-L94
I guess it just "accidentally" worked for me before (with the operator helm chart) because I initially deployed the custom resource using the plain username and password options, resulting in the schema being created successfully, and only after that switched to using a secret.

Would you be interested in contributing a fix?

Would you be interested in contributing a fix?

In the spirit of being helpful and giving back to the open-source community, yes, always! However, I've not written much go code yet (especially production-grade), so chances are that you'll spend more time giving feedback to my contribution than you would need to implement it yourself. Additionally I would need to allocate enough spare time to get familiar with the contribution guidelines, set up my dev environment and submit the PR. If both of those arguments don't matter that much, I'd be happy to help :)

chances are that you'll spend more time giving feedback to my contribution than you would need to implement it yourself

That's fine, I'll end up with one more person knowing this code, which is always a good thing.

Additionally I would need to allocate enough spare time to get familiar with the contribution guidelines, set up my dev environment and submit the PR, so that would take considerably longer

This will make it easier to contribute more features in the future ;-) The docs should be up to date, but let us know if you get blocked.

If both of those arguments don't matter that much, I'd be happy to help

Looking forward to your PR!


Is it possible to log lambda X-Ray traces, to same lambda cloudwatch loggroup?

Will it be possible to use shimmerjs to do monkeypatching to aws-x-ray-sdk
START RequestId: f5507533-9175-4dea-83b0-a71384c4f507 Version: $LATEST

<<<<<<<<<<<<<<<<<Log X-ray traces as part of same lambda loggroup logs>>>>>>>>>>>>>>>>>>>

END RequestId: f5507533-9175-4dea-83b0-a71384c4f507
REPORT RequestId: f5507533-9175-4dea-83b0-a71384c4f507	Duration: 100.72 ms	Billed Duration: 200 ms	Memory Size: 1024 MB	Max Memory Used: 90 MB	Init Duration: 455.37 ms
XRAY TraceId: 1-5f92b333-70350ac7708cb2b827d1dd11	SegmentId: 68798e5d297dfcde	Sampled: true

Hi @bala1074,
I don't think we'd be able to prioritize rewriting all of our patchers to use Shimmer at this time. I also don't understand how that would relate to Logging in Lambda, could you elaborate a bit more on your use case and desired state?

@willarmiros thank you for the response.
Actually, I am working on end to end tracing for serverless. To implement end to end tracing, I was looking into the possible Serverless Lambda triggers (like API Gateway, SQS, SNS, S3, CloudWatch Events, DynamoDB Streams, Step Functions ..etc.,), I enabled X-RAY for the lambda function and get traces but not able to see trigger related traces in X-RAY.
Question1: Will it be possible to get lambda trigger information in X-Ray for all possible triggers?
I assume, if it is not possible to get the trigger information in X-RAY for all possible triggers, So I decided to use lambda functions event object to derive the trigger using https://gist.github.com/jeshan/52cb021fd20d871c56ad5ce6d2654d7b
Once I derive the trigger from event object, I do console to clouwatch loggroup of that lambda function.
Finally, I am collecting cloudwatch logs  to get the trigger information + collecting x-ray traces to get lambda traces
Question2: To simplify the correlatation of the trigger + xray traces, I am thinking to console X-Ray traces to cloudwatch logs.
I was collecting XRAY TraceId from the cloudwatch logs REPORT
START RequestId: f5507533-9175-4dea-83b0-a71384c4f507 Version: $LATEST
<<<<<<<<<<<<<<<<<Log X-ray traces as part of same lambda loggroup logs>>>>>>>>>>>>>>>>>>>
END RequestId: f5507533-9175-4dea-83b0-a71384c4f507
**REPORT** RequestId: f5507533-9175-4dea-83b0-a71384c4f507	Duration: 100.72 ms	Billed Duration: 200 ms	Memory Size: 1024 MB	Max Memory Used: 90 MB	Init Duration: 455.37 ms
**XRAY TraceId: 1-5f92b333-70350ac7708cb2b827d1dd11**	SegmentId: 68798e5d297dfcde	Sampled: true

and then using XRAY TraceId, I am quering the x-ray api's to collect traces.
And all operations here are synchronous and dependent to each other. Like collect x-ray-id and then collect traces from x-ray.
To simplify that, Is It possible to log x-ray traces along with XRAY TraceId in the report section of cloudwatch logs

Hi @bala1074,
Q1: Today, as I'm sure you've noticed, SQS and many other batching services triggering Lambda do not make a connected trace. #208 tracks that feature request and is something the X-Ray team is actively working on and will update when it is available. For now parsing the trigger from the event and using that to connect your traces manually sounds like a good approach for your use case.
Q2: You can pretty-print the entire segment object in your Lambda handler code by simply doing:
console.log(JSON.stringify(AWSXRay.getSegment(), null, 2));

This will print the segment object in your logs, which will include its trace ID. Hope this helps!

Hi @willarmiros,
Q2: I am able to get the x-ray traces for the particular segment, not entire traces. Would it be possible to get the entire trace object (contains all segment traces) in logs. Or else, Is there any possibility to programmatically Identify segment and log traces for all segments with minor code changes by implementing a serverless plugin. I tried by enabling debug flag from the lambda environment AWS_XRAY_DEBUG_MODE, Is it recommended in production?

It is not really possible to log the entire trace in real time from a particular application, e.g. Lambda. That's because a trace is by definition a collection of segments from several different services, so your Lambda function would have no way of knowing the contents of the trace contributed by other services in real time.
I would not recommend AWS_XRAY_DEBUG_MODE logging in production, it can be quite verbose and pollute your logs.


Fix typo

Task name: Azure File Copy
Description: Fix typo in readme
Documentation changes required: N
Added unit tests: N
Attached related issue: N
Checklist:

[ ] Task version was bumped - please check instruction how to do it
[ ] Checked that applied changes work as expected

@chshrikh @Vijay-train Can this doc simple fix now get merged?

@chshrikh @Vijay-train Can this doc simple fix now get merged?


cache apiAt in blockCache

according to our assumption, most requests are targeting recent blocks, why not just construct and cache apiAt in blockCache on new block,  so querying recent blocks should be much faster. Querying old blocks will construct new apiAt, which is fine and do not need to cache

can also trigger getBlock on new head to cache the result


cpeng: change default CLI arg values

Change destination offset to the correct offset in memory where the
HPS boot will look for the image at
Change to timeout to a smaller value

Use std::chrono types to be more readable

Change default image name to kernel.itb

Signed-off-by: Rodrigo Rojo<EMAIL_ADDRESS>

Coverage decreased (-0.004%) to 63.589% when pulling 97641e2db493ef1439dbd11043b0bf340bddea6b on rrojo/cpeng-defaults into 9ad1fa47a11ae2b8776054fa137f415c006750a6 on master.


💡[Feature]: Dark Light mode

Is there an existing issue for this?

[X] I have searched the existing issues

Feature Description
I would like to add a light /dark mode button to toggle between modes . The button will be on the navbar
Use Case
It would enhance user experience
Benefits
No response
Add ScreenShots
No response
Priority
High
Record

[X] I have read the Contributing Guidelines
[X] I'm a GSSOC'24 contributor
[X] I want to work on this issue

@Swarnendu0123 . Shall it be done using Shadcn UI ?

@Swarnendu0123 @Smitkhobragade I would be using tailwind . If you want I can use Shadcn UI

Okay as per convenience. You can go with. I am assigning this tp you. You can start working @Jagpreet153


Saving crop before hitting apply, saves the image with the crop guides visible

Version
https://ui.toast.com/tui-image-editor
Test Environment
Windows, Google Chrome 75.0.3770.142
Current Behavior

https://www.screencast.com/t/iCwLRhSOfUf2
If you open up the image editor example on the website. Click on the crop tool, click one of the crop formats, and then click "download" without clicking "apply" it will result in downloading an image that still contains the crop guides. In this case it should either remove the guides prior to the download by cancelling the action or it should prevent the download. I tested some of the other tools, and they don't seem to suffer this same problem. In example rotate, flip didn't exhibit this behavior, but crop did.
Originally posted at https://github.com/nhn/tui.editor/issues/592 .

@owenallenaz I'll check about it. Thank you for your report.

duplicate of #224


node:internal/errors:464

node:internal/errors:464
ErrorCaptureStackTrace(err);
Error [ERR_UNHANDLED_ERROR]: Unhandled error. ({   message: 'Request failed with status code 400',   type: 'REQUEST_FAILED' })     at new NodeError (node:internal/errors:371:5)     at PassThrough.emit (node:events:379:17) at downloadChunk (C:\Users\smido\Desktop\Group Chat Bot\Youtube API\node_modules\youtubei.js\lib\Innertube.js:613:20) at processTicksAndRejections (node:internal/process/task_queues:96:5) {   code: 'ERR_UNHANDLED_ERROR', context: {message: 'Request failed with status code 400',     type: 'REQUEST_FAILED' }

Hey there, I see you're using v1.
If possible, please provide a code snippet so I can reproduce it and eventually fix it. Or you can just migrate to v2, see #65.
Thanks for reporting and have a great day!


spotify-recent-plays connector in the gallery

Hey! My PR with Spotify recent plays connector has been merged 2 weeks ago. Do I need to do something more in order for it to be presented in the official gallery or was it just "inappropriate" for the gallery? ;)
If you think I should improve something let me know 👍

Sorry for the delay in response. You don't need to do anything further, at the moment, I've just been delayed in getting the new managed deployments out.


[FLINK-14346] [serialization] faster implementation of StringValue writeString and readString

What is the purpose of the change
This PR implements a set of performance optimizations for String serialization and de-serialization. While running a set of state-heavy streaming jobs, we noticed that Flink spends quite a lot of CPU time (~30-40%) doing String encoding and decoding in two places: while transferring messages between the nodes, and while loading and writing objects into the state store.
We did a simple benchmark of String read/write operations compared to a default JDK's DataOutput.writeUTF ano noted a significant performance difference between Flink implementation and the JDK one.
Performance difference was 4x on decoding and 2x on encoding for 16 symbol ascii strings.
[info]	Benchmark	                      (length)	(stringType)	Mode	Cnt	Score	    Error	Units
[info]	StringDeserializerBenchmark.deserializeDefault	16	ascii	avgt	25	251.321	±	3.251	ns/op
[info]	StringDeserializerBenchmark.deserializeJDK	16	ascii	avgt	25	77.147	±	1.661	ns/op

[info]	StringSerializerBenchmark.serializeDefault	16	ascii	avgt	25	95.782	±	0.261	ns/op
[info]	StringSerializerBenchmark.serializeJDK		16	ascii	avgt	25	50.786	±	1.677	ns/op

For larger strings performance was degrading even more significant, 7x and 4x accordingly:
[info]	Benchmark	                      (length)	(stringType)	Mode	Cnt	Score	    Error	Units
[info]	StringDeserializerBenchmark.deserializeDefault	128	ascii	avgt	25	1757.726	±	3.312	ns/op
[info]	StringDeserializerBenchmark.deserializeJDK	128	ascii	avgt	25	263.445	±	6.912	ns/op

[info]	StringSerializerBenchmark.serializeDefault	128	ascii	avgt	25	670.627	±	2.807	ns/op
[info]	StringSerializerBenchmark.serializeJDK		128	ascii	avgt	25	151.789	±	7.295	ns/op

But JDK DataOutput.writeUTF cannot be directly used as a serializer replacement because of it being incompatible with the current Flink binary format for strings. Also it is not able to write strings longer than 32kb, as it uses 2-byte length encoding.
But if you compare the difference in implementation between these two algorithms, the main important difference is intermediate buffering in JDK, compared to a iterative approach in Flink. This buffering allows HotSpot to do two important optimizations:

be able to unroll the whole encoding/decoding loop
as there is no data dependencies between characters anymore, CPU can achieve much higher internal parallelism and spend less time being stalled.

We made a simple POC which alters the implementation of StringValue.writeString and StringValue.readString in a way to introduce additional buffering, which significantly improves both encoding and decoding throughput on almost all the workloads.
There is also a property-based validation test suite which ensures that old and new serialization code produce exactly the same byte sequences, and doing a round-trip from old to new, new to old, and new to new produce the same results. We ran this suite with random data for ~1h and found no differences.
Benchmark results
Full raw benchmark results are located here. We did a series of benchmarks of three string encoding/decoding impmentations:

Flink's current StringValue.writeString and StringValue.readString
StringValue.writeString and StringValue.readString implementations from this PR
baseline binary-incompatible implementation of DataInput.readUTF and DataOutput.writeUTF

For a workload generator we used these parameters:

string types: 7-bit us-ascii, russian symbols (which are usually encoded as a 14-bit varlen numbers), chinese symbols (which are usually within 21-bit varlen number range)
string lengths: 1, 4, 8, 16, 32, 64, 128 characters.

Ascii strings
[info]	Benchmark	                      (length)	(stringType)	Mode	Cnt	Score	    Error	Units
[info]	StringDeserializerBenchmark.deserializeDefault	1	ascii	avgt	25	46.603	±	0.750	ns/op
[info]	StringDeserializerBenchmark.deserializeImproved	1	ascii	avgt	25	51.074	±	0.720	ns/op
[info]	StringDeserializerBenchmark.deserializeJDK	1	ascii	avgt	25	63.402	±	1.631	ns/op
[info]	StringSerializerBenchmark.serializeDefault	1	ascii	avgt	25	31.595	±	0.489	ns/op
[info]	StringSerializerBenchmark.serializeImproved	1	ascii	avgt	25	33.454	±	0.151	ns/op
[info]	StringSerializerBenchmark.serializeJDK		1	ascii	avgt	25	34.721	±	0.128	ns/op

[info]	StringDeserializerBenchmark.deserializeDefault	16	ascii	avgt	25	251.321	±	3.251	ns/op
[info]	StringDeserializerBenchmark.deserializeImproved	16	ascii	avgt	25	55.385	±	1.176	ns/op
[info]	StringDeserializerBenchmark.deserializeJDK	16	ascii	avgt	25	77.147	±	1.661	ns/op
[info]	StringSerializerBenchmark.serializeDefault	16	ascii	avgt	25	95.782	±	0.261	ns/op
[info]	StringSerializerBenchmark.serializeImproved	16	ascii	avgt	25	51.806	±	0.180	ns/op
[info]	StringSerializerBenchmark.serializeJDK		16	ascii	avgt	25	50.786	±	1.677	ns/op

[info]	StringDeserializerBenchmark.deserializeDefault	128	ascii	avgt	25	1757.726 ±	3.312	ns/op
[info]	StringDeserializerBenchmark.deserializeImproved	128	ascii	avgt	25	140.374	±	1.006	ns/op
[info]	StringDeserializerBenchmark.deserializeJDK	128	ascii	avgt	25	263.445	±	6.912	ns/op
[info]	StringSerializerBenchmark.serializeDefault	128	ascii	avgt	25	670.627	±	2.807	ns/op
[info]	StringSerializerBenchmark.serializeImproved	128	ascii	avgt	25	161.481	±	2.798	ns/op
[info]	StringSerializerBenchmark.serializeJDK		128	ascii	avgt	25	151.789	±	7.295	ns/op

So for ascii strings:

on 1-char strings the new implementation is a bit slower than the old one. There was a performance regression, which is fixed in the next commit. For short strings performance is almost the same.
on 16-char strings encoding is 2x faster, decoding is 5x faster
on 128-char strings encoding is 4x faster, decoding is 12x faster

Non-ascii strings
[info]	Benchmark	                      (length)	(stringType)	Mode	Cnt	Score	    Error	Units
[info]	StringDeserializerBenchmark.deserializeDefault	1	chinese	avgt	25	77.743	±	1.635	ns/op
[info]	StringDeserializerBenchmark.deserializeImproved	1	chinese	avgt	25	78.814	±	1.329	ns/op
[info]	StringDeserializerBenchmark.deserializeJDK	1	chinese	avgt	25	66.005	±	1.325	ns/op
[info]	StringSerializerBenchmark.serializeDefault	1	chinese	avgt	25	36.767	±	3.662	ns/op
[info]	StringSerializerBenchmark.serializeImproved	1	chinese	avgt	25	36.382	±	0.153	ns/op
[info]	StringSerializerBenchmark.serializeJDK		1	chinese	avgt	25	36.845	±	0.575	ns/op

[info]	StringDeserializerBenchmark.deserializeDefault	16	chinese	avgt	25	669.156	±	3.021	ns/op
[info]	StringDeserializerBenchmark.deserializeImproved	16	chinese	avgt	25	182.587	±	4.843	ns/op
[info]	StringDeserializerBenchmark.deserializeJDK	16	chinese	avgt	25	148.063	±	2.204	ns/op
[info]	StringSerializerBenchmark.serializeDefault	16	chinese	avgt	25	244.844	±	1.079	ns/op
[info]	StringSerializerBenchmark.serializeImproved	16	chinese	avgt	25	86.651	±	1.316	ns/op
[info]	StringSerializerBenchmark.serializeJDK	 	16	chinese	avgt	25	81.840	±	1.976	ns/op

[info]	StringDeserializerBenchmark.deserializeDefault	128	chinese	avgt	25	5147.632 ±	30.068	ns/op
[info]	StringDeserializerBenchmark.deserializeImproved	128	chinese	avgt	25	714.912	±	26.240	ns/op
[info]	StringDeserializerBenchmark.deserializeJDK	128	chinese	avgt	25	738.740	±	7.291	ns/op
[info]	StringSerializerBenchmark.serializeDefault	128	chinese	avgt	25	1889.786 ±	8.541	ns/op
[info]	StringSerializerBenchmark.serializeImproved	128	chinese	avgt	25	388.404	±	2.511	ns/op
[info]	StringSerializerBenchmark.serializeJDK	 	128	chinese	avgt	25	401.011	±	3.157	ns/op

So for non-ascii chinese character strings:

on 1-char strings there is no performance difference.
on 16-char strings encoding is 3x faster, decoding is 4x faster
on 128-char strings encoding is 5x faster, decoding is 7x faster

Brief change log

Replace an existing StringValue.writeString and StringValue.readString methods with improved ones.
Add an additional test case to StringSerializationTest to cover utf8 encoding/decoding.
Performance regression fix for short strings.

Verifying this change
This change is already covered by existing tests, such as StringSerializationTest.
Also this change added additional test cases and can be verified as follows:

Add an additional test case to StringSerializationTest to cover utf8 encoding/decoding.

Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (yes / no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (yes / no)
The serializers: (yes / no / don't know)
The runtime per-record code paths (performance sensitive): (yes / no / don't know)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: (yes / no / don't know)
The S3 file system connector: (yes / no / don't know)

Documentation

Does this pull request introduce a new feature? (yes / no)
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

Yet another set of benchmarks, out of flink-benchmarks PR (https://github.com/dataArtisans/flink-benchmarks/pull/36).
The only thing I notice here is a slight performance degradation on small strings (<=4 symbols), which I'll address in the next patch.
master:

Benchmark                                                        Mode  Cnt    Score    Error   Units
SerializationFrameworkMiniBenchmarks.serializerAvro             thrpt   30  388.350 ±  5.574  ops/ms
SerializationFrameworkMiniBenchmarks.serializerKryo             thrpt   30  211.344 ±  8.336  ops/ms
SerializationFrameworkMiniBenchmarks.serializerPojo             thrpt   30  470.016 ± 13.141  ops/ms
SerializationFrameworkMiniBenchmarks.serializerRow              thrpt   30  557.009 ±  9.751  ops/ms
SerializationFrameworkMiniBenchmarks.serializerStringHeavyPojo  thrpt   30   88.379 ±  1.292  ops/ms
SerializationFrameworkMiniBenchmarks.serializerTuple            thrpt   30  592.778 ±  8.488  ops/ms

Benchmark                                 (lengthStr)   (type)   Mode  Cnt      Score      Error   Units
PojoSerializationBenchmark.readAvro               N/A      N/A  thrpt   30    598.640 ±   25.763  ops/ms
PojoSerializationBenchmark.readKryo               N/A      N/A  thrpt   30    193.355 ±    6.963  ops/ms
PojoSerializationBenchmark.readPojo               N/A      N/A  thrpt   30    620.239 ±    3.194  ops/ms
PojoSerializationBenchmark.writeAvro              N/A      N/A  thrpt   30    654.290 ±    3.870  ops/ms
PojoSerializationBenchmark.writeKryo              N/A      N/A  thrpt   30    608.389 ±   12.006  ops/ms
PojoSerializationBenchmark.writePojo              N/A      N/A  thrpt   30    828.253 ±    6.037  ops/ms
StringSerializationBenchmark.stringRead             4    ascii  thrpt   30  11445.245 ±   35.093  ops/ms
StringSerializationBenchmark.stringRead             4  russian  thrpt   30   7115.556 ±   25.999  ops/ms
StringSerializationBenchmark.stringRead             4  chinese  thrpt   30   5149.447 ±   30.320  ops/ms
StringSerializationBenchmark.stringRead            32    ascii  thrpt   30   2154.990 ±    6.773  ops/ms
StringSerializationBenchmark.stringRead            32  russian  thrpt   30   1126.236 ±    0.974  ops/ms
StringSerializationBenchmark.stringRead            32  chinese  thrpt   30    772.899 ±    3.538  ops/ms
StringSerializationBenchmark.stringRead           256    ascii  thrpt   30    285.788 ±    0.907  ops/ms
StringSerializationBenchmark.stringRead           256  russian  thrpt   30    144.113 ±    0.793  ops/ms
StringSerializationBenchmark.stringRead           256  chinese  thrpt   30     98.919 ±    0.718  ops/ms
StringSerializationBenchmark.stringWrite            4    ascii  thrpt   30  19755.480 ±  113.023  ops/ms
StringSerializationBenchmark.stringWrite            4  russian  thrpt   30  11731.759 ± 1329.529  ops/ms
StringSerializationBenchmark.stringWrite            4  chinese  thrpt   30  11457.075 ±   64.132  ops/ms
StringSerializationBenchmark.stringWrite           32    ascii  thrpt   30   3349.573 ±   15.093  ops/ms
StringSerializationBenchmark.stringWrite           32  russian  thrpt   30   1464.489 ±   10.258  ops/ms
StringSerializationBenchmark.stringWrite           32  chinese  thrpt   30   1094.098 ±    4.450  ops/ms
StringSerializationBenchmark.stringWrite          256    ascii  thrpt   30    464.168 ±    4.761  ops/ms
StringSerializationBenchmark.stringWrite          256  russian  thrpt   30    269.960 ±   53.424  ops/ms
StringSerializationBenchmark.stringWrite          256  chinese  thrpt   30    189.702 ±   36.327  ops/ms

this PR:

Benchmark                                                        Mode  Cnt    Score    Error   Units
SerializationFrameworkMiniBenchmarks.serializerAvro             thrpt   30  389.392 ±  6.379  ops/ms
SerializationFrameworkMiniBenchmarks.serializerKryo             thrpt   30  217.490 ±  8.975  ops/ms
SerializationFrameworkMiniBenchmarks.serializerPojo             thrpt   30  448.449 ± 11.446  ops/ms
SerializationFrameworkMiniBenchmarks.serializerRow              thrpt   30  521.921 ± 11.082  ops/ms
SerializationFrameworkMiniBenchmarks.serializerStringHeavyPojo  thrpt   30  108.779 ±  2.980  ops/ms
SerializationFrameworkMiniBenchmarks.serializerTuple            thrpt   30  548.718 ± 11.773  ops/ms

Benchmark                                 (lengthStr)   (type)   Mode  Cnt      Score     Error   Units
PojoSerializationBenchmark.readAvro               N/A      N/A  thrpt   30    593.101 ±  30.778  ops/ms
PojoSerializationBenchmark.readKryo               N/A      N/A  thrpt   30    184.984 ±   2.437  ops/ms
PojoSerializationBenchmark.readPojo               N/A      N/A  thrpt   30    657.618 ±   8.342  ops/ms
PojoSerializationBenchmark.writeAvro              N/A      N/A  thrpt   30    632.636 ±   4.231  ops/ms
PojoSerializationBenchmark.writeKryo              N/A      N/A  thrpt   30    609.889 ±   4.084  ops/ms
PojoSerializationBenchmark.writePojo              N/A      N/A  thrpt   30    769.924 ±   8.650  ops/ms
StringSerializationBenchmark.stringRead             4    ascii  thrpt   30  17623.353 ±  48.387  ops/ms
StringSerializationBenchmark.stringRead             4  russian  thrpt   30  10226.762 ±  94.515  ops/ms
StringSerializationBenchmark.stringRead             4  chinese  thrpt   30   7979.150 ±  61.660  ops/ms
StringSerializationBenchmark.stringRead            32    ascii  thrpt   30  13919.065 ±  51.691  ops/ms
StringSerializationBenchmark.stringRead            32  russian  thrpt   30   4537.817 ±  30.646  ops/ms
StringSerializationBenchmark.stringRead            32  chinese  thrpt   30   3263.699 ±  22.664  ops/ms
StringSerializationBenchmark.stringRead           256    ascii  thrpt   30   3183.622 ±  26.376  ops/ms
StringSerializationBenchmark.stringRead           256  russian  thrpt   30   1011.096 ±  12.115  ops/ms
StringSerializationBenchmark.stringRead           256  chinese  thrpt   30    689.678 ±   4.445  ops/ms
StringSerializationBenchmark.stringWrite            4    ascii  thrpt   30  17796.026 ± 143.503  ops/ms
StringSerializationBenchmark.stringWrite            4  russian  thrpt   30  16582.541 ± 372.612  ops/ms
StringSerializationBenchmark.stringWrite            4  chinese  thrpt   30  15225.444 ± 119.326  ops/ms
StringSerializationBenchmark.stringWrite           32    ascii  thrpt   30   9781.345 ± 826.800  ops/ms
StringSerializationBenchmark.stringWrite           32  russian  thrpt   30   8423.629 ±  58.593  ops/ms
StringSerializationBenchmark.stringWrite           32  chinese  thrpt   30   6111.879 ±  37.015  ops/ms
StringSerializationBenchmark.stringWrite          256    ascii  thrpt   30   3620.902 ±  16.969  ops/ms
StringSerializationBenchmark.stringWrite          256  russian  thrpt   30   1801.506 ±  14.516  ops/ms
StringSerializationBenchmark.stringWrite          256  chinese  thrpt   30   1019.450 ±   8.503  ops/ms

Yep, there is a regression for strings shorter than 6 characters, see this more granular benchmark:

Before fallback:

[info] Benchmark                                    (length)  (stringType)  Mode  Cnt   Score    Error  Units
[info] StringSerializerBenchmark.serializeDefault          1         ascii  avgt    5  33.383 ±  2.796  ns/op
[info] StringSerializerBenchmark.serializeDefault          2         ascii  avgt    5  32.731 ±  2.470  ns/op
[info] StringSerializerBenchmark.serializeDefault          3         ascii  avgt    5  37.619 ±  3.950  ns/op
[info] StringSerializerBenchmark.serializeDefault          4         ascii  avgt    5  42.452 ±  3.703  ns/op
[info] StringSerializerBenchmark.serializeDefault          5         ascii  avgt    5  46.887 ±  2.906  ns/op
[info] StringSerializerBenchmark.serializeDefault          6         ascii  avgt    5  57.461 ± 14.265  ns/op
[info] StringSerializerBenchmark.serializeDefault          7         ascii  avgt    5  58.337 ±  2.813  ns/op
[info] StringSerializerBenchmark.serializeImproved         1         ascii  avgt    5  37.015 ± 11.327  ns/op
[info] StringSerializerBenchmark.serializeImproved         2         ascii  avgt    5  40.723 ±  9.182  ns/op
[info] StringSerializerBenchmark.serializeImproved         3         ascii  avgt    5  43.556 ± 10.250  ns/op
[info] StringSerializerBenchmark.serializeImproved         4         ascii  avgt    5  48.410 ± 12.323  ns/op
[info] StringSerializerBenchmark.serializeImproved         5         ascii  avgt    5  47.770 ±  7.285  ns/op
[info] StringSerializerBenchmark.serializeImproved         6         ascii  avgt    5  48.477 ±  7.607  ns/op
[info] StringSerializerBenchmark.serializeImproved         7         ascii  avgt    5  49.082 ± 13.026  ns/op

After fallback:

[info] Benchmark                                    (length)  (stringType)  Mode  Cnt   Score   Error  Units
[info] StringSerializerBenchmark.serializeImproved         1         ascii  avgt    5  31.794 ± 0.898  ns/op
[info] StringSerializerBenchmark.serializeImproved         2         ascii  avgt    5  30.904 ± 0.814  ns/op
[info] StringSerializerBenchmark.serializeImproved         3         ascii  avgt    5  35.260 ± 1.481  ns/op
[info] StringSerializerBenchmark.serializeImproved         4         ascii  avgt    5  40.210 ± 1.505  ns/op
[info] StringSerializerBenchmark.serializeImproved         5         ascii  avgt    5  45.301 ± 2.434  ns/op
[info] StringSerializerBenchmark.serializeImproved         6         ascii  avgt    5  43.255 ± 8.550  ns/op
[info] StringSerializerBenchmark.serializeImproved         7         ascii  avgt    5  45.846 ± 7.652  ns/op

For deserialization, allocating a small buffer is not that much a significant overhead, so the fallback is not really needed:
[info] Benchmark                                        (length)  (stringType)  Mode  Cnt    Score    Error  Units
[info] StringDeserializerBenchmark.deserializeDefault          1         ascii  avgt    5   46.588 ±  4.684  ns/op
[info] StringDeserializerBenchmark.deserializeDefault          2         ascii  avgt    5   58.620 ±  3.946  ns/op
[info] StringDeserializerBenchmark.deserializeDefault          3         ascii  avgt    5   77.313 ± 10.427  ns/op
[info] StringDeserializerBenchmark.deserializeDefault          4         ascii  avgt    5   90.241 ± 10.840  ns/op
[info] StringDeserializerBenchmark.deserializeDefault          5         ascii  avgt    5  102.410 ± 13.860  ns/op
[info] StringDeserializerBenchmark.deserializeDefault          6         ascii  avgt    5  120.779 ± 14.496  ns/op
[info] StringDeserializerBenchmark.deserializeDefault          7         ascii  avgt    5  131.607 ± 14.304  ns/op
[info] StringDeserializerBenchmark.deserializeImproved         1         ascii  avgt    5   51.051 ±  3.370  ns/op
[info] StringDeserializerBenchmark.deserializeImproved         2         ascii  avgt    5   51.510 ±  3.727  ns/op
[info] StringDeserializerBenchmark.deserializeImproved         3         ascii  avgt    5   51.531 ±  5.641  ns/op
[info] StringDeserializerBenchmark.deserializeImproved         4         ascii  avgt    5   51.571 ±  8.137  ns/op
[info] StringDeserializerBenchmark.deserializeImproved         5         ascii  avgt    5   52.366 ±  5.513  ns/op
[info] StringDeserializerBenchmark.deserializeImproved         6         ascii  avgt    5   56.548 ±  7.410  ns/op
[info] StringDeserializerBenchmark.deserializeImproved         7         ascii  avgt    5   52.861 ±  7.447  ns/op

This is nice work, thanks a lot :-)
Could you add a test case that ensures the encoding is still the same? Maybe copy the old String read/write logic and compare it with the new one for some random Strings?

@AHeise thanks for all the ideas, I've updated the PR with all the proposals applied.
As for writeString fallback code, I've found a better way of dealing with short strings, not requiring a separate code path. If you stare long enough in the jmh perfasm listing for short strings, you may notice that most of the time (compared with the original implementation) is spent within initial buffer size computation. In the original unbuffered code there is no reason to compute it, as there is no buffer. But in this PR we need to scan a string twice: to compute the buffer size, and then to write characters to the buffer.
Main idea of this PR is to leverage CPU-level parallelism, helping it to process multiple characters at once. But the problem with short strings is that there is nothing to parallelize, so double-scanning overhead starts to kill the performance.
The proposed fix is to over-allocate the buffer for short strings, skipping the exact buffer size computation. I've found a tipping point for this approach laying somewhere between 6-8 characters:

for strings < 6 chars it's faster to overallocate,
for strings of 6-8 chars it's the same as exact computation,
for strings > 8 chars it can be slower, but insignificantly. But in theory it may produce some GC pressure.

The current round of benchmarks:
[info] Benchmark                                    (length)  (stringType)  Mode  Cnt   Score   Error  Units
[info] StringDeserializerBenchmark.deserializeDefault          1         ascii  avgt   50   45.618 ± 0.339  ns/op
[info] StringDeserializerBenchmark.deserializeDefault          2         ascii  avgt   50   61.348 ± 0.579  ns/op
[info] StringDeserializerBenchmark.deserializeDefault          4         ascii  avgt   50   88.067 ± 1.058  ns/op
[info] StringDeserializerBenchmark.deserializeDefault          8         ascii  avgt   50  142.902 ± 1.121  ns/op
[info] StringDeserializerBenchmark.deserializeDefault         16         ascii  avgt   50  249.181 ± 1.920  ns/op
[info] StringDeserializerBenchmark.deserializeDefault         32         ascii  avgt   50  466.382 ± 1.502  ns/op
[info] StringDeserializerBenchmark.deserializeImproved         1         ascii  avgt   50   49.916 ± 0.132  ns/op
[info] StringDeserializerBenchmark.deserializeImproved         2         ascii  avgt   50   50.278 ± 0.064  ns/op
[info] StringDeserializerBenchmark.deserializeImproved         4         ascii  avgt   50   50.365 ± 0.129  ns/op
[info] StringDeserializerBenchmark.deserializeImproved         8         ascii  avgt   50   52.463 ± 0.301  ns/op
[info] StringDeserializerBenchmark.deserializeImproved        16         ascii  avgt   50   55.711 ± 0.597  ns/op
[info] StringDeserializerBenchmark.deserializeImproved        32         ascii  avgt   50   65.342 ± 0.555  ns/op
[info] StringSerializerBenchmark.serializeDefault              1         ascii  avgt   50   31.076 ± 0.192  ns/op
[info] StringSerializerBenchmark.serializeDefault              2         ascii  avgt   50   31.770 ± 1.811  ns/op
[info] StringSerializerBenchmark.serializeDefault              4         ascii  avgt   50   39.251 ± 0.189  ns/op
[info] StringSerializerBenchmark.serializeDefault              8         ascii  avgt   50   57.736 ± 0.253  ns/op
[info] StringSerializerBenchmark.serializeDefault             16         ascii  avgt   50   94.964 ± 0.514  ns/op
[info] StringSerializerBenchmark.serializeDefault             32         ascii  avgt   50  168.754 ± 1.416  ns/op
[info] StringSerializerBenchmark.serializeImproved             1         ascii  avgt   50   30.145 ± 0.156  ns/op
[info] StringSerializerBenchmark.serializeImproved             2         ascii  avgt   50   30.873 ± 0.274  ns/op
[info] StringSerializerBenchmark.serializeImproved             4         ascii  avgt   50   31.993 ± 0.276  ns/op
[info] StringSerializerBenchmark.serializeImproved             8         ascii  avgt   50   46.220 ± 0.211  ns/op
[info] StringSerializerBenchmark.serializeImproved            16         ascii  avgt   50   50.856 ± 0.826  ns/op
[info] StringSerializerBenchmark.serializeImproved            32         ascii  avgt   50   63.221 ± 1.130  ns/op

So for large strings the new implementation is much faster, and for short it's not regressing (and even slightly faster).

@pnowojski as for large strings, this implementation is also looking quite nice:
Benchmark                                 (lengthStr)   (type)   Mode  Cnt    Score   Error   Units
StringSerializationBenchmark.stringRead          1024    ascii  thrpt   30   70.249 ± 0.458  ops/ms
StringSerializationBenchmark.stringRead          1024  russian  thrpt   30   36.628 ± 0.091  ops/ms
StringSerializationBenchmark.stringRead          1024  chinese  thrpt   30   24.181 ± 0.094  ops/ms
StringSerializationBenchmark.stringRead          4096    ascii  thrpt   30   17.698 ± 0.313  ops/ms
StringSerializationBenchmark.stringRead          4096  russian  thrpt   30    9.086 ± 0.064  ops/ms
StringSerializationBenchmark.stringRead          4096  chinese  thrpt   30    6.048 ± 0.024  ops/ms
StringSerializationBenchmark.stringRead         16384    ascii  thrpt   30    4.382 ± 0.024  ops/ms
StringSerializationBenchmark.stringRead         16384  russian  thrpt   30    2.270 ± 0.008  ops/ms
StringSerializationBenchmark.stringRead         16384  chinese  thrpt   30    1.515 ± 0.007  ops/ms
StringSerializationBenchmark.stringRead         65536    ascii  thrpt   30    1.109 ± 0.005  ops/ms
StringSerializationBenchmark.stringRead         65536  russian  thrpt   30    0.567 ± 0.002  ops/ms
StringSerializationBenchmark.stringRead         65536  chinese  thrpt   30    0.379 ± 0.002  ops/ms
StringSerializationBenchmark.stringWrite         1024    ascii  thrpt   30  175.745 ± 1.416  ops/ms
StringSerializationBenchmark.stringWrite         1024  russian  thrpt   30   52.724 ± 0.231  ops/ms
StringSerializationBenchmark.stringWrite         1024  chinese  thrpt   30   45.952 ± 5.209  ops/ms
StringSerializationBenchmark.stringWrite         4096    ascii  thrpt   30   42.445 ± 0.288  ops/ms
StringSerializationBenchmark.stringWrite         4096  russian  thrpt   30   22.000 ± 0.320  ops/ms
StringSerializationBenchmark.stringWrite         4096  chinese  thrpt   30   13.603 ± 1.681  ops/ms
StringSerializationBenchmark.stringWrite        16384    ascii  thrpt   30    7.062 ± 0.042  ops/ms
StringSerializationBenchmark.stringWrite        16384  russian  thrpt   30    3.532 ± 0.022  ops/ms
StringSerializationBenchmark.stringWrite        16384  chinese  thrpt   30    2.527 ± 0.015  ops/ms
StringSerializationBenchmark.stringWrite        65536    ascii  thrpt   30    1.741 ± 0.007  ops/ms
StringSerializationBenchmark.stringWrite        65536  russian  thrpt   30    0.893 ± 0.002  ops/ms
StringSerializationBenchmark.stringWrite        65536  chinese  thrpt   30    0.635 ± 0.004  ops/ms

Some thoughts for follow-up:

Do you know where exactly the performance difference comes from? Is it mainly the many individual read() single byte operations, that get more efficient if you bulk get into a byte array?

We can actually break the serialization format, as long as we change the StringSerializer config snapshot and restore methods. We can return "needs conversion" as the compatibility and return a serializer with the old encoding as the restore serializer.

Thinking twice, the above would only work if all parts support serializer evoluation, and I think keys in RocksDB cannot be evolved right now (not yet implemented).

@StephanEwen yes, most of the difference comes from multiple single-byte read operations. And CPU cannot parallelize them, as there is a data dependency between characters. Buffering the whole string we improve the situation with parallelism, so CPU can process multiple characters at once.
I've considered breaking the serialization format for strings (and even did an experiment with this approach), but there are a ton of side-effects for end-users (like you've mentioned keys in rocksdb) and the only positive result of this was a slight improvement for long non-ascii strings, compared to the implementation in this PR. I guess it's not worth it :)
I've also added a test for validating binary compatibility of this change.

@shuttie Got it, makes a lot of sense to me.
I was wondering at some point if it would be worthwhile to just "unsafe arraycopy" the char[] from the string to the byte[] in the memory segments or stream buffers. So basically no byte-wise logic at all in the serialization. That would increase the state size (all chars would have two bytes), but might save CPU resources.
Have you ever experimented with something that?

@StephanEwen the only issue with this approach is that the internal binary representation of Strings between jvm8 and jvm9+ is different, see the JEP-254 for the details. So then you will loose the compatibility between JVM versions, that's why it's called Unsafe :)

(for any committer that will be merging this, please wait until the benchmarks are merged first)

(for any committer that will be merging this, please wait until the benchmarks are merged first)
@shuttie I do not understand the results that you posted here. It's in throughput mode, ops/ms, more is better, and it looks like master is out performing the improved version by quite a lot. Did you miss labeled something?

@pnowojski oops, you're right, I've accidentally swapped the labels. I've updated the huge string benchmark results in the post you linked to.

Thanks for all of the work @shuttie.
I will try to merge before the feature freeze for 1.10 release, but I have to wait for green travis build, and there is currently quite long build queue.

Looks like the build passed :-)
BTW, I circumvent the Apache Flink Travis Queue by pushing interesting PRs as branches to my personal repository and free Travis account. That works quite alright.

Thanks for the very detailed analysis and nice contribution @shuttie!


New Version: SoftFever.OrcaSlicer version 2.0.0

Checklist for Pull Requests

[x] Have you signed the Contributor License Agreement?
[ ] Is there a linked Issue?

Manifests

[x] Have you checked that there aren't other open pull requests for the same manifest update/change?
[x] This PR only modifies one (1) manifest
[x] Have you validated your manifest locally with winget validate --manifest <path>?
[ ] Have you tested your manifest locally with winget install --manifest <path>?
[x] Does your manifest conform to the 1.6 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

Hello @og-mrk,
The package manager bot determined there was an issue with installing the application correctly. Please check the application installs correctly. Once repaired, please push an update to your pull request.
Template: msftbot/validationError/installation/general

May I ask for further details on why the validation test(s) failed?

Will convert this PR to Draft until PR #147146 is merged, mainly because I have some speculation around this package depending on vcredist2019 x64 to be installed on the system, so when vcredist2019 x64 is added, I'll update this Manifest.

Hello @og-mrk,
The package manager bot determined there was an issue with installing the application correctly. Please check the application installs correctly. Once repaired, please push an update to your pull request.
Template: msftbot/validationError/installation/general

Any details on why validation tests failed would be appreciated.

Automatic Validation ended with:

Installation failed with exit code -1978334960
2024-03-31 15:31:29.778 [FAIL] D:\a_work\1\s\external\pkg\src\AppInstallerRepositoryCore\RepositorySource.cpp(757)\WindowsPackageManager.dll!00007FFA20A2C11F: (caller: 00007FFA207B8D6F) LogHr(1) tid(196c) 8A15005E     Msg:[D:\a_work\1\s\external\pkg\src\AppInstallerRepositoryCore\Rest\Schema\HttpClientHelper.cpp(30)\WindowsPackageManager.dll!00007FFA20932B08: (caller: 00007FFA209DBC20) Exception(1) tid(196c) 8A15005E ]
2024-03-31 15:31:29.778 [REPO] Failed to open available source: msstore
2024-03-31 15:31:33.863 [FAIL] D:\a_work\1\s\external\pkg\src\AppInstallerRepositoryCore\RepositorySource.cpp(757)\WindowsPackageManager.dll!00007FFA20A2C11F: (caller: 00007FFA207B8D6F) LogHr(1) tid(1424) 8A15005E     Msg:[D:\a_work\1\s\external\pkg\src\AppInstallerRepositoryCore\Rest\Schema\HttpClientHelper.cpp(30)\WindowsPackageManager.dll!00007FFA20932B08: (caller: 00007FFA209DBC20) Exception(1) tid(1424) 8A15005E ]
2024-03-31 15:31:33.864 [REPO] Failed to open available source: msstore
2024-03-31 15:31:41.239 [FAIL] D:\a_work\1\s\external\pkg\src\AppInstallerRepositoryCore\RepositorySource.cpp(757)\WindowsPackageManager.dll!00007FFA04B3C11F: (caller: 00007FFA048C8D6F) LogHr(1) tid(4e8) 8A15005E     Msg:[D:\a_work\1\s\external\pkg\src\AppInstallerRepositoryCore\Rest\Schema\HttpClientHelper.cpp(30)\WindowsPackageManager.dll!00007FFA04A42B08: (caller: 00007FFA04AEBC20) Exception(1) tid(4e8) 8A15005E ]
2024-03-31 15:31:41.239 [REPO] Failed to open available source: msstore
2024-03-31 15:31:44.236 [CLI ] Package hash verification failed. SHA256 in manifest [0685c3054bbc59a1b1502257d0dafdf4dec22f0965ada2ea88939b4f729b795c] does not match download [d652ace87dc6b2b4bcf85e17e099a6928414134a71e4f5e45e580148c759a685]

(Automated response - build 876.)

Automatic Validation ended with:

Installation failed with exit code -1978334960
...
2024-03-31 15:31:44.236 [CLI ] Package hash verification failed. SHA256 in manifest [0685c3054bbc59a1b1502257d0dafdf4dec22f0965ada2ea88939b4f729b795c] does not match download [d652ace87dc6b2b4bcf85e17e099a6928414134a71e4f5e45e580148c759a685]

(Automated response - build 876.)
Edit: Neither of those hashes match the InstallerSha256 in this manifest - because it's the dependency Microsoft.EdgeWebView2Runtime with the out-of-date InstallerSha256.

I've looked into Microsoft's Edge WebView 2 Runtime package, and it turns out the Installer Manifests for it uses a this link, which changes overtime.
So I've a solution to give if it's possible to do so, which's utilizing Microsoft Update Catalog to retrieve pretty much all versions a user/package maintainer will ever need, but I don't know if this will break The Terms of Service that Microsoft has when we use the static download links they provide in this particular case, if you have a resource to direct me in the right direction, then it'll be of great help.
Also there's a way to automate the retrieval of all down links from a Search Query, using something like PowerShell Modules, so Implementing a simple script that automates this process is relatively easy if you know what you're doing.

I've looked into Microsoft's Edge WebView 2 Runtime package, and it turns out all versions of Installer Manifests uses this download link, which changes overtime.

Ah, we call this a "vanity URL" and we have many in our repo. Keeping all of their manifests updated with the current installer hash is a constant task.

So I've a solution to give if it's possible to do so, which's utilizing Microsoft Update Catalog to retrieve pretty much all versions a user/package maintainer will ever need, but I don't know if this will break The Terms of Service that Microsoft has when we use the static download links they provide in this particular case, if you have a resource to direct me in the right direction, then it'll be of great help.
Note
The Installers provided in Microsoft Update Catalog are Standalone, Platform Specific Installers (x86, amd64/x64, arm64 etc...), so every Installer Manifest, for every version Requires having all of the Different Installers specified, meaning we can't use a "Bootstrap" installation method, like the one currently being used in Edge Webview2 Runtime Package.

This implies that the manifest will need to detail every installer and location. There would be a measurable increase in the level of effort required to generate this package's manifest.

Also there's a way to automate the retrieval of all down links from a Search Query, using something like PowerShell Modules, so Implementing a simple script that automates this process is relatively easy if you know what you're doing.

This might be better as an input into one of our several manifest creation tools.

@wingetbot run

https://github.com/microsoft/winget-pkgs/issues/107639

This package installs and launches normally on a Windows 10 VM.


feat: OpenAPI tool extracts POST operations

#1082
#1084
#1083  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @Cobalt0s and the rest of your teammates on  Graphite

#1082
#1084
#1083  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @Cobalt0s and the rest of your teammates on  Graphite


Error on "Load driving video and source image" section of colab

RuntimeError                              Traceback (most recent call last)
 in ()
9
10 source_image = imageio.imread('/content/gdrive/My Drive/first-order-motion-model/ev2.jpg')
---> 11 driving_video = imageio.mimread('/content/gdrive/My Drive/first-order-motion-model/brnew.mp4')
12
13
/usr/local/lib/python3.6/dist-packages/imageio/core/functions.py in mimread(uri, format, memtest, **kwargs)
305             ims[:] = []  # clear to free the memory
306             raise RuntimeError(
--> 307                 "imageio.mimread() has read over 256 MiB of "
308                 "image data.\nStopped to avoid memory problems."
309                 " Use imageio.get_reader() or memtest=False."
RuntimeError: imageio.mimread() has read over 256 MiB of image data.
Stopped to avoid memory problems. Use imageio.get_reader() or memtest=False.

driving_video = imageio.mimread('/content/gdrive/My Drive/first-order-motion-model/brnew.mp4', memtest=False)
seems to work, is there a reason not to add memtest=False?

If size of the video is too large it will cause notebook to crash.

The result from "Load driving video and source image" and the end result of the animated image. The original video is around 29 seconds, the end result is 44.

You should set fps. Imageio.mimsave(...,fps=...)

I ended up cloning the git via anaconda and running it locally. Now it works great! Is there a tutorial on how to get face-swap to work?

Same problem.
From the documentation here, I just tried to disable memtest and its work for me.

Did you disable the memtest with memtest=False?
If so where and how did you use this line?

Did you disable the memtest with memtest=False?
If so where and how did you use this line?
@animemoeus

Really? Then I mist be doing something else wrong. Thanks

@MaalikN did you solve your video slowing down issue? I was able to bypass the error with memtest=False but I still get a 23 sec video rather than 15 sec as my original video is

@kcrank1 I ended up just setting it up on my own computer to run on my hardware instead of google colab. When running on my own gpu it doesn't slow the video down. A solution that I used previously though, was to compare the length of the driving video and the length of the produced video to find what percent the produced one was slowed down by. Then you can speed it up by the exact amount in most editing software.

@MaalikN that's a great workaround.  What I ended up doing to get around the problem was noticing that the output video was 20fps, if I edited my input video to be 20fps going in it preserved the speed.

How can I solve this problem?

How can I solve this problem? The video length of my training data and test data is about 10 seconds. There are 2000 training data and 500 test data. dataset is mp4 file, picture length:1920 picture width:1080 fps:60

go to frames_dataset.py and change mimread(name) to mimread(name,memtest=False)


Sync

Keep develop up-to-date.

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Write some getting started guide

There are many parts which should be updated when creating an api based on this boilerplate. Maybe we should have a list for that?

👍

👍


⚠ Bofrost.de has degraded performance

In cc48ee5, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 974 ms

Resolved: Bofrost.de performance has improved in 614fe4a after 6 minutes.


Fix: category names in Discover Dapps

Make Games and Tools plural and fix spelling variations: Financial vs Finance.

cc @JamesSmartCell in case this affects you too.


I did a tiny change made new coming pic named by date.  i wonder how to store a whole day's pic and make backgroud replay?

I did a tiny change made new coming pic named by date.  i wonder how to store a whole day's pic and make backgroud replay?
himawaripy/confif.py
output_file = os.path.join(appdirs.user_cache_dir(appname="himawaripy",
appauthor=False),
time.ctime()  )
^^^^^^^^^^^
this will store everyday's pic....and will take huge space....but,we just need one days loop....

i donno if its properly write here.this is not some kindof issue.more like a new function request...
maybe someone can tell me ?

himawaripy is to fetch (almost) real-time picture of Earth, not to cycle old images of it, although that's also understandable.
You can save the photos as you said in a directory and then loop over them to change wallpaper in every 10 minutes. KDE supports this out-of-the-box I think, but you can always write a script.
Closing the issue as it's not relevant to himawaripy.


Vulkan: Allow GVRGazeCursorController to work from any camera position

Merge of https://github.com/Samsung/GearVRf/pull/1332

https://github.com/Samsung/GearVRf/pull/1332 was merged


New Features

I'm just going to leave this here so everyone knows why features aren't going to be implemented super fast right now. Currently, I'm working on changing the way ships are formed as well as separating code related to tile entities and such into a library. This way the actual mod can simply hold information about how to move ships, where to move them, when to move them, who can move them, etc. This will take some time and if I choose a set date I can guarantee I won't make it at that time. So for now it'll be done "Soon™"

I always appreciate refactoring old code to prepare it for new requirements!
Good to hear that you are actively improving the code quality.

very much looking forwards to see what you do.
When you are ready to start adding or changeing things. i may be able to help with some blocks/textures.

Update: All code has been moved, most code is working, all that needs to be done now is adding back seats, and engines. Then bugtesting.

Glad you're leading the charge with this mod. I look forward to following your progress.

Are you still looking for help, and how can we help you?

@Alaberti Read the project readme, if you are interested in being a long term dev of the mod with me then please give me a direct message on the minecraft forums as to what you're interested in doing.

Complete.

okay i am quoting a suggestion from someone who has yet to put it in the github (from Luvatar)
the quote is:
This mod is actually my favorite addition to Terrafirma, which has so much "traveling" into it that having a move-able base is wonderful. I'm sure that making two mods work together is much more hassle than what is typically requested of modders, but I still want to make this request because Terrafirma and Archimedes ships are just so wonderful together.
Here are some of the issues I've found:

A lot of blocks don't stay oriented the same way after landing. Chests, Fence Gates, Chiseled blocks, planks, etc. This isn't an issue with carpenter's blocks blocks, so I don't know why it's different.

Every time I board the ship I get an "oak" duplicate of any chest/barrel that is on the ship. This is mostly an annoyance.

It seems that non-vanilla entities don't get transported in the crates. This was a huge letdown after having seeing it work before :/ EDIT: Actually I just tested it a bit and it seems to not be terra-firma related but rather something to do with being underwater when the ship is formed. As the ship formed the mobs floated for a milisecond, that caused them to be "moved" out of the crate it seems. Just managed to move some non-vanilla entities :)

There is a weird major bug involving a chisseled block with a Lantern and an adjasent fence post that makes the entire display go bonkers for anyone within sight of the ship. (No crash, but game is unplayable). I had to exit the world and delete the mod blocks by myself to make the chunks around the ship usable again. This is a very obscure bug to replicate but I mostly suspect it has something to do with the chisseled blocks bug.

As for non-Terrafirma related requests I have 2:

Maybe make a special Bed that won't break your spawn point if you move the ship. We like to make the ship a mobile base and having someone die just to re-spawn at the world spawn point instead of at the ship because he forgot to re-sleep after moving it is annoying.

Maybe add a special ship helm and buffers for "Sub-ships". Our big, floating base can realistically only land on Water, and when we are in the middle of a large land-mass, we like to leave it floating high and use smaller ships to land. Currently the only way of doing this is destroying the blocks anchoring both the Mother ship and the smaller one, or use an elaborate piston design to do that for us. I mean, the pistol design is kind of cool, but having core-mod options for that would be neat.

Also, not so much a bug report but something that I'd like to understand from the mod. Our ship "beta" design floated pretty decently while it was on its ugly form. However, once we changed the outer blocks for stairs to give it a more defined curve it seems like it lost bouyancy, a lot. I'm unsure if it was because it was carpenters block stairs or simply because stairs dont count as well for the bouyancy, but it made us add a ton of floaters to keep it on the level it was before.


⚠ Processors has degraded performance

In ca4d4c5, Processors ($STATUS_URL) experienced degraded performance:

HTTP code: 200
Response time: 49 ms

Resolved: Processors performance has improved in 2d40cf5.


More examples with dllexport (class, typedef, using)

It would be nice to have more usage examples for dllexport, and its usage within a macro:
#define DllImport   __declspec( dllimport )
#define DllExport   __declspec( dllexport )

DllExport void func();
DllExport int i = 10;
DllImport int j;
DllExport int n;

class DllExport S
{
};

typedef DllExport T S;

using T = S DllExport; // ??? not so sure how to use dll export with using - that's the info I was looking for.

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

ID: b536f720-0b84-9bb0-51a8-c58c653f10f1
Version Independent ID: a778134d-f07c-0c55-694f-536f891b048b
Content: dllexport, dllimport
Content Source: docs/cpp/dllexport-dllimport.md
Product: visual-cpp
Technology: cpp-language
GitHub Login: @corob-msft
Microsoft Alias: corob

@Thieum
Perhaps we've not been clear enough about what it means for types to have __declspec(something) applied to them. The named type keeps that attribute, and you don't normally need to repeat it when you use the type name.
That's why your example doesn't quite make sense to me. What are you trying to do with the extra DllExport in your typedef and using examples? It seems redundant:
#define DllImport   __declspec( dllimport )
#define DllExport   __declspec( dllexport )

class DllExport S
{
};

typedef S T1; // T1 is now a typedef for S, including its dllexport attribute

using T2 = S; // T2 is now an alias for S, including its dllexport attribute

There's no way I know of to create either a typedef or an alias that adds __declspec(dllexport) to a type that isn't itself declared that way, if that was your intent.

@corob-msft aah it seems it was a useless tradition in our codebase to annotate the typedefs that way. I'm really unsure of where it comes from, and since it generates no warning, it's been kept that way. Thanks a lot for pointing this out, it will help us clean this up!


Support for looking up credentials for multiple sites

We have a shared credential system, so you can have the same login for parentsite.com and childsitewithadifferentdomain.com; some users only have it saved for one. Have you guys considered the ability to look up any credentials for a set of domains?

Hi @maxdisney,
Thanks for taking the time to write to us :+1:
Searching Logins for multiple domains has been requested several times in the past (see #131 and all the related issues). So we implemented the Show all Logins feature in the recently release 1Password 5.3 for iOS.

So here's how the Show all Logins feature works in 1Password 5.3:

Your app will still use for a single and unique URL string. Let's say ** parentsite.com**
If now matching Login is found in the user's database the Show all Logins "button" will show up.
The user taps on it.
All logins will now be shown.
The user can scroll or search through the entire list for the desired Login, in this case for ** childsitewithadifferentdomain.com**

Hope that this helps :smile:
I will close this issue for now as a duplicate. Please feel free to comment on #131 in order to keep all the comments in one place.
Cheers!


Fix Mandatory and Cardinality fields

Today while going through the specification we believe we found some inconsistencies.

Thanks a lot for the findings!


quantitative result

Thank you for your article. I followed the guidance of readme, but the quantitative results could not reach that in the paper. At the current stage, I only tried rain100L. Can you provide your email? (I've tried your previous mailbox can't receive mail)  I really want to ask you about the problems I encounter. Thanks a lot.

Thanks for your attention. If you have any questions, please contact my email<EMAIL_ADDRESS>


Logging fixes

Purpose

Describe the problems, issues, or needs driving this feature/fix and include links to related issues.

Fixes #
Approach

Describe how you are implementing the solutions along with the design details.

Samples

Provide high-level details about the samples related to this feature.

Remarks

List any other known issues, related PRs, TODO items, or any other notes related to the PR.

Check List

[ ] Read the Contributing Guide
[ ] Required Balo version update
[ ] Updated Change Log
[ ] Checked Tooling Support (#)
[ ] Added necessary tests

[ ] Unit Tests
[ ] Spec Conformance Tests
[ ] Integration Tests
[ ] Ballerina By Example Tests

[ ] Increased Test Coverage
[ ] Added necessary documentation

[ ] API documentation
[ ] Module documentation in Module.md files
[ ] Ballerina By Examples

Codecov Report

Merging #19184 into next-release will decrease coverage by 4.78%.
The diff coverage is n/a.

@@               Coverage Diff                @@
##           next-release   #19184      +/-   ##
================================================
- Coverage         20.51%   15.73%   -4.79%
================================================
  Files                52       47       -5
  Lines              1394     1265     -129
  Branches            216      197      -19
================================================
- Hits                286      199      -87
+ Misses             1095     1053      -42
  Partials             13       13

Impacted Files
Coverage Δ

composer/packages/tracing/src/ToolBar.tsx

composer/packages/tracing/src/TraceList.tsx

composer/packages/tracing/src/DetailView.tsx

composer/packages/tracing/src/TraceLogs.tsx

composer/packages/tracing/src/index.ts

Continue to review full report at Codecov.

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


vcpkg install zlib refers to a non-exist port

vcpkg install zlib refers to a non-exist port that's cleaned by git reset --hard
λ grep -r basic-tools versions\
(empty)
λ grep -r basic-tools ports\
(empty)
λ vcpkg install --triplet=x64-windows zlib
Error: while loading basic-tools:
The port directory (path\to\vcpkg\ports\basic-tools) does not exist
Error: failed to load port from path\to\vcpkg\ports\basic-tools
Note: Updating vcpkg by rerunning bootstrap-vcpkg may resolve this failure.

After redoing everything including fork, the problem is solved.