[Bug]: Crash / Segfault on window drag

Before you make the issue, confirm that

[X] You are running the master build from GitHub actions
[X] You have read the FAQ and the usage instructions
[X] You have searched pull requests and issues and have found none similar to your issue
[X] This problem comes from a failure in the tiling system and not a missing feature

Describe the bug
Hold shift + drag window crashes kwin about 50% of the time. On Plasma 6.0.0, kernel 6.7.6-arch1-2 (64-bit).
To reproduce
Hold shift, drag window.
Expected behavior
No crash.
Relevant log output
Mar 02 11:29:06 archlinux kwin_wayland[81800]: qml: Polonium DBG: Client google-chrome was moved out of a tile
Mar 02 11:29:06 archlinux kwin_wayland[81800]: qml: Polonium DBG: Removing client google-chrome from desktops {"desktop":"bc38e9c1-1cf4-4c87-85ab-3a934332bcf1","activity":"7b24ca0e-97d2-4415-abb7-673e0bffae17","output":"DP-8"}
Mar 02 11:29:06 archlinux kwin_wayland[81800]: qml: Polonium DBG: Rebuilding layout for desktops {"desktop":"bc38e9c1-1cf4-4c87-85ab-3a934332bcf1","activity":"7b24ca0e-97d2-4415-abb7-673e0bffae17","output":"DP-8"}
Mar 02 11:29:06 archlinux kernel: kwin_wayland[81800]: segfault at 62fa4bce8bd0 ip 000062fa4bce8bd0 sp 00007ffdc9ae03e8 error 15 likely on CPU 15 (core 7, socket 0)
Mar 02 11:29:06 archlinux kernel: Code: 22 00 3a 00 22 00 44 00 50 00 2d 00 38 00 22 00 7d 00 00 00 10 4c fa 62 00 00 30 04 00 00 00 00 00 00 a1 00 00 00 00 00 00 00 <00> 00 00 00 00 00 00 00 00 00 00 00 00 00 1d 9e e7 fd e7 9a 16 00
Mar 02 11:29:06 archlinux systemd[1]: Started Process Core Dump (PID 82963/UID 0).
Mar 02 11:29:06 archlinux systemd[1]: Started Pass systemd-coredump journal entries to relevant user for potential DrKonqi handling.
Mar 02 11:29:06 archlinux systemd-coredump[82964]: [🡕] Process 81800 (kwin_wayland) of user 1000 dumped core.

                                                   Stack trace of thread 81800:
                                                   #0  0x000062fa4bce8bd0 n/a (n/a + 0x0)
                                                   ELF object binary architecture: AMD x86-64
