Couldn't find any pixel format that matched the criterias.

I have been able to run my own programs using piston for a while, but since a few days I suddenly get this error.
When trying to run cargo run --bin hello_world from the piston_examples:
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "Couldn\'t find any pixel format that matches the criterias."', /checkout/src/libcore/result.rs:860:4
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
             at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at /checkout/src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at /checkout/src/libstd/sys_common/backtrace.rs:60
             at /checkout/src/libstd/panicking.rs:380
   3: std::panicking::default_hook
             at /checkout/src/libstd/panicking.rs:396
   4: std::panicking::rust_panic_with_hook
             at /checkout/src/libstd/panicking.rs:611
   5: std::panicking::begin_panic_new
             at /checkout/src/libstd/panicking.rs:553
   6: std::panicking::begin_panic_fmt
             at /checkout/src/libstd/panicking.rs:521
   7: rust_begin_unwind
             at /checkout/src/libstd/panicking.rs:497
   8: core::panicking::panic_fmt
             at /checkout/src/libcore/panicking.rs:92
   9: core::result::unwrap_failed
             at /checkout/src/libcore/macros.rs:41
  10: <core::result::Result<T, E>>::unwrap
             at /checkout/src/libcore/result.rs:738
  11: hello_world::main
             at src/hello_world.rs:7
  12: __rust_maybe_catch_panic
             at /checkout/src/libpanic_unwind/lib.rs:98
  13: std::rt::lang_start
             at /checkout/src/libstd/panicking.rs:458
             at /checkout/src/libstd/panic.rs:361
             at /checkout/src/libstd/rt.rs:59
  14: main
  15: __libc_start_main
  16: _start

System
Antergos, based on Arch Linux
$ uname -r: 4.12.12-1-ARCH
$ cargo --version: cargo 0.21.0 (5b4b8b2ae 2017-08-12)
$ rustc --version: rustc 1.20.0 (f3d6973f4 2017-08-27)
$ rustup --version: rustup 1.6.0
glxinfo
recently updated packages, most notably:

upgraded mesa (17.1.8-1 -> 17.1.8-2)
upgraded gtk3 (3.22.19-2 -> 3.22.20-1)
upgraded linux (4.12.10-1 -> 4.12.12-1)

Update 4: All intermediate versions of mesa (17.1.8-1, 17.1.8-2, 17.2.0-2, 17.2.0-3, 17.2.1-3, 17.2.2-1) have this same problem.
Let me know if you need more information 😄
Update: Seems to be the case for all OpenGL versions. Rebooting didn't work either.
Update 2: Also happens on a clean Debian 9 (kernel 4.9.0-3-amd64) build in VirtualBox 5.1.26
Update 3: Also happens on Rust 1.19.0, and Rust 1.18.0 and earlier don't compile

This is a problem with glutin back-end. I suggest running the glutin example here: https://github.com/sumproxy/glutin
Below are lines that probably causes the panic:
https://github.com/sumproxy/glutin/blob/2e7e7a3a8daeac8e9f0b24bf25189623d48df2f2/src/api/egl/mod.rs#L476
https://github.com/sumproxy/glutin/blob/2e7e7a3a8daeac8e9f0b24bf25189623d48df2f2/src/api/cocoa/helpers.rs#L62
https://github.com/sumproxy/glutin/blob/2e7e7a3a8daeac8e9f0b24bf25189623d48df2f2/src/api/wgl/mod.rs#L118
https://github.com/sumproxy/glutin/blob/2e7e7a3a8daeac8e9f0b24bf25189623d48df2f2/src/api/wgl/mod.rs#L118
https://github.com/sumproxy/glutin/blob/2e7e7a3a8daeac8e9f0b24bf25189623d48df2f2/src/api/glx/mod.rs#L70
Hope this will help!!

Actually, all those examples seem to work. 😅 I'll try to see which of those lines might be the issue

Update 4:
Line 143 of piston_window/src/lib.rs looks suspicious:
// Turn on sRGB.
let settings = settings.clone().srgb(true);

Commenting out that line (and keeping glutin unmodified) also fixes all problems. I don't think it has any use to dive into it much more.

Note for any that are still having this issue: I had to set .srgb(false) on my system. Simply commenting it out didn't help.

Notice that sRGB is enabled in piston_window because the shaders assume linear color space. Discussion: https://github.com/PistonDevelopers/gfx_graphics/issues/293

Now that Ubuntu 17.10 artful has been released with Mesa version 17.2.2 this issue will affect more people. Including me!
The bug is indeed a regression of Mesa from the 17.1 branch to the 17.2 branch. I've ran a bisect and the first bad commit is:
commit 6e06e281c6ee342276d087ed4ee4a442626e433a
Author: Neha Bhende<EMAIL_ADDRESS>Date:   Wed Apr 26 16:21:32 2017 -0700

    glx: add missing sRGB attribute check in fbconfigs_compatible()

    This patch will allow driver to choose srgb capable FBconfig
    if GLX_FRAMEBUFFER_SRGB_CAPABLE_ARB attribute is 1

    Reviewed-by: Brian Paul<EMAIL_ADDRESS>    Reviewed-by: Charmaine Lee<EMAIL_ADDRESS>
I could also reproduce the bug on the latest master branch (commit 59fb59ad54d368683d5cc3b149f021452bddc05f) and on the 17.2.3 release.
There is a bug reported upstream for Mesa: https://bugs.freedesktop.org/show_bug.cgi?id=102354
Supertuxkart ran into the same issue, they ended up supporting a non-sRGB mode: https://github.com/supertuxkart/stk-code/issues/2902
@tpalli has proposed a patch for the issue but it got a negative response during review and was probably abandoned due to that reason, given that there have been multiple stable releases on the 17.2 branch of Mesa since (17.2.2 and 17.2.3) and none of them included the patch.
It would be really nice to have the bug fixed by upstream Mesa!
As people have noted above, reverting to one of the Mesa 17.1.* releases fixes the bug.
Please don't be misled by the "upgraded mesa (17.1.8-1 -> 17.1.8-2)" in the initial comment by @C-Bouthoorn. Both linked glxinfo refers to mesa 17.2.0 and the linked "recently upgraded packages" includes two upgrades of mesa, first the cited one, and second one to 17.2.0. So its definitely caused for @C-Bouthoorn by the upgrade to 17.2 as well.

Note on my compilation setup (on Ubuntu 17.10 artful; after having done apt build-dep libgl1-mesa-glx):
git clone https://anongit.freedesktop.org/git/mesa/mesa.git
cd mesa
git checkout mesa-17.1.9
./autogen.sh --prefix=/path/to/desired/mesa-inst --with-gallium-drivers="i915,swrast" --with-dri-drivers="i915,i965,swrast"
make -j 8
make install

And then I ran the tools with the given mesa installation like: LD_LIBRARY_PATH=/path/to/desired/mesa-inst/lib <your command here>
I'm not a fan of sudo make install, I don't want stuff that is not my package manager to mess with my root.

Hi;
On 10/21/2017 12:47 AM, est31 wrote:

Now that Ubuntu 17.10 artful has been released with Mesa version 17.2.2
this issue will affect more people. Including me!
The bug is indeed a regression of Mesa from the 17.1 branch to the 17.2
branch. I've ran a bisect and the first bad commit is:
|commit 6e06e281c6ee342276d087ed4ee4a442626e433a Author: Neha Bhende
<EMAIL_ADDRESS>Date: Wed Apr 26 16:21:32 2017 -0700 glx: add
missing sRGB attribute check in fbconfigs_compatible() This patch will
allow driver to choose srgb capable FBconfig if
GLX_FRAMEBUFFER_SRGB_CAPABLE_ARB attribute is 1 Reviewed-by: Brian Paul
<EMAIL_ADDRESS>Reviewed-by: Charmaine Lee<EMAIL_ADDRESS>|
I could also reproduce the bug on the latest master branch (commit
|59fb59ad54d368683d5cc3b149f021452bddc05f|) and on the 17.2.3 release.
There is a bug reported upstream for Mesa:
https://bugs.freedesktop.org/show_bug.cgi?id=102354
Supertuxkart ran into the same issue, they ended up supporting a
non-sRGB mode: supertuxkart/stk-code#2902
https://github.com/supertuxkart/stk-code/issues/2902
@tpalli https://github.com/tpalli has proposed a patch
https://bugs.freedesktop.org/attachment.cgi?id=134248 for the issue
but it got a negative response during review
https://lists.freedesktop.org/archives/mesa-dev/2017-September/168465.html
and was probably abandoned due to that reason, given that there have
been multiple stable releases on the 17.2 branch of Mesa since (17.2.2
and 17.2.3) and none of them included the patch.
It would be really nice to have the bug fixed by upstream Mesa!

The patch in question has not been abandoned but can be considered
'floating' as there are currently many other issues Mesa team is dealing
with and we wanted to try alternative approach. Unfortunately so far I
haven't figured out alternative that would not break other applications :/
I will ping some people to consider reviewing this soon if no better fix
can be found.
// Tapani

