aplay -L does not list BT device

Built bluealsa from git (Version 3.1.0.r90.g0c9d8c1) and this repo as well (Version r15.f07fdd6)
I have bluealsa, bluealsa-aplay and bluealsa-monitor running. I do not know if I am expecting the right thing, but my expectation is that if all 3 are running and I connect a headphone that it will show up in 'aplay -L'. I do not get that. Do I understand correctly?
I did make one change to your bluealsa-monitor.service file. I added a 'User=http' to it and bluealsa-aplay.service as we have many services running as user http, though no user is logged in. Bluealsa is still being run as a service as root (it will not run as http). I am guessing that permissions or ownership is the problem? Will this allow the permissions to be set properly?
I have the config file in http's home directory. I have a /etc/dbus-1/system.d/bluealsa.conf file which was installed with the latest bluealsa package I built.
As user http:
$ pwd
/srv/http
$ cat .local/bluealsa-monitor/asoundrc
# DO NOT EDIT - automatically managed by bluealsa-monitor service
bluealsa.default.capture.pcm {
type asym
capture.pcm "pcm.bluealsa:PROFILE=a2dp"
playback.pcm {
@func refer
name "bluealsa.default.playback.fallback"
default sysdefault
}
hint.show on
hint.description "Capture: Bluetooth default, Playback: sysdefault"
}
bluealsa.default.playback.pcm {
type asym
capture.pcm {
@func refer
name "bluealsa.default.capture.fallback"
default sysdefault
}
playback.pcm "pcm.bluealsa:PROFILE=a2dp"
hint.show on
hint.description "Capture: sysdefault, Playback: Bluetooth default"
}
bluealsa.default.duplex.pcm {
type empty
slave.pcm "pcm.bluealsa:PROFILE=a2dp"
hint.show on
hint.description "Bluetooth default"
}
namehint.ctl.bluealsa "bluealsa|BlueALSA global control device"~$ cat .local/bluealsa-monitor/asoundrc
# DO NOT EDIT - automatically managed by bluealsa-monitor service
bluealsa.default.capture.pcm {
type asym
capture.pcm "pcm.bluealsa:PROFILE=a2dp"
playback.pcm {
@func refer
name "bluealsa.default.playback.fallback"
default sysdefault
}
hint.show on
hint.description "Capture: Bluetooth default, Playback: sysdefault"
}
bluealsa.default.playback.pcm {
type asym
capture.pcm {
@func refer
name "bluealsa.default.capture.fallback"
default sysdefault
}
playback.pcm "pcm.bluealsa:PROFILE=a2dp"
hint.show on
hint.description "Capture: sysdefault, Playback: Bluetooth default"
}
bluealsa.default.duplex.pcm {
type empty
slave.pcm "pcm.bluealsa:PROFILE=a2dp"
hint.show on
hint.description "Bluetooth default"
}
namehint.ctl.bluealsa "bluealsa|BlueALSA global control device"

With bluealsa-aplay, I get this:
$ bluealsa-aplay -l
**** List of PLAYBACK Bluetooth Devices ****
bluealsa-aplay: W: Couldn't get BlueZ device properties: Rejected send message, 3 matched rules; type="method_call", sender=":1.313" (uid=33 pid=7626 comm="bluealsa-aplay -l ") interface="org.freedesktop.DBus.Properties" member="GetAll" error name="(unset)" requested_reply="0" destination="org.bluez" (uid=0 pid=305 comm="/usr/lib/bluetooth/bluetoothd ")
: 70:BF:92:D8:82:84 [],
A2DP (SBC): S16_LE 2 channels 48000 Hz
SCO (CVSD): S16_LE 1 channel 8000 Hz
**** List of CAPTURE Bluetooth Devices ****
bluealsa-aplay: W: Couldn't get BlueZ device properties: Rejected send message, 3 matched rules; type="method_call", sender=":1.313" (uid=33 pid=7626 comm="bluealsa-aplay -l ") interface="org.freedesktop.DBus.Properties" member="GetAll" error name="(unset)" requested_reply="0" destination="org.bluez" (uid=0 pid=305 comm="/usr/lib/bluetooth/bluetoothd ")
: 70:BF:92:D8:82:84 [],
SCO (CVSD): S16_LE 1 channel 8000 Hz
The device in question is attached and shows no errors when I look for it as root:
# bluealsa-aplay -l
**** List of PLAYBACK Bluetooth Devices ****
hci0: 70:BF:92:D8:82:84 [Jabra Evolve2 65], audio-headset
  A2DP (SBC): S16_LE 2 channels 48000 Hz
  SCO (CVSD): S16_LE 1 channel 8000 Hz
**** List of CAPTURE Bluetooth Devices ****
hci0: 70:BF:92:D8:82:84 [Jabra Evolve2 65], audio-headset
  SCO (CVSD): S16_LE 1 channel 8000 Hz

but alsa does not know about it:
# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Headphones [bcm2835 Headphones], device 0: bcm2835 Headphones [bcm2835 Headphones]
  Subdevices: 8/8
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
  Subdevice #7: subdevice #7
card 1: sndrpihifiberry [snd_rpi_hifiberry_dacplus], device 0: HiFiBerry DAC+ Pro HiFi pcm512x-hifi-0 [HiFiBerry DAC+ Pro HiFi pcm512x-hifi-0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
# aplay -L
null
    Discard all samples (playback) or generate zero samples (capture)
lavrate
    Rate Converter Plugin Using Libav/FFmpeg Library
samplerate
    Rate Converter Plugin Using Samplerate Library
speexrate
    Rate Converter Plugin Using Speex Resampler
jack
    JACK Audio Connection Kit
oss
    Open Sound System
pipewire
    PipeWire Sound Server
pulse
    PulseAudio Sound Server
speex
    Plugin using Speex DSP (resample, agc, denoise, echo, dereverb)
upmix
    Plugin for channel upmix (4,6,8)
vdownmix
    Plugin for channel downmix (stereo) with a simple spacialization
default:CARD=Headphones
    bcm2835 Headphones, bcm2835 Headphones
    Default Audio Device
sysdefault:CARD=Headphones
    bcm2835 Headphones, bcm2835 Headphones
    Default Audio Device
usbstream:CARD=Headphones
    bcm2835 Headphones
    USB Stream Output
default:CARD=sndrpihifiberry
    snd_rpi_hifiberry_dacplus, HiFiBerry DAC+ Pro HiFi pcm512x-hifi-0
    Default Audio Device
sysdefault:CARD=sndrpihifiberry
    snd_rpi_hifiberry_dacplus, HiFiBerry DAC+ Pro HiFi pcm512x-hifi-0
    Default Audio Device
usbstream:CARD=sndrpihifiberry
    snd_rpi_hifiberry_dacplus
    USB Stream Output

and as user http, it also has errors:
$ bluealsa-aplay -L
bluealsa-aplay: W: Couldn't get BlueZ device properties: Rejected send message, 3 matched rules; type="method_call", sender=":1.315" (uid=33 pid=7688 comm="bluealsa-aplay -L ") interface="org.freedesktop.DBus.Properties" member="GetAll" error name="(unset)" requested_reply="0" destination="org.bluez" (uid=0 pid=305 comm="/usr/lib/bluetooth/bluetoothd ")
bluealsa:SRV=org.bluealsa,DEV=70:BF:92:D8:82:84,PROFILE=a2dp
    , , playback
    A2DP (SBC): S16_LE 2 channels 48000 Hz
bluealsa:SRV=org.bluealsa,DEV=70:BF:92:D8:82:84,PROFILE=sco
    , , playback
    SCO (CVSD): S16_LE 1 channel 8000 Hz
bluealsa:SRV=org.bluealsa,DEV=70:BF:92:D8:82:84,PROFILE=sco
    , , capture
    SCO (CVSD): S16_LE 1 channel 8000 Hz

Well, you definitely have D-Bus permission issues for the http user, that will prevent both bluealsa-aplay and bluealsa-cli from functioning correctly. My guess is that either user http is not a member of the audio group, or you have not restarted the D-Bus daemon to make it re-read the group membership. If that guess is wrong, then its difficult for me to see exactly what is wrong - I am not an expert at troubleshooting D-Bus errors.
Also, I am surprised that the bluealsa-monitor data file is being placed under ~http/.local/ - when used with systemd the user temporary runtime data directory ($XDG_RUNTIME_DIR) is normally /run/$(id -u http)/

So I think the lack of $XDG_RUNTIME_DIR is because this is a system session, not a user session. I'll have to think of a better location for the data file in this case - possibly /var, or maybe there is a way to have the .system file tell systemd to create a directory under /run before it starts the service. The reason I would prefer to avoid /home is that is most likely on the sdcard, whereas I think we should be using a tmpfs for this data.

Thanks for looking into this.
I did check and bluealsa is a member of the audio group:
# groups http
audio render video weston-launch http

I have run around in circles with weston witha similar issue as weston is also designed to be run as a user yet in our 'kiosk' type setup it needs to be started by the system. To do all this, I set XDG and other environment variables like I do when I start weston/luakit. when I start it, I first start weston and need to go through gyrations with it, then need to start luakit and can start it as http user/group.
in the weston.service I created, I use this:
...
Group=http  # systemd will allow me to set the group
RuntimeDirectory=weston
RuntimeDirectoryMode=0755
Environment="XDG_RUNTIME_DIR=/run/weston"
ExecStart=/usr/bin/weston --tty=1 --log=/var/log/runeaudio/weston.log --config=/srv/http/.config/weston.ini --modules=systemd-notify.so
ExecStartPost=/usr/bin/chown -R http:http /run/weston/  # need to change ownership after the folder is created

then when I start luakit, it can start as user http but I have to manually set the environment
[Service]
Type=simple
User=http
Group=http
WorkingDirectory=/srv/http
Environment="HOME=/srv/http"
Environment="XDG_RUNTIME_DIR=/run/weston"
Environment="WAYLAND_DISPLAY=wayland-0"
Environment="XDG_SESSION_TYPE=wayland"
Environment="GDK_BACKEND=wayland"
ExecStartPre=/bin/sleep 2
ExecStart=/usr/bin/luakit localhost

I can try something similar to this with bluealsa-monitor and see how far I get.

I tried this and get what I think is what it is 'supposed' to be, but you will have to guide me a bit...
[Unit]
Description=Bluealsa PCM manager
Documentation=https://github.com/borine/bluealsa-monitor

[Service]
Type=simple
Group=http
RuntimeDirectory=bluealsa-monitor
RuntimeDirectoryMode=0755
Environment="XDG_RUNTIME_DIR=/run"
Environment="HOME=/srv/http"
ExecStart=/usr/bin/bluealsa-monitor
ExecStartPost=/usr/bin/chown -R http:http /run/bluealsa-monitor

[Install]
WantedBy=default.target

This starts without error but still nothing under aplay -l and I get this file structure so asoundrc  is not owned by http. Maybe I need to wait a second then chown it... :
# ls -al /run/bluealsa-monitor/
total 4
drwxr-xr-x  2 http http   60 Jan 31 10:03 .
drwxrwxrwx 29 root root  660 Jan 31 10:03 ..
-rw-r--r--  1 root http 1253 Jan 31 10:04 asoundrc

I added a delay in the service file ExecStartPost=/bin/sleep 2
and now I get the /run/bluealsa-monitor set as I think it needs to be and no errors showing with bluealsa-monitor:
# ls -al /run/bluealsa-monitor/
total 4
drwxr-xr-x  2 http http   60 Jan 31 10:12 .
drwxrwxrwx 29 root root  660 Jan 31 10:03 ..
-rw-r--r--  1 http http 1253 Jan 31 10:13 asoundrc

I attached my headphones and they show up in bluealsa-aplay -l but not in aplay -l.
I do get this in the journal but do not know if they mean anything substantial to this experiment:
Jan 31 10:27:53 rune64 bluetoothd[301]: src/profile.c:ext_connect() Headset Voice gateway failed connect to 70:BF:92:D8:82:84: Connection refused (111)
Jan 31 10:27:53 rune64 bluetoothd[301]: Endpoint registered: sender=:1.8 path=/org/bluez/hci0/A2DP/SBC/source/3
Jan 31 10:27:53 rune64 bluealsa[396]: /usr/bin/bluealsa: W: Unsupported AT message: SET: command:+CLIP, value:1
Jan 31 10:27:53 rune64 kernel: input: Jabra Evolve2 65 (AVRCP) as /devices/virtual/input/input1
Jan 31 10:27:54 rune64 systemd-logind[2479]: Watching system buttons on /dev/input/event1 (Jabra Evolve2 65 (AVRCP))

You are now running bluealsa-monitor as root - is that intentional? Previously you had User=http in the .service file. The script here has not been security-checked for running as root, so I have no idea what kind of risk you are running here.
Please can you confirm what user account you run bluealsa under, and also post the contents of /run/bluealsa-monitor/asoundrc when the headphones are connected; and also how have you set the environment variable ALSA_CONFIG_PATH - the user that runs aplay must have that set correctly in the environment. The example bluealsa-monitor-env.conffile given in the source is for use with user sessions, not system sessions.
One way to fix the environment for all users is to create the file /etc/environment.d/99-bluealsa-monitor.conf with the contents:
ALSA_CONFIG_PATH=/usr/share/alsa/alsa.conf:/run/bluealsa-monitor/asoundrc

I have not set ALSA_CONFIG_PATH anywhere that I am aware of.
Running as I noted above, the contents of the asoundrc under /run/bluealsa-monitor are the basic config plus:
# cat /run/bluealsa-monitor/asoundrc
...
namehint.pcm.bluealsa70BF92D88284scoOutput "bluealsa:DEV=70:BF:92:D8:82:84,PROFILE=sco|Jabra Evolve2 65, HFP (CVSD)|IOIDOutput"
namehint.ctl.bluealsa70BF92D88284 "bluealsa:DEV=70:BF:92:D8:82:84|Jabra Evolve2 65 control device"
namehint.pcm.bluealsa70BF92D88284scoInput "bluealsa:DEV=70:BF:92:D8:82:84,PROFILE=sco|Jabra Evolve2 65, HFP (CVSD)|IOIDInput"
namehint.pcm.bluealsa70BF92D88284a2dpOutput "bluealsa:DEV=70:BF:92:D8:82:84,PROFILE=a2dp|Jabra Evolve2 65, A2DP (SBC)|IOIDOutput"

I set the user back to User=http for security concerns and restarted. I verified that the structure under /run is all still owned by http. I deleted the conf under /srv/http/.config created a /etc/environment.d directory then put in the suggested info in 99-bluealsa-monitor.conf
# cat /etc/environment.d/99-bluealsa-monitor.conf
ALSA_CONFIG_PATH=/usr/share/alsa/alsa.conf:/run/bluealsa-monitor/asoundrc

and restarted and now nothing useful appears in /run/bluealsa-monitor/asoundrc. For some reason, it must be running as root for the info to appear in /run/bluealsa-monitor/asoundrc. I still get nothing in aplay -l or aplay -L. When I change the *.service back to running bluealsa-monitor as root, the asoundrc populates, but I still get nothing in 'aplay -l'.

For some reason, it must be running as root for the info to appear

Ok that's something to do with systemd. More reading required. My suspicion is that the RuntimeDirectory= setting is being applied as user http, so is failing. There must be some way to fix that, but I don't know what it is yet.

I still get nothing in 'aplay -l'

Please can you report the result of
echo $ALSA_CONFIG_PATH

from the terminal in which you are running aplay -l
You may need to reboot to get the new environment applied to user sessions.

I've just run a test on my system.
/usr/local/lib/bluealsa-monitor.service
[Unit]
Description=Bluealsa PCM manager
Documentation=https://github.com/borine/bluealsa-monitor

[Service]
Type=simple
User=http
Group=http
RuntimeDirectory=bluealsa-monitor
RuntimeDirectoryMode=0755
Environment="XDG_RUNTIME_DIR=/run"
ExecStart=/usr/bin/bluealsa-monitor

[Install]
WantedBy=default.target

$ groups http
http: http audio

/etc/environment.d/99-bluealsa-monitor.conf
ALSA_CONFIG_PATH=/usr/share/alsa/alsa.conf:/run/bluealsa-monitor/asoundrc

*** reboot *** to force the revised global environment setting
sudo systemctl start bluealsa-monitor.service

$ ls -l /run/bluealsa-monitor
-rw-r--r-- 1 http http 1245 Jan 31 18:38 asoundrc

*** connect bluetooth speaker ***
$ cat /run/bluealsa-monitor/asoundrc
# DO NOT EDIT - automatically managed by bluealsa-monitor service
bluealsa.default.capture.pcm {
type asym
capture.pcm "pcm.bluealsa:PROFILE=a2dp"
playback.pcm {
@func refer
name "bluealsa.default.playback.fallback"
default sysdefault
}
hint.show on
hint.description "Capture: Bluetooth default, Playback: sysdefault"
}
bluealsa.default.playback.pcm {
type asym
capture.pcm {
@func refer
name "bluealsa.default.capture.fallback"
default sysdefault
}
playback.pcm "pcm.bluealsa:PROFILE=a2dp"
hint.show on
hint.description "Capture: sysdefault, Playback: Bluetooth default"
}
bluealsa.default.duplex.pcm {
type empty
slave.pcm "pcm.bluealsa:PROFILE=a2dp"
hint.show on
hint.description "Bluetooth default"
}
namehint.ctl.bluealsa "bluealsa|DESCBlueALSA global control device"

namehint.pcm.bluealsa5CF3709BFB1AscoOutput "bluealsa:DEV=5C:F3:70:9B:FB:1A,PROFILE=sco|DESCmusicroom, HFP (CVSD)|IOIDOutput"
namehint.ctl.bluealsa5CF3709BFB1A "bluealsa:DEV=5C:F3:70:9B:FB:1A|DESCmusicroom control device"
namehint.pcm.bluealsa5CF3709BFB1AscoInput "bluealsa:DEV=5C:F3:70:9B:FB:1A,PROFILE=sco|DESCmusicroom, HFP (CVSD)|IOIDInput"
namehint.pcm.bluealsa5CF3709BFB1Aa2dpOutput "bluealsa:DEV=5C:F3:70:9B:FB:1A,PROFILE=a2dp|DESCmusicroom, A2DP (SBC)|IOIDOutput"

$ echo $ALSA_CONFIG_PATH
/usr/share/alsa/alsa.conf:/run/bluealsa-monitor/asoundrc
$ aplay -L
surround21
    2.1 Surround output to Front and Subwoofer speakers
surround40
    4.0 Surround output to Front and Rear speakers
surround41
    4.1 Surround output to Front, Rear and Subwoofer speakers
surround50
    5.0 Surround output to Front, Center and Rear speakers
surround51
    5.1 Surround output to Front, Center, Rear and Subwoofer speakers
surround71
    7.1 Surround output to Front, Center, Side, Rear and Woofer speakers
default
    Default Audio Device
usbstream:CARD=PCH
    HDA Intel PCH
    USB Stream Output
bluealsa:DEV=5C:F3:70:9B:FB:1A,PROFILE=sco
    musicroom, HFP (CVSD)
bluealsa:DEV=5C:F3:70:9B:FB:1A,PROFILE=a2dp
    musicroom, A2DP (SBC)

So, everything "just works". !!!

 I am really close, but my ALSA_CONFIG_PATH is not set. I am running arch linux and it is supposed to be set by the /etc/environment.d/99-bluealsa-monitor.conf, but when I check it is not (as http or as root):
$ echo $ALSA_CONFIG_PATH

If I set it in /etc/environment instead of environment.d/99-bluealsa-monitor.conf, it does seem to set it:
# cat /etc/environment
#
# This file is parsed by pam_env module
#
# Syntax: simple "KEY=VAL" pairs on separate lines
#
ALSA_CONFIG_PATH=/usr/share/alsa/alsa.conf:/run/bluealsa-monitor/asoundrc

and reboot it shows (as either http or root):
$ echo $ALSA_CONFIG_PATH
/usr/share/alsa/alsa.conf:/run/bluealsa-monitor/asoundrc

If I then reboot and reconnect my speaker, I can 'see' it as root:
# bluealsa-aplay -l
**** List of PLAYBACK Bluetooth Devices ****
hci0: 70:BF:92:D8:82:84 [Jabra Evolve2 65], audio-headset
  A2DP (SBC): S16_LE 2 channels 48000 Hz
  SCO (CVSD): S16_LE 1 channel 8000 Hz
**** List of CAPTURE Bluetooth Devices ****
hci0: 70:BF:92:D8:82:84 [Jabra Evolve2 65], audio-headset
  SCO (CVSD): S16_LE 1 channel 8000 Hz

but as user http, it gives an error:
$ bluealsa-aplay -l
**** List of PLAYBACK Bluetooth Devices ****
bluealsa-aplay: W: Couldn't get BlueZ device properties: Rejected send message, 3 matched rules; type="method_call", sender=":1.168" (uid=33 pid=2860 comm="bluealsa-aplay -l ") interface="org.freedesktop.DBus.Properties" member="GetAll" error name="(unset)" requested_reply="0" destination="org.bluez" (uid=0 pid=301 comm="/usr/lib/bluetooth/bluetoothd ")
: 70:BF:92:D8:82:84 [],
  A2DP (SBC): S16_LE 2 channels 48000 Hz
  SCO (CVSD): S16_LE 1 channel 8000 Hz
**** List of CAPTURE Bluetooth Devices ****
bluealsa-aplay: W: Couldn't get BlueZ device properties: Rejected send message, 3 matched rules; type="method_call", sender=":1.168" (uid=33 pid=2860 comm="bluealsa-aplay -l ") interface="org.freedesktop.DBus.Properties" member="GetAll" error name="(unset)" requested_reply="0" destination="org.bluez" (uid=0 pid=301 comm="/usr/lib/bluetooth/bluetoothd ")
: 70:BF:92:D8:82:84 [],
  SCO (CVSD): S16_LE 1 channel 8000 Hz

and the /run/bluealsa-monitor/asoundrc shows nothing added.
It feels really close...

Rejected send message, ... destination="org.bluez" ...

So user http is not allowed to send messages to org.bluez. Surprisingly, this is the first time I have realized that in a default install bluealsa-aplay -L only works for users who are members of the bluetooth group; perhaps that needs to be mentioned in the BlueALSA docs.
A quick fix would be to create a new d-bus config file:
/etc/dbus-1/system-local.conf
<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>

  <policy user="http">
    <allow send_destination="org.bluez"/>
  </policy>

</busconfig>

Tell dbus to read the new config:
$ sudo systemctl reload dbus

(or reboot if that does not work)
Beware that user http can then administer bluetooth to some extent (eg run programs like bluetoothctl) which needs careful thought, and most likely would not be allowed by a responsible distribution manager.

Thad does it, at least I think so. I added that system-local.conf to the folder /etc/dbus-1/systemd/ because that is where the other *.conf files are. Is that OK or should it be the one directpry up?  When I did that and connected my headphones, they show up:
# aplay -L
null
    Discard all samples (playback) or generate zero samples (capture)
(SNIP)...
bluealsa:DEV=70:BF:92:D8:82:84,PROFILE=sco
    Jabra Evolve2 65, HFP (CVSD)
bluealsa:DEV=70:BF:92:D8:82:84,PROFILE=a2dp
    Jabra Evolve2 65, A2DP (SBC)

They do not show up with aplay -l, though. Are they supposed to? Can I make them show up there? I ask this as out script that enables the outputs for the various players all parse aplay -l for the outputs.

They do not show up with aplay -l

Correct. aplay -l lists only hardware sound cards. There is no way to get software devices such as bluealsa, jack, pipewire, pulse etc to be listed by that command.

well, with that, I think it is done. Thanks for the help. IMO, this should be bundled with bluealsa as it is a huge help. I will plug a but with the udev integration as we need to trigger a refresh anyway on our install, but this gives us most of the information we need.


BUG: Change different fonts and remove hover effect

Is there an existing issue raised for this?

[X] I have searched the existing issues

What happened?
Hey, the below section hover effect is not looking good. I want to remove it. You can see below

Also, there is a different type of font used that does not match with other fonts.

Add ScreenShots
Please assign this issue to me.
What browser are you seeing the problem on?
No response
Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSOC'23 contributor
[X] I want to work on this issue

Heyy,,Id like to work on this. Give it to me


feat: support custom config property name in package.json

PR Details
This PR supports changing the property name used to read config from package.json
Description

Related Issue

Motivation and Context
It makes no sense to only support custom config file name and not a custom package.json custom config property name
How Has This Been Tested

added unit tests to verify toolkit/load-config correctly loads custom config in package.json and not the default modernConfig
Types of changes

[ ] Docs change / refactoring / dependency upgrade
[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

[x] My code follows the code style of this project.
[x] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[x] I have added tests to cover my changes.
[x] All new and existing tests passed.

加一下 changeset

done


Add an option to save only selected part of query results to csv in context menu

Is your feature request related to a problem? Please describe.
Add an option to save only selected part of query results to CSV in context menu.
If possible please, also include if results should contain headers or not.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Example Screenshot

Done in v0.22. You can select the rows you want and save or open editor with those rows


Impossible condition - task10

Hi, guys!
Amazing lab, thank you!
I have question about task 10, file Jenkinsfile, line 14. This condition ought to be true to merge my pull request in the main branch. But this condition can't be true because $(wc -l <version) always return 1 (1 string in the file) and it's can't be equal to 0.
Thank you in advance.

Hi @v3nd1g0, welcome and great to see you like to lab!
This shouldn't be a mistake, and it works for me. Have you tried running this command on this file and see what it returns?
Also, have you tried following the hints or solution and see if it works for you?

Hi @omer-cider. Thank you for your reply.
I have tested this expression in zshrc in such conditions:

empty version file

$ > ./version
$ if [ $(wc -l <version) -eq 0 -a $(grep -Po "^\\d{1,2}\\.\\d{1,2}\\.\\d{1,2}$" version) ] ; then check2=true; else check2=false; fi && echo $check2
false

version file with 1.0.13 (grep pattern ok)

$ echo "1.0.13" > ./version
$ if [ $(wc -l <version) -eq 0 -a $(grep -Po "^\\d{1,2}\\.\\d{1,2}\\.\\d{1,2}$" version) ] ; then check2=true; else check2=false; fi && echo $check2
false

version file with 100.1000.1000 (grep pattern no ok)

$ echo "1.100.100" > ./version
$ if [ $(wc -l <version) -eq 0 -a $(grep -Po "^\\d{1,2}\\.\\d{1,2}\\.\\d{1,2}$" version) ] ; then check2=true; else check2=false; fi && echo $check2
false

In each case I have reached check2 == false.
What am I missing?
Thank you in advance.
P.S. I have checked writeup, but it doesn't work for me :c

Hi @omer-cider. Thank you for your reply.
I have tested this expression in zshrc in such conditions:

empty version file

$ > ./version
$ if [ $(wc -l <version) -eq 0 -a $(grep -Po "^\\d{1,2}\\.\\d{1,2}\\.\\d{1,2}$" version) ] ; then check2=true; else check2=false; fi && echo $check2
false

version file with 1.0.13 (grep pattern ok)

$ echo "1.0.13" > ./version
$ if [ $(wc -l <version) -eq 0 -a $(grep -Po "^\\d{1,2}\\.\\d{1,2}\\.\\d{1,2}$" version) ] ; then check2=true; else check2=false; fi && echo $check2
false

version file with 100.1000.1000 (grep pattern no ok)

$ echo "1.100.100" > ./version
$ if [ $(wc -l <version) -eq 0 -a $(grep -Po "^\\d{1,2}\\.\\d{1,2}\\.\\d{1,2}$" version) ] ; then check2=true; else check2=false; fi && echo $check2
false

In each case I have reached check2 == false.
What am I missing?
Thank you in advance.
P.S. I have checked writeup, but it doesn't work for me :c

Hi @v3nd1g0, wc -l <version counts the number of newlines. If you'll make sure to remote any \ns from the version file, the command will return true.

Thank you, you are right!


Feature Request: Check pkgrepo state deprecation

Preface
Kindly use the check for state.cmd deprecation as an example of adding a check. #37 has to be merged first.
Description
Add the possibility to check for deprecation within the pkgrepo state
The following options have been deprecated:

refresh_db

The following options should be used:

refresh

Example(s) of an improperly configured state:
foo:
  pkgrepo.managed:
    - humanname: Personal repo for foo
    - baseurl: https://mydomain.tld/repo/foo/$releasever/$basearch
    - gpgkey: file:///etc/pki/rpm-gpg/foo-signing-key
    - gpgcheck: 1
    - refresh_db: True

Example(s) of properly configured state:
foo:
  pkgrepo.managed:
    - humanname: Personal repo for foo
    - baseurl: https://mydomain.tld/repo/foo/$releasever/$basearch
    - gpgkey: file:///etc/pki/rpm-gpg/foo-signing-key
    - gpgcheck: 1
    - refresh: True

It has been deprecated since version 2018.3.0
Fix requirements
A fix for this issue should (at least):

Notify the user of using a deprecated option
Notify the user since what version the option will be or has been deprecated
A suggestion on what option to replace it with
Contain unit tests for the check

@jbouter @roaldnefs I really like the idea of all of these deprecation checks that have been proposed.  I'd just like to share an angle from a SaltStack Formulas perspective.  We've had detailed discussions about how to handle deprecations and Salt versions that we have to support.  Our eventual conclusion was that we would keep in sync with upstream Salt's support cycle.  At first, we started from this page:

https://www.saltstack.com/product-support-lifecycle/

In discussions with the Salt team, we were able to refine that into a simpler rubric: the latest three versions of Salt are supported at any given time.  So until the next major release, that's:

2017.7
2018.3
2019.2

You'll see that's what we've been using for all of our Kitchen/InSpec-based testing via. Travis (in the formulas that have been converted).  We also test against develop, to be ready for the next release in advance.
So how does this all apply here to this discussion?  We've found that we have to support deprecated options while a given version of Salt is still supported.  I believe salt-lint should consider doing the same.  I'm not saying that these rules shouldn't be implemented; they'll be an excellent addition to this tool.  Rather, my suggestion is to allow setting the range of Salt versions to be supported in the .salt-lint file.  Then automatically test rules based on whether the rule is "deprecated" based on the user's circumstances or not.  So that would mean tracking the minimum and maximum Salt versions for each rule and then comparing that when it's time to test for it.  Essentially, this can be done automatically, rather than placing the burden of enabling/disabling rules on the end-user, depending on what versions of Salt they have to support, in a given infrastructure setting.

Thanks for your feedback @myii! We should indeed not throw errors (or when used inside a CI-pipeline, fail) for functionality that'll be deprecated in the future (from the standpoint of the oldest supported release). I would suggest, however, to still check for these to-be-deprecated features and throw a warning (not affecting the exit code of salt-lint) much like the warnings within the SaltStack documentation is shown.
It would be nice indeed to have a minimal and maximum version configurable to be checked against in the .salt-lint configuration file. Regardless of SaltStack support, linux distributions may have their own support cycle that we should take into account (for example, Ubuntu 18.04 will have support till 2023, and contains version 2017.7.

Closed in favour of #204


call other ONNX models  error

I am trying to use the common.onnx and commondex.onnx models from the https://github.com/sml2h3/ddddocr repository for text detection and recognition tasks. However, I am encountering an error that says code[2]: NULL input supplied for input input1. I have tried calling them following the example of fastcnn, but I still get the same error. Could you please help me identify where the problem might be?

Happy to help, i might need some further context on how do you use the model, i had a quick look at the python source but i wish I know mandarin to get some context, sharing your pascal code snippet that you are facing this issue with would help, however in short you 1st need to explore the models inputs and output shapes so you can construct the right shape of the tensors to feed the model with , the input NULL message can be caused by too many possibilities here could be a small fix


Fancy Zones cannot reach the top of the monitor

Microsoft PowerToys version
0.37.2
Running as admin

[X] Yes

Area(s) with issue?
FancyZones
Steps to reproduce
For the last few of versions (at least half a year, maybe more),
When edit the zones I can't drag a zone to the top of the monitor, there is a lane of about the height of the task bar at the top of the screen that blocks me from placing the zones there.
The other sides work well.
I am on a large screen (42'' @ 4k)

✔ Expected Behavior
The zones should (and did before) allow themselves to be positioned across the whole screen
❌ Actual Behavior
The zones cannot be positioned within a certain margin from the top of the screen
Other Software
No response

where is your taskbar positioned?

@SeraphimaZ in .39/.41 did we resolve an issue like this

At the bottom.
Thanks
Simon Kolotov
On Tue, Jun 15, 2021, 22:14 Clint Rutkas @.***> wrote:

where is your taskbar positioned?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/PowerToys/issues/11758#issuecomment-861764483,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABDD4JPJ5NDOSVBLDUWSGCDTS6RAJANCNFSM46WTINBQ
.

@crutkas no, there weren't similar issues with editing canvas zones in the editor.

@simonkolotov could you please provide more information?
Can the zone reach the top when the taskbar is hidden or when the taskbar is on the left/right side? Which scaling is set on your monitor?
Also, it would be great if you attach here a bug report. You can generate it by right-click on the PowerToys tray icon and then Report Bug.

Hi.
Thank you for looking into this.
The bug report is attached.
I also looked deeper into the dependency on the taskbar location, and it
looks like your hunch is correct: When I change the taskbar position, the
limits of the zones placement change.
Moreover, it seems that the bug is somewhere in the calculation of those
limits: When the taskbar is at the bottom, the zones can't reach the top,
but can overlap the taskbar by about half of its height, see screenshot 1:
[image: image1 (Small).png]
When the taskbar is at the top, the zones can almost reach the bottom, an
can reach about a third of the way into the taskbar, see screenshot 2 below:
[image: image2 (Small).png]
When the taskbar is on the right side, the windows can reach about 2/3 into
the taskbar, and a symmetrical distance on the left side (i.e. can't reach
the left edge of the screen at all), see screenshot 3:
[image: image3 (Small).png]
Interestingly enough, when the taskbar is on the left, the zones can
practically reach the edges of the screen on all sides (!!).
It also looks like those limits are calculated when clicking the "Launch
layout editor" button, and if I change the taskbar position after opening
the editor, the limits do not change.
Additionally, when I created the zones with the taskbar on the left, and
then tried to apply the zones with the taskbar at the bottom, the zone
positions changes, such that all the zones extend well beyond the limits of
the monitor, both to the right and to the bottom (by a much larger margin
than the width and height of the taskbar in its various positions).
To summarize, the bug is somewhere in calculating the limits for the zone
placements when launching the zone editor, and also in applying the zones
when the taskbar position is not where it was when the zones were
edited/created.
Thanks a lot,
Simon
Simon Kolotov
On Tue, Jun 15, 2021 at 11:38 PM Seraphima Zykova @.***>
wrote:

@simonkolotov https://github.com/simonkolotov could you please provide
more information?
Can the zone reach the top when the taskbar is hidden or when the taskbar
is on the left/right side? Which scaling is set on your monitor?
Also, it would be great if you attach here a bug report. You can generate
it by right-click on the PowerToys tray icon and then Report Bug.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/PowerToys/issues/11758#issuecomment-861814807,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABDD4JI7GVON7FWWQD3D4TTTS622ZANCNFSM46WTINBQ
.

@simonkolotov The attachment won't send by email. Please drag-and-drop it to the github.com's comment area to upload it.

My apologies for the late reply and thank you for looking into this.
Please see above in the comments the description of the issue - the gist is that there is an error in placing the zones, where they cannot reach or overreach the area defined by the taskbar.
A detailed description is above, the missing images (could not be uploaded through the mail) are attached here.
Kind regards,
Simon

@simonkolotov

can you do a "report bug" and drag the zip in the text field?

2, Are you on a newer version, like 0.49.1?
Assuming 0.49.1 still has the quirk else you would have said this was no longer an issue, correct?

Hi all.
I just rechecked it in version 0.49.1, and most of the issues described
here have been resolved.
Moreover the general process has been made much smoother - great work and
thank you everyone.
I did find that a small portion of the buggy behaviour above still persists
in 0.49.1, namely having the taskbar in the right location (to the right of
the screen) makes it overlay the zones.
To be fully honest, I never use the taskbar anywhere but at the bottom, so
this does not affect me at all, I am only mentioning this for fullness.
So as far as I can tell, this issue can be closed as resolved in 0.49.1.
Regarding the portion that is still left, I opened a new issue (I was
confused with your request to "Report a bug" and accidentally created a new
issue on github), and the small change that is left can be resolved there:
https://github.com/microsoft/PowerToys/issues/14413
I apologize if I created extra work for you, but it does seem to me like
this is a separate issue, and the one this bug started with is actually
already resolved (the original issue was about zones not being able to
reach the edge of the screen - an issue that is gone now).
Once again thank you all for the great work that you do!
Best,
Simon Kolotov
On Tue, Nov 9, 2021 at 11:24 PM Clint Rutkas @.***>
wrote:

@simonkolotov https://github.com/simonkolotov

can you do a "report bug" and drag the zip in the text field?
[image: image]
https://user-images.githubusercontent.com/1462282/141007050-6522b8b9-9356-4108-8aa0-655663166aa0.png
2, Are you on a newer version, like 0.49.1?
Assuming 0.49.1 still has the quirk else you would have said this
was no longer an issue, correct?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/PowerToys/issues/11758#issuecomment-964560974,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABDD4JI6IKC4BHB2WTCA2RLULGGRFANCNFSM46WTINBQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

So as far as I can tell, this issue can be closed as resolved in 0.49.1.
Closing as resolved. Feel free to open a new issue or reopen this if the issue persists. :D

Hi, I am having the same issue. I have dual monitor set up and it cannot go up and down all the way.


[SIP-38] Visualization plugin refactoring

[SIP-38] Visualization plugin refactoring
Motivation
One of the most commonly reoccurring questions in the Superset community, on Slack and elsewhere, is that of how to add a new data visualization. The answer, in short, has been “it’s hard.” While that may be true, the goal of this SIP is to lay out both tactical refactor needs for the current implementation to mature, as well as proposing a handful of roadmap features to make plugin development significantly easier. These changes will make upcoming modifications of existing plugins (see SIP-34) drastically simpler, and steer toward opening an ecosystem of Superset visualization plugins.
Much planning and work has already been done to address the difficulty of adding/editing plugins, including a new query API endpoint, but there are many blocking issues and code migrations remaining to complete this process. Special thanks to @kristw, @williaster, @xtinec, and @conglei for their significant contributions to the frontend and API work thus far. These issues, and proposed solutions for them, are enumerated below. Additional suggestions are welcome.
Proposed Changes
General Goals:

As much code and configuration as possible for individual visualization plugins should be moved out of incubator-superset and into the individual plugin’s repos (in a perfect world, a new plugin wouldn’t require touching two repos and opening two PRs).
Reduce frustration in working on plugin repos, allowing people to more easily see changes as they make them

Issue:
Control panel configurations for visualizations are centralized in a difficult to maintain controls.jsx file. All controls are located in incubator-superset , necessitating writing code in two PRs for two repos.

Proposal:
Control configurations (particularly the ones that are unique to any given plugin) should be migrated into the correct individual control panel config files . An example of this can be found in This PR. These individual configs should then be migrated to the individual plugins, and references removed from setupPlugins.ts.

Issue:
Plugins (particularly when using the legacy api (/explore_json) require an entry in viz.py.  In addition to requiring code changes to two repos, the logic in viz.py has proven to be fragile and cumbersome to maintain.

Proposal:
Use of viz.py should be deprecated in favor of the viz-agnostic api/v1/query endpoint. In an effort to decouple this, viz.py logic (data transformations) should be broken out into individual modules and/or reusable methods, which should be invoked by the new endpoint. This will additionally require that controls should be consolidated wherever possible, e.g. use a single control for metric, metrics, metric_2, secondary_metric, etc.

Issue:
New and existing plugins cannot yet fully utilize the new api/v1/queryendpoint due to the following issues:

Superset does not yet respect a plugin’s useLegacy flag to call the correct endpoint when required
The API has no means to accept data transformation options needed for post-processing (e.g. Pandas) to reach feature parity with the legacy API.
The API does not have unit tests
The API is not documented

Proposal:

Modify exploreUtils.js such that the getURIDirectory method calls the right endpoint depending on the useLegacy flag
Add configuration options to the API call to invoke backend post-processing operations, returning transformed data
Write unit tests and documentation
Deprecating the explore_json endpoint

Issue:
Each plugin must be registered manually in incubator-superset’s MainPreset.js file. Additionally, customizing the plugins loaded for a deployment (i.e. disabling some) is done via setupPluginsExtra.js, meaning the plugins are still loaded as dependencies. And this method only supports plugins removal, but does not let you add new plugins that are not listed in package.json from master.

Proposal:
Attempting to load plugins via ES2020’s dynamic imports. The exact implementation of this is a bit TBD, but the idea would be to move the responsibility for registering/loading plugins away from MainPreset.js. Instead, the plugin paths/packages (and their associated keys) could be bootstrapped as an overridable configuration file, and Superset could lazy-load the plugins accordingly. (note: dynamic imports are not supported natively by IE, but Babel provides potential recourse for that).

Issue:
Development work on plugins requires manually running a npm link operation to load the local plugin, and thus see updates/edits in Superset - this is troublesome in that it is both fragile, and difficult for many developers to discover, as it’s not a common pattern).

Proposal:
Automate the process! Create a “plugin dev mode” NPM script that automatically links (or unlinks) viz plugin packages. See a working example of this concept in this PR. This would involve refactoring the NVD3 plugins to not rely on /lib path, preset-chart-xy to not rely on /esm path - all plugins should follow the same build and source directory pattern.

Additional (follow-up) refactoring tasks

Follow CSS-in-JS patterns (see SIP-37) in viz components, sharing common theme styles/variables with incubator-superset. Theme variables may need to be moved to superset-ui to be consumed by both superset-ui-plugins and incubator-superset.
Audit and address issues with, and completeness of, i18n of plugin text.
Converting all viz components to TypeScript (see SIP-36)

New or Changed Public Interfaces
The query endpoint at /api/v1/query needs significant enhancement, as laid out in the proposals above (post-processing options, tests, docs).
New dependencies
N/A
Migration Plan and Compatibility
N/A
Rejected Alternatives

Reintroducing viz plugins into incubator-superset
Having the plugins be in their own repos is troublesome from a workflow perspective (due to the multiple PRs required, NPM Link work needed, and separate build processes required). The proposals laid out above seek to minimize this difficulty. While it is certainly possible (and indeed likely easier) to move the plugins back into Superset itself (like Redash and Metabase do), solving these more difficult problems seems more likely to open the door to a true plugin ecosystem for Superset.
Moving data transformations to plugins (JS), deprecating Pandas
The idea has been floated that perhaps data transformation (at least in some cases) might be more the responsibility of the viz plugin itself than the backend, and maybe if we moved that logic, we could deprecate Pandas. To test the theory, some basic benchmarking attempts were made on large rollup and pivot tasks, to compare the performance of Pandas against Zebras, Datalib, Ramda, and Lodash. This approach, at least as a global migration, was decided against for these reasons:

Sending an entire dataset over the wire, if the frontend just needs a rollup, is a waste of resources
If post-processing is done on the backend, the result can be cached for use by multiple charts (or multiple clients and reloads)
Neither Zebras nor Datalib provides an out-of-the-box pivot function on par with Pandas, and the pivotWith "recipe" from the Ramda cookbook looked to be significantly slower than Pandas (approx 10x).
All these libraries provide grouping, sorting, map/reduce functionality, so you can pivot the data manually. But then, so does Lodash, which matched (or slightly beat) the other JS libraries' performance. This was still about 2x slower than Pandas.
TL;DR: If you want to avoid writing Python for a new viz or calling it through the new API, and want to do a little data munging on the frontend, just use lodash or vanilla JS for best results.

Looks like a solid plan, thanks for writing this up. A few questions (for you or the community):

What was the original rationale in moving plugins out into their own repo(s)?
How are you thinking about exposing Pandas data transformation functionality to the plugins via the /api/v1/query endpoint. Will there be a whitelisted set of transformation methods that can be called? Will it support chaining these transformations?
Should we rename the /api/v1/query endpoint to something less ambiguous?
For i18n, I realize this is bigger issue than just visualizations, but have you looked into libraries like globalize or other CLDR-based solutions?
Will migration to the new plugin architecture simply be handled by the useLegacy frontend flag? What should the deprecation plan for the old architecture/endpoints be?

What was the original rationale in moving plugins out into their own
repo(s)?

The collection of visualizations in Superset had grown organically over
time, with varying quality and lack of ownership for some charts. All
charts were shipped with every release of Superset. There was no easy way
to get rid of them.

The chart code with no owner (after the PR was merged and the chart
author abandoned them) became dead code that nobody owns in the main repo,
and the list kept growing. Maintaining the "visualizations" folder at that
time was a monumental tasks.
Developers have custom needs and keep asking to add more types of charts.
Some are very specific and debatable whether that is useful for anyone
else.
Very difficult to test the charts.

Breaking them into independent packages and lighter weight repositories
allow

more stable incubator-superset and less code to maintain. If a chart
will only be used by single organization, then the entire community should
not have to maintain it.
chances to deprecate uncommon charts by dropping the plugin from the main
bundle, but still make them available as packages for developers to install
them into their own deployment.
enforced decoupling. remove hacks for special handlings of certain charts.
less arguments about adding certain charts or not.
visual inspection of every PR with storybook and easier maintenance.
developer productivity: reduced ci build time, smaller codebase, able to
apply more strict linting rules.

More from https://github.com/apache/incubator-superset/issues/5680
One key part of the embeddable project is to move towards *chart plugins

system*, which we can register only necessary charts for superset or
register custom ones as wish. This will give more flexibility to the
developers to customize their superset instances (making it more
lightweight, include-only-needed, or include custom vis type) as well as
improve maintainability of the superset codebase (instead of hosting every
visualization in the main repo).
In order to do that, we aim to split the chart types (i.e. most of the
things in src/visualizations) into one or more plugins (npm packages),
independent from superset. Then, we will implement a registry mechanism for
importing plugins.

-Krist

Thanks for the writeup, @rusackas . This raises a lot of great points and cleared many doubts for me.
Just to be clear, what I had in mind when commenting #8638 was to temporarily move plugins and their registries back to incubator-superset until things are more settled---plugin API matured, core plugin quality under control, and the big UI overhaul proposed in SIP-34 finally starts to taking shape...
It might take a lot of back and forth to get there and having to sync code between multiple repos slows the whole process down. Even if we can solve the linking issue with a custom npm command, people still need to make (and review) two (maybe three) PRs whenever the registry or control panel API needs to change. Overall, the overhead the 3-repo structure imposes right now seems far overweight the potential benefits it may bring in the future.
In general, I do agree it makes a lot of sense to have optional visualizations as separate packages and in their own repo. Future Superset admins may even install a plugin from the web UI so it's only natural to do so. But for core visualizations, I'm not so sure. Superset as a software needs to ship with some visualizations anyway and having the source code in one place makes it easier for new developers to start writing their own plugins---and for existing contributors to upgrade.
A true plugin ecosystem is achievable even with the frontend registry code and backend API placed in the same repo.

@kristw , to mitigate some of the concerns raised during the initial separation of repos, maybe we can take following actions (if we haven't):

Officially freeze the visualization folder, no PRs will be accepted or reviewed until we clean things up and plugin API stabilized
Require all new visualizations to have unit test that do not depend on Superset backend API
Place additional more strict .eslintrc to the folders of migrated components.

Another alternative is to have a frontend monorepo within incubator-superset, publishing superset-ui and "official" plugins as separate packages but track then under the same git repo as the backend code. This way embedadable Superset charts is also still possible.

@rusackas I have re-read this item again and it is still not quite clear how the proposal (dynamic import) will address the issue.

In particular, how will dynamic import help with adding new plugins that are not listed in package.json from master.

bootstrapped as an overridable configuration file, and Superset could lazy-load the plugins accordingly.

Generating MainPreset.js from the configuration file could be another solution as well.
For clarification, if the bundle size is concerned, Superset is already lazy-loading the plugins.

@kristw Thanks for your thoughts on this

Generating MainPreset.js from the configuration file could be another solution as well.
This is essentially what I'm trying to take a step toward. My understanding is that to do that, you'd have to load in an array of plugins/paths from the config (or some state driven by a future UI, even), and then you could then dynamically load those packages and/or paths. This is what that other WiP PR is taking a stab at.
For clarification, if the bundle size is concerned, Superset is already lazy-loading the plugins via dynamic imports.
Bundle size isn't the main concern here, so much as developer convenience.
how will dynamic import help with adding new plugins that are not listed in package.json from master?
My thought (though admittedly half baked, since we're not at this stage yet) would be that people could have any number of plugins added to their local/deployed filesystem, and dynamic loading would let them add the point to the module or just the file path of that plugin, once loaded from the aforementioned config/state. That would all be done dynamically in MainPreset.

Generating MainPreset.js from the configuration file could be another solution as well.
This is essentially what I'm trying to take a step toward. My understanding is that to do that, you'd have to load in an array of plugins/paths from the config (or some state driven by a future UI, even), and then you could then dynamically load those packages and/or paths. This is what that other WiP PR is taking a stab at.

What do you think if the MainPreset.js generation happen as part of webpack build or some build script, so the app remains unaffected and can treat MainPreset.js as a regular file?

What do you think if the MainPreset.js generation happen as part of webpack build or some build script, so the app remains unaffected and can treat MainPreset.js as a regular file?

I think this is well worth a Spike, and feel like you or @ktmud are probably well qualified to advise on the webpack aspects of it in particular when we get to it.

I love this, specially the part about consolidating the data model in api/v1/query so that we don't have metric vs metrics. Having a common data model for the different plugins will make it much easier to switch visualizations without losing context, which is very powerful feature IMHO.

I think dynamically generating a JS file might not be very practical if we want users (Sueprset admins) to manage plugins in a future UI. I'd imagine all plugins are loaded dynamically by just checking whether a file exists in some folder. There shouldn't be the need to pre-register a chart type. You just load it as you need it based on plugin names.

Lots of work has been done and summarized / documented here:
https://preset.io/blog/2020-07-02-hello-world/


svg namespace, fix Python syntax, allow use without Git

Fixed three issues:
The XML namespace for SVG is actually http://www.w3.org/2000/svg and not https://... (ref on W3C)
The syntax dollar is -1 is invalid since Python 3.8 for literals.
Fixed  #37

Do you plan to merge this? @leegao


Ability to deploy IDL to local validator

Devs want to be able to deploy an IDL to a local validator, so they can do IDL-based testing - especially for client-side and web-based code - from their local development suite

Ooooof how lol

There seems to be a bug with the anchor-cli because I'm able to use IDLs in localnet using playground.

But you are also using the CLI, no?

They are not the same because playground CLIs are rewrites of the original CLIs and I test all of the commands while implementing them so a bug in the original CLI does not necessarily translate into the playground version.

this is possible already with the anchor-cli.
// deploy the program
$ anchor deploy --provider.cluster l

// initialize the idl account
$ anchor idl init --provider.cluster l -f ./target/idl/<program>.json <program_id>

// fetch the on-chain idl
$ anchor idl fetch --provider.cluster l -o idl.json <program_id>

I've just tried it and it seems to work fine. There is also no cluster specific IDL code so there is no reason why it wouldn't work specifically in localnet.

My experience was the IDL publish command just hung there, and other devs I spoke with (like 2) said that you couldn't deploy IDLs to localnet

Could you give steps on how to reproduce this problem?

I'm not able to reproduce it anymore. Strange. I ran into the issue a few times and someone mentioned you can't deploy IDLs to localnet.
I've got Anchor 0.27 CLI and it appears to work as expected.
Closing


[20.09] go_1_15: 1.15.8 -> 1.15.10

fixes CVE-2021-27918, CVE-2021-27919
(cherry picked from commit 6a99841c113d0d7baf3849087d2670f8f6bc4bed)
Motivation for this change
Things done

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

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 116353 run on x86_64-linux 1

29 packages built:

bat-extras.prettybat
bazel-buildtools
bazel-gazelle
bazel-kazel
bazel-remote
bazel-watcher
bazelisk
brig
brillo
brook
browserpass
browsh
cadvisor
captive-browser
cassowary
cayley
cri-o
cri-o-unwrapped
cri-tools
croc
crun
dapper
dapr-cli
dashing
datadog-agent
datadog-process-agent
drive
drone
drone-cli


Fix typo in get.md

Hi there! I was just reading this page and noticed an extra letter in the record word - not a big deal but I know this would bug me if I was writing these docs!

Relevant URLs

https://docs.influxdata.com/flux/v0.x/stdlib/experimental/record/get/

!signed-cla


Changed login and login style

When I synched with the develop it messed with my original and I had to redo it.
The styling is not yet done but this should do for now.
Also, I can't run the whole thing through node.js.
What do I need to do to test our website?

Yusuke, I've actually made quite a few changes to all of the files on the current version - if you don't mind, can you add your changes AFTER my pull request? It would be a lot easier. Thanks!


1.0 Launch todos

We're thinking what is required before we launch 1.0, and are putting all todos in this page.
Are we missing anything? Please feel free to add.
Before 1.0 Launch

[x] tusd: Switch to X-HTTP-Method-Override (@acconut)
[x] tus-java-client: Switch to X-HTTP-Method-Override (@acconut)
[x] protocol: Go over each issue in https://github.com/tus/tus-resumable-upload-protocol/issues, and either close it, or label it 2.0 (@acconut)
[x] blog: Finish technical launch post for tus.io blog (@kvz, @ajvanloon)
[x] meta: Seek interested news outlets who want coverage (@kvz)
[x] website: Add a smaller 'Who uses tus' section on the homepage with the bigger companies and offer people a direct PR link. (@kvz)
[x] tusd-infra: Use latest version of tusd and not precompiled one via `wget "$(curl -Ls -o /dev/null -w %{url_effective} https://github.com/tus/tusd/releases/latest | sed 's/tag/download/')/tusd_linux_amd64.tar.gz"`` (@kvz)
[ ] tus-java-client: Push to Maven Central (@acconut)
[x] website: Make sure the demo is functioning properly - @hedgerh had problems in chrome last week (@acconut)
[x] website: Go over website’s copy again and check for spelling errors, wording, and markdown violations (possibly automated) (@ajvanloon, @kvz)
[x] blog: Finish press release post for transloadit.com blog (@kvz, @ajvanloon)
[ ] meta: Discuss possibility of an early announcement by Vimeo (@vayam)

1.0 Launch!

[x] meta: Sync with news outlets (@kvz)
[x] tus: Merge 1.0 into master (@acconut)
[x] blog: Publish the launch posts on tus.io & transloadit.com (@kvz)
[x] meta: post on HackerNews, link to blog post (@kvz)
[x] blog: Update blogpost with HackerNews link for comments (@kvz)
[x] meta: Update Transloadit's & tus' twitter/linkedin/fb post on reddit/slashdot (@kvz)
[x] meta: Get email subscribers and mail them the blogpost & hacker news link for comments (with intercom?) (@acconut, @kvz)
[x] meta: Reach out to Peter Cooper, pointing to the blog post and a tweet to RT with his publications (@kvz)
[x] meta: Reach out to Olaf van Miltenburg from Tweakers.net, pointing to the blog post, the tech.eu post, the press release, and the earlier tweaker.net coverage (@kvz)
[x] meta: Email press release to all tech editors, pointing to the blog post (@kvz)

After 1.0 Launch

[ ] protocol: Finish Developer Guide
[ ] protocol: RAML spec
[ ] client: Implementation tester

Closing this as the 1.0 launch has happend long ago, even if some of the item on the lists haven't been done yet. Some people report that they were confused about tus' current status.


"GET /static/assets/dist/common.0.10.0.entry.js HTTP/1.1" 404 -

why "GET /static/assets/dist/common.0.10.0.entry.js HTTP/1.1" 404 - happend?

we started versioning the entry.js files restarting npm run dev should do the trick


Reduce duplicated code on visits components and reducer

There's currently a few sets of components and reducers to handle visits:

Short URL visits
Tag visits
Orphan visits
Non-orphan visits
Domain visits (TBD)

All of them have a relatively close handling, as the UI has only small variations.
Currently there's a couple of helper functions used to reduce code duplication, but there's still room for improvement.
Try to find a way to reduce duplicated code (specially on tests), without making it even more complex to understand.

As part of #7 and #9, there have been many refactors, so I'm closing this as completed


Make number button navigation optional

Is your feature request related to a problem? Please describe.
When I'm taking notes on a lecture and I forget to switch the active window and type a number, the video jumps to a completely random time.
Describe the solution you'd like
Make the number button navigation an option in the settings below the VoD.

Hey! A press on SHIFT+? will reveal some useful shortcuts for the watch page. As you can see in the image below, the video doesn't jump to a completely random time.
Regarding the customisability of this feature, I unfortunately have to admit that we are not response for the misuse of window managers.


Test against both openssl 1.1.1 & 3

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.


How to use the new hardening features

I am not seeing how to use the new hardening features when including snmalloc as a header-only library on Windows. There doesn't seem to be any #define or similar mentioned in the documentation? Is it just enabled by default?

It is enabled with
SNMALLOC_CHECK_CLIENT

I will update the documentation.  That does not enable the memcpy protection.
On Windows the performance of the memcpy protection is not great due to the way virtual memory works.  We can't map a large accessible zero range without actually committing the memory.  We could add a Vectored Exception handler, but then it is going to harm the debugging experience.

Thanks! I made a quick test comparing this new version against FMallocBinned2, though whether this can be considered a proper benchmark is questionable. Same integration code as my previous issue https://github.com/microsoft/snmalloc/issues/478.
 Overall usage is also a bit higher. This seems to be a clear win for FMallocBinned2.
FMallocBinned2, performance:

snmalloc 0.6 with SNMALLOC_CHECK_CLIENT, performance:

Only slightly slower on allocations, but much faster on deallocations. This seems to be a win for snmalloc overall.
The game also seems to crash on exit when snmalloc is used but I haven't yet investigated why.

On Windows the performance of the memcpy protection is not great due to the way virtual memory works. We can't map a large accessible zero range without actually committing the memory. We could add a Vectored Exception handler, but then it is going to harm the debugging experience.

Can you explain why this is required? Is it to support allocations from outside snmalloc?
For example, in Unreal Engine, there are over 1000 calls to FMemory::Memcpy, the absolute vast majority only ever operating on memory obtained from FMemory. It would probably be a good start to guard all of those.

Yeah, it is to support allocations from outside snmalloc.  The key issue is "absolute vast majority", if one isn't and we crash because of it, then customers will get very annoyed.  For instance,
   char buffer[256];
   memcpy(src, buffer, std::min(256, src_size));

This needs the stack allocation of buffer to not create an access violation when we look up the meta-data.  On Linux for instance, we mmap a 256GiB region of memory, and then any access is allowed.  On Windows, we MEM_RESERVE, a 256GiB region, and then MEM_COMMIT the bits that correspond to snmalloc allocations.  This means that accessing the meta-data on Windows for anything that doesn't correspond to an allocation will segfault.  There are three approaches we could take

Any attempt to access a meta-data that is not guaranteed to be snmalloc controlled causes a call to MEM_COMMIT.  This is the current implementation and is very slow.
We could install a VectoredExceptionHandler to detect accessing the meta-data when it is not committed, and commit it.  This is much cheaper, but leads to a poor debugging experience.  The debugger will probably trap the access violation before the handler, and lead users to believe that something is wrong when it isn't.
Install shared 2MiB zero pages for all the range outside that currently used by snmalloc.  This would incur a few MiB of commit charge for the associated page tables, and the shared large page.  It would not involve any exceptions, so debugging would be fine.  It is however a pretty complex change.

I prototyped the third option a couple of years ago, and I think given the new refactoring in 0.6.0 it would fit quite nicely.  I don't currently have time to implement it though.

Oh, you're right. I completely forgot about stack allocations. Those are very common, so it would be unusable.
Hope you'll find time to implement a good performing solution at some point!


Problem using existing Database

I have an app that I started just with sqflite, so there is already a database, but I want to integrate the package (looks great :D), but when I try to set the previous database and select one of the tables it says doesn't exists, but it does
no such table: rondas in "Select * from rondas LIMIT -1
Here is the code I use with sqflite
    Directory documentsDirectory = await getApplicationDocumentsDirectory();
    String path = join(documentsDirectory.path, 'ranch_sorting.db');

    return await openDatabase(
      path,
      version: 1,
      onCreate: _onCreate,
    );

And here is the code I'm adding to the main file to integrate the library
    var db = DB.instance;
    Directory documentsDirectory = await getApplicationDocumentsDirectory();
    var dir = documentsDirectory.path;

    db.setFilePath(
        dir,
        shouldForceCreatePath: true,
    );
    db.setFileName('ranch_sorting.db');

Please, some help

If it helps someone else, I just had to add a slash to the path, like this:
  Directory documentsDirectory = await getApplicationDocumentsDirectory();
  var dir = documentsDirectory.path + "/"; <- This slash

  db.setFilePath(
    dir,
    shouldForceCreatePath: true,
  );
  db.setFileName('ranch_sorting.db');


Preload BTC/XCP wallet balances

When your using Freewallet, you can't actually see the BTC/XCP amounts held in addresses in the "Address List" until after you switch to the wallet address and pull down balance/BTC info for the first time for an address.
Need to update wallet to preload BTC and XCP balances for all wallet addresses so they show correct balances in address list. The lack of a balance showing until after an address is loaded is causing some people to think they have no BTC in their addresses and ask customer support questions.

This is very needed, though a small issue. Been having to refresh every time a new address is selected.


Tweak Conflict Resolver to be more clear

I don't know how to put this into words exactly or what exactly is wrong with it.
However, every single time, without fail, I use the conflict resolver, I pick the wrong option. I have absolutely no clue why or how I'm picking the wrong file every time but I definitely am.
I recently had to migrate the server that was running my main Syncthing instance and it had gotten rather out of date.
In the process of re-syncing file conflicts occurred (not entirely sure why, I'd expect them to just update based on the other devices).
I go to fix the conflicts decide that it should clearly be the most recent files that are the correct ones, so I select them and select most recent. Broke everything.
I also have tried to gauge which device created the conflicting file, if it's the device that I was actively using then I select it and break everything.
I don't know if it's how the information is listed and I wrongly associate it with the wrong file/option or if there is something unclear about what the conflicts are in reference to (e.g. are the new files the ones getting marked or are the out of date files getting marked) but each time I've had to fix conflicts it feels like I'm being pranked.

Hello.
Same here, I know the version of the files I wanna keep (local or remote version, related to a firefox profile), but I always end up with the wrong ones.
I first thought the french translation was misleading or completely wrong, but it seems it's "well" translated after all.
It's a "major" issue still eady to fix :)

The same confusion just happened to me. I guess I got tripped up by intuitively assuming the two dates shown were the different modification dates for the two files.

Luckily, I noticed that the file I thought the dialog was saying is older was larger in size than the newer one, which wouldn't make sense in my case. After being perplexed for several minutes, I realized that the bottom date didn't indicate the modification date of the bottom file, but rather, the time the program found the conflict between the two files. That function fits the label "Conflict Created" more closely, but I guess I assumed it was just an awkward translation because the layout strongly suggested the two dates were for comparing the two files in question, at least in my eyes.

I came here because I just got tripped up by this dialog again too and it resulted in me losing keepassxc credential updates earlier today, so I decided to not shrug it off this time and dig into what's confusing us all. I understand the dialog (at least for one possible case of a conflict) and syncthing's conflict behavior a little better now, and know what my (and probably your) mistake was. @Oktayey was on the right track. I hope this helps others understand the dialog while giving the devs an idea to make it less confusing.
Before going into details, I'd like to make my 2 concrete suggestions to the devs to improve the UX of this dialog. I know you don't make syncthing, I'm only suggesting you improve the synctrayzor UI :)

move the Conflict Created date somewhere to the side and fill its place with the Modified Date of the conflicting file of which the Name and Size are to the left and right. Right now this looks like a row by row comparison of the 2 file versions, but the middle column isn't. The label is technically completely correct but placing it there just clashes with the intuitive layout around it.
move the Modified By label to the top row because that's the row describing the file as modified by the host in question. The bottom row describes the original version that's still on the current machine (but renamed to a conflict filename) and was not touched by the remote host, so the remote host label does not belong there.

for my fellow victims: when you get the conflict popup, the original file on disk has already been replaced by the latest remote version, and the original that was on this pc has already been renamed to *.sync-conflict, not the other way around. Syncthing's not asking if you want to accept the remote changes but if you want to revert to the old file this host had until just now.

Let me describe my case:

starting point: home pc, nas, and work pc in sync
friday night I updated a file on my home pc and synced it to my nas, but my work pc was off and did not get the update
this morning I started my work pc

it failed to connect to my nas and did not get the updated file
I made other changes to the same file on my offline work pc, creating the actual conflict by making 2 "child" updates of the same "parent" file within my net, but syncthing had no idea yet
I fixed my connectivity and got the conflict prompt on my work pc, and accidentally picked the work pc version, meaning the update I did on friday was lost. I fixed the file and synced it to my nas, assuming my home pc would accept this version from the network when powered up

I just turned on my home pc and got the conflict prompt again, and took a real good look at it

Below is what I now see on my home pc after starting it, where I last made changes to my file on friday and to which my work pc is now trying to push an update I did this morning after rejecting the home pc's version. Now it's easy to see the Modified By label is in the wrong place, while the "conflict file" is the version that was on the current host, not the incoming disputed version from the network.

I just realized this project appears abandoned... https://github.com/canton7/SyncTrayzor/issues/795


Repeating notification

Is there any method to set repeating to the AlarmManager, so the notification can be displayed each week on a specific day for example ?

Hi @RamiTrabelsi ,
There is no method to do this work. I believe this is not a responsibility of it, so you need to implement your code using AlarmManager and call pugnotification!

PugNotification is using its own AlarmManager, that doesn't permit us to customize repeating notification.

@RamiTrabelsi ,
Unaware her use AlarmManager own! Tell me know when or local?


Add brief explanation of how it works to the README

I was chatting with a friend about how it can feel like crates like read-process-memory are doing Wizard Magic, even though what's happening behind the scenes is really not all that complicated. So I thought it would be cool to add a brief summary to the README (with some C pseudocode) of how it actually works.
I'm not sure all of this is 100% accurate (I haven't looked at this code for a long time and I'm not totally sure I read the Rust code correctly), but I think it's close enough to be useful.
cc @acj

Thanks!


Improved f.robyn.func.R (R session aborted fixed bug )

Contributing to FB NextGen MMM R script
Before this improvement, each time restarting a modeling session a second time, the R session crashed because the parallelization was not correctly closed.
These changes therefore give :
- The ability to launch several modelizations in a row without crashing R session.
- The possibility of looping on several models at once and correctly close our parallelizations after modeling

Thank you Anis for this modification, I needed to model several models in a row and the Session R "crashe" was quite disturbing. I searched for a long time but I did not find the solution.

Hi all, thanks for this PR! We're hearing about this bug for the first time and will examine the changes. Rubenharutyunyan can you confirm that this fixes your problem completely?

Hi all, thanks for this PR! We're hearing about this bug for the first time and will examine the changes. Rubenharutyunyan can you confirm that this fixes your problem completely?

Hello, for personal needs, I created loops to model multiple regions at once but since adding nevergrad my sessions consistently crash after the first model. I also found that running the same model multiple times also caused the R session crash after the first model. With this modification, I had no problem for the 2 cases mentioned above.

Thank you for the feedback! We're freezing the code this and next week due to internal process and will examine and implement this PR asap.

Hi, we've noticed that using makeCluster() and stopCluster() slows down the parallel performance on my side quite dramatically. According to this https://stackoverflow.com/questions/28829300/doparallel-cluster-vs-cores thread, makeCluster/stopCluster uses the SNOW backend only that is intended for Windows and not Unix-like systems, while registerDoParallel(cores) chooses the right backend depending on OS. I'd reverse this commit until we find a more universal solution. Would be great if you can try updating your R to 4.1.0 and try using registerDoParallel() again to see if that works better.

Hi @gufengzhou  i  updated R to 4.1.0 and used registerDoParallel() :

I have the same issue, R session crashes when i launch a second model in a row:

Are you on windows or mac/other OS? Local/cloud?
I'm seeing in your screenshot that it crashes after printing "plotting 22 pareto....", which indicates that the parallelisation is actually already done.

I'm working on Windows and on Local. Yes it crashes after parallelisation. But the problem is caused by a bad closure at the end of the parallelization. And at the time of plotting the results, the memory saturates due to a bad closing of the connections :

So I think registerDoParallel () does not allow full and correct shutdown of parallelization on Windows. Indeed, some parallel computing going on in the background that is not getting cleaned up fully between runs. Unlike make / close Cluster which allows a better control of parallelization.

According to this documentation https://www.rdocumentation.org/packages/doParallel/versions/1.0.16/topics/registerDoParallel, the function stopImplicitCluster can close the connections implicitly. Can you try it out and let me know?

Also interesting for you, in this issue https://github.com/facebookexperimental/Robyn/issues/118, the user sees increase of performance when switching back from makeCluster. He probably works with Unix-like systems. My goal is to have a solution that works for both OS

Hi @gufengzhou , I have tried implementing the stopImplicitcluster in the code. It works but it slows down the processing time on Windows. Furthermore, I managed to find a solution that suits both OS and increases performance while decreasing processing time for both systems.
Could you process the last pull request #122 I posted so that I can suggest this improvement ?


Fix typo and redundant text in the documentation.

JerryScript-DCO-1.0-Signed-off-by: Daniel Vince<EMAIL_ADDRESS>

@vincedani Please use the JerryScript signoff instead of the IoT.js one.

@DanielBallaSZTE Thank you for the review, the PR is updated.

LGTM


Experimental docs.rs changes

Enable doc_cfg for nightly builds (on docs.rs and locally if enabled)
(Experimental) Replace hdf5_1_2_3 config flags with feature = "1.2.3". This will produce annotations like "Enabled on crate feature 1.10.0 only" in the docs instead of "Enabled on hdf5_1_10_0 only". If I understand correctly, this will also allow the users to refer to these as hdf5/1.10.0 externally (?). Features can be named as "hdf5-1.10.0" but that would look a bit ugly in the docs (with the numbers only, it looks pretty neat, see below for examples).
(TODO) we should definitely build the docs on the latest HDF5 version available (1.12.1?).
(TODO) ideally, we want mpio/blosc/lzf on docs.rs as well (the latter two are already there).
Should h5_have_parallel and such be renamed to feature = "have-parallel"?

Note: support for period for feature names has been only recently added to cargo (circa 1.50).
Related: #141.

(Was away for a little while, back now)
Wonder, for the docs.rs build, will we be able to get all the have-parallel, have-direct, etc entries show up? (and what can we do in order to make it work?)

@mulimoen Looks good to merge? (I'll probably update the changelog a bit)
We still need to figure how to build docs on:

1.12.1
direct/parallel/threadsafe/mpio/blosc/lzf all enabled
(but that's a separate issue)

Enabled this for hdf5-sys now. It's not ideal everywhere, some items such as hbool_t is suggested as only available with certain features enabled even though it is always present. This is very minor compared to seeing which functions are available in the current version. Looks good to merge now


Add low processor workaround to ´ensure_control_visible´ docs

The example provided for ´ensure_control_visible´ in the docs wont work in editor plugins. (Tested on 3.4.2)

Thanks for opening a pull request :slightly_smiling_face:
Pull requests (especially ones that break backwards compatibility) should be opened against the master branch instead of 3.x. This is because feature development occurs in the master branch. We can then cherry-pick specific PRs to the 3.x branch if they don't break backwards compatibility.
Also, it sounds like the original bug should be reported and investigated. It may be an easy fix and is better than just mentioning a workaround in the documentation.

@RoniPerson Bump :slightly_smiling_face: Could you do this?

Also, it sounds like the original bug should be reported and investigated. It may be an easy fix and is better than just mentioning a workaround in the documentation.

Completly forgot about this PR.
I don't think, that this is a bug. Based on #55609 I assume that it is known that waiting for the next frame is neccesarry and didn't consider it a bug. And that the workaround won't work in low processor mode lies in the nature of low processor mode as I understand it. It just won't process thr idle frame every frame so it is not given, that the signal will be called on the next frame.
I opened the PR against 3.x because I didn't know if the behavior of grab_focus was touched in the master branch. But I tested it in the beta just now and it still seems to apply. Will update when I find time.

Seems I screwed up with updating. Will open again when i fixed it.


Add troubleshooting for timeout error

When installing Oppia for the first time, githubusercontent requests may timeout due to DNS issues. Add points to address this (more context here).

@aks681 what's going on here? I don't understand how a DNS issue would lead to a timeout when downloading from githubusercontent for only one path but not others

Yeah, I am also not sure how it happened, but what I observed was that even loading images in PRs wasn't working at this point, but changing DNS provider to <IP_ADDRESS> fixed it. Might have been a one-off issue, not sure.

This sounds like an issue with the user's DNS configuration, which seems too generic for our troubleshooting guide, so I'm closing this. Please reopen if you disagree!


Seeing several issues on connections...

https://paste2.org/k9Vbn8cC

Getting that aswell, https://pastebin.com/Hd1QS8fK
Using the latest ViaVersion dev build if it could be due to that.

Duplicate of #264


set_option codegen false breaks subsequent definitions

inductive Exp
  | var (i : Nat)
  | app (a b : Exp)

set_option codegen false in
def Exp.hash1 : Exp → Nat
  | .var i => i
  | .app a b => a.hash1 + b.hash1

def Exp.hash2 : Exp → Nat
  | .var i => i
  | .app a b => a.hash2 + b.hash2

Expected behavior: The definition Exp.hash2 is accepted without error.
Actual behavior: failed to compile definition, consider marking it as 'noncomputable' because it depends on 'Exp.hash1.match_1', and it does not have executable code
Weirdly enough, this doesn't happen if the first definition is marked noncomputable instead of using set_option codegen false.

Thanks for raising this issue. I going to remove the option codegen, it is an old option implemented in C++.  We should use noncomputable instead.


Suggested version for Influxdb2.x

I am a JAVA development engineer from China
I sincerely hope that the InfluxDB database can be integrated with the official MyBatis database, so that operating the InfluxDB database can be as convenient and simple as operating the MySQL database, and even support MyBatis plus

  In this way, we can configure multiple data sources in the Spring Boot project to not only manipulate MySQL, but also use Mybatis to query data in InfluxDB in the project Greatly improving the entry-level operation of InfluxDB, if supported, I believe there will be a large number of developers who will be happy about it. In fact, someone has been working on this before. However, it is not an official plugin launched by InfluxDB https://toscode.mulanos.cn/ruin97/spring-boot-starter-influxdb I hope the official can introduce this method, which can be used to operate InfluxDB like MySQL

Due to my limited development ability I can only hope to communicate with the official boss of InfluxDB I hope the official can seriously consider it. Thank you


Receive updated fieldsState in onSubmitFail

state.fieldsState received in onSubmitFail isn't updated with the new newFieldsState created in the ValidateForm action.
It's especially visible at first try: submit a form without touching any fields result to an onSubmitFail without any error in state.fieldsState

oh that's a good catch, thanks @Freddy03h

thank you for your very fast review and merge :)

@all-contributors add @Freddy03h for bug fix


Opening button doesn't get focus when modal closes in iOS with VoiceOver

Issue
Steps to reproduce:

Turn on VO on an iOS device (doesn't seem to matter what version, even the latest version has this issue)
Go to the main demo page and navigate to the Inline Attribute Configuration example
Click the Show Modaal button to open the modal
Tap the screen to get focus to go to the modal (there's a separate issue where the modal doesn't get focus)
Navigate via swiping to the close button of the modal (at the end)
Activate the close button

What's expected:
VO focus moves back to the Show Modaal button
What happens:
VO focus is at the end of the page (where the modal previously existed)
What's going on
MDN's activeElement documentation mentions that on a Mac, this may only work with text inputs. I found that this is only true on iOS and not on the Mac. If you are on a button that's focused and you query for activeElement, it doesn't return anything.

As commented in #99, we seem to be running into is a random result in the 'return to last focus state' where VoiceOver, if it can't find/remember the state for whatever reason, will default to a focusable element nearest the last press being the close button of the modal.
What JavaScript we've tested so far doesn't seem to have much difference as VoiceOver will make its own decisions on where to go and ignore what we're asking it to do.
In short, needs more work but the issue is understood. Contribution on this from anyone is very welcome.

For this one, you likely need to pass in a reference to the opening element (or actually keep track of what opened it when it triggers the modal) to explicitly focus that element (instead of activeElement) since iOS Safari doesn't seem to track <button>s as active.

Thanks @backwardok - we already do that, only it hasn't been use by VoiceOver correctly or as expected. The replies to #99 have given us a good base and reference point to work from, so we expect to have updates to this task as well rolled into that. Thanks again!


Add banner to landing website for important updates and warnings

I find banners on top of websites extremely helpful to communicate important updates. For example, it is a common practice to communicate planned outages or production freezes. That way we may increase our chances of setting expectations and avoid frustrations when upgrading Falco.
For the Falco 0.37.0 release it could highlight the following:

Falco rules now follow semantic versioning and the most recent Falco rules release requires Falco >= 0.37.0
Falco will deprecate the following configs xyz in Falco 0.38, start using the new config options today (most notably the new engine config)
The -k flag no longer exists. Instead, we've introduced a new opt-in k8smeta plugin, although it isn't necessary for most Falco use cases. This is because the familiar k8s fields are extracted from the container runtime socket concurrently while looking up container images.
Check out the new Supported Fields
...

or similar ...

Hey Melissa, this is now already in the website! We have used this to display a graduation banner for a month. We can use that banner to display any information we please.

Saw this, amazing! Thanks!


No module named "dask_ml"

使用from hypergbm.hyper_gbm import HyperGBM
时报错：
ModuleNotFoundError:  No module named "dask_ml"

You can check it requirements.txt whether the packages in are properly installed.


Update iOS related rules

These rules repos no longer do releases. These are recent master commit
shas that are compatible with the current release of bazel.
This update enables building ios_static_framework targets from swift_library targets for https://github.com/tensorflow/tensorflow/pull/38956

@mihaimaruseac can you help with the copybara failure here?

Thanks!


How to disable default policies?

First of all. I absolutely love this project. It is a godsend!
Now I need to disable a few of the default policies that come in the baseline. How do I go about doing that? Some are assigned on the Landing Zones mgmt group, other are on the root. How does one disable some of the defaults? E.g. Deploy-Linux-Arc-Monitoring & Auditing on SQL server should be enabled
Also, is there a way to add a default nonComplianceMessages to all the default policies?
I will happily make a PR to add these userguides if I can get some initial help on figuring it out. Thanks!

Thank you for the great feedback @binaryPUNCH, and of course your two questions.
Please let us know whether the following helps...
Question 1
Have you seen the examples on Expand built in archetype definitions? This also includes guidance on how to enable the exclusion function which should cover what you're trying to achieve with disabling policies.
You will need to create an exclusion for the archetype at each scope where it's references, but to give an example for Deploy-Linux-Arc-Monitoring at the root scope, you would create the following:
File name ${custom-lib-path}/archetype_exclusion_es_root.json
{
    "exclude_es_root": {
        "policy_assignments": [
            "Deploy-LX-Arc-Monitoring"
        ],
        "policy_definitions": [],
        "policy_set_definitions": [],
        "role_definitions": [],
        "archetype_config": {
            "parameters": {},
            "access_control": {}
        }
    }
}

You can also see an example of this exact example in the test framework.
Just for clarity, you can only modify the presence of a Policy Assignment at the scope of where the assignment is created. If you want to actually exclude a Policy Assignment from applying to a lower scoped resource you need to either add a policy exclusion using the notScopes value, or to create Policy Exemptions.
Question 2

Also, is there a way to add a default nonComplianceMessages to all the default policies?

Unfortunately we haven't added support for this yet but we are tracking this in the following issue:

#67

We've been discussing this recently and have added it to our backlog for the next minor release. We were planning to provide a new input variable to allow specifying an optional "generic" non-compliance message which would be used unless a more specific one was added in the Policy Assignment template. Hopefully this will offer what you're looking for once implemented, but we would greatly appreciate your feedback on this.

Thank you thank you! I missed that part of the documentation. Great solution for doing the exclusions.
Aha, #67! We will really look forward to it. I believe that approach would be perfect. Just make sure it is optional for those who prefer not to use it, but we definitely will :)

Awesome, glad this helps.

Aha, #67! We will really look forward to it. I believe that approach would be perfect. Just make sure it is optional for those who prefer not to use it, but we definitely will :)

And yes, will definitely make this optional... plan is if var.default_non_compliance_message = "" (Actual variable name TBC) we will effectively "do nothing".


Adjust styling of Manage Classes page.

Related PT story: https://www.pivotaltracker.com/story/show/174601762
[#174601762]

react-components conflicts are resolved, now waiting for build...


Make project configurable from a repository file

It would be great to have repo settings available on the online Depfu dashboard page as configurable values in a config file.
Would need to decide on three things:
1) the location
Can be one location like the root of the project or multiple (fallback) locations, for example inside the .github directory would be nice to avoid an extra 'root' file.
2) the language
Looking at other tools TOML, JS or JSON seem to be the most common. Since JSON is not forgiving on (single) quotes and trailing commas TOML seems to be a good option for Depfu. A great Netlify example documentation page about their TOML config.
3) interaction with dashboard
Either the repo file or the dashboard settings take precedence, the first being the most common in my experience. It would also be great to be able to export settings from the dashboard as config file.
Example config content, including a required version for future flexibility:
version = 1
[strategy]
  outofspec = true
  [strategy.dev-dependencies]
    outofspec = false
[schedule]
  openlimit = 3

This is really the only Dependabot feature I miss. When I set up a project, it would be great if I could copy a previous config rather than having to set up everything again through the web UI.

@Siilwyn @andyw8 we recently shipped a beta of this, please give it a try and see if you run into any issues.
https://docs.depfu.com/article/41-config-files


Rails 5.2

[ ] Branch
[ ] Update .travis to CI branch
[ ] Update gemfile (in particular gis gems IIRC)
[ ] test ...

Blocking issues:

[ ] https://github.com/ClosureTree/closure_tree/issues/305
[ ] https://github.com/collectiveidea/delayed_job/pull/1023

Other than a couple of typos, and an issue with postgis 2.2.2 vs 2.4.4, there seem to be these four constants unavailable:
TAXON_NAME_CLASS_NAMES_VALID
TAXON_NAME_RELATIONSHIP_NAMES_SYNONYM
TAXON_NAME_CLASSIFICATION_NAMES
TAXON_NAME_RELATIONSHIP_NAMES


Components added in blueprints are not replicated

Description
Spawning a blueprint that specialises an actor, with a c++ ActorComponent added to it, will fail to replicate the added component.
Expected behavior
According to the docs and discussions with the team, ActorComponents added in this way should replicate properly.
Current behavior
The ActorComponent on this blueprint will not be managed by SpatialOS and it will not be replicated to the client. This can be observed by noting that the component is not mentioned in the Inspector breakdown of the spawned actor.
Possible solution
In SpatialGDK/Public/Schema/UnrealMetadata.h:
FORCEINLINE SubobjectToOffsetMap CreateOffsetMapFromActor(AActor* Actor, const FClassInfo& Info)
{
	SubobjectToOffsetMap SubobjectNameToOffset;

	for (auto& SubobjectInfoPair : Info.SubobjectInfo)
	{
		// REMOVED
		//UObject* Subobject = Actor->GetDefaultSubobjectByName(SubobjectInfoPair.Value->SubobjectName);
		// ADDED
		UObject* Subobject = StaticFindObjectFast(UObject::StaticClass(), Actor, SubobjectInfoPair.Value->SubobjectName);
		uint32 Offset = SubobjectInfoPair.Key;

		if (Subobject != nullptr && Subobject->IsPendingKill() == false && Subobject->IsSupportedForNetworking())
		{
			SubobjectNameToOffset.Add(Subobject, Offset);
		}
	}

	return SubobjectNameToOffset;
}

Steps to reproduce
Provide an unambiguous set of steps to reproduce this bug. Include code snippets if relevant.

Create a C++ Actor, MyActor, and add some default components such as a static mesh.
Create a C++ ActorComponent, MyComponent
Create a Blueprint specializing MyActor, call it MyBlueprint
In the blueprint, drag in MyComponent
In GameState or elsewhere, use code similar to the following to spawn MyBlueprint:

UBlueprint* MyBlueprint = LoadObject<UBlueprint>(nullptr, TEXT("Blueprint'/Game/MyBlueprint.MyBlueprint'"));
MyActor* spawnedActor = GetWorld()->SpawnActor<MyActor>(MyBlueprint->GeneratedClass, position, rotation);

Generate schema, snapshot and run Spatial
Connect clients and note warnings similar to the following:

[improbable.bridge.logging.EngineLogMessageHandler] [Worker: UnrealWorker5F6F8A35461C4C67A6C5A994E7B46699] Tried to generate initial replication state for an invalid sub-object (class SimpleBlockComponent, sub-object SimpleBlock, actor SimpleBlock_C_96). Object may have been deleted or is PendingKill. -[WorkerLogger:Unreal]

In the inspector, note that the spawned objects do not have MyComponent.

Thanks for the report. UNR-1181 tracking on our side.

Fixed in https://github.com/spatialos/UnrealGDK/pull/809


PyQt5 version

we installed napari[all] in a conda environment, but when starting napari, we get error about "xcb" library.
@tischi
I downgrade PyQt5 to an older version then the error went away.
I checked the pypi that PyQt5 was recently upgraded to v5.15.9. So it seems to me that napari won't work with the latest PyQt5 v5.15.9?
I also checked the napari setup.cfg, I can see that the required version fo PyQt5 is !=5.15.0.
My question is that, should we change the pin to PyQt5 version? or is the issue caused by something else?
Thanks

Are you the author of this post on image.sc https://forum.image.sc/t/installing-napari-startdist-plugin/77004?
If no please check if installing the libraries mentioned in this thread solve your problem. If not, please provide details about your operating system as without this is impossible to debug the problem.
Core devs without problems are using Qt > 5.15

Hello @sunyi000,
If you are on a debian-based system(Debian, Ubuntu, etc.), I recommend:
sudo apt-get install --reinstall libxcb-xinerama0

With recent versions of Ubuntu and recent versions of PyQt5, I faced a similar issue and reinstalling libxcb helped to solve. Somehow  libxcb-xinerama.so.0  was missing on each new Ubuntu installations.

Thanks all
We did pip install malaria[all] in a clean conda environment. It didn't work so we change PyQT to 5.12.3 to make napari starts. Install libxcb-xinerrama itself didn't help.
We will the solution on image.sc https://forum.image.sc/t/could-not-load-the-qt-platform/52966/2
Thanks

Hi, gentle bump, @sunyi000 did you manage to get this issue resolved? Can we close this?
Thanks!

Hi, gentle bump, @sunyi000 did you manage to get this issue resolved? Can we close this?
Thanks!

Yes please close this.thanks


Fortran books #5492

What does this PR do?
Add resource(s) | Add info
For resources
Description
Add some Fortran books
Why is this valuable (or not)?
Resolves #5492. All details there.
How do we know it's really free?
Online resources freely distributable with acknowledgment
For book lists, is it a book? For course lists, is it a course? etc.
In books section
Checklist:

[x] Read our contributing guidelines
[x] Search for duplicates.
[x] Include author(s) and platform where appropriate.
[x] Put lists in alphabetical order, correct spacing.
[x] Add needed indications (PDF, access notes, under construction)

Followup

Check the output of Travis-CI for linter errors!

apart from the 2 I flagged, these are great additions

weird. yes, 1467 and 1468

weird. yes, 1467 and 1468

Done