Mar 02 11:29:07 archlinux systemd[1]<EMAIL_ADDRESS>Deactivated successfully.
Mar 02 11:29:07 archlinux plasmashell[82356]: Gdk-Message: 11:29:07.092: Error reading events from display: Broken pipe
Mar 02 11:29:07 archlinux kwin_wayland_wrapper[81938]: (EE) failed to read Wayland events: Broken pipe
Mar 02 11:29:07 archlinux drkonqi[80738]: The Wayland connection broke. Did the Wayland compositor die?
Mar 02 11:29:07 archlinux drkonqi[80738]: qt.qpa.wayland: Attempting wayland reconnect
Mar 02 11:29:07 archlinux dolphin[24258]: The Wayland connection broke. Did the Wayland compositor die?
Mar 02 11:29:07 archlinux konsole[82895]: The Wayland connection broke. Did the Wayland compositor die?
Mar 02 11:29:07 archlinux dolphin[24258]: qt.qpa.wayland: Attempting wayland reconnect
Mar 02 11:29:07 archlinux konsole[82895]: qt.qpa.wayland: Attempting wayland reconnect
Mar 02 11:29:07 archlinux plasmashell[81832]: The Wayland connection broke. Did the Wayland compositor die?
Mar 02 11:29:07 archlinux polkit-kde-authentication-agent-1[8818]: The Wayland connection broke. Did the Wayland compositor die?
Mar 02 11:29:07 archlinux polkit-kde-authentication-agent-1[8818]: qt.qpa.wayland: Attempting wayland reconnect
Mar 02 11:29:07 archlinux kwalletd6[8551]: The Wayland connection broke. Did the Wayland compositor die?
Mar 02 11:29:07 archlinux kwalletd6[8551]: qt.qpa.wayland: Attempting wayland reconnect
Mar 02 11:29:07 archlinux baloorunner[9298]: The Wayland connection broke. Did the Wayland compositor die?
Mar 02 11:29:07 archlinux DiscoverNotifier[8953]: The Wayland connection broke. Did the Wayland compositor die?
Mar 02 11:29:07 archlinux baloorunner[9298]: qt.qpa.wayland: Attempting wayland reconnect
Mar 02 11:29:07 archlinux DiscoverNotifier[8953]: qt.qpa.wayland: Attempting wayland reconnect
Mar 02 11:29:07 archlinux konsole[82895]: Failed to write to the pipe: Bad file descriptor.
Mar 02 11:29:07 archlinux baloorunner[9298]: Failed to write to the pipe: Bad file descriptor.
Mar 02 11:29:07 archlinux konsole[82895]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash
Mar 02 11:29:07 archlinux baloorunner[9298]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash
Mar 02 11:29:07 archlinux polkit-kde-authentication-agent-1[8818]: Failed to write to the pipe: Bad file descriptor.
Mar 02 11:29:07 archlinux polkit-kde-authentication-agent-1[8818]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash
Mar 02 11:29:07 archlinux kwalletd6[8551]: Failed to write to the pipe: Bad file descriptor.
Mar 02 11:29:07 archlinux kwalletd6[8551]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash
Mar 02 11:29:07 archlinux drkonqi[80738]: Failed to write to the pipe: Bad file descriptor.
Mar 02 11:29:07 archlinux DiscoverNotifier[8953]: Failed to write to the pipe: Bad file descriptor.
Mar 02 11:29:07 archlinux dolphin[24258]: Failed to write to the pipe: Bad file descriptor.
Mar 02 11:29:07 archlinux drkonqi[80738]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash
Mar 02 11:29:07 archlinux DiscoverNotifier[8953]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash
Mar 02 11:29:07 archlinux org_kde_powerdevil[8819]: The Wayland connection broke. Did the Wayland compositor die?
Mar 02 11:29:07 archlinux dolphin[24258]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash
Mar 02 11:29:07 archlinux org_kde_powerdevil[8819]: qt.qpa.wayland: Attempting wayland reconnect
Mar 02 11:29:07 archlinux kactivitymanagerd[8815]: The Wayland connection broke. Did the Wayland compositor die?
Mar 02 11:29:07 archlinux kactivitymanagerd[8815]: qt.qpa.wayland: Attempting wayland reconnect
Mar 02 11:29:07 archlinux org_kde_powerdevil[8819]: Failed to write to the pipe: Bad file descriptor.
Mar 02 11:29:07 archlinux org_kde_powerdevil[8819]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash
Mar 02 11:29:07 archlinux kded6[8716]: The Wayland connection broke. Did the Wayland compositor die?
Mar 02 11:29:07 archlinux kded6[8716]: qt.qpa.wayland: Attempting wayland reconnect
Mar 02 11:29:07 archlinux kded6[8716]: Failed to write to the pipe: Bad file descriptor.
Mar 02 11:29:07 archlinux kded6[8716]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash
Mar 02 11:29:07 archlinux kactivitymanagerd[8815]: Failed to write to the pipe: Bad file descriptor.
Mar 02 11:29:07 archlinux kactivitymanagerd[8815]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash
Mar 02 11:29:07 archlinux drkonqi[81836]: The Wayland connection broke. Did the Wayland compositor die?
Mar 02 11:29:07 archlinux drkonqi[81836]: qt.qpa.wayland: Attempting wayland reconnect
Mar 02 11:29:07 archlinux drkonqi[81836]: Failed to write to the pipe: Bad file descriptor.
Mar 02 11:29:07 archlinux drkonqi[81836]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash
Mar 02 11:29:07 archlinux xembedsniproxy[81833]: The X11 connection broke (error 1). Did the X11 server die?
Mar 02 11:29:07 archlinux gmenudbusmenuproxy[81831]: The X11 connection broke (error 1). Did the X11 server die?
Mar 02 11:29:07 archlinux systemd[910]: plasma-gmenudbusmenuproxy.service: Main process exited, code=exited, status=1/FAILURE
Mar 02 11:29:07 archlinux systemd[910]: plasma-gmenudbusmenuproxy.service: Failed with result 'exit-code'.
Mar 02 11:29:07 archlinux systemd[910]: plasma-xembedsniproxy.service: Main process exited, code=exited, status=1/FAILURE
Mar 02 11:29:07 archlinux systemd[910]: plasma-xembedsniproxy.service: Failed with result 'exit-code'.
Mar 02 11:29:07 archlinux kioworker[82273]: Failed to write to the pipe: Bad file descriptor.
Mar 02 11:29:07 archlinux systemd[910]: plasma-plasmashell.service: Main process exited, code=exited, status=255/EXCEPTION
Mar 02 11:29:07 archlinux systemd[910]: plasma-plasmashell.service: Failed with result 'exit-code'.
Mar 02 11:29:07 archlinux systemd[910]: plasma-plasmashell.service: Consumed 4.903s CPU time.
Mar 02 11:29:07 archlinux kernel: ecryptfs_write_inode_size_to_header: Error writing file size to header; rc = [-4]
Mar 02 11:29:07 archlinux kernel: Error writing inode size to metadata; rc = [-4]
Mar 02 11:29:07 archlinux kwin_wayland[82969]: No backend specified, automatically choosing drm
Mar 02 11:29:07 archlinux kernel: [drm] Send DSC disable to synaptics
Mar 02 11:29:07 archlinux drkonqi-coredump-processor[82965]: "/usr/bin/kwin_wayland" 81800 "/var/lib/systemd/coredump/core.kwin_wayland.1000.0a90c8d638bb43f3b468792c3f174a99.81800.1709396946000000.zst"
Mar 02 11:29:07 archlinux systemd[910]: plasma-plasmashell.service: Scheduled restart job, restart counter is at 3.
Mar 02 11:29:07 archlinux systemd[910]: plasma-xembedsniproxy.service: Scheduled restart job, restart counter is at 3.
Mar 02 11:29:07 archlinux systemd[910]: plasma-gmenudbusmenuproxy.service: Scheduled restart job, restart counter is at 3.
Mar 02 11:29:07 archlinux systemd[910]: Started Launch DrKonqi for a systemd-coredump crash (PID 82965/UID 0).
Mar 02 11:29:07 archlinux systemd[910]: Started Proxies GTK DBus menus to a Plasma readable format.
Mar 02 11:29:07 archlinux systemd[910]: Starting KDE Plasma Workspace...
Mar 02 11:29:07 archlinux systemd[910]: Started Handle legacy xembed system tray icons.
Mar 02 11:29:07 archlinux drkonqi-coredump-launcher[83003]: Unable to find file for pid 81800 expected at "kcrash-metadata/kwin_wayland.0a90c8d638bb43f3b468792c3f174a99.81800.ini"
Mar 02 11:29:07 archlinux systemd[1]<EMAIL_ADDRESS>Deactivated successfully.
Mar 02 11:29:08 archlinux kwin_wayland[82969]: could not create a component for  "org.kde.spectacle.desktop"
Mar 02 11:29:08 archlinux kwin_wayland[82969]: OpenGL vendor string:                   AMD
Mar 02 11:29:08 archlinux kwin_wayland[82969]: OpenGL renderer string:                 AMD Radeon Graphics (radeonsi, rembrandt, LLVM 16.0.6, DRM 3.57, 6.7.6-arch1-2)
Mar 02 11:29:08 archlinux kwin_wayland[82969]: OpenGL version string:                  4.6 (Core Profile) Mesa 24.0.2-arch1.1
Mar 02 11:29:08 archlinux kwin_wayland[82969]: OpenGL shading language version string: 4.60
Mar 02 11:29:08 archlinux kwin_wayland[82969]: Driver:                                 Unknown
Mar 02 11:29:08 archlinux kwin_wayland[82969]: GPU class:                              Unknown
Mar 02 11:29:08 archlinux kwin_wayland[82969]: OpenGL version:                         4.6
Mar 02 11:29:08 archlinux kwin_wayland[82969]: GLSL version:                           4.60
Mar 02 11:29:08 archlinux kwin_wayland[82969]: Mesa version:                           24.0.2
Mar 02 11:29:08 archlinux kwin_wayland[82969]: Requires strict binding:                no
Mar 02 11:29:08 archlinux kwin_wayland[82969]: Virtual Machine:                        no
Mar 02 11:29:08 archlinux kwin_wayland[82969]: Timer query support:                    yes
Mar 02 11:29:08 archlinux kwin_wayland[82969]: KPackageStructure of KPluginMetaData(pluginId:"alwaysopenonactivescreen", fileName: "/home/sam/.local/share/kwin/scripts/alwaysopenonactivescreen/metadata.json") does not match requested format "KWin/Script"
Mar 02 11:29:08 archlinux kwin_wayland[82969]: qt.qml.typeresolution.cycle: Cyclic dependency detected between "qrc:/qt/qml/org/kde/desktop/private/TextFieldContextMenu.qml" and "qrc:/qt/qml/org/kde/desktop/MenuItem.qml"
Mar 02 11:29:08 archlinux kwin_wayland[82969]: qml: Polonium INF: Polonium started!
Mar 02 11:29:08 archlinux kwin_wayland[82969]: qml: Polonium DBG: Config is {"debug":true,"tilePopups":false,"filterProcess":["krunner","yakuake","kded","polkit","plasmashell","org.kde.plasmashell"],"filterCaption":[""],"timerDelay":102,"keepTiledBelow":false,"borders":3,"maximizeSingle":false,"resizeAmount":10,"engineType":0,"insertionPoint":1,"rotateLayout":false}
Mar 02 11:29:08 archlinux kwin_wayland_wrapper[83113]: (WW) Option "-listen" for file descriptors is deprecated
Mar 02 11:29:08 archlinux kwin_wayland_wrapper[83113]: Please use "-listenfd" instead.
Mar 02 11:29:08 archlinux kwin_wayland_wrapper[83113]: (WW) Option "-listen" for file descriptors is deprecated
Mar 02 11:29:08 archlinux kwin_wayland_wrapper[83113]: Please use "-listenfd" instead.
Mar 02 11:29:09 archlinux kernel: [drm] Send DSC enable to synaptics
Mar 02 11:29:09 archlinux systemd[910]: app-google\x2dchrome\x20\x283\x29-4401e9c2002c4281ab3678208c61d776.scope: Consumed 39.184s CPU time.
Mar 02 11:29:09 archlinux kwin_wayland_wrapper[83178]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Mar 02 11:29:09 archlinux kwin_wayland_wrapper[83178]: > Warning:          Could not resolve keysym XF86CameraAccessEnable
Mar 02 11:29:09 archlinux kwin_wayland_wrapper[83178]: > Warning:          Could not resolve keysym XF86CameraAccessDisable
Mar 02 11:29:09 archlinux kwin_wayland_wrapper[83178]: > Warning:          Could not resolve keysym XF86CameraAccessToggle
Mar 02 11:29:09 archlinux kwin_wayland_wrapper[83178]: > Warning:          Could not resolve keysym XF86NextElement
Mar 02 11:29:09 archlinux kwin_wayland_wrapper[83178]: > Warning:          Could not resolve keysym XF86PreviousElement
Mar 02 11:29:09 archlinux kwin_wayland_wrapper[83178]: > Warning:          Could not resolve keysym XF86AutopilotEngageToggle
Mar 02 11:29:09 archlinux kwin_wayland_wrapper[83178]: > Warning:          Could not resolve keysym XF86MarkWaypoint
Mar 02 11:29:09 archlinux kwin_wayland_wrapper[83178]: > Warning:          Could not resolve keysym XF86Sos
Mar 02 11:29:09 archlinux kwin_wayland_wrapper[83178]: > Warning:          Could not resolve keysym XF86NavChart
Mar 02 11:29:09 archlinux kwin_wayland_wrapper[83178]: > Warning:          Could not resolve keysym XF86FishingChart
Mar 02 11:29:09 archlinux kwin_wayland_wrapper[83178]: > Warning:          Could not resolve keysym XF86SingleRangeRadar
Mar 02 11:29:09 archlinux kwin_wayland_wrapper[83178]: > Warning:          Could not resolve keysym XF86DualRangeRadar
Mar 02 11:29:09 archlinux kwin_wayland_wrapper[83178]: > Warning:          Could not resolve keysym XF86RadarOverlay
Mar 02 11:29:09 archlinux kwin_wayland_wrapper[83178]: > Warning:          Could not resolve keysym XF86TraditionalSonar
Mar 02 11:29:09 archlinux kwin_wayland_wrapper[83178]: > Warning:          Could not resolve keysym XF86ClearvuSonar
Mar 02 11:29:09 archlinux kwin_wayland_wrapper[83178]: > Warning:          Could not resolve keysym XF86SidevuSonar
Mar 02 11:29:09 archlinux kwin_wayland_wrapper[83178]: > Warning:          Could not resolve keysym XF86NavInfo
Mar 02 11:29:09 archlinux kwin_wayland_wrapper[83178]: Errors from xkbcomp are not fatal to the X server
Mar 02 11:29:09 archlinux kwin_wayland[82969]: kf.windowsystem: static bool KX11Extras::mapViewport() may only be used on X11
Mar 02 11:29:09 archlinux kwin_wayland_wrapper[83207]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Mar 02 11:29:09 archlinux kwin_wayland_wrapper[83207]: > Warning:          Unsupported maximum keycode 708, clipping.
Mar 02 11:29:09 archlinux kwin_wayland_wrapper[83207]: >                   X11 cannot support keycodes above 255.
Mar 02 11:29:09 archlinux kwin_wayland_wrapper[83207]: > Warning:          Could not resolve keysym XF86CameraAccessEnable
Mar 02 11:29:09 archlinux kwin_wayland_wrapper[83207]: > Warning:          Could not resolve keysym XF86CameraAccessDisable
Mar 02 11:29:09 archlinux kwin_wayland_wrapper[83207]: > Warning:          Could not resolve keysym XF86CameraAccessToggle
Mar 02 11:29:09 archlinux kwin_wayland_wrapper[83207]: > Warning:          Could not resolve keysym XF86NextElement
Mar 02 11:29:09 archlinux kwin_wayland_wrapper[83207]: > Warning:          Could not resolve keysym XF86PreviousElement
Mar 02 11:29:09 archlinux kwin_wayland_wrapper[83207]: > Warning:          Could not resolve keysym XF86AutopilotEngageToggle
Mar 02 11:29:09 archlinux kwin_wayland_wrapper[83207]: > Warning:          Could not resolve keysym XF86MarkWaypoint
Mar 02 11:29:09 archlinux kwin_wayland_wrapper[83207]: > Warning:          Could not resolve keysym XF86Sos
Mar 02 11:29:09 archlinux kwin_wayland_wrapper[83207]: > Warning:          Could not resolve keysym XF86NavChart
Mar 02 11:29:09 archlinux kwin_wayland_wrapper[83207]: > Warning:          Could not resolve keysym XF86FishingChart
Mar 02 11:29:09 archlinux kwin_wayland_wrapper[83207]: > Warning:          Could not resolve keysym XF86SingleRangeRadar
Mar 02 11:29:09 archlinux kwin_wayland_wrapper[83207]: > Warning:          Could not resolve keysym XF86DualRangeRadar
Mar 02 11:29:09 archlinux kwin_wayland_wrapper[83207]: > Warning:          Could not resolve keysym XF86RadarOverlay
Mar 02 11:29:09 archlinux kwin_wayland_wrapper[83207]: > Warning:          Could not resolve keysym XF86TraditionalSonar
Mar 02 11:29:09 archlinux kwin_wayland_wrapper[83207]: > Warning:          Could not resolve keysym XF86ClearvuSonar
Mar 02 11:29:09 archlinux kwin_wayland_wrapper[83207]: > Warning:          Could not resolve keysym XF86SidevuSonar
Mar 02 11:29:09 archlinux kwin_wayland_wrapper[83207]: > Warning:          Could not resolve keysym XF86NavInfo
Mar 02 11:29:09 archlinux kwin_wayland_wrapper[83207]: Errors from xkbcomp are not fatal to the X server
Mar 02 11:29:09 archlinux drkonqi[83007]: kf5idletime_wayland: This plugin does not support polling idle time
Mar 02 11:29:09 archlinux kcminit[83219]: Initializing  "/usr/lib/qt6/plugins/plasma/kcms/systemsettings/kcm_fonts.so"
Mar 02 11:29:09 archlinux kcminit[83219]: Initializing  "/usr/lib/qt6/plugins/plasma/kcms/systemsettings/kcm_style.so"
Mar 02 11:29:09 archlinux systemd[910]: Started KDE Plasma Workspace.
Mar 02 11:29:09 archlinux plasmashell[83005]: KPackageStructure of KPluginMetaData(pluginId:"com.github.zren.commandoutput", fileName: "/home/sam/.local/share/plasma/plasmoids/com.github.zren.commandoutput/metadata.json") does not match requested format "Plasma/Applet"
Mar 02 11:29:09 archlinux plasmashell[83005]: KPackageStructure of KPluginMetaData(pluginId:"org.kde.shutdownOrSwitch", fileName: "/home/sam/.local/share/plasma/plasmoids/org.kde.shutdownOrSwitch/metadata.json") does not match requested format "Plasma/Applet"
Mar 02 11:29:09 archlinux plasmashell[83005]: KPackageStructure of KPluginMetaData(pluginId:"org.zayronxio.vector.clock", fileName: "/home/sam/.local/share/plasma/plasmoids/org.zayronxio.vector.clock/metadata.json") does not match requested format "Plasma/Applet"
Mar 02 11:29:09 archlinux plasmashell[83005]: KPackageStructure of KPluginMetaData(pluginId:"org.kde.Date.Bubble", fileName: "/home/sam/.local/share/plasma/plasmoids/org.kde.Date.Bubble/metadata.json") does not match requested format "Plasma/Applet"
Mar 02 11:29:09 archlinux kded6[8716]: Registering ":1.317/StatusNotifierItem" to system tray
Mar 02 11:29:09 archlinux plasmashell[83005]: kf.plasma.quick: Applet preload policy set to 1
Mar 02 11:29:09 archlinux plasmashell[83005]: file:///usr/share/plasma/plasmoids/org.kde.desktopcontainment/contents/ui/main.qml:196:25: QML FolderViewDropArea (parent or ancestor of QQuickLayoutAttached): Binding loop detected for property "minimumWidth"
Mar 02 11:29:09 archlinux plasmashell[83005]: qt.qml.typeresolution.cycle: Cyclic dependency detected between "qrc:/qt/qml/org/kde/desktop/private/TextFieldContextMenu.qml" and "qrc:/qt/qml/org/kde/desktop/MenuItem.qml"
Mar 02 11:29:09 archlinux plasmashell[83005]: file:///usr/share/plasma/wallpapers/org.kde.image/contents/ui/main.qml:14:1: QML WallpaperItem: grabToImage: item's window is not visible
Mar 02 11:29:10 archlinux plasmashell[83005]: kde.plasma.activitiesstats: [Error at ResultSetPrivate::initQuery]:  QSqlError("11", "Unable to fetch row", "database disk image is malformed")
Mar 02 11:29:10 archlinux kwin_wayland[82969]: qml: Polonium DBG: Creating new engine for desktop {"desktop":"bc38e9c1-1cf4-4c87-85ab-3a934332bcf1","activity":"7b24ca0e-97d2-4415-abb7-673e0bffae17","output":"DP-8"}
Mar 02 11:29:10 archlinux kwin_wayland[82969]: qml: Polonium DBG: Creating new engine for desktop {"desktop":"a3170b24-26eb-4b7a-9e3f-3db4922f325b","activity":"7b24ca0e-97d2-4415-abb7-673e0bffae17","output":"DP-8"}
Mar 02 11:29:10 archlinux kwin_wayland[82969]: qml: Polonium DBG: Creating new engine for desktop {"desktop":"c1cf1b40-84ea-43a9-90e4-d6020b5ccdc9","activity":"7b24ca0e-97d2-4415-abb7-673e0bffae17","output":"DP-8"}
Mar 02 11:29:10 archlinux kwin_wayland[82969]: qml: Polonium DBG: Creating new engine for desktop {"desktop":"b3334e8a-92ce-427e-9e2c-6284b83732e0","activity":"7b24ca0e-97d2-4415-abb7-673e0bffae17","output":"DP-8"}
Mar 02 11:29:10 archlinux kwin_wayland[82969]: qml: Polonium DBG: Creating new engine for desktop {"desktop":"cd9a9eae-7755-4d2d-ae7e-8a4684e223bc","activity":"7b24ca0e-97d2-4415-abb7-673e0bffae17","output":"DP-8"}
Mar 02 11:29:10 archlinux kwin_wayland[82969]: qml: Polonium DBG: Creating new engine for desktop {"desktop":"86e15fd1-d604-4224-bdcc-7cf9dca573d8","activity":"7b24ca0e-97d2-4415-abb7-673e0bffae17","output":"DP-8"}
Mar 02 11:29:10 archlinux kwin_wayland[82969]: qml: Polonium DBG: Creating new engine for desktop {"desktop":"85a0e810-e9f2-4694-b912-fb89420ad63d","activity":"7b24ca0e-97d2-4415-abb7-673e0bffae17","output":"DP-8"}
Mar 02 11:29:10 archlinux kwin_wayland[82969]: qml: Polonium DBG: Creating new engine for desktop {"desktop":"a3c4c598-3d67-41bf-ae83-ed4f13642708","activity":"7b24ca0e-97d2-4415-abb7-673e0bffae17","output":"DP-8"}
Mar 02 11:29:10 archlinux kwin_wayland[82969]: qml: Polonium DBG: Creating new engine for desktop {"desktop":"bc38e9c1-1cf4-4c87-85ab-3a934332bcf1","activity":"13555a41-2c1a-488d-bdb1-d38051de7fc0","output":"DP-8"}
Mar 02 11:29:10 archlinux kwin_wayland[82969]: qml: Polonium DBG: Creating new engine for desktop {"desktop":"a3170b24-26eb-4b7a-9e3f-3db4922f325b","activity":"13555a41-2c1a-488d-bdb1-d38051de7fc0","output":"DP-8"}
Mar 02 11:29:10 archlinux kwin_wayland[82969]: qml: Polonium DBG: Creating new engine for desktop {"desktop":"c1cf1b40-84ea-43a9-90e4-d6020b5ccdc9","activity":"13555a41-2c1a-488d-bdb1-d38051de7fc0","output":"DP-8"}
Mar 02 11:29:10 archlinux kwin_wayland[82969]: qml: Polonium DBG: Creating new engine for desktop {"desktop":"b3334e8a-92ce-427e-9e2c-6284b83732e0","activity":"13555a41-2c1a-488d-bdb1-d38051de7fc0","output":"DP-8"}
Mar 02 11:29:10 archlinux kwin_wayland[82969]: qml: Polonium DBG: Creating new engine for desktop {"desktop":"cd9a9eae-7755-4d2d-ae7e-8a4684e223bc","activity":"13555a41-2c1a-488d-bdb1-d38051de7fc0","output":"DP-8"}
Mar 02 11:29:10 archlinux kwin_wayland[82969]: qml: Polonium DBG: Creating new engine for desktop {"desktop":"86e15fd1-d604-4224-bdcc-7cf9dca573d8","activity":"13555a41-2c1a-488d-bdb1-d38051de7fc0","output":"DP-8"}
Mar 02 11:29:10 archlinux kwin_wayland[82969]: qml: Polonium DBG: Creating new engine for desktop {"desktop":"85a0e810-e9f2-4694-b912-fb89420ad63d","activity":"13555a41-2c1a-488d-bdb1-d38051de7fc0","output":"DP-8"}
Mar 02 11:29:10 archlinux kwin_wayland[82969]: qml: Polonium DBG: Creating new engine for desktop {"desktop":"a3c4c598-3d67-41bf-ae83-ed4f13642708","activity":"13555a41-2c1a-488d-bdb1-d38051de7fc0","output":"DP-8"}
Mar 02 11:29:10 archlinux plasmashell[83005]: kde.plasma.activitiesstats: [Error at ResultSetPrivate::initQuery]:  QSqlError("11", "Unable to fetch row", "database disk image is malformed")
Mar 02 11:29:10 archlinux plasmashell[83005]: kde.plasma.activitiesstats: [Error at ResultSetPrivate::initQuery]:  QSqlError("11", "Unable to fetch row", "database disk image is malformed")
Mar 02 11:29:10 archlinux plasmashell[83005]: kde.plasma.activitiesstats: [Error at ResultSetPrivate::initQuery]:  QSqlError("11", "Unable to fetch row", "database disk image is malformed")
Mar 02 11:29:10 archlinux plasmashell[83005]: kde.plasma.activitiesstats: [Error at ResultSetPrivate::initQuery]:  QSqlError("11", "Unable to fetch row", "database disk image is malformed")
Mar 02 11:29:10 archlinux plasmashell[83005]: file:///usr/share/plasma/plasmoids/org.kde.plasma.private.systemtray/contents/ui/main.qml:162:21: QML KSortFilterProxyModel: Binding loop detected for property "sourceModel"
Mar 02 11:29:10 archlinux plasmashell[83005]: file:///usr/share/plasma/plasmoids/org.kde.plasma.private.systemtray/contents/ui/main.qml:162:21: QML KSortFilterProxyModel: Binding loop detected for property "sourceModel"
Mar 02 11:29:10 archlinux plasmashell[83005]: qt.qml.typeresolution.cycle: Cyclic dependency detected between "file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/global/Globals.qml" and "file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/ThumbnailStrip.qml"
Mar 02 11:29:10 archlinux plasmashell[83005]: qt.qml.typeresolution.cycle: Cyclic dependency detected between "file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/global/Globals.qml" and "file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/NotificationHeader.qml"
Mar 02 11:29:10 archlinux plasmashell[83005]: qml: SystemTray ItemLoader: Invalid state, cannot determine source!
Mar 02 11:29:10 archlinux xembedsniproxy[83006]: Qt: Session management error: Could not open network socket
Mar 02 11:29:10 archlinux gmenudbusmenuproxy[83004]: Qt: Session management error: Could not open network socket
Mar 02 11:29:10 archlinux plasmashell[83005]: qt.dbus.integration: Could not connect "org.cups.cupsd.Notifier" to PrinterFinishingsChanged(QString, QString, QString, uint, QString, bool) :
Mar 02 11:29:10 archlinux plasmashell[83005]: qrc:/qt/qml/org/kde/kirigamiaddons/components/Avatar.qml:201:9: QML QQuickImage: Error decoding: qrc:/qt/qml/org/kde/kirigamiaddons/components/Avatar.qml?timestamp=1709396950766: Unsupported image format
Mar 02 11:29:10 archlinux plasmashell[83005]: qrc:/qt/qml/org/kde/kirigamiaddons/components/Avatar.qml:201:9: QML QQuickImage: Error decoding: qrc:/qt/qml/org/kde/kirigamiaddons/components/Avatar.qml?timestamp=1709396950766: Unsupported image format
Mar 02 11:29:10 archlinux plasmashell[83005]: qrc:/qt/qml/org/kde/kirigamiaddons/components/Avatar.qml:201:9: QML QQuickImage: Error decoding: qrc:/qt/qml/org/kde/kirigamiaddons/components/Avatar.qml?timestamp=1709396950766: Unsupported image format
Mar 02 11:29:10 archlinux systemd[910]: Started<EMAIL_ADDRESS>Mar 02 11:29:10 archlinux plasmashell[83005]: The cached device pixel ratio value was stale on window expose.  Please file a QTBUG which explains how to reproduce.
Mar 02 11:29:10 archlinux plasmashell[83005]: QFont::setPointSizeF: Point size <= 0 (0.000000), must be greater than 0
Mar 02 11:29:10 archlinux kwin_wayland[82969]: qml: Polonium DBG: Window plasmashell hooked into script
Mar 02 11:29:10 archlinux kwin_wayland[82969]: qml: Polonium DBG: Not tiling window plasmashell

