Vulkan Panic: ERROR_INITIALIZATION_FAILED on NV

Short info header:

GFX version: 0.7.0
OS: Ubuntu 20.04 LTS.
GPU: NVidia 3070, driver 460.32.03

Panicked at 'internal error: entered unreachable code: Unexpected result - driver bug? Err(ERROR_INITIALIZATION_FAILED)', /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/gfx-backend-vulkan-0.7.0/src/device.rs:1953:18
Looking at the code in device.rs, it looks like the Vulkan driver returned ERROR_INITIALIZATION_FAILED and the code in device.rs didn't have a match case for that, so it reached the default case and panicked.
Why the driver returned that status I do not know. There are recent reports on NVidia forums of games crashing with that error:
https://www.nvidia.com/en-us/geforce/forums/game-ready-drivers/13/428627/vulkan-errorinitializationfailed-on-win10-with-gtx/
So NVidia may have changed something that affects this.
This is from a program of mine using "rend3", which uses "gfx". It's happened twice, both times during window resizing. It's just loading a big scene into the GPU, which can then be explored. Visually, everything looks fine. My program, which is 100% safe Rust, is not doing much except refreshing the scene and responding to window events.
Backtraces follow:
00002 frames over 01.15s. Min: 558.37ms; Average: 576.98ms; 95%: 595.59ms; 99%: 595.59ms; Max: 595.59ms; StdDev: 18.61ms
00002 frames over 01.18s. Min: 588.25ms; Average: 589.56ms; 95%: 590.87ms; 99%: 590.87ms; Max: 590.87ms; StdDev: 01.31ms
thread '' panicked at 'internal error: entered unreachable code: Unexpected result - driver bug? Err(ERROR_INITIALIZATION_FAILED)', /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/gfx-backend-vulkan-0.7.0/src/device.rs:1953:18
stack backtrace:
0: rust_begin_unwind
at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/panicking.rs:495:5
1: std::panicking::begin_panic_fmt
at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/panicking.rs:437:5
2: gfx_backend_vulkan::device::::create_swapchain
at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/gfx-backend-vulkan-0.7.0/src/device.rs:1953:18
3: <gfx_backend_vulkan::window::Surface as gfx_hal::window::PresentationSurface<gfx_backend_vulkan::Backend>>::configure_swapchain
at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/gfx-backend-vulkan-0.7.0/src/window.rs:367:35
4: wgpu_core::device::<impl wgpu_core::hub::Global>::device_create_swap_chain
at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-core-0.7.0/src/device/mod.rs:4180:13
5: <wgpu::backend::direct::Context as wgpu::Context>::device_create_swap_chain
at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-0.7.0/src/backend/direct.rs:801:15
6: wgpu::Device::create_swap_chain
at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-0.7.0/src/lib.rs:1623:17
7: rend3::renderer::util::create_swapchain
at /home/john/.cargo/git/checkouts/rend3-e03f89403de3386a/c51c19f/rend3/src/renderer/util.rs:10:5
8: rend3::renderer::resources::RendererGlobalResources::update::{{closure}}
at /home/john/.cargo/git/checkouts/rend3-e03f89403de3386a/c51c19f/rend3/src/renderer/resources.rs:81:39
9: core::option::Option::map
at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/core/src/option.rs:453:29
10: rend3::renderer::resources::RendererGlobalResources::update
at /home/john/.cargo/git/checkouts/rend3-e03f89403de3386a/c51c19f/rend3/src/renderer/resources.rs:81:17
11: rend3::renderer::render::render_loop::{{closure}}
at /home/john/.cargo/git/checkouts/rend3-e03f89403de3386a/c51c19f/rend3/src/renderer/render.rs:390:13
12: <core::future::from_generator::GenFuture as core::future::future::Future>::poll
at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/core/src/future/mod.rs:80:19
13: <tracing_futures::Instrumented as core::future::future::Future>::poll
at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/tracing-futures-0.2.4/src/lib.rs:258:9
14: <std::panic::AssertUnwindSafe as core::future::future::Future>::poll
at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/panic.rs:339:9
15: <std::panic::AssertUnwindSafe as core::future::future::Future>::poll
at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/panic.rs:339:9
16: <switchyard::CatchUnwind as core::future::future::Future>::poll::{{closure}}
at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/switchyard-0.1.1/src/lib.rs:179:42
17: <std::panic::AssertUnwindSafe as core::ops::function::FnOnce<()>>::call_once
at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/panic.rs:322:9
18: std::panicking::try::do_call
at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/panicking.rs:381:40
19: __rust_try
20: std::panicking::try
at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/panicking.rs:345:19
21: std::panic::catch_unwind
at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/panic.rs:396:14
22: <switchyard::CatchUnwind as core::future::future::Future>::poll
at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/switchyard-0.1.1/src/lib.rs:179:9
23: switchyard::Switchyard::spawn_local::{{closure}}::{{closure}}
at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/switchyard-0.1.1/src/lib.rs:502:32
24: <core::future::from_generator::GenFuture as core::future::future::Future>::poll
at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/core/src/future/mod.rs:80:19
25: <core::pin::Pin as core::future::future::Future>::poll
at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/core/src/future/future.rs:119:9
26: switchyard::task::ThreadLocalTask::poll
at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/switchyard-0.1.1/src/task.rs:270:26
27: switchyard::worker::body::{{closure}}
at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/switchyard-0.1.1/src/worker.rs:132:34
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
thread 'main' panicked at 'Job panicked!', /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/switchyard-0.1.1/src/lib.rs:153:78
stack backtrace:
0: std::panicking::begin_panic
at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/panicking.rs:521:12
1: <switchyard::JoinHandle as core::future::future::Future>::poll::{{closure}}
at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/switchyard-0.1.1/src/lib.rs:153:78
2: core::result::Result<T,E>::unwrap_or_else
at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/core/src/result.rs:825:23
3: <switchyard::JoinHandle as core::future::future::Future>::poll
at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/switchyard-0.1.1/src/lib.rs:153:53
4: pollster::block_on
at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/pollster-0.2.1/src/lib.rs:131:15
5: slscenetester::displaystate::{{closure}}
at /home/john/projects/sl/SL-test-viewer/slscenetester/src/main.rs:496:13
6: winit::platform_impl::platform::sticky_exit_callback
at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.24.0/src/platform_impl/linux/mod.rs:736:5
7: winit::platform_impl::platform::x11::EventLoop::run_return
at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.24.0/src/platform_impl/linux/x11/mod.rs:320:21
8: winit::platform_impl::platform::x11::EventLoop::run
at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.24.0/src/platform_impl/linux/x11/mod.rs:398:9
9: winit::platform_impl::platform::EventLoop::run
at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.24.0/src/platform_impl/linux/mod.rs:652:56
10: winit::event_loop::EventLoop::run
at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.24.0/src/event_loop.rs:154:9
11: slscenetester::displaystate
at /home/john/projects/sl/SL-test-viewer/slscenetester/src/main.rs:342:5
12: slscenetester::main
at /home/john/projects/sl/SL-test-viewer/slscenetester/src/main.rs:616:5
13: core::ops::function::FnOnce::call_once
at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/core/src/ops/function.rs:227:5

Let's make the backend expect this error and turn it into a swapchain creation failure.


add operator registation

Signed-off-by: jie.hou<EMAIL_ADDRESS>#777

Codecov Report

Merging #809 (23dd85e) into main (c998703) will decrease coverage by 0.07%.
The diff coverage is 69.23%.

:exclamation: Current head 23dd85e differs from pull request most recent head d92c4ac. Consider uploading reports for the commit d92c4ac to get more accurate results

@@            Coverage Diff             @@
##             main     #809      +/-   ##
==========================================
- Coverage   70.80%   70.72%   -0.08%
==========================================
  Files         169      170       +1
  Lines        7723     7771      +48
  Branches     1267     1282      +15
==========================================
+ Hits         5468     5496      +28
- Misses       1880     1891      +11
- Partials      375      384       +9

Impacted Files
Coverage Δ

towhee/engine/operator_registry.py
79.68% <69.23%> (-6.36%)
:arrow_down:

towhee/hub/repo_manager.py
80.18% <0.00%> (-0.91%)
:arrow_down:

towhee/models/layers/patch_embed3d.py
55.55% <0.00%> (ø)

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 c998703...d92c4ac. Read the comment docs.

/approve
/lgtm


get prediction of all zero with model trained by train_with_point_label.ipynb on custom dataset

Hi,
Thank you very much for the great work! I tried running the "train_with_point_label.ipynb" notebook with the version "https://github.com/jiyuuchc/lacss@lacss1" a few weeks ago, and it worked fine on my custom data by fine-tuning cnsp4_bf.
However, when I tried running the "train_with_point_label.ipynb" notebook with the latest version "https://github.com/jiyuuchc/lacss" on my custom data, it appears to be training from scratch. The data and training process seem fine, as shown below:
| 0/300000 [00:00<?, ?it/s]
1%| | 2999/300000 [42:55<28:46:25,  2.87it/s]
{'lpn_detection_loss': Array(0.03247223, dtype=float32), 'lpn_localization_loss': Array(0.14013271, dtype=float32), 'cks_loss': Array(0.09420827, dtype=float32)}
2%|▏ | 5999/300000 [1:01:16<28:27:13,  2.87it/s]
{'lpn_detection_loss': Array(0.02858079, dtype=float32), 'lpn_localization_loss': Array(0.09101011, dtype=float32), 'cks_loss': Array(0.04471501, dtype=float32)}
3%|▎ | 8999/300000 [1:18:53<28:12:33,  2.87it/s]
{'lpn_detection_loss': Array(0.02592689, dtype=float32), 'lpn_localization_loss': Array(0.06829988, dtype=float32), 'cks_loss': Array(0.04519194, dtype=float32)}
4%|▍ | 11999/300000 [1:36:28<27:59:13,  2.86it/s]
{'lpn_detection_loss': Array(0.02397426, dtype=float32), 'lpn_localization_loss': Array(0.05469975, dtype=float32), 'cks_loss': Array(0.04542798, dtype=float32)}
5%|▍ | 14999/300000 [1:54:10<27:45:09,  2.85it/s]
{'lpn_detection_loss': Array(0.02224915, dtype=float32), 'lpn_localization_loss': Array(0.04505339, dtype=float32), 'cks_loss': Array(0.04553268, dtype=float32)}
6%|▌ | 17999/300000 [2:11:46<27:20:02,  2.87it/s]
{'lpn_detection_loss': Array(0.02016803, dtype=float32), 'lpn_localization_loss': Array(0.03658255, dtype=float32), 'cks_loss': Array(0.04552186, dtype=float32)}
7%|▋ | 20999/300000 [2:29:23<28:07:17,  2.76it/s]
{'lpn_detection_loss': Array(0.01837666, dtype=float32), 'lpn_localization_loss': Array(0.03024506, dtype=float32), 'cks_loss': Array(0.04559031, dtype=float32)}
8%|▊ | 23999/300000 [2:47:45<26:47:53,  2.86it/s]
{'lpn_detection_loss': Array(0.01599549, dtype=float32), 'lpn_localization_loss': Array(0.02466933, dtype=float32), 'cks_loss': Array(0.04583083, dtype=float32)}
9%|▉ | 26999/300000 [3:05:21<26:24:23,  2.87it/s]
{'lpn_detection_loss': Array(0.01445515, dtype=float32), 'lpn_localization_loss': Array(0.02131219, dtype=float32), 'cks_loss': Array(0.04604229, dtype=float32)}
10%|▉ | 29999/300000 [3:23:03<26:11:34,  2.86it/s]
{'lpn_detection_loss': Array(0.01297874, dtype=float32), 'lpn_localization_loss': Array(0.01888342, dtype=float32), 'cks_loss': Array(0.04607417, dtype=float32)}
11%|█ | 32999/300000 [3:40:38<25:47:36,  2.88it/s]
The lpn_localization_loss decreases to 0.0015185 after 300,000 epochs, but the prediction for one of the training images is all zeros. Could you please provide some guidance on what might be going wrong here?
Many thanks!

