DeepEnsembleRegression doesn't reduce to MVERegression for 1 member

When building a MVE-GMM ensemble with one MVERegression member, then the GMM equations for mean and variance should reduce to the case of as single MVERegression model. This is not the case for the sigmas (pred_uct) of DeepEnsembleRegression.
The reason is that in compute_aleatoric_uncertainty() and compute_predictive_uncertainty() in lightning_uq_box/eval_utils/uq_computation.py, sample_sigma_preds need to be squared, in line with Kendal 2017 (https://arxiv.org/abs/1703.04977) eq. 9, which these functions reference.
I can send a PR with a fix (just 2 lines) and with a test that catches the error (regression case), but I'm not sure what else this might affect -- I had trouble installing the stack for running all tests (in particular hydra), so I couldn't run the test suite. My test doesn't use hydra and shows that the fix works. Please let me know. We have applied this fix internally for our use case, but It would be nice to see it upstream as well I guess.

Hi @elcorto . I hadn't considered the case, because I assumed that if you just have one member then I assumed one would use the member class itself, so MVERegression in that case. Maybe, this should be made clear, or also be handled like you suggest. Or maybe I am overlooking what the use case is for the ensemble class with just one member?
Apologies for the trouble with the tests. I intended that doing pip install lightning-uq-box[dev] would install all dependencies including the ones required to do tests, but sounds like there is an error. Could you send me the error so I can investigate?

Regarding the MVE part: yes you are correct, one MVERegression wrapped in DeepEnsembleRegression doesn't make sense. I used it as a test to find out why I wasn't getting calibrated results with DeepEnsembleRegression, since using that with a single MVERegression member must produce the same results (up to numerical precision) as a standalone MVERegression. The reason was the missing squared sigma as described above. I can open a PR which includes the fix and a test. Since the fix is trivial, you may also implement that and a test yourself. Please let me know.
Regarding test tooling: this was a mistake on my end. Tests work now. I only found a couple of tests failing when using a GPU machine. On CPU all pass, but I will open a separate issue for that.

Ah, the only thing I had to install to make tests work was jsonargparse[signatures]>=4.27.7. However, I installed the test deps by hand and skipped the docs libraries listed in the dev section, so jsonargparse might be a dep of one of them.  I suggest to maybe separate test and docs deps in pyproject.toml.

I can open a PR which includes the fix and a test. Since the fix is trivial, you may also implement that and a test yourself. Please let me know.

Yes, that be great if you can make a PR if have the fix already!

Ah, the only thing I had to install to make tests work was jsonargparse[signatures]>=4.27.7. However, I installed the test deps by hand and skipped the docs libraries listed in the dev section, so jsonargparse might be a dep of one of them. I suggest to maybe separate test and docs deps in pyproject.toml.

Ah you are correct, jsonargparse[signatures] is listed as a dependency for the CI requirements but not in pyproject.toml for the dev section. Will separate them. Thanks for pointing that out!


PowerToys Run Listing MS Teams Multiple Times

Microsoft PowerToys version
0.80.1
Installation method
GitHub
Running as admin
Yes
Area(s) with issue?
PowerToys Run
Steps to reproduce
Have Teams install updates? I do not know the exact steps. I do know that I had two listings after an update, but it just updated again today, and now I have three listings.
Teams auto updates.
✔ Expected Behavior
Only one listing for the app
❌ Actual Behavior
Is listed 3 times

Only one installed app exists

Other Software
You have Microsoft Teams version 24165.1414.2987.41.
You've got the latest version. It was last checked on 2024-07-12.
The client version is 49/24061318408.

https://github.com/microsoft/PowerToys/issues/32063 released in 0.81.0 improve how the update of packaged apps is handled by PT Run. It should prevent cases like that.
Can you update to the latest version? https://github.com/microsoft/PowerToys/releases/tag/V0.82.1
/needinfo

I mean, it seems to be working. Just weird it didn't tell me there was a new version when I got my version info.


What version to use in Ubuntu 19.10?

Hello,
ubuntu 19.10,
gnome-shell 3.34.3

installed version 4
enable it
logout
can't login
disabled gnome-extension using terminal
can login

questions:

what is the possible problem?
should i use different version?

Hi @lon9man, sorry to hear that but this extension supports gnome-shell 3.36 and above. (As you can see on the e.g.o. page https://extensions.gnome.org/extension/3795/notification-timeout/).
You can try to provide the gnome-shell log but no promises.
I will add the note of supported gnome-shell to this GitHub page.

@vchlum
in Settings > About i see:

but in terminal:

i am not an expert in this, but:

what is the debug steps can i do?
what version is applicable for which Gnome Shell?

shel-log
лют 04 14:13:49 Draco gnome-shell[7240]: Object .Gjs_WindowSwitcherPopup (0x55c49509d200), has been already deallocated — impossible to access it. This might be caused by the object having been destroyed f
лют 04 14:13:49 Draco gnome-shell[7240]: clutter_actor_destroy: assertion 'CLUTTER_IS_ACTOR (self)' failed
лют 04 14:13:49 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:13:49 Draco gnome-shell[7240]: #0   55c49a523418 i   resource:///org/gnome/shell/ui/windowManager.js:2094 (c892cf35e98 @ 520)
лют 04 14:13:49 Draco gnome-shell[7240]: #1   7ffc4f1efd00 b   self-hosted:1013 (5da0ab34100 @ 492)
лют 04 14:13:57 Draco org.gnome.tweaks.desktop[7240]: WARNING : Error loading desktopfile: /home/longman/.config/autostart/Apploye.desktop
лют 04 14:14:28 Draco gnome-shell[7240]: endSessionDialog: No XDG_SESSION_ID, fetched from logind: 2
лют 04 14:14:28 Draco gnome-shell[7240]: gnome-session gave us a dead inhibitor: /org/gnome/SessionManager/Inhibitor433
лют 04 14:14:31 Draco gnome-shell[7240]: Ignored exception from dbus method: Gio.IOErrorEnum: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code19: Operation was cancelled
лют 04 14:15:44 Draco gnome-shell[7240]: gnome-session gave us a dead inhibitor: /org/gnome/SessionManager/Inhibitor434
лют 04 14:15:46 Draco thunderbird.desktop[7240]: JavaScript error: resource://messagingmenu/modules/MessagingMenuModule.jsm, line 795: ReferenceError: indicator is not defined
лют 04 14:15:46 Draco gnome-shell[7240]: JS WARNING: [resource:///org/gnome/gjs/modules/core/_signals.js 133]: Too many arguments to method Clutter.Actor.destroy: expected 0, got 1
лют 04 14:15:46 Draco gnome-shell[7240]: JS WARNING: [resource:///org/gnome/gjs/modules/core/_signals.js 133]: Too many arguments to method Clutter.Actor.destroy: expected 0, got 1
лют 04 14:15:46 Draco gnome-shell[7240]: Window manager warning: META_CURRENT_TIME used to choose focus window; focus window may not be correct.
лют 04 14:15:46 Draco gnome-shell[7240]: JS ERROR: TypeError: actor.get_meta_window(...) is null
                                            _destroyWindowDone@resource:///org/gnome/shell/ui/windowManager.js:1801:32
                                            onStopped@resource:///org/gnome/shell/ui/windowManager.js:1771:39
                                            _makeEaseCallback/<@resource:///org/gnome/shell/ui/environment.js:72:13
                                            _easeActor/<@resource:///org/gnome/shell/ui/environment.js:131:56
лют 04 14:15:46 Draco gnome-shell[7240]: JS ERROR: TypeError: actor.get_meta_window(...) is null
                                            _destroyWindowDone@resource:///org/gnome/shell/ui/windowManager.js:1801:32
                                            onStopped@resource:///org/gnome/shell/ui/windowManager.js:1771:39
                                            _makeEaseCallback/<@resource:///org/gnome/shell/ui/environment.js:72:13
                                            _easeActor/<@resource:///org/gnome/shell/ui/environment.js:131:56
лют 04 14:15:46 Draco gnome-shell[7240]: JS ERROR: TypeError: actor.get_meta_window(...) is null
                                            _destroyWindowDone@resource:///org/gnome/shell/ui/windowManager.js:1801:32
                                            onStopped@resource:///org/gnome/shell/ui/windowManager.js:1771:39
                                            _makeEaseCallback/<@resource:///org/gnome/shell/ui/environment.js:72:13
                                            _easeActor/<@resource:///org/gnome/shell/ui/environment.js:131:56
лют 04 14:15:46 Draco gnome-shell[7240]: JS ERROR: TypeError: actor.get_meta_window(...) is null
                                            _destroyWindowDone@resource:///org/gnome/shell/ui/windowManager.js:1801:32
                                            onStopped@resource:///org/gnome/shell/ui/windowManager.js:1771:39
                                            _makeEaseCallback/<@resource:///org/gnome/shell/ui/environment.js:72:13
                                            _easeActor/<@resource:///org/gnome/shell/ui/environment.js:131:56
лют 04 14:15:46 Draco gnome-shell[7240]: JS ERROR: TypeError: actor.get_meta_window(...) is null
                                            _destroyWindowDone@resource:///org/gnome/shell/ui/windowManager.js:1801:32
                                            onStopped@resource:///org/gnome/shell/ui/windowManager.js:1771:39
                                            _makeEaseCallback/<@resource:///org/gnome/shell/ui/environment.js:72:13
                                            _easeActor/<@resource:///org/gnome/shell/ui/environment.js:131:56
лют 04 14:15:46 Draco gnome-shell[7240]: JS ERROR: TypeError: actor.get_meta_window(...) is null
                                            _destroyWindowDone@resource:///org/gnome/shell/ui/windowManager.js:1801:32
                                            onStopped@resource:///org/gnome/shell/ui/windowManager.js:1771:39
                                            _makeEaseCallback/<@resource:///org/gnome/shell/ui/environment.js:72:13
                                            _easeActor/<@resource:///org/gnome/shell/ui/environment.js:131:56
лют 04 14:15:46 Draco gnome-shell[7240]: JS ERROR: TypeError: actor.get_meta_window(...) is null
                                            _destroyWindowDone@resource:///org/gnome/shell/ui/windowManager.js:1801:32
                                            onStopped@resource:///org/gnome/shell/ui/windowManager.js:1771:39
                                            _makeEaseCallback/<@resource:///org/gnome/shell/ui/environment.js:72:13
                                            _easeActor/<@resource:///org/gnome/shell/ui/environment.js:131:56
лют 04 14:15:46 Draco gnome-shell[7240]: JS ERROR: TypeError: actor.get_meta_window(...) is null
                                            _destroyWindowDone@resource:///org/gnome/shell/ui/windowManager.js:1801:32
                                            onStopped@resource:///org/gnome/shell/ui/windowManager.js:1771:39
                                            _makeEaseCallback/<@resource:///org/gnome/shell/ui/environment.js:72:13
                                            _easeActor/<@resource:///org/gnome/shell/ui/environment.js:131:56
лют 04 14:15:46 Draco gnome-shell[7240]: JS ERROR: TypeError: actor.get_meta_window(...) is null
                                            _destroyWindowDone@resource:///org/gnome/shell/ui/windowManager.js:1801:32
                                            onStopped@resource:///org/gnome/shell/ui/windowManager.js:1771:39
                                            _makeEaseCallback/<@resource:///org/gnome/shell/ui/environment.js:72:13
                                            _easeActor/<@resource:///org/gnome/shell/ui/environment.js:131:56
лют 04 14:15:46 Draco thunderbird.desktop[7240]: JavaScript error: resource://messagingmenu/modules/MessagingMenuModule.jsm, line 536: NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERRO
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was destroy on Gjs_IconGrid 0x55c496106120.
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was destroy on Gjs_IconGrid 0x55c4956d21b0.
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was destroy on StButton 0x55c495a8bc10.
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was destroy on StButton 0x55c495a8bc10.
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was destroy on Gjs_BaseIcon 0x55c4956aef70.
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was actor-removed on Gjs_IconGrid 0x55c4956d21b0.
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was destroy on Gjs_IconGrid 0x55c4985c9c60.
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was destroy on StButton 0x55c49863f8d0.
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was destroy on StButton 0x55c49863f8d0.
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was destroy on Gjs_BaseIcon 0x55c4956a89d0.
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was actor-removed on Gjs_IconGrid 0x55c4985c9c60.
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was destroy on StButton 0x55c495b350a0.
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was destroy on StButton 0x55c495b350a0.
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was destroy on Gjs_BaseIcon 0x55c498553020.
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was actor-removed on Gjs_IconGrid 0x55c4985c9c60.
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was destroy on StButton 0x55c4956d08b0.
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was destroy on StButton 0x55c4956d08b0.
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was destroy on Gjs_BaseIcon 0x55c497bd7120.
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was actor-removed on Gjs_IconGrid 0x55c4985c9c60.
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was destroy on StButton 0x55c4986b29d0.
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was destroy on StButton 0x55c4986b29d0.
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was destroy on Gjs_BaseIcon 0x55c495b09080.
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was actor-removed on Gjs_IconGrid 0x55c4985c9c60.
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was destroy on StButton 0x55c4986b0570.
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was destroy on StButton 0x55c4986b0570.
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was destroy on Gjs_BaseIcon 0x55c495cd2660.
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was actor-removed on Gjs_IconGrid 0x55c4985c9c60.
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was destroy on StButton 0x55c495613dc0.
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was destroy on StButton 0x55c495613dc0.
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was destroy on Gjs_BaseIcon 0x55c4984f39e0.
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was actor-removed on Gjs_IconGrid 0x55c4985c9c60.
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was destroy on StButton 0x55c496853f30.
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was destroy on StButton 0x55c496853f30.
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was destroy on Gjs_BaseIcon 0x55c4960bca10.
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was actor-removed on Gjs_IconGrid 0x55c4985c9c60.
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was destroy on StButton 0x55c495e74210.
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was destroy on StButton 0x55c495e74210.
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was destroy on Gjs_BaseIcon 0x55c4956a9de0.
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was actor-removed on Gjs_IconGrid 0x55c4985c9c60.
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was destroy on StButton 0x55c498030420.
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: == Stack trace for context 0x55c49351e320 ==
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was destroy on StButton 0x55c498030420.
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was destroy on Gjs_BaseIcon 0x55c495614780.
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was actor-removed on Gjs_IconGrid 0x55c4985c9c60.
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was destroy on StButton 0x55c4939859d0.
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was destroy on StButton 0x55c4939859d0.
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was destroy on Gjs_BaseIcon 0x55c495f2bba0.
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was actor-removed on Gjs_IconGrid 0x55c4985c9c60.
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was destroy on StButton 0x55c496364240.
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was destroy on StButton 0x55c496364240.
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was destroy on Gjs_BaseIcon 0x55c4986b2310.
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was actor-removed on Gjs_IconGrid 0x55c4985c9c60.
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was destroy on StButton 0x55c4955827e0.
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was destroy on StButton 0x55c4955827e0.
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was destroy on Gjs_BaseIcon 0x55c495cc5620.
лют 04 14:15:46 Draco gnome-shell[7240]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signa
лют 04 14:15:46 Draco gnome-shell[7240]: The offending signal was actor-removed on Gjs_IconGrid 0x55c4985c9c60.
лют 04 14:15:46 Draco gnome-shell[7240]: (google-chrome-stable:21668): GVFS-RemoteVolumeMonitor-WARNING **: 14:15:46.733: Owner of volume monitor org.gtk.vfs.UDisks2VolumeMonitor disconnected from the bus;
лют 04 14:15:46 Draco gnome-shell[7240]: (google-chrome-stable:21668): GVFS-RemoteVolumeMonitor-WARNING **: 14:15:46.734: Owner of volume monitor org.gtk.vfs.AfcVolumeMonitor disconnected from the bus; rem
лют 04 14:15:46 Draco gnome-shell[7240]: (google-chrome-stable:21668): GVFS-RemoteVolumeMonitor-WARNING **: 14:15:46.735: Owner of volume monitor org.gtk.vfs.MTPVolumeMonitor disconnected from the bus; rem
лют 04 14:15:46 Draco gnome-shell[7240]: (google-chrome-stable:21668): GVFS-RemoteVolumeMonitor-WARNING **: 14:15:46.737: Owner of volume monitor org.gtk.vfs.GPhoto2VolumeMonitor disconnected from the bus;
лют 04 14:15:46 Draco gnome-shell[7240]: (google-chrome-stable:21668): GVFS-RemoteVolumeMonitor-WARNING **: 14:15:46.737: Owner of volume monitor org.gtk.vfs.GoaVolumeMonitor disconnected from the bus; rem
лют 04 14:15:46 Draco gnome-shell[7240]: [21668:21705:0204/141546.778091:FATAL:bus.cc(1219)] D-Bus connection was disconnected. Aborting.
лют 04 14:15:46 Draco gnome-shell[7240]: [21668:21403:0204/141546.780039:FATAL:bus.cc(1219)] D-Bus connection was disconnected. Aborting.
лют 04 14:15:46 Draco mysql-workbench.desktop[7240]: Terminated
лют 04 14:15:46 Draco gnome-shell[7240]: [21720:21720:0204/141546.869432:ERROR:connection.cc(66)] X connection error received.
лют 04 14:15:46 Draco gnome-shell[7240]: [21720:21749:0204/141546.869503:ERROR:connection.cc(66)] X connection error received.
лют 04 14:15:47 Draco viber.desktop[7240]: The X11 connection broke: I/O error (code 1)
лют 04 14:15:47 Draco viber.desktop[7240]: XIO:  fatal IO error 2 (No such file or directory) on X server ":1"
лют 04 14:15:47 Draco viber.desktop[7240]:       after 14401 requests (13338 known processed) with 0 events remaining.
лют 04 14:15:47 Draco viber.desktop[7240]: QObject::~QObject: Timers cannot be stopped from another thread
лют 04 14:15:48 Draco gnome-shell[1869]: Removing a network device that was not added
лют 04 14:15:48 Draco gnome-shell[1869]: Removing a network device that was not added

thanks

I can not see anything related to this extension in the log. I installed Ubuntu 19.10 in my VirtualBox and it uses gnome-shell 3.34. The extension works without issues on gnome-shell 3.34 and Ubuntu 19.10.  Since your system is confused about the gnome-shell version, I believe you have installed gnome-shell from some non-official repository, and it causes your trouble:-( I am afraid I can not help you. The Ubuntu 19.10 is EOL a long time ago.

@vchlum
i upgraded OS till 20.04, enabled extension and it works as expected.
big thanks for you time!


🐞 - The color does not change in the proprietary version of rating component

Which @taiga-ui/* package(s) are the source of the bug?
kit
Please provide a link to a minimal reproduction of the bug
https://stackblitz.com/edit/taiga-starter
Description

Angular version
latest
Taiga UI version
latest
Which browsers have you used?

[X] Chrome
[ ] Firefox
[ ] Safari
[ ] Edge

Which operating systems have you used?

[X] macOS
[ ] Windows
[ ] Linux
[ ] iOS
[ ] Android

fixed: coretech-frontend/taiga-ui/-/merge_requests/128
and: https://github.com/Tinkoff/taiga-ui/pull/1828


[Incident] PaleoHack User sessions won't start

Summary
The PaleoHackWeek hub is not putting users on the new nodes that were pre-cooked for the event. Here are the hub logs:
2021-10-28T17:38:46Z [Warning] 0/23 nodes are available: 20 Insufficient cpu, 3 node(s) didn't match node selector.
2021-10-28T17:38:48Z [Normal] pod didn't trigger scale-up: 3 node(s) didn't match node selector, 1 max node group size reached

In addition, I'm not sure if this is relevant but it seems like all of the CPU commit %s are pinned at 62.6% and I'm not sure why. I wonder if that's related to the 20 Insufficient cpu error above. Here's an image of the grafana plot:

Timeline (if relevant)
If it makes sense to include a timeline for this incident, then do so below.
All times in {{ most convenient timezone}}.
{{ yyyy-mm-dd hh:mm }}
Start of incident. First symptoms, possibly how they were identified.
{{ hh:mm }}
Investigation starts.
{{ hh:mm }}
More details.

After-action report
These sections should be filled out once we've resolved the incident and know what happened.
They should focus on the knowledge we've gained and any improvements we should take.
What went wrong
Things that could have gone better. Ideally these should result in concrete
action items that have GitHub issues created for them and linked to under
Action items.
Where we got lucky
These are good things that happened to us but not because we had planned for them.
Action items
These are only sample subheadings. Every action item should have a GitHub issue
(even a small skeleton of one) attached to it, so these do not get forgotten. These issues don't have to be in infrastructure/, they can be in other repositories.
Process improvements

{{ summary }} [link to github issue]
{{ summary }} [link to github issue]

Documentation improvements

{{ summary }} [link to github issue]
{{ summary }} [link to github issue]

Technical improvements

{{ summary }} [link to github issue]
{{ summary }} [link to github issue]

Actions

[x] Incident has been dealt with or is over
[ ] Sections above are filled out
[ ] Incident title and after-action report is cleaned up
[ ] All actionable items above have linked GitHub Issues

I just had a quick debrief with the PaleoHack team and we discussed a bit of this issue as well. Here are some raw notes. Some of them are relevant to this incident specifically but not all of them, just putting them here so we don't lose them.

Things that would help

Provide a checklist about what people should do before an event

Run the notebooks
Click the links etc

Documentation improvements

Environment generation

It was confusing to have to go to a separate repository to learn how to build a docker image
More context around the instructions would be helpful
Make it clear that people can re-use the quay.io images for other JupyterHubs etc
Improve explanations around what "quay.io" is in general

Tutorials for "what do you do once the hub is set up?"

E.g., step by step guide to sharing a notebook on a hub

Recommendations for how communities can filter the best participants

E.g., recommend that communities run a notebook with some basic functionality so that they know what skills they're expected to learn

How to define multiple user profiles for use on the hub

It wasn't obvious how to do this as an admin

Provide some best-practices for certain kinds of events and communities

OK I've updated the top comment and included links to follow-up issues, closing this one now! thanks everybody for your hard work :-)


Add PhantomJS, Selenium, and their various dependencies

@wjwwood That's a good point, so I've removed it.

I'll let another maintainer double check this before merging it.

I've changed the name to python-selenium-pip as per @dirk-thomas's suggestion.


StreamField block usage report

Is your proposal related to a problem?
It would be nice to see a block usage report in the built in reports in Wagtail admin.
Describe the solution you'd like

Reporting of all block types, initially just an inventory.
Ability to filter pages by block usage (or even all models).
Ability to configure (maybe in code) the kinds of blocks that will be listed.

Describe alternatives you've considered
It may make sense for this not to be a core report and is better served by an external package, due to both nuance of requirements and performance concerns.
Additional context

See a historic PR from 2022, a starting point for this reporting approach https://github.com/wagtail/wagtail/pull/9267 (and the trigger for raising this issue).
The PR was just a DRAFT / POC and there has been lots of improvements to how reports are built and even universal listings that may change how this kind of thing would be implemented.
https://github.com/cfpb/wagtail-inventory does already serve mostly this purpose and is well maintained by CFPB, there may not be a need for a core Wagtail solution.

Working on this

There may need to be some consensus on if this is a feature to have in the core code first, please comment if you are willing to work on this and how you would see this useful in your current production projects.
This would require an understanding of how StreamField works across all models, specifically pages.
Some performance optimisations would be required and extensive testing of all block types in unit tests.
View our contributing guidelines, add a comment to the issue once you’re ready to start.

@willbarton - any thoughts or insights for this enhancement request? raised from #9267

Tagging @chosak also.

@jhonatan-lopes I believe you had a version of this around the same time as #10850 – what do you think of your version as a candidate to become a built-in report?

Hey @thibaudcolas, I would be happy to. The only caveat is that the version that I implemented for Moz relies on the PageBlock model from wagtail-inventory.
We need a model that tracks the relationship between pages and blocks and that's exactly what the PageBlock model does in wagtail-inventory. I initially thought that a "Blocks usage report" would live better under that package.

👋 The wagtail-inventory report is implemented as a Wagtail Report in the most recent few versions, and looks like this these days:

@jhonatan-lopes I'd be very curious to see what your report looks like compared to the wagtail-inventory version! Would it be possible for you to share a screenshot?
I agree that this would be a useful addition to Wagtail core. The PageBlock approach from wagtail-inventory maintains a reference index of all (page, block type) pairs which makes it easy to search for pages containing a certain block type -- but this is actually somewhat limited. Ideally users would be able to search for block types and values. And it'd be nice if there were a way to leverage the JSON structure of StreamField data to do JSON-based queries and avoid the need to maintain an index at all (we've played with this a bit here but only in a Postgres-specific way). That said, even the basic block usage report that wagtail-inventory provides has been extremely useful for us over the years.

Hey @chosak, sure I'll put a screenshot here. For a little bit of context, the idea of a new report for block types usage came while working together with the design team on Mozilla Foundation during a CMS clean up. They were making an audit of their block types and wanted to quickly answer the following questions:

What are all block types that we use? Can we get a list of those?
What are the block types that we use the most?
Which block types do we use the least?
Is a block type builtin (from Wagtail core) or was it defined by us? Can we quickly check that?
Can we have a list of pages that use that block type?

The repo was already setup with wagtail-inventory and they had access to the "block inventory" that you've shown. However, this is what it looks like for them (with fake data):

In production, it's even worse because there are more languages, so you end up with 8 duplicates (English, French, German, Dutch, Portuguese,...) before moving on to another page.
From the report builtin to wagtail-inventory, it can be seen that getting answers to the questions above is not trivial and it would require either a dev to compile the data or lots of manual labour from an editor to go through the data that is available now.
For this reason, I've scoped up a new "block types usage" report, focusing on displaying the blocks themselves at the centre and how they are used throughout the pages. This is what it looks like with fake data:

The names of the blocks are simplified for better presentation. You can hover over the block's name and a tooltip will display the block's "full name":

It's also possible to get a list of all page types that use that block:

Finally, there's a flag that indicate whether this is a "Core" (Wagtail builtin) app or a "Custom" one and a counter indicating how many pages are using that block.
Implementation
As I've said, the issue here is that this was built specifically for the Mozilla Foundation, so I was able to leverage the PageBlock model and the Postgres database and assemble a queryset without going through the JSON data.
I agree that it would be awesome to query the page data directly using the JSON but I would have to take a very cautious approach, especially considering:

The different database backends
How to get an unique aggregate for all block types (this is easily done with wagtail-inventory by leveraging PageBlock.objects.all().values("block").annotate(....))
How to keep the queries simple

Limitations
The current Moz implementation is still lacking filters, especially for a locale selection.

Thanks to @chosak for reminding me again to reply to this thread. I have a lot of thoughts, but this is something we've been actively working on at CFPB as part of a larger content audit. That's still very much in progress, and we're like to publish the tools we're working on these as additional Wagtail reports, but they're not really more than internal proofs-of-concept right now.
Specific to these questions:

What are all block types that we use? Can we get a list of those?
What are the block types that we use the most?
Which block types do we use the least?
Is a block type builtin (from Wagtail core) or was it defined by us? Can we quickly check that?
Can we have a list of pages that use that block type?

We've got a work-in-progress QuerySet based on Queryish (AWESOME library for making anything a Wagtail report, FWIW) that produces something we're currently working with in CSV to give an answer to all of these questions.

without going through the JSON data.

Except that we're diving into the JSON to get it. I had experimented with PostgreSQL-specific JSON queries constructing temporary tables with some success to get this info, but found that it's almost as fast for our site (which is not small) to do it in Python. And then it's portable to other databases.
Here's our proof-of-concept for block usage right now:
import csv
from dataclasses import dataclass
from wagtail.blocks import (
    BoundBlock,
    ListBlock,
    StreamBlock,
    StreamValue,
    StructBlock,
    StructValue,
)
from wagtail.blocks.list_block import ListValue
from wagtail.models import get_page_models, Site

from queryish import Queryish

dotted_name = lambda cls: ".".join((cls.__module__, cls.__qualname__))

@dataclass
class AuditedBlock:
    page_model: type
    field: str
    path: str
    block: type
    pages: list
    total_occurrences: int = 0
    pages_count: int = 0
    pages_live_count: int = 0
    pages_in_default_site_count: int = 0

# Traverse a stream field and yield back each available block type
def traverse_streamblock(page_model, block, parent=None):
    """Walk model stream block objects to get initial AuditedBlocks"""
    audited_block = AuditedBlock(
        page_model=dotted_name(page_model),
        field=None,
        path=(parent + "." + block.name if parent is not None else block.name),
        block=dotted_name(block.__class__),
        pages=[],
    )

    yield audited_block

    # If this is a StreamBlock or StructBlock it'll have child blocks
    if isinstance(block, (StreamBlock, StructBlock)):
        for child_block_field_name in block.child_blocks:
            yield from traverse_streamblock(
                page_model,
                block.child_blocks[child_block_field_name],
                parent=audited_block.path,
            )

    elif isinstance(block, ListBlock):
        yield from traverse_streamblock(
            page_model,
            block.child_block,
            parent=audited_block.path,
        )

    else:
        pass

# Traverse a stream field's value and yield back each block type in use
def traverse_streamvalue(value, parent=None):
    """Walk model stream value objects to get AuditedBlocks in-use"""

    # This is a block type
    if isinstance(value, BoundBlock):
        path = (
            parent + "." + value.block.name
            if parent is not None
            else value.block.name
        )
        yield path
        yield from traverse_streamvalue(value.value, parent=path)

    # This is a StructValue
    elif isinstance(value, StructValue):
        for child in value.bound_blocks.values():
            yield from traverse_streamvalue(child, parent=parent)

    elif isinstance(value, ListValue):
        for child in value.bound_blocks:
            yield from traverse_streamvalue(child, parent=parent)

    # This is a sequence of blocks
    elif isinstance(value, StreamValue):
        for child in value:
            yield from traverse_streamvalue(child, parent=parent)

class BlockUsageQuerySet(Queryish):
    """Return a QuerySet-like object for querying block type usage"""

    def get_filtered_page_models(self):
        global_page_models = get_page_models()
        page_models = [
            val
            for key, val in self.filters
            if key == "page_model" and val in global_page_models
        ]
        return page_models if len(page_models) > 0 else global_page_models

    def get_filtered_streamfield_names(self, page_model):
        all_streamfields = page_model.get_streamfield_names()
        streamfields = [
            val
            for key, val in self.filters
            if key == "field" and val in all_streamfields
        ]
        return streamfields if len(streamfields) > 0 else all_streamfields

    def audit_blocks_for_page_model(self, page_model):
        # Get the StreamFields on the page model
        streamfields = self.get_filtered_streamfield_names(page_model)

        # A dictionary to hold counts of each block on a page
        page_blocks = {}

        # First populate all available blocks
        for streamfield_name in streamfields:
            streamfield = page_model._meta.get_field(streamfield_name)
            page_blocks[streamfield_name] = {}

            # Traverse child blocks of this stream field (this avpathoids capturing
            # the containing stream block, so we can line-up with stream values
            # below)
            for child_block_name in streamfield.stream_block.child_blocks:
                for audited_block in traverse_streamblock(
                    page_model,
                    streamfield.stream_block.child_blocks[child_block_name],
                ):
                    audited_block.field = streamfield_name
                    page_blocks[streamfield_name][
                        audited_block.path
                    ] = audited_block

        # Get the default Wagtail site (this avoids the Trash)
        site = Site.objects.get(is_default_site=True)

        # Get a queryset for all pages of this type
        page_queryset = page_model.objects.exact_type(page_model)

        # Loop through the queryset, and traverse each streamfield
        for page in page_queryset:
            for streamfield_name in streamfields:
                streamfield_value = getattr(page, streamfield_name)
                streamfield_dict = page_blocks[streamfield_name]

                for block_path in traverse_streamvalue(streamfield_value):
                    # Get the AuditedBlock object for this path
                    audited_block = streamfield_dict[block_path]

                    audited_block.total_occurrences += 1

                    if page not in audited_block.pages:
                        audited_block.pages.append(page)

                        audited_block.pages_count += 1

                        if page.live:
                            audited_block.pages_live_count += 1

                        if page.is_descendant_of(site.root_page):
                            audited_block.pages_in_default_site_count += 1

        return page_blocks

    def run_query(self):
        audited_blocks = []

        for page_model in self.get_filtered_page_models():
            page_blocks = self.audit_blocks_for_page_model(page_model)

            # Flatten the dictionary of dictionaries of blocks to a list and
            # extend the audited block list
            audited_blocks.extend(
                block
                for streamfield, blocks in page_blocks.items()
                for block in blocks.values()
            )

        # self.ordering

        # Slice based on queryset slicing offset/limit
        return audited_blocks[
            self.offset : self.offset + self.limit if self.limit else None
        ]

This then works like a queryset, with filtering and slicing, providing the AuditedBlock dataclass as a result.
from mysite.models import FooPage
queryset = BlockUsageQuerySet().filter(page_model=FooPage, field="content").all()

We're using this to output a simple CSV with a form like:

page_model
field
path
block
occurrences
pages
live
in site

v1.models.learn_page.DocumentDetailPage
sidefoot
related_metadata.content.date
wagtail.blocks.struct_block.StructBlock
1925
1082
1075
1079

v1.models.learn_page.DocumentDetailPage
sidefoot
related_metadata.content.date.heading
wagtail.blocks.field_block.CharBlock
1925
1082
1075
1079

v1.models.learn_page.DocumentDetailPage
sidefoot
related_metadata.content.date.date
wagtail.blocks.field_block.DateBlock
1925
1082
1075
1079

ask_cfpb.models.answer_page.AnswerPage
answer_content
text
wagtail.blocks.struct_block.StructBlock
1821
1715
1418
1710

And so on. Because we're capturing the pages using a block as a list, we can introspect those as well, though right now we're just doing counts.
Emphasizing again that this is very much a proof-of-concept, maybe it's helpful as an alternative that does dive into the JSON?
Right now I don't see this as something that replaces wagtail-inventory either, but complements it, and becomes part of that larger set of audit tools we've been building as we work through what our needs are.
Those other audit tools are around content specifically, like being able to search in blocks, learn their streamfield-migration-compatible paths, etc. I want to do a larger write-up with our content management lead about this whole process of auditing our blocks and content, especially given our Wagtail site has 8 years work of content to wade through now. But we're very far from done.

Wow, thanks so much for sharing that code @willbarton! :tada: :rocket: that is certainly impressive!
It seems like using queryish can indeed be a great alternative. I believe this would allow us to dive into the JSON without resorting to custom/complex SQL, which is what I was kinda hoping to avoid (not necessarily the JSON itself). Bonus points for being portable to other DB backends as well.
For implementing a report like this into Wagtail, I think we would have to divide the approach into two:

First, a piece of work to leverage the queryish package to gather block data in a structure format like you have presented here (pure Wagtail/queryish, no wagtail-inventory of course)
Second, the block types usage report itself -- built on top of this queryish api where we could easily manipulate the data

My only concern would be doing aggregations/annotations on the data. I could be wrong, but I'm not sure that queryish support those yet. In any case, it would be a matter of doing those in pure Python.
@thibaudcolas what do you think? Is this worth exploring as part of Wagtail itself?

FWIW, we've published the block usage and page search audit tools we've been using here: https://github.com/cfpb/wagtail-content-audit
It's still a work-in-progress, and right now the block usage and page search tools are only usable as management commands or directly in code. I still want to wrap them in a report.

Been a while but my take: yes it’s a good fit for Wagtail’s features because StreamField is such a critical part of its approach to content management. From a maintainers’ perspective, I’d worry about whether this can be accomplished within a reasonable code complexity budget, and whether this can be done with compatibility for all databases we support.


improve doc of std.math.sin

Add detail, example, and helpful links.

Is there a good reason the code example isn't a ddoc'd unittest? That ensures it's actually runnable, and actually does what it claims to.

done


Axis Color Band Ranges

As per forum message - https://forum.radzen.com/t/help-with-lineserieschart-needs-highlighted-area-above-and-below/16503
Add ability to create coloured bands on Value Axis.

Hi @paulo-rico,
I think the suggested API is a bit restrictive - it could be more declarative and also support setting both category and value so bands can be horizontally stacked. It can't be set from a property grid as it currently stands - it relies on a collection of objects instead of tags.
I was thinking of something similar to the existing RadzenSeriesValueLine.
<RadzenSeriesBand ValueStart="0" ValueEnd="1000" CategoryStart="January" CategoryEnd="February" Fill="red" />

It could also be called RadzenChartBand as it applies to the whole chart which doesn't currently support multiple axes.
What do you think?

Hi @akorchev
I see what you mean. I read the forum thread and it appeared simple on the face of it. I wasn't aware of the chart overlays. That method does fit this purpose better. It also looks like a learning curve while I see how it all hangs together, so may take a short while.
Until then
Paul


Clarify how to fix ANN101 and ANN102

Description
I have read several times documentation and PEP 484 and PEP 563 but did not get a clear idea how to get rid of these.
It would be very helpful to see any example of fixing this warning.
Please provide a clear & concise description of the proposed feature.
Rationale/Use Case
I've defined a model in Django:
from django.db import models

class Content(models.Model):
    name = models.CharField(max_length=255)

   def __str__(self) -> str:
       return self.name

That gives me a warning ANN101 that self is not annotated. That's strange, while it method of Content class... Okay, let's try this:
from django.db import models
from typing import TypeVar

TContent = TypeVar("TContent", bound="Content")

class Content(models.Model):
    name = models.CharField(max_length=255)

   def __str__(self: TContent) -> str:
       return self.name

Does it suppose to look like this?  (BTW, what is the point of introducing TContent here?)
With this code PyCharm does not recognize self.name as a field defined in a model...
Now I'm wondering whether it is PyCharm issue or something wrong with linter.
At the same time, this code:
from __future__ import annotations
from django.db import models

class Content(models.Model):
    name = models.CharField(max_length=255)

   def __str__(self: Content) -> str:
       return self.name

It works and PyCharm recognizes self.name attribute. But it seems redundant to define it for each method...
Solution
Provide an example how to correctly fix the warnings ANN101 and ANN102. Thank you.

Hello, please see the discussion in #75

I think the frustration comes from this part not clear from documentation. Maybe documentation should be improved (but I have no idea how :-)

There are multiple methods for accomplishing this and you've provided two valid ones, via PEP 484 and PEP 563, in your original post.
The problems seem to be:

PyCharm doesn't resolve a bound TypeVar
The annotations seem redundant

We have no control or influence over the former, and the latter is a decision for you to make.
As discussed in #75:

The purpose of this package is not to enforce the related PEPs, as they make no mandates regarding full annotation coverage. Its purpose is to detect the absence of these annotations; all errors are exposed and we leave it up to the developer to determine what subset of these errors to enforce for their project. This project, for example, currently ignores 6 of its own errors.

Which also references a statement from PEP 484:

In most cases the first argument of class and instance methods does not need to be annotated, and it is assumed to have the type of the containing class for instance methods, and a type object type corresponding to the containing class object for class methods.


Add Microsoft.Net.Compilers.Razor.Toolset

Similar to the Microsoft.Net.Compilers.Toolset package that we use in roslyn, this nuget package will override the generators used by a project, replacing them with the specific versions from this package. The purpose of this package is to allow shipping hotfixes to customers directly in a simple manner, without having to ask them to manually do a bunch of msbuild magic or replacing existing dlls. It may be helpful to reference the targets that add the razor generators to the compilation in the first place when reviewing: https://github.com/dotnet/sdk/blob/main/src/RazorSdk/Targets/Microsoft.NET.Sdk.Razor.SourceGenerators.targets#L15.

@jaredpar any further comments?


Update: sunzongzheng.music version 1.1.2

Removing old versions to reduce clutter
Microsoft Reviewers: Open in CodeFlow

/azp run


[DO-518] How to send payment with Gevamu

@StanG4313 in order to make page published in production, you need to remove .draft postfix from the name of file.


[$1000] An overlapped skeleton UI in the payment details section

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Click on FAB icon
Click on 'Send money'
Enter amount & click on 'Next' button
Search user
Select user
Click on 'I will settle up elsewhere' button
Click on settled up message
Click on the sent money preview component

Expected Result:
The rows of the skeleton UI shouldn't be overlapped
Actual Result:
The rows of the skeleton UI are overlapped
Workaround:
Can the user still use Expensify without this being fixed? Have you informed them of the workaround?
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android / native
[x] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[x] MacOS / Chrome / Safari
[ ] MacOS / Desktop

Version Number: 1.3.17
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation

https://github.com/Expensify/App/assets/43996225/1be061cc-385a-46b8-bdd4-343ac95b8496
https://github.com/Expensify/App/assets/43996225/8aecee92-80a5-4e5a-9fcd-d332370fdd5f
Expensify/Expensify Issue URL:
Issue reported by: @natnael-guchima
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1684499328591959
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01faa2727c8013d2a4
Upwork Job ID:<PHONE_NUMBER>463225856
Last Price Increase: 2023-05-24

Proposal
Please re-state the problem that we are trying to solve in this issue.
An overlapped skeleton UI in the payment details section
What is the root cause of that problem?
The problem came from here:
https://github.com/Expensify/App/blob/b424edcbe7cea7ed5fe36bc5602f6eb4ed1d78bf/src/components/ReportActionsSkeletonView/index.js#L20
When the header view of request money takes a lot of space, Math.celi return a greater number, which make the remaining space couldn't be enough for all the skeleton.
What changes do you think we should make in order to solve the problem?
Instead of using Math.celi, we should use Math.floor to calculate the number of skeleton lines.
What alternative solutions did you explore? (Optional)
N/A.

Proposal
Please re-state the problem that we are trying to solve in this issue.
The skeleton is overlapping in chat page. This is easily noticeable when the height of the chat is small.
What is the root cause of that problem?
I have encountered the same issue while creating a skeleton loader for LHN here. There is an explanation why that happen, but in short, the problem happens because the total height of all skeleton item is bigger than the height of it's container and we are using flex 1 in the container. (Removing the flex 1 will solve the overlap, but will push down the footer)
What changes do you think we should make in order to solve the problem?

We can use the same solution here which is to wrap the skeleton with a plain View here.
https://github.com/Expensify/App/blob/5cb2b745c52cedb0fd7ae64c0c438953a7d952b0/src/components/ReportActionsSkeletonView/index.js#L53
This will allow the skeleton to overflow.

@hungvu193 Thanks for the proposal. Your RCA makes sense but I think it's intended to use ceil and round up to the closest integer. Otherwise we will see empty space.

@bernhardoj Thanks for the proposal. Your RCA makes sense as well. Wrapping the skeletonview with a View looks good to me. However I have a question, I can reproduce the bug just for a brief period (or when offline) where the scrollbar is not visible. Then once getting back online the scrollbar is visible and no overlap is seen in this case. Any idea what is that about?
Even if we wrap the skeletonview within a View you will still notice that the scrollbar is missing.

Offline
Online

That's weird. The skeleton shouldn't be scrollable because the overflow is hidden. I'm guessing the skeleton you see when back online is from the footer of ReportActionsList. https://github.com/Expensify/App/blob/7a42755a79737314edf702ce17bf0647dd8c41fb/src/pages/home/report/ReportActionsList.js#L159-L178

@hungvu193 Thanks for the proposal. Your RCA makes sense but I think it's intended to use ceil and round up to the closest integer. Otherwise we will see empty space.

We can wrap the skeleton with View and use justify content center, we can reduce the space and it looks just ok.
https://github.com/Expensify/App/assets/16502320/8f8b19ce-e606-4c61-ab9c-5e269c9918c7

@bernhardoj Thanks for the quick follow up. That seems unrelated to this issue. Let's go with your solution :rocket:.
:ribbon: :eyes: :ribbon: C+ reviewed
cc @dangrous

Yep this looks good to me!

Hired everyone via Upwork 👍

PR is reviewed, merged and on Staging

The PR that introduced the bug has been identified: This seems to be an issue that existed since day one https://github.com/Expensify/App/pull/8042
The offending PR has been commented on: https://github.com/Expensify/App/pull/8042#discussion_r1209606444
A discussion in #expensify-bugs has been started: https://expensify.slack.com/archives/C049HHMV9SM/p1685407519069379
Determine if we should create a regression test for this bug: No

Hm @shawnborton what do you think? For payment details chats, should the skeleton UI be aligned to the bottom (like the chats actually show up) or to the top (like other chats)? Could sort of go either way.

I don't feel strongly either, I would say let's just be consistent with what we do with other chats.

Oops, I never actually made the issue. To confirm the plan - @shawnborton - Should I create an issue to make the payment details skeleton UI aligned to the top to match how we see other chats?

I guess at this point a payment details view is just a thread, and a thread is just another kind of chat. So yeah, whatever we do with other chats, we should be consistent with the payment details. Let me know if that's helpful!

See linked issue!


Make FakeEtcdClient prune TTL'd entries properly.

LGTM w/ one nit.

Updated and squashed it (only diff with previous is the "explicit").


test/utils: make assorted functions private

Make tests/utils.go slightly shorter by moving several functions away from it.
Checklist
This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

[x] Design: A design document was considered and is present (link) or not required
[x] PR: The PR description is expressive enough and will help future contributors
[x] Code: Write code that humans can understand and Keep it simple
[x] Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
[x] Upgrade: Impact of this change on upgrade flows was considered and addressed if required
[x] Testing: New code requires new unit tests. New features and bug fixes require at least on e2e test
[x] Documentation: A user-guide update was considered and is present (link) or not required. You want a user-guide update if it's a user facing feature / API change.
[x] Community: Announcement to kubevirt-dev was considered

Release note:
NONE

/hold

I think the compute jobs are failing on the same tests.

/hold cancel
I dropped 2a2109fb61 99daf071 , I hope to fix them later.

/test pull-kubevirt-e2e-k8s-1.28-sig-compute

/cc @fossedihelm

/sig code-quality

/hold
I'm missing something basic, sorry for the noise.

/test pull-kubevirt-build

/test pull-kubevirt-build

/test pull-kubevirt-e2e-k8s-1.28-sig-compute

/test pull-kubevirt-e2e-k8s-1.28-sig-compute

/hold cancel
much much thinner PR


Does not work with Tailwind config option "important: true"

Or it doesn't write !importants into the finished css.

Only utility classes receive !important with the important option set. This plugin provides component classes, so they don't respect the important option. This is to make sure you can override the styles provided by these classes using utilities.


If the registered username or password has an integer, the login would not let it pass

If the registered username or password has an integer, the login would not let it pass.
To Reproduce Steps to reproduce the behavior:
Go to 'Register and have a username or password that has an integer'
Click on Register and try to login the account
See error (the login would not let it pass)
It should accept the username and password that the user entered

Resolve on #10


bump kerlescan to 0.55

Secure Coding Practices Checklist Link

https://github.com/RedHatInsights/secure-coding-checklist

Secure Coding Checklist

[ ] Input Validation
[ ] Output Encoding
[ ] Authentication and Password Management
[ ] Session Management
[ ] Access Control
[ ] Cryptographic Practices
[ ] Error Handling and Logging
[ ] Data Protection
[ ] Communication Security
[ ] System Configuration
[ ] Database Security
[ ] File Management
[ ] Memory Management
[ ] General Coding Practices

Secure Coding Practices Checklist Link
* https://github.com/RedHatInsights/secure-coding-checklist

Secure Coding Checklist
* [ ]  Input Validation

* [ ]  Output Encoding

* [ ]  Authentication and Password Management

* [ ]  Session Management

* [ ]  Access Control

* [ ]  Cryptographic Practices

* [ ]  Error Handling and Logging

* [ ]  Data Protection

* [ ]  Communication Security

* [ ]  System Configuration

* [ ]  Database Security

* [ ]  File Management

* [ ]  Memory Management

* [ ]  General Coding Practices

I think you are supposed to check these items in the checklist to make sure that you reviewed them when you submitted the PR.

Secure Coding Practices Checklist Link
* https://github.com/RedHatInsights/secure-coding-checklist

Secure Coding Checklist
* [ ]  Input Validation

* [ ]  Output Encoding

* [ ]  Authentication and Password Management

* [ ]  Session Management

* [ ]  Access Control

* [ ]  Cryptographic Practices

* [ ]  Error Handling and Logging

* [ ]  Data Protection

* [ ]  Communication Security

* [ ]  System Configuration

* [ ]  Database Security

* [ ]  File Management

* [ ]  Memory Management

* [ ]  General Coding Practices

I think you are supposed to check these items in the checklist to make sure that you reviewed them when you submitted the PR.

I think we are, too.  But this was just a version change of a dependency.  There was no code in the PR.  Plus I'm trying to get back to focusing on FedRAMP stuff and this detour keeps getting longer!

I think we are, too. But this was just a version change of a dependency. There was no code in the PR. Plus I'm trying to get back to focusing on FedRAMP stuff and this detour keeps getting longer!

I went ahead and checked all the items on the checklist.


Fix "Can't use $exists with Moment" error with mongoose 4.7.9

For more information check issue mongoose#4937.
In this PR there is also another change which I applied more than a year ago I think for the checkRequired issue. The approach used differs a bit from the solution applied in this project, but I tried to consider also the case for invalid moments.

Cool, thank you @gastonelhordoy. I will get this merged in and published.

Merged into master and published to NPM as 0.1.3.


fix: remove package-lock from packages

What it does:

Removes package-lock.json from individual packages. <- Trust me this is a good thing.
Adds the --no-ci flag to lerna bootstrap. This ensures cipm (the ci npm tool) is not used. cipm does not like when there is no package-lock.json

Let's merge! Then I can rebase my PR on this one.


Make JNI string conversions behave like ObjC string conversions

When a C++ std::string contains invalid UTF-8, the result is an empty string when trying to pass it to ObjC. For JNI, it caused an exception. For consistency, I would like encoding errors to result in empty strings in JNI as well.

Hi @jb-gcx,
Thanks for the contribution!  This is an area I had hesitated for a long time.
On one hand,  I kind of want to make programming errors stand out more so that they could be corrected earlier.  Passing invalid characters as string is one of them,  binary objects should be passed using the binary type.  Changing the string to something else (such as empty string) may allow this kind of errors to slip past testing.
On the other hand,  I understand it could be annoying when simply passing a string argument may require the caller to handle potential encoding errors.
I can't decided which is better,  convenience or strictness.
Also,  if you just want to return a fallback string when there is an encoding error, std::wstring_convert's constructor lets you pass byte_error and wide_error that will be used in case of error instead of throwing.

Thanks for the response @LiFengSC !
Regarding your worries about errors slipping past, I absolutely agree. I much prefer them to be visible in general.
The reason I feel confident about this change is that iOS already behaves this way. There are arguments for either style of dealing with errors, but I think the most important thing is to use the same style between platforms.
To be consistent, the options are:

Change iOS to generate hard errors when encoding fails -> this is a change that will break existing user code at runtime, probably crashing their apps
Change Android to fallback to empty strings like iOS does -> this will only break code that relied on exceptions being produced, which I would expect to be a very small minority, and it won't cause crashes

Lastly, about the byte_error and wide_error: this was my first approach, but it did not work. I think wstring_convert checks whether they're set by just checking if they're non-empty. Since we want to return empty strings, wstring_convert decides to throw instead. Cppreference is pretty unclear about this behavior, but here's a godbold to demonstrate.


Feature Request: Support Google Sheets

Supporting google sheets?
I think it would be interesting for the provider to support manipulation of online googlesheet data
https://www.google.com/sheets/about/
what do you think :)

It might be nice to have a google sheet provider. However, the way it works would be completely different from the ExcelProvider as the ExcelProvider works by manipulating the XLSX file whereas with Google Sheets you would have to work with some kind of online google api's so it  does not make sense to implement as part of the ExcelProvider.


Error parsing FLEX API error response

Hello,
when I tried to run your jsp-microform example, I've encountered the following exception:
org.apache.jasper.JasperException: An exception occurred processing [/index.jsp] at line [80]
...
javax.servlet.ServletException: com.cybersource.flex.sdk.exception.FlexSDKInternalException: Error parsing FLEX API error response: [responseStatus is expected]
...
I am using:
Java 1.8.0_112
Tomcat 8.5.47
Maven 3.3.9 (pom.xml specifies version 3.2.0)
JS Flex Microform lib 0.4.0
flex-server-sdk 0.3.0
I've followed the instructions in README.md for build and setup of the example.
I kindly ask you for further advice.

Check your actual response from the HttpClient. I had the same issue, but when I debugged it turn out to be an authentication error(401). During the non successful cases, the HttpClient doesn't return the "responseStatus".

Any updates?

We managed to make Flex microform work as expected.
What I would advise to anyone, who runs into a similar issue, is to double check all of the fields which are posted to CyberSource services. Fields should be properly signed, declared, values must be valid etc... Alo merchant keys and credentials must be properly setup, otherwise errors can be expected, as @manoharan0308 mentioned.
I think it's worth mentioning to look at how merchant profile is configured on CyberSource business backend, so that everything is properly configured in order for Flex microform to work (which fields are required etc...).
I hope this helps anyone who's struggling with this integration.
I'm closing this thread since we were able to resolve it.


dynamic bs input model error

I use tool to analyse onnx model meet the error:
Traceback (most recent call last):
File "onnx_dynamic_analyse.py", line 92, in
onnx_tool.model_profile(model, input, savenode=save_path, hidden_ops=[])
File "/usr/local/lib/python3.8/site-packages/onnx_tool/init.py", line 84, in model_profile
g.shape_infer(dynamic_shapes)
File "/usr/local/lib/python3.8/site-packages/onnx_tool/graph.py", line 828, in shape_infer
oshapes = node.shape_infer(itensors)
File "/usr/local/lib/python3.8/site-packages/onnx_tool/node.py", line 2056, in shape_infer
assert raw == volume(newshape)
AssertionError
please help，thx!

Hi, your problem is a model-related problem. In this case, either you need to share the model file with me, or you need to find out which op's shape inference result is wrong.


Allow Chunk to disable preserving keys

Allow Collection chunk to take a second optional parameter for preserving keys.

There are cases where you want to chunk your collection and reset the keys instead of preserving it. The default PHP array_chunk function have this second argument.

By default, it will be true so this is fully backward compatible.

This unfortunately is a breaking change to the methods signatures. Please send to master.


fix(connlib): bind new channel to peer if needed

Initially, when we receive a new candidate from a remote peer, we bind a channel for each remote address on the relay that we sampled. This ensures that every possible communication path is actually functioning. In ICE, all candidates are tried against each other, meaning the remote will attempt to send from each of their candidates to every one of ours, including our relay candidates. To allow this traffic, a channel needs to be bound first.
For various reasons, an allocation might become stale or needs to be otherwise invalidated. In that case, all the channel bindings are lost but there might still be an active connection that wants to utilise them. In that case, we will see "No channel" warnings like https://firezone-inc.sentry.io/issues/6036662614/events/f8375883fd3243a4afbb27c36f253e23/.
To fix this, we use the attempt to encode a message for a channel as an intent to bind a new one. This is deemed safe because wanting to encode a message to a peer as a channel data message means we want such a channel to exist. The first message here is still dropped but that is better than not establishing the channel at all.

Connection intents but for turn messages. Makes sense.

Yep! I had the same realisation after my first attempt of solving there where I was going to just silence the error :)


Coverage Incorrect for Async Method using Linq

Latest of everything:
- netcoreapp3.1
- coverlet.collector 1.2.0 / coverlet.msbuild 2.8.0 (both have the same issue)
- Microsoft.NET.Test.Sdk 16.5.0
- NUnit 3.12.0
- NUnit3TestAdapter 13.16.1

If an async method uses Linq, coverage for all lines except the linq line(s) will be missing. Thus all other lines in the method are implied as uncoverable.
The following solution reproduces the issue and has the output file which shows the issue.
CoverletExample.zip
To reproduce, perform the following command:
dotnet test ExampleTest.csproj --configuration Release --collect:"XPlat Code Coverage"
The class in question:
public class ExampleClass
    {
        public async Task DoSomethingAsync(IEnumerable<object> objects)
        {
            await Task.Delay(TimeSpan.FromMilliseconds(1));
            foreach (var o in objects)
            {
                Console.WriteLine(o);
            }
        }

        public async Task DoSomethingAsyncWithLinq(IEnumerable<object> objects)
        {
            await Task.Delay(TimeSpan.FromMilliseconds(1));
            var selected = objects.Select(o => o);
            foreach (var o in selected)
            {
                Console.WriteLine(o);
            }
        }

        public void DoSomethingSync(IEnumerable<object> objects)
        {
            foreach (var o in objects)
            {
                Console.WriteLine(o);
            }
        }

        public void DoSomethingSyncWithLinq(IEnumerable<object> objects)
        {
            var selected = objects.Select(o => o);
            foreach (var o in selected)
            {
                Console.WriteLine(o);
            }
        }

Each method has a basic test passing it 1000 objects. Note that in the output all lines except for those in the method "DoSomethingAsyncWithLinq" are correctly reported. For the method "DoSomethingAsyncWithLinq", only the Linq line var selected = objects.Select(o => o); is reported:
<class name="Example.ExampleClass/<>c" filename="ExampleClass.cs" line-rate="1" branch-rate="1" complexity="2">
          <methods>
            <method name="<DoSomethingAsyncWithLinq>b__1_0" signature="(System.Object)" line-rate="1" branch-rate="1">
              <lines>
                <line number="22" hits="1001" branch="True" condition-coverage="100% (2/2)">
                  <conditions>
                    <condition number="126" type="jump" coverage="100%" />
                  </conditions>
                </line>
              </lines>
            </method>
          </methods>
          <lines>
            <line number="22" hits="1001" branch="True" condition-coverage="100% (2/2)">
              <conditions>
                <condition number="126" type="jump" coverage="100%" />
              </conditions>
            </line>
          </lines>
        </class>

Also, in all cases the linq statement is listed to have been hit an equivalent number of times to the number of objects (or number of objects + 1), and the foreach statement is listed as being hit double that number of times. Not sure if this is correct behavior. But this is not a big deal for us as we don't really care about hit numbers.

Thank's for reporting this, we'll come back asap.

cc @matteoerigozzi

@zmhh before starting with investigation can you try with nightly build?We did some fix on master for async state machines https://github.com/tonerdo/coverlet/blob/master/Documentation/ConsumeNightlyBuild.md

The output for the example solution was exactly the same for nightly version 1.2.29-gd2f0fd2248.

Ok thank a lot for tests we'll take a look asap

I confirm the strange behaviour, seem a bug.

The same issue occurs in Debug configuration, just fyi.

yep @zmhh it's unrelated

Hi, we encountered similar issue after upgrading to coverlet.msbuild 2.8. Coverage being shown as partial for await statements. (similar behaviour with .Net core 2.2 and 3.1). We resolved it by downgrading back to coverlet.msbuild 2.7 which we were previously using without issues.
(Thanks for this great project btw)

We are also encountering this issue.
2.7 seems to work fine

Guys we fixed the bug...can someone give it a try using nightly build tomorrow? https://github.com/tonerdo/coverlet/blob/master/Documentation/ConsumeNightlyBuild.md
Thank's a lot to all for the help!Really appreciated.

Does nightly only work for the MSBuild package? The issue appears to remain the same using the example posted in the original post with the nightly "coverlet.collector" Version="1.2.36-g54e576f75d".

Edit: It appears I tried to use the nightly before it was produced. Will check again for the updated package later.

Yep will be build at midnight...try tomorrow.

Using nightly version 1.2.38-g34d6dc5ff6 and the example given in the original post, the issue seems unchanged.

Glad to hear!


Add support for x64 packed promote low

Both of these patches have been tested against the spec tests (though simd_conversions.wast is currently disabled).

@jlb6740, I think we also need to document what will live in the upper lanes of an f32x4 when we fdemote an f64x2 to a f32x4--are they zeroed? Are the lanes untouched?


Censyipv4 launches too many tasks

Censyipv4 ended up launching 100 tasks when it was only supposed to launch 20. I manually stopped them and disabled the scan on staging. We should see why this is happening -- perhaps some issues with the scheduler logic.

Sometimes get this error:

{"message":"Rate exceeded.","code":"ThrottlingException","time":"2020-08-04T15:01:23.788Z","requestId":"f3f30ed0-123c-47b7-a0af-02ec469787b3","statusCode":400,"retryable":true}
--


Hard to read results when there are many matches on a line

Not sure if this has come up, but for this case it's tough to parse the results because:

The text in the results changes for every entry, making it harder to realize the match is on the same line
It takes up a lot of vertical space

Might be worth exploring merging them into a single line and selecting all the matches on that line when you click?

It has come up before, I don't want to do that because it will result in matches being hidden, 1 row per match is probably easier for the user, and now you should try our new search editor which has the behavior you expect 😁


file-upload: maxFiles prop bug fix

Previously, the maxFiles prop would only restrict the number of files that can be selected in a single drop of files. It would not restrict files from being selected one at a time.
This bug fix now looks at the total number of files that have been selected, not just the number of files that were in the last drop from Drop Zone.
View preview
Checklist
Preflight

[x] Prefix the PR title with the slug of the package or component - e.g. accordion: Updated padding or docs: Updated header links
[x] Describe the changes clearly in the PR description
[x] Read and check your code before tagging someone for review
[x] Create a changeset file by running yarn changeset. Learn more about change management.

Testing

[x] Manually test component in various modern browsers at various sizes (use Browserstack)
[x] ~Manually test component in various devices (phone, tablet, desktop)~
[x] Manually test component using a keyboard
[x] Manually test component using a screen reader
[x] ~Manually tested in dark mode~
[x] Component meets Web Content Accessibility Guidelines (WCAG) 2.1 standards
[x] Add any necessary unit tests (HTML validation, snapshots etc)
[x] Run yarn test to ensure tests are passing. If required, run yarn test -u to update any generated snapshots.

Documentation

[x] Create or update documentation on the website
[x] ~Create or update stories for Storybook~
[x] ~Create or update stories for Playroom snippets~

Review comment from @adrian-yee
===
great work so far!
I think the error response for maxfiles={3} is better with only the files exceeding the limit getting the error treatment.
However, I think we need to maintain visibility in the docs of the existing code snippet for maxFiles={3} if possible (shown below). We should also edit the hint on the new Multiple files component example to 'Upload a maximum of three files' (unless that was a temporary inclusion to demo the prop behaviour?)

Bug: accepted files error is not adding the "too many files" error to the list if files are added after the invalid file is added

We should break-word the file name since they can be long

We should also have a "singular" version of the error, because "following files" etc isn't correct

Apparently it's not a new issue, but I personally don't think that the drop zone region should be everything, including the error message and valid files. That feels weird to me. Would be good to hear from the designers

I just dropped the same invalid files over and over and it doesn't clear the list of errors, so you get duplicates


Prevent publishing of pallet_contracts for now

For the same reasons as stated in #7494 we want to hold off publishing new version of pallet_contracts until we are done with breaking changes and are ready for 3.0.0-rcX.

bot merge

bot merge


Issue: Qdrant Retrieval Not Including Similarity Scores

Title: QdrantVectorStore Not Returning Similarity Scores with Documents
Details:
Encountering an issue with the QdrantVectorStore in LangChain where the similaritySearchVectorWithScore method does not return similarity scores alongside the retrieved documents. The expected behavior, based on the method's naming and typical usage, is to receive a similarity score per document, essential for evaluating the relevance of each result. Currently, these scores are absent in the retrieval output. Seeking clarification on whether this is a bug or a missing feature, and how to enable or rectify this for accurate relevance assessment in document retrieval.

Any update?


Sensors Not Correctly Dispalyed

My listed Sensors in AlienFx-Fan does not correspond to what is in my registry. Registry Entries are below and .png shows what is displayed in AlienFx-Fan.
"SensorName-0-0"="ESIF sensor 1"
"SensorName-0-1"="ESIF sensor 2"
"SensorName-0-2"="ESIF sensor 3"
"SensorName-0-3"="ESIF sensor 4"
"SensorName-0-4"="ESIF sensor 5"
"SensorName-0-5"="ESIF sensor 6"
"SensorName-0-6"="ESIF sensor 7"
"SensorName-1-1"="CPU Internal Thermistor"
"SensorName-1-6"="GPU Internal Thermistor"
"SensorName-2-0"="SSD sensor 1"
"SensorName-2-1"="SSD sensor 2"

This means you lost ESIF sensors, but it was into the system before.
ESIF sensor data provided by Intel DPTF (Dynamic Tuning Framework driver), so make sure you have it installed.
Also, some DPTF drivers do not provide this data to system (just collect and use inside the driver), so better check you have drivers from Dell's support site, not from Intel one (or just find one which provide it).
How to check you have DPTF data? Open perfmon, select "Performance monitor", press "+" button. Then the list populated, look for "ESIFDeviceInformation" entry. In case it presents into the list, all work correctly.

Hello,
In PERFMONITOR, I do not have ESIF Entry. Goes from Energy Meter to Event Log, skipping ESIF.
I reinstalled Intel-Dynamic-Tuning-Intel-Dynamic-Tuning-Driver_90GWR_WIN64_8.7.10600.20700_A12.EXE from DELL site and observed No Change in my display.
Also used [alienfx-tools.msi] to reinstall AlienFx as opposed to the .zip and still No Change.

As i said, some DPTF does not support it.
You can try fan_sdk_v1,zip version (READ README FIRST!), but i don't sure it supports fan control at your system.

Your program has been supporting my laptop since I started using it months ago. Now, why suddenly it just stops supporting it?
It is a relatively new Alienware m17 R4 with i7-10870H, RTX 3070.

V1 is older SDK and some models not supported. But AFAIR R4 is.

Why would I have to resort to using V1 when laptop previously running fine on most up to date version? What has changed?

Good:

You will have more sensors
Lower CPU usage for fan control
Bad:
Antivirus will be crazy about it

BTW, i check this - yes, R4 is supported.

Thank you for this information but I think I will pass. When you UPDATE your software is when I notice inconsistencies creep in or things get broken. Kindly recall most of my previous issues were observed after an update. This current issue just "popped up" out of now where after my computer has been fine for many months. I do not think a 10th Generation cpu is that old to need V1 SDK. Once. I suggested separate versions in order to avoid this, however, you wrote that you  wish to maintain commonality and I understand and respect that. I will download previous versions to see if any one of them still work. If not, then I will continue using current version as my fans do reliably respond to the visible sensors. Thank you.

Sir, I wanted you to see my CPU & GPU Temps while running MSFS 2020 in a 29 degree Celsius room. I could not have achieved these values without your software as I have played this game for the past year and I know what temps have been. I am grateful for all of your work. Thank you. Maybe if I can find the V1 SDK, I will give it a try.

Repair installed W11 and now all sensors are visible. I suspect that it was my W11 install and not your software causing issues. Apologies. Thank you.


Orekit validation first approach

This pull request is a first approach to poliastro's validation path. It makes use of the Orekit python wrapper and implements the following features:

A class under the name OrekitOrbit, who's usage is similar to poliastro's Orbit class. Both of them try to model Keplerian orbits, which can be defined from vectors or classic orbital elements.

A simple test regarding the conversion between RV and COE.

:warning: Orekit does not provide functions like rv2coe or coe2rv, since conversion is done directly in each of the available constructors of the KeplerianOrbit class in the Orekit library :warning:
Also notice the addition of the orekit-data.zip file, which holds necessary data for Orekit to properly work: ephemeris, time files... We might discuss if this data should be included within this repo or final user is required to download it from official channels.

We might discuss if this data should be included within this repo or final user is required to download it from official channels.

Let's not put it in the repo :pray: Otherwise it will make the whole git history too sluggish. If it's a common Orekit thing we can point to the relevant documentation, or even provide a script to download it.
I'll take a look at this tomorrow!

I just saw that the Orekit wrapper provides a download data function.
On the other hand, if the setup_orekit_dir() does not find the orekit-data.zip file in the local directory, en error message is shown but no exception is raised. This is weird when trying to manage program workflow...

Some updates on this PR regarding previous suggestions and feedback
I came up with the following structure:
orekit/
├── README.md
├── requirements.txt
├── src/
└── tests/

The src/ directory holds all logical files while the tests/ one is devoted to validation unit tests. In addition, a pytest.ini and conftest.py files are placed under this last folder, so anyone can run the tests following the same configuration.
Regarding orekit-data.zip:

Let's not put it in the repo pray Otherwise it will make the whole git history too sluggish. If it's a common Orekit thing we can point to the relevant documentation, or even provide a script to download it.

Now, there exists a setup_orekit_env() function under src/utils.py which checks if data is available in local machine. If not, it automatically downloads it from official sources and points orekit internals to data location, which I selected to be within src/data/.

Sorry, I just forgot to update the README.md installation section guide. I will solve for this this night.

I just added a propagate() method and its corresponding validation test, which passes without any problem. I think with all these features, we are ready to start building more complex tests such us maneuvers validation.

Merging! Thanks @jorgepiloto for taking this up and the patience 💪🏽

Oh, my bad... I now see that we merged orekit-data.zip here.

:warning: HISTORY OF THIS PULL REQUEST HAS BEEN REWRITTEN :warning:


Snap HUD markers to the edges of the screen

When say the prograde vector marker on the HUD enters a position which is off-screen, it should be replaced with an arrow, pointing to the true direction of the marker, and snap the arrow to some box within the current app window.
Other similar HUD elements should follow the same rule.

The prograde marker has been clamped to a maximum distance from the ship (center screen)
Also changed the marker from a crosshair to an arrow, which looks better I think.