Screenshots and videos
No response
Additional context
No response

This is a known issue right now. There doesn't really seem to be a cause. Core dumps from the remove window call on the tiles and the resulting set tile signal from the window. The signal should be deflected in the script by buildingLayout, and it probably is. Note that Plasma 6 is also in an early release state right now, so this may just be a temporary Kwin bug.

Ok thanks. I'll report to kwin if it doesn't get fixed by the time Plasma 6 is stable.

Not sure if that's related, but I've just had a catastrophic crash of polonium/Kwin that brought down all applications - on Kwin it only "untiles" them, but on Wayland it brought everything down.
This happened when dragging an mpv window (which forces a window size).

Reopening this as there will probably be quite a few bug reports about this issue. Probably will pin as well.

Further testing indicates that the crashes are neither predictable nor preventable with the current tiling code. It's strange how basically the same logic flow worked well in Plasma 5. As of now, this issue is a firm KWin bug and a large amount of the features of the engine will be cripped because of it. (Any time KWin crashes, it's almost certainly a KWin bug because no script should be able to crash the compositor)

i'm having the same issue on arch using the latest polonium AUR build (plasma 6)

It makes sense that Polonium would crash much more. Bismuth doesn't use the Kwin API nearly as much as Polonium, and Polonium also uses lots of features that could be considered experimental or new. Plasma 6 probably is also much less stable right now than Plasma 5.
The key issue here is that Polonium shouldn't be able to crash Kwin. If Javascript could crash a browser, there would be security vulnerabilities possible in every website. If a Python interpreter could core dump due to a script being ran, an attacker could exploit the system. Any crash in any script in Kwin needs to be fixed upstream.