Thanks Tapani!

Fix has been pushed to Mesa master, now Mesa exposes BGRA8888 sRGB visuals. I will try to get it for mesa stable but as there are risks with that it might be that it will only come to new Mesa releases.

@tpalli that's really cool to hear! I'll try it out soon. "Pushed to master" means that it won't appear in any of the 17.2 or 17.3 releases, but need to wait for 17.4, right? It would definitely be nice to have it fixed in 17.2 and 17.3 as well :).

Yeah, it might land only to 17.4 due to it being a functional change, typically only bugfixes get accepted to stable release.

@tpalli I've tested the piston example with recent mesa master now (17.4.0-devel (git-ffc2060616)). It includes your patch, I have verified. It still failed with the familiar error :/. The apitrace dump output is:
2 glXChooseFBConfig(dpy = 0x7f752b28e000, screen = 0, attribList = {GLX_X_RENDERABLE, True, GLX_X_VISUAL_TYPE, GLX_TRUE_COLOR, GLX_DRAWABLE_TYPE, GLX_WINDOW_BIT, GLX_RENDER_TYPE, GLX_RGBA_BIT, GLX_RED_SIZE, 8, GLX_GREEN_SIZE, 8, GLX_BLUE_SIZE, 8, GLX_ALPHA_SIZE, 8, GLX_DEPTH_SIZE, 24, GLX_STENCIL_SIZE, 8, GLX_DOUBLEBUFFER, True, GLX_STEREO, False, GLX_FRAMEBUFFER_SRGB_CAPABLE_ARB, 1, GLX_CONFIG_CAVEAT, -1, 0}, nitems = &0) = NULL
5 glXChooseFBConfig(dpy = 0x7f752b28e000, screen = 0, attribList = {GLX_X_RENDERABLE, True, GLX_X_VISUAL_TYPE, GLX_TRUE_COLOR, GLX_DRAWABLE_TYPE, GLX_WINDOW_BIT, GLX_RENDER_TYPE, GLX_RGBA_BIT, GLX_RED_SIZE, 8, GLX_GREEN_SIZE, 8, GLX_BLUE_SIZE, 8, GLX_ALPHA_SIZE, 8, GLX_DEPTH_SIZE, 24, GLX_STENCIL_SIZE, 8, GLX_DOUBLEBUFFER, True, GLX_STEREO, False, GLX_FRAMEBUFFER_SRGB_CAPABLE_ARB, 1, GLX_CONFIG_CAVEAT, -1, 0}, nitems = &0) = NULL

Which distro are you running and are you running with XWayland or pure X/GLX? In case of 'pure X' (like for example Ubuntu 16.04) you will need to install the DRI driver so that X server is using the same one as your Mesa has (running against custom Mesa tree with LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH is not enough). In case of Fedora (XWayland) this should work without replacing system DRI driver.

@tpalli I'm running Kubuntu 17.10 with pure X. The test failure is probably due to me only setting LD_LIBRARY_PATH without installing the DRI driver... That one worked when I compiled Mesa 17.1 so I've thought it would work here too. About Wayland: I seem to not be able to reproduce the bug with Weston. Maybe it is using a software renderer?
Is there a way to set the DRI driver without changing something in the root fs? I just don't like to mess with it :).

Unfortunately this change requires both X server and Mesa to use exact same i965_dri.so because of the added visuals. Weston works because it uses EGL.

@tpalli @Biohazard50 reports that the issue is fixed for them on mesa master. Could we get a fix into 17.2 and 17.3? It is a fix of a regression so I would say that it qualifies as a bugfix.

Unfortunately there are 3 regression bugs open against this change, therefore stable is out of question. The regressions are:
https://bugs.freedesktop.org/show_bug.cgi?id=103655
https://bugs.freedesktop.org/show_bug.cgi?id=103699
https://bugs.freedesktop.org/show_bug.cgi?id=103646

@tpalli I see, thanks.

Is there anything I can do if I'm experiencing this issue? I'm trying to run some GUI tests on Travis CI. Travis does support GUI testing with xvfb, but trying to run my tests results in the error described in this issue.
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value:
"Couldn\'t find any pixel format that matches the criterias."', /checkout/src/libcore/result.rs:906:4
note: Run with `RUST_BACKTRACE=1` for a backtrace.

If it helps, here are my build logs. This is a problem I've also experienced when trying to run an app using piston_window on a Windows virtual machine using VirtualBox. Seems to happen a lot. :frowning_face:
Is there a way to work around it?

@sunjay see my comment above: https://github.com/PistonDevelopers/piston/issues/1202#issuecomment-338331123

@est31 Thanks. I went down the rabbit hole of trying to install mesa on Travis. No luck yet, but I will try again tomorrow. :)

Also experiencing this on appveyor VMs.
https://ci.appveyor.com/project/sunjay/turtle/build/1.0.236/job/whyvvn42mv39g3d6#L368
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "Couldn\'t find any pixel format that matches the criterias."', src\libcore\result.rs:906:4
stack backtrace:
   0: std::sys_common::backtrace::_print
             at C:\projects\rust\src\libstd\sys_common\backtrace.rs:92
   1: std::panicking::default_hook::{{closure}}
             at C:\projects\rust\src\libstd\panicking.rs:380
   2: std::panicking::default_hook
             at C:\projects\rust\src\libstd\panicking.rs:397
   3: std::panicking::rust_panic_with_hook
             at C:\projects\rust\src\libstd\panicking.rs:577
   4: std::panicking::begin_panic<alloc::string::String>
             at C:\projects\rust\src\libstd\panicking.rs:538
   5: std::panicking::begin_panic_fmt
             at C:\projects\rust\src\libstd\panicking.rs:522
   6: std::panicking::rust_begin_panic
             at C:\projects\rust\src\libstd\panicking.rs:498
   7: core::panicking::panic_fmt
             at C:\projects\rust\src\libcore\panicking.rs:71
   8: core::result::unwrap_failed<alloc::string::String>
             at C:\projects\rust\src\libcore\macros.rs:23
   9: core::result::Result<piston_window::PistonWindow<glutin_window::GlutinWindow>, alloc::string::String>::unwrap<piston_window::PistonWindow<glutin_window::GlutinWindow>,alloc::string::String>
             at C:\projects\rust\src\libcore\result.rs:772
  10: turtle::renderer::Renderer::run
             at .\src\renderer.rs:55
  11: turtle::server::main
             at .\src\server.rs:86
  12: turtle::server::start
             at .\src\server.rs:63
  13: turtle::turtle_window::TurtleWindow::new
             at .\src\turtle_window.rs:25
  14: turtle::turtle::Turtle::new
             at .\src\turtle.rs:99
  15: runtest::main
             at .\examples\runtest.rs:11
  16: panic_unwind::__rust_maybe_catch_panic
             at C:\projects\rust\src\libpanic_unwind\lib.rs:99
  17: std::rt::lang_start
             at C:\projects\rust\src\libstd\rt.rs:52
  18: main
  19: __scrt_common_main_seh
             at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:253
  20: BaseThreadInitThunk

Solution which helped me on Arch Linux:
sudo pacman -U https://archive.archlinux.org/packages/m/mesa/mesa-17.1.0-1-x86_64.pkg.tar.xz

What is the current status of this? Getting the same problem running the example on Mesa 17.3.3 Intel(R) UHD Graphics 620 (Kabylake GT2)

@ibrokemypie soon (within the next few days), we are going to have Mesa 18.0.0 with a fix for this. Until then you could try an RC build of 18.0.0.

This bug is terrible, I have waited months for the fix. Is there any workaround for it?

If you can specify that you don't need certain GLX features, you may get the window created.
I'm on my phone now so can't give a comprehensive reply, but if you have a read of the following gist, it may help you to figure out how to fix your particular set up:
https://gist.github.com/azriel91/7a33da3061fa1fb734083e8d22451f91

Working around this issue should just be a matter of requesting a PistonWindow with sRGB disabled. Unfortunately some of the higher level APIs override this setting for you. However, it should work if you directly create the window like this:
extern crate piston_window;
use piston_window::*;

let mut window: PistonWindow = PistonWindow::new(
    OpenGL::V3_3,
    0,
    WindowSettings::new("Hello World!", [640 480])
        .opengl(OpenGL::V3_3)
        .srgb(false)
        .build()
        .unwrap(),
);

Mesa 17.3.5-1 on Arch Linux is still bugged.
Downgrading to 17.1.0-1 temporarily fix the problem

@eisterman The 17.3 branch will never be fixed, even though it is still maintained. See the comment by the mesa developer above. All you can do is to wait for 18.0 which has the fix. There has been a 4th release candidate for 18.0 on Feb 9 and according to schedule we should already have had 18.0.1 on Feb 23 but there was no such message on the mesa announce list nor any message about the 18.0 branch after the rc4 email. Let's see when we'll get an official release of mesa version 18.0 that has the fix :). Look for emails on the mesa-announce list :).