Thanks for the report.
My guess is that your results were due to the model collapse problem. Adjust some training hyperparameter might be sufficient to prevent it.
Do this before you initialize the trainer.
CKS.config.w = 0.01

This increase the weight of minimal-cell-size-loss.
Ji

With CKS.config.w = 0.01, it worked now. Thank you very much!

I have another question. If I want to fine-tune your pretrained model on custom data using the train_with_point_label.ipynb notebook, could you provide some guidance on how to do that?


Minor optimizations pass.

Takes advantage of a few additional optimization opportunities, especially when only a single queue is in use.
Before:
tiny   + single-queue: 101483 iters ran in average 0.027 ± 0.008 ms (0.16% ± 0.05% of 16.6 ms)
tiny   + multi-queue :  63530 iters ran in average 0.050 ± 0.007 ms (0.30% ± 0.04% of 16.6 ms)
small  + single-queue:  15568 iters ran in average 0.195 ± 0.019 ms (1.17% ± 0.11% of 16.6 ms)
small  + multi-queue :   8918 iters ran in average 0.384 ± 0.050 ms (2.32% ± 0.30% of 16.6 ms)
medium + single-queue:   4605 iters ran in average 0.684 ± 0.080 ms (4.12% ± 0.48% of 16.6 ms)
medium + multi-queue :   2795 iters ran in average 1.248 ± 0.073 ms (7.52% ± 0.44% of 16.6 ms)
large  + single-queue:    293 iters ran in average 12.218 ± 0.440 ms (73.60% ± 2.65% of 16.6 ms)
large  + multi-queue :    182 iters ran in average 20.427 ± 0.705 ms (123.05% ± 4.25% of 16.6 ms)
huge   + single-queue:    162 iters ran in average 22.301 ± 0.904 ms (134.34% ± 5.44% of 16.6 ms)
huge   + multi-queue :    105 iters ran in average 35.773 ± 0.985 ms (215.50% ± 5.93% of 16.6 ms)

After:
tiny   + single-queue: 124558 iters ran in average 0.019 ± 0.003 ms (0.12% ± 0.02% of 16.6 ms)
tiny   + multi-queue :  70690 iters ran in average 0.043 ± 0.006 ms (0.26% ± 0.04% of 16.6 ms)
small  + single-queue:  19696 iters ran in average 0.138 ± 0.013 ms (0.83% ± 0.08% of 16.6 ms)
small  + multi-queue :   9779 iters ran in average 0.343 ± 0.032 ms (2.06% ± 0.19% of 16.6 ms)
medium + single-queue:   6166 iters ran in average 0.456 ± 0.047 ms (2.75% ± 0.28% of 16.6 ms)
medium + multi-queue :   3148 iters ran in average 1.078 ± 0.066 ms (6.49% ± 0.40% of 16.6 ms)
large  + single-queue:    461 iters ran in average 6.989 ± 0.592 ms (42.10% ± 3.57% of 16.6 ms)
large  + multi-queue :    226 iters ran in average 15.993 ± 0.660 ms (96.34% ± 3.98% of 16.6 ms)
huge   + single-queue:    293 iters ran in average 11.099 ± 0.541 ms (66.86% ± 3.26% of 16.6 ms)
huge   + multi-queue :    135 iters ran in average 26.934 ± 0.881 ms (162.25% ± 5.31% of 16.6 ms)

Could you also check that result isn't different?

I can manually check that the result makes sense, I guess, but this will shuffle change the ordering of passes chosen with a single queue, I'd imagine.

Definitely has issues.

Should be ready for review/pull at this point.

Sorry for the delay. I fixed the issue with queue_state.


box64: More platforms, dynarec option, hello test, extra maintainer

Description of changes

box64 also supports 64-bit riscv and powerpc64le, I lack the hardware to test but pkgsCross.riscv64.box64 works and there should be no harm in adding platforms upstream says they support. If they end up being broken on our end, we'll add them to meta.broken instead.
Removed custom checkPhase, a make call with the same outcome should happen as long as doCheck = true
Added an option for controlling if dynamic recompilation is enabled, and a corresponding test in installCheckPhase to make sure the setting was honoured
Added a test that runs hello for x86_64-linux via box64. This required moving most of the derivation into the let so the withDynarec option is correctly honoured even when overridden
Added myself as maintainer, if you don't mind. I have a game I'm currently invested in, for which I need to use box64 when I want to play it on my aarch64-linux laptop.

Things done

Built on platform(s)

[ ] x86_64-linux
[x] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/1636


Update Basics codelab to Compose 6922857 snapshot

Upgrade to AGP 4.2 alpha 15
Upgrade to Gradle 6.7
Icon migrates from androidx.compose.foundation to androidx.compose.material

LGTM!


Proposal: Add Multiple style to one control

I think it is useful to add multiple styles to one control like HTML and CSS.

@khoshroomahdi how would you envision this working with templates within styles or conflicting property values?  Would the list of styles applied to a control be ordered and be applied FIFO or LIFO?

I prefer LIFO.

Other than moving closer to CSS and HTML, could you provide some example uses for such a feature?

Are you proposing that the Style property is actually a List and we combine the styles together? Some code samples + expected output would be helpful for understanding the suggestion.

For example i have some styles for button, some for colors and some for size
I should to use both for one button
Style="{staticresource style1 style2}"

I get you now @khoshroomahdi  Having a style for a control, made up from a button colour, or a font size.  It can be done by making each element a StaticResource, and making a style from those Resources (this is how the default control templates work) - but you want the style to be made dynamically, just by applying a list/collection of styles.

I want just applying a list of styles.

I don't know if that would play well with the fact that Styles are typed (TargetType=Class), in css you can write any rule in a class and apply to any element and rules that don't apply just get ignored.

StyleOverride seems like a neat solution/suggestion.
As for how it applies, and effects inheritence - perhaps it is like a class in CSS, where as the Style with its typing, would be like an ID in CSS.  Eitherway it should work like CSS does, as developers will find that familiar.

There's a BasedOn in XAML Style element, but the resource must be target typed either to a base class of the target type or the target type itself.

There is another Xaml framework, which already supports CSS-like styles - Avalonia.
Each ui element can has multiple classes in "Classes" field separated by space.
And each concrete style can target multiple classes with Or (css-like) selector:
https://github.com/AvaloniaUI/Avalonia/pull/2345/files#diff-acd57219d354b2ac1ad9989ae377db10R14
More information about styles in Avalonia docs:
http://avaloniaui.net/docs/styles/styles
And more about css-like selectors:
http://avaloniaui.net/docs/styles/selectors
Note, that there is no documentation for 'Or' selector for now.
Also Avalonia guys work on xaml AOT-compiling (XamlIL), and  style selectors are already parsed and compiled. But they always should be typed for that case, as I know. So it works without additional time wasting in runtime.


docker build/pull fails with "Driver * failed to create image rootfs" on a specific image