It makes sense that Polonium would crash much more. Bismuth doesn't use the Kwin API nearly as much as Polonium, and Polonium also uses lots of features that could be considered experimental or new. Plasma 6 probably is also much less stable right now than Plasma 5.
The key issue here is that Polonium shouldn't be able to crash Kwin. If Javascript could crash a browser, there would be security vulnerabilities possible in every website. If a Python interpreter could core dump due to a script being ran, an attacker could exploit the system. Any crash in any script in Kwin needs to be fixed upstream.

so realistically the issue here is that kwin isn't handling window move events from scripts properly which is causing it to crash?

Core dump traces the crash back to the removeWindow function of the tiles, which happens when a tile is deleted, a tile's client is set to null, or a client's tile is set to null.

So... Where is the upstream bug report?

So... Where is the upstream bug report?

I thought the original author of the issue said they'd file a bug report, so I haven't personally filed one yet.

Will do today.

So... Where is the upstream bug report?

Here is what I found : https://invent.kde.org/plasma/kwin/-/commit/0ca7b40da0457e1ee5ce079d78d304c76b7592b5
It is quite similar to my case, the crash often happens when I try to drag or minimize a tiled window.

This commit actually indicates what may be the root of the problem. In Plasma 5, if a tile is deleted, the window manager does not attempt to put the window back into a suitable tile. Plasma 6 seems to try to do this, but the way Polonium works is by deleting all of the tiles on the screen to rebuild the layout. It seems like a conflict between the scripting layer and tile manager in Plasma 6 is probably causing the issue. If I had to guess, there's also probably a concurrency bug with this as well (given the random incidence of failure and my knowledge of how Qt handles running scripts)

In Polonium v1.0 for Plasma 5, the tile change callback waits on the engine to register the change before acting, which also might be why the issue is more prevalent in Plasma 6.

In Polonium v1.0 for Plasma 5, the tile change callback waits on the engine to register the change before acting, which also might be why the issue is more prevalent in Plasma 6.

yeah i did find that bismuth and polonium would both occasionally crash my wayland desktop on plasma 5, however this was also a problem with many other programs and segfaults seemed random (I suspect latte dock also had something to do with it), but plasma 6 consistently crashes with poloniun

So... Where is the upstream bug report?

I've looked at the kwin repo and there don't seem to be any issues created relating to this so I might go an add one

EDIT: there's a report on kde's bugzilla about the issue so no need

Oops, just posted mine. Do you have a link?
https://bugs.kde.org/show_bug.cgi?id=482757

Quickest way to reproduce this on my system - if you have an nvidia card and blender:

DRI_PRIME=pci-0000_01_00_0 __GLX_VENDOR_LIBRARY_NAME=nvidia blender
Drag that window
Crash

Quickest way to reproduce this on my system - if you have an nvidia card and blender:
1. `DRI_PRIME=pci-0000_01_00_0 __GLX_VENDOR_LIBRARY_NAME=nvidia blender`

2. Drag that window

3. Crash

from my experience crashing it has been as simple as opening two terminals that are tiled (so one appears on the left and one on the right) and dragging the one on the left to the right. it seems to crash my desktop almost every time.

I think I'm getting to the root of this problem.
Kwin sends out signals for things like tile changes before it actually changes the tile. This can cause race issues as Kwin tries to update the tile layout while Polonium is working or has already finished rebuilding the layout. This can lead to assigning null for tiles, removing windows from nonexistant tiles, and creating tiles that don't exist.
I really don't know a way around this. I'll keep experimenting with timers, but those seem to be inconsistent as well.

I think I'm getting to the root of this problem.
Kwin sends out signals for things like tile changes before it actually changes the tile. This can cause race issues as Kwin tries to update the tile layout while Polonium is working or has already finished rebuilding the layout. This can lead to assigning null for tiles, removing windows from nonexistant tiles, and creating tiles that don't exist.
I really don't know a way around this. I'll keep experimenting with timers, but those seem to be inconsistent as well.

I've been using the latest git commit for the last 30 mins or so, no crashes so far, looking good :+1:
Just one question, is it possible to move tiled windows around with meta+drag rather than keyboard shortcuts?
on the usage section of the website it says that you can hold shift while moving windows, however when I try this, it simply overlaps the window already positioned there? I'm not sure if this is a bug or just me being incompetent

I think I'm getting to the root of this problem.
Kwin sends out signals for things like tile changes before it actually changes the tile. This can cause race issues as Kwin tries to update the tile layout while Polonium is working or has already finished rebuilding the layout. This can lead to assigning null for tiles, removing windows from nonexistant tiles, and creating tiles that don't exist.
I really don't know a way around this. I'll keep experimenting with timers, but those seem to be inconsistent as well.

Sir, a recent kwin update (6.0.1) seems to have affected tileChanged(). Dragging a window does not trigger tileChanged()->rebuildLayout(), which causes the tile to be left empty instead of rebuilding the layout to accommodate the dragged window.
I also tried the previous version without the timer and it no longer causes a crash.

I think I'm getting to the root of this problem.
Kwin sends out signals for things like tile changes before it actually changes the tile. This can cause race issues as Kwin tries to update the tile layout while Polonium is working or has already finished rebuilding the layout. This can lead to assigning null for tiles, removing windows from nonexistant tiles, and creating tiles that don't exist.
I really don't know a way around this. I'll keep experimenting with timers, but those seem to be inconsistent as well.

Sir, a recent kwin update (6.0.1) seems to have affected tileChanged(). Dragging a window does not trigger tileChanged()->rebuildLayout(), which causes the tile to be left empty instead of rebuilding the layout to accommodate the dragged window.
I also tried the previous version without the timer and it no longer causes a crash
found solution, add moveResizedChanged()
window.moveResizedChanged.connect(this.moveResizedChanged.bind(this));

    moveResizedChanged(): void {
        this.logger.debug("moveResizedChanged()")
        if (this.ctrl.driverManager.buildingLayout) return;
        if(this.window.move) {
            this.ctrl.driverManager.removeWindow(this.window);
            this.ctrl.driverManager.rebuildLayout();
        }
    }

before the fix it still crashed on 6.0.1 for me, that is the first version that released on the official arch stable repos right?

before the fix it still crashed on 6.0.1 for me, that is the first version that released on the official arch stable repos right?

kwin 6.0.1-3  2024-03-10 10:00 UTC

I remember back in kwin-autotile when frameGeometryChanged used to be used to manage tiles. It was slow, inconsistent, and not pragmatically correct. moveResizedChanged would almost be worse, as I assume it only triggers when the user manually moves the window. Would it even trigger if a window is placed in a tile by the engine?
tileChanged was close to being perfect. If the qml signal was called after the internal Kwin engine manages everything, it would be issueless. Why would Kwin regress their own API?
Needless to say, solutions are still being explored. The horizon dims every day.

moveResizedChanged would almost be worse, as I assume it only triggers when the user manually moves the window. Would it even trigger if a window is placed in a tile by the engine?

This only gives me a temporary solution of being able to drag a window out of a tile into a float, I'm just a noob. 😂
Use this way to drag a window out of a tile, the size and position will be changed by rebuildLayout, now I'm using a very simple method to keep it in its original size and position.
    interactiveMoveResizeStarted(): void {
        if (this.ctrl.driverManager.buildingLayout) return;
        if (this.window.move) {
            this.ctrl.driverManager.removeWindow(this.window);
        }
    }

    interactiveMoveResizeFinished(): void {
        if (this.ctrl.driverManager.buildingLayout) return;
        if (this.ctrl.windowExtensions.get(this.window)!.isTiled == false) {
            var originalX = this.window.x;
            var originalY = this.window.y;
            var originalWidth = this.window.width;
            var originalHight = this.window.height;
            this.ctrl.driverManager.rebuildLayout();
            this.window.frameGeometry.width = originalWidth;
            this.window.frameGeometry.height = originalHight;
            this.window.frameGeometry.x = originalX;
            this.window.frameGeometry.y = originalY;
        }
    }

I also found that this code will cause strange padding to be added to the full-screen window when you switch between desktops. Maybe additional judgment window.fullScreen is needed in the padding part.
https://github.com/zeroxoneafour/polonium/blob/0416e4e2c056dd1264a28547a79b4f8aba2e03e8/src/controller/actions/basic.ts#L93-L98
All in all, I really like this tilling script, thank you very much for your work and I hope you can come up with a better solution!

The issue is with dragging windows into tiles. There are a few different ways Kwin puts windows into tiles (an example is quick tiling) that may not all trigger a move resize event, or may not trigger it at the time necessary for Kwin to respond.
I'll look into this solution over the weekend and see how it works out with the more complex callbacks.

@zeroxoneafour kwin dev here. we are trying to figure out why kwin crashes, but we have troubles reproducing the crash in the first place. if you have some details that can help us, please join https://webchat.kde.org/#/room/#kwin:kde.org

upstream crash report just in case https://crash-reports.kde.org/organizations/kde/issues/7450

Joined the matrix server and posted https://github.com/zeroxoneafour/kwin-crasher there

https://invent.kde.org/plasma/kwin/-/merge_requests/5493 A possible upstream fix has been found. Seems like a simple and non-controversial pr, so hopefully its merged and released soon.

I experience the same behavior when using the kwin shortcut for "Move Window One Screen to the Left/Right" - based on what I read here, I suspect it's from the same root cause and I shouldn't open an issue, right? I am running the latest nightly build (was running v1.0b1 before with same behavior)

It has been merged. We should expect the fix to come on Plasma 6.0.4 I guess.

It has been merged. We should expect the fix to come on Plasma 6.0.4 I guess.

I didn´t expect this to be fixed on 6.0.3 since the merge happened the same day of release. However, dragging is 100% working here without issues. Anyone else have tried?

I didn't see anything about the fix on the release notes. Still waiting for Arch to update the repos.

The fix is released under v<IP_ADDRESS>. See this

