Release 1.1.9 not working on RS4021xs+

When I execute the script I get a bunch of errors like this:
sda SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 10 00 00 00 00 20 00 00 c0 00 00 00 25 20 00 00 00 00 00 00 00 00 00 00 00  HDIO_GET_IDENTITY failed: Invalid argument
I think these come from the getfirmware function. If I replace hdparm -I with smartctl -i that function does not return any errors and the script runs normally and reports that my drives already exist in the db files (Because I've run this a few times now). Unfortunately, Synology still shows the drives as not compatible if I don't use the -f flag. I want to use the deduplication capability so I don't want to use the force flag.
What could be wrong here? What tests can I do?
The drives I am trying to add:
HDD/SSD models found: 6
P043S3T8EMC3840,Revision:             ESFA
P043S7T6EMC7680,Revision:             ESV7
PX02SMF040,Revision:             MS01
PX02SMF040,Revision:             MS02
PX04SMB040,Revision:             AM04
PX05SMB040,Revision:             0101
NVMe drive models found: 1
WD_BLACK SN850X 2000GB,620311WD
P043S3T8EMC3840 already exists in rs4021xs+_host_v7.db
P043S3T8EMC3840 already exists in rs4021xs+_host_v7.db.new
P043S7T6EMC7680 already exists in rs4021xs+_host_v7.db
P043S7T6EMC7680 already exists in rs4021xs+_host_v7.db.new
PX02SMF040 already exists in rs4021xs+_host_v7.db
PX02SMF040 already exists in rs4021xs+_host_v7.db.new
PX02SMF040 already exists in rs4021xs+_host_v7.db
PX02SMF040 already exists in rs4021xs+_host_v7.db.new
PX04SMB040 already exists in rs4021xs+_host_v7.db
PX04SMB040 already exists in rs4021xs+_host_v7.db.new
PX05SMB040 already exists in rs4021xs+_host_v7.db
PX05SMB040 already exists in rs4021xs+_host_v7.db.new
WD_BLACK SN850X 2000GB already exists in rs4021xs+_host_v7.db
WD_BLACK SN850X 2000GB already exists in rs4021xs+_host_v7.db.new

Can you try running the following command: /usr/syno/sbin/synostgdisk --check-all-disks-compatibility to see if the drives appear with the green tick.
After a quick google I found out that some SAS drives do not implement the SATA IDENTIFY command, which is what hdparm is sending them.
I've uploaded a develop version that uses smartctl to get the firmware version for SAS drives: https://github.com/007revad/Synology_HDD_db/blob/develop/syno_hdd_db.sh

The PX04SMB040 show as compatible with that command, all others show as incompatible, even though they've been added to the DB.

It sounds like your SAS drives are sda, sdb etc instead of sas1, sas2 etc. Can you run the following command and report back what it shows.
find /dev -maxdepth 1 \( -name "hd*" -o -name "sd*" -o -name "sas*" -o -name "sata*" -o -name "nvme*" \)

That's right. My drives are not named sas1, sas2, etc. Here's the output from that command:
/dev/sdw3
/dev/sdv3
/dev/sdw2
/dev/sdw1
/dev/sdv2
/dev/sdv1
/dev/sdw
/dev/sdx3
/dev/sdx2
/dev/sdx1
/dev/sdx
/dev/sdv
/dev/sdt2
/dev/sdt1
/dev/sdu2
/dev/sdu1
/dev/sdt
/dev/sdu
/dev/sds2
/dev/sds1
/dev/sds
/dev/sdr2
/dev/sdr1
/dev/sdr
/dev/sdq2
/dev/sdq1
/dev/sdq
/dev/sdp2
/dev/sdp1
/dev/sdp
/dev/sdo2
/dev/sdo1
/dev/sdo
/dev/sdn2
/dev/sdn1
/dev/sdn
/dev/sdm2
/dev/sdm1
/dev/sdm
/dev/sdl3
/dev/sdl2
/dev/sdl1
/dev/sdl
/dev/sdk2
/dev/sdk1
/dev/sdk
/dev/sdj3
/dev/sdj2
/dev/sdj1
/dev/sdh3
/dev/sdh2
/dev/sdh1
/dev/sdi3
/dev/sdi2
/dev/sdi1
/dev/sdj
/dev/sdh
/dev/sdi
/dev/sdg3
/dev/sdg2
/dev/sdg1
/dev/sdf3
/dev/sdf2
/dev/sdf1
/dev/sdg
/dev/sde3
/dev/sde2
/dev/sde1
/dev/sdf
/dev/sdd3
/dev/sdd2
/dev/sdd1
/dev/sde
/dev/sdc3
/dev/sdc2
/dev/sdc1
/dev/sdd
/dev/sdb3
/dev/sdb2
/dev/sdb1
/dev/sdc
/dev/sda3
/dev/sda2
/dev/sda1
/dev/sdb
/dev/sda
/dev/nvme1n1p1
/dev/nvme1n1
/dev/nvme0n1p1
/dev/nvme0n1
/dev/nvme1
/dev/nvme0

Does the following command return anything?
smartctl -i /dev/sda | grep -i sas

Assuming that you are going to say that smartctl -i /dev/sda | grep -i sas returned either:

Transport protocol:   SAS (SPL-3)
Transport protocol:   SAS

I've edited the develop branch's syno_hdd_db.sh file which should now work for you.
https://github.com/007revad/Synology_HDD_db/blob/develop/syno_hdd_db.sh

Does the following command return anything?
smartctl -i /dev/sda | grep -i sas

Transport protocol:   SAS (SPL-3)
The new script works without error and returns this output below. Unfortunately, other than the PX04SMB040 drives, all others show up as unsupported even after this.
HDD/SSD models found: 3
P043S3T8EMC3840,ESFA
P043S7T6EMC7680,ESV7
PX04SMB040,AM04
NVMe drive models found: 1
WD_BLACK SN850X 2000GB,620311WD
P043S3T8EMC3840 already exists in rs4021xs+_host_v7.db
P043S3T8EMC3840 already exists in rs4021xs+_host_v7.db.new
P043S7T6EMC7680 already exists in rs4021xs+_host_v7.db
P043S7T6EMC7680 already exists in rs4021xs+_host_v7.db.new
PX04SMB040 already exists in rs4021xs+_host_v7.db
PX04SMB040 already exists in rs4021xs+_host_v7.db.new
WD_BLACK SN850X 2000GB already exists in rs4021xs+_host_v7.db
WD_BLACK SN850X 2000GB already exists in rs4021xs+_host_v7.db.new
Re-enabled support disk compatibility.
DSM successfully checked disk compatibility.

Can you run the following test script and report back what it outputs.
https://github.com/007revad/Synology_HDD_db/blob/test/drive_info.sh
Also can you run the following command which will copy your rs4021xs+_host_v7.db file to your home folder as rs4021xs+_host_v7.db.txt
sudo cp /var/lib/disk-compatibility/rs4021xs+_host_v7.db ~/rs4021xs+_host_v7.db.txt
Then attach the rs4021xs+_host_v7.db.txt file to your reply.

nvme0n1
NVMe Model:    'WD_BLACK SN850X 2000GB                  '
NVMe Model:    'WD_BLACK SN850X 2000GB'
NVMe Firmware: '620311WD'
NVMe Firmware: '620311WD'
nvme1n1
NVMe Model:    'WD_BLACK SN850X 2000GB                  '
NVMe Model:    'WD_BLACK SN850X 2000GB'
NVMe Firmware: '620311WD'
NVMe Firmware: '620311WD'
sda
Model:    'P043S3T8EMC3840'
Firmware: 'ESFA'
sdb
Model:    'P043S3T8EMC3840'
Firmware: 'ESFA'
sdc
Model:    'P043S3T8EMC3840'
Firmware: 'ESFA'
sdd
Model:    'P043S3T8EMC3840'
Firmware: 'ESFA'
sde
Model:    'P043S3T8EMC3840'
Firmware: 'ESFA'
sdf
Model:    'P043S3T8EMC3840'
Firmware: 'ESFA'
sdg
Model:    'P043S3T8EMC3840'
Firmware: 'ESFA'
sdh
Model:    'P043S3T8EMC3840'
Firmware: 'ESFA'
sdi
Model:    'P043S3T8EMC3840'
Firmware: 'ESFA'
sdj
Model:    'P043S3T8EMC3840'
Firmware: 'ESFA'
sdk
Model:    'PX04SMB040'
Firmware: 'AM04'
sdl
Model:    'PX04SMB040'
Firmware: 'AM04'
sdm
Model:    'PX04SMB040'
Firmware: 'AM04'
sdn
Model:    'PX04SMB040'
Firmware: 'AM04'
sdo
Model:    'PX04SMB040'
Firmware: 'AM04'
sdp
Model:    'PX04SMB040'
Firmware: 'AM04'
sdq
Model:    'PX04SMB040'
Firmware: 'AM04'
sdr
Model:    'PX04SMB040'
Firmware: 'AM04'
sds
Model:    'PX04SMB040'
Firmware: 'AM04'
sdt
Model:    'PX04SMB040'
Firmware: 'AM04'
sdu
Model:    'PX04SMB040'
Firmware: 'AM04'
sdv
Model:    'PX04SMB040'
Firmware: 'AM04'
sdx
Model:    'P043S7T6EMC7680'
Firmware: 'ESV7'
sdw
Model:    'PX04SMB040'
Firmware: 'AM04'
rs4021xs+_host_v7.db.txt

Everything looks okay in the rs4021xs+_host_v7.db file.

Are all 13 PX04SMB040 drives in the RS4021xs+ ?
Are the 10 P043S3T8EMC3840 drives and the P043S7T6EMC7680 in expansion units?
What brand are the P043S3T8EMC3840 and P043S7T6EMC7680 drives?

Google finds nothing for P043S3T8EMC3840 or P043S7T6EMC7680

Hey, appreciate all the investigations so far. Let me know if I can help beyond supplying you the info you need. I'm migrating all data off this nas and am open to all sorts of testing even if it results in data loss.
Answers to your questions below, starting with drive types
P043S3T8EMC3840 = Samsung PM1643 (EMC Firmware): 3.84TB SAS 12G SSD
=== START OF INFORMATION SECTION ===
Vendor:               SAMSUNG
Product:              P043S3T8 EMC3840
Revision:             ESFA
Compliance:           SPC-5
User Capacity:        3,840,774,504,448 bytes [3.84 TB]
Logical block size:   512 bytes
Physical block size:  4096 bytes
LU is resource provisioned, LBPRZ=1
Rotation Rate:        Solid State Device
Form Factor:          2.5 inches
Logical Unit id:      0x5002538b088b8010
Serial number:        ZWNY0K815764
Device type:          disk
Transport protocol:   SAS (SPL-3)
Local Time is:        Sun Mar 12 12:33:09 2023 PDT
SMART support is:     Available - device has SMART capability.
SMART support is:     Enabled
Temperature Warning:  Enabled
Read Cache is:        Enabled
Writeback Cache is:   Enabled
P043S7T6EMC7680 = Samsung PM1643 (EMC Firmware): 7.68TB SAS 12G SSD
=== START OF INFORMATION SECTION ===
Vendor:               SAMSUNG
Product:              P043S7T6 EMC7680
Revision:             ESV7
Compliance:           SPC-5
User Capacity:        7,680,475,267,072 bytes [7.68 TB]
Logical block size:   512 bytes
Physical block size:  4096 bytes
LU is resource provisioned, LBPRZ=1
Rotation Rate:        Solid State Device
Form Factor:          2.5 inches
Logical Unit id:      0x5002538b0028ef30
Serial number:        KPNA0N200850
Device type:          disk
Transport protocol:   SAS (SPL-3)
Local Time is:        Sun Mar 12 12:32:19 2023 PDT
SMART support is:     Available - device has SMART capability.
SMART support is:     Enabled
Temperature Warning:  Enabled
Read Cache is:        Enabled
Writeback Cache is:   Enabled
PX04SMB040 = Toshiba PX04SMB040 (Dell Firmware): 400GB SAS 12G SSD
=== START OF INFORMATION SECTION ===
Vendor:               TOSHIBA
Product:              PX04SMB040
Revision:             AM04
Compliance:           SPC-4
User Capacity:        400,088,457,216 bytes [400 GB]
Logical block size:   512 bytes
LU is resource provisioned, LBPRZ=1
Rotation Rate:        Solid State Device
Form Factor:          2.5 inches
Logical Unit id:      0x50000396dc88e551
Serial number:        2670A00AT2XD
Device type:          disk
Transport protocol:   SAS (SPL-3)
Local Time is:        Sun Mar 12 12:37:45 2023 PDT
SMART support is:     Available - device has SMART capability.
SMART support is:     Enabled
Temperature Warning:  Disabled or Not Supported
Read Cache is:        Enabled
Writeback Cache is:   Disabled
NVME drives are on a Synology M2D20 SSD Adapter. The drives themselves are Western Digital SN850X, 2TB variants.
All drives are in the same machine. This is a redpill (arpl) build of DSM 7.1.1-42962 Update 2 on a custom built server with a Supermicro SAS3 backplane (24 Bay), and a Supermicro X11SSF-CF motherboard with a built in LSI SAS3 3008 controller.

cat "/sys/block/sda/device/model"
P043S3T8 EMC3840

cat "/sys/block/sda/device/model" | xargs
P043S3T8 EMC3840

Seems to me the first one returns some trailing spaces but otherwise both are the same.

The problem with the NVMe drives may be an indication that I need to add those drives M2D20's database file. Though my ds1821+_m2d20_v7.db file has no drives in it at all. It only has {"disk_compatbility_info":{},"nas_model":"ds1821+"}

Attaching my rs4021xs+_m2d20_v7.db as it has a few models defined in it. See if that helps.
rs4021xs+_m2d20_v7.db.txt

I've always been doubtful that drive model names like WD_BLACK SN850X 2000GB would work because none of the drives in the NAS model's .db files have spaces in the model. But I just found SSD 850 PRO 2TB in the expansion unit .db files. So maybe I can add WD_BLACK SN850X 2000GB to the *_m2d20_v7.db file.
WD's product number for the WD_BLACK SN850X 2000GB is WDS200T2X0E but I can't find any way to get the actual WD product number from the NVMe drives in DSM.

So if we can find a way to get that WD product number from DSM that will be all you need? Should we try hardcoding to see if it's the product number that's needed vs something else?
I'm having trouble understanding the layout of these db files.

The db files are single-line JSON files. If you want to view the contents in a human readable JSON format run:
jq . /var/lib/disk-compatibility/rs4021xs+_m2d20_v7.db
For larger db files you need to save it to a file:
jq . /var/lib/disk-compatibility/rs4021xs+_m2d20_v7.db > ~/rs4021xs+_m2d20_v7.db.txt
But don't edit it while it's in the human readable format.
In DSM 7 I add the drive model to the end of the file, before the }},"nas_model":"rs4021xs+"} In DSM I add the drive model at the start just after the {"success":1,"list":[
I've inserted WD_BLACK SN850X 2000GB in the attached file. Make sure you backup the existing rs4021xs+_m2d20_v7.db file before replacing it with this one:
rs4021xs+_m2d20_v7.db.edited.txt

That file worked. The NVME drives are verified now.

As a test, I also manually modified my rs4021xs+_host_v7.db and changed P043S7T6EMC7680 to P043S7T6 EMC7680 and did the same for P043S3T8EMC3840 => P043S3T8 EMC3840. Now all my drives are verified.
I have a backup of the file available to revert and test with the script whenever you're ready.

I've just uploaded the latest script version, v1.1.11, which has some improvements and fixes in it. It will correctly add your P043S7T6 EMC7680 and P043S3T8 EMC3840 so you can restore your rs4021xs+_host_v7.db and try it.
I'll start working on changes to the script to support m2dxx cards. Though I would like to be able to detect which card is installed (rather than editing all the m2dxx.db files).

I only reverted my hosts file, not the one for the M2D20 card and executed the script. Happy to revert both and test again if you want. Everything seems to work fine for now. Script output below
HDD/SSD models found: 3
P043S3T8 EMC3840,ESFA
P043S7T6 EMC7680,ESV7
PX04SMB040,AM04
M.2 drive models found: 1
WD_BLACK SN850X 2000GB,620311WD
Backed up database to rs4021xs+_host_v7.db.bak
Added P043S3T8 EMC3840 to rs4021xs+_host_v7.db
Added P043S3T8 EMC3840 to rs4021xs+_host_v7.db.new
Added P043S7T6 EMC7680 to rs4021xs+_host_v7.db
Added P043S7T6 EMC7680 to rs4021xs+_host_v7.db.new
PX04SMB040 already exists in rs4021xs+_host_v7.db
PX04SMB040 already exists in rs4021xs+_host_v7.db.new
WD_BLACK SN850X 2000GB already exists in rs4021xs+_host_v7.db
WD_BLACK SN850X 2000GB already exists in rs4021xs+_host_v7.db.new
Enabled M.2 volume support.
Changes to rs4021xs+_host_v7.db
},
"P043S3T8 EMC3840": {
"default": {
"compatibility_interval": [
{
"compatibility": "support",
"not_yet_rolling_status": "support",
"fw_dsm_update_status_notify": false,
"barebone_installable": true
}
]
}
},
"P043S7T6 EMC7680": {
"default": {
"compatibility_interval": [
{
"compatibility": "support",
"not_yet_rolling_status": "support",
"fw_dsm_update_status_notify": false,
"barebone_installable": true
}
]
}
}
},
"nas_model": "rs4021xs+"
}
DSM successfully checked disk compatibility.

