Waybar not available anymore

Hi,
I've been using sway and waybar for a few months and it worked fine most of the time.
But today, after restarting, the waybar won't show up anymore and I'm not sure how to debug/fix this issue.
$ waybar
[2020-04-04 19:07:25.410] [info] Resources files: /home/dori/.config/waybar/config, /home/dori/.config/waybar/style.css
[2020-04-04 19:07:25.416] [warning] module sway/workspaces: Disabling module "sway/workspaces", Unable to connect to Sway
[2020-04-04 19:07:25.416] [warning] module sway/mode: Disabling module "sway/mode", Unable to connect to Sway
[2020-04-04 19:07:25.417] [warning] module sway/window: Disabling module "sway/window", Unable to connect to Sway
[2020-04-04 19:07:25.426] [warning] For a functional tray you must have libappindicator-* installed and export XDG_CURRENT_DESKTOP=Unity
$ ps auxw|grep sway
dori       26760  0.0  0.0 159208  5532 tty2     Ssl+ 18:58   0:00 /usr/lib/gdm-wayland-session --register-session sway
dori       26763  0.9  0.3<PHONE_NUMBER>68 tty2    Sl+  18:58   0:06 sway
$ yay -Qs sway
local/sway 1:1.4-8
    Tiling Wayland compositor and replacement for the i3 window manager
local/waybar 0.9.1-1
    Highly customizable Wayland bar for Sway and Wlroots based compositors

Getting a lot of journalctl errors:

journalctl logs when trying to restart sway
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48179]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48179]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48179]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48179]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48179]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48180]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48180]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48180]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48180]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48180]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48181]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48181]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48181]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48181]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48181]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48182]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48182]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48182]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48182]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48182]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48183]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48183]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48183]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48183]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48183]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48184]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48184]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48184]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48184]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48184]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48185]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48185]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48185]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48185]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48185]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48186]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48186]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48186]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48186]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48186]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48187]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48187]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48187]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48187]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48187]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48188]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48188]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48188]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48188]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48188]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48189]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48189]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48189]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48189]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48189]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48190]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48190]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48190]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48190]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48190]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48191]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48191]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48191]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48191]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48191]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48192]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48192]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48192]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48192]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48192]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48193]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48193]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48193]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48193]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48193]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48194]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48194]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48194]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48194]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48194]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48195]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48195]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48195]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48195]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48195]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[26835]: [dix] couldn't enable device 10
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[26835]: [dix] couldn't enable device 11
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[26835]: [dix] couldn't enable device 12
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48196]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48196]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48196]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48196]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48196]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48197]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48197]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48197]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48197]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48197]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48198]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48198]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48198]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48198]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48198]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48199]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48199]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48199]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48199]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48199]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48200]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48200]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48200]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48200]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48200]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48201]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48201]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48201]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48201]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48201]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48206]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48206]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:27 xps7390 /usr/lib/gdm-wayland-session[48206]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48206]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48206]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48203]: 2020-04-04 19:11:27 - [swaybg-1.0/main.c:296] Could not find config for output eDP-1 (Sharp Corporation 0x14A8 0x00000000)
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48207]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48207]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48207]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48207]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48207]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[26835]: [dix] couldn't enable device 10
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[26835]: [dix] couldn't enable device 11
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[26835]: [dix] couldn't enable device 12
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48208]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48208]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48208]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48208]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48208]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48209]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48209]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48209]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48209]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48209]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48214]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48214]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48214]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48214]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48214]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48215]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48215]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48215]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48215]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48215]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:28 xps7390 waybar[26770]: Error flushing display: Broken pipe
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48216]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48216]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48216]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48216]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48216]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48217]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48217]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48217]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48217]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48217]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48218]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48218]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48218]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48218]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48218]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48219]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48219]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48219]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48219]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48219]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[26835]: [dix] couldn't enable device 10
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[26835]: [dix] couldn't enable device 11
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[26835]: [dix] couldn't enable device 12
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48205]: [2020-04-04 19:11:28.063] [info] Resources files: /home/dori/.config/waybar/config, /home/dori/.config/waybar/style.css
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48223]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48223]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48223]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48223]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48223]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48205]: Unknown option -b
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48224]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48224]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48224]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48224]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48224]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48205]: [2020-04-04 19:11:28.078] [warning] For a functional tray you must have libappindicator-* installed and export XDG_CURRENT_DESKTOP=Unity
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48240]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48240]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48240]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48240]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48240]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48242]: sh: jrnl: command not found
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48261]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48261]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48261]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48261]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48261]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48268]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48268]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48268]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48268]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48268]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48277]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48277]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48277]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48277]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48277]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48288]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48288]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48288]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48288]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48288]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48290]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48290]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48290]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48290]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48290]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[26835]: [dix] couldn't enable device 10
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[26835]: [dix] couldn't enable device 11
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[26835]: [dix] couldn't enable device 12
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48291]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48291]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48291]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48291]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48291]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48292]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48292]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48292]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48292]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48292]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48295]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48295]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48295]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48295]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48295]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48296]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48296]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48296]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48296]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48296]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48297]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48297]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48297]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48297]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48297]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48298]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48298]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48298]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48298]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48298]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48299]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48299]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48299]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48299]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48299]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48300]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48300]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48300]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48300]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48300]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[26835]: [dix] couldn't enable device 10
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[26835]: [dix] couldn't enable device 11
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[26835]: [dix] couldn't enable device 12
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48301]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48301]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48301]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48301]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48301]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48302]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48302]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48302]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48302]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48302]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48303]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48303]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48303]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48303]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48303]: Errors from xkbcomp are not fatal to the X server
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48304]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48304]: > Warning:          Unsupported maximum keycode 569, clipping.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48304]: >                   X11 cannot support keycodes above 255.
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48304]: > Internal error:   Could not resolve keysym Invalid
Apr 04 19:11:28 xps7390 /usr/lib/gdm-wayland-session[48304]: Errors from xkbcomp are not fatal to the X server

Reporting the issue here because sway appears to work fine other than not having a waybar.

Commenting swaybar_command waybar in the sway config didn't solve the issue (still no bar with swaybar), so maybe the issue is with sway after all :thinking:  Nobody else having issues?

Same here, restarted my laptop and waybar is suddenly missing, even though I can see the process running. If I run waybar in a terminal it doesn't print any errors, but the bar does not appear.

Personally, this happened when upgrading gtk3 to the latest version (as of writing this, 1:3.24.17-2 )
Downgrading to the previous one, such as 1:3.24.16-1 fixed multiple issues for me (waybar & wofi)
I am curious about what got changed for gtk3 that could cause such issues 😬

Dups of #642

have such an issue after upgrading that packets today
libnftnl 1.1.5-1 -> 1.1.6-1
faudio 20.03-1 -> 20.04-1
gtk-update-icon-cache 1:3.24.16-1 -> 1:3.24.17-2
gtk3 1:3.24.16-1 -> 1:3.24.17-2
firefox 74.0-2 -> 74.0.1-1
fzf <IP_ADDRESS>-1 -> 0.21.1-1
hwloc 2.1.0-2 -> 2.2.0-1
iproute2 5.5.0-1 -> 5.6.0-1
lib32-faudio 20.03-1 -> 20.04-1
libwps 0.4.10-1 -> 0.4.11-1
linux-firmware 20200224.efcfa03-1 -> 20200316.8eb0b28-1
lsp-plugins 1.1.15-1 -> 1.1.17-1
metasploit 5.0.81-1 -> 5.0.83-1
netctl 1.20-2 -> 1.21-2
python-werkzeug 1.0.0-2 -> 1.0.1-1
python-flask 1.1.1-3 -> 1.1.2-1
sbcl 2.0.1-1 -> 2.0.3-1
vim-runtime 8.2.0343-1 -> 8.2.0510-1
vim 8.2.0343-1 -> 8.2.0510-1
yad 5.0-1 -> 6.0-1

$ waybar
[2020-04-05 13:39:06.331] [info] Resources files: /home/nikto_b/.config/waybar/config, /home/nikto_b/.config/waybar/style.css
[2020-04-05 13:39:06.343] [warning] For a functional tray you must have libappindicator-* installed and export XDG_CURRENT_DESKTOP=Unity

