ius-dev

Can the maintainer confirm that ius-dev was removed on purpose?  Some configuration management (salt in particular) enables/disables it and I'd like to know if this was intentional.

It wasn't being used for anything, so we removed it.  Even if we bring it back, it was for a very particular purpose (new packages), so why should that be included in a salt state?  The official way to use IUS is to use the ius-release package, so a salt state to add IUS should just ensure that package is installed (like our salt example).  If the state you are using broke because the dev repo went away then it must be managing the repo files directly.  If that is desired for some reason, then I would recommend only managing the stable repo.

Thanks george.  The salt official salt state just made sure the dev repo was disabled.  I'll commit a PR to get that removed.


Updating meta.yaml to make build and run requirements match (#128)

Resolve #128 by making build and run requirements match (though I've not exhaustively checked all of these requirements); also (more importantly) now require openmm rather than openmm-dev. Previously we required openmm-dev as for a while we required features in openmm 6.3 which was not released yet. Now that it is out, it's reasonable to go back to the stable version as a requirement.
Once this (or any updates/corrections) are merged we should release a new openmoltools version, as the water functionality incorporated by #142 is significant enough for a new point release (as is #147 and possibly others). This will also make it easier for people in my group using the conda install.

Do you need the new release cut immediately, or would this weekend work?

This weekend is totally fine. Is there something else you wanted to get
into it?
On Wed, Sep 30, 2015 at 2:37 PM, John Chodera<EMAIL_ADDRESS>wrote:

Do you need the new release cut immediately, or would this weekend work?
—
Reply to this email directly or view it on GitHub
https://github.com/choderalab/openmoltools/pull/153#issuecomment-144549696
.

--
David Mobley
<EMAIL_ADDRESS>949-385-2436

@jchodera - any reason for me not to go ahead with the release at this point?

Nope, let's move ahead!


improve datacite url mapping function

a couple of the dandisets failed doi generation because the identifier was simply doi.org/... with no http part or a : in the name. since identifiers can be pure strings, the function that handles parsing should take this into account.

an identifier in the model can be a string and also not mandatory, so the validator cannot catch this. in this case it is only the publishing element that needs to determine if that string can be converted to a known entity, and needs to use or fail gracefully.


[HELP] Does not work on Arch linux (Garuda)

I have tried for example creating a button but it seems to not work!
(I took code from documentation)
use gtk::prelude::*;
use gtk::{Application, ApplicationWindow, Button};
const APP_ID: &str = "org.gtk_rs.HelloWorld3";

fn main() {
    // Create a new application
    let app = Application::builder().application_id(APP_ID).build();

    // Connect to "activate" signal of `app`
    app.connect_activate(build_ui);

    // Run the application
    app.run();
}

fn build_ui(app: &Application) {
    // Create a button with label and margins
    let button = Button::builder()
        .label("Press me!")
        .margin_top(12)
        .margin_bottom(12)
        .margin_start(12)
        .margin_end(12)
        .build();

    // Connect to "clicked" signal of `button`
    button.connect_clicked(move |button| {
        // Set the label to "Hello World!" after the button has been clicked on
        button.set_label("Hello World!");
    });

    // Create a window
    let window = ApplicationWindow::builder()
        .application(app)
        .title("My GTK App")
        .child(&button)
        .build();

    // Present window
    window.present();
}

~ This code has to put a button on screen and when I press it it has to write Hello World! but nothing shows up!

~ I am not saying It doesn't work completely, but content does not show up!
~ I am using Garuda (Arch based) linux, KDE desktop environment. (I guess it is about my OS ?)
 Root privileges required.
 Is lm-sensors configured?
Info:
Processes: 347 Uptime: 2h 33m wakeups: 0 Memory: 15.53 GiB
used: 5.41 GiB (34.8%) Init: systemd v: 251 default: graphical
tool: systemctl Compilers: gcc: 12.1.0 alt: 11 clang: N/A Packages: 2026
apt: 0 pacman: 1999 lib: 545 snap: 27 Shell: Zsh v: 5.9 running-in: konsole
inxi: 3.3.19

If you run gtk4-demo, does that show a useful UI?

I am not using it as native, (It is not on my $PATH)
I am using it via cargo so I have to know where the file is.
I couldn't find a file describes gtk4-demo, there is just examples.

But I found this when I ran cargo test inside of the gtk4/ directory:
╭─kobruh@kobruh in repo: gtk4-rs/gtk4 on  master [!] is  v0.6.0 via  v1.63.0 as 🧙 took 1ms
╰─λ cargo test
Skipping git submodule `https://github.com/gtk-rs/gir` due to update strategy in .gitmodules
Skipping git submodule `https://github.com/gtk-rs/gir-files` due to update strategy in .gitmodules
Compiling proc-macro2 v1.0.47
Compiling syn v1.0.105
Compiling gir-format-check v0.1.3
Compiling pango-sys v0.17.0 (https://github.com/gtk-rs/gtk-rs-core#346d5c25)
Compiling gdk4-sys v0.6.0 (/home/kobruh/Projects/gtk4-rs/gdk4/sys)
Compiling gsk4-sys v0.6.0 (/home/kobruh/Projects/gtk4-rs/gsk4/sys)
Compiling gtk4-sys v0.6.0 (/home/kobruh/Projects/gtk4-rs/gtk4/sys)
Compiling gdk-pixbuf-sys v0.17.0 (https://github.com/gtk-rs/gtk-rs-core#346d5c25)
Compiling quote v1.0.21
Compiling proc-macro-error-attr v1.0.4
Compiling proc-macro-error v1.0.4
Compiling thiserror-impl v1.0.37
Compiling futures-macro v0.3.25
Compiling futures-util v0.3.25
Compiling thiserror v1.0.37
Compiling proc-macro-crate v1.2.1
Compiling pest v2.5.1
Compiling glib-macros v0.17.0 (https://github.com/gtk-rs/gtk-rs-core#346d5c25)
Compiling gtk4-macros v0.6.0 (/home/kobruh/Projects/gtk4-rs/gtk4-macros)
Compiling semver-parser v0.10.2
Compiling semver v0.11.0
Compiling rustc_version v0.3.3
Compiling futures-executor v0.3.25
Compiling field-offset v0.3.4
Compiling glib v0.17.0 (https://github.com/gtk-rs/gtk-rs-core#346d5c25)
Compiling gio v0.17.0 (https://github.com/gtk-rs/gtk-rs-core#346d5c25)
Compiling cairo-rs v0.17.0 (https://github.com/gtk-rs/gtk-rs-core#346d5c25)
Compiling graphene-rs v0.17.0 (https://github.com/gtk-rs/gtk-rs-core#346d5c25)
Compiling pango v0.17.0 (https://github.com/gtk-rs/gtk-rs-core#346d5c25)
Compiling gdk-pixbuf v0.17.0 (https://github.com/gtk-rs/gtk-rs-core#346d5c25)
Compiling gdk4 v0.6.0 (/home/kobruh/Projects/gtk4-rs/gdk4)
Compiling gsk4 v0.6.0 (/home/kobruh/Projects/gtk4-rs/gsk4)
Compiling gtk4 v0.6.0 (/home/kobruh/Projects/gtk4-rs/gtk4)
error: linking with `cc` failed: exit status: 1
|
= note: "cc" "-m64" "/tmp/rustcbbGpLw/symbols.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.10woskudb8b9v07q.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.115tivxpoapgozjy.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.12mvs9d27o8u0i9v.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.12tgxnnfyhv6pmp4.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.137c4sg04xyt0nid.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.14qsjk870rqa3nb3.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.14vp95m8ctkgd2o6.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.14y4i1ecqt7v7tyg.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.151gyd6567utqemq.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.16hfwwm9ab37ofid.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.1760lrydms0vokb4.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.17m8bzgjn0tjtijo.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.17trf1pij8bplusu.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.18pi8x3hksj7x0q2.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.18zdewyr5yeiwlhm.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.18zgoq1sq1mnraqj.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.197rd8xzfpwg0yb6.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.19qzirzj7cx8p91c.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.19xozoo654hbo6ay.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.1aerotx6odwaptvu.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.1bjfzc8f6gxloyap.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.1bn15wwf0s399wyd.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.1bvtjgsadc89rq76.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.1c38t3ipepxa4nko.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.1coluh46dvp03dmq.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.1dozgvd44c6o7ua.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.1eba09kkp6bw51x5.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.1egfiwl73p58z5g2.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.1h04ajo6ae0y9ueq.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.1j9obj70ml05z3z3.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.1k073671sx2k6yzf.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.1lm1uul0io1o3el7.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.1m57svvkiihwnacv.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.1mj4htq6u0xqacjx.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.1nr75txdl2ew98tb.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.1nug1yc61hh2d172.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.1oupsr3p1v1zj7pa.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.1pxwt8hota7xz3q6.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.1pyd9q06s20nzslf.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.1pzolg9q342g4dvz.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.1qcq5hfyyy5rejxv.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.1qjlnpkciuyr6lmh.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.1qm8a0cv695l4cl.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.1rdh6oqg8ud3b61b.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.1rlx8y3fegzpi5dv.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.1rqueeb7eoc0h5vs.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.1s9ujkqeff6tfb64.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.1sh7tc8voeqiv1az.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.1tezwj6ii0fa2dka.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.1trfe5tuzzyg65ob.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.1ux1r1ll3h0xx5gz.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.1v83j0gvszaqkg1j.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.1xqhjhz1fct85yfa.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.1y58gsdyjflvjusk.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.1yelz7b9vy3z6ew0.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.1ysloo9zes6t3x8g.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.1z4fjoy2hk2un84h.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.1z8re1f32manzesn.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.201x69ulfx9au6oo.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.224mt46tm6t3vyjh.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.224pq5bnzga6ptu3.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.22fjqkfw16flwqpj.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.22frts5a11pow3gn.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.22iuw5jj9x76kr00.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.23e96va5hqszt1ky.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.25bhiy4hmq209gv4.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.25f71rfev948vef.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.25xxatn9agr4dmhr.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.26hyjmj7cu9gsbjp.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.286nbxk4uftbsnbr.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.2a0jv6wbq6v44pct.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.2av6sgneb36umqt2.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.2blbofu397bm7ils.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.2c3a1v4551ud9p9h.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.2cbm8o4y10484j0u.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.2cu7zp5kttq68hcc.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.2dvpaapuzz5lysat.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.2e3cb1uosl1cl09l.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.2fif94f0xhm5vhci.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.2ghhx6ogk0eedyzp.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.2gqriuktd0ojg77q.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.2igicq6tp27324rt.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.2j7knx3vm2ul9m9c.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.2kiyydwt56zsn7fq.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.2kpdo70piszxuumv.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.2lqyxq9fuub11fv3.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.2ofzj8ffhpt0lnkr.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.2onr00swne7eyrps.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.2oys0v52uqe29brr.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.2pn27knr1jqx6jgj.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.2qds67t6wvgrxx8p.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.2qn4raqpqqpeiolf.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.2r4heoza00vxgzr6.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.2sqblkg63c40a5yn.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.2ty796w517uai9kf.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.2u17zqw7gzm9uynb.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.2uk2s2vt8me2g3i7.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.2voclk2z8dkcejpx.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.2wx8cn478onbv774.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.2yhb0omcqx3bsibc.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.2yhkx5khix1wrh7i.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.2zjz0s37kzjhfgxl.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.2zm205bjavnq742r.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.2zn0d2ct6wf3ka9v.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.2zp9vt64xt297chb.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.30hxxfy5z5xhqhxq.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.318rt69ckohbwegq.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.31ohahdrx9i29fa9.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.326xyxuku6pxs3p7.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.32ic11r2kgcp0hde.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.331slx2xj7bsncnq.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.33eyp16pl18saewc.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.33wcm15et5dmx9wy.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.34bcs289y2dlvtni.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.350tto9a48iai5k6.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.359x4hwrxwobo9ei.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.35hewy2x6u6q7hkg.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.365vazmgq87x5omf.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.36juwypatkcbc64u.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.36vv1rblyikfyk9m.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.38bn9j0wjtgae30w.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.38oz651u2bsgheyx.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.39005k0r0up5tze0.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.395l3b16nkhmnmdn.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.39cahhbftkc2c87g.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.39gopb240ikxrpt4.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.39rxm42y3feepngc.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.3b5z9ihylqv85hpn.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.3c3mgzw9clg0097e.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.3dg4l9rwmwv16o2e.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.3ekdy3ufentt0c1q.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.3f56v4bfv4k31irn.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.3fwi6duu0m6kko8g.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.3g64fh40u981hnps.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.3gaw34off8nxt17f.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.3gwz9vjx9tcqe33g.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.3h4gm7yuuuoqowhu.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.3hs732go1n0ew632.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.3jt2a5xnsnv1nf3w.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.3jueyrexwuoebd36.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.3k1czu4d0s5e3kjz.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.3kqfv0phhe57sy4p.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.3ojhohikiam1v1d2.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.3pwnizi3xaa760u4.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.3qoc1ivy72bmmm2z.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.3ry03fqquz1xtx9y.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.3s3d64wa12504ov1.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.3svvkryorkyhrexx.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.3sx4svmpadc47ye7.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.3uhp6aeh18pppbf8.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.3upk722xo8xcg9u4.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.3x22ye4mj13gviyk.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.3z03ac58ikszzfa8.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.403iocac38t1aq63.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.40e245jpp7edeizr.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.414k0hoi7doazrnb.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.41d5dx446b75wsvy.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.41udsg6af2gn7a69.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.43kvz07kwg07po11.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.43vg1m115ydz2jr8.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.44c12avvuyj4i64v.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.457o6zhyu5e10kl0.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.47lqoo295nbnox9u.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.497jp4ytqld390id.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.4adtj1x0q1sl6oi3.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.4afr3berkuvi8t4h.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.4aifagq9c51gcjh1.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.4azb8tzp5uhqals6.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.4ch1fq27vv66vfu2.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.4ddrhk66lcgwzjzz.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.4dfzoq4onsc97uf3.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.4e3qbzdy2mfka0d6.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.4ecay0t8m0is9xdm.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.4fd4o85l4s84rkae.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.4gfctnzw4j4vfil3.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.4hg870d15gvn91hc.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.4ip76tdkseisngbt.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.4k6vih19u42bym7t.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.4l285c7rjdokl89o.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.4lbqxvqxvd1vhhtg.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.4luyrdezdrf29vhi.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.4m3m2u1kpjk1u2kd.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.4nemg2wjtarqavqm.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.4nygyfnmt4ui2pa5.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.4qd3q9qn2b6fdzql.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.4qt7qm00vi7uopv.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.4rby3qoplab9m2zk.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.4rlflgwbli2ehoep.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.4rsljx4j1j7bcscs.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.4sw9xgupihp6etcm.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.4vis05ydsasranq1.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.4wivdo5n998g0wo9.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.4ycyur84xie3rjr2.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.4z6t9vd871hmg6s9.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.4zfguxpynr9i2l5o.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.51pepla3bffjh7au.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.52fkjom53m98awrz.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.52m7tgxdq98zt2rm.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.52rjipu2lu8272v2.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.54ekgrden99alb09.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.54p9tovvzffc58n5.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.55bnuvtvsu73xll.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.58244d5659916hj9.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.58lwr8m17ffsb1ed.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.58ujr8v86gmpunqu.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.59ajhnhi0s135tfw.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.59ov1jptcceq9ei8.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.5aamlgvinfac1rn4.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.5ah2z48j1qplvded.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.5cynqc7d8xq94cs1.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.5efygl7b56x91lst.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.5eu7p4uefs96q7nz.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.5g5po238ogbgdnlp.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.753phmvd39bo46p.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.7ln45w25ew3t8l6.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.7mwptstvuqra5t3.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.85ud6lpj0yuc7si.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.8wktpa2hf6tlp73.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.9h3f2ucwj512db5.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.atpedkbcla70niy.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.boefjtrvrcueixa.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.ewij4n0vp5zr8m4.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.f1ots015iov70an.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.fuwgxk6z1jyloes.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.fyvlviw363zyskb.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.hleew5aao5xen3v.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.isid1jxhlx8phrr.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.ktofj4rmox353a6.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.lkdgp7qogpvnn92.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.m98vd5eervyvgz8.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.mjev02uf0m2s5h7.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.mt54x56d3eodm0b.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.mvken2d21a8bmge.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.ng33dd7laxhcskr.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.p6md9lmbhn03x0r.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.pjyu47ync012eo7.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.qiangcgdwyog03e.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.rp739p8dd4fzs67.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.rqn1j5n76t0sma.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.ui7hx86ka90tfex.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.uy9ipeo322cnk2.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.v7167lhw0o3epm2.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.vpx46q04g6nof1q.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.vsmsdlrnosbsq2n.rcgu.o""/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.x3e3a3p73kri7p1.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.xno4an79zwlx30i.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.y4pj78lz9znq3mj.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.y4pkkc2foug67vx.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.y6hi933zjesthcw.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.y7kp6k1mhwefq39.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.ys1isgidvi6uno4.rcgu.o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10.4rzwpgav6v8pw09.rcgu.o" "-Wl,--as-needed" "-L" "/home/kobruh/Projects/gtk4-rs/target/debug/deps" "-L" "/home/kobruh/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib""-Wl,-Bstatic" "/home/kobruh/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libtest-50b9616eedb811b7.rlib" "/home/kobruh/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libgetopts-754da76e30d40e26.rlib" "/home/kobruh/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunicode_width-abff7c50c58df25c.rlib" "/home/kobruh/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_std-89f1a8c8e39f4a91.rlib" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/libgsk4-c774d59d92dbf69a.rlib" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/libgraphene-089e7b601575aab6.rlib" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/libgdk4-b1f2117083db7e95.rlib" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/libpango-7c353cc7bd8ae1ef.rlib" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/libgdk_pixbuf-74aa994a340f15a4.rlib" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/libgio-5d8daba07050797d.rlib" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/libfutures_io-8e9072fcc05ccbb4.rlib" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/libcairo-f7e7df4bf17a49c2.rlib" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/libglib-18c88f690d1c4863.rlib" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/libfutures_executor-1f522b9779da44db.rlib" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/libsmallvec-6443878768b3d5c6.rlib" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/libthiserror-728f2d1ea34a1096.rlib" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/libfutures_util-0c4e08ca134da453.rlib" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/libslab-2cd14b541a1c00c4.rlib" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/libpin_project_lite-45a26f3e47ef8489.rlib" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/libpin_utils-09bf07ea1b25970a.rlib" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/libfutures_channel-6730fce99046b047.rlib" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/libfutures_task-94f22da9017bad0a.rlib" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/libfutures_core-24f77729657321d7.rlib" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/libonce_cell-3fc9ecbffbfda6fb.rlib" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/libbitflags-9280358d7a21f5fd.rlib" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/libgtk4_sys-6108bce31245a7d2.rlib""/home/kobruh/Projects/gtk4-rs/target/debug/deps/libgsk4_sys-7b04f2caca33fde2.rlib" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/libgraphene_sys-c17835d052e24188.rlib" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/libgdk4_sys-45a357b8dca49a91.rlib" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/libgdk_pixbuf_sys-f0735e7dede4d1b8.rlib" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/libpango_sys-9d1f973e57dae5df.rlib" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/libcairo_sys-fe5b1349b49791b0.rlib" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/libgio_sys-bfccd7ce6eb439c4.rlib" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/libgobject_sys-8b9d0121d0d29815.rlib" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/libglib_sys-7e5e331e0b42771e.rlib" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/liblibc-3bd7a6e91c74eaf1.rlib" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/libfield_offset-040883b378f070f4.rlib" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/libmemoffset-61e0dfb22b2c016d.rlib" "-Wl,--start-group" "/home/kobruh/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-8f1929c73c3f8167.rlib" "/home/kobruh/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-e359d865975ccf21.rlib" "/home/kobruh/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libobject-b886fd10c5a7c7c0.rlib" "/home/kobruh/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libmemchr-9d7c322d48daa475.rlib" "/home/kobruh/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libaddr2line-08ae1606a951cabe.rlib" "/home/kobruh/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libgimli-682a81c4b2133b72.rlib" "/home/kobruh/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_demangle-a73b3512c88de071.rlib" "/home/kobruh/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd_detect-7b5ec4c918d9f957.rlib" "/home/kobruh/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libhashbrown-65c63cf3af0af657.rlib" "/home/kobruh/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libminiz_oxide-4a53f0a2785abc6a.rlib" "/home/kobruh/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libadler-868e2d515c28d027.rlib" "/home/kobruh/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_alloc-394ad2d73aede76a.rlib" "/home/kobruh/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-19c77e4dc3dcb87e.rlib" "/home/kobruh/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcfg_if-fb44a42088c9369a.rlib" "/home/kobruh/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-61a7402e61a5b0e0.rlib" "/home/kobruh/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-63f8356c87a0d0e8.rlib" "/home/kobruh/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_core-a506e577d917828c.rlib" "/home/kobruh/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-fc1fb63210fdafad.rlib" "-Wl,--end-group" "/home/kobruh/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-c21be34a5cae8449.rlib" "-Wl,-Bdynamic" "-lgobject-2.0" "-lgtk-4" "-lpangocairo-1.0" "-lpango-1.0" "-lharfbuzz" "-lgdk_pixbuf-2.0" "-lcairo-gobject" "-lcairo" "-lgraphene-1.0" "-lgio-2.0" "-lgobject-2.0" "-lglib-2.0" "-lgtk-4" "-lpangocairo-1.0" "-lpango-1.0" "-lharfbuzz" "-lgdk_pixbuf-2.0" "-lcairo-gobject" "-lcairo" "-lgraphene-1.0" "-lgio-2.0" "-lgobject-2.0" "-lglib-2.0" "-lgraphene-1.0" "-lgobject-2.0" "-lglib-2.0" "-lgtk-4" "-lpangocairo-1.0" "-lpango-1.0" "-lharfbuzz" "-lgdk_pixbuf-2.0" "-lcairo-gobject" "-lcairo" "-lgraphene-1.0" "-lgio-2.0" "-lgobject-2.0" "-lglib-2.0" "-lgdk_pixbuf-2.0" "-lgobject-2.0" "-lglib-2.0" "-lpango-1.0" "-lgobject-2.0" "-lglib-2.0" "-lharfbuzz" "-lcairo-gobject" "-lcairo" "-lgobject-2.0" "-lglib-2.0" "-lgio-2.0" "-lgobject-2.0" "-lglib-2.0" "-lgobject-2.0" "-lglib-2.0" "-lgobject-2.0" "-lglib-2.0" "-lgcc_s" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl" "-lc" "-Wl,--eh-frame-hdr" "-Wl,-znoexecstack" "-L" "/home/kobruh/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-o" "/home/kobruh/Projects/gtk4-rs/target/debug/deps/gtk4-dd98e91870c4da10" "-Wl,--gc-sections" "-pie" "-Wl,-zrelro,-znow" "-nodefaultlibs"
= note: /usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../lib/libgtk-4.so: undefined reference to<EMAIL_ADDRESS>/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../lib/libgtk-4.so: undefined reference to<EMAIL_ADDRESS>/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../lib/libgtk-4.so: undefined reference to<EMAIL_ADDRESS>/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../lib/libgtk-4.so: undefined reference to<EMAIL_ADDRESS>/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../lib/libgtk-4.so: undefined reference to<EMAIL_ADDRESS>/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../lib/libgtk-4.so: undefined reference to<EMAIL_ADDRESS>/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../lib/libgtk-4.so: undefined reference to<EMAIL_ADDRESS>/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../lib/libgtk-4.so: undefined reference to<EMAIL_ADDRESS>/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../lib/libgtk-4.so: undefined reference to<EMAIL_ADDRESS>/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../lib/libgtk-4.so: undefined reference to<EMAIL_ADDRESS>/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../lib/libgtk-4.so: undefined reference to<EMAIL_ADDRESS>/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../lib/libgtk-4.so: undefined reference to<EMAIL_ADDRESS>/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../lib/libgtk-4.so: undefined reference to<EMAIL_ADDRESS>/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../lib/libgtk-4.so: undefined reference to<EMAIL_ADDRESS>collect2: error: ld returned 1 exit status

= help: some `extern` functions couldn't be found; some native libraries may need to be installed or have their path specified
= note: use the `-l` flag to specify native libraries to link
= note: use the `cargo:rustc-link-lib` directive to specify the native libraries to link with Cargo (see https://doc.rust-lang.org/cargo/reference/build-scripts.html#cargorustc-link-libkindname)

error: could not compile `gtk4` due to previous error
warning: build failed, waiting for other jobs to finish...

It seems to fail, and there is that gigantic cluster of paths

gtk4-demo is part of GTK itself. I don't know where/how/if Arch packages that. Please try running that and report back

It seems to work! @sdroege
but why it does not work in rust code?

That's the next step to find out, I first wanted to make sure GTK4 is not broken completely on your system before wasting time on other things.
Just to be sure, did you run gtk4-demo in the same shell as you tried to run the hello world Rust example?

yes

Buttons works either (But on the demo not on my code)

I wonder if it's about resizabilty of the window, Bcuz all examples has fixed sized windows but mine is resizable @sdroege

Nope! It wasn't it
I added
fn build_ui(/* ... */) {
     // Create a window
     // -> snip

      window.set_size_request(256,256);
     window.set_resizable(false);

     // Present window
     // ...
}

maybe It is about the upper window rim huh? @sdroege

Not sure what the problem is, it seems like something broken with your theming. Do the C and Rust examples from https://gtk.org work? :)

Rust's one didn't work I saw same as other ones that I sent!
C: Bro There are some errors and I dont want to ruin my whole day fixing them (about linting etc)
So Rust does not work

My assumption would be that the C version has exactly the same behaviour, but as you don't want to test that I can't help any further.

Like I said: It is about my os and desktop env:
(gtk4-demo:225066): Gtk-WARNING **: 15:17:10.590: Theme directory 64/devices of theme Gruvbox has no size field


Remove all mutations of data

Requirements
Currently, the following items are being mutated internally to the table:

Columns: Ids, Widths, Sort Direction
Rows: Sort, Expanded, Id
Selected
Sorts

This is causing a slew of issues (store freeze, de-referencing) and inconsistent results. Instead, we should maintain separate collections for the items we use internally and bubble the rest for the user to do. After lots of thought, I feel doing these things internally breaks the dumb component pattern and could be considered outside of the scope of a base datatable implementation.
This will make things a bit more tedious and things like sorting will not be able to happen internally but we can provide helpers for users to implement. Example of the proposed sorting solution:
import { SortHelper } from 'ngx-datatable';

@Component({
   template: `
    <ngx-datatable [results]="results" (sort)="onSort($event)"></ngx-datatable>
  `
})
MyComponent {
   onSort(data) {
     // on push CD
     this.results = SortHelper(data);

    // dirty checking
    this.results.splice(0, this.results.length);
    this.results.push(...SortHelper(data));
   }
}

Open to suggestions and thoughts on the topic.

Some of this is done in 10.0.0.
Closing for now since i addressed majority of issuesi n that.


Parse error URGENT HELP

Parse error: syntax error, unexpected '<' in /home/vol2_6/website.com/www/client.website.com/htdocs/clientarea/function/signup.php on line 28
Help pls

Did you change any code

Nope.

I think you has change the code, line 28 is ?>
or your hustal have some bug in that version

@ItsGamingTube can i help you ?


Remove prevent_default for mousedown events

This fixes the issue of VSCode tabs not focusing when egui is running inside VSCode.
I left a comment just in case someone wants to add it back for completeness.

I tested the demo app on the browser and it seems to work just fine.


External MongoDB

Hi,
I just curious is it possible to use external mongoDB?
For example: via changing mongodb url in api-umbrella.yml like that
url: "mongodb://db_user:db_pass@db_host:27017/"
Is it compatible with AWS DocumentDB?

resolved

resolved

What is your solution?


Python 2.7 logic causing Python 3.x toolbox to fail.

Hey Tom,
I got the following error message when attempting to create the Esri File GDB via ArcGIS Pro:

From what I've researched, Python 3 doesn't support "iteritems" for dictionaries.
https://github.com/NENA911/NG911GISDataModel/blob/67a6aac3f91184f6c1492f8c97ea8a43f9bfa9e9/esri_geodatabase/NENA_NG911_Scripts/create_ng911_fgdb.py#L241-L247
-David L.

Thanks. Thought I snuck around the differences in Python 2 and 3. Obviously not...

If there isn’t a workaround to this, perhaps we should roll back.  It’s not ideal but I’d prefer to have a solution that works going forward as opposed to resolving an inconvenience on software with a declared end of life.Sent from my iPhoneOn Jan 3, 2023, at 3:19 PM, Tom Neer @.***> wrote:
Thanks. Thought I snuck around the differences in Python 2 and 3. Obviously not...
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

Tom, I changed line 245 in my forked script from domain["values"].iteritems() to domain["values"].items() and so far it seems to be humming along nicely in Python 2.7 and Python 3 (at first glance). I'll deep dive it in the morning, but let me know if you see issues with that approach.
ArcMap:

Pro:

-David L.

My test in in 10.5.1 this am is working and I have an ordered list of domain values from which to choose.


{% parent %} in nested twig blocks

Description
Whenever you use the {% parent %} tag in administration related component overrides (Vue.js & Twig.js), it is causing duplicated content in nested twig blocks. In this way it's not possible to override certain/parent blocks containing other child blocks (from which the content should be inherited, not overridden).
Possible Solution
The {% parent %} tag should always return the inherited contents of the wrapping {% block %} in rendered templates.
Additional context
Eg: When overriding the "sw-product-list" component in "src/Administration/Resources/app/administration/src/module/sw-product/page/sw-product-list/sw-product-list.twig" in order to add additional properties to the "sw-entity-listing" component.
The "sw-entity-listing" tag from the "sw_product_lis_grid" block is repeated in the "sw_product_list_grid_columns" block.
{% block sw_product_list_grid %}
    <sw-entity-listing
        ref="swProductGrid"
        class="sw-product-list-grid"
        :items="products"
        :columns="productColumns"
        :repository="productRepository"
        detail-route="sw.product.detail"
        :show-selection="true"
        :is-loading="isLoading"
        identifier="sw-product-list"
        :allow-edit="acl.can('product.editor')"
        :allow-delete="acl.can('product.deleter')"
        :allow-inline-edit="acl.can('product.editor')"
        :sort-by="sortBy"
        :sort-direction="sortDirection"
        :natural-sorting="naturalSorting"
        :criteria-limit="limit"
        :disable-data-fetching="true"
        :allow-bulk-export="acl.can('product.viewer')"
        @column-sort="onColumnSort"
        @page-change="onPageChange"
        @inline-edit-save="onInlineEditSave"
        @selection-change="updateSelection"
        @update-records="updateTotal"
        @bulk-export="onBulkExport"
    >
        {% block sw_product_list_grid_columns %}
            {% parent %}
        {% endblock %}
    </sw-entity-listing>
{% endblock %}

Isn't the correct syntax {{ parent() }}?
I'm not familiar with twig.js but I assume it should be the same.

No, this syntax is introduced as an additional statement tag that can be used in order to prevent conflicts with the Vue.js template bindings.
https://github.com/shopware/platform/blob/01d2da25be8d437bae0e6617c6e11b102c9ece6d/src/Administration/Resources/app/administration/src/core/factory/template.factory.js#L53

Ah, it's a custom tag. TIL.
Thank you.

I noticed that nested components may also disappear.
I tried custumizing the sw-order-detail-base view, to alter to the sw-order-user-card component's props, however the sw_order_detail_base_overview_status_change block will not show using {% parent %}.
{% block sw_order_detail_base__user_card %}
<sw-order-user-card
    :key="isEditing"
    :current-order="order"
    :version-context="versionContext"
    :is-loading="isLoading"
    :is-editing="isEditing"
    @order-change="saveAndReload"
    @order-reset="recalculateAndReload"
    @error="$emit('error',$event)"
>

  {% block  sw_order_detail_base_overview_status_change %}
      {% parent %}
  {% endblock %}

</sw-order-user-card>
{% endblock %}

src/Administration/Resources/app/administration/src/module/sw-order/view/sw-order-detail-base

Thats not possible in twig https://twigfiddle.com/j0hiow

And there isn't a way to make it possible ?
We have a lot of cases like that, and it makes template extension unnecessarily hard and annoying, it was a lot better with smarty in Shopware 5. The Administration is changing a lot in the template factory, why not change that as well?

@creinelt We get stuck at this a lot as well. If the existing blocks are not structured enough, there seems to be no other way, than copying a lot of code, which is very bad practice in case of code updates from Shopware. However, as a best practice we now wrap our adjustments inside an if case. This way the adjusted and copied code is at least only used, when the "plugin case" is true and the default code can stay as is.
For example if you need to extend an if case like this:
{% block a_existing_block %}
  <template v-if="some.shopware.boolean">
    ...
  </template>

  Need another case here!

  <template v-else>
    ...
  </template>

  {% block another_existing_block %}
    ...

You can at least try:
{% block a_existing_block %}
  <template v-if="some.plugin.case">
    <template v-if="some.shopware.boolean">
      Copied code
      ...
    </template>

    Your plugin code...

    <template v-else>
      Copied code
      ...
    </template>

    {% block another_existing_block %}
      Copied code
      ...
  </template>

  <template v-else>
    {% parent %}
  </template>

Always open for and interested in better solutions. Hope it helps! :)


Solve #97 for upgrading gviewer to v1.0.0

Pushed one commit 76d690a which update the setup.py as well.

LGTM, I will push one more commit to fix the master build failed issue. After that, we may need to rebase this branch. Sorry for the inconvenience. 囧rz

Current master has fix the test fail.

Coverage decreased (-0.4%) to 63.315% when pulling b5b99b8668cc278948549d49daaad7d25d32632f on gviewer-upgrade-#97 into ec0ee91ac0f7c201e679acb928667eca2cb827cf on master.


Can't Arm Away

Issue
From the Home app, when I set the system to Arm Away it will say 'Arming...' but eventually it sets itself to Stay instead of Away.
When I arm the system for Away from the Alarm.com app the Home will reflect the system as Away.
Version
Plug-in version: homebridge-qolsys v0.3.0
Panel model: Qolsys IQPanel 2+
Logs
Will provide soon...

Hi,
Try disabling the Auto Stay option.
With that option enabled, After arming , panel will automatically reverts to Arm Stay if no delay door is opened.

Let me know if it helps !

This is the root cause of the issue. I was able to fix it in the panel settings. Thank you.


math_ops.div_no_nan support for float16

System information

OS Platform and Distribution: Ubuntu 18.04
TensorFlow installed from: binary
TensorFlow version: 1.14.1-dev20190306
Python version: 3.6
CUDA/cuDNN version: 1.01
GPU model and memory: M60

Describe the current behavior
math_ops.div_no_nan only allows float32 or float64, this limits the ability to use MirroredStrategy with float16

there is no problem I will add the feature in core of math_ops soon.

I got some issues in my pull request, sorry for that but you can do it on your own go to TensorFlow's/core/ops/math_ops.cc and search for DivNoNan and add required dtypes in its attributes

The issue seems to have been fixed in:
https://github.com/tensorflow/tensorflow/commit/11245e46584b2e610ee7ea8258978bfcef1f5c26

Excellent, thanks @shashvatshahi1998 and @yongtang!


fix reply-to header being set as string for mailgun adpt

relates to #420 where h:Reply-To is being set in the body as a string vs an atom. This blows up a little down stream when Atom.to_string is called and passed the string of "h:Reply-To"

I also added a a fix to circle ci since you are still using v1 I bumped it to using v2

The Circle 2.0 PR has been merged. Could you rebase this and push it up without your Circle changes?

Done.

ping...

Ping Pong

@paulcsmith I did a rebase the commit #9786cf7 removed the config.yml and added that .circleci/circle.yml from upstream.
Maybe I'm missing something?

@paulcsmith let me know if there was anything else you wanted to fix.


Support writing reports for expiry S3 batch tagging

Also Url :arrow_right: URL code fix.

Thanks, pulling!

We really do need system tests against S3 to really test stuff like this. I assume this is at least manually tested.

Yes.  Testing also revealed that no matter what I did (pass a trailing slash or not to the report base key) Igot an empty directory component in the report.  I'll fix it if I figure it out, but it looks as if this part of the S3 API may be subtly different.  Not blocking, just an annoyance.


System can not shut down with Plasma on Wayland

Describe the bug
My system cannot shutdown when running Plasma via a Wayland session. When shutting down or rebooting, it will instead infinitely wait for "A stop job is running for X11 Server" with no time limit. This does not occur when running plasma in an X11 session
Steps To Reproduce
Steps to reproduce the behavior:

Start a Plasma session via Wayland
sudo reboot or shut down via graphical menu
Infinite hang of display-manager.service on shutdown

Expected behavior
The system shut down correctly, no matter if I am running via Wayland or X11.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
I'm running on relatively new hardware with a Ryzen 9 7900X as the primary GPU and an RX 7900 XTX via DRI_PRIME offloading on the modesetting drivers. Relevant parts:
  boot = {
    kernelPackages = pkgs.linuxKernel.packages.linux_6_2;
    kernelParams = [
      "amdgpu.sg_display=0"
      "amd_iommu=on"
      "iommu=pt"
    ];
  };

  services = {
    xserver.videoDrivers = [ "modesetting" "fbdev" ];
    #xserver.videoDrivers = [ "amdgpu" ];
  };

  hardware = {
    enableRedistributableFirmware = true;
    opengl = {
      driSupport = true;
      driSupport32Bit = true;
      extraPackages = with pkgs; [
        amdvlk
        rocm-opencl-icd
        rocm-opencl-runtime
      ];
      extraPackages32 = with pkgs; [
        driversi686Linux.amdvlk
      ];
    };
  };

Notify maintainers
@abbradar @ttuegel
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.2.12, NixOS, 23.05 (Stoat), 23.05.20230423.e78d25d`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.13.3`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Does this happen if you instead start Plasma from a TTY (startplasma-wayland)?
If not, then it's probably https://bugs.kde.org/show_bug.cgi?id=445449.

It actually shuts down correctly when using startplasma-wayland, yes! Nice, the bug seems to be solved upstream so we are just waiting for it to reach the next release? :)

It should be solved by now, with SDDM 0.20.0.

As it seems it will not be backported to 23.05 I can not test this at the moment to confirm :grimacing:

Logout before shutdown works as a workaround for me
as mentioned in the linked issue #issuecomment-1523797685

Meanwhile I've migrated to nixos-unstable where it works without problems :)

Works now in 23.11 :)


On invocation, some output message flashes on screen before hints are shown

When I do -F to invoke hints, I see some log output flash on the screen before it goes back to my regular screen with hints enabled.
Here's a screenshot:

I also notice a new window gets opened in tmux, temporarily while hint-mode is active. Not sure if it has any relation.
I'm on zsh, by the way.

Hi! Is this still happening to you? In theory :tm: this message appears in the background, so you shouldn't see it.

@Morantron Yeah, it's still happening. I'm just living with it for now :)
Let me know if I can provide more information.


Developers - Core Package and functional Automation

What within the Core Package needs to have certain automation developed now that TDTM is removed and there isn't an EDA or NPSP functionality.

Triggered Emails
Contact Matching process
Others?

What of this is essential for MVP here? If we're looking to make a package, perhaps it might be wise to isolate what is 'core' functionality and then work out automation from there.

Contact Matching is in the core.  Email may not need to be.  closing ticket


Add additional parameters to Graph Cypher Chain

Based on the inspiration from the SQL chain, the following three parameters are added to Graph Cypher Chain.

top_k: Limited the number of results from the database to be used as context
return_direct: Return database results without transforming them to natural language
return_intermediate_steps: Return intermediate steps

Thanks for adding these additional parameters! Will be very useful!


Unknown Error Occurred when trying to enable integration

When trying to add this integration into HASS for the first time. Every time I enter my API credentials I receive the following error:

I've tested this both with the flair integration added via HACS and manually in my custom components. I've tried the last 5 published versions (v<IP_ADDRESS>, v<IP_ADDRESS>, v<IP_ADDRESS>, v<IP_ADDRESS>, and v<IP_ADDRESS>).
I'm currently on HASS 2021.12.8, installed in a docker container.
I've confirmed my API key works with curl requests. And I'm using the v1 API key from Flair.
Nothing is getting written to the logs from the failed attempt.
I've tested adding other integrations to confirm it wasn't some larger issue with adding integrations via the UI. Other integrations can be added without issue.

I honestly won't know until I try your credentials on the backend. If you could let me know an e-mail address you can be reached at, I'll shoot you a message to get your credentials to test.

@Melachiah I tested adding the integration with my own credentials on 2021.12.8 and had no issues. There have been issues in the past with Flair's servers that I've been able to uncover with user's credentials and reported the findings to Flair. I'm certain something similar is going on in your case, but won't be able to confirm without the credentials.

@Melachiah Are you trying to use the OAuth2 credentials?  If so, they won't work.
Notice here: https://github.com/RobertD502/hass-flair-helper/blob/main/flair/flair_helper.py#L48
The Flair API Helper that's in use hits the legacy OAuth endpoint for authentication. Your e-mail from Flair with your API credentials should have two different ID/secret pairs.
Have you tried both?

As mentioned, there's notably nothing in the logs concerning the failure. Even when enabling debug logging. Everything else logs as expected. Just not this particular integration.
I realize that isn't the most helpful. In the interim I've created REST template sensors and my own python script to issue commands to flair. Which works fine for now.

@Melachiah I have just pushed out <IP_ADDRESS> which has increased logging during the onboarding process. Try it out and let's see if we can get to the bottom of the issue.

I get this same error, also with oauth1 creds, just unknown error then it shows "failed to load" on the integration, you can delete it and restart and try again, same issue, also see nothing in the logs

ok, my log level was wrong, did it again...  this is how far it makes it, I'm not posting earlier logs like loading the custom integration, etc...
[custom_components.hacs] <Integration RobertD502/home-assistant-flair> Getting repository information
[custom_components.hacs] <Integration RobertD502/home-assistant-flair> Running checks against <IP_ADDRESS>
[homeassistant.setup] Setting up flair
[homeassistant.setup] Setup of domain flair took 0.0 seconds
[custom_components.flair] Initializing the Flair API
Then that's it, nothing else with the word flair, I looked manually through the logs and I didn't see an exception from core that looked like it was related, just stuff all about other integrations, etc...

if you get me your email I can send you creds to test, and then just have Flair create me new ones once we figure it out

you could also email me at davidkmcgowan   <.com>

@dkmcgowan was able to hunt down the problem on his end which seems to be related to self-hosted reverse proxies.
He was able to add the integration by accessing Home Assistant using his local url (URL) instead of the external URL.
From my own testing, this problem does not occur when adding the integration using a Nabu Casa external URL.
@Melachiah Can you please report back if you are using Nabu Casa and, if not, if you were trying to add the integration while accessing Home Assistant from your external URL. If this is the case, accessing HA through your local URL and then adding the Flair integration may resolve the problem you are having.


Duplicate content-type headers in outgoing response

Describe the bug
SCG version - 3.0.5
Java - 17
Configuration:

Route is configured with "retry filter" and number of retries as 2.

Test call flow:

Request sent to SCG
SCG forward request to server address in route
server responds with 404 error
SCG retry request to server
server responds with 201 response code

Actual Result:
In the above call flow, SCG is sending content type header as:
"content-type: application/json, application/json"
Expected result:
we are expecting single content type header in response sent by SCG as "content-type: application/json"

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.


Fix Api-subscriber's onCompleted call before realm data is loaded

We need to take 2 first items from realm: 1) from current realm state 2) from updated realm state (after data is loaded via retrofit). Only then subscriber should be closed (issue #7 ).

compile 'io.fabianterhorst:apiclient:0.4.4'


Proxy blocking Omni-channel chat - whitelist URLs required for proxy bypass?

Our organisation web proxy filter is blocking Omni-channel for Customer Service chat.
Are Microsoft able to provide the pre-requisite whitelist URLs for this service to allow chat to work through a web filtering proxy?

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

ID: 12c84269-3853-d570-7c74-d69184f8c981
Version Independent ID: 9ef1c7d7-a56b-0385-f661-92eb30f465e7
Content: Pre-requisites and system requirements of Omnichannel for Customer Service
Content Source: ce/omnichannel/system-requirements-omnichannel.md
Service: dynamics-365-customerservice
GitHub Login: @kabala123
Microsoft Alias: kabala

@stephenacrown : Thanks for reaching out to us. I've reached out to internal teams for the issue. I will keep you updated as soon as I get an update. Thanks for your understanding.


Extension possibilities of the IDS DAT validation

We happened to look over the current IDS DAPS DAT validations implemented. If we haven't missed anything, these validations currently primarily check the DAT claims Audience, NotBefore date, and Expiration date so far.
Looking at the current reference-implementations of the IDSA Dataspace Connector and the Messaging-Services, the validations can be extended for example by the following:
Basic additional Oauth2ValidationRule(s):

Is the expiration date in the claims prior in time to the issued-at date in the claims (general check)?
Is the current time before the Issued-At date in the claims (with respect to time zones)?

Additional IDS message specific additionalValidationRules:

Does the specification of the "referringConnector" in the DAT claims match the specification of the "issuerConnector" in the message headers?
Is a "securityProfile" present in the received message payload? If yes, does it match the "securityProfile" specification in the DAT claims?

In addition, in the current implementations, individual checks can be added at runtime, for example, to automatically reject received messages from a specific connector, given the specification of the referringConnector in the DAT. This would allow, for example, messages from other connectors to be automatically rejected for a given time, and the connectors to be rejected can be managed in a list at runtime, which can be changed at any time.
Some of them would be basic Oauth2ValidationRule(s) and some additionalValidationRules specific to the IDS context.
If the validations from above are already implemented and I just didn't see them or the above suggestions are not considered useful, please just ignore this issue.

I recommend to make the referringConnector / issuerConnector setting configurable, use-case experience shows that the referringConnector specification in the DAT does not always match the issuerConnector, although it should. Mostly the reason is the content of the DAT and configuration of the connector at the DAPS. We had no problem with the securityProfile so far, if it was included in the DAT as well as in the message.


Teams fx migration samples

Build Pipeline

@Harikrishnan-MSFT - Kindly run build pipeline before merging this PR. Also, resolve all the fixed comments.


[Figma] Add option to Expressive button

AEM currently uses Expressive button in their library to create nested components. When using our button with an icon, the button does not expand as expected (this was intentional to match the code). This is effecting their prototypes down the line.
We should add another variant option only available when the button has both text and an icon to accomplish this. Should also have prototyping and states set up.

Published updates to Expressive button:

The button label should be set to fill , so the text should fill up to the button
Added an option when using text + icon to have the text wrap. Text wrap is set to true by default (allowing the designer to resize the button manually), or can be set to false to have the button scale with the amount of text on a single line


[Orbital] The positions of the details is off

The positions of the tips of the values (the numbers showing the values of each ring in details mode) is off.
I've tried a lot of things, and my brain has fried on this.
If anyone wants to try, please do, and report back !

What you want probably will involve display.getTextBounds and some combination of acos and asin - turning pixel dimensions back into an angle.

Different project but I think this might be what you want
replace the radius of the first circle - with somthing based off display.getTextBounds
display.fillCircle(
100 + 86 * sin((360 * mods3 / 256.0) * DEG2RAD),
100 - 86 * cos((360 * mods3 / 256.0) * DEG2RAD),
12,
GxEPD_BLACK
);
display.fillTriangle(
100,
100,
100 + 86 * sin((360 * mods3 / 256.0 - 8) * DEG2RAD - (atan(12/86) / DEG2RAD)),
100 - 86 * cos((360 * mods3 / 256.0 - 8) * DEG2RAD - (atan(12/86) / DEG2RAD)),
100 + 86 * sin((360 * mods3 / 256.0 + 8) * DEG2RAD + (atan(12/86) / DEG2RAD)),
100 - 86 * cos((360 * mods3 / 256.0 + 8) * DEG2RAD + (atan(12/86) / DEG2RAD)),
GxEPD_BLACK

Apologies for the spam, try this again. This should be more adaptable. If not quite the order you want.
  int16_t  x_center, y_center;
  uint16_t w_center, h_center;

   uint16_t mods3;
  char mods_buffer3[64]; // if you need some sprintf formatting, otherwise use mods3 for everything

// replace the 12 with somthing based on  w_center or h_center
  display.fillTriangle(
    100,
    100,
    100 + 86 * sin((360 * mods3 / 256.0) * DEG2RAD + atan(12/86.0)),
    100 - 86 * cos((360 * mods3 / 256.0) * DEG2RAD + atan(12/86.0)),
    100 + 86 * sin((360 * mods3 / 256.0) * DEG2RAD - atan(12/86.0)),
    100 - 86 * cos((360 * mods3 / 256.0) * DEG2RAD - atan(12/86.0)),
    GxEPD_BLACK
    );
// rendered text dimensions, beware wrapping
  display.getTextBounds( mods_buffer3, 0, 0, &x_center, &y_center, &w_center, &h_center);
  // so  the atan calls should actually go here
  display.setCursor(
    99 + 86 * sin((360 * mods3 / 256.0) * DEG2RAD) - w_center / 2,
    110 - 86 * cos((360 * mods3 / 256.0) * DEG2RAD) - h_center / 2
    );
  display.println(mods_buffer3);

To be honest, I have no idea what you are talking about.
All I want is that the text is just after the end of the circle, centered, so that it doesn't get written over the circle or too far from it.
The issue I have is to find the right setCursor parameters.
All I use is in the drawDetails of the watchface :
void WatchyOrbital::drawDetails(float angle, unsigned int radius, String value){
    unsigned int center_x = 100;
    unsigned int center_y = 100;
    /*int16_t x1;
    int16_t y1;
    uint16_t width;
    uint16_t height;
    display.getTextBounds(value, 0, 0, &x1, &y1, &width, &height);*/

    // Calculate the end of the circle
    float x = center_x + radius * cos((angle - 90) * DEG2RAD);
    float y = center_y + radius * sin((angle - 90) * DEG2RAD);

    // Calculate a x and y delta to move the cursor based on the angle of the circle
    x = x + 3 + 7*(sin((angle + 90.0)*DEG2RAD) - 1);
    y = y + 2 + 9*(sin((180-angle)*DEG2RAD) - 0.5);

    display.setFont();
    display.setCursor(x, y);
    display.print(value);
}

I tried using the length and width of the text to calculate the delta necessary for the cursor, without success. I tried a lot of things. The code as it is now, is the best visual result I could achieve.
Another issue being that depending on the font, the cursor doesn't represent the same thing (when no font, it seems to be the top left corner, while when using a font, it's the left baseline coordinates).

I'm understanding some of your frustration.
https://github.com/Cqoicebordel/Watchfaces/compare/main...Sudrien:Watchfaces:main shows what I thought might work.

https://learn.adafruit.com/assets/29277 from https://learn.adafruit.com/adafruit-gfx-graphics-library/using-fonts confims your "cursor doesn't represent the same thing" thought. I don't know why they would have left it this way.
Adafruit-GFX is messing up display box calculations due to text wrapping, and as far as I can tell, this can not be turned off completely. display.setTextWrap(false); does something, but not enough.
One really has to treat the detail text as having a bounding circle, not box, to determine it's proper position. I do not think I'm ready for that yet.
inverting text is it's own issue - when it must overlap with an arc.

Whatever the solution is, it is going to have a lot of moving parts.

I'll test your code in the near futur (thank you for trying, even if it doesn't work !).
For the points you make :

Yeah, it's a shitty way to show text, if you don't know how it works, and even more if you do :D I had issues with the weather font because some of the details go below the baseline, and thus couldn't be positioned correctly (getTextBound return the bounding box, not the position of the baseline). In the end, it may have been better to use images, but I was angry enough to keep it in font form :)
Yeah, text wrapping is weird too.
Not sure about the bounding box being a circle : when the arc is at 90°, it's nice to have the text very close to it. The rectangular bounding box fits my tastes well. The issue is its relation to the end of the arc, and calculating the closest point to it, so it can get close, but not overlapping it. That's the part that gives me headaches, and so I (temporarly) gave up, given the code right now mostly work.
Finally for inverting, I decided (but not implemented it yet) that I would cheat : there is overlapping only on the last item of the circle, so the last item should be inverted. That's not pretty, but it'll fit most cases :)


Make separate goroutines for metrics collection method calls

Description
Currently, if there is delay in collection of metrics, then the time interval set for metrics collection is not honored.
Made the metrics collection method as separate goroutines which which shoot new method call in spite of delayed metrics collection response.
GitHub Issues
List the GitHub issues impacted by this PR:

GitHub Issue #

https://github.com/dell/csm/issues/1012

Checklist:

[ ] I have performed a self-review of my own code to ensure there are no formatting, vetting, linting, or security issues
[x] I have verified that new and existing unit tests pass locally with my changes
[x] I have not allowed coverage numbers to degenerate
[x] I have maintained at least 90% code coverage
[ ] I have inspected the Grafana dashboards to verify the data is displayed properly
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have maintained backward compatibility

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Please also list any relevant details for your test configuration
-Unit tests:

Added a time delay > time interval set for metrics collection. For example,  volumePollFrequencySeconds: 20
and time delay introduced in the respective method is 30s. Observation is calls to metric collection is made after every 20s.

This may not be the correct approach.

You now have new WaitGroups every time a timer event fires. I don't see where wg.Wait() sis being called. Do you really need the WaitGroup?
Also you will end up having lots of goroutines in the case of volume collection, if the volume collection takes longer than the interval.
Each goroutine will/could run in parallel and hence exceed the concurrency limit as the semaphore is implemented as a channel, and each metrics export method has its own private channel. You want a single semaphore for all goroutines so that all methods, if run in parallel will not exceed the concurrency limit. Take a look at how the concurrency is designed in the Export* methods to understand.

Please explain the intent of your implementation.
A better approach is to run each Export method in its own goroutine with the timer in their respective goroutine. Each goroutine uses the same semaphore for concurrent connections.

Closed the PR by mistake. Reopened it


Fix download of binary files

Bugtracker: https://www.concrete5.org/developers/bugs/5-7-5-3/zip-file-download/

Is it just removal of the closing PHP tag that fixes this?

We should give this another pass if we can and convert to using Symfony's binary file response.

Yes, IMHO the problem was in output buffering turned off and in an extra new line sent by PHP (the closing ?> followed by \n in our file) before the real content of the response.


replace master with main

As far as I know, the master to main change shouldn't affect any client, however it broke the C client. I always get Error: Could Not Rename: /tmp/tldr70oDX4/tldr-master to /home/user/.tldrc/tldr-master/ and /tmp/tldr70oDX4/ just doesn't exist.
However after changing everything to main it works again.

https://github.com/tldr-pages/tldr-c-client/pull/56#issuecomment-761781479

Ah, I see. But I think this should be done quickly since right now, the client is broken (at least for me). Also, I don't think it would be a big problem creating tldr-main, even if tldr-master exists. It is by far the easiest solution and it's merely an additional 36 MiB.

@marchersimon, I think maybe it should just be tldr instead of tldr-main, and we can do the cleanup/migration after?

Done

could we not mirror the branches

@owenvoke can we merge this?

This seems fine to me. However, I don't use the C client, so not entirely sure. 👍🏻

@sbrl @CleanMachine1 any thoughts?

Again, if we just mirror the branches we wont lose backwards support, so I'd recommend setting it up how we have our main repo

@CleanMachine1 I think you misunderstood this PR. It just changes from where the client downloads the files and how it names them. For me, the client is still broken and can't update without this change.

Then we should probably merge.


Update netty-handler to 4.1.109.Final

About this PR
📦 Updates io.netty:netty-handler from 4.1.92.Final to 4.1.109.Final
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "io.netty", artifactId = "netty-handler" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "io.netty", artifactId = "netty-handler" }
}]

labels: library-update, commit-count:1

Superseded by #1676.


Support [__ref] attribute to make this pass by reference.

Fixes #4110.
New feature

Added [__ref] attribute that can be placed on struct member functions that causes this parameter to be passed by reference.

If this is going to be an official way to workaround the limitations of the reference feature, it will need to be explained better on our document.

Because this new attribute is only for this, how about a name like __ref_this to be more explicit.
I agree with changing the syntax, it is quite confusing.


Update to stable-baselines3 v2.0+

Once released, update to stable-baselines3 version 2.0.0+ to properly support gymnasium. sb3 is used for tests and in the demo notebook; currently an early alpha version with gymnasium support.
Once updated, also make an MR to add mobile-env to the sb3 projects page: https://stable-baselines3.readthedocs.io/en/master/misc/projects.html

PR to update SB3 docs: https://github.com/DLR-RM/stable-baselines3/pull/1617

Added to the SB3 docs successfully: https://stable-baselines3.readthedocs.io/en/master/misc/projects.html


[FEATURE] Checkout: Different Shipping Address for Guests

Description
At the moment in our demo store only logged-in users can have different billing and shipping addresses.
Is there a reason for this or is that just missing for guests?
Use Case
It should also be possible to order with a different shipping address for guests.
Proposed Solution
No response
Alternatives Considered
No response
Additional Context
No response

solved via #271


Hotspots

Fixes #334
Well, 'fixes' might be going a little far, but this is a first step. All I have here is the ability to put blue spots in space, but they work and they become partially transparent when viewed from behind (which the UX studies seem to be favoring). Obviously we'll want to make these more CSS customizable and interactive. For animated models we'll also want a mesh-relative way to specify them, rather than global coordinates.
Check out examples/annotations.html to see how this works so far. Mostly I'd like feedback on the direction this is going and general API shape.

@cdata After playing with this awhile, I began to feel that it was more important for the hotspot styles to work cleanly like the rest of HTML and CSS, and that this trumped the concern of exposing their positions to the light DOM. This lead me to the design here, which has a pretty clean API at least (see the annotation example). I still need to add a mutation observer to handle changes. Feedback welcome, especially about what kinds of edge cases this might break.

TL;DR the current approach creates the potential for style contention between a content author and the component; we can avoid this and also be more coherent with built-in DOM/style behavior by using <slot>s.
The main problem with the current approach is that the DOM node is essentially transitioned from author control (it is part of the author-controlled "light" DOM) to component control (it is a detail of the components "shadow" DOM), but without any contract or guarantee for who will control the element moving forward. Shadow roots are opaque to authors who work in the host document. In handling a "light" DOM element directly in the component, we are piercing the shadow veil and creating a surface area for style contention.
Importantly, if the goal is to behave coherently with HTML/CSS, there should only be one canonical "owner" for a given node and its styles/attributes. Anything that the browser does to a DOM node that relates to layout (particularly) can and does allow author styles and configuration to layer on top, in an additive fashion or as a way for the user to override built-in behavior.
Consider the following contrived case:

<model-viewer id="modelViewer">

</model-viewer>

There a few things about this that will probably violate this user's expectations:

The transform style that they provided is not applied to the hotspot
The inline border-radius style is overwritten
New hierarchy is created in the "light" DOM ("where did that come from?") and the hotspot itself is moved, so the query cannot find it
The newly introduced element is not encapsulated from author-specific styles, so it accidentally fades with the loading indicator

Why are these things true? Because when <model-viewer> connected to the document, it did a number of things that DOM elements don't typically do:

It created and appended a wrapper element to itself in the host document, depriving the element (a <model-viewer> internal detail) of shadow root encapsulation from content author CSS
It directly assigned a transform and an opacity to the element, superseding and overwriting user style configuration respectively

Once all the DOM effects have played out, the live DOM will look something like this:
<model-viewer id="modelViewer">

</model-viewer>

We can avoid all of these problems by using <slot>s (and wrappers) in the shadow root. With <slot>s, no elements need to be moved, no hierarchy needs to be changed, and no styles need to be overwritten. Positional styles provided by the content author will layer additively with positional styles assigned to a <slot> wrapper. If the author sets the opacity of the hotspot, it will be multiplied by the opacity set by <model-viewer> on the <slot> wrapper. The  (in the example) doesn't need to move around the hierarchy (which is what the content author expects). And perhaps most importantly: if the CSS2DRenderer.domElement is in the shadow root, content author styles do not apply to it (so no danger of accidentally messing with it).

@cdata Thank you for the detailed example! I'll address your first four bullets as though they're numbered:

True, though I believe you can accomplish relative transforms by making a child node under it. This would certainly require documentation.
I just tested your example and it actually works fine. What would overwrite it? In fact, this is the primary reason I like this approach better than slots; all my CSS styles apply just as they would to any other nodes I put on my page.
Valid con, though I think documentation would suffice.
Akin to 2), I actually view this as a pro, not a con. It behaved exactly as I told it to!