[pid  4887] read(13,  <unfinished ...>
[pid  4887] unlink("/var/lib/docker/graph/dc921aeac8d06e7bd5b2d85b8684bb7c94ed08db3f18a9b6e897827810b289de") = -1 ENOENT (No such file or directory)
[pid  4887] rmdir("/var/lib/docker/graph/dc921aeac8d06e7bd5b2d85b8684bb7c94ed08db3f18a9b6e897827810b289de") = -1 ENOENT (No such file or directory)
[pid  4887] unlink("/var/lib/docker/overlay/dc921aeac8d06e7bd5b2d85b8684bb7c94ed08db3f18a9b6e897827810b289de") = -1 ENOENT (No such file or directory)
[pid  4887] rmdir("/var/lib/docker/overlay/dc921aeac8d06e7bd5b2d85b8684bb7c94ed08db3f18a9b6e897827810b289de" <unfinished ...>
[pid  4887] stat("/var/lib/docker/graph/_tmp/41ca02d9c383106b6a174a43408a793f86fecbc590037d70c113bfbdf1b72364", 0xc2085a6ab0) = -1 ENOENT (No such file or directory)
[pid  4887] stat("/var/lib/docker/graph/_tmp", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
[pid  4887] mkdir("/var/lib/docker/graph/_tmp/41ca02d9c383106b6a174a43408a793f86fecbc590037d70c113bfbdf1b72364", 0700 <unfinished ...>
[pid  4887] chown("/var/lib/docker/graph/_tmp/41ca02d9c383106b6a174a43408a793f86fecbc590037d70c113bfbdf1b72364", 0, 0) = 0
[pid  4887] stat("/var/lib/docker/overlay", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid  4887] chown("/var/lib/docker/overlay", 0, 0 <unfinished ...>
[pid  4887] mkdir("/var/lib/docker/overlay/dc921aeac8d06e7bd5b2d85b8684bb7c94ed08db3f18a9b6e897827810b289de", 0700) = 0
[pid  4887] chown("/var/lib/docker/overlay/dc921aeac8d06e7bd5b2d85b8684bb7c94ed08db3f18a9b6e897827810b289de", 0, 0) = 0
[pid  4887] lstat("/var/lib/docker/overlay/4c0cc976b7bbefe9abdfd8f0aae1bb3759004d3c9888c3164b38909b862c0cdf",  <unfinished ...>
[pid  4887] unlink("/var/lib/docker/overlay/dc921aeac8d06e7bd5b2d85b8684bb7c94ed08db3f18a9b6e897827810b289de") = -1 EISDIR (Is a directory)
[pid  4887] rmdir("/var/lib/docker/overlay/dc921aeac8d06e7bd5b2d85b8684bb7c94ed08db3f18a9b6e897827810b289de") = 0
[pid  4887] unlink("/var/lib/docker/graph/_tmp/41ca02d9c383106b6a174a43408a793f86fecbc590037d70c113bfbdf1b72364" <unfinished ...>
[pid  4887] rmdir("/var/lib/docker/graph/_tmp/41ca02d9c383106b6a174a43408a793f86fecbc590037d70c113bfbdf1b72364") = 0
[pid  4887] unlink("/var/lib/docker/overlay/dc921aeac8d06e7bd5b2d85b8684bb7c94ed08db3f18a9b6e897827810b289de") = -1 ENOENT (No such file or directory)
[pid  4887] rmdir("/var/lib/docker/overlay/dc921aeac8d06e7bd5b2d85b8684bb7c94ed08db3f18a9b6e897827810b289de") = -1 ENOENT (No such file or directory)
[pid  4887] ioctl(0, TIOCGWINSZ <unfinished ...>
[pid  4887] write(13, "\25\3\3\0\32\0\0\0\0\0\0\0\2\201\237\277\3138n\313\37\20\220L\336<vF\322\253m", 31) = 31
[pid  4887] close(13)                   = 0
[pid  4887] ioctl(0, TIOCGWINSZ, 0xc208be80d8) = -1 ENOTTY (Inappropriate ioctl for device)tail\":{},\"id\":\"dc921aeac8d0\"}\r\n", 93) = 93
[pid  4887] ioctl(0, TIOCGWINSZ, 0xc208be8138) = -1 ENOTTY (Inappropriate ioctl for device)
540b4a39c7e2: [pid  4887] unlink("/var/lib/docker/tmp/docker-builder553678363" <unfinished ...>
540b4a39c7e2: Error pulling image (3.4.3-onbuild) from docker.io/library/python, Driver overlay failed to create image rootfs dc921aeac8d06e7bd5b2d85b8684bb7c94ed08db3f18a9b6e897827810b289de: lstat /var/lib/docker/overlay/4c0cc976b7bbefe9abdfd8f0aae1bb3759004d3c9888c3164b38909b862c0cdf: no such file or directory df: no such file or directory
[pid  4887] write(3, "160\r\n{\"status\":\"Error pulling image (3.4.3-onbuild) from docker.io/library/python, Driver overlay failed to create image rootfs dc921aeac8d06e7bd5b2d85b8684bb7c94ed08db3f18a9b6e897827810b289de: lstat /var/lib/docker/overlay/4c0cc976b7bbefe9abdfd8f0aae1bb3759004d3c9888c3164b38909b862c0cdf: no such file or directory\",\"progressDetail\":{},\"id\":\"540b4a39c7e2\"}\r\n", 359) = 359
[pid  4887] rmdir("/var/lib/docker/tmp/docker-builder553678363" <unfinished ...>
[pid  4887] lstat("/var/lib/docker/tmp/docker-builder553678363",  <unfinished ...>
[pid  4887] open("/var/lib/docker/tmp/docker-builder553678363", O_RDONLY|O_CLOEXEC) = 13
[pid  4887] getdents64(13,  <unfinished ...>
[pid  4887] getdents64(13, /* 0 entries */, 4096) = 0
[pid  4887] unlink("/var/lib/docker/tmp/docker-builder553678363/build.sh" <unfinished ...>
... all the unlinks ...
[pid  4887] write(3, "281\r\n{\"errorDetail\":{\"message\":\"Error pulling image (3.4.3-onbuild) from docker.io/library/python, Driver overlay failed to create image rootfs dc921aeac8d06e7bd5b2d85b8684bb7c94ed08db3f18a9b6e897827810b289de: lstat /var/lib/docker/overlay/4c0cc976b7bbefe9abdfd8f0aae1bb3759004d3c9888c3164b38909b862c0cdf: no such file or directory\"},\"error\":\"Error pulling image (3.4.3-onbuild) from docker.io/library/python, Driver overlay failed to create image rootfs dc921aeac8d06e7bd5b2d85b8684bb7c94ed08db3f18a"..., 653) = 653
Error pulling image (3.4.3-onbuild) from docker.io/library/python, Driver overlay failed to create image rootfs dc921aeac8d06e7bd5b2d85b8684bb7c94ed08db3f18a9b6e897827810b289de: lstat /var/lib/docker/overlay/4c0cc976b7bbefe9abdfd8f0aae1bb3759004d3c9888c3164b38909b862c0cdf: no such file or directory

The same error message happens with aufs.
Whereas I can do builds with other Dockerfiles.
The problematic Dockerfile seems to be: https://github.com/ipedrazas/taiga-docker/blob/1f2004cffcd10206065d17e0a24d6eff060fa86c/backend/Dockerfile
# sudo docker pull python:3.5.0-onbuild
Pulling repository docker.io/library/python
f896d57cf5af: Error pulling image (3.5.0-onbuild) from docker.io/library/python, Driver overlay failed to create image rootfs dc921aeac8d06e7bd5b2d85b8684bb7c94ed08db3f18a9b6e897827810b289de: lstat /var/lib/docker/overlay/4c0cc976b7bbefe9abdfd8f0aae1bb3759004d3c9888c3164b38909b862c0cdf: no such file or directory 4b38909b862c0cdf: no such file or directory
21845f98d5b6: Download complete
371b8d572221: Download complete
dc921aeac8d0: Error downloading dependent layers
Error pulling image (3.5.0-onbuild) from docker.io/library/python, Driver overlay failed to create image rootfs dc921aeac8d06e7bd5b2d85b8684bb7c94ed08db3f18a9b6e897827810b289de: lstat /var/lib/docker/overlay/4c0cc976b7bbefe9abdfd8f0aae1bb3759004d3c9888c3164b38909b862c0cdf: no such file or directory

Hi!
Please read this important information about creating issues.
If you are reporting a new issue, make sure that we do not have any duplicates already open. You can ensure this by searching the issue list for this repository. If there is a duplicate, please close your issue and add a comment to the existing issue instead.
If you suspect your issue is a bug, please edit your issue description to include the BUG REPORT INFORMATION shown below. If you fail to provide this information within 7 days, we cannot debug your issue and will close it. We will, however, reopen it if you later provide the information.
This is an automated, informational response.
Thank you.
For more information about reporting issues, see https://github.com/docker/docker/blob/master/CONTRIBUTING.md#reporting-other-issues

BUG REPORT INFORMATION
Use the commands below to provide key information from your environment:
docker version:
docker info:
uname -a:
Provide additional environment details (AWS, VirtualBox, physical, etc.):
List the steps to reproduce the issue:
1.
2.
3.
Describe the results you received:
Describe the results you expected:
Provide additional info you think is important:
----------END REPORT ---------
#ENEEDMOREINFO

# docker info
Containers: 2
Images: 59
Server Version: 1.9.0
Storage Driver: overlay
 Backing Filesystem: extfs
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 4.2.0-18-generic
Operating System: Ubuntu 15.10
CPUs: 4
Total Memory: 7.705 GiB
Name: stranger
ID: EH3D:4HWI:4PJ3:QWCT:I4B7:6I3I:RD77:636Y:ZPXJ:C7PG:5SZH:JKBT
WARNING: No swap limit support

# docker version
Client:
 Version:      1.9.0
 API version:  1.21
 Go version:   go1.4.2
 Git commit:   76d6bc9
 Built:        Tue Nov  3 17:54:53 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.9.0
 API version:  1.21
 Go version:   go1.4.2
 Git commit:   76d6bc9
 Built:        Tue Nov  3 17:54:53 UTC 2015
 OS/Arch:      linux/amd64

This is happening to me as well on the same image:
$ docker pull python:3.4.3
root@kondratov:~# docker pull python:3.4.3
Pulling repository docker.io/library/python
6ebe4a97d61e: Error pulling image (3.4.3) from docker.io/library/python, Driver overlay failed to create image rootfs dc921aeac8d06e7bd5b2d85b8684bb7c94ed08db3f18a9b6e897827810b289de: lstat /var/lib/docker/overlay/4c0cc976b7bbefe9abdfd8f0aae1bb3759004d3c9888c3164b38909b862c0cdf: no such file or directory 4b38909b862c0cdf: no such file or directory
21845f98d5b6: Download complete
371b8d572221: Download complete
dc921aeac8d0: Error downloading dependent layers
Error pulling image (3.4.3) from docker.io/library/python, Driver overlay failed to create image rootfs dc921aeac8d06e7bd5b2d85b8684bb7c94ed08db3f18a9b6e897827810b289de: lstat /var/lib/docker/overlay/4c0cc976b7bbefe9abdfd8f0aae1bb3759004d3c9888c3164b38909b862c0cdf: no such file or directory

Other images seem to work well (e.g. python:3.4 or python:3 from docker hub). It is reproducible after clean install as well.
Environment information:
# docker version
Client:
Version:      1.9.0
API version:  1.21
Go version:   go1.4.2
Git commit:   76d6bc9
Built:        Tue Nov  3 17:54:53 UTC 2015
OS/Arch:      linux/amd64
Server:
 Version:      1.9.0
 API version:  1.21
 Go version:   go1.4.2
 Git commit:   76d6bc9
 Built:        Tue Nov  3 17:54:53 UTC 2015
 OS/Arch:      linux/amd64
# docker info
Containers: 0
Images: 3
Server Version: 1.9.0
Storage Driver: overlay
 Backing Filesystem: extfs
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 4.2.0-18-generic
Operating System: Ubuntu 15.10
CPUs: 8
Total Memory: 7.752 GiB
Name: testuser
ID: XEQ5:TTIR:LKZM:5UIP:LP5K:5FGJ:H7UO:CVVM:PH2A:2J5E:4DPU:UIZ2
Debug mode (server): true
 File Descriptors: 14
 Goroutines: 25
 System Time: 2015-11-16T19:13:18.293667104+03:00
 EventsListeners: 0
 Init SHA1: 473773cb80df58c09c77dafb96bf115b10179b0c
 Init Path: /usr/lib/docker/dockerinit
 Docker Root Dir: /var/lib/docker

uname -a
Linux 4.2.0-18-generic #22-Ubuntu SMP Fri Nov 6 18:25:50 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

ping @LK4D4 looks like something in that python image and overlay does not like it.   In my case I am pulling Python 2.7.10-slim.

More or less same issue with me. Docker version 1.9.0, build 76d6bc9, docker-machine version 0.5.0 (04cfa58) on Mac OSx Yosemite 10.10.5 with a Virtualbox (Version 5.0.10 r104061) container.
Images I know I can pull:

python
python:2.7
python:2.7.10
python:3.4

But if I try docker pull python:3.4.3 I get the output:
6ebe4a97d61e: Error pulling image (3.4.3) from docker.io/library/python, Driver aufs failed to create image rootfs dc921aeac8d06e7bd5b2d85b8684bb7c94ed08db3f18a9b6e897827810b289de: open /mnt/sda1/var/lib/docker/aufs/layers/4c0cc976b7bbefe9abdfd8f0aae1bb3759004d3c9888c3164b38909b862c0cdf: no such file or directory 4b38909b862c0cdf: no such file or directory
21845f98d5b6: Download complete
371b8d572221: Download complete
dc921aeac8d0: Error downloading dependent layers
Error pulling image (3.4.3) from docker.io/library/python, Driver aufs failed to create image rootfs dc921aeac8d06e7bd5b2d85b8684bb7c94ed08db3f18a9b6e897827810b289de: open /mnt/sda1/var/lib/docker/aufs/layers/4c0cc976b7bbefe9abdfd8f0aae1bb3759004d3c9888c3164b38909b862c0cdf: no such file or directory

Docker info:
Containers: 0
Images: 78
Server Version: 1.9.0
Storage Driver: aufs
 Root Dir: /mnt/sda1/var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 79
 Dirperm1 Supported: false
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 4.1.12-boot2docker
Operating System: Boot2Docker 1.9.0 (TCL 6.4); master : 16e4a2a - Tue Nov  3 19:49:22 UTC 2015
CPUs: 8
Total Memory: 3.764 GiB
Name: defaultLrg
ID: K64C:TYJU:OB2T:5ZVH:T7SP:XEJC:SALT:LL2S:QYDA:OLFE:ESWH:VRKZ
Debug mode (server): true
 File Descriptors: 11
 Goroutines: 19
 System Time: 2015-11-20T00:19:39.847752729Z
 EventsListeners: 0
 Init SHA1:
 Init Path: /usr/local/bin/docker
 Docker Root Dir: /mnt/sda1/var/lib/docker
Username: ****
Registry: https://index.docker.io/v1/
Labels:
 provider=virtualbox

Just tried and it works for me. Feel free to reopen if the problem still persists.


Css to fix on posts page on smarthpone

Hi @bebatut 👋🏼
Has this issue been fixed? 👀
If no, I'd like to take this on.

Hi am jacinta
I am an outreachy applicant and would like to work on this issue.
if given access please

Hello @bebatut
My name is Jolade, I am an Outreachy applicant, I will be working on this issue.
thank you.

As defined in the OLS Outreachy contribution guide,

If someone else has already commented, let them try first
If they don’t update after three days, the issue is “free” again, and you can pick it up.

@NPDebs were the first one to comment here. Are you still interested to work on this issue? You are already interested in other issues. You might need to pick one

Thanks for replying ma’am, it’s seems most issues have been taken up at the
moment…..I would really appreciate if you can assign anyone that is free to
me please.
This will be my first contribution
Thank you
Best Regards.
On Mon, 10 Oct 2022 at 1:27 PM, Bérénice Batut @.***>
wrote:

As defined in the OLS Outreachy contribution guide
https://docs.google.com/document/d/1HP7qTBe-6YrCUYAVkrT441rGtF6zxzNbbz2E5RWQvTM/edit?usp=sharing
,

If someone else has already commented, let them try first
If they don’t update after three days, the issue is “free” again,
and you can pick it up.

@NPDebs https://github.com/NPDebs were the first one to comment here.
Are you still interested to work on this issue? You are already interested
in other issues. You might need to pick one
—
Reply to this email directly, view it on GitHub
https://github.com/open-life-science/open-life-science.github.io/issues/238#issuecomment-1273239138,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AXUL2JGAJ7S6CR4FVDH2JT3WCQDTZANCNFSM4UQLEWWQ
.
You are receiving this because you commented.Message ID:
<open-life-science/open-life-science.github.io/issues/238/1273239138@
github.com>

I am sorting issues and will add more in the next hours

Alright ma'am

As defined in the OLS Outreachy contribution guide,

If someone else has already commented, let them try first
If they don’t update after three days, the issue is “free” again, and you can pick it up.

@NPDebs were the first one to comment here. Are you still interested to work on this issue? You are already interested in other issues. You might need to pick one

Hi @bebatut
These blocks of code (added to the custom.css file under the _sites directory) caused the required behaviour when I tested the site in my gitpod environment. However, git ignores this folder and so, the changes cannot be committed. I know I'm doing something wrong. Please help in any way you can. Thank you!
@media screen and (min-width: 320px) and (max-width: 720px), print {
  .hero {
    background-attachment: fixed;
    height: auto;
    min-height: 400px;
  }
  .hero .hero-body h1 {
    font-size: 2.5em;
    line-height: 1.2em;
    margin-bottom: 50px;
  }
}

Hello again, @bebatut 😅
While reviewing someone else's PR, I think I got the hang of where the styles should go.
Please review the changes to see if everything is in order. Thank you! 🙌🏼

@NPDebs seems to have fixed the issue here #449
Does anyone want to review the Pull Request, test it locally and check if the issue is really fixed?

Hi, @bebatut...I think you may have forgotten to close this issue. 👀


feat: Add Rake instrumentation

This PR implements #17
Porting the datadog instrumentation (Arguments have to be quantized so ignoring them per the porting guide)
There are two methods to invoke rake tasks, invoke and execute but the invoke method is calling the execute method inside:
https://github.com/ruby/rake/blob/v13.0.6/lib/rake/task.rb#L219
I couldn't find a suitable one in Semantic Conventions and this discussion doesn't seem to reach a conclusion yet so I am setting the following span kinds for now (but any suggestions are welcome!):

invoke : internal span kind
execute: client span kind

Here is a screenshot of a local trace:

Hey thanks for the PR! just ack'ing this and assigning it to myself for review, will try to take a look shortly. Appreciate you including a screenshot of a trace UI :)

@arielvalentin is there anything else that needs to be addressed?

@yoheyk thank you for your patience. I will merge as soon as the builds are done!

@arielvalentin Thanks!!

this is very exciting!


fix: References on pre-existing SLOs do not work

The SLO API returns http status code 200 or 201 when updating an
existing config. Previously, monaco just listened for the 204 status
code on update. This commit changes the behavior and makes the response
checking more explicit.
fixes #288

LGTM as well - I'd suggest we discuss @patrickpichler 's nitpick in general/removed from this bugfix, we're overall inconsistent with that.

I had to add another commit (d9e17ef) to this PR, to fix the integration tests which currently keep failing due to #275.


Update primary group after adding group by "parent add".

Hi,
I wanted to get player's highest group from database (I can't use the API, I'm not writing plugin). I thought about using player's "primary group", but it doesn't update if group have been added by "parent add".
If this behaviour was intended, consider it as suggestion / question.

By default the plugin doesn't actually use the stored field in the database.
https://github.com/lucko/LuckPerms/wiki/Configuration#primary-group-calculation
It's set to parents-by-weight usually. :)


Implemented CallerInfoException to display additional info with Exception raises

Implemented CallerInfoException to display caller file name and line when exceptions are raised.
Also added a new assert assertRaisesWithRegexMessage so that we will be able to test the new message given that the string will begin with " .... {file_path}:{line no} ..."

This is overall legit, but I see some issues. To make things easier, I just added more thorough tests for StrictMock, which you should rebase on top, and I believe will expose some bugs (see below).
Looking at the exceptions:
StrictMock
	UndefinedBehavior
	NoSuchAttribute
mock_callable()
	UndefinedBehaviorForCall
	UnexpectedCallReceived
	UnexpectedCallArguments

They don't seem to be shareable across StrictMock and mock_callable(), perhaps it is worth making this clear at their descriptions and messages that were changed.
I believe that inspect.getframeinfo(inspect.stack()[1][0]) won`t properly get the correct place where the call was created, but rather, somewhere inside TestSlide itself for most cases. One way out I can think of is:
1 - Get the call stack.
2 - Go up the stack, until you find the first non-TestSlide line.
3 - Use it.
(2) can be a bit tricky, because the tests... are part of TestSlide, so lines that match TestSlide tests module should be considered "outside". This logic should probably go in a shared function (some new lib.py?) and use it at:

At StrictMock.__init__, and refer the values at StrictMock.__repr__ (this should cover all cases).
At _MockCallableDSL.__init__, and refer the values in all places exceptions are created at the same file.

Note that _MockCallableDSL is the engine below mock_constructor and mock_callable, so perhaps, either name should come to _MockCallableDSL.__init__, so we can have proper exception messages.
Makes sense?

Thanks @xteodora for making this happen!


fix: handle version number field renames substrait-io/substrait#362

I guess we may want to hold this off until the next substrait release? Or how do we go about handling those types of changes? We would have to handle all breaking proto changes in one PR?
Edit:
Some failing CI jobs turned this PR into a mess, but the summary is:

Handle version number field rename in substrait (breaking change)
Prepare for next substrait-validator release
Handle new clippy warnings with Rust 1.65.0
Bump pyo3 and maturin

I've been striving to do updates the Monday after the Substrait auto-release, but it doesn't really matter how it's done I guess as long as the validator releases corrospond with a "whole-number" Substrait version. Thus far there haven't been breaking changes so big that it was more than an hour of work or so, so I haven't really thought of it.

It seems we have to wait for the maturin 0.14.0 release.

Going to re-open with just the substrait version bump modification.


Jean C6 is not implemented

Incoming DMG is decreased by 35% within the Field created by Dandelion Breeze. Upon leaving the Dandelion Field, this effect lasts for 3 attacks or 10s.

blocked by #1131


How to disable on large buffer?

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

          highlight_definitions = {
            is_supported = function(lang)
              local queries = require("nvim-treesitter.query")
              return not disabled(lang, vim.api.nvim_get_current_buf()) and queries.has_locals(lang)
            end,
          }


3937 searching for resources with a target resource parameter in  include fail

Root cause of the issue:

Use of contiguous ternary operators that would both add sql conditions each with named parameters but subsequently providing only one named parameter value.  As a result, we'd get an exception from Hibernate because one of the named parameter was not provided.

What was done:

Replacing string concatenation to a StringBuilder in native query building.  Making use of the StringBuilder simplifies the code and provides an easy way to replace the contiguous ternary operators.
Adding test case;
Adding changeLog.

Could the public sandbox be updated to include this fix?


New Contribution - Active

Contributor: BlockchainGuru
SSH Public key: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOdG9RGuEyjjTXVPcACWioL7QeEdUPPNyksc3sugW95x
Attestation: [any form of attestation for contribution (e.g., signature) - Optional]

I am ready

I will proceed now

I am waiting for the process to complete

waiting for the rescaling of powers of tau to complete 😵💫

All cores are running at full capacity, and the RAM is 38GB out of 62GB. The server is about to explode! 😄 Please wait a little longer

I lost the private key for the SSH key I set up earlier, I'll set up a new one: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMJ3LPJU0OXu6dZVTW8HKlmaLDM4u0LQbMDOP2DokAM3

@zvorcuit

Done.

0x24284449526ab7BcA5BB550c9E09a523e7970fC1
Warm regards.


Can't put DB value in template

I would like to use the template function added here to dynamically enter the DB value.
https://github.com/k1LoW/runn/issues/117
When I specified as follows, an error occurred at the "[" part.
{
  "id": {{.steps.getIdFromDB.rows[0].id}}
}

How can I put the DB value dynamically? Sorry to trouble you, but please confirm.

Templates for variables use text/template package. You can use {{ index .rows 0 }} instead of rows[0]

@k1LoW
Sorry for the delay. Thank you for answering.
Even if I replaced the above as it is, an error occurred, so when I tried various things, the following code worked as expected.
{
  "checkInId": "{{with index .steps.getCheckinId.steps.dbRequest.rows 0 }}{{ .checkin_id }}{{ end }}"
}

It can't be helped because it's the way text/template is written, but it's hard to write. . .

This has been resolved, so I will close it. Thank you for your answer.


Restore and fix macOS dark text selection cursor

This PR fixes #96946 by restoring the old cursor for all macOS versions, because even on macOS Catalina, the old special cursor is easier on the eyes when there's a dark background. The continued use of a special cursor can be seen in other apps as well, such as iTerm 2.
The cursor was originally removed in a915df17f58315bf1245d27701f3f7a818a71564 to fix #94144, but removing it entirely isn't necessary. This PR fixes the inconsistency issues exhibited in the old implementation of the special cursor by adding a shared mouse-text class to all editor-related elements that need a text selection cursor in their entire bounding box and applying the special cursor to that class rather than just .monaco-editor .view-lines.
The custom dark cursor is now consistent in the following areas:

Text caret (which was the original issue behind #94144)
Editor text view
Diff editor
GitHub review comments and "Reply" field
Debug console REPL

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

I have added one comment which I think should be tackled. Otherwise the change in repl.ts looks good.
I do not understand why is a change in textAreaHandler needed? This textArea is not visible.

The textarea can become visible when doing input composition, like e.g. typing Japanese text.

Good point, thanks.

I wasn't actually thinking of IMEs when I added the text cursor class to the textarea — it was because it's one of the elements causing #94144 (the other element being the cursor div). It's not necessarily visible, but there's still a 1 px mouse hover area that it occupies, so the cursor changes when moving over the textarea.

@rebornix I have tried this locally and the changes in the comment thread look good to me, I think it makes sense to have the same I cursor everywhere, in the editor, and in the comment body/title/reply button.
I will optimistically merge, since this looks good and people are complaining (e.g. #97550) and I'd like to have a fix out in Insiders.

@alexdima thanks for the ping, it looks good to me!


Pandas logs NonExistentTimeError: 2023-03-26 02:00:00

Home Assistant 2023.3.6
Supervisor 2023.03.2
Operating System 9.5
Frontend 20230309.1 - latest
Emhass  0.3.7
When the automation starts dayahead-optim or publish-data I get errors about NonExistentTimeError. The time zone I use

2023-03-26 00:45:01,848 - web_server - ERROR - Exception on /action/dayahead-optim [POST]
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/dist-packages/flask/app.py", line 2528, in wsgi_app
    response = self.full_dispatch_request()
  File "/usr/local/lib/python3.9/dist-packages/flask/app.py", line 1825, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/usr/local/lib/python3.9/dist-packages/flask/app.py", line 1823, in full_dispatch_request
    rv = self.dispatch_request()
  File "/usr/local/lib/python3.9/dist-packages/flask/app.py", line 1799, in dispatch_request
    return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)
  File "/usr/local/lib/python3.9/dist-packages/emhass/web_server.py", line 170, in action_call
    input_data_dict = set_input_data_dict(config_path, str(data_path), costfun,
  File "/usr/local/lib/python3.9/dist-packages/emhass/command_line.py", line 64, in set_input_data_dict
    fcst = forecast(retrieve_hass_conf, optim_conf, plant_conf,
  File "/usr/local/lib/python3.9/dist-packages/emhass/forecast.py", line 160, in __init__
    self.forecast_dates = pd.date_range(start=self.start_forecast,
  File "/usr/local/lib/python3.9/dist-packages/pandas/core/indexes/extension.py", line 95, in method
    result = attr(self._data, *args, **kwargs)
  File "/usr/local/lib/python3.9/dist-packages/pandas/core/arrays/datetimelike.py", line 1775, in round
    return self._round(freq, RoundTo.NEAREST_HALF_EVEN, ambiguous, nonexistent)
  File "/usr/local/lib/python3.9/dist-packages/pandas/core/arrays/datetimelike.py", line 1761, in _round
    return result.tz_localize(
  File "/usr/local/lib/python3.9/dist-packages/pandas/core/arrays/_mixins.py", line 84, in method
    return meth(self, *args, **kwargs)
  File "/usr/local/lib/python3.9/dist-packages/pandas/core/arrays/datetimes.py", line 1043, in tz_localize
    new_dates = tzconversion.tz_localize_to_utc(
  File "pandas/_libs/tslibs/tzconversion.pyx", line 328, in pandas._libs.tslibs.tzconversion.tz_localize_to_utc
pytz.exceptions.NonExistentTimeError: 2023-03-26 02:00:00

5b918bf2_emhass_2023-03-25T23-48-57.328Z.log
System Information

version
core-2023.3.6

installation_type
Home Assistant OS

dev
false

hassio
true

docker
true

user
root

virtualenv
false

python_version
3.10.10

os_name
Linux

os_version
5.15.90

arch
x86_64

timezone
Europe/Oslo

config_dir
/config

Home Assistant Community Store

GitHub API
ok

GitHub Content
ok

GitHub Web
ok

GitHub API Calls Remaining
4953

Installed Version
1.31.0

Stage
running

Available Repositories
1313

Downloaded Repositories
6

Home Assistant Cloud

logged_in
true

subscription_expiration
October 7, 2023 at 02:00

relayer_connected
true

remote_enabled
true

remote_connected
true

alexa_enabled
false

google_enabled
true

remote_server
eu-central-1-6.ui.nabu.casa

can_reach_cert_server
ok

can_reach_cloud_auth
ok

can_reach_cloud
ok

Home Assistant Supervisor

host_os
Home Assistant OS 9.5

update_channel
stable

supervisor_version
supervisor-2023.03.2

agent_version
1.4.1

docker_version
20.10.22

disk_total
116.7 GB

disk_used
14.3 GB

healthy
true

supported
true

board
generic-x86-64

supervisor_api
ok

version_api
ok

installed_addons
File editor (5.5.0), SSH & Web Terminal (13.0.3), Mosquitto broker (6.1.3), ESPHome (2023.3.1), Z-Wave JS UI (1.8.0), EMHASS (0.3.7), Frigate (0.11.1)

Dashboards

dashboards
1

resources
2

views
10

mode
storage

Recorder

oldest_recorder_run
March 3, 2023 at 16:47

current_recorder_run
March 26, 2023 at 00:43

estimated_db_size
801.98 MiB

database_engine
sqlite

database_version
3.38.5

Could the error be due to daylight saving time changes? Today we changed the clock one hour ahead.
26 Mar 2023 - Daylight Saving Time Started
When local standard time was about to reach
Sunday, 26 March 2023, 02:00:00 clocks were turned forward 1 hour to
Sunday, 26 March 2023, 03:00:00 local daylight time instead.

In the morning I started a dayahead-optim at 09:58. I get error because Nordpool do not have 24 hour with power price, but I do not get the error now.
2023-03-26 09:58:58,554 - web_server - INFO - Setting up needed data
2023-03-26 09:58:58,557 - web_server - ERROR - ERROR: The passed data is either not a list or the length is not correct, length should be 24
2023-03-26 09:58:58,557 - web_server - ERROR - Passed type is <class 'list'> and length is 24
2023-03-26 09:58:58,557 - web_server - ERROR - ERROR: The passed data is either not a list or the length is not correct, length should be 24
2023-03-26 09:58:58,557 - web_server - ERROR - Passed type is <class 'list'> and length is 24
2023-03-26 09:58:58,561 - web_server - INFO - Retrieving weather forecast data using method = scrapper
2023-03-26 09:59:02,544 - web_server - INFO - Retrieving data from hass for load forecast using method = naive
2023-03-26 09:59:02,545 - web_server - INFO - Retrieve hass get data method initiated...
2023-03-26 09:59:03,351 - web_server - INFO -  >> Performing dayahead optimization...
2023-03-26 09:59:03,351 - web_server - INFO - Performing day-ahead forecast optimization
2023-03-26 09:59:03,353 - web_server - INFO - Perform optimization for the day-ahead
2023-03-26 09:59:03,396 - web_server - INFO - Status: Infeasible
2023-03-26 09:59:03,397 - web_server - INFO - Total value of the Cost function = -20.56
2023-03-26 10:00:00,126 - web_server - INFO - Setting up needed data
2023-03-26 10:00:00,132 - web_server - INFO -  >> Publishing data...
2023-03-26 10:00:00,132 - web_server - INFO - Publishing data to HASS instance
2023-03-26 10:00:00,182 - web_server - INFO - Successfully posted to sensor.p_pv_forecast = 432.4
2023-03-26 10:00:00,198 - web_server - INFO - Successfully posted to sensor.p_load_forecast = 823.98
2023-03-26 10:00:00,210 - web_server - INFO - Successfully posted to sensor.p_deferrable0 = 1950.0
2023-03-26 10:00:00,220 - web_server - INFO - Successfully posted to sensor.p_deferrable1 = 0.0
2023-03-26 10:00:00,231 - web_server - INFO - Successfully posted to sensor.p_deferrable2 = 0.0
2023-03-26 10:00:00,242 - web_server - INFO - Successfully posted to sensor.p_deferrable3 = 2968.42
2023-03-26 10:00:00,253 - web_server - INFO - Successfully posted to sensor.p_grid_forecast = 5310.0
2023-03-26 10:00:00,269 - web_server - INFO - Successfully posted to sensor.total_cost_fun_value = -20.56
2023-03-26 10:05:00,112 - web_server - INFO - Setting up needed data

Maybe it's related to problems I'm having with Nordpool today.

Logger: homeassistant.components.sensor
Source: custom_components/nordpool/sensor.py:344
Integration: Sensor (documentation, issues)
First occurred: 10:23:47 (2 occurrences)
Last logged: 10:23:47

Error adding entities for domain sensor with platform nordpool
Error while setting up nordpool platform for sensor
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 442, in async_add_entities
    await asyncio.gather(*tasks)
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 717, in _async_add_entity
    await entity.add_to_platform_finish()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 806, in add_to_platform_finish
    await self.async_added_to_hass()
  File "/config/custom_components/nordpool/sensor.py", line 521, in async_added_to_hass
    await self.handle_new_hr()
  File "/config/custom_components/nordpool/sensor.py", line 495, in handle_new_hr
    self._update()
  File "/config/custom_components/nordpool/sensor.py", line 344, in _update
    self._average = mean(today)
  File "/usr/local/lib/python3.10/statistics.py", line 329, in mean
    T, total, count = _sum(data)
  File "/usr/local/lib/python3.10/statistics.py", line 187, in _sum
    T = _coerce(T, typ)  # or raise TypeError
  File "/usr/local/lib/python3.10/statistics.py", line 237, in _coerce
    raise TypeError(msg % (T.__name__, S.__name__))
TypeError: don't know how to coerce float and NoneType

It is reported as a bug which are going to be fixed: https://github.com/custom-components/nordpool/issues/129

Yes this was related to DST hour change. We were discussing this here: https://community.home-assistant.io/t/emhass-an-energy-management-for-home-assistant/338126/557?u=davidusb
I will eventually transfer this issue to add it to the to do list for EMHASS

Thanks for the reply again. I am closing the case as my Nordpool problem is not related to this case.


Jesse: Watch techdefinepk.blogspot

Jesse requests the watch of the watch_keyword techdefinepk\.blogspot. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

techdefinepk\.blogspot has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Jeff Schaller in Charcoal HQ


polyadenylation-dependent catabolic process- relabel terms

Need to check this (I.e other annotations), but I'm pretty sure that this is referring to TRAMP-exosome dependent pathway. However the current labels are problematic because MOST  other unrelated RNA decay is polyadenylation dependent.
In fact TRAMP really appears to degrade RNAs that are not polyadnylated by the CPF, but since exosome substrate recognition requires a polyA sequence TRAMP cid14 adds a  short number of AAA's

need to double check this, some are TRAMP/ Some are MTREC/NURS-exosome


Investigate support for ONNX runtime

Investigate the changes required to support ONNX runtime, then either implement the changes or document the barriers.

We have an prototype implementation to support MIGRAPHX as an execution provider. With this prototype, most of the unit tests can pass, and real models like image models and BERT can run using the migraphx execution provider.
Additional work to better utilize migraphx capability and stable interface between onnxruntime and migraphx is in next release. Please refer release 0.6 for specific tasks related to onnxruntime.


repositoryPath is not overridden by environment variable

fixes: https://github.com/NuGet/docs.microsoft.com-nuget/issues/1989

Docs Build status updates of commit 75c2fb6:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/reference/nuget-config-file.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit 75c2fb6:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/reference/nuget-config-file.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


[Bug]: image_mimetype not found during MultiModal Retrievala

Bug Description
I basically forced it to pull images even though it didn't want to, because of that it seemingly tried to use the image_mimetype for some reason on the ImageNode
Version
0.9.32
Steps to Reproduce

Create a multimodal vector index of images and text in Qdrant
Create a MultiModalRetriever
Ask it to pull images?

More Info - I am using the base64 encoding, basically my project setup is https://github.com/zachhandley/LlamaIndexAPI and when it pulls the images using the method there it gives me that error, I can reproduce it locally but I'm unsure if I can reliably reproduce it in prod, the error message should be enough IMO but let me know and I can add more to it.
Relevant Logs/Tracbacks
ERROR:    Exception in ASGI application
Traceback (most recent call last):
  File "/Users/zachhandley/Documents/GitHub/My-Project/api/.venv/lib/python3.11/site-packages/uvicorn/protocols/http/httptools_impl.py", line 426, in run_asgi
    result = await app(  # type: ignore[func-returns-value]
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/zachhandley/Documents/GitHub/My-Project/api/.venv/lib/python3.11/site-packages/uvicorn/middleware/proxy_headers.py", line 84, in __call__
    return await self.app(scope, receive, send)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/zachhandley/Documents/GitHub/My-Project/api/.venv/lib/python3.11/site-packages/fastapi/applications.py", line 290, in __call__
    await super().__call__(scope, receive, send)
  File "/Users/zachhandley/Documents/GitHub/My-Project/api/.venv/lib/python3.11/site-packages/starlette/applications.py", line 122, in __call__
    await self.middleware_stack(scope, receive, send)
  File "/Users/zachhandley/Documents/GitHub/My-Project/api/.venv/lib/python3.11/site-packages/starlette/middleware/errors.py", line 184, in __call__
    raise exc
  File "/Users/zachhandley/Documents/GitHub/My-Project/api/.venv/lib/python3.11/site-packages/starlette/middleware/errors.py", line 162, in __call__
    await self.app(scope, receive, _send)
  File "/Users/zachhandley/Documents/GitHub/My-Project/api/.venv/lib/python3.11/site-packages/starlette/middleware/cors.py", line 91, in __call__
    await self.simple_response(scope, receive, send, request_headers=headers)
  File "/Users/zachhandley/Documents/GitHub/My-Project/api/.venv/lib/python3.11/site-packages/starlette/middleware/cors.py", line 146, in simple_response
    await self.app(scope, receive, send)
  File "/Users/zachhandley/Documents/GitHub/My-Project/api/.venv/lib/python3.11/site-packages/starlette/middleware/exceptions.py", line 79, in __call__
    raise exc
  File "/Users/zachhandley/Documents/GitHub/My-Project/api/.venv/lib/python3.11/site-packages/starlette/middleware/exceptions.py", line 68, in __call__
    await self.app(scope, receive, sender)
  File "/Users/zachhandley/Documents/GitHub/My-Project/api/.venv/lib/python3.11/site-packages/fastapi/middleware/asyncexitstack.py", line 20, in __call__
    raise e
  File "/Users/zachhandley/Documents/GitHub/My-Project/api/.venv/lib/python3.11/site-packages/fastapi/middleware/asyncexitstack.py", line 17, in __call__
    await self.app(scope, receive, send)
  File "/Users/zachhandley/Documents/GitHub/My-Project/api/.venv/lib/python3.11/site-packages/starlette/routing.py", line 718, in __call__
    await route.handle(scope, receive, send)
  File "/Users/zachhandley/Documents/GitHub/My-Project/api/.venv/lib/python3.11/site-packages/starlette/routing.py", line 276, in handle
    await self.app(scope, receive, send)
  File "/Users/zachhandley/Documents/GitHub/My-Project/api/.venv/lib/python3.11/site-packages/starlette/routing.py", line 66, in app
    response = await func(request)
               ^^^^^^^^^^^^^^^^^^^
  File "/Users/zachhandley/Documents/GitHub/My-Project/api/.venv/lib/python3.11/site-packages/fastapi/routing.py", line 241, in app
    raw_response = await run_endpoint_function(
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/zachhandley/Documents/GitHub/My-Project/api/.venv/lib/python3.11/site-packages/fastapi/routing.py", line 167, in run_endpoint_function
    return await dependant.call(**values)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/zachhandley/Documents/GitHub/My-Project/api/app/server.py", line 262, in get_summary
    summary = await actions.summarize_user(assessment.userId)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/zachhandley/Documents/GitHub/My-Project/api/app/api/ai_actions.py", line 216, in summarize_user
    ai_response = await query_engine.aquery(query_str)
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/zachhandley/Documents/GitHub/My-Project/api/.venv/lib/python3.11/site-packages/llama_index/core/base_query_engine.py", line 46, in aquery
    return await self._aquery(str_or_query_bundle)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/zachhandley/Documents/GitHub/My-Project/api/.venv/lib/python3.11/site-packages/llama_index/query_engine/multi_modal.py", line 220, in _aquery
    response = await self.asynthesize(
               ^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/zachhandley/Documents/GitHub/My-Project/api/.venv/lib/python3.11/site-packages/llama_index/query_engine/multi_modal.py", line 146, in asynthesize
    llm_response = await self._multi_modal_llm.acomplete(
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/zachhandley/Documents/GitHub/My-Project/api/.venv/lib/python3.11/site-packages/llama_index/multi_modal_llms/openai.py", line 380, in acomplete
    return await self._acomplete(prompt, image_documents, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/zachhandley/Documents/GitHub/My-Project/api/.venv/lib/python3.11/site-packages/llama_index/multi_modal_llms/openai.py", line 362, in _acomplete
    message_dict = self._get_multi_modal_chat_messages(
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/zachhandley/Documents/GitHub/My-Project/api/.venv/lib/python3.11/site-packages/llama_index/multi_modal_llms/openai.py", line 173, in _get_multi_modal_chat_messages
    generate_openai_multi_modal_chat_message(
  File "/Users/zachhandley/Documents/GitHub/My-Project/api/.venv/lib/python3.11/site-packages/llama_index/multi_modal_llms/openai_utils.py", line 41, in generate_openai_multi_modal_chat_message
    mimetype = image_document.image_mimetype or "image/jpeg"
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NodeWithScore' object has no attribute 'image_mimetype'

@ZachHandley ImageDocument here expects image_mimetype. You can by default fix it to None and that should solve the issue.

image_mimetype is optional field of ImageNode.
@ZachHandley I am wondering are you trying to access image_mimetype for text nodes since it seems you are building multi model vector index

since the error log shows you are creating chat msg using NodeWithScore.
you need to get node form nodewithscore and assert it is imagenode

I believe this is closed :)


Fixed #25468 -- Made DjangoJSONEncoder lazy strings aware

Thanks Stavros Korokithakis for the report.

Worth a mention in the release notes? In commit message: "lazy string aware".

1.9 or 1.10?

I think 1.10 since it seems to be more of a feature than a bug.


TRS catch-up

Feature Request
Desired behaviour
There are a few TRS issues that are falling through the cracks.
Evaluate and/or implement

https://github.com/ga4gh/tool-registry-service-schemas/issues/39
https://github.com/ga4gh/tool-registry-service-schemas/issues/38
https://github.com/ga4gh/tool-registry-service-schemas/issues/37

┆Issue is synchronized with this Jira Story
┆Issue Number: DOCK-360

See also https://github.com/ga4gh/dockstore/issues/1395

ToolDescriptor of a language doesn't seem to be implemented for issue 39 @garyluu

We now have the TRS tickets in Jira, do you still want this ticket [~denis.yuen]


Upgraded to Ecto 3.4 and getting problem with dialyzer and Ecto.Migrator.run

Environment

Elixir version (elixir -v): 1.9.4
Database and version (PostgreSQL 9.4, MongoDB 3.2, etc.): PostgreSQL 12.2
Ecto version (mix deps): 3.2 - 3.4
Database adapter and version (mix deps): postgrex
Operating system: MacOS catalina

Current behavior
Dialyzer is giving me the following error after I upgraded to ecto 3.4
lib/ticket_booth/release/tasks.ex:54:no_return
Function run_migrations_for/1 has no local return.
________________________________________________________________________________
lib/ticket_booth/release/tasks.ex:58:call
The function call will not succeed.

Ecto.Migrator.run(_repo :: atom(), _migrations_path :: binary(), :up, [{:all, true}])

breaks the contract
(Ecto.Repo.t(), [String.t()] | [{integer(), module()}], atom(), Keyword.t()) :: [integer()]

________________________________________________________________________________

Expected behavior
Dialyzer should pass

This is because we're soft-deprecating passing a single migration path (a binary) in favour of a list of migrations paths (list of binaries) and we've updated specs accordingly.


Add support for version based packet processing

The problem
The CaptureBytes filter is currently the primary means in quilkin to extract information from packets. Packets have a fixed format that determines where to find that info. In practice however that format can change over time or differ between packets - as a result it would be desirable to capture (potentially different) info based on the format of the particular packet in question.
For context, we're currently trying out UnrealEngine integration where the client tags each packet with a routing token but we can't actually put this in production unless we have a backwards compatibilty plan in place otherwise we'll probably have to run specific proxies with different filter chains for our different clients over time to avoid breaking old clients whenever we add changes to the packet format.
We'd also like to use the same set of proxies to handle packets across all our games and not necessarily be tied to having them all use the same packet format.
For example, right now due to some UE limitations, we need to tag our token onto packets as a prefix but we hope to resolve this upstream in the future and then switch to appending the token as a suffix instead. Also, today we only send a routing token but we might want to include more information later on - like when we add support for setting up a connection/authentication.
In any case, we don't want to break previous clients that only use a prefixed token.
Proposal
I think we can extend the CaptureBytes filter to

be version aware (i.e know that a packet has a version)
capture multiple pieces of information from a packet (currently it can only extract a single piece of info) -

by configuring the filter to first, fetch version information either from the packet itself or from dynamic metadata - and then based on the value of that found version, execute a list of captures.
We should also have support for what to do if the version we got doesn't have any registered list of captures - allow the packet or drop the packet, the former lets us bypass the filter for packets that do not need to be processed by it (e.g some version x packet has no interesting info for the filter to capture).
config wise the filter's schema becomes something like:
# The config is one of:
config:
  # A versioned, capture list
  versioned: versioned
  # Short hand for a non-versioned, capture list of 1 - which is how is works today.
  capture: capture
  # A list of captures to perform, non-versioned.
  captures: [ capture ]

versioned:
  # Where to retrieve what version to use.
  # For each packet the version is always retrieved first.
  version: version
  # A list of (version, captures) pair checked in list order to figure out what capture list
  # to use.
  captures: [ versionedCapture ]
  # What to do if we don't find a capture list to process the packet with.
  onNoVersionMatched: DROP | PASSTHROUGH

# Version is retrieved from one of
version:
  # A capture from the packet
  packet: capture
  # Or from dynamic metadata (e.g in cases where you have multiple CaptureByte
  # filters in the chain or the version is already known from some other means).
  metadataKey: string

versionedCapture:
  # If the captured version matches this value
  version: base64Bytes
  # then use this list to capture info from the packet.
  captures: [ capture ]

# This part remains largely the same as today.
capture:
  strategy: PREFIX | SUFFIX
  # This becomes optional - for cases where we don't necessarily want to store the
  # captured value (like the version maybe could only be captured and thrown away after usage)
  metadataKey: string
  size: int
  remove: bool

As an example configuration, the following shows a CaptureBytes that has evolved over time and is backwards compatible with older clients+packet formats.
config:
  versioned:
    version:
      packet:
        strategy: PREFIX
        size: 1
        metadataKey: packet-version
        remove: true
    captures:

    # v0 has only a single token prefix
    - version: AA==
      captures:
      - strategy: PREFIX
        size: 16
        metadataKey: routing-token
        remove: true

    # In v1 the token is now a suffix
    - version: AQ==
      captures:
      - strategy: SUFFIX
        size: 16
        metadataKey: routing-token
        remove: true

    # In v2 we have both a token and some other piece of information attached
    - version: Ag==
      captures:
      # First capture the routing token
      - strategy: SUFFIX
        size: 16
        metadataKey: routing-token
        remove: true
      # Then capture the extra info
      - strategy: SUFFIX
        size: 32
        metadataKey: extra-info
        remove: true

Oooh this is very interesting. I can totally understand this use case for sure.
To me - the versioning makes perfect sense. The only thought I had is - that we likely will want versioning across different filters (say you want to change compression or encryption between versions?) - so my concern therefore would be that the above design has a tight coupling to CaptureBytes.
This could potentially also be done as two seperate Filter configurations (something like):
version: v1alpha1
static:
  filters:
    - name: quilkin.extensions.filters.capture_bytes.v1alpha1.CaptureBytes
      config:
        strategy: PREFIX
        size: 1
        metadataKey: packet-version
        remove: true
    - name: quilkin.extensions.filters.capture_bytes.v1alpha1.CaptureBytes
      config:
         versionMetadataKey: packet-version
         versions:
            # v0 has only a single token prefix
            - version: AA==
              captures:
              - strategy: PREFIX
                size: 16
                metadataKey: routing-token
                remove: true
  endpoints:
    - address: <IP_ADDRESS>:7001

Another question: Do we also need a "if it's this version do nothing/passthrough?" (if we did that, we probably wouldn't need a single Filter to capture multiple pieces of data, we could have multiple CaptureBytes Filter configurations in the chain)
I'm personally more inclined towards a Filter does one thing not multiple operations, just because I think it's easier to mentally get a picture of what is going on - but it is a more verbose configuration.
Another fun thought: Should this versioning be a general part of our overall configuration somehow (We may run into xDS compatibility issues here?) Or a standard part of all our Filter configs somehow? (or maybe just a useful library for when needed). This feels to me like versioning would be extremely useful!

Another fun thought: Should this versioning be a general part of our overall configuration somehow (We may run into xDS compatibility issues here?) Or a standard part of all our Filter configs somehow? (or maybe just a useful library for when needed).

Yes, I think this is the proper way to go. I went with a CaptureBytes only solution since that's the only way we can get info from a packet today but I think this is the better alternative to properly support other versioning for other filters.
So in my mind what this requires is that we'll have one filter chain per version vs our single filter chain today.
Then quilkin itself needs to know where the version comes from (it can't really be a filter since then there's the chicken and egg problem) but it should be enough to say, capture these bytes from all packets to get the version.
XDS wise this all works (it supports multiple filter chains, and the concept of a filterchain match to select a filter chain based on some equality check).

Another question: Do we also need a "if it's this version do nothing/passthrough?" (if we did that, we probably wouldn't need a single Filter to capture multiple pieces of data, we could have multiple CaptureBytes Filter configurations in the chain)

Yeah, the pass through option is required if we have some packet version that doesn't have any info to capture (whereas some other versions do).
Note that only supporting a single capture per filter won't work with versioning like in your example, e.g if we have a v1 filter too, what does the v0 filter do when it receives a v1 packet?
Neither of these are an issue or needed if we go the multiple filter chain route though.

I'm personally more inclined towards a Filter does one thing not multiple operations, just because I think it's easier to mentally get a picture of what is going on - but it is a more verbose configuration.

I think it makes more sense for capturebytes to support multiple operations, (which would be a separate issue if we go down the multiple filter chain route since it becomes unrelated to version).
It's surely the less verbose alternative compared to using multiple filters because it'll literally contain the exact same list of captures without the boilerplate of a full filter specification per capture.
But more importantly, filters aren't free (there's a difference between running 1 Noop filter vs running 5 Noop filters in terms of perf) - if one feels a capture per filter is fine then they can still do that in their config.
I think this is similar to typical unix commands like grep, sed etc, it'll be silly if we were required to do sed s/.../ | sed s/.../  without any means to group all transformations into the same sed/grep command. The filter is still doing one thing (capturing bytes) but now it'll do it well :)

Yes, I think this is the proper way to go. I went with a CaptureBytes only solution since that's the only way we can get info from a packet today but I think this is the better alternative to properly support other versioning for other filters.

I think that 100% make sense.

XDS wise this all works (it supports multiple filter chains, and the concept of a filterchain match to select a filter chain based on some equality check).

Oh that's neat! I really need to dig into those protos more.
Is this the one you are referring to:
https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/listener/v3/listener_components.proto#envoy-v3-api-msg-config-listener-v3-filterchainmatch
Is there an issue here in that a FilterChainMatch doesn't allow us to specify our own config through our own UDP specific configuration? 🤔

Then quilkin itself needs to know where the version comes from (it can't really be a filter since then there's the chicken and egg problem) but it should be enough to say, capture these bytes from all packets to get the version.

Sound like we need something similar to FilterChainMatch - that can introspect a packet for specific data before it goes into a FilterChain.

I think it makes more sense for capturebytes to support multiple operations, (which would be a separate issue if we go down the multiple filter chain route since it becomes unrelated to version).
But more importantly, filters aren't free (there's a difference between running 1 Noop filter vs running 5 Noop filters in terms of perf) - if one feels a capture per filter is fine then they can still do that in their config.

The perf aspect sold me on multiple operations per filter. 👍🏻 SGTM.

Sounds good!

Is this the one you are referring to:
https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/listener/v3/listener_components.proto#envoy-v3-api-msg-config-listener-v3-filterchainmatch
Is there an issue here in that a FilterChainMatch doesn't allow us to specify our own config through our own UDP specific configuration?

Yes that's the one, there's the application_protocols field that is likely the most relevant in our case - we can specify the version(s) in that list to match against in order to select the filter chain. The FilterChainMatch is part of the FilterChain resource (currently its always ignored by Quilkin) so it should be enough to pass any info in there for that filter chain and have Quilkin pick it up.

Yes that's the one, there's the application_protocols field that is likely the most relevant in our case

Just so I can think this through as a use case: Say version is defined as a 1st byte in a packet. (So we max at 256 versions)
How would we configure that through the application_protocols? 🤔
Unfortunately we can't do our own configuration system, so we would have a set of enum values for application_protocols?
So prefix_byte could be the option for above, and we might also have the option of suffix_byte if someone wanted to have the version be the last byte value?
If for some reason people wanted to use a different strategy, they might need to define their own FilterChainMatch implementation? (or say, use two bytes... which seems unlikely, since why would you need more than 256 versions?)
Is that the general gist you were thinking?

Ah so what I meant was that application_protocols will contain the versions to match the filter chain only, it doesn't say anything about where the version to compare against come from, that one is set on startup to e.g prefix, suffix etc, and it can't change dynamically (since that property can't change between versions either)

so on the xds side, we get something like this from the management server

# simplified proto
filter_chains: [
  {
    filter_chain_match: {
      application_protocols: ["AA=="] # v0
    },
    filters: [...] # Use this filter chain to process any v0 packets
  },
  {
    filter_chain_match: {
      application_protocols: ["AQ==", "Ag=="] # v1 and v2
    },
    filters: [...] # Use this filter chain to process any v1 or v2 packets.
  },
]

Then Quilkin itself is configured with how to capture the version, it applies to all packets
version: v1alpha1
dynamic:
  filter_chain:
    versioned:
      capture_version:
        strategy: PREFIX
        size: 1

For static configs
version: v1alpha1
static:
  # We can support one of 'filter_chain' or 'filters' so that 'filters' is short hand for
  # a non versioned filter chain as it is today.
  filter_chains:
    # One of 'versioned' or 'non_versioned'
    versioned:
      capture_version:
        strategy: PREFIX
        size: 1

      filter_chain:
      - versions: [ AA== ]
        filters:
        - name: quilkin.extensions.filters.debug.v1alpha1.Debug
      - versions: [ Ag== ]
        filters:
        - name: quilkin.extensions.filters.capture_bytes.v1alpha1.CaptureBytes

For each packet, quilkin uses the provided static info under capture_version to get the packet's version, then depending on static vs dynamic config, looks for a match of the captured bytes in the static versions or dynamic application_protocols list to select a filter chain

Got it, got it, got it, got it! That makes perfect sense to me. I like it!

Sorry, only just reading through this now. I'm a bit concerned that this is adding a lot of complexity for not a lot of benefit. This comes pretty close to writing code as a configuration. I think we should take a step back and look at the problem as whole and think about what we're achieving with this feature rather than trying to shove this functionality into the current filters.
The problem statement as I see it, is that we have a custom user-specific protocol that we want to parse with Quilkin which can't be upstreamed. That protocol is complex, so we need a way to provide Quilkin with functionality to parse and validate that protocol. I don't think we should do that by adding parsing to Quilkin's configuration format. This versioning scheme is really just lookahead, there's protocols where this simple lookahead won't work. Adding parsing significantly increases the problem space the configuration needs to cover immensely and is a problem that is better handled in code, where you can use your own libraries and conditionals to parse the protocol.
This kind of custom behaviour is exactly why we have the Filter trait though, so we should look at what currently makes it undesirable to write a custom filter to handle this behaviour. To me it boils down two main parts, both of which have to do with the current rigidity in Quilkin's extensibility.

No scripting filter. Even with just WASM, it would be less code (~10x comparing #412 to #256) for Quilkin, and the users to write this protocol as a WASM script than a YAML file.
There's no way to extend Quilkin, without also distributing your own Quilkin binary. No one is going to do it, as evident by the fact that doing this would have been the most performant and quickest option here, and even we didn't do it. If the filter traits were moved to another crate, filters could be defined in separate crates and loaded by Quilkin at runtime. That would be much more reasonable for users.

To me, implementing either of those alternatives, and implementing the UE protocol as a separate crate is much more preferable to me than adding a versioning scheme that makes our configuration more complicated.

I'm not sure I'm following the idea with filters. Could you give an example of how your proposal solves the problems that the ticket addresses e.g if formats change between clients such that different packet formats should be handled by different set of filters?

I feel like I'm coming back to FilterChainMatch, but to come back to @XAMPPRocky 's original point - do we actually want to be able to handle different UDP protocols through Quilkin? Or do is each proxy only going to handle a single protocol with multiple versions?

I feel like we do want to be able to handle protocols built onto of UDP, I just think that the protocol parsing should be a filter and not a filter chain. It needs to be a complete logical unit because parsing is complex and depending on the protocol how it is parsed could have security implications (e.g. needing constant time comparisons in your decryption code). So it's something that we should have in code, and be able to take advantage of Rust's features.
The protocol filter's job is to take the protocol, and make Quilkin aware of it and able to act smartly on the data. So this would be for example populating metadata with header information such as the version so filters can trigger different behaviour, while also maybe unwrapping it, so that the next filter is only dealing with the data payload, before another filter wraps the the data back before sending it on its way.
To provide a more concrete idea. Here's an example and user story of what I mean of how using a protocol as filter could look like.
Imagine ACME broadcasting company is using SRT to broadcast video between their studios back to a control room, and from the control room to outside world to be retransmitted around the world. They want to send the data unencrypted when it's being sent internally between machines for speed, but when the control room is publicly transmitting it needs to be encrypted until it reaches the local broadcasters.
Here's how a filter chain could look with an SRT and match that would allow you to accept unencrypted SRT traffic, that is then rebroadcast as encrypted. You could of course write this whole thing in one filter, but I think this what a good filter chain could look like.

version: v1alpha1
static:
  filters:
    # Parses and unwraps SRT data, populating metadata and session data with SRT headers.
    - name: acme.srt.unwrap
    - name: quilkin.match
      config:
        # Key to match against
        metadata: acme.srt.encryption
        # Match guard behaviour, whether to drop or pass if no arm matches.
        passthrough: pass
        # The list of values and filter chain arms.
        match_arms:
        - value: [AES-128, AES-192, AES-256]
          then:
           - name: quilkin.encryption
             config:
               # Maybe not this syntax, but we should have a syntax and mechanism for doing metadata substitution.
               algorithm: ${acme.srt.encryption}
    # Uses Quilkin metadata to wrap the data back in an SRT packet.
    - name: acme.srt.wrap

So I'm digging into Envoy/XDS and I don't see a concept of nested filters:

http functionality is implemented using nested filters for example, here's the http_connection_manager that is itself a filter
https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/network/http_connection_manager/v3/http_connection_manager.proto
Itself has a field http_filters that contains a filter chain to be used to process http requests

(repeated extensions.filters.network.http_connection_manager.v3.HttpFilter) A list of individual HTTP filters that make up the filter chain for requests made to the connection manager. Order matters as the filters are processed sequentially as request events happen.

xds wise,  the protocol itself doesn't have the concept of nested filters but makes it possible - the connection_manager's config would be a list of proto anys that make up the chain and the connection_manager then knows how to instantiate other filters

xds wise, the protocol itself doesn't have the concept of nested filters but makes it possible - the connection_manager's config would be a list of proto anys that make up the chain and the connection_manager then knows how to instantiate other filters

That makes sense. I can see how we could potentially make that relatively easy to integrate with some Rust library code. Also the fact that FilterChain implements Filter doesn't hurt either. Easy enough to pass data through.
🤔 doing nested filters is likely to make #420 and/or #13 much harder though? Unless we can come up with a clever way of creating/executing FilterChains that come from the main binary based on whatever custom Filters have been dynamically loaded and registered (which we might be able to do, but figured it was worth considering).


Full path to file should be given in error message

$ hugo version
hugo v0.130.0+extended darwin/arm64 BuildDate=2024-07-29T13:51:56Z VendorInfo=brew

I use page objects in my blog, and the new EXIF reader prints error message files relative to the page object.  I'd really like it to print them relative to the blog root, so I know which file.  For example:
WARN  images: "/fox.jpg": BitsPerSample: expected []interface {}, got uint16:

would be much better as:
WARN  images: "content/posts/part1/part2/fox.jpg": BitsPerSample: expected []interface {}, got uint16:

If it makes sense to strip the content/posts portion off to shorten the error message, that's fine.

You are right, but that info isn't easily available where this is printed, which is why I got lazy. The important info for me (to fix this) here is the info to the right.

It would be great if this could also apply to layout errors that are due to a content file being the culprit.
For example, I got this error recently:
Error: error building site: render: failed to render pages: render of "page" failed: "/app/layouts/blog/single.html:3:21": execute of template failed: template: blog/single.html:3:21: executing "main" at <.Fragments.HeadingsMap>: nil pointer evaluating *tableofcontents.Fragments.HeadingsMap

The problem is I have 500 posts and 300 drafts and there's no indication in the error which page is causing it. There's only a reference to a layout file to a function that is being used by those 800 posts.
Similarly I've gotten errors related to a nil reference from a missing image where the error only mentioned the baseof layout file being the issue but it's really due to a missing image in one of the 800 posts. It would be nice to see which content page that image is being referenced from.

Another option is to add "while processing " to the error message.


Fix minor typos in Prerequisites

This change is

/lgtm

@mbssaiakhil thanks!

Welcome, and Thanks @aledbf, was reading all the examples in ingress and parallelly solving small mistakes in the documents.


Remove stray newline from Turkish translation header field

Thanks for contributing! Unfortunately there were the following style issues with your Pull Request:

Commit: 217caf3ea4da7a758ab5ee80ec4e8e6a0a2055ba
Your subject line is longer than 50 characters

Please see https://github.com/agis-/git-style-guide (you can use git push -f to update this PR)

This message was auto-generated by https://gitcop.com

Translation files are merged from Crowdin; any such adjustments would be lost on the next merge. As far as I can tell, such newline is also completely harmless, so why bother?


The scheduler address seems not to be correct

Has this project been abandoned? I tried to install a client and finally hit an error
Error: The scheduler address seems to not be correct. Using 0x6c8f2a135f6ed072de4503bd7c4999a1a17f824b. You may need to specify the address using --address if you are running the client against a test network.

The contract does appear to exist. https://etherscan.io/address/0x6c8f2a135f6ed072de4503bd7c4999a1a17f824b
Perhaps my configuration cannot find it? I did hit quite a few issues following the instructions in the docs.

This project has not been abandoned :)
Can you expand on what issues you ran into.  Code you ran.  Errors you received.  Transactions you sent?

@philipodonnell is it possible that your client has not fully synced the blockchain?  Based on your original pasted output I'm guessing that your chain is still syncing.

Ah, I see. That would make sense. Is there a way to check that the geth has finished syncing? I am tailing the log files but all I see is "imported 1 block" every few seconds, I assume those are new blocks.
On the errors during installation, off the top of my head there were a number of dependency issues with cffi and fflr and pip. Also I had to symlink to the geth.ipc file because the defaults were looking for it in ~/.ethereum/geth but the directory I found it in after following the tutorials was in the /data/ethereum folders.

I used the latest Ubuntu 15.04 from here: https://virtualboxes.org/images/ubuntu/#ubuntu1504

I'm going to close this issue.  Feel free to re-open when/if you have any specific issue.
I am aware that there are parts of this code that are fragile.  I'm currently working on a lot of upstream changes in the populus and web3.py codebases that once done, will propogate down into this project and ideally improve the state of things.
But by all means, let me know about any issues you run into and I'm happy to help you get them working.

Closing old issue


Instructions to run integrations tests fail on tox

Additional environment details (Operating System, Cloud provider, etc):
Ubuntu 14.04, Python 2.7.6
Steps to reproduce the issue:

Follow instructions at https://github.com/DataDog/integrations-core/blob/e3985fe43853f6ee3bb11e8d9d20a18ca12ae340/docs/dev/README.md

Describe the results you received:
$ tox
ERROR: No setup.py file found. The expected location is:
  /home/sday/src/DataDog/integrations-core/setup.py
You can
  1. Create one:
     https://packaging.python.org/tutorials/distributing-packages/#setup-py
  2. Configure tox to avoid running sdist:
     http://tox.readthedocs.io/en/latest/example/general.html#avoiding-expensive-sdist

Describe the results you expected:
Tests should run.
Additional information you deem important (e.g. issue happens only occasionally):

Hi @stevvooe thanks for reporting!
Which check are you trying to run the tests for? Tox is supposed to be run from inside one of the check folders.
In the meantime I'm going to remove the tox.ini file which is a relic from the old testing strategy to reduce confusion, sorry about that!

@masci I am working with the kubernetes_state integration. I've rebased with the latest changes that removed the tox.ini file but now get this error message:
ERROR: toxini file 'tox.ini' not found

It seems to work for other plugins, although it skips the tests due to "platform mismatch".

Unfortunately the kubernetes_state check wasn't ported to the new testing framework yet (see the list of currently available checks here.  I'll keep this issue open and ping you as soon as we provide the check with the new tests, thanks for your patience.

@masci In the meantime, how can I run the tests? I'd like to make a contribution and want to ensure that the changes are correct. I am not really interested in the other checks.

@stevvooe can you try again running the tests with tox from the master branch?
cd kubernates_state && tox should work now, let me know how it goes.

Looks good:
tests/test_kubernetes_state.py::test__update_kube_state_metrics PASSED                                                                                [ 33%]
tests/test_kubernetes_state.py::test__update_kube_state_metrics_v040 PASSED                                                                                [ 66%]
tests/test_kubernetes_state.py::test__join_custom_labels PASSED                                                                                [100%]

============================================================================================================================================== 3 passed in 0.29 seconds ==============================================================================================================================================
flake8 recreate: /home/sday/src/DataDog/integrations-core/kubernetes_state/.tox/flake8
flake8 installdeps: flake8
flake8 installed: configparser==3.5.0,enum34==1.1.6,flake8==3.5.0,mccabe==0.6.1,pycodestyle==2.3.1,pyflakes==1.6.0
flake8 runtests: PYTHONHASHSEED='1803360524'
flake8 runtests: commands[0] | flake8 .
______________________________________________________________________________________________________________________________________________________ summary _______________________________________________________________________________________________________________________________________________________
  unit: commands succeeded
  flake8: commands succeeded
  congratulations :)