Arch Linux was updated to Mesa 18.0 recently, so I tested my Piston project and it works now.

I've just updated to Ubuntu bionic (18.04) which uses Mesa 18.0.0-rc5. Can confirm that the bug is fixed. :tada:

Can also confirm this is now working again on my system with mesa 18.0.1-1. Thanks for the help everyone :blush:

The error still occurs on Arch linux updated. Using mesa 18.0.4-1. And by using arch, I am unable to install other mesa version.

@JeffBusterCase what does glxinfo | grep "renderer string" say?

@est31 It says: OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile

Are you absolutely sure your program is not using anything that is not supported by the GPU (OpenGL 4.1+, high level of anti-aliasing, etc.).

@JeffBusterCase  It works fine on my system:
Arch: 4.16.13-1
mesa: 18.0.4-1
glxinfo: OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 630 (Kaby Lake GT2)
Project: hello world example
Rust: 1.26.1 (stable) and 1.28.0 (nightly)

@C-Bouthoorn even hello_world doesn't work.
No more clue about what is happening, but maybe is cause I'm accessing it by chroot, so it makes me directs this question to some other repo. Thanks by the way. :)

Still getting this error on lubuntu. Updating the mesa drivers didn't work. Still need to test the srgb fix.
OS: Ubuntu 18.04 LTS
Project: hello world example
Rust: stable (1.27.1) + nightly (not sure how to check version)

@nyghtly-derek You don't seem to be hitting this bug, but rather window creating is failing for some other reason. You should look at exactly what Err() value is being returned by build, and then if the cause isn't obvious, figure out where that specific kind of error is generated.

@fintelia I'm think I'm getting the same error. It reads:
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "Couldn\'t find any pixel format that matches the criterias."', libcore /result.rs:945:5

@nyghtly-derek The fact that you have an updated mesa version and that disabling sRGB doesn't fix the issue strongly suggests that you are actually running into a different problem. It would probably be better to open a new issue if you aren't able to figure it out, but to point you in the right direction, you may want to compare the exact pixel format parameters you're requesting to the supported ones shown by glxinfo.


fix: bump after breaking change hardcoded niscode list

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


Fix transactions counters

Fix sender/recipient transactions counters.

This is an issue on the end of the modified node. Will be fixed later today.


Should use fork to better view commits