$ yaourt -Qs sway
community/sway 1:1.4-8
    Tiling Wayland compositor and replacement for the i3 window manager
community/swaybg 1.0-3
    Wallpaper tool for Wayland compositors
community/swayidle 1.6-1
    Idle management daemon for Wayland
community/swaylock 1.5-1
    Screen locker for Wayland
local/swaylock-blur-bin 0.3.1-1
    A small Rust program that runs swaylock and sets the image to a blurred screenshot of the desktop
community/waybar 0.9.1-1
    Highly customizable Wayland bar for Sway and Wlroots based compositors
local/wf-recorder-git r106.ccbd0c7-1
    A video recorder for wlroots-based compositors like sway or wayfire

any fixes will be for gtk3 1:3.24.17-2?

As above, the issue is with gtk3. You need to wait for the fixed package to be released. (Maybe ask Arch to yank the broken gtk3.)
As a quick workaround in the meantime, if you still have the older working gtk3 version in your pkg cache you can install it:
sudo pacman -U /var/cache/pacman/pkg/gtk3-1\:3.24.16-*

installing the gtk3-1:3.24.17+4+g8c97702a07-2-x86_64 instead of yesterday gtk3-1:3.24.17-2-x86_64 fixes this issue


Remove unnecessary statement in Session tracking

Amplitude Developer Docs PR
Description
Looks like a copy pasta error duplicating info from the page views section. In the context of session tracking this first section removed is confusing.
Deadline
Now
Change type

[ ] Doc bug fix. Fixes #[insert issue number]. Amplitude contributors include Jira issue number.
[x] Doc update.
[ ] New documentation.
[ ] Non-documentation related fix or update.

PR checklist:

[x] My documentation follows the style guidelines of this project.
[ ] I previewed my documentation on a local server using mkdocs serve.
[ ] Running mkdocs serve didn't generate any failures.
[ ] I have performed a self-review of my own documentation.

@amplitude-dev-docs

@justin-fiedler @bgiori can we get this reviewed?


Fix typo in example

There's a small typo on https://docs.rs/git-version/0.3.4/git_version/macro.git_version.html

Nice catch, thanks! :)


Web support

Hi, your library is awesome and thanks for that!
On Linux and Windows works as a charm.
But on web, dart compiler throws Unsupported operation: _Namespace .
Please could you fix it?
Thanks for reply.

Thanks,
Currently the library need 'dart:io' for reading local file when compiles, if I strip the compiler and just leaves the interpreter, it might be okay to run in browser.
I maybe try this later.
Currently I'm not working on this project, I might return to work several weeks later.

I think it's still beneficial to support web too. The scripts are strings, so they can be loaded on the fly. If we don't use import, we can load them from server or other sources.

Is there other problem. Dart js sdk dont support 64 bit data type (int and double) .

It needs some fundamental structure change to achieve web support.
I have to rewrite module and context implementation to strip the dart:io dependency. And it needs an outside tool to achieve import without dart:io in the library.
If this is needed for a lot people, I need to make the decision now before it's too late to change this project.
So if any other people are using this library and have thoughts on this issue feel free to share with me.

Since 0.3.1, hetu script supported web platform.
for file system handling, use another package: hetu_script_dev_tools
for flutter, use: hetu_script_flutter

Thanks a lot!! In few days i will try it.

Hi unfortunately, when you try to run the script. I get this exception
The following HTError object was thrown building FutureBuilder<void>(dirty, state: _FutureBuilderState<void>#28e7b):
  File: hetu:value
Line: 0, Column: 0
Runtime error: extern
Message: Unsupported operation: Int64 accessor not supported by dart2js.
Dart stack trace:
dart-sdk/lib/_internal/js_dev_runtime/private/ddc_runtime/errors.dart 251:49  throw_
packages/hetu_script/interpreter/interpreter.dart 242:7                       handleError
packages/hetu_script/interpreter/interpreter.dart 286:9                       evalSource
packages/hetu_script/interpreter/abstract_interpreter.dart 161:20             eval
packages/hetu_script/interpreter/abstract_interpreter.dart 110:9              init
packages/hetu_script/interpreter/interpreter.dart 184:11                      init

Hi unfortunately, when i try to run the script. I get this exception
The following HTError object was thrown building FutureBuilder<void>(dirty, state: _FutureBuilderState<void>#28e7b):
  File: hetu:value
Line: 0, Column: 0
Runtime error: extern
Message: Unsupported operation: Int64 accessor not supported by dart2js.
Dart stack trace:
dart-sdk/lib/_internal/js_dev_runtime/private/ddc_runtime/errors.dart 251:49  throw_
packages/hetu_script/interpreter/interpreter.dart 242:7                       handleError
packages/hetu_script/interpreter/interpreter.dart 286:9                       evalSource
packages/hetu_script/interpreter/abstract_interpreter.dart 161:20             eval
packages/hetu_script/interpreter/abstract_interpreter.dart 110:9              init
packages/hetu_script/interpreter/interpreter.dart 184:11                      init

int64 is another issue, but I'm not sure what exact is  the class that

Maybe because this method?
  /// Fetch a int64 from the bytes list
  int readInt64() {
    final start = ip;
    ip += 8;
    return bytes.buffer.asByteData().getUint64(start);
  }

Could you check the branch web_fix to see if it works?
I changed the method from int64 into int32 in that branch.

IMHO this method has smae issue
 /// Fetch a float64 from the bytes list
  double readFloat64() {
    final start = ip;
    ip += 8;
    return bytes.buffer.asByteData().getFloat64(start);
  }

Flutter for web doesnt support 64bit variable. Only 32bit. This is core of this issue

Okay I changed both the compiler and bytecode reader, and I tested in chrome (flutter run -d chrome), it seems okay for me to run a example in web now.

The problem is little more complicated.

variable must load as 32bit  (bytecode_reader.dart)
variable must stored as 32bit (compiler.dart)

This fork works as a charm for me.
https://github.com/aleslanik2/hetu-script/commit/044fcdf87da620cc8ccd031e35985cca9f1ddc52

But I have no idea what other consequences this may cause.

Yes I have tried it out myself. And I will merge this change into master branch.

I have added BigInt class binding in case we need to manipulate bigger integers after we changed it from 64 to 32.

Thanks so much for your work!


[add-resource] New Plugin: Google Charts

For your consideration: Perlkonig/grav-plugin-google-charts
Embeds Google charts into pages via shortcode

I believe you must name the release 1.0.0, instead of Grav Plugin: Google Charts in https://github.com/Perlkonig/grav-plugin-google-charts/releases/tag/v1.0.0` or the GPM won't pick it up, @w00fz am I right?

Hasn't been a problem so far. They just want the tag. If you download the zip file, it's actually named v1.0.0.zip.

https://github.com/Perlkonig/grav-plugin-google-charts/releases/tag/v1.0.0

This is fine, the important thing is you keep consistency when you release, meaning that you always tag with v prefix and don't switch to version without the v prefix.
Going to add it

Added! Should be available soon.

Ok, was a doubt of mine :)


Chocolatey: Create package from scratch

https://twitter.com/ddieppa/status/1042875121550196736

For example, perhaps this application:
https://github.com/sharkdp/bat

bat has already been created: https://chocolatey.org/packages/Bat

Perhaps this could be a good one to do as well: https://github.com/zricethezav/gitleaks

@gep13 you could also just look through the many open requests for packages
https://github.com/chocolatey-community/chocolatey-package-requests/issues?utf8=✓&q=is%3Aissue+is%3Aopen+label%3A"Status%3A+Available+For+Maintainer(s)"+RFP
Just mention on the issue that you will be using it in the stream? (and mark it as in progress)

@AdmiringWorm yip, that makes sense!

Just be quick, @chtof is gobling them down like crazy :smile:

Ha ha, yip, I noticed that a LOT of them were disappearing!


UT2k4 - Command not found

[ut2k4server@server ~]$ ./ut2k4server start
./ut2k4server: line 186: fn_startserver: command not found
I noticed you have been changing a lot of code today. Maybe this has something to do with it.

Yup its probably a bug I didn't spot. I will fix asap. Thanks for spotting this.

Try deleting the functions dir as you may have outdated functions.

That did not work.
Tried removing the functions directory and running the install again. Same error.

When starting the script it gives this too.
./ut2k4server: line 161: fn_rootcheck: command not found

Fixed :)
https://github.com/dgibbs64/linuxgameservers/commit/64a32515a08b39b507aeb6595ff71437da966612