The trouble I have with slots is the convoluted nature of styling them, and potentially having state that needs to be synced between two places (the light and shadow DOMs). But I agree, it's not a clear slam dunk either way.

I'll put together a live example and then we can discuss more.

Please consider this live example demonstrating a handful of the ways that user expectations could be violated with this approach: http://lopsided-motion.glitch.me/hotspot-exposure.html
In the first example, I try to style the transform of the hotspot and it doesn't seem to work.
In the second example, I try something many who are familiar with CSS might try: add an !important expression to bump up the precedence of my style. This breaks in a totally new way.
In the third example, I break annotations all in one go by accidentally styling the wrapper.
Note that the third example is particularly important because users don't always have a say in what a stylesheet targets. They may be consuming a stylesheet from a third party that violates the expectations of <model-viewer> or Three.js. These examples illustrate the perils of a shared style scope, and explain why shadow roots exist: you need strong style encapsulation in order to guarantee the portability of a component.
You were right about border-radius, because the style attribute is not being replaced wholesale (I made a mistake in my example), so I used another style property to demonstrate the contention (opacity). As for asking users to just make more nodes to work around our implementation details, we don't need to ask that of them; what do we gain from doing so?
HTML is a sort of high-level, functional programming language. Each tag is a function invocation, and attributes and the child list are the arguments. When an element manipulates its own child list, it is analogous to re-invoking a function with different arguments. It turns out that almost no DOM elements spawn new hierarchy and/or re-parent nodes. One notable exception to this is
, but it is the exception that proves the rule: it is one of the oldest HTML elements, and we do not create elements in its likeness today because what it does is unintuitive and confusing.
Assuming the current implementation, let's say we want to support removing a hotspot node in order to hide a hotspot. We cannot simply observe for nodes being removed from the host (where the user told them to go, and where the user will intuitively expect them to be); after all, the nodes are re-parented to a whole new element. If the user reads our docs and understands this, then they will know to remove the hotspot node from the Three.js-specific wrapper. But, if they want to dynamically add a new hotspot, should they add it to the Three.js-specific wrapper? Or to <model-viewer>? And for implementation purposes, <model-viewer> will need not one but two mutation observers: one for the host <model-viewer> (to observe when nodes are added) and one for the Three.js
 wrapper (to observe when nodes are removed).