Since this project, as stated in the readme, is a fork from BSDS; why is it uploaded as a new repo?
This breaks the whole commit history thing :(

你看提交历史有什么用
还有其他用bsds改的私服都是这么写的
比如lsbs-v49

🥺


fix: Synchronize copy/paste between the editor and remote page.

Description

1.Prevent event penetration to the input box in the toolbar when screencast page input.
2.Synchronize copy/paste between the editor and remote page.
Linked Issues
#46
Additional context

Please delete this unnecessary pull request.


Global search with deferred AJAX call

When using the global search, it would be great if there was a deferred event on the input field that waits so many seconds before firing the Ajax call. This would allow users to type in lengthy search criteria (e.g. a surname) rather than having the Ajax call fire for each individual key press event.
Is there anything out of the box that does this already? I couldn't see anything in the documentation.

+1


Create Multiple DynamoDB Tables

This PR introduces changes that create 2 new DynamoDB tables. visits will be used to track individual visits, while users will be used to track the users that visit the space. This does not affect the lambda operation, as all reads/writes will still be to the old tables.

This PR will be the first to replace the changes in #88


Comparing residuals

The 2D residuals, for example for the wave problem (tutorial3), can have positive and negative color-bar values.
In order to compare multiple approaches with the same color-bar, should I take the absolute values, and then see where is lowest?
thanks!

Hi @dgm2! There is not a unique metric to assess the quality of the solution. Usually, one computes the $L_2$ norm (see here) of the residual for different methodologies and see which one archives the lowest. However, it depends on your specific problem and what you want to check👍🏻

The "best" value is when the residual is zero, so a very negative value is as bad as a very positive value. To assess which model is better you can look at the axis, the best model is the one with the colorbar values closer to zero.

Hi @dgm2! Can I close the issue, where you able to compare different pinns? We are preparing a tutorial exactly for that, stay tuned!


How to get LastReadLocator in FolioReader Please reply me

Issue / Feature -
FolioReader version -
FolioReader Stock / Modified -
Android SDK -
Mobile / Tablet / Emulator Info -
Crash / Error -
Steps to reproduce / Describe in detail -
How to get LastReadLocator in FolioReader Please reply me

did you manage to find a tutorial about ReadLocator ? I'm stuck :( I cant find any demo on GitHub with this feature

did you manage to find a tutorial about ReadLocator ? I'm stuck :( I cant find any demo on GitHub with this feature


urls in a sitemap are https:// instead of https:/

A bug in the realAdd function was causing sitemap URLS to be generated with only one slash in their addresses, which is not a valid URL. This change uses path.Join instead of filepath.Join to fix. Also wrote a test to check that the url is what is expected.

Great job Siri!
Please roll go.mod back, so I can merge it.

Never mind! I fixed it.

Thanks for merging Saeed!


[enhancement] Disregard non-running pods

Describe the enhancement you'd like
I have been using the Kubernetes dashboards provided in this repository, and I appreciate the work that has gone into creating them. However, I’ve noticed that some of the metrics currently include non-running pods, which can lead to inaccurate resource usage and performance insights.
Specifically, I would like to request the following changes to ensure that PromQL queries related to resource requests and limits (specifically kube_pod_container_resource_requests and kube_pod_container_resource_limits) explicitly filter out non-running pods. For example, metrics like kube_pod_status_phase should include a check for phase="Running".
Current expressions:
sum(kube_pod_container_resource_requests{namespace=~"$namespace", resource="cpu", cluster="$cluster"})
sum(kube_pod_container_resource_limits{namespace=~"$namespace", resource="memory", cluster="$cluster"})
Proposed modifications:
sum(kube_pod_container_resource_requests{namespace=~"$namespace", resource="cpu"} * on(namespace, pod) group_left() (sum(kube_pod_status_phase{phase="Running", cluster="$cluster"}) by (pod, namespace) == 1))
sum(kube_pod_container_resource_limits{namespace=~"$namespace", resource="memory"} * on(namespace, pod) group_left() (sum(kube_pod_status_phase{phase="Running", cluster="$cluster"}) by (pod, namespace) == 1))
Similar modifications should be applied to all relevant metrics to accurately reflect the state of running pods.
Additional context
No response

Hi we have imilar issue for memory/cpu metrics. When pod is restarted, metrics for it persists for a little while, thus creating peaks in cpu/memory metrics since they are summing 2 metrics together. We have added id to expression to separate them.
Current expression:
"sum(rate(container_cpu_usage_seconds_total{namespace=\"$namespace\", pod=~\"$pod\", image!=\"\", container!=\"\", cluster=\"$cluster\"}[$__rate_interval])) by (container)"
Changed expression:
"sum(rate(container_cpu_usage_seconds_total{namespace=\"$namespace\", pod=~\"$pod\", image!=\"\", container!=\"\", cluster=\"$cluster\"}[$__rate_interval])) by (container,id)"
Similarly to cpu, network and other metrics.


Sketch2image

First of all thanks for the amazing repository!
I have been playing with image generation from paint sketches for a while and I thought it would be nice to industrialize a bit the process.
I used Streamlit because I'm mostly developing in Python and I have no experience with JS or anything fancier.
I will create the PR as a draft for the moment so that those who are interested can test, eventually give some feedback and if you think this would be a nice addition to the repo I'll change what needs to be changed and we can merge :)
I tried to keep the changes to the original codebase as light as possible
Install/Dependencies
requirements.txt is up to date, only addition was streamlit-drawable-canvas==0.9.1
! Creating a folder streamlit on /outputs might be necessary !
Usage

To run, use streamlit run scripts/sketch2image.py.
Go to localhost:8501 on your browser (loading can take a bit, just like dream.py. Loading logs should be visible on the terminal.)
Give a name to the project, draw something and add a prompt. Or you can test the default parameters with this beautiful illustration of a castle on a cliff I did myself:

Adjust parameters and click on Generate new images
Once the N images are generated, a button wil be visible by the side of each image. By clicking on it we start a new iteration. Basically, this image is sent to the canvas, can be redrawn upon et is ready for another generation. Notice the go back/forward buttons that let you come back to older generations if you wish.
!! I have still not done the cleaning of the uploaded file, if it exists, and the automatic flush of the canvas once another image is loaded as background. So please remove the upload files on the sidebar and clean the canvas with the icon on the bottom left of the canvas if the image does not update at first. Same applies for the rest button on the top !!

TODOs

Properly reset the page
Better interface
Add all model parameters
Safe check back/forward buttons

Conclusion
I'm very open to any kind of feedback if anyone has the time to test this :)
I'll be more active at the beginning of the week for evolutions!

I love this and can't wait to start playing with it. Is there a particular version of streamlit that needs to run? I see 1.11.0 in the default conda channels.

Nice, thank you for your response!
I used the one that was already in the requirements.txt, streamlit==1.12.0.
Usage is pretty vanilla, so I don't expect that close version should be a problem.

Do you think you could connect this to the dream.py --web interface, like on a 'Sketch' button ?

Hmm it might be possible, altough we would still have a separate app running with streamlit. I can have a go at it tomorrow see if I can get it to work!
The most interesting part, in my opinion, is to be able to iterate on the results and edit at the same time and I don't really know how to do that with the --web interface right now.

I think this draft PR has been up long. I'm going to close it now. I think it was better suited as a Discussion item, and I encourage you to move it there.

@lstein I've been holding off on this pending our inpainting implementation but a simple sketch thing I can certainly do. I actually did a rough implementation a while ago but it appears that git stash is lost to the sands of time.

This will be implemented in #1355 .


Develop

In this commit the project is ready for the main branch because all works and the teacher want this in main

Read this Yero
In this pull request i made several changes in the vector model implementation for calculating the document vectors much faster. I recommend that you test this or at least read the changes before acepting this pull request. Plus I can not merge it directly because I added some protections to the branch to block a single person to merge in main, it means that at least a person different than me needs to review it and click the merge button


(Lucie) Wait for labs to get back to us

[ ]  WSUMARCS_adults_participantdata.csv has duplicated columns with different values - so probably want to reduce to just the columns with the correct values:
second_session
session_error_notes

[ ] babylabNijmegen
adult: why is RU_022 missing?
baby: why are RU_016, RU_023 missing?

babylabNijmegen sent us the missing data files. The data can be found here: https://drive.google.com/drive/u/0/folders/1-vT1ibGKJna2jXxTzFmFRa78uPEXiWVf

the demo data file of WSUMARCS is also updated on OSF and GoogleDrive

babylabNijmegen sent us the missing data files. The data can be found here: https://drive.google.com/drive/u/0/folders/1-vT1ibGKJna2jXxTzFmFRa78uPEXiWVf

@yanwei-W could you have a look at this?

babylabNijmegen sent us the missing data files. The data can be found here: https://drive.google.com/drive/u/0/folders/1-vT1ibGKJna2jXxTzFmFRa78uPEXiWVf

@yanwei-W could you have a look at this?

Sure！

I have added the new data into the files and uploaded them to OSF.

I have added the new data into the files and uploaded them to OSF. @adriansteffan

Thanks for that, we nearly fixed all ID mismatches now! It seems that RU_016 is still missing from the toddler eyetracking data on OSF. Could you take another look at that?

@yanwei-W : could you please check the eye-tracking data of babylabNijmegen_toddlers that are saved on OSF again and add the data of RU_016? The lab sent us the missing tsv-file of RU_016 which can be found here https://drive.google.com/drive/u/0/folders/1-vT1ibGKJna2jXxTzFmFRa78uPEXiWVf

OK, I'm working on it.

I find out the problem. It seems that the lab recorded ParticipantName of RU_016 as "RU_017". I will fix it and upload again.


Classic: tank units and nodes

•"So in the name of the tanks differ from the easy mode, the units are not correct, the modules are not in the correct section (science), the clipping of the Station Hubs are not working (especially the top and bottom node)."

• Classic is very much legacy. The locations of parts and how they work comes directly from the very first release of BioMass.
• The top/bottom node issue with the hubs is due to a change in how KSP read in node locations. This we can fix.


UseStaticImport removes type in Javadoc links

UseStaticImport shortens Javadoc link tags if they match the given methodPattern. The link is broken afterwards, Javadoc does not resolve static imports.
What is the smallest, simplest way to reproduce the problem?

    @Issue("https://github.com/openrewrite/rewrite/issues/3663")
    @Test
    void javadocLinkUnchanged() {
        rewriteRun(
          spec -> spec.recipe(new UseStaticImport("java.util.Collections emptyList()")),
          java(
            """
            import java.util.Collections;
            import java.util.List;

            public class WithJavadoc {
                /**
                 * This method uses {@link Collections#emptyList()}.
                 */
                public void mustNotChangeTheJavadocAbove() {
                    List<Object> list = Collections.emptyList();
                }
            }
            """,
            """
            import java.util.List;

            import static java.util.Collections.emptyList;

            public class WithJavadoc {
                /**
                 * This method uses {@link Collections#emptyList()}.
                 */
                public void mustNotChangeTheJavadocAbove() {
                    List<Object> list = emptyList();
                }
            }
            """
          )
        );
    }

What did you expect to see?
Only the call inside the method should change.
What did you see instead?

    import java.util.List;

    import static java.util.Collections.emptyList;

    public class WithJavadoc {
        /**
         * This method uses {@link emptyList()}.
         */
        public void mustNotChangeTheJavadocAbove() {
            List<Object> list = emptyList();
        }
    }

Both the Javadoc and the method call have changed. The Javadoc is now invalid and will lead to an "invalid reference" error during Javadoc generation.
Are you interested in contributing a fix to OpenRewrite?

No. I'm not sure how Javadoc is handled by the visitors.

Thanks for the detailed report! Indeed better to not update the JavaDoc here. Surprised we even did that originally. From the recipe implementation I don't immediately see how we're removing that either, but with your tests we can start to step through.
https://github.com/openrewrite/rewrite/blob/2173a7125fd4360b71a998c70b6eb9b6431eedba/rewrite-java/src/main/java/org/openrewrite/java/UseStaticImport.java#L60-L76

I meanwhile know this happens because the JavadocVisitor detects a method reference and delegates to the JavaVisitor at https://github.com/openrewrite/rewrite/blob/e908b09f87d945f5ce0198a0f8f826347732864e/rewrite-java/src/main/java/org/openrewrite/java/JavadocVisitor.java#L271.
To fix this, the visitor for the recipe would have to be disabled temporarily as long as it's stack trace is inside the javadoc visit. So an additional class along these lines seems reasonable:
    private class UseStaticImportJavadocVisitor extends JavadocVisitor<ExecutionContext> {
        public UseStaticImportJavadocVisitor() {
            super(new JavaVisitor<>());
        }

        @Override
        public Javadoc visitDocComment(Javadoc.DocComment javadoc, ExecutionContext executionContext) {
            try {
                inJavadoc = true;
                return super.visitDocComment(javadoc, executionContext);
            }
            finally {
                inJavadoc = false;
            }
        }
    }

The inJavadoc field could now be used by the JavaVisitor. However, I have not yet found an example how to combine 2 different visitors via composition to get one resulting visitor that visits the implementations of both. Is there some utility available or would this rather mean to fall back to implementing a single visitor that derives from the common super class of JavaVisitor and JavadocVisitor?


Log Point default message is cut off when Explorer is on the right

Version: 1.55.0-insider
OS: Mac
Steps to Reproduce:

Move activity bar to the right and show explorer
Add a log point
Hide explorer and the default codelens/message in the Log Point is cut off

Yeah, that's just life.
We could wrap the placeholder message, but then the breakpoint input could take potentially more lines.
We do no do this in other places (SCM Commit box for example).
So I would for now not change anything here


Fix link to github repo for 'Edit this page' link

At the bottom of the Introduction page, https://realworld-docs.netlify.app/docs/intro, the link to the github repo seems to be broken.
It is sending us to:
https://github.com/gothinkster/realworld/tree/main/docs/docs/docs/intro.mdx
I think it should be:
https://github.com/gothinkster/realworld/blob/main/apps/documentation/docs/intro.mdx
So, I have made a pull request here. I am not sure if this is the correct place for this change to be made.
I notice that there may be a similar problem a few lines below with the link to the blog on line 33, but I could not find the blog so I have not investigated further.

Summary

🤖 Generated by Copilot at 60415e0
Fixed the edit links for the documentation pages by updating the editUrl configuration in docusaurus.config.js. This improves the user experience and the contribution workflow for the documentation.
Details

🤖 Generated by Copilot at 60415e0

Fix the edit URL for documentation pages (link)

Thanks for your contribution once again!


get rid of awkward hack to check for github repo

would be nicer to use a real check from some other pkg here.

this is currently working via gh:: but it'd be nicer if some other pkg did this out of the box.


bash: cd: jetson-inference/: no such file or directory

Hi,
I tried to follow your instructions but at the very beginning a problem occurs.

bash: cd: jetson-inference/: no such file or directory

Maybe it's because of the image I downloaded? (jetson-nano-4gb-jp441-sd-card-image)
I downloaded it from this page:
https://developer.nvidia.com/embedded/learn/get-started-jetson-nano-devkit#write
Or do I simply have to use a different directory?
Best regards
chris

BTW when you see "cd jetson-inference/" it means to cd into the directory that you cloned the repo into.

From: chrisTopp84<EMAIL_ADDRESS>Sent: Saturday, October 24, 2020 3:29:49 AM
To: dusty-nv/jetson-inference<EMAIL_ADDRESS>Cc: Subscribed<EMAIL_ADDRESS>Subject: Re: [dusty-nv/jetson-inference] bash: cd: jetson-inference/: no such file or directory (#769)
Closed #769https://github.com/dusty-nv/jetson-inference/issues/769.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/dusty-nv/jetson-inference/issues/769#event-3916440232, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADVEGK2LVVHWPMBNNO6OFADSMJ663ANCNFSM4S5L3VBQ.


AsyncCompletion sample: removes default c++ intellisense sense?

Installed products
Microsoft Visual Studio Community 2019
Version 16.7.5
Description
Hi! I want to add suggestions to default intellisense sense list. When I compile and try the AsyncCompletionSample, the default intellisense sense is removed. I tried to follow the comments and returned CompletionStartData.ParticipatesInCompletionIfAny; in public CompletionStartData InitializeCompletion(CompletionTrigger trigger, SnapshotPoint triggerLocation, CancellationToken token), then only sugestions from default intellisense sense is visible in the list. I want my sugestions to coexist with the default intellisense sense, is this possible to achieve or how are your supposed to go about this? I also want to be able to have multiple vsix extenstions active at the same time with AsyncCompletion.
Steps to recreate

Open AsyncCompletionSample
Download NuGet packages
Run
Open .cpp file
Try to use intellisense sense

I believe that Intellisense for C++ still uses the old not-async way of doing it : https://docs.microsoft.com/en-us/visualstudio/extensibility/walkthrough-displaying-statement-completion?view=vs-2019
However this example adds a "CompletionSet" so your suggestions won't exactly be in the same list as the default Intellisense, but at least it won't completely remove the default suggestions.


chore: release main

:robot: I have created a release beep boop
@libp2p/autonat: 1.0.8
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface-internal bumped from ^1.0.5 to ^1.0.6
@libp2p/peer-id-factory bumped from ^4.0.3 to ^4.0.4

@libp2p/bootstrap: 10.0.11
Dependencies

The following workspace dependencies were updated

devDependencies

@libp2p/interface-compliance-tests bumped from ^5.1.1 to ^5.1.2

@libp2p/circuit-relay-v2: 1.0.11
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface-internal bumped from ^1.0.5 to ^1.0.6
@libp2p/peer-collections bumped from ^5.1.3 to ^5.1.4
@libp2p/peer-record bumped from ^7.0.4 to ^7.0.5
@libp2p/utils bumped from ^5.2.0 to ^5.2.1

devDependencies

@libp2p/interface-compliance-tests bumped from ^5.1.1 to ^5.1.2
@libp2p/peer-id-factory bumped from ^4.0.3 to ^4.0.4

crypto: 4.0.0
4.0.0 (2024-01-12)
⚠ BREAKING CHANGES

Legacy RSA operations are now in @libp2p/rsa, streaming AES-CTR ciphers are in @libp2p/aes-ctr

Bug Fixes

remove node-forge dependency from @libp2p/crypto (#2355) (856ccd7)

@libp2p/dcutr: 1.0.8
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface-internal bumped from ^1.0.5 to ^1.0.6

@libp2p/fetch: 1.0.8
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface-internal bumped from ^1.0.5 to ^1.0.6

devDependencies

@libp2p/peer-id-factory bumped from ^4.0.3 to ^4.0.4

@libp2p/floodsub: 9.0.7
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/pubsub bumped from ^9.0.5 to ^9.0.6

devDependencies

@libp2p/interface-compliance-tests bumped from ^5.1.1 to ^5.1.2
@libp2p/peer-collections bumped from ^5.1.3 to ^5.1.4
@libp2p/peer-id-factory bumped from ^4.0.3 to ^4.0.4

@libp2p/identify: 1.0.10
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface-internal bumped from ^1.0.5 to ^1.0.6
@libp2p/peer-record bumped from ^7.0.4 to ^7.0.5

devDependencies

@libp2p/peer-id-factory bumped from ^4.0.3 to ^4.0.4

@libp2p/interface-compliance-tests: 5.1.2
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface-internal bumped from ^1.0.5 to ^1.0.6
@libp2p/peer-collections bumped from ^5.1.3 to ^5.1.4
@libp2p/peer-id-factory bumped from ^4.0.3 to ^4.0.4
@libp2p/utils bumped from ^5.2.0 to ^5.2.1

@libp2p/interface-internal: 1.0.6
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/peer-collections bumped from ^5.1.3 to ^5.1.4

@libp2p/kad-dht: 12.0.3
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/crypto bumped from ^3.0.4 to ^4.0.0
@libp2p/interface-internal bumped from ^1.0.5 to ^1.0.6
@libp2p/peer-collections bumped from ^5.1.3 to ^5.1.4
@libp2p/utils bumped from ^5.2.0 to ^5.2.1

devDependencies

@libp2p/interface-compliance-tests bumped from ^5.1.1 to ^5.1.2
@libp2p/peer-id-factory bumped from ^4.0.3 to ^4.0.4
@libp2p/peer-store bumped from ^10.0.5 to ^10.0.6

@libp2p/keychain: 4.0.6
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/crypto bumped from ^3.0.4 to ^4.0.0

devDependencies

@libp2p/peer-id-factory bumped from ^4.0.3 to ^4.0.4

@libp2p/mdns: 10.0.11
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface-internal bumped from ^1.0.5 to ^1.0.6
@libp2p/utils bumped from ^5.2.0 to ^5.2.1

devDependencies

@libp2p/interface-compliance-tests bumped from ^5.1.1 to ^5.1.2
@libp2p/peer-id-factory bumped from ^4.0.3 to ^4.0.4

mplex: 10.0.11
10.0.11 (2024-01-12)
Bug Fixes

replace rate-limiter (#2356) (ddaa59a)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/utils bumped from ^5.2.0 to ^5.2.1

devDependencies

@libp2p/interface-compliance-tests bumped from ^5.1.1 to ^5.1.2

@libp2p/multidim-interop: 2.0.15
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/circuit-relay-v2 bumped from ^1.0.10 to ^1.0.11
@libp2p/identify bumped from ^1.0.9 to ^1.0.10
@libp2p/mplex bumped from ^10.0.10 to ^10.0.11
@libp2p/ping bumped from ^1.0.8 to ^1.0.9
@libp2p/tcp bumped from ^9.0.10 to ^9.0.11
@libp2p/webrtc bumped from ^4.0.14 to ^4.0.15
@libp2p/websockets bumped from ^8.0.10 to ^8.0.11
@libp2p/webtransport bumped from ^4.0.14 to ^4.0.15
libp2p bumped from ^1.1.1 to ^1.1.2

@libp2p/peer-collections: 5.1.4
Dependencies

The following workspace dependencies were updated

devDependencies

@libp2p/peer-id-factory bumped from ^4.0.3 to ^4.0.4

@libp2p/peer-id-factory: 4.0.4
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/crypto bumped from ^3.0.4 to ^4.0.0

@libp2p/peer-record: 7.0.5
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/crypto bumped from ^3.0.4 to ^4.0.0
@libp2p/utils bumped from ^5.2.0 to ^5.2.1

devDependencies

@libp2p/peer-id-factory bumped from ^4.0.3 to ^4.0.4

@libp2p/peer-store: 10.0.6
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/peer-collections bumped from ^5.1.3 to ^5.1.4
@libp2p/peer-record bumped from ^7.0.4 to ^7.0.5

devDependencies

@libp2p/peer-id-factory bumped from ^4.0.3 to ^4.0.4

@libp2p/perf: 3.0.11
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface-internal bumped from ^1.0.5 to ^1.0.6

devDependencies

@libp2p/interface-compliance-tests bumped from ^5.1.1 to ^5.1.2

@libp2p/ping: 1.0.9
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/crypto bumped from ^3.0.4 to ^4.0.0
@libp2p/interface-internal bumped from ^1.0.5 to ^1.0.6

devDependencies

@libp2p/peer-id-factory bumped from ^4.0.3 to ^4.0.4

@libp2p/plaintext: 1.0.11
Dependencies

The following workspace dependencies were updated

devDependencies

@libp2p/interface-compliance-tests bumped from ^5.1.1 to ^5.1.2
@libp2p/peer-id-factory bumped from ^4.0.3 to ^4.0.4

@libp2p/prometheus-metrics: 3.0.11
Dependencies

The following workspace dependencies were updated

devDependencies

@libp2p/interface-compliance-tests bumped from ^5.1.1 to ^5.1.2
@libp2p/peer-id-factory bumped from ^4.0.3 to ^4.0.4

@libp2p/pubsub: 9.0.6
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/crypto bumped from ^3.0.4 to ^4.0.0
@libp2p/interface-internal bumped from ^1.0.5 to ^1.0.6
@libp2p/peer-collections bumped from ^5.1.3 to ^5.1.4
@libp2p/utils bumped from ^5.2.0 to ^5.2.1

devDependencies

@libp2p/peer-id-factory bumped from ^4.0.3 to ^4.0.4

@libp2p/tcp: 9.0.11
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/utils bumped from ^5.2.0 to ^5.2.1

devDependencies

@libp2p/interface-compliance-tests bumped from ^5.1.1 to ^5.1.2

@libp2p/upnp-nat: 1.0.9
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface-internal bumped from ^1.0.5 to ^1.0.6
@libp2p/utils bumped from ^5.2.0 to ^5.2.1

devDependencies

@libp2p/peer-id-factory bumped from ^4.0.3 to ^4.0.4

utils: 5.2.1
5.2.1 (2024-01-12)
Bug Fixes

replace rate-limiter (#2356) (ddaa59a)

Dependencies

The following workspace dependencies were updated

devDependencies

@libp2p/peer-id-factory bumped from ^4.0.3 to ^4.0.4

@libp2p/webrtc: 4.0.15
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface-internal bumped from ^1.0.5 to ^1.0.6
@libp2p/utils bumped from ^5.2.0 to ^5.2.1

devDependencies

@libp2p/circuit-relay-v2 bumped from ^1.0.10 to ^1.0.11
@libp2p/interface-compliance-tests bumped from ^5.1.1 to ^5.1.2
@libp2p/peer-id-factory bumped from ^4.0.3 to ^4.0.4
@libp2p/websockets bumped from ^8.0.10 to ^8.0.11
libp2p bumped from ^1.1.1 to ^1.1.2

@libp2p/websockets: 8.0.11
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/utils bumped from ^5.2.0 to ^5.2.1

devDependencies

@libp2p/interface-compliance-tests bumped from ^5.1.1 to ^5.1.2

@libp2p/webtransport: 4.0.15
Dependencies

The following workspace dependencies were updated

devDependencies

@libp2p/peer-id-factory bumped from ^4.0.3 to ^4.0.4
libp2p bumped from ^1.1.1 to ^1.1.2

libp2p: 1.1.2
1.1.2 (2024-01-12)
Bug Fixes

query routing for RSA public key (#2350) (ee7ffe9)
replace rate-limiter (#2356) (ddaa59a)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/crypto bumped from ^3.0.4 to ^4.0.0
@libp2p/interface-internal bumped from ^1.0.5 to ^1.0.6
@libp2p/peer-collections bumped from ^5.1.3 to ^5.1.4
@libp2p/peer-id-factory bumped from ^4.0.3 to ^4.0.4
@libp2p/peer-store bumped from ^10.0.5 to ^10.0.6
@libp2p/utils bumped from ^5.2.0 to ^5.2.1

devDependencies

@libp2p/circuit-relay-v2 bumped from ^1.0.10 to ^1.0.11
@libp2p/identify bumped from ^1.0.9 to ^1.0.10
@libp2p/interface-compliance-tests bumped from ^5.1.1 to ^5.1.2
@libp2p/mplex bumped from ^10.0.10 to ^10.0.11
@libp2p/plaintext bumped from ^1.0.10 to ^1.0.11
@libp2p/tcp bumped from ^9.0.10 to ^9.0.11
@libp2p/websockets bumped from ^8.0.10 to ^8.0.11

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/multidim-interop-v2.0.15 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/plaintext-v1.0.11 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/crypto-v4.0.0 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/interface-compliance-tests-v5.1.2 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/interface-internal-v1.0.6 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/kad-dht-v12.0.3 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/keychain-v4.0.6 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/libp2p-v1.1.2 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/prometheus-metrics-v3.0.11 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/peer-collections-v5.1.4 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/bootstrap-v10.0.11 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/mdns-v10.0.11 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/peer-id-factory-v4.0.4 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/peer-record-v7.0.5 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/peer-store-v10.0.6 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/autonat-v1.0.8 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/dcutr-v1.0.8 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/fetch-v1.0.8 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/identify-v1.0.10 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/perf-v3.0.11 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/ping-v1.0.9 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/pubsub-v9.0.6 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/floodsub-v9.0.7 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/mplex-v10.0.11 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/circuit-relay-v2-v1.0.11 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/tcp-v9.0.11 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/webrtc-v4.0.15 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/websockets-v8.0.11 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/webtransport-v4.0.15 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/upnp-nat-v1.0.9 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/utils-v5.2.1 :sunflower:


Expose num_segmets to add_shapes for shape_type ellipse

🚀 Feature ?or Bugfix?
add_shapes should expose a parameter such as num_segments for shapes that require approximation by polygons, e.g. ellipse.
The function napari.layers.shapes._shape_utils.triangulate_ellipse has such a parameter as an argument, but the calling functions don't use this, so in practice the default value of 100 is always used.  (https://github.com/napari/napari/blob/0bc1adc290d50f9793bd1b7c0ce912095f2e2354/napari/layers/shapes/_shapes_utils.py#L444)
Motivation
This image below shows some points to which I fitted a circle (there are other points outside the field of view). The fitted circle is shown as a white shape. The visual impression is that the fit is not very good as the shape doesn't coincide with the points:

However, the fit is actually very good, but the polygon approximating the displayed circle is too coarse. In the example above, the points lie in a part of the circle that is approximated by a straigt line segment. A matplotlip plot with different scale shows that the fitted circle actually goes through the points:

I do not see a way to change the number of polygon vertices without calling private functions in _shape_utils.
Pitch
The num_segments should be exposed to add_shapes
Alternatives
A possible alternative would be to automatically determine the number of vertices required to stay below a certain error.
However, I think this would have to take the zoom level into account, so may not be practical.

This makes sense but the UX and API questions are pretty massive. Do we make this a per-shape parameter? Do we implement this as multiscale shapes, which we want to do anyway? Definitely interested in discussion with a few core devs here...

While it doesn't solve the underlying problem at all, a short-term improvement might be to increase the default value for num_segments from 100 to 360. The drawback would be that it could cause reduced performance for users who need to visualize many circles.


SVS bootstrapping and fast catch-up protocol

Implement faster bootstrapping and catch-up when a user joins or comes back online.
Initial thoughts:

Every piece of data in workspace is a small CRDT delta. The slow part of the pipeline is fetching each piece of data.
We can just bundle all data packets into a single larger data packet and make it faster
When the user comes online, it hears the state vector. Subsequently they can fetch the bundle / snapshot from the entity that sent the state vector (another user or repo)
The bundle can be fetched using the state vector as a version number. To account for the data the user already has, we can use two state vectors as a way to fetch everything in between.

Considerations:

This isn't ideal since there's no history pruning (not supported by Yjs?). There may be other CRDT algorithms that can do this (see https://braid.org/antimatter)
Do we store "ready" bundles or build them on the fly? Performance.
Can we exclude the signatures from individual bundled deltas?
How to handle corner cases, e.g. the bundle producer does not (yet?) have all the requested data. Send partial bundle back with a longer name?

Refer to #4

Let's use #4 for further discussion.


types.nix: better error message for non-paths

This improves error messages when a set or a list is used where a path
was expected. For an example, if you used a package set (as opposed to a
single package) in systemPackages before this commit, the error was:
cannot coerce a list to a string, at "/home/nixpkgs/lib/types.nix":103:37

Now, the error message reads:
The option value `environment.systemPackages' in `/etc/nixos/configuration.nix' is not a list of paths.

/cc @shlevy @edolstra, are you ok with this change (I have never worked with types.nix before)? (you seem to have done the most changes to types.nix)

Looks ok to me

Yup looks good to merge :+1:

Why not just check with isString whether the argument is a string?

@edolstra builtins.isString { outPath = "example"; } returns false, but we want derivations to be accepted as paths.

Hm, do we? We already have types.package that does allow derivations. My understanding of types.path is that it's for non-store paths, such as state directories (e.g. services.postgresql.dataDir). It's probably better to extend types.package to support store paths (strings) in addition to derivations.

@edolstra systemPackages is of type listOf path, so I thought it was for derivations. So systemPackages should rather use listOf package then?

Hm, you're right. It happens to work because of the toString coercion. listOf package would be better.

Ok, changed systemPackages to use listOf package and used isString check for path. Not sure if there are any other places where we use path but really want package?

@edolstra Why would package need to support store paths to? Should it be possible to put store paths in systemPackages?

I'd say that we shouldn't put arbitrary store paths in systemPackages, but with the advent of multiple-output derivations, people might be putting in things like packageFoo.output5, which would be a path rather than a derivation (I think?)

@copumpkin Seems to work fine in that case too:
nix-repl> (import <nixpkgs> {}).lib.isDerivation (import <nixpkgs> {}).boost.lib
true

Oh, perfect then.

Check out https://github.com/NixOS/nix/blob/1.8/corepkgs/derivation.nix for more details on what's going on (derivationStrict is a primop that returns a set with an attr drvPath corresponding to the derivation path (with associated context) and an attr for each output corresponding to that output's path (with associated context))


add view tests and fix a couple bugs

Codecov Report

Merging #153 into init-lerna will increase coverage by 16.75%.
The diff coverage is 83.33%.

@@               Coverage Diff               @@
##           init-lerna     #153       +/-   ##
===============================================
+ Coverage       40.81%   57.57%   +16.75%
===============================================
  Files               3        4        +1
  Lines              49       66       +17
  Branches           11       12        +1
===============================================
+ Hits               20       38       +18
+ Misses             29       28        -1

Impacted Files
Coverage Δ

packages/nexus-sdk/src/View/index.ts
88.23% <100%> (ø)

packages/nexus-sdk/src/testUtils.ts
75% <80%> (+37.5%)
:arrow_up:

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 12e926b...bb0fe0c. Read the comment docs.


Update Shell-Completion.md

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.
[ ] Have you successfully run brew style with your changes locally?
[ ] Have you successfully run brew typecheck with your changes locally?
[ ] Have you successfully run brew tests with your changes locally?

Info here

CC @maxim-belkin and any @Homebrew/maintainers who know about Bash completions here. I've got a feeling we've talked about this before but I can't remember the context.

Changes proposed here make sense to me. A few more comments:

$HOMEBREW_PREFIX/etc/profile.d directory is installed by bash-completion or bash-completion@2 formula. Why do we mention it in the docs?
All Bash completion files installed by formulae (including completions file for brew) are
symlinked to $HOMEBREW_PREFIX/etc/bash_completion.d/

So, my recommendations are:

Remove [[ -r "${COMPLETION}" ]] && in added for loop -- it would be best to fail if a file is not readable.
Don't mention "${HOMEBREW_PREFIX}/etc/profile.d/bash_completion.sh" here. It is explained in "Caveats" of bash-completion and bash-completion@2 formulas.

the underlying completion loader already does pretty much what this PR is trying to force:

Indeed, bash-completion and bash-completion@2 formulae take care of $HOMEBREW_PREFIX/etc/bash_completion.d folder. I feel that used "shortcuts" in the documentation and formulae' caveats add confusion: it might be better if Homebrew/brew docs mention default completion location and code snippet and "Caveats" for both bash-completion and bash-completion@2 formulae explained that suggested code snippet can replace the one suggested by default.

it might be better if Homebrew/brew docs mention default completion location and code snippet, whereas "Caveats" for both bash-completion and bash-completion@2 formulae can explain that suggested code snippet replaces the one suggested by default.

This makes sense to me, @gromgit?

As originally conceived in https://github.com/Homebrew/brew/pull/6322, the suggested script uses an if/else because bash_completion.sh, as installed by either the bash-completion or bash-completion@2 formulae, already reads the contents of ${HOMEBREW_PREFIX}/etc/bash_completion.d/ via the bash_completion script that it references. The suggested change will result in the contents of bash_completion.d being read twice if either of the above formulae are installed.
As with @gromgit, I wasn't able to reproduce the behaviour of bash_completion.d being skipped.

Happy to continue discussion here but closing as several folks cannot reproduce.

@gromgit Its empty.
env | grep BASH_COMPLETION

I don't see any mentioning about bash_completion.d in bash_completion.sh:
cat ${HOMEBREW_PREFIX}/etc/profile.d/bash_completion.sh
# shellcheck shell=sh disable=SC1091,SC2039,SC2166
# Check for interactive bash and that we haven't already been sourced.
if [ "x${BASH_VERSION-}" != x -a "x${PS1-}" != x -a "x${BASH_COMPLETION_VERSINFO-}" = x ]; then

    # Check for recent enough version of bash.
    if [ "${BASH_VERSINFO[0]}" -gt 4 ] ||
        [ "${BASH_VERSINFO[0]}" -eq 4 -a "${BASH_VERSINFO[1]}" -ge 2 ]; then
        [ -r "${XDG_CONFIG_HOME:-$HOME/.config}/bash_completion" ] &&
            . "${XDG_CONFIG_HOME:-$HOME/.config}/bash_completion"
        if shopt -q progcomp && [ -r<EMAIL_ADDRESS>]; then
            # Source completion code.
<EMAIL_ADDRESS>        fi
    fi

fi

Seems like its should be here:
[ -r "${XDG_CONFIG_HOME:-$HOME/.config}/bash_completion" ] &&
            . "${XDG_CONFIG_HOME:-$HOME/.config}/bash_completion"

But for me its empty: echo $XDG_CONFIG_HOME.

The latest version of bash provided by brew is 5.2.15 and in the script its checking for 4.2, so its not working for latest bash. Maybe this is the issue?
if [ "${BASH_VERSINFO[0]}" -gt 4 ] ||
        [ "${BASH_VERSINFO[0]}" -eq 4 -a "${BASH_VERSINFO[1]}" -ge 2 ]; then
        [ -r "${XDG_CONFIG_HOME:-$HOME/.config}/bash_completion" ] &&
            . "${XDG_CONFIG_HOME:-$HOME/.config}/bash_completion"
        if shopt -q progcomp && [ -r<EMAIL_ADDRESS>]; then
            # Source completion code.
<EMAIL_ADDRESS>        fi
    fi

The latest version of bash provided by brew is 5.2.15 and in the script its checking for 4.2

Bash versions 4+ are taken care of by the first check: if [ "${BASH_VERSINFO[0]}" -gt 4 ].
So, I recommend that you start debugging from the end: tt's obvious that . /opt/homebrew/.../bash_completion command is not executed, so go backwards from there and find the condition that is not true in your shell:
shopt -q progcomp || echo "progcomp False"
[ -r<EMAIL_ADDRESS>] || echo "file not readable"
[ "x${BASH_VERSION-}" != x ] || echo "BASH_VERSION empty"
[ "x${PS1-}" != x ] || echo  "PS1 unset"
[ "x${BASH_COMPLETION_VERSINFO-}" = x ] || echo "BASH_COMPLETION_VERSINFO is not unset"

I was able to reproduce this in WSL2: in Ubuntu (WSL2) there is the following piece of beauty in the default ~/.bashrc file:
  if ! shopt -oq posix; then
    if [ -f /usr/share/bash-completion/bash_completion ]; then
      . /usr/share/bash-completion/bash_completion
    elif [ -f /etc/bash_completion ]; then
      . /etc/bash_completion
    fi
  fi

which provide a slightly older version of bash-completion@2. As a result, it sets BASH_COMPLETION_VERSINFO variable and, as a result of that, sourced Bash completions are ignored.
I suppose that something similar is happening in your case, @nrlquaker.

@maxim-belkin I'm running latest macos Ventura 13.2.1. The issue starts when I've updated to the latest version from the previous (don't remember the exact version).
I don't have time to debug the bash script.
But from your script:
shopt -q progcomp || echo "progcomp False"
[ -r ${HOMEBREW_PREFIX:-$(brew<EMAIL_ADDRESS>] || echo "file not readable"
[ "x${BASH_VERSION-}" != x ] || echo "BASH_VERSION empty"
[ "x${PS1-}" != x ] || echo  "PS1 unset"
[ "x${BASH_COMPLETION_VERSINFO-}" = x ] || echo "BASH_COMPLETION_VERSINFO is not unset"

I'm getting PS1 unset

I'm getting PS1 unset

Setting PS1 to something sensible should do the trick then.

@maxim-belkin I got a script that changes PS1. But its below mentioned code.
And it will be nice if it will be mentioned in the doc.

@gromgit Its empty.
env | grep BASH_COMPLETION

Sorry, what's the output of set | grep BASH_COMPLETION?

I don't see any mentioning about bash_completion.d in bash_completion.sh from bash-completion@2:

That's because the snippet I grep'd earlier is from the file that's searched and sourced by bash_completion.sh:

        if shopt -q progcomp && [ -r<EMAIL_ADDRESS>]; then
            # Source completion code.
<EMAIL_ADDRESS>        fi


improve nether network roads

dig down to Y=119 and pave with slabs

we should decide on colors for the tunnels


Problem: taplo-lsp outdated, conflicts with taplo v.0.6

Problem description
I use "neoformat" for formating and use "taplo-cli" with toml-files for this purpose. Everything worked fine, so far.
Now, since the taplo version change from v0.5 to v0.6 there is a curious and serious bug occuring which seems to be related to the  very outdated taplo-lsp which is used by nvim-lsp-installer.
As soon as I use taplo v0.6 the toml-files get whiped out / cleared if neoformat hooks in (with me it's automatically hooked at save).
This does neither seem to be related to taplo-cli nor neoformat as the cli works correctly if invoked via the terminal and the invocation syntax didn't change either.
Neovim version (>= 0.6)
NVIM v0.7.0-dev
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3
Compilation: /usr/bin/cc -g -O2 -ffile-prefix-map=/build/neovim-3JyIhf/neovim-0.7.0~ubuntu1+git202203291505-ba257d74b-dd05b3569=. -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DNVIM_TS_HAS_SET_MATCH_LIMIT -DNVIM_TS_HAS_SET_ALLOCATOR -O2 -g -Og -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wdouble-promotion -Wmissing-noreturn -Wmissing-format-attribute -Wmissing-prototypes -Wimplicit-fallthrough -Wsuggest-attribute=pure -Wsuggest-attribute=const -Wsuggest-attribute=malloc -Wsuggest-attribute=cold -Wvla -fstack-protector-strong -fno-common -fdiagnostics-color=auto -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -DMIN_LOG_LEVEL=3 -I/build/neovim-3JyIhf/neovim-0.7.0~ubuntu1+git202203291505-ba257d74b-dd05b3569/build/config -I/build/neovim-3JyIhf/neovim-0.7.0~ubuntu1+git202203291505-ba257d74b-dd05b3569/src -I/build/neovim-3JyIhf/neovim-0.7.0~ubuntu1+git202203291505-ba257d74b-dd05b3569/.deps/usr/include -I/usr/include -I/build/neovim-3JyIhf/neovim-0.7.0~ubuntu1+git202203291505-ba257d74b-dd05b3569/build/src/nvim/auto -I/build/neovim-3JyIhf/neovim-0.7.0~ubuntu1+git202203291505-ba257d74b-dd05b3569/build/include
Compiled by buildd@lcy02-amd64-114
Features: +acl +iconv +tui
See ":help feature-compile"
system vimrc file: "$VIM/sysinit.vim"
fall-back for $VIM: "/usr/share/nvim"
Run :checkhealth for more info
Operating system/version
Linux xxx 5.13.0-37-generic #42-Ubuntu SMP Tue Mar 15 14:34:06 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
I've recently downloaded the latest plugin version of both nvim-lsp-installer and nvim-lspconfig

[X] Yes

Affected language servers
taplo-lsp
Steps to reproduce

Install neoformat plugin
Get the latest taplo-cli (v0.6): cargo install taplo-cli
Open any Cargo.toml
Fire :Neoformat

Actual behavior
The Cargo.toml gets whiped out / cleared.
Expected behavior
Cargo.toml should be reformatted or stay untouched.
LspInfo
omnisharp, lemminx, jdtls, diagnosticls, graphql, yamlls, tsserver, clangd, dockerls, sumneko_lua, gopls, hls, sqlls, taplo, ansiblels, asm_lsp, texlab, jsonls, groovyls, clojure_lsp, html, eslint, remark_ls, julials, cssls, bashls, vimls, pyright, angularls, cmake

Healthcheck
nvim-lsp-installer: require("nvim-lsp-installer.health").check()
========================================================================
## nvim-lsp-installer report
  - OK: neovim version >= 0.6.0
  - WARNING: **Composer**: not available
  - WARNING: **PHP**: not available
  - OK: **sh**: `Ok`
  - OK: **bash**: `GNU bash, version 5.1.8(1)-release (x86_64-pc-linux-gnu)`
  - OK: **tar**: `tar (GNU tar) 1.34`
  - OK: **gzip**: `gzip 1.10`
  - OK: **curl**: `curl 7.80.0 (x86_64-conda-linux-gnu) libcurl/7.80.0 OpenSSL/1.1.1n zlib/1.2.11 libssh2/1.9.0 nghttp2/1.46.0`
  - OK: **wget**: `GNU Wget 1.21 built on linux-gnu.`
  - OK: **python3**: `Python 3.8.13`
  - OK: **node**: `v16.11.1`
  - OK: **Ruby**: `ruby 2.7.4p191 (2021-07-07 revision a21a3b7d23) [x86_64-linux-gnu]`
  - OK: **Go**: `go version go1.17 linux/amd64`
  - OK: **julia**: `julia version 1.5.3`
  - OK: **java**: `Ok`
  - OK: **RubyGem**: `3.2.5`
  - OK: **npm**: `8.0.0`
  - OK: **javac**: `javac 18-ea`
  - OK: **pip3**: `pip 22.0.3 from /home/her/bin/.share/anaconda3/lib/python3.8/site-packages/pip (python 3.8)`

Screenshots or recordings
No response

It does seem like taplo has started embedding the LSP service inside its main CLI tool though, will look into that.

It does seem like taplo has started embedding the LSP service inside its main CLI tool though, will look into that.

FYI and if you're using this:
The formatting bug has been fixed. cargo install --force --git https://github.com/tamasfe/taplo taplo-cli


Delete User Data not Deleting user data

Firestore structure
test_users  ->  uid1, uid2 ...
users ->  uid3, uid4 ...
Cloud Firestore Paths: users/{UID}, test_users/{UID}
Logs:
Deleted: ' test_users/uid1' from Cloud Firestore
Deleted: ' users/uid1' from Cloud Firestore
What happen: Documents were not deleted

Thanks for the report.
Have you re-configured the extension and redeployed at all? Or is this happening straight after a fresh install?

I have just noticed you have spaces in your paths. Spaces are valid in collection paths, so you're technically pointing to a valid path.
When setting up your paths, ensure it is: users/{UID},test_users/{UID}. I'll bring this up with the team though, as it's confusing!

I have just noticed you have spaces in your paths. Spaces are valid in collection paths, so you're technically pointing to a valid path.
When setting up your paths, ensure it is: users/{UID},test_users/{UID}. I'll bring this up with the team though, as it's confusing!

Oh, ok thank you!
A message warning users to pay attention to spaces between commas would be very useful.

I agree - the safest option would be to create an additional extensions field which allows "list" type arguments to be added one by one, without commas. cc @karayu


No upload on save if not already connected

Since a few builds, saving a file won't connect automagically to the remote host and save the edited file, you need to manually connect first.
"Before", whenever I would open an existing project (with existing .ftpconfig), working on any file and saving it would connect to the remote host and save the file.
Tested on v0.10.7

Confirmed on same version. No visible errors in Console.
If I Connect, it's working as expected.

Same issue here

Issue? This IS the correct behaviour! How would you save to a local file without accidentally moving it to your FTP-Server too?

@icetee, we can all do without your arrogant and condescending response, particularly since you seem to be clueless about this issue and YES it IS an issue.
No idea what you're talking about, with respect to "accidentally" moving it to your FTP server. If a site is configured to automatically upload saved files, there would be nothing "accidental" about it. The point is, if you lose your FTP connection, it should automatically reconnect. Not sure why this is such a bizarre concept to you???

@bkonia I don't believe he was being arrogant, maybe a miss understanding of the bug? Either way the guy has voluntarily taken the reasonability to maintain this package that has needed some serious attention for quite a while. Cut him some slack, he has gone through dozens of old threads trying to clean things up.

@bkonia what did I write?
I remove duplicate issues. When very first connected not lucky upload file. (May bad path, etc.)
It is planned to "auto-reconnect" function, if lose connection, timeout etc.

@bkonia, actually the comment you are referring to was from anither user about a month ago, @xN118x. All @icetee did was close this issue because it was a duplicate of another.


Do not label DKIM signatures

By default, the exporter keeps a list of the number of DKIM signatures
by domain. It slows down significantly the exporter after several weeks
of running.
To avoid that, we keep a global counter.

@julienlegros Looking good on mailsaas1a/b. The query duration has been stable for a week.


Background setting lost when drawing a saved conversation onto a new conversation

If you save a conversation, a background image will be saved as well and shown in the journal item as Conversation Background.
If you start a new conversation and drag the former saved conversation onto the dialog, the participants are added but not the background.
The following example shows saved conversation (right) and the new conversation after the saved conversation was drawn onto it from the sidebar (journal).

Is this a bug or a missing feature? :-)

So this is neither a bug nor a missing feature, this is the intended behavior. So, when dragging and dropping a conversation I decided to only transfer the actors themselves.
This is because you might have a conversation with a specific background and you just want the participants from another sheet. If that sheet also has a background, I personally feel it would be annoying if the background itself would also be carried over.
When creating a new conversation, it could be convenient to set the background as well. But maybe once again you want to set a new background or no background at all and it would be inconvenient to set it when dragging and dropping. At the end of the day, copying and pasting the path to the background does not take too long, so I think the way the module works now is good enough so I am not going to change this behavior.
That said, if this is something that you need in your games, I can tell you what to do locally to implement this behavior (if it is possible, the code is getting a bit convoluted and at one point I do want to rewrite the entire module). Still, I would be glad to look into this if this is something that you desire.


Change 'flush' commnad key

I think the flush command should be changed.
https://github.com/AmineZouitine/rmt.rs/blame/d90c3e6ef16623b109142a13165e04a3cf6b5116/src/display_manager.rs#L141
display_input("del", "flush"),

Because keyboards below 70% and laptop keyboards do not have a Del key.

Good point, thank you! I will make the necessary modifications !

Ok now user can press 'f' key to do that too


RootViz Attribute editor doesn't respect read-only setting

WebGME properly doesn't allow the attribute to be edited, but provides a confusing interface for the user.

Edited data continues to show up for as long as the RootViz remains in memory.