Not sure its fixed. Now it does not download the server files.
=================================
Unreal Tournament 2004
Linux Game Server Manager
by Daniel Gibbs
http://danielgibbs.co.uk
./ut2k4server: line 66: fn_ut2k4filesdl: command not found
Installing Unreal Tournament 2004 Server
Extracting dedicatedserver3339-bonuspack.zip
unzip:  cannot find or open dedicatedserver3339-bonuspack.zip, dedicatedserver3339-bonuspack.zip.zip or dedicatedserver3339-bonuspack.zip.ZIP.
Extracting ut2004-lnxpatch3369-2.tar.bz2
tar (child): ut2004-lnxpatch3369-2.tar.bz2: Cannot open: No such file or directory
tar (child): Error is not recoverable: exiting now
tar: Child returned status 2
tar: Error is not recoverable: exiting now

Ouphs i forgot to add the functions to fn_functions. I have now resolved that issue as well. remove functions dir again to reload them.

that did it.
Thanks for the great work!!


onFilter is not called when the text in the input is empty

Also happen with select filter.

I confirm this issue. When I reset select filter, onFilter hook is not fired at all (react-bootstrap-table2-filter@1.3.0).

hi, any update on this issue?


libmbim: 1.24.0 -> 1.24.2

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/libmbim/versions.
meta.description for libmbim is: "Library for talking to WWAN modems and devices which speak the Mobile Interface Broadband Model (MBIM) protocol"
meta.homepage for libmbim is: "https://www.freedesktop.org/wiki/Software/libmbim/"
meta.changelog for libmbim is: ""
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 1.24.2 with grep in /nix/store/fsn8ixqv4qy94q86gxa6sqgwvqdj83zi-libmbim-1.24.2

directory tree listing: https://gist.github.com/9787e01d83ead221ce01069fdca1869f

du listing: https://gist.github.com/2402f50d573a331a3624bf6b1a4a14f1

Rebuild report (if merged into master) (click to expand)

1406 total rebuild path(s)

493 package rebuild(s)