On the flip side, let's say that hotspots stay exactly where they are when they are created (and that we are using <slot>s internally). The user can inspect the live DOM and see that the node is where they said it should be when they authored their HTML. No docs are necessary to explain this to them, because by-and-large this is how HTML/DOM works. And <model-viewer> implementation is simpler because there is only one node that we care about observing: <model-viewer>. When hotspot nodes are added to <model-viewer>'s child list, we create hotspots for them. When hotspot nodes are removed from <model-viewer>'s child list, we cleanup/remove corresponding hotspot state.
The most important thing, ultimately, is that if we used slots, we would not need to ask our users to read our docs in order to understand how the hierarchy of the DOM changes when they configure <model-viewer>. Instead, those details will be opaque to the user, and <model-viewer> will do exactly what they asked for (which, ultimately, is best represented by the HTML they have written themselves). Styles will merge in reasonable ways.  Everything seems to be working properly in dev tools; I think the CSS2DRenderer element is just hidden, but I can't figure out why.

@cdata Nevermind, fixed!

@cdata I've tested enough that I think the mutationObserver is now doing all the things we want it to. I need to add some automated tests for that. The only weird thing I see is that the hotspots will appear briefly at the top corner before the progress bar appears, which is unsightly. Do you have any idea how to fix that?

Sorry, some more hotspot questions / suggestions .. I've found myself listening to 'camera-change' events in order to notify individual hotspots as to their visibility (i.e. to do more than just toggle opacity via css variables). Is it possible to toggle a non-intrusive class / data attribute on the slotted node, in addition to the .hide class you toggle on its container in the component?
Also in looking into this I noticed that the $updateHotspots logic is running on tick and not taking into account the previous state of the hotspot element. Taking this and the above into account, can I suggest the following?
// from annotation.ts line 208
[$updateHotspots]() {
  // get the camera position outside of the loop
  const view = this[$scene].activeCamera.position.clone();

  // check current position against previous position, continue if camera has moved
  // note - this.view is defined after first run
  if (this.view && view.distanceTo(this.view) === 0) return;

  // clone the current position before it's subtracted (below)
  this.view = view.clone();
  for (let i = 0, l = children.length; i < l; i++) {
    const object = children[i];
    if (object instanceof Hotspot) {
      view.sub(object.position);

      // check if the element is currently hidden / occluded
      const hidden = object.element.classList.contains('hide');

      // if element should be hidden / occluded (and isn't already)
      if (view.dot(object.normal) < 0) {
        if (!hidden) {
          object.element.classList.add('hide');

          // also update [data-occluded="1"] on the slotted nodes
          // data attribute is suggested over a class as per normal and position attrs
          object.element.children[0].assignedNodes()
          .forEach($el => ($el.dataset.occluded = 1));
        }
      }

      // if element shouldn't be hidden / occluded (but is)
      else if (hidden) {
        object.element.classList.remove('hide');

        // also update [data-occluded="0"] on the slotted nodes
        object.element.children[0].assignedNodes()
        .forEach($el => ($el.dataset.occluded = 0));
      }
    }
  }
}