I noticed this one has a message about enabling M.2 volume support. Is that supposed to work via Storage Manager? I don't see any options in the GUI to create a volume out of my M.2 drives. Not a deal breaker for me because I don't plan on doing this yet but thought I'd let you know.
Completely unrelated question (and happy to open a new issue to make it a separate thread if needed). Do you see a path to somehow changing the vendor name on these drives to make them look like Synology drives? DSM seems to be restricting the ability to enable Deduplication because these are not Synology drives.

Can you run the following command and see if it identifies the card model as M2D20
synodisk --m2-card-model-get /dev/nvme0n1
The comment about enabling M.2 volume support refers to the script making sure that "support_m2_pool" is set to "yes" in /etc.defaults/synoinfo.conf. Someone testing DSM 7.2 beta on a DS918+ lost their SSH created NMVe volume because DSM 7.2 beta set "support_m2_pool" to "no".
I am working on figuring out how Synology prevents non-Synology NMVe drives being able to create a volume in the GUI so I can bypass it. After that's done I'll have a look at enabling Deduplication for non-Synology drives. I'm actually surprized that the clever Expenology developers haven't done it already.
A discussion on changing the vendor name and model, or changing the vendor name and model that DSM sees, would be best in a new thread with an appropriate title so others who may now a solution can join the thread.

Yup, that command returns
M2D20
I'll start a separate issue on enabling deduplication

Can you restore your .db file backups then try this version the script which processes the M2D20 as well:
https://github.com/007revad/Synology_HDD_db/blob/test/syno_hdd_db.sh

Sorry, just saw this. I'm migrating some live VMs off the NAS and will test after that and report back. Will be likely tomorrow by the time I get a chance

tl;dr: I've just finished testing and the M.2 drives are NOT marked verified.
Detailed steps below

I reverted these two files:

rs4021xs+_host_v7.db
rs4021xs+_m2d20_v7.db

I executed sudo ./syno_hdd_db.sh -showedits
DSM marked my drives as unverified.
I then downloaded and executed the new script shared here
DSM marks my SSDs as compatible but the M.2 drives still show as unverified
Just to double check I executed this command again: sudo /usr/syno/sbin/synostgdisk --check-all-disks-compatibility but my M.2 drives are marked unverified

Detailed script output below
HDD/SSD models found: 3
P043S3T8 EMC3840,ESFA
P043S7T6 EMC7680,ESV7
PX04SMB040,AM04
M.2 drive models found: 1
WD_BLACK SN850X 2000GB,620311WD
Added P043S3T8 EMC3840 to rs4021xs+_host_v7.db
P043S3T8 EMC3840 already exists in rs4021xs+_host_v7.db.new
Added P043S7T6 EMC7680 to rs4021xs+_host_v7.db
P043S7T6 EMC7680 already exists in rs4021xs+_host_v7.db.new
PX04SMB040 already exists in rs4021xs+_host_v7.db
PX04SMB040 already exists in rs4021xs+_host_v7.db.new
WD_BLACK SN850X 2000GB already exists in rs4021xs+_host_v7.db
WD_BLACK SN850X 2000GB already exists in rs4021xs+_host_v7.db.new
M.2 volume support already enabled.
Changes to rs4021xs+_host_v7.db
},
"P043S3T8 EMC3840": {
"default": {
"compatibility_interval": [
{
"compatibility": "support",
"not_yet_rolling_status": "support",
"fw_dsm_update_status_notify": false,
"barebone_installable": true
}
]
}
},
"P043S7T6 EMC7680": {
"default": {
"compatibility_interval": [
{
"compatibility": "support",
"not_yet_rolling_status": "support",
"fw_dsm_update_status_notify": false,
"barebone_installable": true
}
]
}
}
},
"nas_model": "rs4021xs+"
}
DSM successfully checked disk compatibility.

Just to be fully sure, I copied over your manually edited file rs4021xs+_m2d20_v7.db.edited.txt into /var/lib/disk-compatibility/rs4021xs+_m2d20_v7.db and now my M.2 drives show as verified

Copy of the original file that I am using to revert M.2 to unverified status:
rs4021xs+_m2d20_v7.db.org.txt

Yes, both rs4021xs+_m2d20_v7.db.org.txt and rs4021xs+_m2d20_v7.db.script.txt are the same.
That script version was just to test if it found your M2D20.
This version will edit the m2d20 db file. https://github.com/007revad/Synology_HDD_db/blob/develop/syno_hdd_db.sh

Getting an error with this one
HDD/SSD models found: 3
P043S3T8 EMC3840,ESFA
P043S7T6 EMC7680,ESV7
PX04SMB040,AM04
M.2 drive models found: 1
WD_BLACK SN850X 2000GB,620311WD
ERROR 3 /var/lib/disk-compatibility/rsrs4021xs+_host_v7.db not found!

Can you tell me what these 3 commands return:
printf "sed: " && sed 's/[0-9].*//' "/proc/sys/kernel/syno_hw_version"
printf "cat: " && cat /proc/sys/kernel/syno_hw_version
printf "key: " && get_key_value /etc/synoinfo.conf unique | cut -d'_' -f3

I've fixed the develop version of the script. Can you please try this one.
https://github.com/007revad/Synology_HDD_db/blob/develop/syno_hdd_db.sh

printf "sed: " && sed 's/[0-9].*//' "/proc/sys/kernel/syno_hw_version"
sed: RS

printf "cat: " && cat /proc/sys/kernel/syno_hw_version
cat: RS4021xs+

printf "key: " && get_key_value /etc/synoinfo.conf unique | cut -d'_' -f3
key: rs4021xs+

I've fixed the develop version of the script. Can you please try this one.
https://github.com/007revad/Synology_HDD_db/blob/develop/syno_hdd_db.sh

Reverted both sets of files and used this version of the script. My M.2 drives still show as unverified.

Can you attach a copy of the rs4021xs+_host_v7.db and rs4021xs+_m2d20_v7.db files from after the script ran.

rs4021xs+_m2d20_v7.db.3-21.txt
rs4021xs+_host_v7.db.3-21.txt

I assume you are still using that develop version of the script?
This output is missing the M.2 card models section:
M.2 drive models found: 1
WD_BLACK SN850X 2000GB,620311WD

No Expansion Units found

It should look like this:
M.2 drive models found: 1
WD_BLACK SN850X 2000GB,620311WD

M.2 card models found: 1
M2D20

No Expansion Units found

I've changed v1.2.23 so if there are M.2 drives and no M.2 cards were found it will output like this:
M.2 drive models found: 1
WD_BLACK SN850X 2000GB,620311WD

No M.2 card models found

No Expansion Units found

At least then we can see if not finding the M2D20 or is finding it but failing to edit the db files.
Please try v1.2.23 https://github.com/007revad/Synology_HDD_db

Tried the latest script, still the same problem. My M.2 drives are still unverified. Output below
Synology_HDD_db v1.2.23
RS4021xs+ DSM 7.1.1
HDD/SSD models found: 3
P043S3T8 EMC3840,ESFA
P043S7T6 EMC7680,ESV7
PX04SMB040,AM04
M.2 drive models found: 1
WD_BLACK SN850X 2000GB,620311WD
No M.2 cards found
No Expansion Units found
Added P043S3T8 EMC3840 to rs4021xs+_host_v7.db
P043S3T8 EMC3840 already exists in rs4021xs+_host_v7.db.new
Added P043S7T6 EMC7680 to rs4021xs+_host_v7.db
P043S7T6 EMC7680 already exists in rs4021xs+_host_v7.db.new
PX04SMB040 already exists in rs4021xs+_host_v7.db
PX04SMB040 already exists in rs4021xs+_host_v7.db.new
WD_BLACK SN850X 2000GB already exists in rs4021xs+_host_v7.db
WD_BLACK SN850X 2000GB already exists in rs4021xs+_host_v7.db.new
Re-enabled support memory compatibility.
M.2 volume support already enabled.
Changes to rs4021xs+_host_v7.db
},
"P043S3T8 EMC3840": {
"default": {
"compatibility_interval": [
{
"compatibility": "support",
"not_yet_rolling_status": "support",
"fw_dsm_update_status_notify": false,
"barebone_installable": true
}
]
}
},
"P043S7T6 EMC7680": {
"default": {
"compatibility_interval": [
{
"compatibility": "support",
"not_yet_rolling_status": "support",
"fw_dsm_update_status_notify": false,
"barebone_installable": true
}
]
}
}
},
"nas_model": "rs4021xs+"
}
DSM successfully checked disk compatibility.