493 x86_64-linux rebuild(s)
458 i686-linux rebuild(s)
6 x86_64-darwin rebuild(s)
449 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
adapta-gtk-theme
almanah
apostrophe
areca
astroid
azureus
balsa
birdfont
blueman
bolt
bomber
bomi
bookworm
bovo
calls
cawbird
chrome-gnome-shell
cinnamon.cinnamon-control-center
citrix_workspace
citrix_workspace_19_12_0
citrix_workspace_20_04_0
citrix_workspace_20_06_0
claws-mail
claws-mail-gtk3
clight
deepin.dde-control-center
deepin.dde-daemon
deepin.dde-dock
deepin.dde-file-manager
deepin.dde-kwin
deepin.dde-launcher
deepin.dde-session-ui
deepin.startdde
deja-dup
dino
discover
dolphin
dragon
dropbox-cli
eclipse-mat
eclipses.eclipse-committers
eclipses.eclipse-cpp
eclipses.eclipse-java
eclipses.eclipse-modeling
eclipses.eclipse-platform
eclipses.eclipse-scala-sdk
eclipses.eclipse-sdk
eid-mw
elementary-planner
empathy

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/fsn8ixqv4qy94q86gxa6sqgwvqdj83zi-libmbim-1.24.2 \
  --option binary-caches 'https://cache.nixos.org/ https://r-ryantm.cachix.org/' \
  --option trusted-public-keys '
  r-ryantm.cachix.org-1:gkUbLkouDAyvBdpBX0JOdIiD2/DP1ldF3Z3Y6Gqcc4c=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(r-ryantm's Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A libmbim https://github.com/r-ryantm/nixpkgs/archive/ca2371238e761b6bc62022bb3d9d687eadcfe9ca.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/fsn8ixqv4qy94q86gxa6sqgwvqdj83zi-libmbim-1.24.2
ls -la /nix/store/fsn8ixqv4qy94q86gxa6sqgwvqdj83zi-libmbim-1.24.2/bin

Pre-merge build results
NixPkgs review skipped

Maintainer pings

Changes look okay: https://lists.freedesktop.org/archives/libmbim-devel/2020-July/001106.html


Table of Contents in a seperate file

Hi friend, I love this plugin so much it is awesome. One thing I would love is being able to put the table of contents for a note in a separate note.
The reason being is that I take notes for my lessons and each lesson is in a separate note in a folder for that class. Then I make a quick reference for that folder to quickly get to the chapters I need. But if I make a table of contents inside of a note for another note than that would be perfect! You could include the specific note or notes that you would like to make that table of contents for in the code block and then it would go through like normal.
Thanks again for your great plugin!
Have a great day.

Got it!


test showing two problems with user types

they must be public classes, or Hibernate refuses to instantiate them
even after making it public the EnhancedUserType fails in a trivial test

Apparently the second problem is now also fixed.


Problems with COWs

Hello,
I am considering to use COWs for a case when the discriminating variable correlates with the control variable, however I have encountered a  problem when the discriminating variable  has negative values.
Even if only lower bound of mrange argument is negative, then all values of W-matrix are nan and the computation fails with the following exception:
/cvmfs/belle.cern.ch/el7/externals/v01-12-01/Linux_x86_64/common/lib/python3.8/site-packages/sweights/cow.py:112: IntegrationWarning: The maximum number of subdivisions (50) has been achieved.
  If increasing the limit yields no improvement it is advised to analyze
  the integrand in order to determine the difficulties.  If the position of a
  local difficulty can be determined (singularity, discontinuity) one will
  probably gain from splitting up the interval and calling the integrator
  on the subranges.  Perhaps a special-purpose integrator should be used.
  N = quad(f, *self.mrange)[0]
/cvmfs/belle.cern.ch/el7/externals/v01-12-01/Linux_x86_64/common/lib/python3.8/site-packages/sweights/cow.py:124: RuntimeWarning: divide by zero encountered in divide
  return self.gk[k](m) * self.gk[j](m) / self.Im(m)
Initialising COW:
/cvmfs/belle.cern.ch/el7/externals/v01-12-01/Linux_x86_64/common/lib/python3.8/site-packages/sweights/cow.py:127: IntegrationWarning: The maximum number of subdivisions (50) has been achieved.
  If increasing the limit yields no improvement it is advised to analyze
  the integrand in order to determine the difficulties.  If the position of a
  local difficulty can be determined (singularity, discontinuity) one will
  probably gain from splitting up the interval and calling the integrator
  on the subranges.  Perhaps a special-purpose integrator should be used.
  return quad(integral, self.mrange[0], self.mrange[1])[0]
    W-matrix:
	[[nan nan]
	  [nan nan]]
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
Cell In [291], line 10
      8 mrange = (binning[0], binning[-1])
      9 Im = 1
---> 10 cw = Cow(mrange, sig_pdf_obj, bkg_pdf_obj, Im, renorm=True, verbose=True)
     11 sweighter = SWeight(test_mc_df[c_var].values,
     12                     [sig_pdf_obj,bkg_pdf_obj],
     13                     [len(test_mc_df)*1.0-len(app_bkg_df),len(app_bkg_df)*1.],
   (...)
     16                     compnames=('sig','bkg'),
     17                     verbose=True, checks=False )

File /cvmfs/belle.cern.ch/el7/externals/v01-12-01/Linux_x86_64/common/lib/python3.8/site-packages/sweights/cow.py:105, in Cow.__init__(self, mrange, gs, gb, Im, obs, renorm, verbose)
    102     print("\t" + str(self.Wkl).replace("\n", "\n\t "))
    104 # invert for Akl matrix
--> 105 self.Akl = linalg.solve(self.Wkl, np.identity(len(self.Wkl)), assume_a="pos")
    106 if verbose:
    107     print("    A-matrix:")

File ~/.local/lib/python3.8/site-packages/scipy/linalg/_basic.py:140, in solve(a, b, sym_pos, lower, overwrite_a, overwrite_b, check_finite, assume_a, transposed)
    137 # Flags for 1-D or N-D right-hand side
    138 b_is_1D = False
--> 140 a1 = atleast_2d(_asarray_validated(a, check_finite=check_finite))
    141 b1 = atleast_1d(_asarray_validated(b, check_finite=check_finite))
    142 n = a1.shape[0]

File ~/.local/lib/python3.8/site-packages/scipy/_lib/_util.py:287, in _asarray_validated(a, check_finite, sparse_ok, objects_ok, mask_ok, as_inexact)
    285         raise ValueError('masked arrays are not supported')
    286 toarray = np.asarray_chkfinite if check_finite else np.asarray
--> 287 a = toarray(a)
    288 if not objects_ok:
    289     if a.dtype is np.dtype('O'):

File ~/.local/lib/python3.8/site-packages/numpy/lib/function_base.py:627, in asarray_chkfinite(a, dtype, order)
    625 a = asarray(a, dtype=dtype, order=order)
    626 if a.dtype.char in typecodes['AllFloat'] and not np.isfinite(a).all():
--> 627     raise ValueError(
    628         "array must not contain infs or NaNs")
    629 return a

ValueError: array must not contain infs or NaNs

One can obtain this result with the tutorial notebook by setting the nrange to (-1,1).

Tagging @matthewkenzie

Thank you for raising this. An unusual and interesting issue, I will investigate it.
For now perhaps I can suggest (horrible hack I know) shifting the entire distribution so that x values are all positive, this will not impact the weights.

@Bilokin I cannot reproduce this with the current version. There is no nrange in the tutorial, do you mean mrange?
Please provide a minimal code example which triggers this bug.

I am closing this for lack of feedback.


[@auth] access control using object / field auth

Amplify CLI Version
3.17.0
What AWS Services are you utilizing?
AppSync
Provide additional details e.g. code snippets
My requirement for my object is two fold:

signed-in user can CRUD all fields
public apiKey access can read all fields and can update only state field and can't create / delete

Tried this:
type MyObject
  @model(subscriptions: null)
  @auth(rules: [
    {allow: private}
  ])
{
  id: ID!
  name: String
  state: String
    @auth(rules: [
      {allow: private, operations: [create, read, update, delete]},
      {allow: public, provider: apiKey, operations: [read, update]}
    ])
}

What's happening ok:
private access can CRUD all fields.
public access can't create / delete, can read all fields and can update state field.
What's happening not ok:
public access can still update name field. How can I disable this?
#2241 maybe related, current document is too confusing for me to fully understand..

@bob-lee I am working on this, will get back to you.

Hi @bob-lee , to restrict access you would need to define the allow:private rule on all the field to restrict access. We are in the process of making improvements to this work around.

@ammarkarachi thanks for update. I tried below hoping public access cannot update state field but had no success.
type MyObject
  @model(subscriptions: null)
{
  id: ID!
    @auth(rules: [
      {allow: private},
      {allow: public, provider: apiKey, operations: [read, update]}
    ])
  name: String
    @auth(rules: [
      {allow: private},
      {allow: public, provider: apiKey, operations: [read, update]}
    ])
  state: String
    @auth(rules: [
      {allow: private},
      {allow: public, provider: apiKey, operations: [read]}
    ])
}

@bob-lee I am sorry for the delay. I would suggest using Cognito for finer grained control over fields. Let me know if that answers your question


##[error]Cannot read property 'login' of null

Got a problem with a specific developer where any action started from him, and only from him will result on this error:
##[error]Cannot read property 'login' of null
My current action look like this:
- name: Send RocketChat notification - job started
uses<EMAIL_ADDRESS>if: always()
timeout-minutes: 3
continue-on-error: true
with:
type: ${{ job.status }}
job_name: ':robot: ${{ env.APP_NAME }} CI/CD - Starting job... | Current status: '
icon_emoji: ':hammer_pick:'
channel: '#devops'
url: ${{ secrets.ROCKETCHAT_WEBHOOK }}
commit: true
token: ${{ secrets.GITHUB_TOKEN }}
Looking at the code:
const authorName: string = commit.author.login;
I have absolutely no idea about why the payload would've commit.author as null but I can confirm if that's the actual case if this helps.
Any chance of adding a validation there and letting it pass through empty? I'll do a PR if that sounds alright
Thanks!

Well, I'm closing this for now as the problem got resolved by itself after my coworker updated all of his Github settings, even though he already had all vital infos fulfilled at first. Our theory is that his infos weren't updated for too long (like.. many, many years ago) and maybe Github didn't have his author.login where it needed to be.
Thanks anyway!


Configurable sources

TODO: documentation (existence of config, where to place user config, update photos/gifs with SMK8)

I can confirm this runs fine on my machine. I haven't tested super extensively but normal usage appears to work.

Merging into master for now without pushing to AnkiWeb, thanks again for testing it!


Fixed typo in log message

What this PR does / why we need it:
The pull request fixes a minor typo in the log message of the dependency watchdog probe code.
Which issue(s) this PR fixes:
None.
Special notes for your reviewer:
Release note:

Thanks @ScheererJ  for the PR.
We are in works to refactor the DWD as we were not happy with not just the way some of the terms are defined like resultRun which doesn't convey anything meaningful, but we also intend to make the behavior more deterministic as we observed with race conditions spurring with recently introduced secret rotation in gardener as well as handling of meltdown scenarios where it wasn't sure how long should one wait for a dependent component to scale down.
@unmarshall  is currently in the process of publishing the new approach to the community which should be out soon. The implementation for the same is already underworks.  So i'll rather close this in lieu of overhauling,  wdyt?
@rishabh-11  may be you can run a spell-check on the new code base to verify if such typos still exist in the new codebase.

Yes i agree. We will double check all logs that DWD emits to ensure that it clearly depicts the message without spelling mistakes.
@ScheererJ i will publish the new approach soon. Implementation is also going at a good pace. Once we finish proper testing we will release the new version of DWD prober initially which will a lot of improvements. This is a very small change and if you still wish to merge this change i don't have any reasons to block it :)

@ashwani2k & @unmarshall: Thanks for the heads-up. Feel free to close or merge this pull request at your convenience. It is certainly not very important, especially if the dependency watchdog is anyway rewritten.

/close as we shall take care of it during refactoring PR.


Make stumps harder to destroy by way of nearby creeper explosions

I just think it makes stump removers kinda pointless.  Especially since they cost two bait items to make when early game, that's a precious resource.

I agree with Hirachosan on this one. Using creepers to destroy stump is tedious enough for stump removers to become useful.

Yeah personally I think it's fine as is as well


fix: Pivot Table can't display Null value

substitute NULL_STRING in PivotTableViz Class for any nulls in the necessary columns
SUMMARY
substitute NULL_STRING in PivotTableViz Class for any nulls in the necessary columns
ADDITIONAL INFORMATION

[x] Has associated issue:
[x ] Changes UI
[x ] Requires DB Migration.
[ x] Confirm DB Migration upgrade and downgrade tested.
[ x] Introduces new feature or API
[ x] Removes existing feature or API

On second thought, you can probably also use the fill_value argument in pivot_table, it might be more performant. See: https://pandas.pydata.org/pandas-docs/stable/reference/api/pandas.pivot_table.html

On second thought, you can probably also use the fill_value parameter in pivot_table, it might be more performant. See: https://pandas.pydata.org/pandas-docs/stable/reference/api/pandas.pivot_table.html

I try to use fill_value slove this bug, but fail it. it's same error.

Ok, thanks for trying. It seems CI flaked out, I'll restart.

Ok, thanks for trying. It seems CI flaked out, I'll restart.

Thanks

Codecov Report

Merging #10377 into master will increase coverage by 4.99%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master   #10377      +/-   ##
==========================================
+ Coverage   65.46%   70.46%   +4.99%
==========================================
  Files         603      603
  Lines       32436    32437       +1
  Branches     3297     3297
==========================================
+ Hits        21234    22856    +1622
+ Misses      11018     9475    -1543
+ Partials      184      106      -78

Flag
Coverage Δ

#cypress
55.39% <ø> (?)

#javascript
59.36% <ø> (ø)

#python
69.78% <0.00%> (+0.03%)
:arrow_up:

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

Impacted Files
Coverage Δ

superset/viz.py
57.04% <0.00%> (ø)

...src/components/FilterableTable/FilterableTable.tsx
81.77% <0.00%> (-0.41%)
:arrow_down:

superset/sql_lab.py
78.35% <0.00%> (+0.43%)
:arrow_up:

...rontend/src/SqlLab/components/AceEditorWrapper.tsx
56.98% <0.00%> (+1.07%)
:arrow_up:

...ashboard/components/gridComponents/ChartHolder.jsx
78.57% <0.00%> (+1.42%)
:arrow_up:

superset-frontend/src/utils/common.js
74.62% <0.00%> (+1.49%)
:arrow_up:

...perset-frontend/src/components/CopyToClipboard.jsx
36.36% <0.00%> (+1.51%)
:arrow_up:

...hboard/components/resizable/ResizableContainer.jsx
71.87% <0.00%> (+1.56%)
:arrow_up:

superset/result_set.py
98.31% <0.00%> (+1.68%)
:arrow_up:

...src/explore/components/controls/VizTypeControl.jsx
78.84% <0.00%> (+1.92%)
:arrow_up:

... and 148 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 3c39b26...9161536. Read the comment docs.

It's not better to handle this like DistribuationBarViz handled this?
And do this for other classes
https://github.com/apache/incubator-superset/blob/9b8da402955d3adcebaf7b711b79e0cfd720d025/superset/viz.py#L1624-L1627

please review this PR#10390. we have been tested in our development.

@villebro Today, we fix some bug, more precisely fill Null String in Dataframe. Please review this PR and merge it first. Because I am not sure whether my modifications in other classes are correct. refer New PR#10390


BUG: Vertical black lines

Sometimes when drawing on the canvas, vertical black lines will appear. They seem to move positions when painting a new pixel.

@jkl3848 Strange. Can you please post a video clearly showing the behaviour?
Also if you have steps to reproduce the issue, that would be helpful for me.

Also what are the purple lines and when specificaly does this happen

I'm no longer able to replicate this issue. Perhaps it was fixed. But I am getting a similar issue with white lines. This is less of a problem tho because it stays within the shape and doesn't extend out.
https://github.com/user-attachments/assets/f6a69712-155e-4ce2-bbb2-297ba2818b44

I'm no longer able to replicate this issue. Perhaps it was fixed. But I am getting a similar issue with white lines. This is less of a problem tho because it stays within the shape and doesn't extend out.

Hmmm, I think I have an idea what is going on. What browser are you using and what is your zoom level?
I remember that sometimes when I would zoom out/in on the canvas with my trackpad, I sometimes see faint lines around each canvas tile.
https://github.com/user-attachments/assets/cd15f8d7-a93c-4810-af01-a4f9b40913b2
and here's a screenshot to show them off more

@jkl3848 Hey again. Any word on this? Wondering if this issue still exists? If not, we can close :)