Memorypipeline (Distributed) does not delete memories from AzureCognitiveSearch

Describe the bug
Memorypipeline (Distributed) does not delete memories from AzureCognitiveSearch

When user use the "upload document" it will be saved to AzureCognitiveSearch. When eventually the session will be deleted, the memorypipeline destroy everything else but not AzureCognitiveSearch memories..
It tries to find an index but does not use the common chatmemory

To Reproduce
Steps to reproduce the behavior:

Use Distributed memorypipeline
User creates sessions and save documents / memories
After discussions, session will be deleted
Everything else is destroyed but not the AzureCognitiveSearch memories / document embedings..

Expected behavior
If user deletes the session > it should also delete memories from AzureCognitiveSearch

@TaoChenOSU and / or @crickman can you take a look at this?

Thank you for reporting this.  Memory are indeed intended to be deleted along with the chat.  I'll dig into what is going on here.

Hi @crickman, as much as I have researched the matter myself.. The memorypipeline switch / forgets the "chatmemory" index name when pipeline goes to private-delete-document queue > ether it does not  Respect the given index value or given index value is not the correct value (mixed at some point)

Thank you.  Looks like we were passing in the wrong id...pr incoming.


svgbobrus: init at 2017-08-29

Things done

[ ] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] Linux

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Fits CONTRIBUTING.md.