The fix is released under v<IP_ADDRESS>. See this

just installed kwin 6.0.3-1 from the testing repos (manually curled > sudo pacman -U) then rebooted but it made no difference
trying to move a window still guarantees a segfault.
can confirm

kwin_wayland --version
does return kwin 6.0.1

not sure what's going on tbh

just installed the latest kwin 6.0.3-1

6.0.3 OR <IP_ADDRESS>?

The fix is released under v<IP_ADDRESS>. See this

just installed the latest kwin 6.0.3-1 from the testing repos (manually curled > sudo pacman -U) then rebooted but it made no difference trying to move a window still guarantees a segfault.
can confirm

kwin_wayland --version

does return kwin 6.0.3 anyone got it working?

Same, installed the 6.0.3-1 package, crash still occurs, kwin_wayland --version returns 6.0.3. Maybe they didn't update the version string? Or could it be a packaging mistake? (I assume it's automated).

It's a packaging mistake, I marked the kwin package in extra-testing as out of date so it should be fixed sooner or later

Can confirm that the issue is definitely fixed in v<IP_ADDRESS>. If you have v<IP_ADDRESS> installed and you know for certain that it is installed, try the latest commit and see if it works.

Finally can close this now, any issues with dragging should be reported as separate bugs

I'm so glad this has been solved 🎉


Enhance virtual camera sensor for SITL testing

The new camera capabilities exchange/setting features needs to be fully tested. The only practical way to do this would be with a virtual camera sensor that can exhaustively test the possible options. This also allows the options to be exercised on the QGC side as well.

We already have support for a camera and gimbal in Gazebo SITL on the Typhoon H480 model.

@mcabir Then we would need to extend it to support options being set from the new work Gus has been doing for the Camera API

@mcharleb To do this we should create a camera base library. It should hook into here: https://github.com/PX4/sitl_gazebo/blob/master/src/gazebo_gst_camera_plugin.cpp

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 30 days. Feel free to reopen this issue if you deem it appropriate.
(This is an automated comment from GitMate.io.)