Datapoint source redundancy

Close #133

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

10 of 54 (18.52%)  changed or added relevant lines in 8 files are covered.
3 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.2%) to 61.366%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

core/src/datapoint_source/erg_xau/coingecko.rs
8
9
88.89%

core/src/datapoint_source/erg_xau.rs
0
3
0.0%

core/src/datapoint_source/predef.rs
0
5
0.0%

core/src/datapoint_source.rs
0
6
0.0%

core/src/datapoint_source/custom_ext_script.rs
0
8
0.0%

core/src/main.rs
0
10
0.0%

core/src/datapoint_source/aggregator.rs
0
11
0.0%

Files with Coverage Reduction
New Missed Lines
%

core/src/pool_commands.rs
1
0%

core/src/main.rs
2
0%

Totals

Change from base Build<PHONE_NUMBER>:
-0.2%

Covered Lines:
1968

Relevant Lines:
3207

💛  - Coveralls


Fix typo in docs

The docs said "your app while launch by the specified time" which was changed to "your app will launch at the specified time".

Ahh, nice catch! Thanks for this.


intelmetool: 4.14 -> 4.19

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/intelmetool/versions.
meta.description for intelmetool is: "Dump interesting things about Management Engine"
meta.homepage for intelmetool is: "https://www.coreboot.org"
meta.changelog for intelmetool is: ""
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 4.17 in filename of file in /nix/store/bm2f0ra18mvqia2dxvas9cnnl9wabbmw-intelmetool-4.17

Rebuild report (if merged into master) (click to expand)

13 total rebuild path(s)

13 package rebuild(s)

First fifty rebuilds by attrpath
acpidump-all
amdfwtool
cbfstool
cbmem
coreboot-utils
diffoscope
ectool
ifdtool
intelmetool
inteltool
msrtool
nvramtool
superiotool

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/bm2f0ra18mvqia2dxvas9cnnl9wabbmw-intelmetool-4.17 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A intelmetool https://github.com/r-ryantm/nixpkgs/archive/b81069c55278477a22284219ee504d07031e2eab.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/bm2f0ra18mvqia2dxvas9cnnl9wabbmw-intelmetool-4.17
ls -la /nix/store/bm2f0ra18mvqia2dxvas9cnnl9wabbmw-intelmetool-4.17/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

13 packages built:

acpidump-all
amdfwtool
cbfstool
cbmem
coreboot-utils
diffoscope
ectool
ifdtool
intelmetool
inteltool
msrtool
nvramtool
superiotool

Maintainer pings
cc @felixsinger @yu-re-ka for testing.

@ofborg build coreboot-utils

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/intelmetool/versions.
meta.description for intelmetool is: "Dump interesting things about Management Engine"
meta.homepage for intelmetool is: "https://www.coreboot.org"
meta.changelog for intelmetool is: ""
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 4.18 in filename of file in /nix/store/9py8b61lg10v20qqzqm5qagw82sjw3f9-intelmetool-4.18

Rebuild report (if merged into master) (click to expand)

14 total rebuild path(s)

14 package rebuild(s)

First fifty rebuilds by attrpath
acpidump-all
amdfwtool
cbfstool
cbmem
coreboot-configurator
coreboot-utils
diffoscope
ectool
ifdtool
intelmetool
inteltool
msrtool
nvramtool
superiotool

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/9py8b61lg10v20qqzqm5qagw82sjw3f9-intelmetool-4.18 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A intelmetool https://github.com/r-ryantm/nixpkgs/archive/e64fbd7bf87f1ca76d55d6ee1df406d0d560f1ee.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/9py8b61lg10v20qqzqm5qagw82sjw3f9-intelmetool-4.18
ls -la /nix/store/9py8b61lg10v20qqzqm5qagw82sjw3f9-intelmetool-4.18/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

2 packages failed to build:

amdfwtool
coreboot-utils

12 packages built:

acpidump-all
cbfstool
cbmem
coreboot-configurator
diffoscope
ectool
ifdtool
intelmetool
inteltool
msrtool
nvramtool
superiotool

Maintainer pings
cc @felixsinger @yu-re-ka for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/intelmetool/versions.
meta.description for intelmetool is: Dump interesting things about Management Engine
meta.homepage for intelmetool is: https://www.coreboot.org
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 4.19 in filename of file in /nix/store/wr8f3a2kdqkizdwjj6kdr68k0aaqqhwv-intelmetool-4.19

Rebuild report (if merged into master) (click to expand)

14 total rebuild path(s)

14 package rebuild(s)

First fifty rebuilds by attrpath
acpidump-all
amdfwtool
cbfstool
cbmem
coreboot-configurator
coreboot-utils
diffoscope
ectool
ifdtool
intelmetool
inteltool
msrtool
nvramtool
superiotool

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/wr8f3a2kdqkizdwjj6kdr68k0aaqqhwv-intelmetool-4.19 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A intelmetool https://github.com/r-ryantm/nixpkgs/archive/8c0f70f77ac06f24bc61b114aa8fa26b876bc2b1.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/wr8f3a2kdqkizdwjj6kdr68k0aaqqhwv-intelmetool-4.19
ls -la /nix/store/wr8f3a2kdqkizdwjj6kdr68k0aaqqhwv-intelmetool-4.19/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