Pinging @kevincox as requested.
This fails with
ERROR: The Cargo.lock file doesn't exist

The solution is to add a Cargo.lock. Either ask the project to do so or run cargo update in the project and add the Cargo.lock as a patch to the project. Otherwise we can not build this project reproducible.

And how to refer to the Cargo.lock file then?

Ah, I see my problem: The commandline binary "svgbob_cli" is actually a subdir of the repository. And there is also the Cargo.lock file.
How to specify a subdir as the actual target?

Set the sourceRoot variable would be my wild guess.

Seems like it should work. This is what https://github.com/NixOS/nixpkgs/blob/7c696a08ce0faa7851dec48d9899980699f224a3/pkgs/applications/version-management/pijul/default.nix#L14 does.

Hm... does not work for me. Also not without the "rus" part.

I'll take a look when I get home but often what I do it add set -i somewhere so that I can see what it is doing, that often helps me find out what I am setting wrong. You can see other rust packages to find spots where you can inject this.

Okay, now I only get a compiletime error (when compiling svgbobrus) because the nightly toolchain is required instead of stable. Everything else seems to work.

Hmm, I don't actually know how to use nightly. There is a passthru.rustc which might work but I haven't tried it.

There is rustBeta and rustNightly. However both are broken at the moment in master. rustNightlyBin.buildRustPackage might work.