Can you try the following command, which should list your M2D20 twice (once for each NVMe drive.
sudo for d in /sys/block/*; do cardmodel=$(synodisk --m2-card-model-get "/dev/$d") && echo "$cardmodel"; done

I get a syntax error
-sh: syntax error near unexpected token ``do'

If it helps, I ran these two command manually
synodisk --m2-card-model-get /dev/nvme0n1
M2D20
synodisk --m2-card-model-get /dev/dm-10
Not support

Also ls -l /dev/block
total 0
lrwxrwxrwx 1 root root 0 Mar 24 17:45 dm-10 -> ../devices/virtual/block/dm-10
lrwxrwxrwx 1 root root 0 Mar 24 17:45 dm-2 -> ../devices/virtual/block/dm-2
lrwxrwxrwx 1 root root 0 Mar 24 17:45 dm-3 -> ../devices/virtual/block/dm-3
lrwxrwxrwx 1 root root 0 Mar 24 17:45 dm-4 -> ../devices/virtual/block/dm-4
lrwxrwxrwx 1 root root 0 Mar 24 17:45 dm-5 -> ../devices/virtual/block/dm-5
lrwxrwxrwx 1 root root 0 Mar 24 17:45 dm-6 -> ../devices/virtual/block/dm-6
lrwxrwxrwx 1 root root 0 Mar 24 17:45 dm-7 -> ../devices/virtual/block/dm-7
lrwxrwxrwx 1 root root 0 Mar 24 17:45 dm-8 -> ../devices/virtual/block/dm-8
lrwxrwxrwx 1 root root 0 Mar 24 17:45 dm-9 -> ../devices/virtual/block/dm-9
lrwxrwxrwx 1 root root 0 Mar 24 17:45 loop0 -> ../devices/virtual/block/loop0
lrwxrwxrwx 1 root root 0 Mar 24 17:45 loop1 -> ../devices/virtual/block/loop1
lrwxrwxrwx 1 root root 0 Mar 24 17:45 loop2 -> ../devices/virtual/block/loop2
lrwxrwxrwx 1 root root 0 Mar 24 17:45 loop3 -> ../devices/virtual/block/loop3
lrwxrwxrwx 1 root root 0 Mar 24 17:45 loop4 -> ../devices/virtual/block/loop4
lrwxrwxrwx 1 root root 0 Mar 24 17:45 loop5 -> ../devices/virtual/block/loop5
lrwxrwxrwx 1 root root 0 Mar 24 17:45 loop6 -> ../devices/virtual/block/loop6
lrwxrwxrwx 1 root root 0 Mar 24 17:45 loop7 -> ../devices/virtual/block/loop7
lrwxrwxrwx 1 root root 0 Mar 13 17:37 md0 -> ../devices/virtual/block/md0
lrwxrwxrwx 1 root root 0 Mar 13 17:37 md1 -> ../devices/virtual/block/md1
lrwxrwxrwx 1 root root 0 Mar 13 17:37 md2 -> ../devices/virtual/block/md2
lrwxrwxrwx 1 root root 0 Mar 13 17:37 md3 -> ../devices/virtual/block/md3
lrwxrwxrwx 1 root root 0 Mar 13 17:37 md4 -> ../devices/virtual/block/md4
lrwxrwxrwx 1 root root 0 Mar 13 17:37 nvme0n1 -> ../devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:04.0/0000:06:00.0/nvme/nvme0/nvme0n1
lrwxrwxrwx 1 root root 0 Mar 13 17:37 nvme1n1 -> ../devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:08.0/0000:07:00.0/nvme/nvme1/nvme1n1
lrwxrwxrwx 1 root root 0 Mar 24 17:45 ram0 -> ../devices/virtual/block/ram0
lrwxrwxrwx 1 root root 0 Mar 24 17:45 ram1 -> ../devices/virtual/block/ram1
lrwxrwxrwx 1 root root 0 Mar 24 17:45 ram10 -> ../devices/virtual/block/ram10
lrwxrwxrwx 1 root root 0 Mar 24 17:45 ram11 -> ../devices/virtual/block/ram11
lrwxrwxrwx 1 root root 0 Mar 24 17:45 ram12 -> ../devices/virtual/block/ram12
lrwxrwxrwx 1 root root 0 Mar 24 17:45 ram13 -> ../devices/virtual/block/ram13
lrwxrwxrwx 1 root root 0 Mar 24 17:45 ram14 -> ../devices/virtual/block/ram14
lrwxrwxrwx 1 root root 0 Mar 24 17:45 ram15 -> ../devices/virtual/block/ram15
lrwxrwxrwx 1 root root 0 Mar 24 17:45 ram2 -> ../devices/virtual/block/ram2
lrwxrwxrwx 1 root root 0 Mar 24 17:45 ram3 -> ../devices/virtual/block/ram3
lrwxrwxrwx 1 root root 0 Mar 24 17:45 ram4 -> ../devices/virtual/block/ram4
lrwxrwxrwx 1 root root 0 Mar 24 17:45 ram5 -> ../devices/virtual/block/ram5
lrwxrwxrwx 1 root root 0 Mar 24 17:45 ram6 -> ../devices/virtual/block/ram6
lrwxrwxrwx 1 root root 0 Mar 24 17:45 ram7 -> ../devices/virtual/block/ram7
lrwxrwxrwx 1 root root 0 Mar 24 17:45 ram8 -> ../devices/virtual/block/ram8
lrwxrwxrwx 1 root root 0 Mar 24 17:45 ram9 -> ../devices/virtual/block/ram9
lrwxrwxrwx 1 root root 0 Mar 13 17:37 sda -> ../devices/pci0000:00/0000:00:01.1/0000:09:00.0/host0/port-0:0/expander-0:0/port-0:0:0/end_device-0:0:0/target0:0:0/0:0:0:0/block/sda
lrwxrwxrwx 1 root root 0 Mar 13 17:37 sdb -> ../devices/pci0000:00/0000:00:01.1/0000:09:00.0/host0/port-0:0/expander-0:0/port-0:0:1/end_device-0:0:1/target0:0:1/0:0:1:0/block/sdb
lrwxrwxrwx 1 root root 0 Mar 13 17:37 sdc -> ../devices/pci0000:00/0000:00:01.1/0000:09:00.0/host0/port-0:0/expander-0:0/port-0:0:2/end_device-0:0:2/target0:0:2/0:0:2:0/block/sdc
lrwxrwxrwx 1 root root 0 Mar 13 17:37 sdd -> ../devices/pci0000:00/0000:00:01.1/0000:09:00.0/host0/port-0:0/expander-0:0/port-0:0:3/end_device-0:0:3/target0:0:3/0:0:3:0/block/sdd
lrwxrwxrwx 1 root root 0 Mar 13 17:37 sde -> ../devices/pci0000:00/0000:00:01.1/0000:09:00.0/host0/port-0:0/expander-0:0/port-0:0:4/end_device-0:0:4/target0:0:4/0:0:4:0/block/sde
lrwxrwxrwx 1 root root 0 Mar 13 17:37 sdf -> ../devices/pci0000:00/0000:00:01.1/0000:09:00.0/host0/port-0:0/expander-0:0/port-0:0:5/end_device-0:0:5/target0:0:5/0:0:5:0/block/sdf
lrwxrwxrwx 1 root root 0 Mar 13 17:37 sdg -> ../devices/pci0000:00/0000:00:01.1/0000:09:00.0/host0/port-0:0/expander-0:0/port-0:0:6/end_device-0:0:6/target0:0:6/0:0:6:0/block/sdg
lrwxrwxrwx 1 root root 0 Mar 13 17:37 sdh -> ../devices/pci0000:00/0000:00:01.1/0000:09:00.0/host0/port-0:0/expander-0:0/port-0:0:7/end_device-0:0:7/target0:0:7/0:0:7:0/block/sdh
lrwxrwxrwx 1 root root 0 Mar 13 17:37 sdi -> ../devices/pci0000:00/0000:00:01.1/0000:09:00.0/host0/port-0:0/expander-0:0/port-0:0:8/end_device-0:0:8/target0:0:8/0:0:8:0/block/sdi
lrwxrwxrwx 1 root root 0 Mar 13 17:37 sdj -> ../devices/pci0000:00/0000:00:01.1/0000:09:00.0/host0/port-0:0/expander-0:0/port-0:0:9/end_device-0:0:9/target0:0:9/0:0:9:0/block/sdj
lrwxrwxrwx 1 root root 0 Mar 13 17:37 sdk -> ../devices/pci0000:00/0000:00:01.1/0000:09:00.0/host0/port-0:0/expander-0:0/port-0:0:10/end_device-0:0:10/target0:0:10/0:0:10:0/block/sdk
lrwxrwxrwx 1 root root 0 Mar 13 17:37 sdl -> ../devices/pci0000:00/0000:00:01.1/0000:09:00.0/host0/port-0:0/expander-0:0/port-0:0:11/end_device-0:0:11/target0:0:11/0:0:11:0/block/sdl
lrwxrwxrwx 1 root root 0 Mar 13 17:37 sdm -> ../devices/pci0000:00/0000:00:01.1/0000:09:00.0/host0/port-0:0/expander-0:0/port-0:0:12/end_device-0:0:12/target0:0:12/0:0:12:0/block/sdm
lrwxrwxrwx 1 root root 0 Mar 13 17:37 sdn -> ../devices/pci0000:00/0000:00:01.1/0000:09:00.0/host0/port-0:0/expander-0:0/port-0:0:13/end_device-0:0:13/target0:0:13/0:0:13:0/block/sdn
lrwxrwxrwx 1 root root 0 Mar 13 17:37 sdo -> ../devices/pci0000:00/0000:00:01.1/0000:09:00.0/host0/port-0:0/expander-0:0/port-0:0:14/end_device-0:0:14/target0:0:14/0:0:14:0/block/sdo
lrwxrwxrwx 1 root root 0 Mar 13 17:37 sdp -> ../devices/pci0000:00/0000:00:01.1/0000:09:00.0/host0/port-0:0/expander-0:0/port-0:0:15/end_device-0:0:15/target0:0:15/0:0:15:0/block/sdp
lrwxrwxrwx 1 root root 0 Mar 13 17:37 sdq -> ../devices/pci0000:00/0000:00:01.1/0000:09:00.0/host0/port-0:0/expander-0:0/port-0:0:16/end_device-0:0:16/target0:0:16/0:0:16:0/block/sdq
lrwxrwxrwx 1 root root 0 Mar 13 17:37 sdr -> ../devices/pci0000:00/0000:00:01.1/0000:09:00.0/host0/port-0:0/expander-0:0/port-0:0:17/end_device-0:0:17/target0:0:17/0:0:17:0/block/sdr
lrwxrwxrwx 1 root root 0 Mar 13 17:37 sds -> ../devices/pci0000:00/0000:00:01.1/0000:09:00.0/host0/port-0:0/expander-0:0/port-0:0:18/end_device-0:0:18/target0:0:18/0:0:18:0/block/sds
lrwxrwxrwx 1 root root 0 Mar 13 17:37 sdt -> ../devices/pci0000:00/0000:00:01.1/0000:09:00.0/host0/port-0:0/expander-0:0/port-0:0:19/end_device-0:0:19/target0:0:19/0:0:19:0/block/sdt
lrwxrwxrwx 1 root root 0 Mar 13 17:37 sdu -> ../devices/pci0000:00/0000:00:01.1/0000:09:00.0/host0/port-0:0/expander-0:0/port-0:0:20/end_device-0:0:20/target0:0:20/0:0:20:0/block/sdu
lrwxrwxrwx 1 root root 0 Mar 13 17:37 sdv -> ../devices/pci0000:00/0000:00:01.1/0000:09:00.0/host0/port-0:0/expander-0:0/port-0:0:21/end_device-0:0:21/target0:0:21/0:0:21:0/block/sdv
lrwxrwxrwx 1 root root 0 Mar 13 17:37 sdw -> ../devices/pci0000:00/0000:00:01.1/0000:09:00.0/host0/port-0:0/expander-0:0/port-0:0:22/end_device-0:0:22/target0:0:22/0:0:22:0/block/sdw
lrwxrwxrwx 1 root root 0 Mar 13 17:37 sdx -> ../devices/pci0000:00/0000:00:01.1/0000:09:00.0/host0/port-0:0/expander-0:0/port-0:0:23/end_device-0:0:23/target0:0:23/0:0:23:0/block/sdx
lrwxrwxrwx 1 root root 0 Mar 24 17:45 synoboot -> ../devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/host1/target1:0:0/1:0:0:0/block/synoboot

Can you please download this test version: https://raw.githubusercontent.com/007revad/Synology_HDD_db/test/syno_hdd_db.sh
And run it with -d or --debug
sudo -i /<path-to-script>/syno_hdd_db.sh -d

Getting an error:
sudo -i ./syno_hdd_db.sh -d
-ash: ./syno_hdd_db.sh: No such file or directory

Worked with different syntax. The M.2 drives are still not verified. SSD's become verified like before
sudo -i ~/syno_hdd_db.sh -d
Synology_HDD_db v1.2.27
RS4021xs+ DSM 7.1.1-42962
debug 1: /sys/block/nvme0n1 nvme
debug 2: getcardmodel
debug 3: cardmodel: Not M.2 adapter card
debug 1: /sys/block/nvme1n1 nvme
debug 2: getcardmodel
debug 3: cardmodel: Not M.2 adapter card
HDD/SSD models found: 3
P043S3T8 EMC3840,ESFA
P043S7T6 EMC7680,ESV7
PX04SMB040,AM04
M.2 drive models found: 1
WD_BLACK SN850X 2000GB,620311WD
No M.2 cards found
No Expansion Units found
Added P043S3T8 EMC3840 to rs4021xs+_host_v7.db
P043S3T8 EMC3840 already exists in rs4021xs+_host_v7.db.new
Added P043S7T6 EMC7680 to rs4021xs+_host_v7.db
P043S7T6 EMC7680 already exists in rs4021xs+_host_v7.db.new
PX04SMB040 already exists in rs4021xs+_host_v7.db
PX04SMB040 already exists in rs4021xs+_host_v7.db.new
WD_BLACK SN850X 2000GB already exists in rs4021xs+_host_v7.db
WD_BLACK SN850X 2000GB already exists in rs4021xs+_host_v7.db.new
M.2 volume support already enabled.
DSM successfully checked disk compatibility.

I see the problem. The script is using
synodisk --m2-card-model-get /dev/sys/block/nvme0n1 when it should have been using
synodisk --m2-card-model-get /dev/nvme0n1
This test version should work for you:
https://raw.githubusercontent.com/007revad/Synology_HDD_db/test/syno_hdd_db.sh

Someone else has confirmed that my new version of the script now finds MS cards and the M2 drives on the M2 card are now showing as compatible.
https://github.com/007revad/Synology_HDD_db/releases/tag/v1.2.28

The latest version works but seems to have trouble with updating itself. It says a new version is available, (Current 1.2.27, New 1.2.28), I say 'y' to get the new version, then say 'y' to stop so I can run the new one. But the newly downloaded one still thinks its 1.2.27 so it prompts to download again.

Looking up the code, the version number hardcoded in Release 1.2.28 is wrong - it says 1.2.27

Sorry @jayanty. I read your comment 2 weeks ago and immediately released a newer version to fix that wrong version number and forgot to reply to let you know.


Being unable to stand after crouching causes noclip

Attempting to stop crouching in a 1 block tall space causes the player to clip through the ground.
This can then be repeated once the player is underground to crouchfall forever.
Gif demonstration
(apologies for odd screencap)

Closing as proposed in https://github.com/MovingBlocks/Terasology/pull/2961#issuecomment-341993601
The PR should fix this issue.
Follow up issue is #1075


Refactor framework-independent core library

Issue: #2240
What I did
Work in progress: first proof of concept for discussion

create @storybook/core library
move most common code into library
add some per-framework configuration for decorators

Still to-do:

[x] Update RN
[ ] Update tests/docs

How to test
yarn bootstrap --core

cd examples/cra-kitchen-sink
yarn storybook
cd ../vue-kitchen-sink
yarn storybook
cd ../angular-cli
yarn storybook
cd ../..
yarn test

Is this testable with jest or storyshots?
Does this need a new example in the kitchen sink apps?
Does this need an update to the documentation?
If your answer is yes to any of these, please make sure to include it in your PR.

Is the plan to move most of the server stuff over as well or should that be a separate package?

Some ideas on how we could improve this further:

[ ] Can we make ClientApi/ConfigApi self-bind its methods (ala React ES6 class components), so we don't have to repeat this stuff: https://github.com/storybooks/storybook/blob/shilman/refactor-core/app/react/src/client/preview/index.js#L34-L38

[ ] Can we factor out init.js? It seems identical between the 3 web-based frameworks

[ ] Can we factor out common parts of index.js from the 3 web frameworks as well? I feel like there are bugs involved in the query parsing stuff that would be good to fix just once ;)

@tmeasday Updated the binding per your suggestion.
I didn't factor out init.js in the first pass because it depends on the UI library and I didn't want to introduce that dependency into core. But agree that it's dupe code and should be factored out. Same with the query-string code. Open to suggestions on the API for this if you have ideas! Otherwise, will take a crack at this in the next day or two.
Thanks!

I was thinking just something like:
import { init } from '@storybook/core/web`;
init(); // <- we could pass args if ever needed to

// or even just
import from '@storybook/core/init-web`;

@tmeasday do you mean import '@storybook/core/init-web'?

@tmeasday do you mean import '@storybook/core/init-web'?

@Hypnosphi too fast off the mark there ;) Gotta give me time to fix my mistakes

@danielduan long-term will refactor everything, including preview, manager, and server. starting with preview since that's where most of the action is.

Codecov Report

Merging #2241 into release/3.3 will decrease coverage by 0.48%.
The diff coverage is 9.83%.

@@               Coverage Diff               @@
##           release/3.3    #2241      +/-   ##
===============================================
- Coverage        22.66%   22.18%   -0.49%
===============================================
  Files              346      338       -8
  Lines             6767     6587     -180
  Branches           887      856      -31
===============================================
- Hits              1534     1461      -73
+ Misses            4587     4483     -104
+ Partials           646      643       -3

Impacted Files
Coverage Δ

lib/components/src/highlight_button.js
0% <ø> (ø)
:arrow_up:

lib/core/src/client/preview/reducer.js
0% <ø> (ø)

lib/core/src/client/preview/actions.js
0% <ø> (ø)

...react-native/src/manager/components/PreviewHelp.js
0% <ø> (ø)
:arrow_up:

lib/core/src/client/preview/index.js
0% <0%> (ø)

app/react/src/client/preview/init.js
0% <0%> (ø)
:arrow_up:

app/vue/src/client/preview/index.js
0% <0%> (ø)
:arrow_up:

lib/core/src/client/preview/story_store.js
0% <0%> (ø)

app/vue/src/client/preview/init.js
0% <0%> (ø)
:arrow_up:

lib/core/src/client/index.js
0% <0%> (ø)

... and 53 more

Continue to review full report at Codecov.

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

@tmeasday refactored init per our slack chat. will pull out the query string handling when i try to deal with the manager code. short-term was able to remove a few fields from the context object.

Would this make it feasible for a framework author to integrate with Storybook?

@shilman -- what's up with this PR? I was looking at making some core changes but it feels weird to touch code before this PR has been merged. Are we waiting to merge it post 3.3?

Yes, we are @tmeasday, maybe you can base your work on this PR, or even on this branch?


Add coveralls

Fixes https://github.com/OpenZeppelin/zeppelin-solidity/issues/230

Changes Unknown when pulling 41a6f1cd84e28df4e5ed9610aaf7725dce78dae0 on maraoz:coveralls into ** on OpenZeppelin:master**.

It worked!!!

👍  Great!!!!

This is all based on your work @cgewecke, thanks! :)

Oh no thanks for putting it in @maraoz! It's an honor.

Love this! Kudos to @cgewecke. Now let's get that number as high as we can! 🚀


NOISSUE - Refactor provision tool

Signed-off-by: Ivan Milošević<EMAIL_ADDRESS>What does this do?

Use bulk SDK functions for generating Things and Channels for better performance of tool
Add prefix option

Did you document any new/modified functionality?
Yes, updated README

Codecov Report

Merging #1189 into master will increase coverage by 0.02%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1189      +/-   ##
==========================================
+ Coverage   77.29%   77.32%   +0.02%
==========================================
  Files         102      102
  Lines        6814     6814
==========================================
+ Hits         5267     5269       +2
+ Misses       1180     1178       -2
  Partials      367      367

Impacted Files
Coverage Δ

things/service.go
90.44% <0.00%> (+1.47%)
:arrow_up:

Continue to review full report at Codecov.

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


⚠ Bofrost.be has degraded performance

In 31561ce, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1483 ms

Resolved: Bofrost.be performance has improved in e0d909f.


Support more mathematical functions

Basic math

[ ] erf
[ ] erfc (complementary error function 1 - erf, useful for better accuracy)
[ ] beta function
[ ] zeta function?

Float

[ ] frac (fractional part)
[ ] int (integer part)
[ ] sgn
[ ] is_infinite
[ ] is_nan
[ ] …

Number theory, combinatorics

[ ] gcd
[ ] idiv (integer division)
[ ] binomial coefficient

Bitwise?

[ ] and, or, …
[ ] shl, shr

Simple statistics

[ ] geomean (see interesting observations regarding geomean here: http://typesatwork.imm.dtu.dk/material/TaW_Paper_TypesAtWork_Kennedy.pdf)
[ ] median
[ ] stddev

Statistics

[ ] binomial distribution etc

Numerics:

[ ] root-finding algorithms
[ ] numerical diff./integration, see #59

Cryptography

[ ] checksum / hash functions?

I'm interested in working on bit-wise operations

I'm interested in working on bit-wise operations

Sounds great. Note that we do not have proper integers at the moment. We basically just show floating point numbers as integers if they "look like one". I would definitely like to add support for different numeric types (floats, big/arbitrary-precision integers, potentially rationals, potentially complex numbers).
Just as a hint. We could still look into getting bit-wise operations working with what we have at the moment.


Create uniform translation table from live prog instead of initial prog.

The table is used on the live program, and the driver is free to create it
with different locations to the initial state program.

Im not sure if this is correct, so feel free to reject this. Im getting errors from Serialise_glProgramUniformVector when it sets a value onto the wrong uniform.

This is tricky. At minimum you'd need to change the patch so that after doing the SerialiseProgramUniforms call to generate the location translation table on the live program, you then need to copy everything into the initial program. Kind of the reverse of what happens in Apply_InitialState. Since we need the initial program to contain all of the mutable state at the point of the frame beginning, to be able to restore it every time in case that state is changed over the course of the frame to 'undo' that change. I think it's fine to generate the location translation table using the live program, since like you say that's where we actually use it. We could maybe avoid the copy by just splitting that out into a separate call maybe with an extra parameter to ForAllUniforms or something.
However in general the idea of a driver that reports different locations for identical-looking programs scares me :cry:. There are other places where I assume the programs are going to be equivalent and copy between them.
Before that though - are you able to investigate a bit deeper to find out why the locations have changed between the programs? Does the driver have a rand() or something unpredictable like that, or is there some subtle difference between the initial program and the live program, which we could try to correct?

Ive figured out why the locations changed between init and live programs - its because of that gl.glTransformFeedbackVaryings(initProg, ... eGL_INTERLEAVED_ATTRIBS) call that we added.
This happens both on NVidia as well as Mali.
We still need this fix for those other TF-only shaders, so shall I just modify this patch to copy all the mutable state back to the initial program like you said?

It feels a bit like playing whack-a-mole :disappointed: .
I think that's probably the best option then, this won't be the first fiddly workaround for GL and I'm sure it won't be the last.

Ive added the copy from the live back to the init prog.


multiple addHID instance problem

Hi all, I try to use the HID_test example from arduino-BLEPeripheral library for interfacing with my IPhone. The problem is that The program work properly if I instance only one addHid:
bleHID.addHID(bleMultimedia);
but when I try to add the keyboardHID:
bleHID.addHID(bleMultimedia);
bleHID.addHID(bleKeyboard);
The system does not work, it seem in loop in setup() function or the system in in continous reset.
If somebody had this kind of problem, please help me.
Thanks

@claudioarduino what board are you using? It could be a RAM limitation ....

@sandeepmistry I'm using the Arduino mega2560. I have the same problem also with the ancs example. When I try to add different remote attributes it doesn't work anymore. It works only with one addRemoteAttribute. How could it be possible?

@claudioarduino I do not know how many attributes do want to create. I had a similar problem, adding service characteristics. I found that there is a native softdevice call (e.g. sd_ble_gatts_characteristic_add)  in nRF51822.cpp, where the return value is not yet evaluated and have found that my application has reached a (preallocated) memory limit. At Nordic devzone, I have found that there is a limit with 1.5kB
So, the first test would be, if that is the case in your context.
@sandeepmistry .... I can do a PR to create a DEBUG message in that cases.
Here is the snippet to check on errors for adding characteristics:
uint32_t ret=sd_ble_gatts_characteristic_add(BLE_GATT_HANDLE_INVALID, &characteristicMetaData, &characteristicValueAttribute, &this->_localCharacteristicInfo[localCharacteristicIndex].handles);
if (ret!=NRF_SUCCESS) {
  Serial.print("sd_ble_gatts_characteristic_add ERROR: ");
  Serial.print(characteristic->uuid()); Serial.print(": ");
  switch (ret) {
  case NRF_ERROR_INVALID_ADDR:  Serial.println("INVALID_ADDR: Invalid pointer supplied.");	  break;
  case NRF_ERROR_INVALID_PARAM: Serial.println("INVALID_PARAM: Invalid parameter(s) supplied, service handle, Vendor Specific UUIDs, lengths, and permissions need to adhere to the constraints.");  break;
  case NRF_ERROR_INVALID_STATE: Serial.println("INVALID_STATE: Invalid state to perform operation, a service context is required.");  break;
  case NRF_ERROR_FORBIDDEN:     Serial.println("FORBIDDEN: Forbidden value supplied, certain UUIDs are reserved for the stack.");	  break;
  case NRF_ERROR_NO_MEM:        Serial.println("NO_MEM: Not enough memory to complete operation.");         break;
  case NRF_ERROR_DATA_SIZE:     Serial.println("DATA_SIZE: Invalid data size(s) supplied, attribute lengths are restricted by @ref BLE_GATTS_ATTR_LENS_MAX.");      break;
  }
}

... same has to be done for services an descriptors to be on the save side at development time.

@bojh I'm using the nrf8001. I  wanted to use both keyboard and multimedia, but it doesn't work. The native softdevice call  sd_ble_gatts_characteristic_add  I can use it also with the nrf8001?

@claudioarduino nrf8001 has a completely  different implementation, because it acts as a external chip and is realized to tell the configuration in sent messages. I'm not deep inside, but you should check if there is a chance to get, if the creation is accepted or an error has occurred. "Serial" debugging in the library source does help in such cases, to explore what happens really.

@bojh Thanks for your answers. I enabled the nrf8001 debug but when I try to add more than one attribute the system doesn't work and I'm not able to see the serial debugging. I think there must be something to change.

@claudioarduino I think you have to add your own Serial.println() commands to see what happens.

In the HID_test example, in void setup(),  if i put both
bleHID.addHID(bleKeyboard);
bleHID.addHID(bleMultimedia);
and then
bleHID.begin();
Serial.println(F("BLE HID"));
in the serial monitor it doesn't print "BLE HID" but stops working after bleHID.begin();.
Instead if I put only
bleHID.addHID(bleMultimedia);
it works and prints on the serial monitor "BLE HID".


Page start does not get reset

If a user searches for a exam in the student exam table while previously going to a different page the pageStart does not get reset.
This causes a problem only when the amount of pages created from the filtered search is less than the original search.

Fixed by https://github.com/shanearcaro/ceralis/compare/main...feature/review-exam


nao_meshes: 2.1.1-1 in 'iron/distribution.yaml' [bloom]

Increasing version of package(s) in repository nao_meshes to 2.1.1-1:

upstream repository: https://github.com/ros-naoqi/nao_meshes2.git
release repository: https://github.com/ros-naoqi/nao_meshes-release.git
distro file: iron/distribution.yaml
bloom version: 0.11.2
previous version for package: null

nao_meshes
* Download and install directly in bin dir
* Update status badges
* Contributors: Victor Paléologue

Thanks for fixing the merge conflict.
I'm going to merge this, but I wanted to strongly recommend that you consider releasing for rolling as well, which will make sure that you automatically will be attempted to be added to Jazzy. But to be added to rolling you need to ask for a ros2-gbp release repository to push to at https://github.com/ros2-gbp/ros2-gbp-github-org/issues/new/choose That is necessary for the automation to work.

FYI @victorpaleologue this package has been blocked from building on RHEL https://github.com/ros2/ros_buildfarm_config/pull/290


FAIL TO DEV BUILD: Incorrect dynamic import response during pre-build with esbuild

Describe the bug
Hello
When i started dev server i got some errors like "TypeError: CoinbaseWalletSDK is not a constructor" from packages.
I've looked in package where it's happened and saw that dynamic import provide an unexpected wrapper with default property for it and package don't expect it.
When i build for production it works well, so i think it's something with esbuild.

For example webpack and rollup build this think without additional wrapper and package expect the same.

Here piece of code from module with dynamic import
return Promise.resolve(import('@coinbase/wallet-sdk').then(function (m) {
                var _m$default;

                return (_m$default = m == null ? void 0 : m["default"]) != null ? _m$default : m;
  })).then(function (CoinbaseWalletSDK) {....}

Reproduction
https://vitejs-vite-yyulnd--5173.local.webcontainer.io
Steps to reproduce
No response
System Info
System:
    OS: macOS 12.4
    CPU: (8) x64 Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz
    Memory: 450.68 MB / 16.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 16.15.1 - ~/.nvm/versions/node/v16.15.1/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 8.11.0 - ~/.nvm/versions/node/v16.15.1/bin/npm
  Browsers:
    Chrome: 106.0.5249.103
    Safari: 15.5
  npmPackages:
    @vitejs/plugin-react: ^2.1.0 => 2.1.0
    vite: 3 => 3.1.7

Used Package Manager
yarn
Logs
No response
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

I think I'm experiencing this same behavior, when building the site statically there are no issues, however when running dev I get the error:
__vite_ssr_import_0__.EventEmitter2 is not a constructor
TypeError: __vite_ssr_import_0__.EventEmitter2 is not a constructor

The module being included imports eventemitter2 on the first line:
import { EventEmitter2 } from 'eventemitter2';

Duplicate of #2139

Closing as duplicate of https://github.com/vitejs/vite/issues/2139


how to create crud ?>

Laravel Version: #.#.#
PHP Version:
Laravel-admin: #.#.#

Description:
Haii how to create crud?
Steps To Reproduce:

Take a look:
Quick start


Use crypto.constants instead of constants module in NodeCryptoDriver

Removes a seemingly unnecessary import that would otherwise have to be polyfilled in non-node environments.
Node.js v18.6.0:
> crypto.constants.RSA_PKCS1_PSS_PADDING === constants.RSA_PKCS1_PSS_PADDING
true

thanks!


Deploy demo

Using new --apt-get-install option from https://github.com/simonw/datasette/issues/1110

This worked (after creating /tmp/all as a folder full of files to search):
datasette publish cloudrun \
    --static all:/tmp/all \
    --install datasette-ripgrep \
    --service datasette-ripgrep \
    --install datasette-ripgrep \
    --plugin-secret datasette-ripgrep path /app/all \
    --apt-get-install ripgrep

I grabbed all repos for simonw with github-to-sqlite repos simonw.db simonw and then did this:
for line in $(
  sqlite-utils simonw.db "select full_name from repos where full_name like 'simonw/datasette%'" \
  --csv --no-headers
)
do
  git clone git@github.com:$line --depth 1
done

I'm going to turn this into a manually triggered Actions workflow in this repo.

https://ripgrep.datasette.io/-/ripgrep?pattern=pytest

The new demo isn't quite working right, I think the checked out code isn't being uploaded to the /app/all directory as it should be.

Demo is back up, deployed via the workflow - and it survives a search for .* https://ripgrep.datasette.io/-/ripgrep?pattern=%2C*


TLS check: implement StartTLS protocol for postgres

What does this PR do?
This PR adds support for StartTLS implementation of postgresql protocol within TLS check.
Motivation
There are few protocols that works with StartTLS protocol. This is a way to handle both encrypted and unencrypted traffic on the same port. The client needs to send some protocol specific packets to switch the connection to encrypted format. Before that TLS handshake is not possible. Due to that TLS check is currently not able to detect certs on these protocols.
Additional Notes
Protocols implementing StartTLS: smtp, pop3, imap, ftp, xmpp, xmpp-server, irc, postgres, mysql, lmtp, nntp. sieve and ldap.
This PR adds support only for postgresql however with the general idea of extension.
Review checklist (to be filled by reviewers)

[x] Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
[x] PR title must be written as a CHANGELOG entry (see why)
[x] Files changes must correspond to the primary purpose of the PR as described in the title (small unrelated changes should have their own PR)
[x] PR must have changelog/ and integration/ labels attached

Appreciate documentation review. All applied.

@FlorentClarret 🤦 fixed

@FlorentClarret should I do anything more to have new version of check published? I don't see new release yet.

@FlorentClarret should I do anything more to have new version of check published? I don't see new release of TLS check yet.

@krogon we merged the release a few minutes ago https://github.com/DataDog/integrations-core/pull/12707/files#diff-ddf6d275575841a976817db77163265d173a78116a323f47d0ec5027d523c56a. It will be available soon :)


Workshop Tutorial

This contains the expanded, more detailed workshop tutorials presented at: http://mobilize.stanford.edu/events/snorkelworkshop2017/

@jason-fries Looks like n_epochs needs to be brought back to 10 in the intro tutorial?  When passing & you're all done ping me and I'll review!

@jason-fries seems like travis is randomly stalling out... maybe they switched to slower machines?  Not sure what's going on...

Yeah, definitely some Travis weirdness going on here. This is a direct rebase off of master -- the only new contribution is the workshop tutorial folder.


answer the question and implement  ResNet by using MNIST dataset

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


feat: update Argo CD and Rollouts configuration for release v1.11.0

What type of PR is this?

/kind enhancement

What does this PR do / why we need it:
Have you updated the necessary documentation?

[ ] Documentation update is required by this PR.
[ ] Documentation has been updated.

Which issue(s) this PR fixes:
Fixes #?
Test acceptance criteria:

[ ] Unit Test
[ ] E2E Test

How to test changes / Special notes to the reviewer:

/test v4.14-kuttl-sequential


nested iframes  scrollto problem

Hi,
first of all: thank you so much for your great iframe-resizer! :)
We try to include a webhelp in an iframe which has already iframes in it.
The resizing is triggered and calculated manually and everything works fine... except:
Within the iframe of our webhelp, we use anchors.
We decided to trigger the parentIFrame.scrollTo(x, y) after triggering parentIFrame.size(height);
Unfortunately, it seems we can't produce the wished result
what we did so far:
in our webhelp index, we included a function resize(), which calls
	if ('parentIFrame' in window) {
			parentIFrame.size(height);
			console.log("scroll!!!!!!!!!!!!!!!!!!!");
			console.log(top);
			parentIFrame.scrollTo(0,top);
		}

In our main window, the iFrameResize call is like below. we decided to remove inPageLinks, as the links are in the nested iframe within the index.htm
			iFrameResize({
				log:true,
				checkOrigin:false,
				minHeight:650,
				autoResize:false,
				scrollCallback: function (coords) {
					console.log("[OVERRIDE] overrode scrollCallback x: " + coords.x + " y: " + coords.y);
				}
				//inPageLinks:true
				});

The logfile says:
`[iFrameSizer][content] Trigger event: parentIFrame.size(4050)
iframeResizer.contentWindow.js:140 [iFrameSizer][content] Trigger event lock on
iframeResizer.contentWindow.js:140 [iFrameSizer][content] Sending message to host page (content:4050:1904:size)
iframeResizer.contentWindow.js:140 [iFrameSizer][content] Sending message to host page (content:1379.265625:0:scrollTo)
iframeResizer.js:129 [iFrameSizer][Host page: content] Received: [iFrameSizer]content:4050:1904:size
iframeResizer.js:129 [iFrameSizer][Host page: content] Checking height is in range 650-Infinity
iframeResizer.js:129 [iFrameSizer][Host page: content] Checking width is in range 0-Infinity
iframeResizer.js:129 [iFrameSizer][Host page: content] Requesting animation frame
iframeResizer.js:129 [iFrameSizer][Host page: content] Received: [iFrameSizer]content:1379.265625:0:scrollTo
iframeResizer.js:129 [iFrameSizer][Host page: content] Reposition requested from iFrame (offset x:0 y:0) - y:1379.265625
johwe_main.html:115 [OVERRIDE] overrode scrollCallback x: 0 y: 1379.265625
iframeResizer.js:129 [iFrameSizer][Host page: content] --
iframeResizer.js:129 [iFrameSizer][Host page: content] IFrame (content) height set to 4050px
iframeResizer.contentWindow.js:140 [iFrameSizer][content] Trigger event lock off
iframeResizer.contentWindow.js:140 [iFrameSizer][content] --`

is there any chance you can help us with this?
Thanks in advance!
Johanna

scrollCallback needs to return false if you want to stop iFrameResize scrolling the page.

Thanks for the fast reply.
We tried this as well, but in this case we scrolled only the first time using the parentiframe.scrollTo () method.
Or does this mean we can't use your scrollTo function and should give postmessage with a custom function a go ?

It means that if you do return false and it still doesn't work the issue is in your code.
If you rip scrollCallback out does it then work?

thanks again, I will check that today.


Fusion reactor output capping (3.8Mrf)

So, this issue is somewhat similar to https://github.com/turbodiesel4598/NuclearCraft/issues/161
When you change the output multiplier of the fusion reactor, you can easily get output of way more than 3.8Mrf, but since the buffer is only of that size, any "surplus" energy is lost...
Could you make the buffer configurable ? Or fix this issue in some way ?

Did you change the config option after you'd already placed the core?

I broke / replaced the core after changing the config.

Did you change the configs from the cfg file or the in-game mod options? If the former, you need to restart the game for Forge to reload them, them breaking and replacing should work. If the latter, that should have worked - which version of the mod are you using?

I'm using v2.16f. I changed the config through the .cfg on the client & server. I restarted both the client & server (twice), and also broke / replaced the fusion core.

Well, I restarted everything again and it's now working... Thanks for your help !

No prob!


Subscribing to Identic Topic Filters

@erylee  I don't know whether this can be related to #349, but I came across this while trying to find a workaround for it.
[MQTT-3.8.4-3] states that

A subscribe request which contains a Topic Filter that is identical to an existing Subscription’s Topic Filter completely replaces that existing Subscription with a new Subscription.

However, I think that this check kinda goes against this rule, for if the topic filter is the same the subscriptions are in fact not being replaced currently. What is your opinion on this?

Has been fixed in 1.x


Issue Proxying Rasa Parse

So I setup the docker instance and modified the rasanluendpoint to include my address where my Rasa instance is.
So then I sent the following command to the Rasa UI to parse hoping it would go to that system but I'm getting a auth error and not sure what the payload expects:
http://<IP_ADDRESS>:5001/api/v2/rasa/parse - the URL I used
params = {"q": question, "project": "chatbot"} - the payload and question is just a simple hello.
The error I get is:
{'message': 'No Authorization header.', 'success': False}
So what is the right format for this call?
Thanks

Hi @btotharye - could you check this: https://github.com/paschmann/rasa-ui/wiki/Using-Rasa-UI-as-Middleware and see if it solves your problem?

Sure also is what I'm doing the right process to have this interact with a external Rasa server I already have setup?  Sorry didn't know about that in the wiki I'll check it out.
Thanks

Yes, what you are doing is correct. Are you able to use the Rasa UI? Are you able to use the sidebar chat dialog to interact with the Rasa NLU backend successfully?

hey @btotharye  i know that this is another question, but, can you share the coe that you use to change the rasanluendpioint and how you run the dockerfile (i have been trying doing this too)

@rafaelariad I just basically modified https://github.com/paschmann/rasa-ui/blob/master/Dockerfile#L47 to include my rasa server address then did docker build -t rasa-ui . to build it and docker run -itd -p 5001:5001 rasa-ui to spin it up

@paschmann just to make sure should the payload look like this after I have my token:
url = "http://<IP_ADDRESS>:5001/api/v2/rasa/parse"
question = 'hello'
headers = {
    'Accept': 'application/json',
    'Authorization': 'Bearer {}'.format(token)
    }
params = {"q": question, "project": "chatbot"}
r = requests.get(url, headers=headers, params=params)

This is how I do my other api calls but I'm still getting cannot get /api/v2/rasa/parse as the error atm.

@btotharye - the method should be a POST, something like this:
`var request = require("request");
var options = { method: 'POST',
url: 'http://localhost:5001/api/v2/rasa/parse',
headers:
{ 'Postman-Token': 'fc7b3022-70c4-bdf8-5eff-425c0d7b55b1',
'Cache-Control': 'no-cache',
Authorization: 'Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE1MjA0Nzk3NjJ9.nSCzx1V-bS_S77G8uICZgFJub_5q4sukByiq6f_sgY4',
'Content-Type': 'application/json' },
body:
{ q: 'resturants in new york',
project: 'Dining Out',
model: 'model_20180307-131724' },
json: true };
request(options, function (error, response, body) {
if (error) throw new Error(error);
console.log(body);
});
`

Ok sorry getting closer what does this mean?
{'message': {'data': {'type': 'undefined'},
  'errorcode': 'EKEYTYPE',
  'message': 'The key argument has to be of type `string` or `number`. Found: `undefined`',
  'name': 'EKEYTYPE'},
 'status': 'error'}

I wasn't sure if I had to send it the actual model or if just the project is enough and in this case the project is the Project in Rasa UI or my project in my Rasa server?

I am not entirely sure to be honest - not a very descriptive error ...
You would need to send the project name on the Rasa Server.

interesting thats what I'm doing but its failing I tried inside postman and this is the response back:
{
    "status": "error",
    "message": {
        "expose": true,
        "statusCode": 400,
        "status": 400,
        "body": "{ q: 'hello',\r\nproject: 'Cisco Chatbot',\r\nmodel: 'chatbot*model_20180326-185644' },\r\njson: true };",
        "type": "entity.parse.failed"
    }
}

I'll have to keep messing around to figure out what is up

Could you check if you have a Agent in Rasa UI called "Cisco Chatbot"?

Lets also move the conversation here: https://gitter.im/rasa-ui/Lobby

I created it manually wasn't sure if that had to be there or not, I already have on my rasa server a model trained called chatbot which is what I'm trying to proxy this stuff to.  All I did so far was modify the https://github.com/paschmann/rasa-ui/blob/master/Dockerfile#L47 to be my ip address of my rasa server and spun it up, wasn't sure if there were other steps required or not.

@btotharye Rasa UI needs to have Agent information in its database. There is logging and webhook information tied to an agent that gets pulled for every request. There are multiple ways you can get to it

Either manually create an agent and start adding intents, entities, utterance details.
or by uploading an existing rasa_nlu domain data in JSON format

The later one would be more suitable in your case since you already have domain data from nlu. Also remember that Project name in NLU servers should be same as the Agent name in Rasa-ui.

I was working with @paschmann on this in gitter it actually appears to be an issue with https://github.com/paschmann/rasa-ui/blob/master/server/routes/middleware.js#L43 through 45 because once I commented that out everything started working the way it should with my remote NLU server I already have setup.
I'm gonna work on it a bit and see if I can see what is causing all the issues.

actually it wasn't a bug after all in those lines I just tested now and its working I think part of it was how I was issuing the output so for documentation purposes this is how I have it working:
url = "http://<IP_ADDRESS>:5001/api/v2/rasa/parse"
question = "hello"
payload = "q={}&project=chatbot".format(question)
headers = {
    'Content-Type': 'application/x-www-form-urlencoded',
    'Authorization': 'Bearer {}'.format(token)
    }
r = requests.post(url, data=payload, headers=headers)
response.json()

which now works properly and proxies to my Rasa server and gives me back the results:
{'entities': [{'confidence': 0.7423392842897176,
   'end': 5,
   'entity': 'serial',
   'extractor': 'ner_crf',
   'start': 0,
   'value': 'hello'}],
 'intent': {'confidence': 0.5612418049086964, 'name': 'greet'},
 'intent_ranking': [{'confidence': 0.5612418049086964, 'name': 'greet'},
  {'confidence': 0.12778262542564556, 'name': 'goodbye'},
  {'confidence': 0.12426149548459074, 'name': 'affirm'},
  {'confidence': 0.06779630706788278, 'name': 'cisco_serial'},
  {'confidence': 0.06100715539325644, 'name': 'about'},
  {'confidence': 0.05791061171992811, 'name': 'help'}],
 'text': 'hello'}

So sorry for the issue seems it was just how I was making the call and I didn't realize the project needed to be equal to my agent name.
Thanks again


Signature Issue in Docker image

Please make sure that this is a bug. As per our GitHub Policy, we only address code/doc bugs, performance issues, feature requests and build/installation issues on GitHub. tag:bug_template
System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): No
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Docker - Arch Linux 5.1.15-arch1
TensorFlow installed from (source or binary): Through docker
TensorFlow version (use command below): latest
Python version: 3
GPU model and memory: GTX 2080, 8 i think?

Describe the current behavior
When pulling the docker image tensorflow/tensorflow:latest-gpu-py3 and running apt-get update some signatures fail to fetch and thus the build fails immediately
Describe the expected behavior
Should update apt issues
Code to reproduce the issue
Provide a reproducible test case that is the bare minimum necessary to generate the problem.
This was tested 27/06/2019:
cd `mktemp -d`
echo "FROM tensorflow/tensorflow:latest-gpu-py3" > Dockerfile
echo "RUN apt-get update" >> Dockerfile
docker build .

Other info / logs
Include any logs or source code that would be helpful to diagnose the problem. If including tracebacks, please include the full traceback. Large logs and files should be attached.
Terminal log: https://pastebin.com/EYzFE5wP

I just tried this and did not get an error. Could it be an environment issue?
Ping @angersson for this thoughts
$ docker build .
Sending build context to Docker daemon 2.048 kB
Step 1/2 : FROM tensorflow/tensorflow:latest-gpu-py3
Trying to pull repository registry.access.redhat.com/tensorflow/tensorflow ...
 No issues there. I guess i'll have to look into the environment tomorrow.
Any idea what can cause these kinds of glitches?

Could be an issue upstream, on apt side.

@mrcpj1998 It's also possible that an old local version of latest-gpu-py3 could be causing this. Does anything change if you run docker pull tensorflow/tensorflow:latest-gpu-py3 first?
I also couldn't replicate the issue on my machine.

@mrcpj1998 Did you get a chance look @angersson's solution. Thanks!

After yesterday, did a pacman -Syu and docker pull, then built without cache. I haven't been able to reproduce this image. So definitely something weird, but this issue can be closed

@mrcpj1998 Will close issue now, Please update the issue when new information becomes available, and we will reopen the issue. Thanks!


Bugfix 5931: Scrollable content is not accessible on npm docs pages

Ref: https://github.com/github/accessibility-audits/issues/5931
Scrollable content (HTML <pre> elements) are not getting focussed while using keyboard tab key to navigate the pages.
Fix is to add the tabIndex property with value 0 for all those elements.

PR https://github.com/npm/documentation/pull/771 replaces this pr. I will address the review comment in the new pr.
Using branch on master instead of forking the repo


Add InferenceService resource

Short description:
Add InferenceService resource
More details:
InferenceServices are AI/ML models deployed on K8S/OpenShift to be used.
What this PR does / why we need it:
Which issue(s) this PR fixes:
Special notes for reviewer:
Bug:

/verified

/retest tox

/retest python-module-install

/verified

/lgtm


Allow authors without viewUnpublished permission to view cards they authored

Related to #232
Currently if the user may not viewUnpublished, we never download any unpublished cards. However, if the author doesn't have viewUnpublished permission, we should instead do an alt query of unpublished + author = me. (No need to do that for people with viewUnpublished permission, because they'll get all cards anyway).

This used to work before #188. Back then all cards were downloaded to client, and selectCards filtered out unpublished cards that weren't authored by the given user.

Related to #301

Also should download cards you are listed as an editor on


[Feature Request] programmatically set Goals

Detailed Description
Right now the only way to enter goals is via the admin UI.  Would it be possible to implement one of these programmatic way to set goals:

I can fire an event from my app with a custom goal that's not set up, and Plausible would simply create a new goal (GA does this)
we expand the Plausible API so developers can add or remove goals programmatically (probably some kind of oAuth / token would be needed for this)

Context
We are tracking sets of activities by state.  The client insists on having the state name in the goals, ie: Georgia Activity.
I'd have to manually add / remove goals for 50 states, and if I enter a typo in the state name, then events for that state would be lost forever.

thanks for the feedback @chulinguy! it's already possible to create and delete goals using our sites API. see https://plausible.io/docs/sites-api

I think it's not a common practice to use a PUT route such /api/v1/sites/goals as to do read and create, no ?

@metmarkosaric wait but we can only generate API tokens for the Stats API, and we need an API token for the site API to hit /api/v1/sites/goals ???

hi @chulinguy! please contact us to get a sites API key


Use Mantine

After working with Mantine over the last several months, I'd like to convert this hobby app from TailwindCSS to Mantine.

Done! https://github.com/gregrickaby/reddit-image-viewer/pull/385


Web Validator: Add Google Analytic tracking code

@ryon embed the following GA tracking code in the web interface:
<!-- Google tag (gtag.js) -->
<script async src="https://www.googletagmanager.com/gtag/js?id=G-NXV73Q9HBS"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());

  gtag('config', 'G-NXV73Q9HBS');
</script>

@themightychris what are we going to be able to track with this?

@isabelle-dr we don't have access to the Google Tags Manager account this links to, that's where most of the control is over what tracking happens. Presumably it's at least going to feed into a Google Analytics account that will record profiles of traffic opening the main page. We are not embedding any tracking code in the report.html so we won't see people entering those pages, but depending on how Google Tag Manager is configured it could be set up there to record clicking on the "report ready" button that links to it.

@KClough #1407 was merged but the analytics tag doesn't appear to be rendering if you view source on https://gtfs-validator.mobilitydata.org/—looks like the only thing that could stop it is the dev flag so investigate why that might be active still in prod

Closing as this was already initially merged in #1407 and #1458 covers looking into why it's not working in production


dmc ball_in_cup

#103

To reproduce this bug in dmc:
from dm_control import suite
import numpy as np

e0 = suite.load("ball_in_cup", "catch", {"random": 0})
e1 = suite.load("ball_in_cup", "catch", {"random": 1})
e2 = suite.load("ball_in_cup", "catch", {"random": 2})

print(e0.reset())
print(e1.reset())
print(e2.reset())
action = np.random.uniform(
    e0.action_spec().minimum,
    e0.action_spec().maximum,
    e0.action_spec().shape,
)
print("---step 1---")
print(e0.step(action))
print(e1.step(action))
print(e2.step(action))
print("---step 2---")
print(e0.step(action))
print(e1.step(action))
print(e2.step(action))


Unexport validate Workspace function 👼

Changes
They are not used elsewhere, so let's not export them.
/cc @bobcatfish
Signed-off-by: Vincent Demeester<EMAIL_ADDRESS>Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:

[ ] Includes tests (if functionality changed/added)
[ ] Includes docs (if user facing)
[x] Commit messages follow commit message best practices

See the contribution guide for more details.
Double check this list of stuff that's easy to miss:

If you are adding a new binary/image to the cmd dir, please update
the release Task to build and release this image.

Reviewer Notes
If API changes are included, additive changes must be approved by at least two OWNERS and backwards incompatible changes must be approved by more than 50% of the OWNERS, and they must first be added in a backwards compatible way.

/retest

/approve

/retest


CSS class sorting shouldn't sort if a razor tag is present.

The auto format that sorts class names works great, but if a razor tag is present, it sorts that to the front which can cause undesirable results. Here is a simple example:

Some content here

becomes this when the file is saved

Some content here

So if @Css was set to something like text-red, the final rendered html would have the dynamic css value sorted to the front which would then be overridden so the red would never be shown.

Some content here

I think the desired outcome would be to not have any of the class names sorted if there is a presence of any non-tailwind class names. This would make sure if there are any dynamically generated elements using any kind of css concatenation, they would just be ignored during formatting. If all css values are tailwind classes, then formatting should work as it does now.

Thanks for letting me know, fixed in 1.3.2. Rather than disabling class sort when a non-Tailwind class is present, I opted to just maintain the same order when Razor is detected within (i.e. if there is a razor token at the second class, it will sort to the second class; if it is last, it will sort last as well), as it is difficult to know if a class is Tailwind or not especially with customization. If you run into any issues, please let me know!

Fantastic. Thanks!


Support Jenkins Credentials parameters in TerraformEnvironmentStage

Allow credentials to be used in the TerraformEnvironmentStage
Need to think through this a bit:

UseCase: Global credentials like artifactory - easy
UseCase: environment-specific credentials - what do we do here?

See Issue #192
See Issue  #213

At the risk of being less DRY perhaps credentials and environment variables should be a first-class object you apply to a particular stage instance rather than a plugin?
It seems mapping various "things" into the environment of each stage is something that needs to be directly supported through a common interface on the stages themselves than being deferred to the plugin system.


A confusion about the Co-Scheduling of Gemini

Hi, I am trying to implement several graph algorithms for an experimental research and meet some problem.
Firstly, we define a concept named seperable.
A main computing function f is seperable iff f(A union B) = f(f(A),f(B)), e.g., sum, min, max are seperable, while min color, h-index are non-seperable.
In my understanding, the design of Co-Scheduling of Computation can well support the seperable type of algorithm, while it is not very suitable for non-seperable computing in just a process_edge.
Taking the graph coloring algorithm as an example, we have to maintain a temporal vertex_array to store the min color which have not been used in all neighbors for every vertex because a super step is divided into p mini-steps, and it will lead to a huge space overhead.
But if there's no mini-steps and the system just process vertices one by one, we only need to maintain such a temporal vertex_array for every machine rather than vertex, which may significantly reduce the space cost.
I am not sure whether my understanding is correct or have something overlooked. Looking forward to your views.
Thank you very much.

Hi, the given concept looks a bit confusing to me. Do you mean algorithms that are associative and commutative?
While I agree that classical graph coloring is unsuitable/inefficient to be implemented in Gemini, the major obstacle seems to be the BSP model which makes coordination in coarse-grained super-steps.
Regarding co-scheduling, there are no explicit barriers between mini-steps like those between super-steps. So mini-steps (or co-scheduling) should not be the main issue.


Added DarkForest Theme

All npm tests have been passed.

I'm confused... It passes the npm checks but fails the "Travis Cl" check.


Code optimization issues in generic binary search benchmark

This is notes from my investigation into the performance of the binary search code written by @scheglov
We are comparing three different implementation of the algorithm:

Generic version in Dart which searches for a value of type E in the given List<E> using configurable comparator and projection functions.
Specialized version in Dart which searches for an int value in the given Int64List.
Specialized version in Rust which searches for an i64 values in the given &[i64].

These implementations are benchmarked using the following loop:
final Int64List searchIn;  // sorted array of length 1024 * 1024 * 128
final Int64List searchFor; // array of length 1000 containing data to search

{  // Benchmark iteration
  for (var i = 0; i < searchFor.length; i++) {
    binarySearch(searchIn, searchFor[i]);
  }
}

Searching for a new value on each iteration allows us to minimise the effect of branch prediction and CPU caches on the benchmark results. We measure 3 different variants of this benchmark: with 1000, 100 and 10 different search values.
final searchForVariants = <int, Int64List>{
  for (var k in [1, 10, 100, 1000])
    k: Int64List.fromList(
      List.generate(searchFor.length, (i) => searchFor[i % k]),
    ),
};

Full code of the benchmarks is available here.
Initial benchmark results look like this (Dart is measured in AOT mode):

Implementation
Variant
μs/iter

Dart
GenericBinarySearch
1
423

Dart
GenericBinarySearch
10
440

Dart
GenericBinarySearch
100
548

Dart
GenericBinarySearch
1000
757

Dart
BinarySearch
1
60

Dart
BinarySearch
10
56

Dart
BinarySearch
100
58

Dart
BinarySearch
1000
460

Rust
BinarySearch
1
40

Rust
BinarySearch
10
47

Rust
BinarySearch
100
155

Rust
BinarySearch
1000
504

[!NOTE]
Notice how memory effects completely dominate this benchmark. In general the rest of the issue considers itself only with issues in the generated machine code caused by deficiencies in our Dart VM's backend. If you are interested in the topic of optimizing binary search for modern hardware consider reading Algorithms for Modern Hardware - 12.1 Binary Search (by Sergey Slotin), which gives a well rounded explanation of various issues one must tackle. For deeper exposure check  Array Layouts for Comparison-Based Searching (by Paul Khuong and Pat Morin). The following Paul's posts are also of interest:

Binary search eliminates branch mispredictions

Binary search is a pathological case for caches

Retrospective on binary search and comp{ress,ilat}ion

Understanding GenericBinarySearch slowness
Profiling with perf reveals the following hot code in GenericBinarySearch.binarySearch:
       │     GenericCheckBound:50(v135 T{_Smi}, v61) int64
  2.00 │       cmp  rbx,rax
       │     ↓ jae  28c
       │     v156 <- LoadIndexed(v7 T{_Int64List}, v61 T{int}) int64
 42.14 │       mov  r10,QWORD PTR [rsi+r9*8+0x17]
       │     v139 <- BoxInt64(v156 T{int}) T{int}
  0.08 │       mov  rax,r10
  1.95 │       add  rax,rax
  2.78 │     ↓ jno  165
       │     → call stub _iso_stub_AllocateMintSharedWithoutFPURegsStub
       │       mov  QWORD PTR [rax+0x7],r10
       │     MoveArgument(v25 T{_Closure}, SP+1)
  0.00 │165:   mov  r11,QWORD PTR [rbp-0x10]
  0.58 │       mov  QWORD PTR [rsp+0x8],r11
       │     MoveArgument(v139 T{int}, SP+0)
  1.83 │       mov  QWORD PTR [rsp],rax
       │     ParallelMove rax <- S-2
  0.49 │       mov  rax,QWORD PTR [rbp-0x10]
       │     v63 <- ClosureCall:56( closure=v25<0>, v25, v139 T{int})
  0.01 │       mov  r10,QWORD PTR [r15+0xc7]
  0.32 │       mov  rcx,QWORD PTR [rax+0x37]
  2.40 │     → call rcx

[!NOTE]
You can get IL comments automatically interspersed with your perf profiles if you use --dwarf-stack-traces --code-comments --write-code-comments-as-synthetic-source-to=/tmp/comments.txt when compiling your AOT snapshot.

This corresponds to the following code in Dart:
var element = sortedList[mid];
var comp = compare(keyOf(element), key);

This means that keyOf did not get inlined. Looking at IL dump (--print-flow-graph --print-flow-graph-filter=GenericBinarySearch_binarySearch) reveals the following code
 v22 <- Constant(#Closure: <Y0>(Y0) => Y0 from Function 'identity': static.)

 v23 <- LoadField(v22 . Closure.function {final}) T{Function}
 v24 <- LoadField(v22 . Closure.context {final}) T{Context}
 StaticCall:58( _boundsCheckForPartialInstantiation@9040228<0> v22, v18)

 v25 <- AllocateClosure:56(v23, v24) T{_Closure}

This code corresponds to partial instantiation of identity, which is generic function T Function<T>(T value) assigned to the parameter of type E Function(E element) keyOf.
We can observe the following problems:

[ ] v22 is a constant, but we fail to evaluate v22.function and v22.context which makes instantiation heavier than necessary.

This is due to missing code LoadFieldInstr::TryEvaluateLoad.

[ ] We don't eliminate _boundsCheckForPartialInstantiation (which is a heavy runtime call), even though the underlying closure does not actually have any type parameter bounds.

This is due to a missing canonicalisation rule. This can also be handled in front-end.

[ ] We don't inline binarySearch into the caller which would allow us to specialise the code for E == int

This is due to a bug in the inliner which does incorrect argument validity check, which always fails for generic functions.

[ ] (Minor) we don't seem to forward E == int in TFA, even though that's the only invocation and the type argument is fixed.

Fixing the first three problems and rerunning benchmark shows 1.6x improvement. The hot code changes to
       │     GenericCheckBound:50(v196 T{_Smi}, v64)
  0.23 │       cmp  rbx,rax
       │     ↓ jae  1ba
       │     v219 <- LoadIndexed(v3 T{_Int64List}, v64 T{int}) int64
 37.04 │       mov  rax,QWORD PTR [rdx+rcx*8+0x17]
       │     ParallelMove rdx <- rax
  0.07 │       mov  rdx,rax
       │     v200 <- BoxInt64(v219 T{int}) T{int}
  2.91 │       mov  rax,rdx
  3.32 │       add  rax,rax
  6.92 │     ↓ jno  e0
       │     → call stub _iso_stub_AllocateMintSharedWithoutFPURegsStub
       │       mov  QWORD PTR [rax+0x7],rdx
       │     v242 <- LoadClassId(v200 T{int}) int64
  0.02 │ e0:   test al,0x1
  0.37 │       mov  edx,0x3b
  3.88 │     ↓ je   ef
       │       mov  edx,DWORD PTR [rax-0x1]
       │       shr  edx,0xc
       │     MoveArgument(v200 T{int}, SP+1)
  0.09 │ ef:   mov  QWORD PTR [rsp+0x8],rax
       │     MoveArgument(v195 T{int}, SP+0)
  1.33 │       mov  QWORD PTR [rsp],r10
       │     ParallelMove rcx <- rdx, rax <- rcx
  0.19 │       mov  rax,rcx
  3.54 │       mov  rcx,rdx
       │     v156 <- DispatchTableCall( cid=v242 Comparable.compareTo<0>, v200 T{int}, v195 T{int}) int64
  0.05 │       mov  rax,QWORD PTR [r14+0x58]
  5.41 │     → call QWORD PTR [rax+rcx*8+0x480]

Now we successfully inline keyOf (which equals identity) and compare (which equals defaultCompare), but we fail to devirtualize int.compareTo even if we know that receiver is an integer value (v200 <- BoxInt64(v219)).
This happens because call specializer is unnecessary scared by invocations in classes, which are used as interfaces (i.e. int is actually an interface implemented by _IntegerImplementation). This currently completely disables devirtualization logic in AotCallSpecializer::VisitInstanceCall.

[ ] Fix AotCallSpecializer::VisitInstanceCall to apply devirtualization logic to calls through interfaces as well.

Fix this converts DispatchTableCall(Comparable.compareTo, ...) into a StaticCall( _IntegerImplementation.compareTo, ...) but this function is still not inlined. Looking at --trace-inlining output reveals the following about compareTo:
     Mark not inlinable
     Bailout: heuristics (default) with code size:  38, call sites: 3, inlining depth of callee: 0, const args: 0

This function is polymorphic with respect to its argument:
int compareTo(num other) {
  if (other is double) {
    // handle integer comparison with double
  }
  // handle integer comparison with integer
}

Inliner should be able to specialise it for the context which passes int as an argument, but it does not. If we look at IL we see that other is double became:
v199 <- UnboxedConstant(#61) int64
v169 <- Parameter(1) T{int}
v171 <- AssertAssignable:12(v169, v170, 'other', instantiator_type_args(v164), function_type_args(v164)) T{int}
v198 <- LoadClassId(v171) int64
Branch if EqualityCompare(v198 == v199) T{bool} goto (65, 77)

There are two problems here:

[ ]  AssertAssignable is not eliminated when constructing callee graph - this happens because inliner creates ParameterInstr with representation set to kNoRepresentation and Canonicalization avoids canonicalising any instructions which have unmatched input representations and gurded inputs. This is minor problem in context of this microbenchmark - but might mean that inliner is looking at larger than necessary callee graphs.
[ ] We don't eliminate EqualityCompare(LoadClassId(v171) == kDoubleCid) even though we know that it would never succeed.

Fixing this last problem using @rmacnak-google's recently added range analysis for LoadClassId makes inlining of _IntegerImplementation.compareTo succeed:
Success
  with reason need to count first, code size 8, call sites: 0

This improves benchmark runtime:
GenericBinarySearch.1(RunTime):<PHONE_NUMBER>4492113 us.
GenericBinarySearch.10(RunTime): 89.3001067995728 us.
GenericBinarySearch.100(RunTime):<PHONE_NUMBER>050598 us.
GenericBinarySearch.1000(RunTime): 503.161 us.

Looking at the hot code reveals that the inner (hot) loop is reasonably specialised, however there is one obvious redundancy. compareTo followed by the if chain became:
         :   v290 <- LoadIndexed(v3 T{_Int64List}, v64 T{int}) int64
   52.04 :   aff047: mov    rbx,QWORD PTR [rdx+r13*8+0x17]
         :   Branch if RelationalOp(<, v290, v288) goto (79, 80)
    0.87 :   aff04c: cmp    rbx,r10
    3.93 :   aff04f: jge    aff061 <GenericBinarySearch.run+0x8d>
         :   B79
         :   ParallelMove rbx <- C goto:134 B86
    3.48 :   aff055: mov    rbx,0xffffffffffffffff
    0.16 :   aff05c: jmp    aff076 <GenericBinarySearch.run+0xa2>
         :   B80
         :   Branch if RelationalOp(>, v290, v288) goto (81, 82)
    2.86 :   aff061: cmp    rbx,r10
    0.81 :   aff064: jle    aff074 <GenericBinarySearch.run+0xa0>
         :   B81
         :   ParallelMove rbx <- C goto:150 B86
    0.60 :   aff06a: mov    ebx,0x1
    2.72 :   aff06f: jmp    aff076 <GenericBinarySearch.run+0xa2>
         :   B82
         :   ParallelMove rbx <- C goto:156 B86
    0.98 :   aff074: xor    ebx,ebx
         :   B86
         :   v271 <- BoxInt64(v221) [-1, 1] T{_Smi}
    0.00 :   aff076: mov    rax,rbx
    2.97 :   aff079: add    rax,rax
         :   Branch if StrictCompare(===, v271, v5) goto (21, 22)
    1.22 :   aff07c: test   rax,rax
    0.14 :   aff07f: je     aff0a6 <GenericBinarySearch.run+0xd2>
         :   B21
         :   B22
         :   Branch if RelationalOp(<, v221, v287) goto (23, 24)
    0.18 :   aff085: cmp    rbx,0x0
    3.08 :   aff089: jge    aff09e <GenericBinarySearch.run+0xca>

Not only these branches did not get fused together, but we also introduced BoxInt64 + StrictCompare for  a.compareTo(b) == 0. There are few improvements that can be made to the code:

[ ] Avoid emitting StrictCompare if incoming argument is already unboxed.
[ ] Push integer comparisons upwards through a Phi with constant arguments. Existing BranchSimplifier pass can't handle this code because it only triggers on single-use Phis.

When looking at this code I have also noticed two other things:

[ ] We something have Redefinition(v) instructions left in the graph where compile type of v is clearly assignable to constrained type of the redefinition (e.g. constrained type is int? and the compile type of v is _Smi). Such redefinitions can be removed.
[ ] We don't fuse Branch Comparison(a, b) === true pattern into Branch Comparison(a, b) eagerly enough because at early stages of compilation Comparison(a, b) often has unmatched representation (e.g. requires unboxed integer values, but unboxing instructions are not yet inserted). This only makes sense when comparison is speculative.

After I have prototyped an improvement to BranchSimplify pass which could fuse a.compareTo(b) with subsequent if-then-else cascade I got the following result:
GenericBinarySearch.1(RunTime): 33.111468077175665 us.
GenericBinarySearch.10(RunTime): 43.18818799449605 us.
GenericBinarySearch.100(RunTime): 53.623792524149515 us.
GenericBinarySearch.1000(RunTime):<PHONE_NUMBER>2625697 us

This brings us to the same level as BinarySearch written in Dart. The hot loop now looks like this:
       │    B27
       │    CheckStackOverflow:108(stack=0, loop=1)
  0.35 │42:   cmp  rsp,QWORD PTR [r14+0x38]
       │    ↓ jbe  b6
       │    Branch if RelationalOp(<, v54, v55) T{bool} goto (40, 28)
  1.13 │4c:   cmp  r12,r9
       │    ↓ jge  9b
       │    B40
       │    ParallelMove r13 <- r9
  0.93 │      mov  r13,r9
       │    v62 <- BinaryInt64Op(- [tr], v55, v54) int64
 13.74 │      sub  r13,r12
       │    v63 <- ShiftInt64Op(>> [tr], v62, v238 T{_Smi}) int64
  0.10 │      sar  r13,1
       │    ParallelMove rbx <- r12
  1.11 │      mov  rbx,r12
       │    v64 <- BinaryInt64Op(+ [tr], v54, v63) int64
  0.91 │      add  rbx,r13
       │    ParallelMove rax <- rdi, rbx <- rbx, r13 <- rbx
 14.49 │      mov  rax,rdi
  0.19 │      mov  r13,rbx
       │    GenericCheckBound:50(v215 T{_Smi}, v64) int64
  1.27 │      cmp  rbx,rax
       │    ↓ jae  bf
       │    v239 <- LoadIndexed(v3 T{_Int64List}, v64 T{int}) int64
 33.00 │      mov  rbx,QWORD PTR [rdx+r13*8+0x17]
       │    Branch if RelationalOp(<, v239, v237 T{int}) goto (23, 80)
  3.10 │      cmp  rbx,r10
 11.10 │    ↓ jge  8d
       │    B23
       │    ParallelMove rax <- r13
  0.35 │      mov  rax,r13
       │    v73 <- BinaryInt64Op(+ [tr], v64 T{int}, v238 T{_Smi}) int64
  0.26 │      add  rax,0x1
       │    ParallelMove r12 <- rax goto:98 B25
  0.17 │      mov  r12,rax
  2.90 │    ↑ jmp  42
       │    B80
       │    Branch if RelationalOp(>, v239, v237 T{int}) goto (24, 21)
  0.98 │8d:   cmp  rbx,r10
  0.61 │    ↓ jle  9b
       │    B24
       │    ParallelMove r9 <- r13 goto:100 B25
  0.84 │      mov  r9,r13
 11.09 │    ↑ jmp  42

We could do a bit more here, e.g. fuse both RelationalOp comparisons into a single one, but at this point we are entering the territory of diminishing returns.
Other observations
GenericCheckBound issues
I noticed that the same version of binarySearch has different performance characteristics depending on how we measure its performance. Performance is worse if we write a measuring loop manually instead of using benchmark_harness:
final benchmark = BinarySearch(1, searchIn, searchForVariants[1]!);
for (var j = 0; j < 10; j++) {
  final sw = Stopwatch()..start();
  for (var i = 0; i < 10000; i++) {
    benchmark.run();
  }
  print(sw.elapsedMilliseconds);
}

Yields 64 us per benchmark.run invocation compared to 33 us reported by benchmark_harness.  This difference might be caused by loop alignment, but while analyzing this difference I have also noticed that GenericCheckBound has problematic fixed-register constraints on its inputs.
       │    ParallelMove rax <- S-4, rbx <- r8
  0.67 │      mov  rax,QWORD PTR [rbp-0x20]
 11.24 │      mov  rbx,r8
       │    GenericCheckBound:28(v173 T{_Smi}, v108) int64
  0.76 │      cmp  rbx,rax
       │    ↓ jae  328
       │    v202 <- LoadIndexed(v61, v108 T{int}) int64
 37.42 │      mov  rax,QWORD PTR [rdx+r8*8+0x17]
       │    Branch if EqualityCompare(v202 T{int} == v172 T{int}) T{bool} goto (35, 36)
  8.95 │      cmp  rax,rcx
  0.45 │    ↓ je   23f

Having fixed register constraints usually means:

Additional parallel moves emitted shuffling values around.

If the length value got spilled (e.g. there are multiple nested loops and length value got hoisted out), it will end up used directly from the spill slot even if register pressure inside the innermost loop allows to keep it in the register. This happens because rax <- P move created by the register allocator when resolving fixed-register input constraints does not require incoming value to be in a register - and register allocator is eager to resolve all such uses to use a spilled value if the value is already spilled and there are no requires register uses left.

[ ] Evaluate if GenericCheckBound could use non-fixed inputs

[ ] Evaluate if register allocator should not be too eager at using spill slot for R <- P moves when inside loops.

Block Scheduling
When looking at the generated code for non-generic binarySearch:
@pragma('vm:never-inline')
static int binarySearch(Int64List values, int value) {
  var min = 0;
  var max = values.length;
  while (min < max) {
    final mid = (min + max) >> 1;
    final element = values[mid];
    if (element == value) {
      return mid;
    } else if (element < value) {
      min = mid + 1;
    } else {
      max = mid;
    }
  }
  return -1;
}

We can notice a suboptimal code placement: terminal block (one corresponding to return mid) occurs in the middle of the hot loop instead of being emitted after the loop (see B3):
       │    B9
       │    CheckStackOverflow:74(stack=0, loop=1)
  0.52 │19:┌─→cmp  rsp,QWORD PTR [r14+0x38]
       │   │↓ jbe  80
       │   │Branch if RelationalOp(<, v6, v7) T{bool} goto (8, 10)
  0.00 │23:│  cmp  r8,rdi
       │   │↓ jge  74
       │   │B8
       │   │ParallelMove r9 <- r8
       │   │  mov  r9,r8
       │   │v14 <- BinaryInt64Op(+ [tr], v6, v7) int64
 12.28 │   │  add  r9,rdi
       │   │v15 <- ShiftInt64Op(>> [tr], v14, v40 T{_Smi}) int64
  0.58 │   │  sar  r9,1
       │   │ParallelMove rax <- rdx, rbx <- r9
  0.00 │   │  mov  rax,rdx
  0.99 │   │  mov  rbx,r9
       │   │GenericCheckBound:28(v34 T{_Smi}, v15) int64
 21.19 │   │  cmp  rbx,rax
       │   │↓ jae  89
       │   │v41 <- LoadIndexed(v2, v15 T{int}) int64
 26.32 │   │  mov  rbx,QWORD PTR [rcx+r9*8+0x17]
       │   │Branch if EqualityCompare(v41 T{int} == v3) T{bool} goto (3, 4)
  0.44 │   │  cmp  rbx,rsi
  8.93 │   │↓ jne  5a
       │   │B3
       │   │ParallelMove rax <- r9
       │   │  mov  rax,r9
       │   │Return:42(v15 T{int})
       │   │  mov  rsp,rbp
  0.00 │   │  pop  rbp
  0.51 │   │← ret
       │   │B4
       │   │Branch if RelationalOp(<, v41 T{int}, v3) T{bool} goto (5, 6)
       │5a:│  cmp  rbx,rsi
 14.38 │   │↓ jge  6f
       │   │B5
       │   │ParallelMove rbx <- r9
       │   │  mov  rbx,r9
       │   │v21 <- BinaryInt64Op(+ [tr], v15 T{int}, v40 T{_Smi}) int64
       │   │  add  rbx,0x1
       │   │ParallelMove r8 <- rbx, rdi <- rdi goto:64 B7
       │   │  mov  r8,rbx
       │   │↑ jmp  19
       │   │B6
       │   │ParallelMove r8 <- r8, rdi <- r9 goto:66 B7
       │6f:│  mov  rdi,r9
 12.68 │   └──jmp  19

This is due to very simplistic algorithm used by block_scheduler in AOT: it only attempts to move always throwing code to the end, but does not attempt to lay out loops tightly. The code is simply emitted in the reverse postorder.

[ ] Improve block scheduling in AOT to keep loop blocks together and not intersperse hot and cold code.

I have (half baked / prototype) fixes for some of these issues, but some of these require more thought. I will continue branching out issues from this one (for individual items), if you want to jump on fixing things - just let me know :)
/cc @alexmarkov @aam @mkustermann


Protect main branch from direct commits! >:c

There are several reasons why it is essential to protect the main branch from direct commits on GitHub:

Ensuring stability: The main branch is typically the default branch in a Git repository and should contain a stable project version. Direct commits to the main branch can introduce bugs or errors that can break the build or cause other issues.

Enforcing code review: By protecting the main branch, you can enforce a code review process where other collaborators review changes before merging. This helps ensure the code is high quality, meets coding standards, and is aligned with the project goals.

Maintaining a clear history: When changes are made to the main branch, it is crucial to maintain a clear history of the changes and why. By enforcing a pull request process, changes can be tracked more efficiently, and you can ensure that commit messages are informative and precise.

Preventing accidental or malicious changes: Protecting the main branch helps prevent accidental or malicious modifications that could significantly impact the project. For example, someone could accidentally delete essential files or make changes that are not in line with the project's goals.

Protecting the main branch helps ensure your project remains stable, high-quality, and aligned with your goals.

Main branch should only be able to have commits from contributors

Just checked with someone, non-contributors don't have write access. Appreciate the concern, though.