4 packages failed to build:

acpidump-all
amdfwtool
coreboot-utils
msrtool

10 packages built:

cbfstool
cbmem
coreboot-configurator
diffoscope
ectool
ifdtool
intelmetool
inteltool
nvramtool
superiotool

Maintainer pings
cc @felixsinger @yu-re-ka for testing.

The current release binary has some issues and we are working on it getting this fixed. Please use the git repository instead. The release tag from there is fine.

Also, update the title of this pull request and commit. It should be coreboot-utils instead of intelmetool.


Adding support for new bedrock vue manager classes

This is the companion pull request to https://github.com/concrete5/bedrock/pull/61 - please check there for more details.

Updated the pull request to address feedback on the bedrock PR


Running samplestack on ml-gradle

The main changes here are:

Most of the custom tasks are gone in favor of existing tasks in ml-gradle
I re-organized the database config files and modules under database/ml-config and database/ml-modules

I kept MarkLogicSlurpTask largely as-is, as it contains a good amount of logic that is specific to samplestack. And I think it's a nice demo then of how if ml-gradle doesn't do something that you want, it's easy to make a custom task that does exactly what you want.
For testing, I did a new install of ML and ran "gradle appserver", and everything ran fine. This was done on ML 8.0-3.

I've had a chance to look at these changes -- I think it's a really good step for samplestack, not sure whether the PR is being analyzed by ss team...

Rob, could you help me understand the purpose behind rearranging the files in the repo? Was this necessary, did it make things easier?

Hey Daphne - the separation of ML config and modules is what ml-app-deployer expects by default, and the organization of ml-config is based on the management API.
I think it's a bit easier to understand for someone new to ML - they can go to the management API docs and seem the same breakout in the docs as they do in the ml-config directory.
The ml-modules directory structure is based on how samplestack is already organized.

I've verified this PR from the java side.  I think it's ready to go.  I also think its a great step forward for samplestack as it gets rid of many lines of code and takes the build stuff out of customizations.

Charles - I'm going to add support for mimetypes and then call ml-gradle a "2.0", and then I'll update the PR for this to include the latest version and the simplified buildscript (since only jcenter() is needed).


Update CSS on index.html

Added Media Print to only show right side on printing

Closing as already merged. Refer to #77. Thanks @dennyschwender!


Typescript Playground > New

Bug Report

🔎 Search Terms

🕗 Version & Regression Information
After TS4.4 beta.
Please keep and fill in the line that best applies:
-->

I was unable to test this on prior versions because this is a new option

⏯ Playground Link
The following playground link was generated by the share button. It contains:
https://www.typescriptlang.org/play?ts=4.4.0-beta&exactOptionalPropertyTypes=true#code/JYOwLgpgTgZghgYwgAgArQM4HsTIN4BQyxyIcAthAFzIZhSgDmANESXIxAPw0gCu5AEbQA3AQC+BAghx1kAB0w4a6KNlwBefG2JlKNAEQAROCGAQANgdYlkHasgBMAdgliCAE0sRICpSAA6exFiAHpQ5AAVAAsULEUoUw9kLBg7ZAByLwsfCAyUhLgwLChkcj45YQKwYBw4CwCpAiA
💻 Code

// We can quickly address your report if:
//  - The code sample is short. Nearly all TypeScript bugs can be demonstrated in 20-30 lines of code!
//  - It doesn't use external libraries. These are often issues with the type definitions rather than TypeScript bugs.
//  - The incorrectness of the behavior is readily apparent from reading the sample.
// Reports are slower to investigate if:
//  - We have to pare too much extraneous code.
//  - We have to clone a large repo and validate that the problem isn't elsewhere.


fix for #38

portaudio-sharp uses LPStr as a string mapping method, this will lose some of the data for non-ANSI strings.
Changing the string mapping of the name member of PaDeviceInfo in portaudio-sharp from LPStr(ANSI) to LPWStr(Unicode) solves the problem perfectly.Changing the string mapping of the name member of PaDeviceInfo in portaudio-sharp from LPStr(ANSI) to LPWStr(Unicode) solves the problem perfectly.

@vasilevp Do you want to review and merge it? I have moved almost entirely to MacOS and have not used flexASIO in ages, let alone worked on the repo...

I think I may be mistaken about what's causing the problem, it's actually the fact that PortAudio no longer uses ANSI strings internally but Unicode strings instead, so that causes the old PortAudio-sharp string mapping to garble errors.
However, the code that needs to be merged is fine, but the logic of the fix is a bit wrong.

PortAudio 在内部不再使用 ANSI 字符串，而是使用 Unicode 字符串

PortAudio 始终以 UTF-8 格式返回设备名称，据我所知，情况一直如此。

But I found something in PortAudio about ANSI string changing to UTF-8 string, so I'm guessing that a long time ago (when PortAudio-Sharp was developed) PortAudio used to use ANSI strings to return the device name.


Cassandra link broken

Cassandra released 3.6.0 today and broke the previous link to 3.5

Opened PR to fix: https://github.com/InsightDataScience/pegasus/pull/84


Re add large sample

Re-add the large sample app, and fix the dev/dartdoc.dart script so that it can be run by the chromium bots.
@abarth


Issue with Camera Detection

Ali Ahmad - Team5401
Camera used - Logitech HD Pro Webcam C920 (h264 and MJPEG Capable)
Drive link to the terminal i/o -> https://drive.google.com/drive/folders/1gkdJJtxD8x_nj3azOCujJFEbB3Y4NXah?usp=sharing
Even though our camera was connected, Opensight could not detect the program as running. A test python program was run, testing if the camera was connected. The test program did provide video feed from the camera. After multiple trials, it was revealed that Opensight had a problem. I hope this can be fixed in the future.
Credit to Team5401: The Fightin' Robotic Owls

Output of user's v4l2-ctl --list-formats-ext: https://fs.ikl.sh/vh1ft467.file

Cause of the issue is that v4l2-ctl outputs the format information on current version and the version IronKai123 is on. @IronKai123 I recommend doing the following to install the current version of v4l-utils if you distribution does not package the latest version:
wget https://linuxtv.org/downloads/v4l-utils/v4l-utils-1.16.7.tar.bz2
tar xvfj v4l-utils-1.16.7.tar.bz2
cd v4l-utils-1.16.7
./configure
make
sudo make install


docs(ngRepeat): redundant "and" on line 77

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
docs update
What is the current behavior? (You can also link to an open issue here)
What is the new behavior (if this is a feature change)?
Does this PR introduce a breaking change?
Please check if the PR fulfills these requirements

[ ] The commit message follows our guidelines
[ ] Fix/Feature: Docs have been added/updated
[ ] Fix/Feature: Tests have been added; existing tests pass

Other information:

I signed it!

Thx for the PR.
It seems that the CLA is still not verified. Have you signed it with the same address that is associated with the commit?

I made the edit and commit from github, maybe this is the problem? Though i have used the same address for the cla with the one i'm using on github.
When i click on my name under the commit, i get the message "No commits found for "john-mantas"...", maybe i did something wrong, sorry for the inconvenience this was my first PR.

Googlebot wanted me to say sorry to accept my cla? :)
This seems ok now, please inform me if there are more issues with my PR!
PS. Why does googlebot post messages twice?


Pin werkzeug<3 to enable freezing of the site

As suggested in https://github.com/Frozen-Flask/Frozen-Flask/issues/129#issuecomment-1748317230 this is a working workaround. Fixes #733
My local freeze went well after adding this constraint, let's see about the CI.

I need this fix to be able to build the site for #736 . I think it's okay to use this workaround and CI is green. Merging.


Fixing breaking bitstring import

Fixing breaking bitstring import
Situation
The library was unable to be used in python 3.x environments.
Reproduction

Paste example into main.py (Issue with port in serve_rtmp is not being fixed in this PR)
Create Dockerfile:

FROM python:3-alpine

RUN mkdir -p /application

WORKDIR /application
COPY . /application/

RUN python -m pip install --upgrade pip && \
    apk add git build-base linux-headers
RUN --mount=type=cache,target=~/.cache/pip pip install -r requirements.txt

ENTRYPOINT [ "python", "main.py" ]

Build image
Run container

Fix
Change:
from bitstring import tokenparser, BitStream

To:
from bitstring import BitStream
from bitstring.bitstream import tokenparser

Tested in:
Python 3.10 on Alpine 3.18
DEBUG set to True and False checked.
To test, simply replace the pyrtmp==0.2.0 in the requirements.txt by pyrtmp @ git+https://github.com/KneeNinetySeven/pyrtmp

Thank you for contribution


Add My first branch

I hava created a new branch, created file, and made a commit!

leave a commit!


Efficient querying of many persistence IDs

I'm trying to optimize the read side of a system where I'm expecting to have on the order of, say, 1000 journals active at any given time. I'd like to have <1s latency between the write and read side of my system. I've read the source a bit of the Persistence Query implementation here, and correct me if I'm wrong, but if I set the polling interval to 1s and I have 1000 eventsByPersistenceId Sources open, I'm going to be generating 1000 DB queries per second. This doesn't seem scalable.
Do I have this correct? If so, is there a better way to accomplish what I'm going for here?

Having 1000 queries running on the database doesn't seem a good idea. Maybe just create one query for all pids and broadcast the emitted pids to other actors?

Well that was kind of my idea -- each of those other actors would hold a eventsByPersistenceId. But it seems like each of those sources would poll. I don't think there's a allEvents query, but if there were, I could have each actor bootstrap itself with currentEventsByPersistenceId and then have one centralized actor with an allEvents distribute the rest. But that feels fragile to me.
It seems like what could be missing is a way to centralize the polling, somehow. Not sure how that would work.
My current plan is to use DistributedPubSub to publish updates and then have my read-side actors listen via that channel. But it would be nice to be able to stay within the Akka ecosystem. Perhaps this is just a limitation of how Akk Persistence Query is currently designed.

For you non-functional requirements, <1s poll and ~1000 current events by pid on a single database and a single read journal the JDBC read journal is not a good solution. You could however store some pids on one database, and other pids on another database by overriding the journalPluginId of your persistent actor. You can then launch multiple jdbc-journal and multiple jdbc-read-journals, each pointing to another database. Say 10 databases for 10 pids? This way you have distributed the load across a number of databases.

You can read about overriding the journal and snapshot plugin here: http://doc.akka.io/docs/akka/2.4.7/scala/persistence.html#Multiple_persistence_plugin_configurations

This way you can even use a mix of storage technologies like Cassandra, Leveldb, JDBC for some pids. There are a lot of options to scale.

Thanks for the advice. So the thing about my use case is immediacy is a strong desire, but event volume is quite low (at the very most 10 per second at bursts, and far lower normally). So the overwhelming majority of those polls would reveal nothing had changed.
I think the DistributedPubSub route may be the way to go for me, for now. I'm going to close, since I think the limitation is more with the framework. I mostly just wanted to figure out whether there was an idiomatic way within Akka Persistence Query to approach my use case, but I think the answer is probably not.

The akka-persistence-query is still experimental and I am running into issues myself. There is currently no idiomatic approach. The only advice I have is, if you have Cassandra at your disposal, chances are a whole lot better that it will match your non-functional requirements, albeit I have never experimented with it under such a load. The jdbc plugin however could be used when you are a bit creative with your system architecture eg. using more databases to distribute the load.

I'm a believer in the concept of "unless you have some kind of crazy functional need, just use Postgres. Otherwise, probably still use Postgres." :)
My use case isn't too exotic. I think it could probably be a simple library around Akka Persistence. I just get nervous about adding complex unfamiliar components to my setup unless it's a perfect fit.


add docs that provide background about encodings

would be nice to link to some papers/further resources

Element Mover's Distance

(1) Hargreaves, C. J.; Dyer, M. S.; Gaultois, M. W.; Kurlin, V. A.; Rosseinsky, M. J. The Earth Mover’s Distance as a Metric for the Space of Inorganic Compositions. Chem. Mater. 2020, 32 (24), 10610–10620. https://doi.org/10.1021/acs.chemmater.0c03381.

A snippet relevant to scalar elemental featurizers:

We could assign the atomic number as the vector index for each element, then take the difference between indices as a measure of elemental similarity, but this approach loses the natural clustering of chemical properties afforded by the periodic table. An ideal elemental indexing would perfectly capture the chemical trends observed in nature, but ordering the elements in such a manner is problematic. As well as the unclear resolution of how to handle the f-block elements, chemical trends moving down the periodic table tend to be the direct opposite of those moving across. This leads to some elements having greater substitutional feasibility to their diagonal neighbor than their immediate neighbor, making a simple placement of these difficult.
To solve this problem, Pettifor proposed a method of labeling the elemental scale in his seminal paper of 1984,10 drawn from extensive domain knowledge. These numeric labels may form the basis of a coordinate system allowing us to associate patterns in geometric and physiochemical properties, with extensions to this idea continuing to guide practitioners.11,12 This concept of labeling was further developed by analyzing the probability that an element can be substituted for another given the same structural framework on 20,500 compounds of the inorganic crystal structure database (ICSD) by Glawe et al.13 This probability matrix can be reordered to maximize the likelihood that local neighborhoods will contain elements with greater feasibility of stable substitutions, thus possessing inherent chemical similarities.14 We take the associated indices of this final ordering to give each element its modified Pettifor number.
In this report, we define a composition vector by taking the ratio of each element in a compound assigned to the index of its respective modified Pettifor number. By assuming the sample of the set of feasibly stable compounds (although we know this is not strictly the case15), we can see that these indices capture the truly physical similarities between elements from statistical analysis. Using the modified Pettifor scale gives resultant similarities between compounds which align with human judgement but may be substituted with any continuous elemental scale including less equally spaced distributions, for example, Pauling electronegativity

Another snippet:

Even when using simple atomic numbers as the elemental index, the EMD introduces a significant structure to the UMAP generated clusters, leading to clusters with nontrivial shapes, however without the purity of labels observed when using the modified Pettifor scale (Figure S1). Elemental scales such as Pettifor’s original Mendeleev number13 and alternate orderings of this scale33 result in plots with similar cluster shapes and purity to the modified Pettifor scale (Figures S2−S6). An alternative approach to the use of compositional vectors X and Y is the use of recently developed vectors of features which are derived from values of physicochemical properties of the elements present in the composition.34−36

Composition-based property prediction models

(1) Tian, S. I. P.; Walsh, A.; Ren, Z.; Li, Q.; Buonassisi, T. What Information Is Necessary and Sufficient to Predict Materials Properties Using Machine Learning? 18.
(2) Falkowski, A. R.; Kauwe, S. K.; Sparks, T. D. Optimizing Fractional Compositions to Achieve Extraordinary Properties. Integr Mater Manuf Innov 2021, 10 (4), 689–695. https://doi.org/10.1007/s40192-021-00242-3.
(3) Vasylenko, A.; Antypov, D.; Gusev, V.; Gaultois, M.; Dyer, M.; Rosseinsky, M. Element Selection for Functional Materials Discovery by Integrated Machine Learning of Atomic Contributions to Properties; preprint; In Review, 2022. https://doi.org/10.21203/rs.3.rs-1334648/v1.
(4) Chen, C.; Ong, S. P. AtomSets as a Hierarchical Transfer Learning Framework for Small and Large Materials Datasets. npj Comput Mater 2021, 7 (1), 173. https://doi.org/10.1038/s41524-021-00639-w.
(5) Jha, D.; Choudhary, K.; Tavazza, F.; Liao, W.; Choudhary, A.; Campbell, C.; Agrawal, A. Enhancing Materials Property Prediction by Leveraging Computational and Experimental Data Using Deep Transfer Learning. Nat Commun 2019, 10 (1), 5316. https://doi.org/10.1038/s41467-019-13297-w.
(6) Jha, D.; Ward, L.; Paul, A.; Liao, W.; Choudhary, A.; Wolverton, C.; Agrawal, A. ElemNet: Deep Learning the Chemistry of Materials From Only Elemental Composition. Sci Rep 2018, 8 (1), 17593. https://doi.org/10.1038/s41598-018-35934-y.
(7) Meredig, B.; Agrawal, A.; Kirklin, S.; Saal, J. E.; Doak, J. W.; Thompson, A.; Zhang, K.; Choudhary, A.; Wolverton, C. Combinatorial Screening for New Materials in Unconstrained Composition Space with Machine Learning. Phys. Rev. B 2014, 89 (9), 094104. https://doi.org/10.1103/PhysRevB.89.094104.
(8) Ward, L. A General-Purpose Machine Learning Framework for Predicting. npj Computational Materials 2016, 7.
(9) Gupta, V.; Choudhary, K.; Tavazza, F.; Campbell, C.; Liao, W.; Choudhary, A.; Agrawal, A. Cross-Property Deep Transfer Learning Framework for Enhanced Predictive Analytics on Small Materials Data. Nat Commun 2021, 12 (1), 6595. https://doi.org/10.1038/s41467-021-26921-5.
(10) Dunn, A.; Wang, Q.; Ganose, A.; Dopp, D.; Jain, A. Benchmarking Materials Property Prediction Methods: The Matbench Test Set and Automatminer Reference Algorithm. npj Comput Mater 2020, 6 (1), 138. https://doi.org/10.1038/s41524-020-00406-3.
(11) Goodall, R. E. A.; Lee, A. A. Predicting Materials Properties without Crystal Structure: Deep Representation Learning from Stoichiometry. Nat Commun 2020, 11 (1), 6280. https://doi.org/10.1038/s41467-020-19964-7.
(12) Wang, A. Y.-T.; Kauwe, S. K.; Murdock, R. J.; Sparks, D. Compositionally-Restricted Attention-Based Network for Materials Property Predictions. npj Computational Materials 2021, 33. https://doi.org/10.1038/s41524-021-00545-1.