This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a temporary error. The following address(es) deferred:
<EMAIL_ADDRESS>Domain evercl.com has exceeded the max emails per hour (204/200 (102%)) allowed.  Message will be reattempted later
------- This is a copy of the message, including all the headers. ------
Received: from o6.sgmail.github.com ([<IP_ADDRESS>]:5593)
by apollo.graphium.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128)
(Exim 4.89_1)
(envelope-from<EMAIL_ADDRESS>id 1eoU6g-0007ie-KY
for<EMAIL_ADDRESS>Wed, 21 Feb 2018 08:06:46 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com;
h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe;
s=s20150108; bh=u4P+PMdcOklKUlQYe50Yjt3Tb+E=; b=ql4WTkzrkZXyLJV0
Ci6T/YevTZK45Za3DWJwXdEdLG35aOoylnbUCaafICo6muHuuQ2HWy2mw8/Q71o0
99JEvBhfmanzG0aTTtrsf+qabvlyib++SMAGcIqaGa72cg4WPQpZQmi9hiiOMWuM
lYSkPnZZKRNfBYyAk/6ha8Ytkak=
Received: by filter0283p1iad2.sendgrid.net with SMTP id filter0283p1iad2-22476-5A8D6E45-18
2018-02-21 13:04:05.654511193 +0000 UTC
Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2b-ext-cp1-prd.iad.github.net [<IP_ADDRESS>])
by ismtpd0001p1iad1.sendgrid.net (SG) with ESMTP id 3FlYp5c7SJi2zJJooaShHg
for<EMAIL_ADDRESS>Wed, 21 Feb 2018 13:04:05.505 +0000 (UTC)
Date: Wed, 21 Feb 2018 13:04:05 +0000 (UTC)
From: PX4 Build Bot<EMAIL_ADDRESS>Reply-To: PX4/Firmware<EMAIL_ADDRESS>To: PX4/Firmware<EMAIL_ADDRESS>Cc: Subscribed<EMAIL_ADDRESS>Message-ID<EMAIL_ADDRESS>In-Reply-To<EMAIL_ADDRESS>References<EMAIL_ADDRESS>Subject: Re: [PX4/Firmware] Enhance virtual camera sensor for SITL testing
(#7647)
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="--==_mimepart_5a8d6e442ffd3_c4403f9f934d0f2c739cd";
charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: PX4BuildBot
X-GitHub-Recipient: evercltech
X-GitHub-Reason: subscribed
List-ID: PX4/Firmware <Firmware.PX4.github.com>
List-Archive: https://github.com/PX4/Firmware
List-Post<EMAIL_ADDRESS>List-Unsubscribe<EMAIL_ADDRESS>https://github.com/notifications/unsubscribe/ACSImASU0uXsnvFLKpVZlfPTApX4sIiiks5tXBREgaJpZM4OdCCn
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address<EMAIL_ADDRESS>X-SG-EID: f9JBnm3v7f66Apd0aaWYVY2Q5oBOa4jl+J/GIWOkKC46ecS0/q8rd8B50/fToRu1q2HDO023x90roq
Bq3MVFZjBZ2L9QiVyRevN8jkvFo6rl8yfBe21QLqfIfR1zwpU132jdD+5vak88LiJFlXpq18832CDx
4wLKQfxwQNKZ4FzlvzABEPIYv7MoWCUTqx+sjqxBNP8GH2XSi2Osqq479A/7YnlBRjnKApRrQGG81W
8=
----==_mimepart_5a8d6e442ffd3_c4403f9f934d0f2c739cd
Content-Type: text/plain;
charset=UTF-8
Content-Transfer-Encoding: 7bit
Hey, this issue has been closed because the label status/STALE is set and there were no updates for 30 days. Feel free to reopen this issue if you deem it appropriate.
(This is an automated comment from GitMate.io.)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/PX4/Firmware/issues/7647#issuecomment-367319042
----==_mimepart_5a8d6e442ffd3_c4403f9f934d0f2c739cd
Content-Type: text/html;
charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hey, this issue has been closed because the label status/STALE is set and there were no updates for 30 days. Feel free to reopen this =
issue if you deem it appropriate.
(This is an automated comment from GitMate.io.)
&mda=
sh;You are receiving this because you are subscribed to this thread.<=
br />Reply to this email directly, view it on GitHub, or mute the thread.

=
----==_mimepart_5a8d6e442ffd3_c4403f9f934d0f2c739cd--

This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a temporary error. The following address(es) deferred:
<EMAIL_ADDRESS>Domain evercl.com has exceeded the max emails per hour (203/200 (101%)) allowed.  Message will be reattempted later
------- This is a copy of the message, including all the headers. ------
Received: from o1.sgmail.github.com ([<IP_ADDRESS>]:50752)
by apollo.graphium.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128)
(Exim 4.89_1)
(envelope-from<EMAIL_ADDRESS>id 1eoU6g-0007nS-D6
for<EMAIL_ADDRESS>Wed, 21 Feb 2018 08:06:46 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com;
h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe;
s=s20150108; bh=nQJ/UQ6Bf5o9xV0QSroCDtweghs=; b=SPR2pwqpAH9gvass
aT47w1ncNN6Qr/blTaJnqQDU8gi11gQtPCnqM+td4M9MbMqH4vpC9AO+iR2eGOwU
pZO3pXHT018RSqp8K+dPe8e43hTRADPSRci42dEnrI1VOAxjTf9tMhy9ZQBalmPs
cAslgK+atvl10+vmllu33WHgo/4=
Received: by filter0455p1iad2.sendgrid.net with SMTP id filter0455p1iad2-12126-5A8D6E47-7D
2018-02-21 13:04:07.95002965 +0000 UTC
Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2a-ext-cp1-prd.iad.github.net [<IP_ADDRESS>])
by ismtpd0009p1iad1.sendgrid.net (SG) with ESMTP id tO9BN_2vRjCivNbkakZbXA
for<EMAIL_ADDRESS>Wed, 21 Feb 2018 13:04:07.748 +0000 (UTC)
Date: Wed, 21 Feb 2018 13:04:07 +0000 (UTC)
From: PX4 Build Bot<EMAIL_ADDRESS>Reply-To: PX4/Firmware<EMAIL_ADDRESS>To: PX4/Firmware<EMAIL_ADDRESS>Cc: Subscribed<EMAIL_ADDRESS>Message-ID<EMAIL_ADDRESS>In-Reply-To<EMAIL_ADDRESS>References<EMAIL_ADDRESS>Subject: Re: [PX4/Firmware] Enhance virtual camera sensor for SITL testing
(#7647)
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="--==_mimepart_5a8d6e446daf2_681c2ac5a51e6ec41841f2";
charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: PX4BuildBot
X-GitHub-Recipient: evercltech
X-GitHub-Reason: subscribed
List-ID: PX4/Firmware <Firmware.PX4.github.com>
List-Archive: https://github.com/PX4/Firmware
List-Post<EMAIL_ADDRESS>List-Unsubscribe<EMAIL_ADDRESS>https://github.com/notifications/unsubscribe/ACSImASU0uXsnvFLKpVZlfPTApX4sIiiks5tXBREgaJpZM4OdCCn
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address<EMAIL_ADDRESS>X-SG-EID: f9JBnm3v7f66Apd0aaWYVSt7V836wFHQHM1zhSpBUb0LHmZOplslDf0Ch7oYbNpd9PYDHBXY21Hth0
rmzXT7wkfsBgn9v3CF8bGm5yVeNe4rJ50wXHswXrH0n9RM5aMw83QutOWriLhAnv0UMjdtJYqHe1Rt
oHVG0V85WnN2BdqQqf4fjtOPlpSPyIFMOJ9J6tlrx57uR8z5IhTfaEVLCA==
----==_mimepart_5a8d6e446daf2_681c2ac5a51e6ec41841f2
Content-Type: text/plain;
charset=UTF-8
Content-Transfer-Encoding: 7bit
Closed #7647.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/PX4/Firmware/issues/7647#event-1484605334
----==_mimepart_5a8d6e446daf2_681c2ac5a51e6ec41841f2
Content-Type: text/html;
charset=UTF-8
Content-Transfer-Encoding: 7bit
Closed #7647.
—You are receiving this because you are subscribed to this thread.Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_5a8d6e446daf2_681c2ac5a51e6ec41841f2--


#743 support encoding parameter

Solution for issue #743 on ci.maven to support setting the file encoding of the java source files.

@maroschutte Thank you for the PRs for this issue. If this is your first contribution to an OpenLiberty project, we will need you to sign the CLA. You can find a link in our CONTRIBUTING doc.
Also, a couple of points:

Since the change was in ci.common, this affects both the ci.maven and the ci.gradle projects. So we will need a similar PR in ci.gradle.
Can an existing IT test case be changed to prove this fix works?

@maroschutte Seems like ci.gradle does not need a similar change after all. This code is only used for multi-module Maven support. So just need to address the second point I listed (test case change) and the CLA.

@maroschutte Any updates on your CLA status?

Getting the CLA done involves multiple departments, so it will take some time

New pull request from my work account: https://github.com/OpenLiberty/ci.maven/pull/1640


Add ability to modify AjvOptions on IOpenAPIResponseValidator arguments

What version of Ajv you are you using?
8.6.4
What problem do you want to solve?
I would like to be able to modify AJV options in custom response validators (IOpenAPIResponseValidator).
What do you think is the correct solution to problem?
Adding AjvOptions to OpenAPIResponseValidatorArgs just like there is an option in OpenAPIRequestValidatorArgs.
That would allow something like:
constructor(args: OpenAPIRequestValidatorArgs) {
    args.ajvOptions = {
      ...args.ajvOptions,
      discriminator: true,
    };
    super(args);
  }

Like I was able to do in a custom request validator.
Will you be able to implement it?
Yes.

Sorry, opened on the wrong project


usdts and child process

The way we currently spawn a child process is:

fork child, let it block on a pipe read
go through the whole codegen phase
attach the probes
let the child run, i.e. execve

The issue with this is that we cannot use USDTs on the child process as it hasn't execved yet when we try to attach them.
Using ptrace to pause the child after execve seems like a viable option. Not all programs like to be ptraced but I don't think they can detect it if you detach right after they execved.
To be on the safe side we can keep the original behaviour and hide the ptrace one behind a flag  (--ptrace-child?), which is disabled by default and enabled for USDTs.

Good idea! Was thinking on how to solve this as well 😄

Using ptrace to pause the child after execve seems like a viable option. Not all programs like to be ptraced but I don't think they can detect it if you detach right after they execved.

I think think it's a reasonable assumption due to strace's popularity!
As a follow-up, should we look into how to make this work with dynamic USDTs? Not sure how could we approach this but might be interesting as well cc @mmarchini @dalehamel

The issue I see with dynamic USDT @javierhonduco is that you can’t know for certain when they would be enabled, it may not happen immediately on boot. This creates a race that can be difficult to reason about, and the only option I can think makes sense is for bpftrace to poll waiting for the USDT target symbol to be present.
I suspect some programs will also only want to enable dynamic USDT on receiving a signal, perhaps that would need to be supported as well, where bpftrace would need it emit a signal to the child process after spawning it. Again though, a race as we cannot know of the signal handler has been set up, and not all signals are safe to send without a handler.
I like the concept overall, I’m interested to help out however I can.

I'm working on a solution for this. A separate "child process manager" class which will allow us to remove some code from class BPFtrace (#1080) and also add pidfd support (#880).

Fixed by #1238.


Setup precommit

install precommit in your local clone with:
pre-commit install
pre-commit install -t pre-push

See also pre-commit documentation.

Codecov Report

Merging #51 (e903af8) into main (e3ea05e) will decrease coverage by 0.02%.
The diff coverage is 0.00%.

@@           Coverage Diff            @@
##            main     #51      +/-   ##
========================================
- Coverage   0.02%   0.00%   -0.03%
========================================
  Files        148     146       -2
  Lines      24866   24085     -781
========================================
- Hits           6       0       -6
+ Misses     24860   24085     -775

Flag
Coverage Δ

unittests
?

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

geoapps/__init__.py
0.00% <ø> (ø)

geoapps/base.py
0.00% <0.00%> (ø)

geoapps/em1d_inversion.py
0.00% <0.00%> (ø)

geoapps/export.py
0.00% <0.00%> (ø)

geoapps/inversion.py
0.00% <0.00%> (ø)

geoapps/pf_inversion.py
0.00% <0.00%> (ø)

geoapps/plotting/__init__.py
0.00% <ø> (ø)

geoapps/plotting/plotting.py
0.00% <0.00%> (ø)

geoapps/plotting/scatter.py
0.00% <0.00%> (ø)

geoapps/plotting/selection.py
0.00% <0.00%> (ø)

... and 71 more

Continue to review full report at Codecov.

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


[WFCORE-3797] Add the -Djava.util.logging.manager system property to …

…the surefire argLine and the jboss-logmanager library to the bootclasspath for the IBM JDK.
https://issues.jboss.org/browse/WFCORE-3797

retest this please


Maven executable jar

Add mainClass to manifest of jar so you can run
java -jar target/bsh-2.1.0-SNAPSHOT.jar
Also cleaned up some IDE files, in a separate commit that can be removed if desired.
@stain let me know if this is useful.

grr, should have been against maven branch


Fastlane fails on latest verison of Ruby 3

Troubleshooting

[ x] I've searched discuss.bitrise.io for possible solutions.
Which version of the step is effected? 3.4.3
Is the issue reproducible with the latest version? YES
Does the issue happen sporadically, or every time? EVERY TIME
Is the issue reproducible locally by following our local debug guide? NOT APPLICABLE

Issue description
Bitrise info

Build URL
Bitrise Support enabled: YES
Log:

Failed to install Step dependencies:
  command failed with exit status 5 (bundle "_2.1.4_" "install" "--jobs" "20" "--retry" "5"):
    check the command's output for details
Failed to install Step dependencies:
  command failed with exit status 5 (bundle "_2.1.4_" "install" "--jobs" "20" "--retry" "5"):
    check the command's output for details

+------------------------------------------------------------------------------+
| (2) fastlane                                                                 |
+------------------------------------------------------------------------------+
| id: fastlane                                                                 |
| version: 3.4.3                                                               |
| collection: https://github.com/bitrise-io/bitrise-steplib.git                |
| toolkit: go                                                                  |
| time: 2023-07-17T20:15:10Z                                                   |
+------------------------------------------------------------------------------+
|                                                                              |
Inputs:

work_dir: ./capacitor/ios/App
lane: build
connection: automatic
apple_id:
password:
app_password:
api_key_path:
api_issuer:
update_fastlane: true
verbose_log: false
enable_cache: true
GEM_HOME:
BITRISE_BUILD_URL: https://app.bitrise.io/build/a4762ceb-fac9-4ac2-8878-38ff6a3c9b80
BITRISE_BUILD_API_TOKEN: *****
Expand WorkDir
Expanded WorkDir: /Users/vagrant/git/capacitor/ios/App
Checking rbenv version
$ rbenv "versions"
system
2.6.9
2.7.2
2.7.5
2.7.6
3.0.0
3.0.3
3.1.0
3.1.3
3.1.4
3.2.1

3.2.2 (set by /Users/vagrant/.rbenv/version)
Reading Apple Developer Portal authentication data
Bitrise Apple Developer Connection with API key found
Determine desired Fastlane version
Gem lockfile defined Fastlane version: 2.182.0
Gem lockfile defined bundler version: 2.1.4
Failed to check active Ruby version: command failed with exit status 1 (bundle "2.1.4" "exec" "ruby" "--version"): check the command's output for details
Output: /Users/vagrant/.asdf/installs/ruby/3.2.2/lib/ruby/3.2.0/rubygems.rb:263:in find_spec_for_exe': can't find gem bundler (= 2.1.4) with executable bundle (Gem::GemNotFoundException)   from /Users/vagrant/.asdf/installs/ruby/3.2.2/lib/ruby/3.2.0/rubygems.rb:282:in activate_bin_path'
from /Users/vagrant/.asdf/installs/ruby/3.2.2/bin/bundle:25:in <main>' Install bundler $ gem "install" "bundler" "--no-document" "-v" "2.1.4" "--force" Successfully installed bundler-2.1.4 1 gem installed $ rbenv "rehash" Install Fastlane with bundler $ bundle "_2.1.4_" "install" "--jobs" "20" "--retry" "5" Calling DidYouMean::SPELL_CHECKERS.merge!(error_name => spell_checker)' has been deprecated. Please call `DidYouMean.correct_error(error_name, spell_checker)' instead.
Fetching gem metadata from https://rubygems.org/........
google-api-client-0.38.0 requires ruby version ~> 2.4, which is incompatible
with the current version, ruby 3.2.2p53
Failed to install Step dependencies:
command failed with exit status 5 (bundle "2.1.4" "install" "--jobs" "20" "--retry" "5"):
check the command's output for details
Failed to install Step dependencies:
command failed with exit status 5 (bundle "2.1.4" "install" "--jobs" "20" "--retry" "5"):
check the command's output for details
|                                                                              |
+---+---------------------------------------------------------------+----------+
| x | fastlane (Failed)                                             | 9.63 sec |
+---+---------------------------------------------------------------+----------+
| Issue tracker: https://github.com/bitrise-io/steps-fastlane/issues           |
| Source: https://github.com/bitrise-io/steps-fastlane                         |
+---+---------------------------------------------------------------+----------+

Steps to reproduce

Run fastlane build step with M1 on Xcode 14.1.x, on macOS 13.2 (Ventura)

I am facing the same issue from today.

My current workaround is a script step to run
asdf install ruby 2.6.9
asdf global ruby 2.6.9


Support metric system measurements (#4)

This PR consists the fix for #4.
Changes

Makes use of user's location to identify country to predict unit of measure.
Added Toggle button for unit of measure.
Added fuse support for metric systems.

@ifvictr Sorry about the delay, something came up :relieved:
Let me know if it is okay! :smiley:

@ifvictr Fixed them!


Debugging the server-rendered page

Hopefully this is an easy one. I'm simply wanting to view the server-rendered page in the browser, and not have it replaced immediately by the client-side app. Is there a way to turn off the client code and just see the SSR output?

Just disable JS client side.

A'ight!


This also seems to happen when deleting any profile.  Only on page refresh do you notice that the error message was wrong and it did successfully delete.

Documentation issue.  New config options are mandatory, solved in docs PR#132.


Remapping Module Alias Names

Prerequisites

[X] Please first check README. There are breaking changes from 0.x to 1.0

[X] Did you check the FAQ?

[X] Did you search open and closed issues to see if your issue has already been reported?

Description
Ability to remap module names.  In cases where other loaders are being used and TypeScripts moduleResolution is set to classic (and with TypeScript 2.0, where paths will be able to be supplied), there can be a disconnect between the module ID managed by typings and the location of the corresponding emitted code.
For example, if I have a ./node_modules/my-package/dist/amd/foo.js and a ./node_modules/my-package/dist/amd/foo.d.ts I would configure my package loader so that my-package/foo would resolve to node_modules/my-package/dist/amd/foo.js and therefore in my TypeScript code, I would want to import foo from 'my-package/foo'; to resolve to the typings in ./node_modules/my-package/dist/amd/foo.d.ts.
As far as I can tell though, typings will always create the "real" module as ~my-package/dist/amd/foo and alias the module to my-package/dist/amd/foo, neither of which will represent the run-time configuration.
I have read the documentation and open and closed tickets... While I found a couple things that sort of maybe would have helped, I have been unable to find a way of configuring a typings.json to be able to import a package and remap the module names.
As I mention above, in TypeScript 2.0 (which is unreleased as of this writing) there will be an ability to explicitly remap paths (see: Microsoft/TypeScript#5039) and this should allow TypeScript to resolve .ts files in other locations and sort of accomplish the above, but it would not provide the additional management of dependencies, etc. that typings/typings brings.
Currently we use dts-generator to general ambient/global definitions that are mapped, but then that of course causes other challenges of trying to manage ambient/global definitions.
Steps to Reproduce

Read lots of documentation
Mash lots of keys
Swear at laptop
Open an issue, wondering what I am missing

Expected behavior: [What did you expect to happen?]
Find a way to remap/alias/use a different root when using typings/typings.
Actual behavior: [What actually happened?]
Unable to find a way.
Versions
1.0.4

There isn't currently any way to achieve this. I'd be open to a proposal, but I'm also hoping more of this would work at the TypeScript level. If TypeScript is remapping module paths, why wouldn't it automatically remap the global module paths to match?

For < TS 2.0, TypeScript does no remapping.  We have used classic module resolution and expressed our typings as global typings, where the MID matches where the run-time location will be.  We then keep the AMD loader configured to match that run-time location.
For example, if we had a module package/dist/umd/foo.js we would emit in our package.d.ts file:
declare module 'package/foo' {
  export foo;
}

And we would configure in our AMD loader:
{
  packages: [
    { name: 'package', location: 'node_modules/package/dist/umd' }
  ]
}

As mentioned above though, typings will always emit package/dist/umd/foo.d.ts:
declare module '~package/dist/umd/foo' {
  export foo;
}

declare module 'package/dist/umd/foo' {
  import alias = require('~package/dist/umd/foo');
  export = alias;
}

Although I haven't tried it, for TypeScript 2, in the tsconfig.json I would be able to supply the following:
{
  "paths": {
    "package/*": [ "node_modules/package/dist/umd/*" ]
  }
}

And that would essentially allow TypeScript to resolve a reference to 'package/foo' to find a match in /node_modules/package/dist/umd/foo.d.ts based on the resolution logic.
I am not sure how TypeScript will be manifesting that in the TypeScript services, but even then it would only inform of a possible way of resolving the reference, versus actually giving a definitive name for a module.
So as far as a proposal, what would work for our use case (though I don't know if it would work for everyone) is to allow something like this in typings.json:
{
  "dependencies": {
    "package": {
      "typings": "npm:package",
      "rootDir": "dist/umd"
    }
  }
}

Where the rootDir would imply that modules should be calculated in reference to that path, which would be relative to the base of the npm package.

Just to follow up on module resolution in TypeScript 2.0.
The following configuration in the tsconfig.json allows the compiler to resolve the module of package/foo to ./node_modules/package/dist/umd/foo.d.ts:
{
	"compilerOptions": {
		"baseUrl": ".",
		"paths": {
			"package/*": [ "./node_modules/package/dist/umd/*" ]
		}
	}
}


ciations all got corrupted and automatically deleted when converting md with ciatation keys to docx using pandoc

Debug log ID
V4C94885-refs-euc/6.7.137-7
What happened?
I am converting a md file with bbt citations to a word file. In the converted word document when click zotero referesh the error bellow occurs and the citations are deleted automatically!
I opened the converted word files weeks ago which could be refershed and updated to live ciations and did the same actions, but even these files show the same errors as below: zotero code corrupted, and citations got deleted.
This example and action I did achived correct live citations results few weeks ago but tody I opened the previeusly converted docx files and did zotero refresh, even these previously correct citations were shown corrputed and gone!  I don't know what  is going on.
I tried on two PCs still the same
My coauthor is waiting for my version of the paper for days but now it is totally corrupted and I am really crazy on it.
The command:
pandoc -s --lua-filter=zotero.lua -o paperback.docx paper.md
The md file:
zotero:
csl-style: apa7 # pre-fill the style
author-in-text: true
Creativity, a fundamental feature of human intelligence, has long been a challenge for AI
[@ArtifIntellRev2022AnantrasirichaiArtificialIntelligenceCreative]
[@NatHumBehav2023WebbEmergentAnalogicalReasoning; @2023ZhangExploringMITMathematics; @InternetofThingsandCyber-PhysicalSystems2023RayChatGPTComprehensiveReview]
The docx file and error

I have nearly a hundred ciations in that paper and now don't know what to do .
This is a duplicate of #2718 but that got no response for 3 days due to lack of log id and I am really really time constrained so I have to open another one. I really hope my problem can be solved.
Best,

Yeah it got no response for 3 days because you were asked for a debug log ID immediately and you chose to ignore that for two days -- and now suddenly no response from me withing one day is a problem?


Remove deprecated sync_batchnorm and num_nodes attributes in DDPSpawnPlugin

What does this PR do?
Part of #10312
test_v1_6_0_ddp_spawn_num_nodes()
test_v1_6_0_ddp_spawn_sync_batchnorm()
Does your PR introduce any breaking changes? If yes, please list them.

Before submitting

[x] Was this discussed/approved via a GitHub issue? (not for typos and docs)
[x] Did you read the contributor guideline, Pull Request section?
[x] Did you make sure your PR does only one thing, instead of bundling different changes together?
[ ] Did you make sure to update the documentation with your changes? (if necessary)
[x] Did you write any new necessary tests? (not for typos and docs)
[x] Did you verify new and existing tests pass locally with your changes?
[x] Did you list all the breaking changes introduced by this pull request?
[ ] Did you update the CHANGELOG? (not for typos, docs, test updates, or internal minor changes/refactorings)

PR review
Anyone in the community is welcome to review the PR.
Before you start reviewing make sure you have read Review guidelines. In short, see the following bullet-list:

[x] Is this pull request ready for review? (if not, please submit in draft mode)
[x] Check that all items from Before submitting are resolved
[x] Make sure the title is self-explanatory and the description concisely explains the PR
[x] Add labels and milestones (and optionally projects) to the PR so it can be classified

Did you have fun?
Make sure you had fun coding 🙃

@puhuk Great, thanks for working on this. A few items need to be resolved:

See my review comments
Let's add a changelog entry in the "Removed" section
You will also need to remove the two tests: test_v1_6_0_ddp_spawn_num_nodes() and test_v1_6_0_ddp_spawn_sync_batchnorm()

Seems to be a duplicate of  #10357

@awaelchli
It's different since this PR is about ddp_spawn.py, while #10357 to resolve ddp.py


RTD theme fix

Coverage remained the same at 100.0% when pulling a00a91cc73a11a883b047b3905de19b116af145e on dev into 2642be1a1ffaee624339a5c9df72547fe8f4764b on master.


Set up sign-up and sign-in with a Google account using Azure Active Directory B2C - Authorized JavaScript origins

When attempting to create an Oauth client ID, Google displays the following error message for the Authorized JavaScript origins:
Invalid Origin: URIs must not contain a path or end with "/".

And the Create button is disabled.

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

ID: 2c9d9c00-1382-c578-6b0d-7b5f9d63eebd
Version Independent ID: ce817a72-ca0d-ce18-f6ac-fc4812e9245d
Content: Set up sign-up and sign-in with a Google account - Azure AD B2C
Content Source: articles/active-directory-b2c/identity-provider-google.md
Service: active-directory
Sub-service: b2c
GitHub Login: @msmimart
Microsoft Alias: mimart

Nevermind, I misread the doc.

@DaveBagler Glad to know that you have self resolved the issue. Thanks for the update.


how do i unlock a week

In version 1.6.1 the weeks are blocked and then the lock comes out and I want them to be unlocked, could you tell me how?

you play the weeks and complete them vice versa . close this

juegas las semanas y las completas al revés. cierra esto

a and about that is that every time a song ends it crashes and leaves the game


Add changelog for v4.4b8

Codecov Report
Attention: 258 lines in your changes are missing coverage. Please review.

Comparison is base (a26557b) 89.38% compared to head (c353069) 89.22%.
Report is 228 commits behind head on beta/v4.0.

Files
Patch %
Lines

integration/test_collection_openai.py
33.33%
38 Missing :warning:

weaviate/collections/batch/base.py
83.10%
25 Missing :warning:

weaviate/collections/filters.py
73.01%
17 Missing :warning:

weaviate/collections/data.py
78.57%
15 Missing :warning:

integration/test_collection_rerank.py
26.31%
14 Missing :warning:

weaviate/collections/batch/batch_wrapper.py
83.13%
14 Missing :warning:

weaviate/collections/batch/grpc_batch_objects.py
84.41%
12 Missing :warning:

weaviate/collections/config.py
66.66%
10 Missing :warning:

weaviate/client.py
84.48%
9 Missing :warning:

integration/test_collection_batch_delete.py
94.96%
8 Missing :warning:

... and 32 more

Additional details and impacted files
@@              Coverage Diff              @@
##           beta/v4.0     #746      +/-   ##
=============================================
- Coverage      89.38%   89.22%   -0.17%
=============================================
  Files            154      175      +21
  Lines          16747    17989    +1242
=============================================
+ Hits           14970    16050    +1080
- Misses          1777     1939     +162

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Cleanup metadata tests

This PR replaces func returns with t.Cleanup,
which makes tests slightly easier to maintain as
there is no need to call defer cancel() everywhere.
Signed-off-by: Maksym Pavlenko<EMAIL_ADDRESS>

might be easier to get a clean CI run with a rebase (for Windows flaky test)

Yep, rebased.


Fail GPS isolation earlier when uncommitted changes exist

It's a sad day you've waited to get past all your tests and you find out there was a lingering file that didn't make the cut and isolation fails due to uncommitted changes existing. Or maybe you got excited and started working while the tests were running and created uncommitted changes (I guess this could happen after an initial check anyways).
It would be nice to have isolation fail early before running builds and tests. I still think there has to be a final check anyways too; which can help catch instances where you may have missed committing some type of build artifact potentially.

Isolation should be exiting early based on these things before running. Are you sure you are running the latest version?
This was addressed with https://github.com/uptech/git-ps-rs/issues/139

I will double check; I may have just started making changes mid-isolation potentially too.

Verified this was likely a me issue 👍


User ID shown when @'ing someone

In the posts, when someone @'s someone in their post the scrapbook site shows the person's slack ID rather than the name. It might be better to show the name instead, or at least some better form of identification?

https://github.com/hackclub/scrappy/issues/15 👀

Whoops!


Enabling Heat Autoscale Test

Enabling Heat Autoscale Test

Here are the results
https://ci.nue.suse.com/job/openstack-ardana-tests/502/artifact/.artifacts/heat.log
There is a failure ,but has nothing to do with this checkin.


rx_observe can be more intuitive as rx_observe<AnyObject?>

rx_observe for KVO compliant objects is a little confusing
For example. I may want to store my apiToken in
  NSUserDefaults.standardDefaults().setObject(apiToken, forKey: "apiToken")

I should be able to subsequently observe this like so
 NSUserDefaults.standardUserDefaults().rx_observe("apiToken")
        >- subscribeNext{ myApiToken -> Void in
            println(myApiToken)
        }

However the compiler doesn't understand this syntax.
It would be helpful if rx_observe was generically typed with
  rx_observe<AnyObject?>

Will try to figure out how to make this more user friendly. Have some ideas.

Hm, I've tried to play with some ideas, but I don't right now I don't see a way to trick Swift compiler into some kind of default return value.
@mbalex99  Do you have some ideas?
I've documented everything here https://github.com/kzaher/RxSwift/blob/master/Documentation/GettingStarted.md#kvo
Don't see we can do anything else. I've thought about adding rx_observeAnyObject -> Observable<AnyObject?> but it seems ugly, and it doesn't really solve the original issue.
Let me know what do you think.

I think rx_observeAsAnyObject or yet rx_observeKVO
You can't easily cast generic's types. It's not good practice. So I think explicitly having rx_observeAsAnyObject makes it clear that you'll have to cast it yourself. It should be okay in the mean time.
Maybe an option is to transform the KVO object into a Variable then just make rx_observe as an alias to that value.

Hm,
I guess I can add rx_observeAsAnyObject(...) -> Observable<AnyObject?>, and write it in front of other overloads to allow users to more easily express that they want AnyObject as return type. I understand that people have different backgrounds, and I don't want to make more confusing then the problem requires.
I would really like to maintain current api because correctly unwrapping CGPoint and other structs is not so trivial as one might think :)
This is the code needed to correctly unwrap CGRect, it's not just as! :)
#if arch(x86_64) || arch(arm64)
let CGRectType = "{CGRect={CGPoint=dd}{CGSize=dd}}"
#elseif arch(i386) || arch(arm)
let CGRectType = "{CGRect={CGPoint=ff}{CGSize=ff}}"
#endif

// rx_observe + CoreGraphics
extension NSObject {
    public func rx_observe(keyPath: String, options: NSKeyValueObservingOptions = NSKeyValueObservingOptions.New | NSKeyValueObservingOptions.Initial, retainSelf: Bool = true) -> Observable<CGRect?> {
        return rx_observe(keyPath, options: options, retainSelf: retainSelf) as Observable<NSValue?>
            >- map { value in
                if let value = value {
                    if strcmp(value.objCType, CGRectType) != 0 {
                        return nil
                    }
                    var typedValue = CGRect(x: 0, y: 0, width: 0, height: 0)
                    value.getValue(&typedValue)
                    return typedValue
                }
                else {
                    return nil
                }
            }
    }

Do you think that adding rx_observeAsAnyObject(...) -> Observable<AnyObject?> would solve your concern?
Any other opinions/suggestions on this?

I guess this has been addressed in the development cycle of RxSwift 2.0.
I will close this issues, if anyone has something interesting to say about this, please consider opening a new issue referring to this one. :)


Faulty invalidate of FormattedMessage when getting PropertiesDictionary

Found a bug in NLog 4.5, where the LogEventInfo.FormattedMessage is recalculated when PropertiesDictionary is accesed.
This doesn't work well with complex parameters that might change after the log-statement.

Thanks will merge soon!


structInit doesn't work for components

I'm new to this lib, but it seems like component classes tagged with @:structInit do not work as intended.
@:structInit
class Tile {
    public var x:Int;
    public var y:Int;
}

// in Main
var a = ecs.createEntity();
ecs.setComponents(a, ({ x : 0, y : 0 }:Tile));

// in a system
@:fastFamily
var tiles : {
    tile:Tile
};

I get a warning that Tile is not used, and nothing happens in the system. Giving the component class a constructor and removing @:structInit works as intended.

do you have a full example where it doesn't work? I adapted the velocity sample to use struct init and it seems to work.
import ecs.System;
import ecs.Universe;
import ecs.macros.SystemMacros;
import ecs.macros.UniverseMacros;

class Position {
    public var x : Float;

    public var y : Float;

    public function new() {
        x = 0;
        y = 0;
    }
}

@:structInit @:publicFields class Velocity {
    var x : Float;

    var y : Float;
}

class VelocitySystem extends System {
    @:fastFamily var movables : { pos : Position, vel : Velocity };

    override function update(_dt : Float) {
        iterate(movables, {
            pos.x += vel.x * _dt;
            pos.y += vel.y * _dt;

            trace('${ pos.x },${ pos.y }');
        });
    }
}

function main() {
	final universe = new Universe(1024);
    final object   = createEntity(universe);

    setSystems(universe, VelocitySystem);
    setComponents(universe, object,
        Position,
        ({ x : 1, y : 1 } : Velocity));

	universe.update(1 / 60);
}

Ahhh I think I had multiple things wrong at the same time. I tested a few different ways, and it works.


New rule on Elasticache Redis cluster automatic backup enabled

'''
Rule Name:
  ELASTICACHE_REDIS_CLUSTER_AUTOMATIC_BACKUP_CHECK

Description:
  Check whether the Amazon ElastiCache Redis clusters have automatic backup turned on. The rule is NON_COMPLIANT if the SnapshotRetentionLimit of an Amazon Elasticache Redis cluster is 0.

Trigger:
  Periodic

Reports on:
  AWS::ElastiCache::CacheCluster

Rule Parameters:
  None

Scenarios:
  Scenario: 1
    Given: No Amazon ElastiCache Redis cluster in the AWS Account
     Then: Return NOT_APPLICABLE
  Scenario: 2
    Given: At least 1 Amazon Elasticache Redis cluster is present
      And: The SnapshotRetentionLimit is set to 0
     Then: Return NON_COMPLIANT with Annotation "Automatic backup not enabled for Amazon ElastiCache cluster {Cluster_ID}"
  Scenario: 3
    Given: At least 1 Amazon Elasticache Redis cluster is present
      And: The SnapshotRetentionLimit is greater than 0
     Then: Return COMPLAINT
'''

Can you write the scenarios as "The Elasticache Redis cluster has automatic backup enabled" not "All ...". It is because you report on individual resources. You would write "One or more..." if you were reporting on AWS::::Account.
Scenario 1 needs to report COMPLIANT
You need another Scenario if there is no Cluster, reporting NOT_APPLICABLE

Gherkin has been updated as per above suggestion.

Updated:

The order of the scenario is usually better NOT_APPLICABLE -> NON_COMPLIANT -> COMPLIANT.
there were quite a lot of typo.

Idea:
Since you mention 0, then it is probably worth to have an optional parameter that allow to configure a target number of days, with 90 days by default. What do you think?

Thank you for making those changes.
Using parameter for the snapshot retention period is a good idea, however it's default value of 90 days will be too long I think. 15 days default snapshot retention period would be fine?

Good to go!


Failed to activate asdf environment: Unexpected token / in JSON at position 0

Description
Hey people, it seems latest ruby-lsp v0.5.20 has problems to start:
Failed to activate asdf environment: Unexpected token / in JSON at position 0

My software set:
ruby 3.1.4p223
VSC 1.88.1
asdf v0.11.3-0adc6c1

Rolled back to ruby-lsp 0.50.19 and things started working again

Hi @ssnake, in https://github.com/Shopify/ruby-lsp/issues/1985 someone found that updating asdf solved this for them, could you try that please?


chore: add unit tests for tolerating an = in config property

Summary
This PR simply adds unit tests to confirm/test  that the core tolerates an "=" within a config property value.
ref: https://github.ibm.com/arf/planning-sdk-squad/issues/1759

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

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

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


(WIP) Multi-GPU : use threads instead of processes

This PR aims to fix the fact that the current version of dev/automate_training.py is not compatible with a non-zero num_workers which became a problem after what @charleygros  discovered in #111
This  error was previously discussed
Using shared queue to assign an available GPU to each thread

@olix86 can you please add a justification when closing a PR without merging it?

It fixes a really old bug with automate training that hasn't occured in > 1 year


Merge Swift 3.1 branch into master

Bring in Swift-3.1 fixes.

#843

This already has conflicts.
In general what we've been doing is this: putting changes in master, then cherry-picking to swift-3.1-branch. It's the process the other projects are using.
Personally I prefer to target fixes at the branch and merge to master, but that's not the current setup. I think we could revisit that next time we branch for a release.

Ah - ok. Is this documented anywhere or shall I add to README?

Mostly it's just emails to the various dev lists.

Let's certainly cherry-pick your fix in #843 to master though.

Hello, did the cherry-pick of #843 into master end up happening? The latest snapshot (02-05) still seems to fail to build CoreFoundation - at least, a Vapor project I'm working with fails to import Foundation with the same errors as those referenced in #843.

Cherry Pick is happening in #868.


New API Proposal: RSA Key Support

New API Proposal: RSA Key Support
Motivation:
RSA is a widely used and popular public key system used for key exchange and popular with JWTs and older TLS versions among other uses. Although relatively old and slow, it is still widely supported and heavily used, justifying its inclusion in Swift Crypto. BoringSSL has the code in it required, so those APIs would need to be exposed.
Importance:
A lot of systems still use RSA to public key encryption and validation. Apple's own Sign in With Apple service provides a JWT that is signed using an RSA key, provided as a JWK. Without RSA support in Swift Crypto, we are unable to use that library to verify JWTs from Apple on the server-side.

Thanks for this feature request! We'll circulate it with the team and get back to you.

Would be really great to see the support of RSA inside swift-crypto. It is such a common use-case and we had to fall back to the Security framework on iOS to generate RSA keys now.

I've hit the lack of RSA support in this project today - adding my voice: it'd be great to see RSA key support ❤

I guess the requested feature has been implemented here:
https://github.com/apple/swift-crypto/blob/main/Sources/_CryptoExtras/RSA/RSA.swift
Does that solve your problem?

Ooh it could well do

@0xTim : Can you confirm this addresses your request?

@FredericJacobs sure, give me a few days to see if et offers everything we need for JWTKit

Would it be possible to include a way to extract the data representations of the modulus, exponent and private exponent for the public and private keys? an initialiser using those would be amazing as well!

What's the intended use-case?

@FredericJacobs I was taking a look at the JWTKit API in order to see what was needed to move to swift-crypto's RSA implementation. There's this initializer that's part of the public API  https://github.com/vapor/jwt-kit/blob/449850f0db4769c630d90ff09ee1be2a5a382bd8/Sources/JWTKit/RSA/RSAKey.swift#L145,
Secondly there's also an initializer using a certificate string to create an RSAKey, https://github.com/vapor/jwt-kit/blob/449850f0db4769c630d90ff09ee1be2a5a382bd8/Sources/JWTKit/RSA/RSAKey.swift#L65.
I'm not well versed enough in these to know if it's trivial to convert between these representations of certificate strings and pemkey formats to the n, e, d formats ourselves but couldn't find anything conclusive on that while doing some reading. So those would be the main missing features regarding RSA keys.
@Lukasa I'm working on an OpenSSH private key parser currently used along with swift-nio-ssh where I'm reading the modulus etc from the openssh format itself to then create an RSAKey with (using BoringSSL currently). I would like to move to swift-crypto's RSA implementation instead (if possible).

I think we can probably add a "from numbers" interface to RSA.

This is now implemented in CryptoExtras


Add an option to disable thiserror::v1

This PR brings an option to disable thiserror::v1 when using C++20.
The v1 is now disabled by default on C++20 because I think most users do not want to use an extra dependency (Boost.Metaparse). When we want to keep v1, we can enable it by defining MITAMA_THISERROR_ENABLE_V1 like #define MITAMA_THISERROR_ENABLE_V1 true.

@LoliGothick こちら、マージしちゃいます、、！もし問題があれば、Revertしましょう！:+1: