sway: Optimal NixOS integration

This is intended as an issue to collect and track possible improvements and feedback in general. Feedback form users is welcome (what is difficult, does not work, could be improved, are packages missing, etc.).
Possible improvements (feel free to propose additions and notify me of updates):

[x] Read all configurations from /etc and fallback to /nix/store for non NixOS systems (#60319)
Should we install the default wallpaper? (see https://github.com/NixOS/nixpkgs/pull/57414#discussion_r265056873)

We could e.g. install them into another output and introduce an option to enable/disable them.
/run/current-system/backgrounds/sway or /run/current-system/wallpapers/sway would probably work well, but unfortunately only on NixOS

[ ] systemd integration (user units) - WIP: https://github.com/NixOS/nixpkgs/pull/54627#issuecomment-462736971
[x] Login manager integration (e.g. SDDM) - https://github.com/swaywm/sway/issues/100

Might work with services.xserver.displayManager.extraSessionFilePackages = [sway];
Nixpkgs issue: https://github.com/NixOS/nixpkgs/issues/39871
Sway's desktop/session file: https://github.com/swaywm/sway/blob/master/sway.desktop
Implementation:

services.xserver.displayManager.session
Probably needs to be modified for Wayland-only sessions (and it's unsure which login/display managers properly support Wayland sessions - IIRC this was still problematic a few months ago, but I could be wrong)
See: nixos/modules/services/x11/display-managers/default.nix

Search for share/wayland-sessions

[ ] Proper initialization / environment setup via graphical login/display managers

See #109546.

Copying /etc/sway/config is not optimal because the file in the Nix store is read-only (-> the configuration in ~/.config/sway/config will be read-only). We could consider copying the example configuration file to /etc (instead of symlinking it) and change the permissions.
Track sway-security
Compare the setup script (D-Bus, etc.) to the ones for X11

Unify these for X11 and Wayland?

[ ] Enable a few extraSessionCommands by default?

See https://github.com/swaywm/sway/wiki/Running-programs-natively-under-wayland
QT_QPA_PLATFORM=wayland-egl is problematic sometimes as the Wayland backend for QT is unfortunately broken from time to time in nixpkgs. Maybe we should add a test.
https://git.sr.ht/~emersion/dotfiles/tree/master/item/bin/sway-run

Rename the Sway wrapper to sway-run or sway-launch (similar to weston-launch)?

That way one could use the unwrapped Sway more easily (e.g. for sway --version)

Useful software (for Wayland in general) in nixpkgs:

[x] swayidle: idle management daemon
[x] swaylock: lock screen
[x] mako: notification daemon
[x] grim: screenshot tool
[x] slurp: interactive region selection
[x] wf-recorder: video capture tool (https://github.com/NixOS/nixpkgs/pull/57662)
[x] waybar: alternative panel (https://github.com/NixOS/nixpkgs/pull/54627)
[ ] virtboard: on-screen keyboard (https://github.com/NixOS/nixpkgs/pull/57614)
[x] wl-clipboard: xclip replacement
[x] wallutils: fancy wallpaper manager (https://github.com/NixOS/nixpkgs/pull/59878)
[x] light / brightnessctl: backlight management
[x] bemenu: Dynamic menu library and client program inspired by dmenu (Wayland, ncurses, and X11)
[x] wdisplays: Basically an ARandR equivalent for Wayland (see https://github.com/NixOS/nixpkgs/issues/81825)
[ ] sgtk-menu: GTK launcher for sway & other WMs w/ menu, dmenu, application grid and button bar (see https://github.com/NixOS/nixpkgs/issues/78370)
[x] wshowkeys (WIP: #83687)
[x] sway-contrib (grimshot, etc.): #88577
[x] wlsunset (#103606)

virtboard is packaged in https://github.com/NixOS/nixpkgs/pull/57614

light / brightnessctl: backlight management

Could actkbd or acpid used instead? For brightness control locally I use
  brightness = pkgs.writeShellScriptBin "brightness.sh" ''
    bl_dev=`echo /sys/class/backlight/*`
    echo $(($(< $bl_dev/brightness) $1 $2)) >$bl_dev/brightness
  '';

Will this work for all video cards? If so, I would like to add brightness control defaults to actkbd, like we already have for sound control sound.mediaKeys.enable = true;

Useful software (for Wayland in general) in nixpkgs:
wallutils

Don't see it in nixpkgs.

systemd integration (user units) - WIP: #54627 (comment)

What benefits it brings? sway is capable to run applications on start by itself.

What benefits it brings?

Starting sway itself, presumably.

Could actkbd or acpid used instead?

I do not have any preference here, it was simply meant as a list of software that could be useful (I took if from Drew's blog post). I also didn't plan to integrate this into the sway module if that was your concern (not sure if I'm interpreting your comment correctly).

If so, I would like to add brightness control defaults to actkbd, like we already have for sound control sound.mediaKeys.enable = true;

Might be a good idea if we already have this for sound. But since this is a generic solution that should work with both Wayland and X11 we should not put it in the sway module (but that was probably not your intention anyway).

Don't see it in nixpkgs.

Only the checked entries (checkbox) are already in nixpkgs.

What benefits it brings? sway is capable to run applications on start by itself.

I'm not using user units - it's mainly useful for people who already use them. I assume the main advantages are to automatically launch sway on a TTY (like with .bashrc), "dependency management" (other systemd user units) and we could better integrate it into nixpkgs than via the sway configuration (though I'm not sure how useful it would actually be - but it could be implemented in a generic and standardized way I guess).

Home-manager provided a nice way to set i3 declaratively [0].
Could be nice to have that in-tree and shared with i3 or add sway support to home-manager's dingy.
[0] https://github.com/rycee/home-manager/blob/master/modules/services/window-managers/i3.nix

@t184256

Starting sway itself, presumably.

Looks like we have a blocker for user services: https://github.com/NixOS/nixpkgs/issues/21460
@primeos

But since this is a generic solution that should work with both Wayland and X11 we should not put it in the sway module (but that was probably not your intention anyway).

Right, I'm just interesting whether it will work with different video cards. I only have Intel there.

Only the checked entries (checkbox) are already in nixpkgs.

Sorry. With sway 1.0-rc5, firefox and breeze dark theme they are not visible by some reason.

wf-recorder has been merged! #57662  :tada:

Right, I'm just interesting whether it will work with different video cards. I only have Intel there.

I also only have Intel but according to the Arch Wiki:

All methods are exposed to the user through /sys/class/backlight

it sounds like a good method that should work in most cases.
But we would have to modify the script to consider max_brightness.
According to the Arch Wiki:

The maximum brightness can be found by reading from max_brightness, which is often 15.

and on my system max_brightness has the value 7500. So the step size of 10 is either too high or too low in these cases. Using something like 10% would be better.

With sway 1.0-rc5, firefox and breeze dark theme they are not visible by some reason.

As long as it works with 1.0 :)

Home-manager provided a nice way to set i3 declaratively [0].
Could be nice to have that in-tree and shared with i3 or add sway support to home-manager's dingy.

@amazari interesting. I don't think that we can/should move it in-tree (too many configuration options IMO) but I'm assuming that adding a module for sway to home-manager would be fine - any volunteers? :)

Waybar has been merged. #54627

@primeos Would be nice to add environment setup like that https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/x11/display-managers/default.nix does
For e.g. currently without doing
exec dbus-update-activation-environment DISPLAY
in sway config I get an error when trying to send notification
gi.repository.GLib.Error: g-dbus-error-quark: Ошибка вызова StartServiceByName для org.freedesktop.Notifications: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.freedesktop.Notifications exited with status 1 (25)

What about bemenu?

@NilsIrl good idea, I added it to the list - it's already packaged in nixpkgs (pkgs/applications/misc/bemenu/default.nix)
@gnidorah seems like I forgot to reply :o
Regarding the environment setup: Yes, that would be nice. I think there is already an issue to unify this for X11 and Wayland (I'll try to look it up and reference it).
Regarding the notification: Can this be reproduced (e.g. with notify-send and mako)? I don't use notifications but I could have a look at it if it doesn't work.

@primeos
No, mako works. Looks like this is only needed for X11 programs. Thanks, I will switch to mako from now.
Though with mako I see an issue that it can't be launched automatically
gi.repository.GLib.Error: g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Notifications was not provided by any .service files (2)

If I start mako manually, everything works fine

@gnidorah great :) Just realized that I missed the exec dbus-update-activation-environment DISPLAY part...

gi.repository.GLib.Error: g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Notifications was not provided by any .service files (2)

Seems like mako didn't provide a .service file but it should work after the next release:
https://github.com/emersion/mako/commit/ca8e763f06756136c534b1bbd2e5b536be6b1995 (cc @dywedir maybe you could you test if it works after the next release)

@NilsIrl
How to make it work under sway? This doesn't show anything for me
nix-build -A bemenu
./result/bin/bemenu

@NilsIrl
How to make it work under sway? This doesn't show anything for me
nix-build -A bemenu
./result/bin/bemenu

I had the same problem. Bemenu is only in the master branch.
git clone git@github.com:NixOS/nixpkgs.git
nix-build -A bemenu -I nixpkgs=nixpkgs/

@NilsIrl I've tried it from master branch, but when I run bemenu under sway it doesn't draw anything on the screen.

@NilsIrl I've tried it from master branch, but when I run bemenu under sway it doesn't draw anything on the screen.

Have you tried to run bemenu from a terminal?

Have you tried to run bemenu from a terminal?

That is. And nothing on the screen. Sway version is 1.1.1

Have you tried to run bemenu from a terminal?

That is. And nothing on the screen. Sway version is 1.1.1

If you can open a terminal, you could see what bemenu outputs when it is run. If you don't have access to a terminal, you can try to redirect the output from bemenu into a file and then view the file.

I personally had a problem where I couldn't even run a terminal. What I did is that I redirected stdout and stderr from the command launching the terminal in sway into a file.
I then viewed the file from the tty. And guess what... The file had an error message saying my version of opengl was too outdated for the terminal emulator, alacritty to work.

@NilsIrl Looks like my mistake was in that I've tried to run bemenu instead of bemenu-run. bemenu-run works just fine. My sorry :disappointed:
BTW I hope they introduce something akin to i3-dmenu-desktop some day

@gnidorah
https://github.com/i3/i3/blob/6339427f017e1265a022e6537e16a8b4a921e52f/i3-dmenu-desktop
You can modify this script for it to use bemenu instead of dmenu.

Actually you don't even need to do that.
Just run $ i3-dmenu-desktop --demenu=bemenu and it should work
If you don't want to install i3 just to have i3-dmenu-desktop you can download it from https://github.com/i3/i3/blob/6339427f017e1265a022e6537e16a8b4a921e52f/i3-dmenu-desktop

i'd like to suggest redshift to adjust the color temperature:
https://aur.archlinux.org/packages/redshift-wlr-gamma-control-git/
optimally there could be a switch in services.redshift

also, https://github.com/ReimuNotMoe/ydotool

wshowkeys, https://git.sr.ht/~sircmpwn/wshowkeys
mentioned in https://github.com/swaywm/sway/wiki/i3-Migration-Guide

Regarding systemd user service integration: I started to document my setup in https://nixos.wiki/wiki/Sway. Atm I have no time to integrate these changes into NixOS, but maybe somebody else has?

Hello @erictapen, I've been trying to integrate Sway with systemd the way you proposed, but I had multiple issues doing so :

I could not find a way to autostart correctly the session
I could not find a way bind it with a displaymanager properly at all

Have you been able to achieve this ?
The approach i' m currently following is to start Sway as the display-manager itself. I have the feeling the way you're doing it might be cleaner. Here is my setup :
  systemd.defaultUnit = "graphical.target";
  systemd.services.sway = {
    enable = true;
    wants = [ "systemd-machined.service" ];
    aliases = [ "display-manager.service" ];
    after =  [
      "rc-local.service"
      "systemd-machined.service"
      "systemd-user-sessions.service"
      "plymouth-quit.service"
      "plymouth-start.service"
    ];
    serviceConfig = {
      ExecStartPre = "${config.system.path}/bin/chvt ${sway.tty}";
      ExecStart = "${pkgs.dbus}/bin/dbus-launch --exit-with-session ${pkgs.sway}/bin/sway";
      TTYPath = "/dev/tty${sway.tty}";
      TTYReset = "yes";
      TTYVHangup = "yes";
      TTYVTDisallocate = "yes";
      PAMName = "login";
      User = sway.username;
      WorkingDirectory = "/home/${sway.username}";
      StandardInput = "tty";
      StandardError = "journal";
      StandardOutput = "journal";
      Restart = "no";
    };
  };

It still has one issue though.

I am sorry if this is not a right place to drop my idea, or this is something to create a separate issue for, but I would personally love if the Sway package in the option programs.sway was exposed so that it could be overridden with a package from the nixos-unstable.
Since the Wayland ecosystem and Sway are still in work in progress adoption-wise; many Wayland tools, and the newest releases of Wlroots and Sway themselves rarely make it into Linux distributions, which follow the fixed 6 months release schedule model, in time. While using NixOS Unstable may be an option, having the latest Wayland stack is all I need.
My lack of understanding of the basic knowledge about Nix and NixOS'es Sway wrapper may make obvious limitations of implementing this feature inapparent to me, but I would like to hear from you what you think about it, and why it could/should (not) be implemented, nonetheless.
https://functor.tokyo/blog/2018-02-18-install-packages-from-nixos-unstable

@Bryophyllum that's a valid idea and feel free to add such comments to this issue ;)
That said, I'm not sure if having such a package option is worth it. I don't have any strong feelings on this, but AFAIK the consensus is to avoid such an option in cases like this (see https://github.com/NixOS/nixpkgs/issues/50476). Also: Mixing Sway from nixos-unstable with a system based on nixos-stable can result im problems like https://github.com/NixOS/nixpkgs/pull/76787#issuecomment-578461880.
Therefore I would avoid adding such an option. However, you should still be able to realise your use-case by using overlays. It should be sufficient to override the sway package with the one from nixos-unstable. Here is an example: https://gist.github.com/LnL7/58d687c58948e71acd7fd4d410f3cdd1 (instead of unstable = ... the following should be sufficient: sway = unstable.sway).

would you add : https://github.com/NixOS/nixpkgs/issues/78370 ?

For users interested in Grimshot or other scripts in contrib/: In #87979 we're currently discussing how to best package these in Nixpkgs.

I'm still missing some documentation / configuration examples on how to actually /enable/ sway.
While testing pipewire support in a VM, I hacked together the following:
      programs.sway.enable = true;

      services.xserver.enable = true; #??
      services.xserver.displayManager.sddm = {
        enable = true;
        autoLogin = {
          enable = true;
          user = "alice";
        };
      };
      services.xserver.displayManager.defaultSession = "sway";

      xdg.portal = {
        enable = true;
        extraPortals = with pkgs; [ xdg-desktop-portal-wlr ];
        gtkUsePortal = true;
      };

      services.pipewire.enable = true;

However, this is using Xwayland, and this is probably not right, i don't know.
We should also have some tests that ensure stuff doesn't break - I tried automating something with ydotool, but couldn't get it to work.

I'm still missing some documentation / configuration examples on how to actually /enable/ sway.

Where would you suggest to document this? E.g. there's a page on the NixOS wiki but that is currently only focused on systemd. Alternatively we could document it in the NixOS manual, but unfortunately there are many Wayland compositors and we don't have a general abstraction for them in Nixpkgs (i.e. documenting Sway there might be too specific).
But basically programs.sway.enable = true; is already enough and the most relevant things should already be documented via the NixOS module.

However, this is using Xwayland, and this is probably not right, i don't know.

I guess this is regarding Chromium? Unfortunately Ozone still isn't considered stable / enabled by default so you have to recompile Chromium for native Wayland support: chromium.override { useOzone = true; }. You can also disable XWayland by removing it from programs.sway.extraPackages or via the Sway config (IIRC).

We should also have some tests that ensure stuff doesn't break - I tried automating something with ydotool, but couldn't get it to work.

A NixOS VM test for Sway sounds like a good idea :)

Where would you suggest to document this? E.g. there's a page on the NixOS wiki but that is currently only focused on systemd. Alternatively we could document it in the NixOS manual, but unfortunately there are many Wayland compositors and we don't have a general abstraction for them in Nixpkgs (i.e. documenting Sway there might be too specific).

Yeah, I'd prefer having more complicated things documented in the NixOS manual via meta.doc - those hopefully are more likely to be up-to-date with the code than a page in the wiki.
A Sway-specific documentation is probably better than no documentation at all :-)
Also note the Wiki Page is more a configuration dump that shows a way to get it working with systemd (and probably outdated, see https://github.com/NixOS/nixpkgs/pull/85334#issuecomment-615495925 as discussed with @Ma27)
These parts should really just end up in the sway module, and once we want to abstract that to support more wayland compositors, can be done as a follow-up.

I guess this is regarding Chromium? Unfortunately Ozone still isn't considered stable / enabled by default so you have to recompile Chromium for native Wayland support […]

Once compiled with Ozone support, is this a flag/environment variable? Could we enable this during compilation, while still having users opting in (similar to https://github.com/NixOS/nixpkgs/pull/89565)?

A NixOS VM test for Sway sounds like a good idea :)

As I posted in my previous comment, I didn't get the ydotool parts to work, so we can't really do anything in it. I'd assume for the test, we'd at least want to open a terminal and do some OCR (like in nixosTests.cage)

A Sway-specific documentation is probably better than no documentation at all :-)

Ok, I'll try to look into that then (but it might take me some time). Help is obviously welcome, if someone else who follows this issue is interested in that.

Once compiled with Ozone support, is this a flag/environment variable?

You need to run chromium --ozone-platform=wayland to select the Wayland backend (by default X11 is used).

Could we enable this during compilation, while still having users opting in (similar to #89565)?

Unfortunately not :o See https://github.com/NixOS/nixpkgs/issues/82443 and https://github.com/NixOS/nixpkgs/pull/85197 for related discussions. I'm hoping that Ozone will become stable in 2020 and current news look promising (e.g. Chrome Is Reaching The Point Of Good X11 + Wayland Support In Same Build  - the X11 stability was lacking behind Wayland, which is the main focus).

As I posted in my previous comment, I didn't get the ydotool parts to work, so we can't really do anything in it. I'd assume for the test, we'd at least want to open a terminal and do some OCR (like in nixosTests.cage)

Why don't we just send the key combinations via send_keys to launch a terminal, etc.?

services.xserver.enable = true; #??

I was curious about that myself as I'd rather not have everything else that brings in.
To have just a display manager that launches sway and other wayland window managers all that is needed from xserver.nix  is settingsystemd.defaultUnit and creating the display manager service. I pulled those out manually on my local machine to verify.
I'm wondering if extracting that config into display manager specific config might be a good idea. Maybe something where if services.xserver.enabled is true, then the display manager is automatically enabled, but it could be enabled without enabling the xserver.
I'd appreciate any feedback and opinions on that idea, and then I could potentially put together a PR.

Has anyone gotten a different login manager than sddm working with sway? I am currently trying lightdm with the mini greeter, but I only get a black sceen with a cursor.
Maybe something like https://git.sr.ht/~kennylevinsen/gtkgreet would be perfect since it seems to be made specifically for sway?

Has anyone gotten a different login manager than sddm working with sway? I am currently trying lightdm with the mini greeter, but I only get a black sceen with a cursor.

I've been using gdm with sway, as it's the only one that I'm aware of that will render with wayland and not have to start an Xserver. I did it with the proposed method above where just the display manager is enabled without enabling all of Xorg.
In my configuration.nix:
  services.xserver.displayManager.gdm = {
    enable = true;
    wayland = true;
  };

  # Extracted from nixos/modules/services/x11/xserver.nix
  systemd.defaultUnit = "graphical.target";
  systemd.services.display-manager =
    let
      cfg = config.services.xserver.displayManager;
    in
    {
      description = "Display Manager";

      after = [ "acpid.service" "systemd-logind.service" ];

      restartIfChanged = false;

      environment =
        lib.optionalAttrs
          config.hardware.opengl.setLdLibraryPath {
          LD_LIBRARY_PATH = pkgs.addOpenGLRunpath.driverLink;
        } // cfg.job.environment;

      preStart =
        ''
          ${cfg.job.preStart}

          rm -f /tmp/.X0-lock
        '';

      script = "${cfg.job.execCmd}";

      serviceConfig = {
        Restart = "always";
        RestartSec = "200ms";
        SyslogIdentifier = "display-manager";
        # Stop restarting if the display manager stops (crashes) 2 times
        # in one minute. Starting X typically takes 3-4s.
        StartLimitInterval = "30s";
        StartLimitBurst = "3";
      };
    };

I previously checked out gtkgreet, it's one of the greeters that are part of greetd. That project seems really promising but still in early phases. Maybe some progress has been made since I last looked. Also since it involves login, hopefully there will be some security minded folks looking over it.

Has anyone gotten a different login manager than sddm working with sway? I am currently trying lightdm with the mini greeter, but I only get a black sceen with a cursor.

I have been using lightdm with Sway successfully on nixpkgs-unstable and 20.03 channel with no problems whatsoever.
I use the enso greeter if it's relevant.
My keyring (gnome-keyring) gets automatically unlocked too.
Excerpt from my config:
{
  services.xserver.enable = true;
  services.xserver.displayManager.defaultSession = "sway";
  services.xserver.displayManager.lightdm = {
    enable = true;
    greeters.enso.enable = true;
  };
  services.xserver.libinput.enable = true;
  services.xserver.layout = "us";

  services.gnome3.gnome-keyring.enable = true;
}

I've never tried screen sharing myself but for Firefox #84233 might fix your issues and for Chromium #89565 and linked issues/PRs might contain valuable information (configuration examples, etc.).

Meanwhile, wf-recoder might or might not save you from relogging into XFCE.

Meanwhile, wf-recoder might or might not save you from relogging into XFCE.

I did try an alternate configuration involving the v4l2loopback kernel module and wf-recorder but when I tried to initialize a "webcam" feed from wf-recorder I ran into some errors. If I recreate that configuration I could share the errors I got here. It feels like kind of a hack to begin with though; if I could get one of these solutions to work I'd prefer it to be pipewire.

Meanwhile, wf-recoder might or might not save you from relogging into XFCE.

If I recreate that configuration I could share the errors I got here.

Alright, I tried again to adapt some instructions from the Arch Wiki to use wf-recorder to create a virtual webcam, and (good news!) this time I succeeded. Still feels a little hacky, but this is what I did.
In my NixOS config:
  # Obviously omitting all my non-screen-sharing-related packages:
  programs.sway.extraPackages = with pkgs; [
    v4l2-utils
    wf-recorder
  ];
  boot.extraModulePackages = with config.boot.kernelPackages; [
    v4l2loopback
  ];

Then when I'm ready to start screen-sharing I do
# modprobe v4l2loopback exclusive_caps=1 card_label=WfRecorder
$ v4l2-ctl --list-devices

On my system this results in /dev/video4 being allocated with the WfRecorder label, so then I do
$ wf-recorder --muxer=v4l2 --codec=rawvideo --file=/dev/video4 -x yuv420p

I had two displays active when I first tried this, so wf-recorder asked me to specify which one I wanted to capture. I left this command running while I opened Firefox, opened a webcam-sharing test, and easily shared the "webcam" that was capturing my screen.
Now that I have this working I guess it's my solution for the time being. Would have preferred to just select applications or displays from within Firefox on the fly instead of setting up a virtual webcam first, but this is a pretty cool workaround.

As someone who is relatively new to NixOS and configuring this kind of thing I still found it fairly difficult to pull together all of the required pieces from different places to get a working setup with  sway as the window manager and  gdm as the display manager (to avoid having to enable xserver - not sure how much sway users care about this).
I'm still having trouble with kanshi, other than that I have a working config, which I wanted to share in case others find it useful:
https://gist.github.com/mschwaig/195fe93ed85dea7aaceaf8e1fc6c0e99
I also added a warning in the wiki because I forgot to start the sway-session.target and this gave me trouble for a long time. If kanshi was working and I knew that GDM was a good choice for most people (SDDM is mentioned in the original issue) I'd be happy to extend the wiki with a few lines on display manager integration..
There is a blogpost by Ongy who pulled out more stuff than just kanshi into individual units. I don't know if that would be a good idea.

@mschwaig yeah, the current module is focused on running Sway from a virtual terminal so using login/display managers (especially without X11) and/or systemd user units is unfortunately a bit tricky. For the login/display managers we'd likely need better NixOS abstractions that aren't so much X11 focused (not sure how well this is currently possible though). I'm also not sure what to do about the systemd user unit integration. Upstream doesn't officially support it (e.g. noted in the wiki and there should be a few issues/PRs IIRC) but AFAIK there are many(?) NixOS users that want/use it. I think if there are NixOS users interested in maintaining that it might make sense to add an option to the module (e.g. programs.sway.systemdIntegration) that is disabled by default but can be quickly enabled (and should then work with the Sway/Wayland related Nixpkgs packages - not sure if they can install systemd user units without a module though). But given that it's not officially supported and we likely add systemd user units that integrate with the sway unit it's likely better suited for home-manager(?).

If kanshi was working and I knew that GDM was a good choice for most people (SDDM is mentioned originally in this issue) I'd be happy to extend the wiki with a few lines on display manager integration.

That seems like a good idea. The Wiki is community maintained and the current version of the Sway page is AFAIK only a draft to document the systemd integration. So it would be good to extend it. And if there's e.g. an example for GDM that might be easily portable to other login/display managers as well.

@primeos, thank you for the reply it was really helpful to me to understand what I can expect to work.
About getting a nice default sway setup to work:
@primeos's post makes me think it might be better to not use a display manager at all or get a really minimal one working instead of GDM. I have the suspicion that configuring GDM to not do any power-managment would help, but it looks like right now that would also still be quite complicated to configure, I am not sure (does #54150 apply when I try to disable GDM's power manamgent?). I will also try to run kanshi directly from sway and see if that fixes it.
About using systemd units:
I have not used home-manager at all yet (I'm going one step at a time), but it seems like home-manager would be a way better fit to optinally integrate specific services as systemd user units instead of starting them from the sway config. Probably having options that move individual parts ot the desktop into user units directly in NixOS is prone to leave you with one foot inside of your configuration.nix file and the other one inside your ~/.config/sway/config file, because things you change in configuration.nix will mean you always also have make the corresponding changes in your sway config file correctly. So maybe home-manager would be a better place to do that kind of thing and maybe to do heavier customization in general.

Probably having options that move individual parts ot the desktop into user units directly in NixOS is prone to leave you with one foot inside of your configuration.nix file and the other one inside your ~/.config/sway/config file

To avoid this situation I declare the content of global /etc/sway/config via environment.etc."sway/config" and intentionally have no file in ~/.config/sway/. Works only for single user setups of course.
Regarding the discussion wether to put sway logic into home-manager I'd like to add that this would leave us without the possibility to test sway integration via NixOS tests, like pretty much all X display-manager do and also cage.
Half a year ago I started bringing my Sway systemd user modules upstream, but never finished it. Here is my progress: https://github.com/erictapen/nixpkgs/tree/sway-systemd-integration (heavily WiP). My goal was to make the proposed systemd user integration described in the Wiki article I wrote easier for the end user. I'm still using this setup, but felt that it'd be better to wait with the PR until the discussion about where to put sway and how to integrate it into NixOS is solved.

Regarding the discussion wether to put sway logic into home-manager I'd like to add that this would leave us without the possibility to test sway integration via NixOS tests, like pretty much all X display-manager do and also cage.

Not sure about that one, what wouldn't we be able to do? Sway should be fully functional without systemd user units.

I'm still using this setup, but felt that it'd be better to wait with the PR until the discussion about where to put sway and how to integrate it into NixOS is solved.

I think it would be best to open a dedicated Nixpkgs issue regarding this (with e.g. the "0.kind: question" and "9.needs: community feedback" labels for better visibility and since this will require some discussion). I'm not too optimistic that it will be easy to nicely integrate this into Nixpkgs tbh but I guess it should be possible. I think the main problems are:

Wayland is very modular and flexible by design which resulted in a very diverse ecosystem (software wise)
We don't have any abstractions for Wayland compositors in Nixpkgs (like services.xserver for X11) and the previous problem makes this more difficult
AFAIK there's no real consensus if and how we want to handle systemd user units in Nixpkgs

I have updated my config (also linked above) to use SDDM instead of GDM. Kanshi still doesn't pick up when outputs are changed on the fly, but this is now a workable setup for me, because I can recover from being left with a black screen easily and every time.
I also wanted to highlight that when I was using GDM I used the snippet that @wkral posted and that itself was working well for avoiding xserver.enable = true and looks promising to me.

Hello,
I have been experimenting with Sway for a while so I would like to share some feedback. I am currently using NixOS 20.09 and GDM as the login manager. Things mostly work, the one thing that I find problematic is the setup of environment variables.
More specifically, when enabling Sway with no customization, simply by saying programs.sway.enable = true in configuration.nix, the session is started without reading /etc/profile nor ~/.profile, so Sway itself and anything it launches ignores any session configuration found in those places. This can be problematic when some variables need to be set up, especially PATH. Besides, when starting terminals, these profiles are not read either because they are not login shells.
My current way out of this problem is to enable Sway this way:
    programs.sway = {
      enable = true;
      extraSessionCommands = ''
        source /etc/profile
        test -f $HOME/.profile && source $HOME/.profile
        export MOZ_ENABLE_WAYLAND=1
        systemctl --user import-environment
      '';
      wrapperFeatures.gtk = true;
    };

I also tried using the systemd approach of putting files in ~/.config/environment.d/ and it works for all variables except for PATH which apparently gets reinitialized before starting the session. Besides, this approach induces some redundancy with ~/.profile (unless environment.d is somehow used also for login shells).
I would be interested if there are better ways to proceed.
For what it's worth, Gnome session on Wayland apparently does read /etc/profile and ~/.profile at some point.
A few other random thoughts while I am at it:

The startup sequence for Wayland sessions is a mystery. Is there any standard that would specify what should happen when logging into a session through a Wayland compositor, particulary regarding the role of the login manager vs the role of the compositor ?
The NixOS wrapper for Sway apparently hard-codes the path to swaybg in PATH. That makes no sense to me. What is so special about swaybg that it has to get special treatment this way ? Before fumbling with extraSessionCommands, this weird PATH was inherited by anything launched from Sway.
What is the point of the option programs.sway.extraPackages ? Are these packages somehow integrated into the Sway setup or are they just installed like those in environment.systemPackages ?

Hello,
I have been experimenting with Sway for a while so I would like to share some feedback. I am currently using NixOS 20.09 and GDM as the login manager. Things mostly work, the one thing that I find problematic is the setup of environment variables.
More specifically, when enabling Sway with no customization, simply by saying programs.sway.enable = true in configuration.nix, the session is started without reading /etc/profile nor ~/.profile, so Sway itself and anything it launches ignores any session configuration found in those places. This can be problematic when some variables need to be set up, especially PATH. Besides, when starting terminals, these profiles are not read either because they are not login shells.
My current way out of this problem is to enable Sway this way:
    programs.sway = {
      enable = true;
      extraSessionCommands = ''
        source /etc/profile
        test -f $HOME/.profile && source $HOME/.profile
        export MOZ_ENABLE_WAYLAND=1
        systemctl --user import-environment
      '';
      wrapperFeatures.gtk = true;
    };

I also tried using the systemd approach of putting files in ~/.config/environment.d/ and it works for all variables except for PATH which apparently gets reinitialized before starting the session. Besides, this approach induces some redundancy with ~/.profile (unless environment.d is somehow used also for login shells).
I would be interested if there are better ways to proceed.
For what it's worth, Gnome session on Wayland apparently does read /etc/profile and ~/.profile at some point.
A few other random thoughts while I am at it:

The startup sequence for Wayland sessions is a mystery. Is there any standard that would specify what should happen when logging into a session through a Wayland compositor, particulary regarding the role of the login manager vs the role of the compositor ?
The NixOS wrapper for Sway apparently hard-codes the path to swaybg in PATH. That makes no sense to me. What is so special about swaybg that it has to get special treatment this way ? Before fumbling with extraSessionCommands, this weird PATH was inherited by anything launched from Sway.
What is the point of the option programs.sway.extraPackages ? Are these packages somehow integrated into the Sway setup or are they just installed like those in environment.systemPackages ?

The startup sequence for Wayland sessions is a mystery. Is there any standard that would specify what should happen when logging into a session through a Wayland compositor, particulary regarding the role of the login manager vs the role of the compositor?

AFAIK the compositor isn't responsible for reading any startup files but I'm not aware of any official documentation regarding this. Most Sway users likely start it from a virtual terminal so the login shell will have already taken care of it. For display managers the behaviour likely isn't consistent (IIRC each one tends to do it's own thing).
For Nixpkgs we'd need something like https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/x11/display-managers/default.nix for Wayland. I thought there was already a dedicated issue for this but couldn't find one :o

The NixOS wrapper for Sway apparently hard-codes the path to swaybg in PATH. That makes no sense to me. What is so special about swaybg that it has to get special treatment this way ? Before fumbling with extraSessionCommands, this weird PATH was inherited by anything launched from Sway.

The discussion is in https://github.com/NixOS/nixpkgs/issues/60434. IIRC this was because it's a fixed dependency of Sway and the solution via PATH sucked the least.

What is the point of the option programs.sway.extraPackages ? Are these packages somehow integrated into the Sway setup or are they just installed like those in environment.systemPackages ?

The latter. I guess the main reasons are to make it easy to avoid optional packages by overriding programs.sway.extraPackages and to have a dedicated option for packages that are only/mostly relevant for Sway.

The startup sequence for Wayland sessions is a mystery. Is there any standard that would specify what should happen when logging into a session through a Wayland compositor, particulary regarding the role of the login manager vs the role of the compositor?

AFAIK the compositor isn't responsible for reading any startup files but I'm not aware of any official documentation regarding this. Most Sway users likely start it from a virtual terminal so the login shell will have already taken care of it. For display managers the behaviour likely isn't consistent (IIRC each one tends to do it's own thing).
For Nixpkgs we'd need something like https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/x11/display-managers/default.nix for Wayland. I thought there was already a dedicated issue for this but couldn't find one :o

The NixOS wrapper for Sway apparently hard-codes the path to swaybg in PATH. That makes no sense to me. What is so special about swaybg that it has to get special treatment this way ? Before fumbling with extraSessionCommands, this weird PATH was inherited by anything launched from Sway.

The discussion is in https://github.com/NixOS/nixpkgs/issues/60434. IIRC this was because it's a fixed dependency of Sway and the solution via PATH sucked the least.

What is the point of the option programs.sway.extraPackages ? Are these packages somehow integrated into the Sway setup or are they just installed like those in environment.systemPackages ?

The latter. I guess the main reasons are to make it easy to avoid optional packages by overriding programs.sway.extraPackages and to have a dedicated option for packages that are only/mostly relevant for Sway.

AFAIK the compositor isn't responsible for reading any startup files but I'm not aware of any official documentation regarding this. Most Sway users likely start it from a virtual terminal so the login shell will have already taken care of it.

Well, let me be the counter-example here :-)

For display managers the behaviour likely isn't consistent (IIRC each one tends to do it's own thing).
For Nixpkgs we'd need something like https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/x11/display-managers/default.nix for Wayland. I thought there was already a dedicated issue for this but couldn't find one :o

That indeed seems to be the way to proceed. If Sway appears among the possible sessions in a graphical display manager, then it is expected to be started from there and not from a login shell in the console, so the thing that is run as a session should behave accordingly. A simple sway-session script could do the job: set Wayland-specific environment variables, read profile files, then exec sway.

The NixOS wrapper for Sway apparently hard-codes the path to swaybg in PATH. That makes no sense to me. What is so special about swaybg that it has to get special treatment this way ? Before fumbling with extraSessionCommands, this weird PATH was inherited by anything launched from Sway.

The discussion is in #60434. IIRC this was because it's a fixed dependency of Sway and the solution via PATH sucked the least.

So I'll comment in that issue…

AFAIK the compositor isn't responsible for reading any startup files but I'm not aware of any official documentation regarding this. Most Sway users likely start it from a virtual terminal so the login shell will have already taken care of it.

Well, let me be the counter-example here :-)

For display managers the behaviour likely isn't consistent (IIRC each one tends to do it's own thing).
For Nixpkgs we'd need something like https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/x11/display-managers/default.nix for Wayland. I thought there was already a dedicated issue for this but couldn't find one :o

That indeed seems to be the way to proceed. If Sway appears among the possible sessions in a graphical display manager, then it is expected to be started from there and not from a login shell in the console, so the thing that is run as a session should behave accordingly. A simple sway-session script could do the job: set Wayland-specific environment variables, read profile files, then exec sway.

The NixOS wrapper for Sway apparently hard-codes the path to swaybg in PATH. That makes no sense to me. What is so special about swaybg that it has to get special treatment this way ? Before fumbling with extraSessionCommands, this weird PATH was inherited by anything launched from Sway.

The discussion is in #60434. IIRC this was because it's a fixed dependency of Sway and the solution via PATH sucked the least.

So I'll comment in that issue…

Sway 1.6 changed the default for $WAYLAND_DISPLAY which might cause a few regressions, even if you don't hard-code the value (defaults to wayland-0 when unset). For a quick workaround you might want to add the following to your Sway configuration (especially the 1st command for D-Bus, the second one is only required for some systemd user units):
exec dbus-update-activation-environment WAYLAND_DISPLAY
exec systemctl --user import-environment WAYLAND_DISPLAY

See https://github.com/NixOS/nixpkgs/issues/119445#issuecomment-820507505 for more details.

is there a recommended way forward with regards to dbus on wayland?
i'm specifically asking because apparently setting MOZ_DBUS_REMOTE in the wrapper for element-desktop (#123777)
while fixing opening links for wayland users, broke an X11 user's ability to open links from element-desktop in (presumably) firefox
requiring every sway user to add a workaround seems like something we should avoid if this can be managed via programs.sway.enable (and equivalents for other wayland environments?)
(particularly, i am unwilling to add such a workaround to my system, this should "just work" and i won't add stuff i'll have to remember to remove later)

Some updates:
@evils: If this is regarding https://github.com/NixOS/nixpkgs/issues/57602#issuecomment-820512097 / https://github.com/NixOS/nixpkgs/issues/119445 then it's fixed now by https://github.com/NixOS/nixpkgs/pull/122605. That only works for new Sway users though. If you've already copied the old /etc/sway/config then this requires adding include /etc/sway/config.d/*.
With https://github.com/NixOS/nixpkgs/pull/123034 and https://github.com/NixOS/nixpkgs/pull/122602 screen-sharing should also be easier to get to work now. We've also updated the documentation of the Sway module a little bit.
Btw: Quick heads-up that I'm planning to remove rxvt-unicode from sway.extraPackages (https://github.com/NixOS/nixpkgs/pull/121925) since Alacritty is the new default terminal for Sway for quite some time now.
We're also considering to use a wallpaper in the default configuration for the Sway module but it wasn't decided yet whether to use Sway's default wallpaper (https://github.com/NixOS/nixpkgs/pull/122995) or a NixOS wallpaper (https://github.com/NixOS/nixpkgs/pull/122992). Feedback is welcome.

Btw: Quick heads-up that I'm planning to remove rxvt-unicode from sway.extraPackages (#121925) since Alacritty is the new default terminal for Sway for quite some time now.

Just wanted to mention that sway recently switched to foot as a default terminal: https://github.com/swaywm/sway/commit/009c58fc9529e284569bf58b73964cb3dc7c5baf

If this is regarding ....

this is regarding 123777
as the comment about WAYLAND_DISPLAY seems to be dbus related it seemed likely related to me

Heads-up: The Nix package was just updated to Sway 1.7.
More details: https://github.com/NixOS/nixpkgs/commit/2e719d1cdab9e81750c19425a1f5c7678b5e73ad (https://github.com/NixOS/nixpkgs/pull/151902)

Notable (backward incompatible) changes:

The default terminal changed from Alacritty to foot

Known issues:

swaynag will crash when Sway 1.6.1 is still running while the Nix
package (and thus swaynag) is already updated to version 1.7.
The experimental Ozone/Wayland support of Electron apps will be broken
for a while. Electron version 17 should work but the Chromium fixes
haven't yet been backported to Electron version 16.

The Electron status is tracked in https://github.com/NixOS/nixpkgs/issues/156352.

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/some-lose-ends-for-sway-on-nixos-which-we-should-fix/17728/1

Does anyone experience the return of firefox popup issue (literally all firefox extensions are broken since the popups don't render) on latest unstable? It started to happen since the last mass rebuild from staging has landed to unstable.

@ymatsiuk mine render, never flicker and even have a solid chance of then never going away; willing to send the excess extraneous ones your way =D I'm now on GNOME tho

Here is more about the Firefox issue: https://github.com/NixOS/nixpkgs/issues/167785. I think upstream is looking at fixing it as well.

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/source-profile-with-gdm-and-sway/24561/1

Today I was hit by the problem of sway not sourcing /etc/profile
As most environment variables probably get set by pam_env, but SSH_AUTH_SOCK is set by a bash snippet run in /etc/profile: https://github.com/NixOS/nixpkgs/blob/c43f676c938662072772339be6269226c77b51b8/nixos/modules/programs/ssh.nix#L348-L353 I found it because vscode would fail to connect via ssh when launched outside a shell ( https://github.com/microsoft/vscode-remote-release/issues/8043 ), as SSH_AUTH_SOCK had not been set.
An ad-hoc solution is the following:
  programs.sway.extraSessionCommands = ''
    source /etc/profile
  ''

My guessings are that:

X11 window managers do this sourcing in some sort of xsession init script (?)
Wayland desktop managers exec bash internally (?)

And on a side note, should we wrap sway to get this env, or should sway itself exec bash to get this environment?

Today I was hit by the problem of sway not sourcing /etc/profile

That's actually the intended behaviour (but not everyone likes it - IIRC this already came up a couple of times from users of graphical login managers).
Luckily it's already documented in https://github.com/swaywm/sway/wiki/Setting-Environmental-Variables now:

Environment variables are inherited from the process that starts sway. You need to set variables there.

It would probably best to simply document this in https://nixos.wiki/wiki/Sway (just be aware that it's community maintained and not an official NixOS documentation).

Does anybody have working idle inhibit with firefox (e.g. video playback, video call) running in sway? Not working at all here, current workaround is waybar's idle inhibit module. Not sure where to start debugging this.

I've had good results from https://github.com/rafaelrc7/wayland-pipewire-idle-inhibit


Fix stacked_violin plot bug

num_rows was incorrectly calculated when swap_axes=False in the stacked_violin plot. This fixes issue #405

Thank you for this! Unfortunately, it breaks the tests. It's such a small change, but I guess @fidelram had something in mind when setting it the way he did...

I’ll have another look. But it doesn’t work the way it is now either

@outlace I will check the problem with the test and integrate your changes in a new PR that addresses #512 and #524 if this is OK with you.

@fidelram Sounds good!

@outlace Curiously, your change causes an error. Without your change I can run the tests correctly without a problem. I remember that I fixed a bug similar to this one that was recently integrated into master (see https://github.com/theislab/scanpy/pull/425/files#diff-b5175ed1415cdbf853646e523cbe8ae0L902). Could it be that you didn't have the latest pull from scanpy and that was causing the error?

Possible, I will try pulling the latest master and see if I still get the problem

@outlace do you think I can close this PR?

@fidelram, did that PR happen? I assume #405 got fixed but am not actually sure.

@fidelram, did that PR happen? I assume #405 got fixed but am not actually sure.

yes 405 got fixed. The code was moved to _stacked_violin.py

yes 405 got fixed. The code was moved to _stacked_violin.py

Great, thanks!

Great, thanks!


On-boarding and off-boarding the editorial board members

In Issue #7, @danwallach says:

There were some members of our board who were fantastic about getting their assignments done. Others? Not so much. I don't have fantastic advice about how to get people engaged and keep them productive, nor can I say when it's time to cut the cord. My advice is to create multiple tiers of engagement, and allow people to ramp up and down their commitments. It's probably a good idea to be super inclusive for the editorial board, letting you scale the number of reviews per reviewer without killing anybody. You might also want to consider subcommittees on particular hot topics for any given year, so if we get 30 papers on the same topic which get disjoint reviewers, the subcommittee members will be likely to have better coverage and can reduce some of the randomness inherent in the review process.

Good points!  We do plan to expand the PC, so as to keep the monthly review load relatively low.  We're also currently planning to try to ensure that reviewers only receive new reviews every other month, to help keep things manageable.
As with any conference, we will continue to maintain a history of reviewers that submit high-quality timely reviews, and those who do not, and we'll use that information to inform future PC selections.  VLDB has been fairly successful at doing this, and their PC chairs tell us that they've only had to blacklist a few reviewers.


New settings/general styles

Dem styles

Incorporated into https://github.com/TryGhost/Ghost-Admin/pull/541 with test fixes and accordion toggles


Support RedisTimeSeries

Description

Describe your pull request here
Add support to RedisTimeSeries commands

Checklist

[X] Does npm test pass with this change (including linting)?
[X] Is the new or changed code fully tested?
[ ] Is a documentation update included (if this change modifies existing APIs, or introduces new ones)?

Codecov Report

Merging #1757 (e4d99a8) into master (41bd136) will increase coverage by 0.38%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #1757      +/-   ##
==========================================
+ Coverage   94.13%   94.52%   +0.38%
==========================================
  Files         306      311       +5
  Lines        3122     3195      +73
  Branches      426      432       +6
==========================================
+ Hits         2939     3020      +81
+ Misses        106       96      -10
- Partials       77       79       +2

Impacted Files
Coverage Δ

packages/time-series/lib/commands/DELETERULE.ts
100.00% <100.00%> (+50.00%)
:arrow_up:

packages/time-series/lib/commands/MADD.ts
100.00% <100.00%> (+66.66%)
:arrow_up:

...ckages/time-series/lib/commands/MGET_WITHLABELS.ts
100.00% <100.00%> (ø)

packages/time-series/lib/commands/MRANGE.ts
100.00% <100.00%> (ø)

...ages/time-series/lib/commands/MRANGE_WITHLABELS.ts
100.00% <100.00%> (ø)

packages/time-series/lib/commands/MREVRANGE.ts
100.00% <100.00%> (ø)

...s/time-series/lib/commands/MREVRANGE_WITHLABELS.ts
100.00% <100.00%> (ø)

packages/time-series/lib/commands/RANGE.ts
100.00% <100.00%> (+16.66%)
:arrow_up:

packages/time-series/lib/commands/REVRANGE.ts
100.00% <100.00%> (+16.66%)
:arrow_up:

packages/client/lib/errors.ts
91.66% <0.00%> (-8.34%)
:arrow_down:

... and 8 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 41bd136...e4d99a8. Read the comment docs.


password?

What's the vagrant user's password? After being idle for a bit, OS X requires a login. Could this be configurable? Thanks!

I just tested and confirmed the password for the vagrant user is the typical "vagrant" (w/o quotes).
I feel like I'm missing something obvious -- how are you getting a GUI from this vagrant box?
I'm using it as commandline only so far...

@levelos Hi. User and password is default for Vagrant (vagrant:vagrant) and this user have paswordless sudo.
@WayneBuckhanan to start in GUI mode you should change vb.gui flag to true. Here it is: https://github.com/AndrewDryga/vagrant-box-osx/blob/master/Vagrantfile#L22

Thanks Andrew, I didn't realize it was that obvious :)


Compiling GUI in VS2017 Community Edition

I'm trying to compile the UI and I'm getting this error message:

I compile the leveldb project with the dll option

and I copy the dll file to the bin/Debug folder

Am I missing anything? Is there any other step missing?
Maybe the "interop" version of the leveldb is not the same? How can I update it?
Paulo Aboim Pinto.

Click "View Details" link, and check the inner exceptions.

this is the information

and the stackstrace is

Try to put the libleveldb.dll into x86 or x64 directory.

I did that and got the same error.
this is a not document "feature" ;)
after this, the documentation will be better.

I will release a new version which can log more details about the error.

... dammm
The code that you submit was not compiling in my machine and I'm using VS2017.
The error.log file was generated with the content:
System.BadImageFormatException
An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
at Neo.Implementations.Blockchains.LevelDB.Native.leveldb_options_create()
at Neo.Implementations.Blockchains.LevelDB.LevelDBBlockchain..ctor(String path)
at Neo.Program.Main() in D:\myDevelop\neo-gui-master\neo-gui\Program.cs:line 108
at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[] args)
at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()

The other post was with a project with the Chain folder copy to the Debug. I did this to make usage of the existem blockchain that I already have.
I did a new clone of the Neo-Gui and this is the content in the error.log file
System.BadImageFormatException
An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
at Neo.Implementations.Blockchains.LevelDB.Native.leveldb_options_create()
at Neo.Implementations.Blockchains.LevelDB.LevelDBBlockchain..ctor(String path)
at Neo.Program.Main() in d:\myDevelop\GitHubRepos\neo-gui\neo-gui\Program.cs:line 108

after many ... many atempts I found the issue
the problem is the leveldb dll is compiled in 32bits and the wallet project is AnyCPU. As soon that I change this configuration to x32, I could run the wallet from code.

This could be fixed by adding x86/x64 DLLs in embedded resources, then detecting processor architecture at runtime and choosing the correct one, similar to how SQLite/CLRZMQ packages work, but @erikzhang likely has a reason it's not distributed.

agree .. or at least this way should be documented how to make the project compilable!


simplified test application

This replaces the current app, that has 100s of dependencies, with a much simpler version that has zero dependencies. As a result, this should resolve all of our vulnerabilities.
We do lose some of the cosmetics, but it should be possible to add these back without additional project dependencies.
Also, I was hoping to find an HTML test runner for Mocha, I was surprised that I couldn't find one. Possibly worth more searching.

It's basic but it works.
The README needs updating as some things have changed. Manually hosting the conformance app on the 3000 port solves most issues but this step or some other solution should probably be added.

Thanks @osouthwell-scottlogic

The README needs updating as some things have changed. Manually hosting the conformance app on the 3000 port solves most issues but this step or some other solution should probably be added.

I've added a start script which runs the app in port 3000, so should mean the original README instructions are still relevant
https://github.com/finos/FDC3-conformance-framework/pull/48/commits/c89348529ec1da58ce40cdcbb206e057ad0a3403#diff-012b982f97a0d326aeec58dd3b789484b05a944d609afe1b8ed5e299fc485f61R6

closed via #49


Generated index is not saved if the ".padawan" folder doesn't exist.

The sub-folder is not created before saving the index, so no ".padawan/project" file is created if the sub-folder doesn't exist.

hm, looks like I've broken this after https://github.com/mkusher/padawan.php/commit/65bd91dba04296e8fe21c9a185c17882cca2fca5

should be fixed in https://github.com/mkusher/padawan.php/commit/6816c3262314b57904ec31a1a427b656ffe73f8c


go-gui: modernize

formula modernized
head added (with manually installed quaqua look & feel and docbook help files)
install gogui script to run the app bundle
caveats removed (brew already explains linkapps)
test added

@BrewTestBot test this please

When I run brew test go-gui I get a Java pop-up with "To open “GoGui” you need to install the legacy Java SE 6 runtime."  Can you add a depends_on :java => "1.6" line? Thanks!

depends_on :java => "1.6" added.

Thank you! Merged in 947a9aa594bf2011481aca82386f8dce5a2c3c22.


there is a certain probability that events cannot be triggered automatically on android 9

There is a certain probability that events can not be triggered automatically on android 9.
I use scroller component. On android 7, the appear event can be triggered automatically when the page is opened and no manual scoll page.
However,  on android 9, sometimes, the appear event can not be triggered automatically, even if use scrollToElement to scroll scroller. Only use finger to scroll the scroller, the appear event is triggered.
weex sdk 0.18
Has anyone encountered the same problem?

First upgrade weex to the latest version (0.24.0)
Provide a demo.

I will close your issue and you are welcomed to reopen it when you have a demo.


CI pipeline and badge

hi! this is ci for your project.
The pipeline fails right now - https://ci.sparrowhub.io/report/2199
00:59:30 :: ===> Searching for missing dependencies: Digest, FiniteFields
00:59:58 :: ===> Installing: Digest:ver<0.27.4>
00:59:58 :: ===> Installing: FiniteFields:ver<0.2.0>
00:59:58 :: ===> Install [FAIL] for FiniteFields:ver<0.2.0>: Failed to open file /tmp/.zef/FiniteFields%3Aver%3C0.2.0%3E%3Aauth%3Cgithub%3Agrondilu%3E.tar.gz/finite-fields-raku-master/lib/FiniteField.pm: No such file or directory
[task stderr]

Please be aware that you need to add this repo to your repos list in SparrowCI account to make badge status to known


Slow Inference on A2 with VPTQ Compared to Ollama

I'm encountering performance issues with VPTQ on an Nvidia A2 GPU. Here's a comparison of my results:
Model: Qwen 2.5
VPTQ Performance (Tokens/sec):
v8-k256-256-woft: 5.22
v8-k65536-256-woft: 5.21
v8-k65536-65536-woft: 2.10
v16-k65536-65536-woft: 2.02
v8-k65536-0-woft: 3.77
Ollama Results (Tokens/sec)::
q6 K: 10.06
q5 0: 14.30
What am I doing wrong, and why is VPTQ inference significantly slower on the same hardware?
Thank you!

Thanks for letting me know. I’ve encountered a similar issue, and I’m still investigating the cause. For now, you can try reverting to commit 83ab80a46b94fb8cd5cbb7200eed8ff282c065bb to see if it helps, or directly use the previous model_base from this link.
Additionally, we currently haven’t optimized for inference yet. As you can see, our inference implementation is purely based on PyTorch with simple CUDA kernels. In the future, we plan to leverage existing frameworks like vllm or llama.cpp, which will greatly improve our inference performance. Apologies for the inconvenience.

In the next 1-2 months, I will continue optimizing the inference. Please stay tuned.

I'm trying to discuss with ggerganov at this link, can you help support us? (upvote) :) We really want to integrate into llama.cpp/ollama.

BTW, I found this repo https://github.com/WpythonW/VTPQ-comparsion-custom_UI-example.
Thank you so much for paying attention to our project!
I have a simple web UI here: https://github.com/microsoft/VPTQ/blob/main/vptq/app.py, though it's still quite basic.
The community has contributed with the visualization of GPU memory usage and utilization, thanks to them!


Error: ENOENT errno 34

hey there, i am exited about to install and i did everything like you discribed, test worked fine
Execution Time (2014-12-17 19:52:37 UTC)
jshint:all                 576ms  ▇ 3%
loopback_angular:services   2.2s  ▇▇▇▇ 11%
docular                     9.7s  ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇ 47%
wiredep:app                320ms  ▇ 2%
concurrent:dist             7.2s  ▇▇▇▇▇▇▇▇▇▇▇▇▇ 35%
but
/loopback-angular-admin/server# npm start  gave me an
npm ERR! Error: ENOENT, open '/root/loopback-angular-admin/server/package.json'
npm ERR! If you need help, you may report this entire log,
npm ERR! including the npm and node versions, at:
npm ERR!     http://github.com/npm/npm/issues
npm ERR! System Linux 3.13.0-37-generic
npm ERR! command "/usr/local/bin/node" "/usr/local/bin/npm" "run" "dev"
npm ERR! cwd /root/loopback-angular-admin/server
npm ERR! node -v v0.10.33
npm ERR! npm -v 1.4.28
npm ERR! path /root/loopback-angular-admin/server/package.json
npm ERR! code ENOENT
npm ERR! errno 34
npm ERR!
Thanks for your help and your awsome work ! :+1:

hi everybody
can somebody help me?
I want to install loopback like the official site says
but that dont works for me
npm ERR! Additional logging details can be found in:
npm ERR! /home/usuario/npm-debug.log
npm ERR! not ok code 0
the directory have write permissions, what happs??


Lowered the reading level, and simplified some things

this just makes it easier for newcomers, and non-english speakers to understand
please tell me if i got something wrong, of if i deleted too much

i added things

@death7654 please resolve merge conflicts

It is ready


Backport  solution for #163 (MR !541) to the bst-1.2 branch

See original issue on GitLab
In GitLab by [Gitlab user @jjardon] on Jul 26, 2018, 16:07
This is needed to both freedesktop-sdk and gnome-build-meta project; It would be nice if this functionality can get backported

In GitLab by [Gitlab user @jjardon] on Jul 26, 2018, 16:07
changed the description

In GitLab by [Gitlab user @jjardon] on Jul 26, 2018, 16:27
marked this issue as related to #163

In GitLab by [Gitlab user @jjardon] on Jul 26, 2018, 16:32
mentioned in merge request !572

In GitLab by [Gitlab user @jjardon] on Jul 27, 2018, 10:30
This is done now

In GitLab by [Gitlab user @jjardon] on Jul 27, 2018, 10:30
closed


Attempt to fix RTD failures using Python 3.7

The default Python version has changed from 3.7 to 3.11 when updating Read the Docs configuration. See the announcement of configuration file version 2 for more details [1].
[1] https://blog.readthedocs.com/migrate-configuration-v2/

It is failing with another error now: https://readthedocs.org/projects/stackhpc-kayobe-config/builds/21627190/


Resolves unexpected bind() with nulls set to nullptr behavior.

Closes #122.

I think it'd be good to prevent Travis CI from kicking off two builds for a PR. Right now it seems to create one for the PR and one for the topic branch. Ideally it'd only kick one off for the PR, and just ignore the topic branch.

Rebased off of master w/ the branch whitelist configuration added for CI. Should hopefully make the CI cycles faster and reduce load on Travis and AppVeyor.


AVS Device Make UI Manager cpp file does not meet avs-device-sdk header

When performing the copy from the avs device maker, the new cpp file does not match the header in the device sdk

New update will fix the issue.


Update 1.19.2forge for configuration options

This is really important!

im gonna tac onto this just so i dont open a new ticket, would it be possible for witch mobility to get uploaded to modrinth? thanks.


Add RowLacks

I tried to make the error messages a bit nicer, but they are still bad.
I wonder if we should just solve it in the compiler instead.

Example error:
  29  demo0 = 0 :: RowLacks "k" (k :: String) => Int
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Could not match type

    RowLacking "Existing key found in row" "k"

  with type

    String

  while trying to match type ( k :: RowLacking "Existing key found in row" "k"
                             | t0
                             )
    with type ( k :: String
              , k :: RowLacking "Existing key found in row" "k"
              )
  while solving type class constraint

    Prim.RowCons "k"
                 (RowLacking "Existing key found in row" "k")
                 t0
                 t1

And for the polymorphic case:
  29  demo = 0 :: forall t. RowLacks "k" (k :: t) => Int
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Could not match type

    "Existing key found polymorphically in row"

  with type

    "Existing key found in row"

  while trying to match type RowLacking "Existing key found polymorphically in row"
    with type RowLacking "Existing key found in row"
  while solving type class constraint

    Prim.RowCons "k"
                 (RowLacking "Existing key found polymorphically in row" "k")
                 t0
                 t1

I've found another way to do it with a single pass.  If I include the row in the RowLacking type then it'll cause an infinite type error in the polymorphic case.  The following might be a nicer error?
  28  demo = 0 :: forall t. RowLacks "k" (k :: t) => Int
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  An infinite type was inferred for an expression:

    RowLacking "k"
      ( k :: t0
      )

  while trying to match type RowLacking "k"
                               ( k :: t0
                               )
    with type t0
  while solving type class constraint

    Prim.RowCons "k"
                 (RowLacking "k"
                    ( k :: t0
                    )
                 )
                 t1
                 t2

Instance chains would be nice here, so we could provide a custom error message 😃

Thanks!

I would actually prefer to simplify RowLacking to something like
data SkolemA
data SkolemB

I know the errors won't be as good, but they're already a little confusing honestly.
You might also be interested in this (older) code from constraints:
http://hackage.haskell.org/package/constraints-0.3.3/docs/src/Data-Constraint-Forall.html#Forall

Anything left to do here? :)
Let me know if you want something rewording or whatever.

Looks good to me! Sorry for the slow replies.
@garyb Any thoughts here before I merge?

This is pretty fancy! No complaints from me :shipit:

I think this looks good to merge, but before we do, we should consider the alternative of deriving this in the compiler. We're probably going to end up adding a lot of things to work with rows at some point anyway, so it's probably worth considering.
The error messages might be slightly better, for one, but I do like doing things in libraries if possible.
Any thoughts?

Just tried this again - I've simplified it, it only uses one skolem type, and the error is a bit better.
http://try.purescript.org/?gist=3d4c602fc34075b8a9f99789f903aa80&backend=core&session=40913a4c-d58f-676b-b4ee-cc651d37cff7
Uncomment individual test cases to see the error.

Also you never see the Skolem type in the error!

Ah, one problem is that I'd have to export RowLacking too 😢.

Very clever! I like it.

The errors now look like this:
  16  test = 0 :: RowLacks "k" (k :: Int) => Int
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  No type class instance was found for

    Type.Row.RowLacking Entry "k" Int ( k :: Int )

  while checking that type RowLacks "k" ( k :: Int ) => Int
    is at least as general as type Int
  while checking that expression 0
    has type Int
  in value declaration test

And for the polymorphic case:
  16  test = 0 :: forall t. RowLacks "k" (k :: t) => Int
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  No type class instance was found for

    Type.Row.RowLacking Entry "k" t0 ( k :: t0 )

  The instance head contains unknown type variables. Consider adding a type annotation.

  while checking that type forall t. RowLacks "k" ( k :: t ) => Int
    is at least as general as type Int
  while checking that expression 0
    has type Int
  in value declaration test

  where t0 is an unknown type

I'll squash the commits, then I'm happy with this.  Let me know if you want any changes or if you still want to consider solving in the compiler. @paf31 / @garyb

Sorry, could you merge with master? Then I'll merge this and release.

@paf31 Rebased :)

Thanks again!


stylelint 12.x as peer dependency

Hi,
stylelint 12.0.0 was released but do you have a plan to update the peer dependency?
https://github.com/YozhikM/stylelint-a11y/blob/1c522f677e1bd68420cc47a935e9865dd797159a/package.json#L40
I get the following error when installing stylelint@12 and stylelint-a11y. 😢

npm ERR! peer dep missing<EMAIL_ADDRESS>|| ^9.0.0 || ^10.0.0 || ^11.0.0, required by<EMAIL_ADDRESS>
It would be great if you could consider it.
Thanks.

@YozhikM Thank you so much for the new release 1.2.3! 🎉
https://github.com/YozhikM/stylelint-a11y/releases/tag/1.2.3


namespace (Patchwork) and convert to PSR-4 (fixes #11)

Previously JSqueeze claimed PSR-0 compliance in composer.json but was not in fact compliant, as PSR-0 requires at least one level of namespacing, bare classes are not PSR-0 compliant. As PSR-4 has now deprecated PSR-0, convert to PSR-4 while we're about it, which has the handy bonus of meaning the class file does not need to be moved at all.
This is an obvious BC break: all consumers have to switch from calling new \JSqueeze() to new \Patchwork\JSqueeze().
My erstwhile colleague Remi Collet contends the namespace should be Patchwork\Jsqueeze , I don't really care, I just want to cry myself to sleep at this point.

I forgot you PR while working on #11 sorry...

I forgot you PR while working on #11 sorry...

that's totally fine, I don't care who gets the credit :P

that's totally fine, I don't care who gets the credit :P


mobile: fix new book/sort buttons for my library, my contributions, and favorite books pages

Done!


ATS 10.0.x,  *_HIT always on event log.  NO TCP_MISS with ttl-in-cache on cache.config at all

hello !
i would like to ask about cache.config
cache.config is below

dest_domain=test2222.kinxzone.com ttl-in-cache=20s

records.yaml is below

records:
  http:
    connect_attempts_max_retries: 3
    cache:
      http: 1
      required_headers: 0
      max_stale_age: 0
    server_ports: 80 80:ipv6 443:ssl
    normalize_ae: 2
  reverse_proxy:
    enabled: 1
  url_remap:
    pristine_host_hdr: 0
    remap_required: 1
  log:
    logging_enabled: 3
    logfile_dir: var/log/trafficserver
    rolling_enabled: 1
    rolling_interval_sec: 300
    rolling_allow_empty: 1
    rolling_max_count: 10
  ssl:
    client:
      version:
        min: 2
        max: 3
      certification_level: 1
      verify:
        server:
          policy: PERMISSIVE
    server:
      multicert:
        exit_on_load_fail: 0
      cert:
        path: /opt/ts/etc/trafficserver/ssl
      private_key:
        path: /opt/ts/etc/trafficserver/ssl
  diags:
    debug:
      enabled: 1

and i did curl https://test2222.kinxzone.com/cat/cat1.jpg
about 20 seconds later, i did curl https://test2222.kinxzone.com/cat/cat1.jpg again
but always *_HIT   Nothing TCP_MISS
even i set revalidate 20s
and, pin-in-cache 20s
but same result
i refered https://docs.trafficserver.apache.org/en/10.0.x/admin-guide/files/cache.config.en.html
i know that PURGE method can be used to clear cache exactly
curl -X PURGE https://test2222.kinxzone.com/cat/cat1.jpg
it works well,
and invalidating cache by using regex revalidate plugin as well
event.log is below

1724744803 3 <IP_ADDRESS> 200 6345 GET https://test2222.kinxzone.com/cat/cat1.jpg 443 - "curl/7.81.0" - "-" TLSv1.3 TCP_HIT 0 5912 <IP_ADDRESS>
1724744804 2 <IP_ADDRESS> 200 6345 GET https://test2222.kinxzone.com/cat/cat1.jpg 443 - "curl/7.81.0" - "-" TLSv1.3 TCP_HIT 1 5912 <IP_ADDRESS>
1724744804 2 <IP_ADDRESS> 200 6345 GET https://test2222.kinxzone.com/cat/cat1.jpg 443 - "curl/7.81.0" - "-" TLSv1.3 TCP_MEM_HIT 2 5912 <IP_ADDRESS>
1724744804 2 <IP_ADDRESS> 200 6345 GET https://test2222.kinxzone.com/cat/cat1.jpg 443 - "curl/7.81.0" - "-" TLSv1.3 TCP_MEM_HIT 3 5912 <IP_ADDRESS>
1724744829 2 <IP_ADDRESS> 200 6345 GET https://test2222.kinxzone.com/cat/cat1.jpg 443 - "curl/7.81.0" - "-" TLSv1.3 TCP_MEM_HIT 4 5912 <IP_ADDRESS>

i would like to see TCP_MISS on event.log
how to set cache.config for setting ttl exactly ?
Please give me some any informations
@bneradt @calavera @janfrode @biilmann @jpeach @sekimura @mlibbey
thank you !!!

maybe cache.config does not work at all
please check cache.config please
https://docs.trafficserver.apache.org/en/10.0.x/admin-guide/files/cache.config.en.html
so, i used header_rewrite plugin to set Cache-Control: max:age <seconds> on READ_RESPONSE_HDR_HOOK
and i solved it


update WDC version

fixed sha1

Testing:

https://ci.appveyor.com/project/ingenue/hunter/build/1.0.2223
https://travis-ci.org/ingenue/hunter/builds/267333981?utm_source=github_status&utm_medium=notification

I sealed the url.

Testing:

https://ci.appveyor.com/project/ingenue/hunter/build/1.0.2225
https://travis-ci.org/ingenue/hunter/builds/267459767?utm_source=github_status&utm_medium=notification

Uploading:

https://ci.appveyor.com/project/ingenue/hunter/build/1.0.2228
https://travis-ci.org/ingenue/hunter/builds/267506098?utm_source=github_status&utm_medium=notification

Released:

https://github.com/ruslo/hunter/releases/tag/v0.19.79


Issue on Android N

https://github.com/IsseiAoki/SimpleCropView/pull/102
Why this is closed without merging?
i am getting error using android N version.
java.lang.RuntimeException: android.os.TransactionTooLargeException: data parcel size 20195964 bytes
Please look on this

In the new version, CropImageView does not save bitmap internally . Please use the version 1.1.5 and see also new sample.


[fix][broker]optimize the shutdown sequence of broker service when it close

Fixed #16755
Motivation
see #16755
Modifications

Close protocol handler before closing broker server. Because the protocol handler service maybe depends on broker service.
First close the acceptorGroup and workerGroup service of BrokerService. Because they can accept the request from outside.

Verifying this change

[x]  Make sure that the change passes the CI checks.

This change is a trivial rework / code cleanup without any test coverage.
Does this pull request potentially affect one of the following parts:
If yes was chosen, please highlight the changes

Dependencies (does it add or upgrade a dependency): (no)
The public API: (no)
The schema: (no)
The default values of configurations: (no)
The wire protocol: (no)
The rest endpoints: (no)
The admin cli options: (no)
Anything that affects deployment: (no)

Documentation
Check the box below and label this PR (if you have committer privilege).
Need to update docs?

[x] doc-not-needed

/pulsarbot run-failure-checks

/pulsarbot run-failure-checks

/pulsarbot run-failure-checks

/pulsarbot run-failure-checks

/pulsarbot run-failure-checks

If the EventLoop is closed first, the client reconnection will fail.
The reconnection won't retry to other brokers?

/pulsarbot run-failure-checks

/pulsarbot run-failure-checks

/pulsarbot run-failure-checks

/pulsarbot run-failure-checks

If the EventLoop is closed first, the client reconnection will fail.

The reconnection won't retry to other brokers? @Technoboy-

Bundle is not unloaded at the moment.

If the EventLoop is closed first, the client reconnection will fail.

The reconnection won't retry to other brokers? @Technoboy-

Bundle is not unloaded at the moment.

True. Closing protocol handler first is reasonable because the outside service maybe depends on broker service. How about it ?


dpotrf + dpotri: Windows vs Linux

I've come across what looks like an anomalous difference in performance inverting a positive definite matrix using dpotrf() and dpotri(), on Windows as compared with Linux. This is on a dual-boot SkylakeX laptop, using OpenBLAS 0.3.28, compiled with gcc 14.2.0 on Arch Linux and cross-compiled with x86_64-mingw-w64-mingw32-gcc 14.2.0 for Windows 11, in both cases using OpenMP for threading. The configuration flags are mostly the same for the two OpenBLAS builds, except that the Windows build uses DYNAMIC_ARCH=1 but the Linux one is left to auto-detect SkylakeX.
The context is a Gibbs sampling operation with many thousands of iterations, so the performance difference becomes very striking. My test rig iterates inversion of a sequence of p.d. matrices of moderate size, from dimension 4 to 64 by powers of 2. Given the moderate size, multi-threading is not really worthwhile. Best performance is achieved by setting OMP_NUM_THREADS=1; in that case the rig runs very fast on both platforms, with Windows marginally slower than Linux. But if I set the number of OMP threads to equal the number of physical cores (4), which is the default in the program I'm working with,

there's just a slight degradation of performance on Linux, but
the performance on Windows becomes really horrible, 10 or more times slower than Linux.

I'd be very grateful if anyone can offer insight into what might be going on here. I'd be happy to supply more details depending on what might be relevant.

can you set OPENBLAS_VERBOSE=2 in the Windows environment please, just to be sure that it uses SKYLAKEX there too as expected ? there may be a few places in the code where OpenMP is handled differently on the two platforms, and I guess the libgomp runtime on Windows may differ from the Linux implementation too... I'm currently at a conference with limited access to decent hardware, so it may take me a few days to investigate

Thanks for looking into this, Martin. I can confirm that SKYLAKEX is detected on Windows.

Any more thoughts on this?

Thanks, Martin. OMP_WAIT_POLICY=passive does have an influence: it makes the problem a good deal worse! We have used earlier versions of OpenBLAS. We noticed the problem only recently, by chance -- it may well have been there before, unnoticed. Anyway I'm attaching a self-contained test-case and I'll inline below the results from running it on a few systems.
Aside from the relatively extreme problem on Windows, it seems to me that in general the matrix size at which multi-threading kicks in is much too small for optimality. In lapack/potrf/potrf_L_parallel.c there's this clause:
if (n <= GEMM_UNROLL_N * 4) {
    info = POTRF_L_SINGLE(args, NULL, range_n, sa, sb, 0);
    return info;
}

In many cases the default value of DGEMM_UNROLL_N is 4, so this policy would start multi-threading at n = 17. From experimentation on several machines with various Intel and AMD processors I think the threshold should be much higher, in the range 100-150.
Anyway, here are the results I have from the test case. The times are for 50000 replications of a p.d. matrix. "default"  means letting OpenBLAS decide how many threads to use (with a limit equal to the number of physical cores), and "single" means forcing use of a single thread. All the machines referenced below are quad-core.
Arch Linux, OpenBLAS 0.3.28, blascore HASWELL
Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz

Times in seconds plus ratio default/single:

  n   default    single     d/s
  4    0.0456    0.0471    0.97
  8    0.0656    0.0652    1.01
 16    0.1386    0.1378    1.01
 17    0.5386    0.1498    3.60
 32    0.7247    0.4257    1.70
 64    2.4502    1.6720    1.47

Windows 11, OpenBLAS 0.3.28, blascore SKYLAKEX
11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80 GHz

Times in seconds plus ratio default/single:

  n   default    single     d/s
  4    0.0400    0.0680    0.59
  8    2.2960    0.0940   24.43
 16    6.7490    0.1860   36.28
 17    8.9470    0.2000   44.73
 32   15.9350    0.5670   28.10
 64   36.5520    2.2400   16.32

Arch Linux, OpenBLAS 0.3.28, blascore SKYLAKEX
11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80 GHz

Times in seconds plus ratio default/single:

  n   default    single     d/s
  4    0.0416    0.0425    0.98
  8    0.2349    0.0546    4.30
 16    0.6412    0.1092    5.87
 17    0.8500    0.1417    6.00
 32    1.6334    0.3540    4.61
 64    4.8043    1.3387    3.59

Fedora, OpenBLAS 0.3.21, blascore SANDYBRIDGE
Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz

Times in seconds plus ratio default/single:

  n   default    single     d/s
  4    0.0872    0.0813    1.07
  8    0.1041    0.1049    0.99
 16    0.6036    0.1979    3.05
 17    0.8675    0.2146    4.04
 32    1.7614    0.6149    2.86
 64    6.5231    2.8875    2.26

invpd.c.txt

Thank you very much. Unfortunately I did not manage to do much so far, but at least this does not appear to be a recent regression.

From individual timing of the two functions, the problem appears to be specifically related to POTRI rather than POTRF. There used to be a reimplementation of POTRI in OpenBLAS but this was disabled ten years ago in #410 due to problems with the code (and subsequent suggestions that the function itself posed no bottleneck). The POTRI from Reference-LAPACK is basically a frontend for TRTRI, which again OpenBLAS reimplements. Contrary to the one for POTRF, this reimplementation currently uses full-on multithreading even for the smallest workloads, which is addressed by #4994
Why this leads to pronounced hangs in Windows is still unclear to me, but it appears to be a misfeature of the implementation of libgomp there.

Thanks, Martin. I too did some more timing tests, and I agree that it's POTRI rather than POTRF that's the trigger for the slowdown on Windows.

The behaviour when compiled with LLVM19 (and its libomp) appears to be a lot more Linux-like even without my small correction from #4994.
Unfortunately that version still appears to have some problem with AVX512 code on Windows, although OpenBLAS itself builds and tests without errors. Thought we could finally put those behind us, but your test code crashes with weird symptoms unless I build OpenBLAS for the Haswell target... At least it seems to confirms that something in the way GNU libgomp implements thread idling or locking is to blame for the extremely poor performance originally observed

Hi,
look at these results:

clang under msys2 or native ms windows clang (yes, used with MS SDK) or msvc (cl.exe): all these three combinations result in very similar timings:

Using default threading...
Forcing single-threaded behavior...
Times in seconds plus ratio default/single:
n   default    single     d/s
4    0.1426    0.0902    1.58
8    0.1254    0.1251    1.00
16    0.2436    0.2429    1.00
17    6.2650    6.0594    1.03
32    3.6997    3.6944    1.00
64   11.5803   11.5690    1.00

gcc under msys2:
Using default threading...
Forcing single-threaded behavior...
Times in seconds plus ratio default/single:
n   default    single     d/s
4    0.0910    0.0950    0.96
8    0.1260    0.1250    1.01
16    0.2420    0.2410    1.00
17    6.0890    0.2610   23.33
32    3.7180    0.7400    5.02
64   11.6410    3.1500    3.70

OpenBLAS 0.3.28, Win10, i5-4460 @3.2GHz
Marcin

hi Marcin, thanks for the data - is this with USE_OPENMP=1 as well ? Very similar timing for the native MSVC build is a bit surprising as that would be using generic C kernels instead of the optimized GEMM (MSVC still does not support our unix-y style of assembly)

Hi,
yes: with USE_OPENMP=1 results are pretty much the same. (In addition I re-created *.def and *.lib files.)
On screenshot: left-hand side are msys2 results (gcc, next clang); right-hand side are native MS results (clang, next msvc).

So it might be related with 'libgomp', but it may also have something to do with gcc itself.

interesting, thanks - maybe the Windows11 scheduler plays a role as well (at least with my Zen 5/5c). at least PR #4994 should not hurt in any case - I think

Marcin, in your results above it seems that only in the gcc case (top left) is single-threading actually being imposed. In the other cases supposed "single-threading" makes no difference. In my test code "single" is specified by
omp_set_num_threads(1);
and this doesn't seem to be doing anything in the clang and msvc cases.

Ahh, you're right!!!
So, forcing single-threaded via OMP_NUM_THREADS=1 yields int the following results (left-hand side clang under msys2, right-hand side native clang and later msvc:

omp_set_num_threads(1);
and this doesn't seem to be doing anything in the clang and msvc cases.

Allin, but shouldn't omp_set_num_threads()/omp_get_num_threads() be used inside #pragma block? (This is how I understand the OpenMP standard).
I'm asking because when I did something like that, both functions started to for me with clang, though only on Linux.

My impression is that #pragma is needed only when launching a team of threads.


Calendar skill skip CollectAttendee step when answering twice with unrecognizable contact

Project
Virtual Assistant
Description
In Calendar skill, CreateEvent scenario, when asked for participant, the dialog continues after you answer with unrecognizable contact twice when it should keep asking
To Reproduce
user: schedule a meeting
bot: who are the participants?
user: lauren
bot: I cannot find the contact your are looking for right now. Please include more details, do you want to try again?
user: lauren
bot: Alright, I will send this to , what is the subject of the meeting?
Expected behavior
the bot should keep asking if the contact is unrecognizable
Screenshots

Additional context
This could be a common issue in all scenarios

fixed in #216


script execution generates trace back in debug mode

From<EMAIL_ADDRESS>on 2011-08-18T10:18:40Z
What steps will reproduce the problem?
When a python console is closed there is a traceback visible when running in debug mode. This only persist when multiple consoles are open. Note that closing an Ipython console does not give this traceback.
Traceback when closing a console (consistent for python and Ipython):
Traceback (most recent call last):
File "/home/dave/Projects/spyderlib/spyderlib/plugins/externalconsole.py", line 685, in <lambda>
lambda sid=id(shellwidget): self.process_finished(sid))
File "/home/dave/Projects/spyderlib/spyderlib/plugins/externalconsole.py", line 716, in process_finished
self.inspector.shell_terminated(shell.shell)
File "/home/dave/Projects/spyderlib/spyderlib/plugins/inspector.py", line 657, in shell_terminated
self.shell = self.get_running_python_shell()
File "/home/dave/Projects/spyderlib/spyderlib/plugins/inspector.py", line 646, in get_running_python_shell
shell = self.external_console.get_running_python_shell()
File "/home/dave/Projects/spyderlib/spyderlib/plugins/externalconsole.py", line 455, in get_running_python_shell
if shellwidget.is_interpreter():
TypeError: 'bool' object is not callable
Further, executing a script in the current console fails (for both python and Ipython) and delivers following traceback:
Traceback (most recent call last):
File "/home/dave/Projects/spyderlib/spyderlib/plugins/externalconsole.py", line 462, in run_script_in_current_shell
shellwidget = self.__find_python_shell(interpreter_only=True)
File "/home/dave/Projects/spyderlib/spyderlib/plugins/externalconsole.py", line 435, in __find_python_shell
if not interpreter_only or shellwidget.is_interpreter():
TypeError: 'bool' object is not callable What version of the product are you using? On what operating system? Ubuntu 10.04 64bit
Python 2.6.5, Qt 4.6.2, pyqt 4.7.2, IPython 0.10
Spyder 2.1.0dev ()
The problem appeared after following commit:
(95f5eaa15e09) Added new IPython plugin supporting IPython Qt console (requires IPython v0.12dev)
Original issue: http://code.google.com/p/spyderlib/issues/detail?id=735

From<EMAIL_ADDRESS>on 2011-08-19T01:34:14Z
There is a contradiction in the post:
Traceback when closing a console (consistent for python and Ipython):
is contradicting:
Note that closing an Ipython console does not give this traceback.
It seems that it kind of depends on how many consoles you have open whether or not closing an Ipython consoles results in the traceback.

From pierre.raybaut on 2011-08-21T06:35:20Z
This issue was closed by revision be83f1c93b0c .
Status: Fixed


Update Speakers section with the images of 2019 speakers

Manoj's picture is required

Fixed as a part of PR #7


Crash in iOS 9 Devices. LGSideMenuController.m line 1210 -[LGSideMenuController setRootViewController:]

Hi,
An app I developed is crashing on iOS 9.0 devices in LGSideMenuController.m line 1210 -[LGSideMenuController setRootViewController:].
Any idea on why this is occurring? I am not able to reproduce this on my end in simulator. But I got several crash logs in Crashlytics, and the numbers are high. Any help or suggestions would be appreciated. The app is live in AppStore and needs urgent fix for this issue. Thanks in advance.
Added full crash log below:
Crashed: com.apple.main-thread
0  libobjc.A.dylib                0x1976a5bdc objc_msgSend + 28
1  UIKit                          0x18865bfb4 -[UINibStringIDTable lookupKey:identifier:] + 132
2  UIKit                          0x188657c04 -[UINibDecoder decodeObjectForKey:] + 48
3  UIKit                          0x1885399e4 -[UIProxyObject initWithCoder:] + 104
4  UIKit                          0x188657fdc UINibDecoderDecodeObjectForValue + 672
5  UIKit                          0x188657d24 -[UINibDecoder decodeObjectForKey:] + 336
6  UIKit                          0x188539c38 -[UIRuntimeConnection initWithCoder:] + 188
7  UIKit                          0x18853a3d8 -[UIRuntimeEventConnection initWithCoder:] + 68
8  UIKit                          0x188657fdc UINibDecoderDecodeObjectForValue + 672
9  UIKit                          0x188658154 UINibDecoderDecodeObjectForValue + 1048
10 UIKit                          0x188657d24 -[UINibDecoder decodeObjectForKey:] + 336
11 UIKit                          0x188538f6c -[UINib instantiateWithOwner:options:] + 1220
12 UIKit                          0x1883e414c -[UIViewController _loadViewFromNibNamed:bundle:] + 376
13 UIKit                          0x1881b049c -[UIViewController loadView] + 176
14 UIKit                          0x188073d44 -[UIViewController loadViewIfRequired] + 144
15 UIKit                          0x188073c9c -[UIViewController view] + 28
16 *******                       0x100100204 -[LGSideMenuController setRootViewController:] (LGSideMenuController.m:1210)
17 *******                       0x10046da74 LoginViewController.(loginAction() -> ()).(closure #1) (MainViewController.swift:36)
18 Alamofire                      0x100e757b8 specialized DataRequest.(response<A where ...> (queue : DispatchQueue?, responseSerializer : A, completionHandler : (DataResponse<A.SerializedObject>) -> ()) -> Self).(closure #1).(closure #1) (ResponseSerialization.swift)
19 libdispatch.dylib              0x197eb16e8 _dispatch_call_block_and_release + 24
20 libdispatch.dylib              0x197eb16a8 _dispatch_client_callout + 16
21 libdispatch.dylib              0x197eb6db0 _dispatch_main_queue_callback_4CF + 1844
22 CoreFoundation                 0x182a981f8 CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE + 12
23 CoreFoundation                 0x182a96060 __CFRunLoopRun + 1628
24 CoreFoundation                 0x1829c4ca0 CFRunLoopRunSpecific + 384
25 GraphicsServices               0x18dc00088 GSEventRunModal + 180
26 UIKit                          0x1880dcffc UIApplicationMain + 204
27 *********                       0x10011e0dc main (AppDelegate.swift:20)
28 libdyld.dylib                  0x197ee28b8 start + 4

I already told you I did not think it came from the library.
https://github.com/John-Lluch/SWRevealViewController/issues/674#issuecomment-276003088

@iDevelopper If the crash is because of usage of any new methods available since iOS 10, then it should crash on iOS8 devices also, which is not happening. The crash is happening only in iOS 9 devices. The issue which you linked is for SWRevealViewController and I removed it and used LGSideMenuController. I have implemented the logic same like in the sample using Storyboard.

If it does not crash on iOS8, you are right. But if it crash with the two librairies, then the problem comes from elsewhere, no? I have tested your application on my iPad 9.

@iDevelopper Is it crashing on your iPad?

The first time I try it some days ago, no. And now yes, at launch I can see a white screen during few seconds ans it crash. iPad mini iOS 9.3.2.

I think this issue is not a problem of the library. Probably you have some errors in your own code.


Add GitHub Docs Annotations to Code Blocks

Resolved #367

Tested this and it doesn't work, so I'm converting this PR to a draft.


prerelease-0.1.0

Pull Request Test Coverage Report for Build<PHONE_NUMBER>-1

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall First build on chore/prerelease-0.1.0 at 91.001%

Totals

Change from base Build<PHONE_NUMBER>-1:
91.0%

Covered Lines:
7524

Relevant Lines:
8268

💛  - Coveralls