Hide "Create Repo" option if limit is reached

Fixes issue #27663.
Some of the styling got messy because disabling a menu item removes the pointer events which prevents the tool-tip from showing. We could simplify this by removing the tool-tip if that's acceptable.
Also, there's a line of inline JS that should probably live somewhere else, but I was unsure where to put it.

Thank you for your contributions. Can you post some screenshots?

Sure, here you go.

Another entry to create repository at

should also be handled.

Organization's home page also has create repo button.

Ok, I adjusted those as well. I simply hid it on the org page because there was some logic already to hide the button group.

Ok, I adjusted those as well. I simply hid it on the org page because there was some logic already to hide the button group.

This will prevent users from creating repositories when he is allowed to create repositories in organizations. So I don't think it's right.

How do we count the limit of creating repos in organizations? It is not depended on the individual user but the organization? (as organization is also a 'user')

This PR is stale for long time, and the change doesn't seem right ....


LICENSE texts are are not correctly formatted

Gitea version (or commit ref): 1.6.1
Can you reproduce the bug at https://try.gitea.io:

[x] Yes (provide example URL)
[ ] No
[ ] Not relevant

Description
When I add a new repository and select a license, the LICENSE file is missing space and double-newlines, at least for GPL-2.0-only, GPL-3.0-only, GPL-3.0-or-later and BSD-4-Clause.
The GPL-3.0 licenses are also having a corrupted URL in line 3.
Correctly formatted GPL-3.0 license: https://www.gnu.org/licenses/gpl-3.0.txt
Screenshots

Hmm... I'm not sure that the formatting is necessarily incorrect.  All of the other licenses in options/license are similarly formatted. I'll put a PR in to fix the urls though.

It may not be technically incorrect, but it is hard to read for humans and I don't see any advantage.

@zeripath this is the script that pulls the latest license files from the SPDX repo: https://github.com/go-gitea/gitea/blob/801843b0115e29ba2304fa6a5bea1ae169a58e02/scripts/generate-licenses.go#L20

Heya @tastytea , so the issue with the url is coming from our upstream ( https://github.com/spdx/license-list-data ) - please could you open an issue there?
They've changed their formatting to match your preferred style - which I agree is nicer - so I've run our update script (go run scripts/generate-licenses.go) and added a PR for this #5558.

I've reported the issue upstream.

Closing this issue as PR has been merged.


Link checking with DocumenterCitations

Link checking errors when using citations from
https://github.com/ali-ramadhan/DocumenterCitations.jl

I took the liberty of transferring the issue, but maybe this should be closed instead.

Yes, since there wasn't a concrete example from OP, you should close this issue (I don't have permission). But anyone reading this who encounters a similar issue should either comment below, or open a new issue.

I'd consider "Add a test that checks that invalid links trigger the link checker" as the actionable item for closing this.

Trying to add a test uncovered that, in fact, the link checker does not traverse into the bibliography.
That's a bug, and should be fixed.

This will require a fix in Documenter: https://github.com/JuliaDocs/Documenter.jl/issues/2329

As soon as https://github.com/JuliaDocs/Documenter.jl/pull/2330 is merged, I'll be able to fix this


Use all caps pure-tokens in command "Usage:"

In the command page's "Usage:", the lower case name was used in case of a pure-token. However, the all caps token should be used instead. For MIGRATE, this makes an even bigger difference (see empty-string):
Before:
Usage:
    MIGRATE host port 〈 key | empty-string 〉 destination-db timeout [ copy ] [ replace ] [ AUTH auth | AUTH2 username password ] [ KEYS keys ] [ [ KEYS keys ] ... ]

Now:
Usage:
    MIGRATE host port 〈 key | "" 〉 destination-db timeout [ COPY ] [ REPLACE ] [ AUTH auth | AUTH2 username password ] [ KEYS keys ] [ [ KEYS keys ] ... ]

This addresses a part of #116
By submitting this pull request, I confirm that my contribution is made under the terms of the BSD-3-Clause License.

This looks good.
I get a little itchy when there are changes to the command reference parser due to the possibility of unintended consequences, but I ran a diff vs the command rendering on current iteration of the website and indeed this appears to only affect spacing (fine/irrelevant) and the intended capitalization.


WindowDialog can be dragged around without holding down any mouse buttons

Godot version:
Godot 3.0.2-stable_win64
OS/device including version:
Windows 10.0.17134 Build 17134
Issue description:
When holding both right and left mouse button on the upper bar of a window dialog like the project settings window and then releasing them, the window can be dragged around without holding down any mouse buttons.
Steps to reproduce:

right click the upper bar of a window dialog
left click the upper bar of a window dialog
release the right mouse button
release the left mouse button
drag the window around without holding down any mouse buttons

Minimal reproduction project:
This can be reproduced in any project by performing the steps above on the project settings window.

Assumed fixed by #19151 in the master branch, please comment if it's not the case so that we can reopen it.

Built godot from source 30 minutes ago, this issue is still present.

Reopening.

Why is this issue closed? I can still reproduce it in 3.0.6.

As the milestone says, it was closed in 3.1.


[Camp Editing] inconsistent check-box positions under basic details tab

Overview of the problem
Checkboxs should stay in same position (right to text in Hebrew, left in English) relative to text.
Steps to Reproduce

Navigate to camp editing.
Navigate to BASIC DETAILS tab.
Checkbox is right hand to Child friendly text (In English view)

Expected behavior
Checkboxs should stay in same position (right to text in Hebrew, left in English) relative to text.
Actual behavior
heckbox is right hand to Child friendly text (In English view)

can you add a screen shot?


Compilation error of SwiftThemisServerExample

Project can't be compiled and build because of compilation error in Themis itself:
./themis/docs/examples/Themis-server/swift/Pods/themis/src/soter/boringssl/soter_asym_cipher.c:146:8: Implicit declaration of function 'EVP_PKEY_get0_RSA' is invalid in C99
xcode 7.3.1
xcode 8 can't compile either because of old swift version of the project.

Thank you!
I'll take a look

Any news?

not yet, but no worries, we're working on it

Thank you, this was fixed by #147.
All examples are working with the latest master now.


csrf: increase only one counter per request

Requests with an invalid origin should increase only the counter "missing_source_origin" but not the counter "request_invalid".
Before this bugfix, the counter "request_invalid" was also increased, depending on the value of the "Host" or ":authority" header.
Risk Level: Low (only metrics affected)
Testing: With improved tests

@mattklein123 Thanks for reviewing! I have added a release note.