#30088 has deleted rustNightly. @matthiasbeyer would you try to resurrect or close this PR?

Well, I do not care about that software this much anymore... shall we close it then?

this is up to you.


Set end time during on_exit instead of during `on_close

Feature Request
Motivation
Currently, the open telemetry span is considered to be running until the tracing span is dropped and closed. This can be an issue in cases where either the span is held onto in case the operation needs more processing which was not known beforehand or when a structure holds onto the span.
More specifically, this can happen for example with JoinHandle<T> which points to a spawned instrumented task. Even though the task has finished as long as we hold the handle, the span will exist and end time will be sent only when the handle is dropped.
Proposal
Set the time on each on_exit, overwriting the value on each exit. The last value will be used when the span is closed, built, and sent.
Alternatives
The user can manage dropping the spans themself, but then they sometimes cannot use instrument() and some other useful utilities.

This also prevents us from having children spans that are open longer than their parent.
tracing closes spans only after all their children have been also closed so that they have access to the parent and its extensions.


Improve the style of the wizard steps when in a detail view dialog

One more issue, in the setup wizard if you shrink vertically the buttons now overlap screen content and there's also something strange happening when shrunk horizontally.
The steps also need some polish when shrunk, however I'm not sure there's a simple solution (when individual step labels start wrapping)


Improve job completion wait logic

Improve job completion wait logic

Codecov Report

Merging #504 into master will decrease coverage by 0.16%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master     #504      +/-   ##
==========================================
- Coverage   65.28%   65.12%   -0.17%
==========================================
  Files          34       34
  Lines        1161     1164       +3
  Branches       93       95       +2
==========================================
  Hits          758      758
- Misses        350      353       +3
  Partials       53       53

Impacted Files
Coverage Δ

...ng/src/main/java/io/cellery/impl/RunTestSuite.java
3.14% <0%> (-0.08%)
:arrow_down:

Continue to review full report at Codecov.

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