Allow Messaging Offline Players

Context: Our server needs a new messaging plugin seeing as the plugin we currently use https://www.spigotmc.org/resources/privatemessages-1-7-1-19.54026/. Is no longer being updated by its creator and doesn't work at least on the dev builds of paper 1.20.6. This one seems like a great match with a lot of these features being better than on the other plugin, however, you cannot message offline players using this plugin.
Feature: Adding the ability to message offline players and having the messages stored in a database with players being prompted whenever they next login that they have unread messages. Basically it ideally would work similarly to the plugin I attached.

This is a good idea! I will implement this mechanic in the next version of the plugin 1.3.0, it will be released today or tomorrow on Modrinth

Your idea has been implemented in the new version of the plugin 1.3.0!
You can already download from Modrinth
If you have new ideas/suggestions or find a bug, you can write to me on Discord or Issues
Thanks for your feedback!

Hi again, this is a great feature and it works almost perfectly! Could you however add an a config option to change the offline msg text/color?

I forgot to add the pattern for this message to the config. Apologize. Today I will fix it and post it on Modrinth

I fixed errors related to sending offline messages and setting up sound.
You can download the new version from Modrinth
Thanks for your feedback!


Bump version to 4.15.0

Add support for Google Analytics fieldsObject (PR #298)
anchor-buttons.js: normalise keyboard behaviour between buttons and links with a button role (PR #297)

👍


Does this pull request fix issue #24 ?

Does this pull request fix issue #24  ?
get cDNA
wget ftp://ftp.ensemblgenomes.org/pub/metazoa/release-46/fasta/caenorhabditis_elegans/cdna/Caenorhabditis_elegans.WBcel235.cdna.all.fa.gz

use seqtk to isolate first cDNA sequence
seqtk seq -l0 Caenorhabditis_elegans.WBcel235.cdna.all.fa.gz |paste - - |head -n1 |tr '\t' '\n' > test.fa

rust setup
rustup show

Default host: x86_64-unknown-linux-gnu
rustup home:  /nfs/scistore16/itgrp/jelbers/.rustup

installed toolchains
--------------------

stable-x86_64-unknown-linux-gnu (default)
nightly-x86_64-unknown-linux-gnu

active toolchain
----------------

stable-x86_64-unknown-linux-gnu (default)
rustc 1.60.0 (7737e0b5c 2022-04-04)

mudskipper installation
cd ~/git/
git clone https://github.com/jelber2/mudskipper
cd mudskipper
git show

commit 993320bdc4528615311c2250d68c3d7a91c2efc4 (HEAD -> main, origin/main, origin/HEAD)

cargo build --release

get GTF file and genome
wget ftp://ftp.ensemblgenomes.org/pub/metazoa/release-46/gtf/caenorhabditis_elegans/Caenorhabditis_elegans.WBcel235.46.gtf.gz
gunzip Caenorhabditis_elegans.WBcel235.46.gtf.gz
wget ftp://ftp.ensemblgenomes.org/pub/metazoa/release-46/fasta/caenorhabditis_elegans/dna/Caenorhabditis_elegans.WBcel235.dna.toplevel.fa.gz
gunzip Caenorhabditis_elegans.WBcel235.dna.toplevel.fa.gz

STAR index genome
module load seqtk/20210125
# make sequences upper case (remove soft-masking)
seqtk seq -CU Caenorhabditis_elegans.WBcel235.dna.toplevel.fa > Caenorhabditis_elegans.WBcel235.dna.toplevel_uppercase.fa

module load STAR/2.7.9a
mkdir -p Caenorhabditis_elegans.WBcel235.dna.toplevel_Ensembl46_STAR-2.7.9a_sjdbOverhang18
STAR \
--genomeSAindexNbases 12 \
--limitGenomeGenerateRAM<PHONE_NUMBER>00 \
--runThreadN 34 \
--sjdbOverhang 18 \
--runMode genomeGenerate \
--genomeDir Caenorhabditis_elegans.WBcel235.dna.toplevel_Ensembl46_STAR-2.7.9a_sjdbOverhang18 \
--genomeFastaFiles Caenorhabditis_elegans.WBcel235.dna.toplevel_uppercase.fa \
--sjdbGTFfile Caenorhabditis_elegans.WBcel235.46.gtf

simulate one 150-bp read pair on the transcript Y110A7A.10.1 with BBTools/BBMap's randomreads.sh version 38.82 (any recent version should be fine too)
module load bbtools/38.82
randomreads.sh ref=test.fa out1=test_R1.fq.gz out2=test_R2.fq.gz \
reads=1 simplenames=t illuminanames=t paired=t addslash=t seed=1

test_R1.fq.gz
@0/1
ACAATATTTGATGTGTGGAACTTCTAAGGAAAATGCTGCGAATGCTCTGATTCATGCTCGCTATCGGATCGCTCAACTTGACAAGGCTGTTGGATTGAAAAGAGAGCCACAAGATGGTATTTTCTTGATTCGAGGATCCTCTTCTCATGG
+
6=5559=;9=A<>A?=@A?CD@A=D@B@=@?DDDCB?ABD<D>CBA?BDB;@?AABD>@B@:C?A>=9:???@:D?8B?C>@:>@C;@=<??=@AA>?7?ABA6?@A?E@?;>B>B;7<<=7A9C:><=:<@;9C;:<;<5555;67:65

test_R2.fq.gz
@0/2
GTTTTGATAGCATCCGCGTGGGTTTCAAGACTGAAGTGAGAGTAATAGCGAACGAAGTCACTTATAGTTGTCAGGTAGACATTGCTGTGCTCGAATCCCCATCCTTCTTCGTTTTGTTCGATTAGACAATGTGAGACACGTTCTCCGTGA
+
44788<4<<;9>>??B@AB@<<>6?>?=BAAC5=;<@><;5@?C?BA8B;>?>>>=;A<C@?;?>BAA??C>CA?B96@6:@@=>:@<B<>@AB@<:><<>C;=C6@?=@9@7?==6<?<:9@A:?>7:=?A;8=A995<444;;44446

STAR mapping
module load STAR/2.7.9a
STAR  --runThreadN 32 \
--genomeDir auxData/Caenorhabditis_elegans.WBcel235.dna.toplevel_Ensembl46_STAR-2.7.9a_sjdbOverhang18 \
--readFilesCommand zcat \
--outSAMtype BAM SortedByCoordinate \
--outFileNamePrefix mapped/ref/RNAseq.MUT1.rep4 \
--outTmpDir TMP/ref_RNAseq.MUT1.rep4/TEMP/ \
--outReadsUnmapped Fastx \
--readFilesIn test_R1.fastq.gz test_R2.fastq.gz

mudskipper index GTF
export PATH="/nfs/scistore16/itgrp/jelbers/git/mudskipper/target/release:$PATH"
mudskipper index --gtf auxData/Caenorhabditis_elegans.WBcel235.46.gtf --dir-index auxData/mudskipper

[2022-05-12T06:02:52Z INFO  mudskipper] Mudskipper started...
[2022-05-12T06:02:52Z INFO  mudskipper::annotation] reading the gtf file and building the tree.
[2022-05-12T06:02:59Z INFO  mudskipper::annotation] building the tree
[2022-05-12T06:02:59Z INFO  mudskipper::annotation] Time to build the tree: 7.234329464s
[2022-05-12T06:02:59Z INFO  mudskipper::annotation] saving the GTF index
[2022-05-12T06:03:03Z INFO  mudskipper::annotation] Done with saving the GTF index
[2022-05-12T06:03:03Z INFO  mudskipper] Mudskipper finished.

run mudskipper bulk
mudskipper bulk --threads 32 --alignment Aligned.sortedByCoord.out.bam --index auxData/mudskipper --out alignments.bam
[2022-05-17T08:21:36Z INFO  mudskipper] Mudskipper started...
[2022-05-17T08:21:36Z INFO  mudskipper::annotation] Loading parsed GTF...
[2022-05-17T08:21:36Z INFO  mudskipper::bam] Number of reference sequences: 61451
[2022-05-17T08:21:36Z INFO  mudskipper::bam] thread count: 32 in total
[2022-05-17T08:21:36Z INFO  mudskipper::bam] thread count: 16 for reading
[2022-05-17T08:21:36Z INFO  mudskipper::bam] thread count: 16 for writing
[2022-05-17T08:21:37Z INFO  mudskipper] Mudskipper finished.

Aligned.sortedByCoord.out.bam (no header)
0	99	I	5108012	255	5M47N145M	=	5108277	596	GTGAAATTTGCCGCCCAAGTGAAACTTCTCCGAATCGTTGTTAAAGATGGAAAATGCGGATTCAATACAGATTCATTAACTCACGATTCTGTTGTCAGAGTAATTGAATTTCATCGAAATATTTCTCTCAATATTTTCAATGATGCACTT	8;9=898:;@>B9DAD89AB;C?EDEH<?B8AE9AD>?ACBC8>:@98=CFB?A;A=?9>:D;@BAAE>>@8A<>@=<AE=G>:C@@8;;8B=>>D@E?88=;CA89::;?ABD>=@8:><8=C=E?@888?@A8D<8C@9=8?888888	NH:i:1	HI:i:1	AS:i:298	nM:i:2	NM:i:1	MD:Z:99T50	jM:B:c,21	jI:B:i,5108017,5108063	MC:Z:47M181N103M
0	147	I	5108277	255	47M181N103M	=	5108012	-596	GGGGCCACTTCAGCAGCGTATGATTCTCAGTGCAAAAAATGATCATGATTGGAGAGAACGCTTGGAAATGGAAAATTTGAGAGCAGTACATTTGGCATTTGAGAGAGGAGCCAAGCTATATGATTCAGCTCATCAAGAAATGGAACGAGC<PHONE_NUMBER>7333383><37;3;398:8:79<785786=6<333?=77???93A;5A=B:79>48>A83;;3678<>@7A=:::=34337=??=;9BA<3=3;>83:=;>;5<9>9=?=;@9;;A=@;@=<B5:878:=8848:93533	NH:i:1	HI:i:1	AS:i:298	nM:i:2	NM:i:1	MD:Z:5A144	jM:B:c,21	jI:B:i,5108324,5108504	MC:Z:5M47N145M

alignments.bam (no header)
0	99	Y110A7A.10.1	180	255	150M	=	398	368	GTGAAATTTGCCGCCCAAGTGAAACTTCTCCGAATCGTTGTTAAAGATGGAAAATGCGGATTCAATACAGATTCATTAACTCACGATTCTGTTGTCAGAGTAATTGAATTTCATCGAAATATTTCTCTCAATATTTTCAATGATGCACTT	8;9=898:;@>B9DAD89AB;C?EDEH<?B8AE9AD>?ACBC8>:@98=CFB?A;A=?9>:D;@BAAE>>@8A<>@=<AE=G>:C@@8;;8B=>>D@E?88=;CA89::;?ABD>=@8:><8=C=E?@888?@A8D<8C@9=8?888888	NH:i:1	HI:i:1	AS:i:298	nM:i:2	NM:i:1	MD:Z:99T50	jM:B:c,21	jI:B:i,5108017,5108063	MC:Z:47M181N103M
0	147	Y110A7A.10.1	398	255	150M	=	180	-368	GGGGCCACTTCAGCAGCGTATGATTCTCAGTGCAAAAAATGATCATGATTGGAGAGAACGCTTGGAAATGGAAAATTTGAGAGCAGTACATTTGGCATTTGAGAGAGGAGCCAAGCTATATGATTCAGCTCATCAAGAAATGGAACGAGC<PHONE_NUMBER>7333383><37;3;398:8:79<785786=6<333?=77???93A;5A=B:79>48>A83;;3678<>@7A=:::=34337=??=;9BA<3=3;>83:=;>;5<9>9=?=;@9;;A=@;@=<B5:878:=8848:93533	NH:i:1	HI:i:1	AS:i:298	nM:i:2	NM:i:1	MD:Z:5A144	jM:B:c,21	jI:B:i,5108324,5108504	MC:Z:5M47N145M
0	99	Y110A7A.10.2	170	255	150M	=	388	368	GTGAAATTTGCCGCCCAAGTGAAACTTCTCCGAATCGTTGTTAAAGATGGAAAATGCGGATTCAATACAGATTCATTAACTCACGATTCTGTTGTCAGAGTAATTGAATTTCATCGAAATATTTCTCTCAATATTTTCAATGATGCACTT	8;9=898:;@>B9DAD89AB;C?EDEH<?B8AE9AD>?ACBC8>:@98=CFB?A;A=?9>:D;@BAAE>>@8A<>@=<AE=G>:C@@8;;8B=>>D@E?88=;CA89::;?ABD>=@8:><8=C=E?@888?@A8D<8C@9=8?888888	NH:i:1	HI:i:1	AS:i:298	nM:i:2	NM:i:1	MD:Z:99T50	jM:B:c,21	jI:B:i,5108017,5108063	MC:Z:47M181N103M
0	147	Y110A7A.10.2	388	255	150M	=	170	-368	GGGGCCACTTCAGCAGCGTATGATTCTCAGTGCAAAAAATGATCATGATTGGAGAGAACGCTTGGAAATGGAAAATTTGAGAGCAGTACATTTGGCATTTGAGAGAGGAGCCAAGCTATATGATTCAGCTCATCAAGAAATGGAACGAGC<PHONE_NUMBER>7333383><37;3;398:8:79<785786=6<333?=77???93A;5A=B:79>48>A83;;3678<>@7A=:::=34337=??=;9BA<3=3;>83:=;>;5<9>9=?=;@9;;A=@;@=<B5:878:=8848:93533	NH:i:1	HI:i:1	AS:i:298	nM:i:2	NM:i:1	MD:Z:5A144	jM:B:c,21	jI:B:i,5108324,5108504	MC:Z:5M47N145M

On second thought, perhaps my quick fix my only work with when 100% reads are paired and 100% mates are mapped?

Thanks for this test case and PR @jelber2! @gmarcais, can we take a look at this?

On second thought, perhaps my quick fix may only work with when 100% reads are paired and 100% mates are mapped? I have not tested how it works when one mate is unmapped. EDIT if one mate is unmapped, the mapped mate is not transferred when using mudskipper bulk

I am pretty sure this is not just because of your fix but rather a combination with the rest of the mudskipper bulk code. Your solution works only if both mates are present in a name sorted SAM/BAM. If the SAM/BAM file is not name sorted mudskipper bulk treats all the reads as sort of pseudo-single-end reads - it duplicates each of the reads with the only difference being the TLEN sign (switches + for - and vice versa).
For example (modified from tests/NC_007114.7_12427.sam):

Paired, mapped, name sorted = works fine (output not copied)

J00153:160:HMTNMBBXX:6:1104:18893:12427	419	NC_007114.7	24289610	3	149M	=	24289724	264	GGCAGTGGTCTCTGTCCTGGATCATGTAGAGTGTCGTTGTCAACCTGCTCCTCGCCCCGCACATCGCCGAAAGTCATCCAGCCAGAAACTAGACGCACGTGATCGTTCAGAGAAAAGTCGACCCAAAGAGGATCTCCATCGCAGGGATG	AAFFFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJJFJJJJJFJJJJJJJJJJJFFJJJFJJJJJJJJJFAFAFJJJJJJJJJA<A	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12427	339	NC_007114.7	24289724	3	150M	=	24289610	-264	AAGTCGACCCAAAGAGGATCTCCATCGCAGGGATGAACTCAAACACAACCAGAGGCTAAACCTGGAGGACCTGCTCAGCCACAGCTGGCTGCCCCAAGACAGGTTCTCTGAATCACCAGACACTGTCCATTTTGGCCGCGATGCCTGGAC	FAFJJFAJFJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJFJJJJJJJJJJJJJFJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJFFFAA	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12428	419	NC_007114.7	24289610	3	149M	=	24289724	264	GGCAGTGGTCTCTGTCCTGGATCATGTAGAGTGTCGTTGTCAACCTGCTCCTCGCCCCGCACATCGCCGAAAGTCATCCAGCCAGAAACTAGACGCACGTGATCGTTCAGAGAAAAGTCGACCCAAAGAGGATCTCCATCGCAGGGATG	AAFFFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJJFJJJJJFJJJJJJJJJJJFFJJJFJJJJJJJJJFAFAFJJJJJJJJJA<A	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12428	339	NC_007114.7	24289724	3	150M	=	24289610	-264	AAGTCGACCCAAAGAGGATCTCCATCGCAGGGATGAACTCAAACACAACCAGAGGCTAAACCTGGAGGACCTGCTCAGCCACAGCTGGCTGCCCCAAGACAGGTTCTCTGAATCACCAGACACTGTCCATTTTGGCCGCGATGCCTGGAC	FAFJJFAJFJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJFJJJJJJJJJJJJJFJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJFFFAA	NH:i:2	HI:i:2	AS:i:297	nM:i:0

Paired, mapped, not name sorted (but coordinate sorted) = doesn't work:

J00153:160:HMTNMBBXX:6:1104:18893:12427	419	NC_007114.7	24289610	3	149M	=	24289724	264	GGCAGTGGTCTCTGTCCTGGATCATGTAGAGTGTCGTTGTCAACCTGCTCCTCGCCCCGCACATCGCCGAAAGTCATCCAGCCAGAAACTAGACGCACGTGATCGTTCAGAGAAAAGTCGACCCAAAGAGGATCTCCATCGCAGGGATG	AAFFFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJJFJJJJJFJJJJJJJJJJJFFJJJFJJJJJJJJJFAFAFJJJJJJJJJA<A	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12428	419	NC_007114.7	24289610	3	149M	=	24289724	264	GGCAGTGGTCTCTGTCCTGGATCATGTAGAGTGTCGTTGTCAACCTGCTCCTCGCCCCGCACATCGCCGAAAGTCATCCAGCCAGAAACTAGACGCACGTGATCGTTCAGAGAAAAGTCGACCCAAAGAGGATCTCCATCGCAGGGATG	AAFFFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJJFJJJJJFJJJJJJJJJJJFFJJJFJJJJJJJJJFAFAFJJJJJJJJJA<A	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12427	339	NC_007114.7	24289724	3	150M	=	24289610	-264	AAGTCGACCCAAAGAGGATCTCCATCGCAGGGATGAACTCAAACACAACCAGAGGCTAAACCTGGAGGACCTGCTCAGCCACAGCTGGCTGCCCCAAGACAGGTTCTCTGAATCACCAGACACTGTCCATTTTGGCCGCGATGCCTGGAC	FAFJJFAJFJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJFJJJJJJJJJJJJJFJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJFFFAA	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12428	339	NC_007114.7	24289724	3	150M	=	24289610	-264	AAGTCGACCCAAAGAGGATCTCCATCGCAGGGATGAACTCAAACACAACCAGAGGCTAAACCTGGAGGACCTGCTCAGCCACAGCTGGCTGCCCCAAGACAGGTTCTCTGAATCACCAGACACTGTCCATTTTGGCCGCGATGCCTGGAC	FAFJJFAJFJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJFJJJJJJJJJJJJJFJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJFFFAA	NH:i:2	HI:i:2	AS:i:297	nM:i:0

results in:
J00153:160:HMTNMBBXX:6:1104:18893:12427	419	XM_021473592.1	1294	3	149M	=	1294	149	GGCAGTGGTCTCTGTCCTGGATCATGTAGAGTGTCGTTGTCAACCTGCTCCTCGCCCCGCACATCGCCGAAAGTCATCCAGCCAGAAACTAGACGCACGTGATCGTTCAGAGAAAAGTCGACCCAAAGAGGATCTCCATCGCAGGGATG	AAFFFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJJFJJJJJFJJJJJJJJJJJFFJJJFJJJJJJJJJFAFAFJJJJJJJJJA<A	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12427	419	XM_021473592.1	1294	3	149M	=	1294	-149	GGCAGTGGTCTCTGTCCTGGATCATGTAGAGTGTCGTTGTCAACCTGCTCCTCGCCCCGCACATCGCCGAAAGTCATCCAGCCAGAAACTAGACGCACGTGATCGTTCAGAGAAAAGTCGACCCAAAGAGGATCTCCATCGCAGGGATG	AAFFFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJJFJJJJJFJJJJJJJJJJJFFJJJFJJJJJJJJJFAFAFJJJJJJJJJA<A	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12428	419	XM_021473592.1	1294	3	149M	=	1294	149	GGCAGTGGTCTCTGTCCTGGATCATGTAGAGTGTCGTTGTCAACCTGCTCCTCGCCCCGCACATCGCCGAAAGTCATCCAGCCAGAAACTAGACGCACGTGATCGTTCAGAGAAAAGTCGACCCAAAGAGGATCTCCATCGCAGGGATG	AAFFFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJJFJJJJJFJJJJJJJJJJJFFJJJFJJJJJJJJJFAFAFJJJJJJJJJA<A	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12428	419	XM_021473592.1	1294	3	149M	=	1294	-149	GGCAGTGGTCTCTGTCCTGGATCATGTAGAGTGTCGTTGTCAACCTGCTCCTCGCCCCGCACATCGCCGAAAGTCATCCAGCCAGAAACTAGACGCACGTGATCGTTCAGAGAAAAGTCGACCCAAAGAGGATCTCCATCGCAGGGATG	AAFFFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJJFJJJJJFJJJJJJJJJJJFFJJJFJJJJJJJJJFAFAFJJJJJJJJJA<A	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12427	339	XM_021473592.1	1408	3	150M	=	1408	150	AAGTCGACCCAAAGAGGATCTCCATCGCAGGGATGAACTCAAACACAACCAGAGGCTAAACCTGGAGGACCTGCTCAGCCACAGCTGGCTGCCCCAAGACAGGTTCTCTGAATCACCAGACACTGTCCATTTTGGCCGCGATGCCTGGAC	FAFJJFAJFJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJFJJJJJJJJJJJJJFJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJFFFAA	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12427	339	XM_021473592.1	1408	3	150M	=	1408	-150	AAGTCGACCCAAAGAGGATCTCCATCGCAGGGATGAACTCAAACACAACCAGAGGCTAAACCTGGAGGACCTGCTCAGCCACAGCTGGCTGCCCCAAGACAGGTTCTCTGAATCACCAGACACTGTCCATTTTGGCCGCGATGCCTGGAC	FAFJJFAJFJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJFJJJJJJJJJJJJJFJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJFFFAA	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12428	339	XM_021473592.1	1408	3	150M	=	1408	150	AAGTCGACCCAAAGAGGATCTCCATCGCAGGGATGAACTCAAACACAACCAGAGGCTAAACCTGGAGGACCTGCTCAGCCACAGCTGGCTGCCCCAAGACAGGTTCTCTGAATCACCAGACACTGTCCATTTTGGCCGCGATGCCTGGAC	FAFJJFAJFJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJFJJJJJJJJJJJJJFJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJFFFAA	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12428	339	XM_021473592.1	1408	3	150M	=	1408	-150	AAGTCGACCCAAAGAGGATCTCCATCGCAGGGATGAACTCAAACACAACCAGAGGCTAAACCTGGAGGACCTGCTCAGCCACAGCTGGCTGCCCCAAGACAGGTTCTCTGAATCACCAGACACTGTCCATTTTGGCCGCGATGCCTGGAC	FAFJJFAJFJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJFJJJJJJJJJJJJJFJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJFFFAA	NH:i:2	HI:i:2	AS:i:297	nM:i:0

One pair is mapped and both mates are present, the other pair is missing a mate completely (due to post-alignment filtering) but SAM/BAM is name sorted = the complete pair is correctly converted, the one-mate-pair read gets copied again with only the TLEN sign changed:

J00153:160:HMTNMBBXX:6:1104:18893:12428	419	NC_007114.7	24289610	3	149M	=	24289724	264	GGCAGTGGTCTCTGTCCTGGATCATGTAGAGTGTCGTTGTCAACCTGCTCCTCGCCCCGCACATCGCCGAAAGTCATCCAGCCAGAAACTAGACGCACGTGATCGTTCAGAGAAAAGTCGACCCAAAGAGGATCTCCATCGCAGGGATG	AAFFFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJJFJJJJJFJJJJJJJJJJJFFJJJFJJJJJJJJJFAFAFJJJJJJJJJA<A	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12428	339	NC_007114.7	24289724	3	150M	=	24289610	-264	AAGTCGACCCAAAGAGGATCTCCATCGCAGGGATGAACTCAAACACAACCAGAGGCTAAACCTGGAGGACCTGCTCAGCCACAGCTGGCTGCCCCAAGACAGGTTCTCTGAATCACCAGACACTGTCCATTTTGGCCGCGATGCCTGGAC	FAFJJFAJFJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJFJJJJJJJJJJJJJFJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJFFFAA	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12427	339	NC_007114.7	24289724	3	150M	=	24289610	-264	AAGTCGACCCAAAGAGGATCTCCATCGCAGGGATGAACTCAAACACAACCAGAGGCTAAACCTGGAGGACCTGCTCAGCCACAGCTGGCTGCCCCAAGACAGGTTCTCTGAATCACCAGACACTGTCCATTTTGGCCGCGATGCCTGGAC	FAFJJFAJFJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJFJJJJJJJJJJJJJFJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJFFFAA	NH:i:2	HI:i:2	AS:i:297	nM:i:0

results in:
J00153:160:HMTNMBBXX:6:1104:18893:12428	419	XM_021473592.1	1294	3	149M	=	1408	264	GGCAGTGGTCTCTGTCCTGGATCATGTAGAGTGTCGTTGTCAACCTGCTCCTCGCCCCGCACATCGCCGAAAGTCATCCAGCCAGAAACTAGACGCACGTGATCGTTCAGAGAAAAGTCGACCCAAAGAGGATCTCCATCGCAGGGATG	AAFFFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJJFJJJJJFJJJJJJJJJJJFFJJJFJJJJJJJJJFAFAFJJJJJJJJJA<A	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12428	339	XM_021473592.1	1408	3	150M	=	1294	-264	AAGTCGACCCAAAGAGGATCTCCATCGCAGGGATGAACTCAAACACAACCAGAGGCTAAACCTGGAGGACCTGCTCAGCCACAGCTGGCTGCCCCAAGACAGGTTCTCTGAATCACCAGACACTGTCCATTTTGGCCGCGATGCCTGGAC	FAFJJFAJFJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJFJJJJJJJJJJJJJFJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJFFFAA	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12427	339	XM_021473592.1	1408	3	150M	=	1408	150	AAGTCGACCCAAAGAGGATCTCCATCGCAGGGATGAACTCAAACACAACCAGAGGCTAAACCTGGAGGACCTGCTCAGCCACAGCTGGCTGCCCCAAGACAGGTTCTCTGAATCACCAGACACTGTCCATTTTGGCCGCGATGCCTGGAC	FAFJJFAJFJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJFJJJJJJJJJJJJJFJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJFFFAA	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12427	339	XM_021473592.1	1408	3	150M	=	1408	-150	AAGTCGACCCAAAGAGGATCTCCATCGCAGGGATGAACTCAAACACAACCAGAGGCTAAACCTGGAGGACCTGCTCAGCCACAGCTGGCTGCCCCAAGACAGGTTCTCTGAATCACCAGACACTGTCCATTTTGGCCGCGATGCCTGGAC	FAFJJFAJFJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJFJJJJJJJJJJJJJFJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJFFFAA	NH:i:2	HI:i:2	AS:i:297	nM:i:0

Dear Jan, thanks for catching this. I can see these trends in my 'real' data too. Using this pull request as is.

Note that I added your test examples in tests/

Paired, mapped, name sorted
target/release/mudskipper bulk --alignment tests/NC_007114.7_12427_1.sam --gtf tests/NC_007114.7_12427.gtf --out test1.bam

cat <(grep -v "^@" tests/NC_007114.7_12427_1.sam) <(echo) <(samtools view test1.bam)

J00153:160:HMTNMBBXX:6:1104:18893:12427	419	NC_007114.7	24289610	3	149M	=	24289724	264	GGCAGTGGTCTCTGTCCTGGATCATGTAGAGTGTCGTTGTCAACCTGCTCCTCGCCCCGCACATCGCCGAAAGTCATCCAGCCAGAAACTAGACGCACGTGATCGTTCAGAGAAAAGTCGACCCAAAGAGGATCTCCATCGCAGGGATG	AAFFFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJJFJJJJJFJJJJJJJJJJJFFJJJFJJJJJJJJJFAFAFJJJJJJJJJA<A	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12427	339	NC_007114.7	24289724	3	150M	=	24289610	-264	AAGTCGACCCAAAGAGGATCTCCATCGCAGGGATGAACTCAAACACAACCAGAGGCTAAACCTGGAGGACCTGCTCAGCCACAGCTGGCTGCCCCAAGACAGGTTCTCTGAATCACCAGACACTGTCCATTTTGGCCGCGATGCCTGGAC	FAFJJFAJFJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJFJJJJJJJJJJJJJFJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJFFFAA	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12428	419	NC_007114.7	24289610	3	149M	=	24289724	264	GGCAGTGGTCTCTGTCCTGGATCATGTAGAGTGTCGTTGTCAACCTGCTCCTCGCCCCGCACATCGCCGAAAGTCATCCAGCCAGAAACTAGACGCACGTGATCGTTCAGAGAAAAGTCGACCCAAAGAGGATCTCCATCGCAGGGATG	AAFFFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJJFJJJJJFJJJJJJJJJJJFFJJJFJJJJJJJJJFAFAFJJJJJJJJJA<A	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12428	339	NC_007114.7	24289724	3	150M	=	24289610	-264	AAGTCGACCCAAAGAGGATCTCCATCGCAGGGATGAACTCAAACACAACCAGAGGCTAAACCTGGAGGACCTGCTCAGCCACAGCTGGCTGCCCCAAGACAGGTTCTCTGAATCACCAGACACTGTCCATTTTGGCCGCGATGCCTGGAC	FAFJJFAJFJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJFJJJJJJJJJJJJJFJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJFFFAA	NH:i:2	HI:i:2	AS:i:297	nM:i:0

J00153:160:HMTNMBBXX:6:1104:18893:12427	419	XM_021473592.1	1294	3	149M	=	1408	264	GGCAGTGGTCTCTGTCCTGGATCATGTAGAGTGTCGTTGTCAACCTGCTCCTCGCCCCGCACATCGCCGAAAGTCATCCAGCCAGAAACTAGACGCACGTGATCGTTCAGAGAAAAGTCGACCCAAAGAGGATCTCCATCGCAGGGATG	AAFFFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJJFJJJJJFJJJJJJJJJJJFFJJJFJJJJJJJJJFAFAFJJJJJJJJJA<A	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12427	339	XM_021473592.1	1408	3	150M	=	1294	-264	AAGTCGACCCAAAGAGGATCTCCATCGCAGGGATGAACTCAAACACAACCAGAGGCTAAACCTGGAGGACCTGCTCAGCCACAGCTGGCTGCCCCAAGACAGGTTCTCTGAATCACCAGACACTGTCCATTTTGGCCGCGATGCCTGGAC	FAFJJFAJFJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJFJJJJJJJJJJJJJFJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJFFFAA	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12428	419	XM_021473592.1	1294	3	149M	=	1408	264	GGCAGTGGTCTCTGTCCTGGATCATGTAGAGTGTCGTTGTCAACCTGCTCCTCGCCCCGCACATCGCCGAAAGTCATCCAGCCAGAAACTAGACGCACGTGATCGTTCAGAGAAAAGTCGACCCAAAGAGGATCTCCATCGCAGGGATG	AAFFFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJJFJJJJJFJJJJJJJJJJJFFJJJFJJJJJJJJJFAFAFJJJJJJJJJA<A	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12428	339	XM_021473592.1	1408	3	150M	=	1294	-264	AAGTCGACCCAAAGAGGATCTCCATCGCAGGGATGAACTCAAACACAACCAGAGGCTAAACCTGGAGGACCTGCTCAGCCACAGCTGGCTGCCCCAAGACAGGTTCTCTGAATCACCAGACACTGTCCATTTTGGCCGCGATGCCTGGAC	FAFJJFAJFJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJFJJJJJJJJJJJJJFJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJFFFAA	NH:i:2	HI:i:2	AS:i:297	nM:i:0

Paired, mapped, cooridnate has incorrect coordinates
target/release/mudskipper bulk --alignment tests/NC_007114.7_12427_2.sam --gtf tests/NC_007114.7_12427.gtf --out test2.bam

cat <(grep -v "^@" tests/NC_007114.7_12427_2.sam) <(echo) <(samtools view test2.bam)

J00153:160:HMTNMBBXX:6:1104:18893:12427	419	NC_007114.7	24289610	3	149M	=	24289724	264	GGCAGTGGTCTCTGTCCTGGATCATGTAGAGTGTCGTTGTCAACCTGCTCCTCGCCCCGCACATCGCCGAAAGTCATCCAGCCAGAAACTAGACGCACGTGATCGTTCAGAGAAAAGTCGACCCAAAGAGGATCTCCATCGCAGGGATG	AAFFFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJJFJJJJJFJJJJJJJJJJJFFJJJFJJJJJJJJJFAFAFJJJJJJJJJA<A	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12428	419	NC_007114.7	24289610	3	149M	=	24289724	264	GGCAGTGGTCTCTGTCCTGGATCATGTAGAGTGTCGTTGTCAACCTGCTCCTCGCCCCGCACATCGCCGAAAGTCATCCAGCCAGAAACTAGACGCACGTGATCGTTCAGAGAAAAGTCGACCCAAAGAGGATCTCCATCGCAGGGATG	AAFFFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJJFJJJJJFJJJJJJJJJJJFFJJJFJJJJJJJJJFAFAFJJJJJJJJJA<A	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12427	339	NC_007114.7	24289724	3	150M	=	24289610	-264	AAGTCGACCCAAAGAGGATCTCCATCGCAGGGATGAACTCAAACACAACCAGAGGCTAAACCTGGAGGACCTGCTCAGCCACAGCTGGCTGCCCCAAGACAGGTTCTCTGAATCACCAGACACTGTCCATTTTGGCCGCGATGCCTGGAC	FAFJJFAJFJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJFJJJJJJJJJJJJJFJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJFFFAA	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12428	339	NC_007114.7	24289724	3	150M	=	24289610	-264	AAGTCGACCCAAAGAGGATCTCCATCGCAGGGATGAACTCAAACACAACCAGAGGCTAAACCTGGAGGACCTGCTCAGCCACAGCTGGCTGCCCCAAGACAGGTTCTCTGAATCACCAGACACTGTCCATTTTGGCCGCGATGCCTGGAC	FAFJJFAJFJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJFJJJJJJJJJJJJJFJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJFFFAA	NH:i:2	HI:i:2	AS:i:297	nM:i:0

J00153:160:HMTNMBBXX:6:1104:18893:12427	419	XM_021473592.1	1294	3	149M	=	24289724	264	GGCAGTGGTCTCTGTCCTGGATCATGTAGAGTGTCGTTGTCAACCTGCTCCTCGCCCCGCACATCGCCGAAAGTCATCCAGCCAGAAACTAGACGCACGTGATCGTTCAGAGAAAAGTCGACCCAAAGAGGATCTCCATCGCAGGGATG	AAFFFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJJFJJJJJFJJJJJJJJJJJFFJJJFJJJJJJJJJFAFAFJJJJJJJJJA<A	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12428	419	XM_021473592.1	1294	3	149M	=	24289724	264	GGCAGTGGTCTCTGTCCTGGATCATGTAGAGTGTCGTTGTCAACCTGCTCCTCGCCCCGCACATCGCCGAAAGTCATCCAGCCAGAAACTAGACGCACGTGATCGTTCAGAGAAAAGTCGACCCAAAGAGGATCTCCATCGCAGGGATG	AAFFFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJJFJJJJJFJJJJJJJJJJJFFJJJFJJJJJJJJJFAFAFJJJJJJJJJA<A	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12427	339	XM_021473592.1	1408	3	150M	=	24289610	-264	AAGTCGACCCAAAGAGGATCTCCATCGCAGGGATGAACTCAAACACAACCAGAGGCTAAACCTGGAGGACCTGCTCAGCCACAGCTGGCTGCCCCAAGACAGGTTCTCTGAATCACCAGACACTGTCCATTTTGGCCGCGATGCCTGGAC	FAFJJFAJFJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJFJJJJJJJJJJJJJFJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJFFFAA	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12428	339	XM_021473592.1	1408	3	150M	=	24289610	-264	AAGTCGACCCAAAGAGGATCTCCATCGCAGGGATGAACTCAAACACAACCAGAGGCTAAACCTGGAGGACCTGCTCAGCCACAGCTGGCTGCCCCAAGACAGGTTCTCTGAATCACCAGACACTGTCCATTTTGGCCGCGATGCCTGGAC	FAFJJFAJFJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJFJJJJJJJJJJJJJFJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJFFFAA	NH:i:2	HI:i:2	AS:i:297	nM:i:0

One pair is mapped and both mates are present, the other pair is missing a mate completely (due to post-alignment filtering) but SAM/BAM is name sorted = the complete pair is correctly converted, the one-mate-pair read has incorrect coordinates
target/release/mudskipper bulk --alignment tests/NC_007114.7_12427_3.sam --gtf tests/NC_007114.7_12427.gtf --out test3.bam

cat <(grep -v "^@" tests/NC_007114.7_12427_3.sam) <(echo) <(samtools view test3.bam)

J00153:160:HMTNMBBXX:6:1104:18893:12428	419	NC_007114.7	24289610	3	149M	=	24289724	264	GGCAGTGGTCTCTGTCCTGGATCATGTAGAGTGTCGTTGTCAACCTGCTCCTCGCCCCGCACATCGCCGAAAGTCATCCAGCCAGAAACTAGACGCACGTGATCGTTCAGAGAAAAGTCGACCCAAAGAGGATCTCCATCGCAGGGATG	AAFFFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJJFJJJJJFJJJJJJJJJJJFFJJJFJJJJJJJJJFAFAFJJJJJJJJJA<A	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12428	339	NC_007114.7	24289724	3	150M	=	24289610	-264	AAGTCGACCCAAAGAGGATCTCCATCGCAGGGATGAACTCAAACACAACCAGAGGCTAAACCTGGAGGACCTGCTCAGCCACAGCTGGCTGCCCCAAGACAGGTTCTCTGAATCACCAGACACTGTCCATTTTGGCCGCGATGCCTGGAC	FAFJJFAJFJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJFJJJJJJJJJJJJJFJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJFFFAA	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12427	339	NC_007114.7	24289724	3	150M	=	24289610	-264	AAGTCGACCCAAAGAGGATCTCCATCGCAGGGATGAACTCAAACACAACCAGAGGCTAAACCTGGAGGACCTGCTCAGCCACAGCTGGCTGCCCCAAGACAGGTTCTCTGAATCACCAGACACTGTCCATTTTGGCCGCGATGCCTGGAC	FAFJJFAJFJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJFJJJJJJJJJJJJJFJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJFFFAA	NH:i:2	HI:i:2	AS:i:297	nM:i:0

J00153:160:HMTNMBBXX:6:1104:18893:12428	419	XM_021473592.1	1294	3	149M	=	1408	264	GGCAGTGGTCTCTGTCCTGGATCATGTAGAGTGTCGTTGTCAACCTGCTCCTCGCCCCGCACATCGCCGAAAGTCATCCAGCCAGAAACTAGACGCACGTGATCGTTCAGAGAAAAGTCGACCCAAAGAGGATCTCCATCGCAGGGATG	AAFFFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJJFJJJJJFJJJJJJJJJJJFFJJJFJJJJJJJJJFAFAFJJJJJJJJJA<A	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12428	339	XM_021473592.1	1408	3	150M	=	1294	-264	AAGTCGACCCAAAGAGGATCTCCATCGCAGGGATGAACTCAAACACAACCAGAGGCTAAACCTGGAGGACCTGCTCAGCCACAGCTGGCTGCCCCAAGACAGGTTCTCTGAATCACCAGACACTGTCCATTTTGGCCGCGATGCCTGGAC	FAFJJFAJFJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJFJJJJJJJJJJJJJFJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJFFFAA	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12427	339	XM_021473592.1	1408	3	150M	=	24289610	-264	AAGTCGACCCAAAGAGGATCTCCATCGCAGGGATGAACTCAAACACAACCAGAGGCTAAACCTGGAGGACCTGCTCAGCCACAGCTGGCTGCCCCAAGACAGGTTCTCTGAATCACCAGACACTGTCCATTTTGGCCGCGATGCCTGGAC	FAFJJFAJFJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJFJJJJJJJJJJJJJFJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJFFFAA	NH:i:2	HI:i:2	AS:i:297	nM:i:0

Ok, well, I think I fixed it for now, but one must still do sorting by read name prior to running mudskipper.

Paired, mapped, coordinate-sorted must sort by read name, otherwise, pairs not next to each other are considered single-end reads
target/release/mudskipper bulk --alignment tests/NC_007114.7_12427_2.sam --gtf tests/NC_007114.7_12427.gtf --out test2.bam

cat <(grep -v "^@" tests/NC_007114.7_12427_2.sam) <(echo) <(samtools view test2.bam)

J00153:160:HMTNMBBXX:6:1104:18893:12427	419	NC_007114.7	24289610	3	149M	=	24289724	264	GGCAGTGGTCTCTGTCCTGGATCATGTAGAGTGTCGTTGTCAACCTGCTCCTCGCCCCGCACATCGCCGAAAGTCATCCAGCCAGAAACTAGACGCACGTGATCGTTCAGAGAAAAGTCGACCCAAAGAGGATCTCCATCGCAGGGATG	AAFFFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJJFJJJJJFJJJJJJJJJJJFFJJJFJJJJJJJJJFAFAFJJJJJJJJJA<A	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12428	419	NC_007114.7	24289610	3	149M	=	24289724	264	GGCAGTGGTCTCTGTCCTGGATCATGTAGAGTGTCGTTGTCAACCTGCTCCTCGCCCCGCACATCGCCGAAAGTCATCCAGCCAGAAACTAGACGCACGTGATCGTTCAGAGAAAAGTCGACCCAAAGAGGATCTCCATCGCAGGGATG	AAFFFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJJFJJJJJFJJJJJJJJJJJFFJJJFJJJJJJJJJFAFAFJJJJJJJJJA<A	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12427	339	NC_007114.7	24289724	3	150M	=	24289610	-264	AAGTCGACCCAAAGAGGATCTCCATCGCAGGGATGAACTCAAACACAACCAGAGGCTAAACCTGGAGGACCTGCTCAGCCACAGCTGGCTGCCCCAAGACAGGTTCTCTGAATCACCAGACACTGTCCATTTTGGCCGCGATGCCTGGAC	FAFJJFAJFJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJFJJJJJJJJJJJJJFJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJFFFAA	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12428	339	NC_007114.7	24289724	3	150M	=	24289610	-264	AAGTCGACCCAAAGAGGATCTCCATCGCAGGGATGAACTCAAACACAACCAGAGGCTAAACCTGGAGGACCTGCTCAGCCACAGCTGGCTGCCCCAAGACAGGTTCTCTGAATCACCAGACACTGTCCATTTTGGCCGCGATGCCTGGAC	FAFJJFAJFJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJFJJJJJJJJJJJJJFJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJFFFAA	NH:i:2	HI:i:2	AS:i:297	nM:i:0

J00153:160:HMTNMBBXX:6:1104:18893:12427	418	XM_021473592.1	1294	3	149M	*	0	0	GGCAGTGGTCTCTGTCCTGGATCATGTAGAGTGTCGTTGTCAACCTGCTCCTCGCCCCGCACATCGCCGAAAGTCATCCAGCCAGAAACTAGACGCACGTGATCGTTCAGAGAAAAGTCGACCCAAAGAGGATCTCCATCGCAGGGATG	AAFFFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJJFJJJJJFJJJJJJJJJJJFFJJJFJJJJJJJJJFAFAFJJJJJJJJJA<A	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12428	418	XM_021473592.1	1294	3	149M	*	0	0	GGCAGTGGTCTCTGTCCTGGATCATGTAGAGTGTCGTTGTCAACCTGCTCCTCGCCCCGCACATCGCCGAAAGTCATCCAGCCAGAAACTAGACGCACGTGATCGTTCAGAGAAAAGTCGACCCAAAGAGGATCTCCATCGCAGGGATG	AAFFFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJJFJJJJJFJJJJJJJJJJJFFJJJFJJJJJJJJJFAFAFJJJJJJJJJA<A	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12427	338	XM_021473592.1	1408	3	150M	*	0	0	AAGTCGACCCAAAGAGGATCTCCATCGCAGGGATGAACTCAAACACAACCAGAGGCTAAACCTGGAGGACCTGCTCAGCCACAGCTGGCTGCCCCAAGACAGGTTCTCTGAATCACCAGACACTGTCCATTTTGGCCGCGATGCCTGGAC	FAFJJFAJFJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJFJJJJJJJJJJJJJFJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJFFFAA	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12428	338	XM_021473592.1	1408	3	150M	*	0	0	AAGTCGACCCAAAGAGGATCTCCATCGCAGGGATGAACTCAAACACAACCAGAGGCTAAACCTGGAGGACCTGCTCAGCCACAGCTGGCTGCCCCAAGACAGGTTCTCTGAATCACCAGACACTGTCCATTTTGGCCGCGATGCCTGGAC	FAFJJFAJFJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJFJJJJJJJJJJJJJFJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJFFFAA	NH:i:2	HI:i:2	AS:i:297	nM:i:0

One pair is mapped and both mates are present, the other pair is missing a mate completely (due to post-alignment filtering) but SAM/BAM is name sorted = the complete pair is correctly converted, the one-mate-pair read will be considered a single-end read
target/release/mudskipper bulk --alignment tests/NC_007114.7_12427_3.sam --gtf tests/NC_007114.7_12427.gtf --out test3.bam

cat <(grep -v "^@" tests/NC_007114.7_12427_3.sam) <(echo) <(samtools view test3.bam)

J00153:160:HMTNMBBXX:6:1104:18893:12428	419	NC_007114.7	24289610	3	149M	=	24289724	264	GGCAGTGGTCTCTGTCCTGGATCATGTAGAGTGTCGTTGTCAACCTGCTCCTCGCCCCGCACATCGCCGAAAGTCATCCAGCCAGAAACTAGACGCACGTGATCGTTCAGAGAAAAGTCGACCCAAAGAGGATCTCCATCGCAGGGATG	AAFFFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJJFJJJJJFJJJJJJJJJJJFFJJJFJJJJJJJJJFAFAFJJJJJJJJJA<A	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12428	339	NC_007114.7	24289724	3	150M	=	24289610	-264	AAGTCGACCCAAAGAGGATCTCCATCGCAGGGATGAACTCAAACACAACCAGAGGCTAAACCTGGAGGACCTGCTCAGCCACAGCTGGCTGCCCCAAGACAGGTTCTCTGAATCACCAGACACTGTCCATTTTGGCCGCGATGCCTGGAC	FAFJJFAJFJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJFJJJJJJJJJJJJJFJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJFFFAA	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12427	339	NC_007114.7	24289724	3	150M	=	24289610	-264	AAGTCGACCCAAAGAGGATCTCCATCGCAGGGATGAACTCAAACACAACCAGAGGCTAAACCTGGAGGACCTGCTCAGCCACAGCTGGCTGCCCCAAGACAGGTTCTCTGAATCACCAGACACTGTCCATTTTGGCCGCGATGCCTGGAC	FAFJJFAJFJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJFJJJJJJJJJJJJJFJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJFFFAA	NH:i:2	HI:i:2	AS:i:297	nM:i:0

J00153:160:HMTNMBBXX:6:1104:18893:12428	419	XM_021473592.1	1294	3	149M	=	1408	264	GGCAGTGGTCTCTGTCCTGGATCATGTAGAGTGTCGTTGTCAACCTGCTCCTCGCCCCGCACATCGCCGAAAGTCATCCAGCCAGAAACTAGACGCACGTGATCGTTCAGAGAAAAGTCGACCCAAAGAGGATCTCCATCGCAGGGATG	AAFFFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJJFJJJJJFJJJJJJJJJJJFFJJJFJJJJJJJJJFAFAFJJJJJJJJJA<A	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12428	339	XM_021473592.1	1408	3	150M	=	1294	-264	AAGTCGACCCAAAGAGGATCTCCATCGCAGGGATGAACTCAAACACAACCAGAGGCTAAACCTGGAGGACCTGCTCAGCCACAGCTGGCTGCCCCAAGACAGGTTCTCTGAATCACCAGACACTGTCCATTTTGGCCGCGATGCCTGGAC	FAFJJFAJFJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJFJJJJJJJJJJJJJFJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJFFFAA	NH:i:2	HI:i:2	AS:i:297	nM:i:0
J00153:160:HMTNMBBXX:6:1104:18893:12427	338	XM_021473592.1	1408	3	150M	*	0	0	AAGTCGACCCAAAGAGGATCTCCATCGCAGGGATGAACTCAAACACAACCAGAGGCTAAACCTGGAGGACCTGCTCAGCCACAGCTGGCTGCCCCAAGACAGGTTCTCTGAATCACCAGACACTGTCCATTTTGGCCGCGATGCCTGGAC	FAFJJFAJFJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJFJFJJJJJJJJJJJJJFJJJJFJJJJJJJJJJJJJJJJJJJJJJJJJFFFAA	NH:i:2	HI:i:2	AS:i:297	nM:i:0


Unexpected show/hide behavior of BottomBar and FeedTabBar on mobile web

Describe the bug
When scrolling up or down on mobile web (width < 1230px), the BottomBar and FeedTabBar exhibit random "dancing" behavior, showing and hiding repeatedly.
To Reproduce
Steps to reproduce the behavior:

Open the app on mobile web (width < 1230px).
Randomly scroll up and down. (Exact conditions are added in the Additional context section.)

Expected behavior
The BottomBar and FeedTabBar are expected to remain stable, without showing and hiding repeatedly.
Screenshots
https://github.com/bluesky-social/social-app/assets/31644638/a6f0907a-25a3-488a-afd6-fda5fd1657b6
Details

Platform: MacOs Desktop Arc
Platform version: 0.109.1
App version: Build version 1.34.0

Additional context
Upon investigation of the codebase, it seems that the bug occurs in useOnMainScroll.ts when the current dy value is the inverse of the previous dy value. The relevant code snippet is as follows:
social-app/src/lib/hooks/useOnMainScroll.ts
export function useOnMainScroll(
  store: RootStoreModel,
): [OnScrollCb, boolean, ResetCb] {
  let lastY = useRef(0)
  let lastDy = useRef(0) // added by me to check last `dy` value
  let [isScrolledDown, setIsScrolledDown] = useState(false)
  return [
    useCallback(
      (event: NativeSyntheticEvent<NativeScrollEvent>) => {
        const y = event.nativeEvent.contentOffset.y
        const dy = y - (lastY.current || 0)

        // below is added by me to check the condition
        const isDancing = dy > DY_LIMIT && lastDy.current * -1 === dy
        console.log({lastDy: lastDy.current, dy})
        if (isDancing) {
          console.error('Dance!') // Starts dance
        }
        lastDy.current = dy
        // end of added by me

        lastY.current = y

        if (!store.shell.minimalShellMode && y > 10 && dy > DY_LIMIT) {
          store.shell.setMinimalShellMode(true)
        } else if (
        // ...

and here's the video capture:
https://github.com/bluesky-social/social-app/assets/31644638/9eda3cf5-9858-41f6-83e1-e1f1529baed0

I tuned the behaviors a bit before merging with https://github.com/bluesky-social/social-app/pull/942
The mobile simulator seemed okay with it but please re-open if I got the thresholds wrong

Thank you for tuning the behaviors and merging! I'll let you know if I find any issues. Appreciate your response!


Data received and immediately lost in Home Assistant

I am trying to feed temperature and humidity data from a Xiaomi LYWSD03MMC BLE device into Home Assistant via MQTT.
In principle, the ble2mqtt script seems to work as expected. It connects to the MQTT broker (Mosquitto) in the local network. It further connects to the Xiaomi BLE device periodically and reads out temperature and humidity data. See excerpt from the log below:
INFO:ble2mqtt.__main__:Starting BLE2MQTT version 0.1.0a47
INFO:ble2mqtt.ble2mqtt:Connected to mosquitto.valais
...
INFO:ble2mqtt.devices.base:Connected to A4:C1:38:7B:70:5D
INFO:ble2mqtt.devices.base:[Xiaomi_LYWSD03MMC_a4c1387b705d] send state=SensorState(battery=100, temperature=21.62, humidity=53)

This is the corresponding configuration file /etc/ble2mqtt.json:
{
    "mqtt_host": "<host>",
    "mqtt_port": 1883,
    "mqtt_user": "<user>",
    "mqtt_password": "<password>",
    "base_topic": "ble2mqtt1",
    "log_level": "INFO",
    "devices": [
        {
            "address": "A4:C1:38:7B:70:5D",
            "type": "xiaomilywsd",
            "key": "<key>"
        }
    ]
}

When I check in Home Assistant, the device appears in the MQTT integration, however, temperature and humidity sensor readings are indicated as not available. Sometimes, sensor readings flash up in Lovelace or the MQTT integration. However, data disappears immediately again and is not shown in sensor trend graphs.
I am using Home Assistant version 2021.12.10 with the default MQTT integration. For Mosquitto, I am using the docker image eclipse-mosquitto:latest. The setup works flawlessly in combination with zigbee2mqtt.
What could be the cause for the observed behaviour?

Here is the debug log: https://dpaste.com//HD4GU2XLZ

Observing the behaviour in Home Assistant I noticed that values seem to disappear, again, when the device disconnects and an "offline" message is being send.
DEBUG:ble2mqtt.devices.base:Client A4:C1:38:7B:70:5D disconnected, device=Xiaomi_LYWSD03MMC_a4c1387b705d
DEBUG:ble2mqtt.ble2mqtt:Xiaomi_LYWSD03MMC_a4c1387b705d has disconnected
DEBUG:ble2mqtt.ble2mqtt:call publish callback topic=0xa4c1387b705d/availability value=offline

Thanks for the report, the problem is resolved in the commit cd69806d445444399e57277c7add7186899ec362
Can you please try the version from git with
pip3 install -U https://github.com/devbis/ble2mqtt/archive/refs/heads/main.zip --no-cache-dir --force-reinstall

and confirm that the bug is fixed?

Working now. Wonderful. Thank you so much!
Am 20.01.22 um 12:14 schrieb Ivan Belokobylskiy:

|pip3 install -U
https://github.com/devbis/ble2mqtt/archive/refs/heads/main.zip
--no-cache-dir --force-reinstall|

Fixed in version 0.1.0a48


Use 'replaceState' instead of 'pushState' in order to keep the back button working

Great plugin! We're using it in our documentation site, mainly to support deep linking into a specific tab.
I wonder if it would be better to use replaceState instead, in order not to keep the old url in the history? If switching several times between tabs, each switch will be remembered by the back button...
I ran a little test here, and it seems that everything still works with replaceState. Any reason not to use it? Would you accept a PR with adding this to the options?

Maybe it could be a toggle ... for deep linking behaviour it makes sense that every navigation can be back/forwarded.

Just sent a PR. Please let me know what you think?


progress_display add time to completion estimate

tqdm supports this, will it work with our customisation?

Mostly likely not. I believe the estimated time completion uses the size of the collection provided to the tqdm object.
However, with our customisation we do not provide tqdm a collection. Instead, we manually update the progress attribute. We did this to allow progress to be set dynamically in the case it had to be set back.

On further investigation, we should be able to use the estimate. I forgot that we set the tqdm total to 1.0 when we instantiate it. I made a test file is it gave an estimate even though I was manually setting the progress.
We we do not already have the estimate, I need to look at how I formatted the displayed information of the progress display. I may not have added it in.


Add PhaseSpacePoint definition

Proposal to fix issue #46
This branch is currently based on PR #39 and should be merged after it.
This is a draft for now, but I think it is a good compromise from the discussion in issue #46. The definition is type stable, allows some nice overloads for is_fermion and so on for the ParticleStateful objects, and takes care of preventing illegal objects in the constructors.
Creating particles is straightforward and disallows illegal configurations (electron with polarization or photon with spin):
in_el = ParticleStateful(rand(SFourMomentum), Electron(), AllSpin(), Incoming())
in_ph = ParticleStateful(rand(SFourMomentum), Photon(), AllPol(), Incoming())
out_el = ParticleStateful(rand(SFourMomentum), Electron(), AllSpin(), Outgoing())
out_ph = ParticleStateful(rand(SFourMomentum), Photon(), AllPol(), Outgoing())

in_particles_valid = SVector(in_el, in_ph)
in_particles_invalid = SVector(in_el, out_ph)

out_particles_valid = SVector(out_el, out_ph)
out_particles_invalid = SVector(out_el, in_ph)

Creating PhaseSpacePoints is similarly simple and prevents illegal configurations, e.g. incoming particles in the outgoing list, but is still reasonably fast and does not need allocations. One PhaseSpacePoint for a 2 to 2 process is 944B in memory.
julia> @benchmark PhaseSpacePoint($process, $model, $phasespace_def, $in_particles_valid, $out_particles_valid)
BenchmarkTools.Trial: 10000 samples with 991 evaluations.
 Range (min … max):  39.268 ns … 111.740 ns  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median):     41.068 ns               ┊ GC (median):    0.00%
 Time  (mean ± σ):   43.116 ns ±   6.557 ns  ┊ GC (mean ± σ):  0.00% ± 0.00%

   ▃▇█▆▂ ▁▂▁▁                                             ▁    ▁
  ▆███████████▇▆▆▇▆▆▆▅▅▆▆▆▅▄▅▅▄▄▆▆▆▆▆▆▇▇▆▇▇█▇▅▄▅▅▄▅▄▅▄▅▆████▇▇ █
  39.3 ns       Histogram: log(frequency) by time      70.9 ns <

 Memory estimate: 0 bytes, allocs estimate: 0.

Suggestions welcome

Can you explain, why the unit tests for Julia v1.6 and v1.7 fail, but the others not? Looks a bit like an API change for @test_throws.

Yeah I'm pretty sure that's what it is... I think the matching to a regex is new. I can just wrap it in a check about the Julia version, but are we sure we need to support 1.6 and 1.7 anyways? Especially when the now stable version is 1.10 already.

Can you explain, why the unit tests for Julia v1.6 and v1.7 fail, but the others not? Looks a bit like an API change for @test_throws.

Yeah I'm pretty sure that's what it is... I think the matching to a regex is new. I can just wrap it in a check about the Julia version, but are we sure we need to support 1.6 and 1.7 anyways? Especially when the now stable version is 1.10 already.

Julia v1.6 is the defacto LTS, but you are right, the tests for v1.7 to v1.9 are somewhat arbitrary. However, I am fine with the exclusion of some tests, if there is an API change of lack of support in the respective Julia version. Therefore, there is no need to drop the support in the current status, but we should keep an eye on that.
Regarding the support of Julia v1.10, you are right, of course. There should be an issue opened on its inclusion 😉

Btw: we must not set assignees on pull requests, because it breaks the gitlab bot somehow 🤷♂

Oh you're right, I completely forgot


How does vector embedding perform compared to fuzzy string matching?

How does vector embedding perform compared to fuzzy string matching?
I’m exploring the usage of string matching like levenshtein distance, Jaro-Winkler among others.
Vector embedding seems similar in terms of addressing the issue of string similarity.
Bit is it the case that I may need to have access to good pre-trained models?
For example my use case is on identifying similar pharmacy names and their adresses.
I may have two different files and contain duplicates of pharmacy+address combinations. But the way these pharmacies and their respective adresses may have been wrongfully inputed.

Hey @lejarx, have you tried it ? I'm having a similar use case :)


Task "API for analytics"

Added necessary elements for statistics API, integrated AutoMapper

What benefits give us separation automapper profile in 3 files?

At this point, it's not that essential. But putting all automapper configs into 1 profile class can quickly become chaotic as soon as new mapping rules need to be added.

Why is the controller responses not using status codes other than 200. For example 204 (No Content) or 404 (Not Found)

Fairly. I'll fix this.

What benefits of using query as model binding source instead of route? Why we don't validate year and month values before pass it to service?

I've reconsidered this point. You're right, using route for model binding is semantically better in our case. As for validation, I'm going to implement attributes inherited from ActionFilterAttribute.

Why we don't check result, returning from service for null?

Fairly. I'll fix this.

Why we add automapper profile in this way: builder.Services.AddAutoMapper(AppDomain.CurrentDomain.GetAssemblies()); As I understand, in result we add all profiles of all assemblies, even if another layers use some profiles for another presentation layers?

AutoMapper is loaded in this way to check for profile classes not only in the current project but also in the BLL where they will be added later. As long as we don't plan to create layers for other presentation layers, it shouldn't be a problem.

Why in AnalyticsPerHourViewModel.TimeSpent has float type, but in MonthlyStatisticsViewModel.TimeSpent has integer type? Same in MonthlyStatistics and AnalyticsPerHour? In my opinion its better to use int anywere, its faster in performance, and both c# and js date (TimeSpan) don't have constructors to work with floats.

According to the statistics page in Figma, time spent per 1 hour on the diagram of daily statistics should be displayed with seconds. That's why I chose the float type for these models.


Please refund because some people mistakenly purchased credit

In the early days, it seems that some people thought that it was necessary to transmit 2500 TNT for credit (I also do).
From here you can check the send of TNT of 2500 ~ 3000.
https://etherscan.io/token/0x08f5a9235b08173b7569f83645d2c7fb55e8ccd8?a=0xddfff2b78463ab1ca781e853bb888fdfd06083d3
I know about Frequently-Asked-Questions.
 no undo's in Blockchain. Yes, right.
Do you mean to manage TNT nodes for more than 10 years while paying server costs?
People who make mistakes think of themselves as slaves and may hate Tierion.
such PoS(Proof of Slave).
Even if the block chain can not be changed, it can be added later.
It is a solution, if you burn credit of the applicant and refund TNT from the support team.

it was not mentioned on the official guides how to setup a node?

It was made explicitly clear in the github files what the requirements were for setting up a node and in what order to do them in. I feel for you on this matter, because it sucks, but it's not Tierions fault.
Maybe they will be nice, but what then? If they set the precedent for paying back everyone's development errors, how will that affect the operation of the business? Not good I can tell you that.
I hope you saved the HMAC key for that node because you will have those credits a long time. Plus side is that node will probably pay you back 3 fold what you paid into it down the long stretch. Good luck.

With today's update credit has become completely unnecessary.
Nodes will receive enough credits to submit the maximum number of hashes to Core per day.
Nodes under max load will submit one hash per second to Core, and there are 86,400 seconds per day.
Users with a credit balance under 86,400 now have a credit balance of 86,400.
Credits will be used throughout the day.
At UTC midnight, nodes with a balance below 86,400 will have their credit balance restored to 86,400.
This credit model will remain active until further notice.
At this time, there is no need to convert TNT to credits.

My asset is completely worthless.
Very sad 😥

With today's update credit has become completely unnecessary.
Nodes will receive enough credits to submit the maximum number of hashes to Core per day.
Nodes under max load will submit one hash per second to Core, and there are 86,400 seconds per day.
Users with a credit balance under 86,400 now have a credit balance of 86,400.
Credits will be used throughout the day.
At UTC midnight, nodes with a balance below 86,400 will have their credit balance restored to 86,400.
This credit model will remain active until further notice.
At this time, there is no need to convert TNT to credits.

My asset is completely worthless.
Very sad 😥

With today's update credit has become completely unnecessary.
Nodes will receive enough credits to submit the maximum number of hashes to Core per day.
Nodes under max load will submit one hash per second to Core, and there are 86,400 seconds per day.
Users with a credit balance under 86,400 now have a credit balance of 86,400.
Credits will be used throughout the day.
At UTC midnight, nodes with a balance below 86,400 will have their credit balance restored to 86,400.
This credit model will remain active until further notice.
At this time, there is no need to convert TNT to credits.

My asset is completely worthless.

We have temporarily removed the need to submit TNT for credits. We will announce an update to the credit usage model in the near future. Your original TNT submission has been logged and will be accounted for in the update to the model. In the interim we have provided your account with all of the credits needed to operate at full load throughout every day. This is not a technical issue. Closing.


Update Integration tests

Codecov Report

Merging #432 (2b4a047) into master (bd30853) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #432   +/-   ##
=======================================
  Coverage   97.29%   97.29%
=======================================
  Files          53       53
  Lines        3887     3887
=======================================
  Hits         3782     3782
  Misses        105      105

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 bd30853...2b4a047. Read the comment docs.


[Bug]: No end point available after model is fully loaded

Your current environment
vllm==0.5.0.post1
vllm-flash-attn==2.5.9
Python 3.10.11

🐛 Describe the bug
Hey Guys,
I loaded a Llama-3-70B with vllm, once the model is loaded, I get the following message, which I assume means it is ready to take the requests,
INFO:     Uvicorn running on http://<IP_ADDRESS>:8000 (Press CTRL+C to quit)

However, no end point is available, I tried both / and /generate, both giving me 404 error, here is the log printed by vllm:
INFO:     <IP_ADDRESS>:55504 - "GET / HTTP/1.1" 404 Not Found
INFO 07-07 20:12:44 metrics.py:295] Avg prompt throughput: 0.0 tokens/s, Avg generation throughput: 0.0 tokens/s, Running: 0 reqs, Swapped: 0 reqs, Pending: 0 reqs, GPU KV cache usage: 0.0%, CPU KV cache usage: 0.0%.
INFO:     <IP_ADDRESS>:59820 - "GET /generate HTTP/1.1" 404 Not Found
INFO 07-07 20:12:54 metrics.py:295] Avg prompt throughput: 0.0 tokens/s, Avg generation throughput: 0.0 tokens/s, Running: 0 reqs, Swapped: 0 reqs, Pending: 0 reqs, GPU KV cache usage: 0.0%, CPU KV cache usage: 0.0%.
INFO:     <IP_ADDRESS>:53798 - "POST /generate HTTP/1.1" 404 Not Found

where do you get the /generate endpoint?
if you are running openai server, the endpoint should be /v1/models stuff.

Oh I see, so the generate would be /v1/models/generate ?

if you start an openai server, you should use openai client to interact with it. I don't think you should care about the specific endpoints.

Oh I see, thanks, do you have an example with open ai client?
Here is how I launch the server: python -m vllm.entrypoints.openai.api_server --host <IP_ADDRESS> --port 8000 --served-model-name $NAME --model ....

it is https://docs.vllm.ai/en/latest/serving/openai_compatible_server.html#openai-compatible-server


Merge pageflow-react gem

With more and more functionality being moved to the pageflow-react gem, the pageflow gem no longer was functional on its own. Merge the two gems to allow moving even more of the ES5 code to the  Babel/Webpack setup.

Coverage decreased (-5.0%) to 94.146% when pulling bf03885aaa1cd8401ae00a2707e175cc5091ca4c on tf:react into 133ead1edabc47eb70222df79427c8834e115206 on codevise:master.

Coverage decreased (-5.0%) to 94.146% when pulling bf03885aaa1cd8401ae00a2707e175cc5091ca4c on tf:react into 133ead1edabc47eb70222df79427c8834e115206 on codevise:master.

Coverage decreased (-5.0%) to 94.146% when pulling bf03885aaa1cd8401ae00a2707e175cc5091ca4c on tf:react into 133ead1edabc47eb70222df79427c8834e115206 on codevise:master.

Coverage decreased (-0.1%) to 98.985% when pulling d0969137912ae7981556f99d3a6d3d5ebb20e36c on tf:react into 133ead1edabc47eb70222df79427c8834e115206 on codevise:master.

Coverage decreased (-0.1%) to 98.985% when pulling ba699007b8eb56eaef2bc0a746a5e37e9eab9498 on tf:react into 133ead1edabc47eb70222df79427c8834e115206 on codevise:master.

Coverage decreased (-0.1%) to 98.985% when pulling ba699007b8eb56eaef2bc0a746a5e37e9eab9498 on tf:react into 133ead1edabc47eb70222df79427c8834e115206 on codevise:master.

Coverage decreased (-36.02%) to 63.1% when pulling 612f1167903c515c526036a63d53fe0bebf4b2a9 on tf:react into 133ead1edabc47eb70222df79427c8834e115206 on codevise:master.

Coverage decreased (-36.02%) to 63.1% when pulling 612f1167903c515c526036a63d53fe0bebf4b2a9 on tf:react into 133ead1edabc47eb70222df79427c8834e115206 on codevise:master.

Coverage decreased (-36.0009%) to 63.124% when pulling cfc76854d321c8e5557679c6ab3beec2a4ba8290 on tf:react into 133ead1edabc47eb70222df79427c8834e115206 on codevise:master.

Coverage decreased (-36.0009%) to 63.124% when pulling cfc76854d321c8e5557679c6ab3beec2a4ba8290 on tf:react into 133ead1edabc47eb70222df79427c8834e115206 on codevise:master.

Coverage decreased (-41.5%) to 57.586% when pulling 5666d0948f47fab1d2a12fb3908ce68ab7a36be7 on tf:react into 133ead1edabc47eb70222df79427c8834e115206 on codevise:master.

Coverage decreased (-41.5%) to 57.586% when pulling 5666d0948f47fab1d2a12fb3908ce68ab7a36be7 on tf:react into 133ead1edabc47eb70222df79427c8834e115206 on codevise:master.

Coverage decreased (-35.5%) to 63.61% when pulling 366cdeb4b447afb31ebda53181b6bf352d00e0ec on tf:react into 133ead1edabc47eb70222df79427c8834e115206 on codevise:master.

Coverage decreased (-35.5%) to 63.61% when pulling 366cdeb4b447afb31ebda53181b6bf352d00e0ec on tf:react into 133ead1edabc47eb70222df79427c8834e115206 on codevise:master.

Coverage decreased (-35.9%) to 63.244% when pulling 6862ec60b73877925038b0dcfa9b03d369fe5236 on tf:react into 133ead1edabc47eb70222df79427c8834e115206 on codevise:master.

Coverage decreased (-0.09%) to 99.031% when pulling 1de0c1f74b1f223d43d09d98485d59688db8c323 on tf:react into 133ead1edabc47eb70222df79427c8834e115206 on codevise:master.


getmastodon page need some UI/UX fixes

getmastodon page need responsive better with different size (some button not align with input at different size)
also need container to match with content at mastodon website.

we use Mastodon color to brand the page and add container
@xmonader @AhmedHanafy725 @MohamedElmdary what u think?

done and updated by @MohamedElmdary Thanks


openvino to tensorflow falis

trying to convert a ir model create with 2019 r2 openvino toolkit version with this command:
openvino2tensorflow   --model_path=raftC.xml   --output_saved_model True   --output_pb True   --output_weight_quant_tflite True   --output_no_quant_float32_tflite True
output:
import: not authorized os' @ error/constitute.c/WriteImage/1028. import: not authorized sys' @ error/constitute.c/WriteImage/1028.
import: not authorized argparse' @ error/constitute.c/WriteImage/1028. import: not authorized struct' @ error/constitute.c/WriteImage/1028.
import: not authorized np' @ error/constitute.c/WriteImage/1028. import: not authorized et' @ error/constitute.c/WriteImage/1028.
from: can't read /var/mail/openvino.inference_engine
import: not authorized tf' @ error/constitute.c/WriteImage/1028. from: can't read /var/mail/tensorflow.keras from: can't read /var/mail/tensorflow.keras.layers from: can't read /var/mail/tensorflow.keras.initializers from: can't read /var/mail/tensorflow.keras.backend from: can't read /var/mail/tensorflow.keras.activations from: can't read /var/mail/tensorflow.python.framework.convert_to_constants import: not authorized np' @ error/constitute.c/WriteImage/1028.
import: not authorized sys' @ error/constitute.c/WriteImage/1028. import: not authorized tfds' @ error/constitute.c/WriteImage/1028.
/home/user/miniconda3/bin/openvino2tensorflow: line 79: syntax error near unexpected token (' /home/user/miniconda3/bin/openvino2tensorflow: line 79: def convert(model,'

Please update the program and try again. d7110b9f3dbf3b18a9c159979f6cffd48e0780f4 17700b34bb58625c23d36a786aed876def1e16c0
pip install git+https://github.com/PINTO0309/openvino2tensorflow --upgrade

after installing the tensorflow-datasets and updating the tqdm i know get this msg;
The Input layer is not yet implemented.
as i see in netron the input layer of my model is: Convolution

Is this a model you converted from Caffe?
https://docs.openvinotoolkit.org/2019_R2/_docs_MO_DG_prepare_model_Supported_Frameworks_Layers.html
If possible, try upgrading to OpenVINO 2021.1 and generating the IR again.

Nope, my model is from onnx.
will try to update OpenVino

Close for lack of progress.

Close for lack of progress.


display pod logs respecting the value provided in kapp.k14s.io/deploy-log annotation

Issue - #460
kapp.k14s.io/deploy-log  with the default value of "" and with the specified valued "for-new" kapp should omit logs for existing pods and only show logs for new pods.

On a second thought, should we check how much of a difference this makes for an active cluster? See how much difference does it make? Not sure if it is already in place, but if the overhead is too high we could maybe disable podlogs for kapp-controller? (if it is not done already)

On a second thought, should we check how much of a difference this makes for an active cluster? See how much difference does it make? Not sure if it is already in place, but if the overhead is too high we could maybe disable podlogs for kapp-controller? (if it is not done already)

Yeah sure, I can check this out.

@sethiyash would be good to add an e2e test to catch this regression.


vscode steals focus when opening a new window

VSCode Version: 1.26.1
OS Version: Windows 10 Pro Build 1803

Steps to Reproduce:

Open vscode
Immediatly click on "More" under Recent (Folders)
The search will popup, while vscode is loading/restoring the UI, it will steal focus or restore the window, closing the popup.

Does this issue occur when all extensions are disabled?: No

@johannes-z are you using the custom title style with custom menus?

@bpasero Yes I am!

@sbatten yes! it doesn't matter what you open. E.g. the terminal also loses focus a few seconds after opening vs code.
I tried both custom and native menus, it happens with both of thrm.

@bpasero doesn't appear to be specific to new menus.
@johannes-z I notice this was reported on 1.26.1, does it also repro on 1.27.1?

Closing as designed. As a workaround you can configure workbench.quickOpen.closeOnFocusLost: false

@bpasero @sbatten As designed? Stealing focus is never good UX. Even if there is an option to disable closeOnFocusLost, e.g. writing in a terminal still steals focus. in the quickOpen


Fix violation of the render rule in Windows Startup Test

This PR fixes yet another case in the windows startup test that violates the render rule, which caused https://github.com/flutter/engine/pull/45300 to be reverted.
Although the FlutterView.render call is within onBeginFrame, there is an await before the call, causing the call to fall out of the synchronous scope.
I've added this problem to the documentation of FlutterView.render in https://github.com/flutter/engine/pull/45555.
Pre-launch Checklist

[ ] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[ ] I read the Tree Hygiene wiki page, which explains my responsibilities.
[ ] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[ ] I signed the CLA.
[ ] I listed at least one issue that this PR fixes in the description above.
[ ] I updated/added relevant documentation (doc comments with ///).
[ ] I added new tests to check the change I am making, or this PR is test-exempt.
[ ] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

@loic-sharma Thank you first for reviewing it during your vacation. I'll post my reply now but feel free to enjoy your vacation and the discussion can wait until you come back.
I haven't fully read the native code of this test yet, but by analysis I agree that there is some kind of synchronization issues. The following is my analysis for affirmation:
Comparing the logic before the PR and after the PR, they're same in:

The request to fetch isWindowVisible takes place at the exact same time, therefore should return the exact same result.
The visibilityCompleter resolves after the first-frame isWindowVisible(), and the test waits for visibilityCompleter.

They're different in:

drawHelloWorld is now run even if the window is visible on the first frame.
The visibilityCompleter now resolves before drawHelloWorld, instead of after it.

I'm guessing drawHelloWorld opens the first window on its first frame, and isWindowVisible is there just to ensure the automatic window opening is effective.
In this way, I can spot a significant difference in that the test can't verify if the first frame can be rendered or not, since when visibilityCompleter resolves and the test completes, drawHelloWorld still hasn't been executed. However, I doubt if this is verified at all. If so, can you tell me how you verified it?
Also, from your reply, it seems to me that you're also verifying whether the latter onBeginFrame is executed with the window opened, which I don't think is happening in the current code.

I'm guessing drawHelloWorld opens the first window on its first frame, and isWindowVisible is there just to verify that it opens window.

Yup that's correct.

In this way, I can spot a significant difference in that the test after the PR can't verify if the first frame can be rendered or not, since when visibilityCompleter resolves and the test completes, drawHelloWorld still hasn't been executed. However, I doubt if this is verified in the original test at all.

Ah good catch, that's a goof on my part 🤦. Could you:

Comment out the drawHelloWorld as this can cause flakes (see: https://github.com/flutter/flutter/pull/134245#pullrequestreview-1620889673)
Add a TODO comment that links to https://github.com/flutter/flutter/issues/134986

I'll go ahead and improve the test in a subsequent PR. Apologies for this messy test.


Should return a better error when attempting to insert NaN into numeric field?

There have been a few issues raised related to accidentally trying to insert a NaN into a numeric field.
For example, a statement such as:
db.query('SELECT * FROM customers WHERE id = ?', [0 / 0])

is sent to the db as SELECT * FROM customers WHERE id = NaN, which results in the error:
Error: ER_BAD_FIELD_ERROR: Unknown column 'NaN' in 'where clause'

This error message has led to a bit of confusion in the past (see #1716, #1880, and #2158). Since mysql cannot store NaN and Infinity values at all, perhaps the behavior could be improved by refusing to perform the query at all, and returning an error message such as, Error: Attempting to insert NaN into numeric field. Or at the very least, the NaN should be quoted so that it is interpreted as a string rather than an object name.
This also brings up the question--and unfortunately I don't have time to test this right now--what happens if "NaN" or "Infinity", are the names of actual objects in the database? Could this lead to unexpected (or worse, malicious) behavior?

You are correct in that this has been discussed several times before, and even then, nothing has changed in our contract:

We are very explicit on this fact in our docs (https://github.com/mysqljs/mysql#escaping-query-values): "NaN / Infinity are left as-is. MySQL does not support these, and trying to insert them as values will trigger MySQL errors until they implement support." so there is no surprise that this is the behavior.
When using our ? behavior, you can never pass in a value that will throw an error by design -- introducing a throw will be a huge change, with enormous amounts of code out there not wrapping in a try or similar because it's not possible for an error to be thrown from that.

Could this lead to unexpected (or worse, malicious) behavior?

This has been brought up before but nothing has ever been produced around this, though. If you think there is something, you are putting all users at risk without even attempting to go through the process of https://github.com/mysqljs/mysql#security-issues


Delete Roles

User story
As an administrator, I am able to delete roles.
Narrative
As an administrator, I want to delete existing roles, which will also remove said roles from the associated users.
Out of scope
Managing the permissions covered by the roles.
Acceptance criteria

#
Given
When
Then

1
I am an administrator
I try to remove a role
The system removes that role and disassociates it from all the linked users

2
I am not an administrator
I try to remove a role
The system prevents me from removing that role

UI Mockup:

Was implemented in earlier PR


Enum type should be default constructible

Normal scoped enumerations are default constructible:
enum class Fubar { One, Two, Three };
auto myinstance = Fubar{};

However, your ENUM macro does not yield a struct that matches these semantics:
ENUM(Fubar, int, One, Two, Three);
auto myinstance = Fubar{}; // compiler error on MSVC12

The error I get is:

error C2248: 'Fubar' : cannot access private member declared in class 'Fubar'

These semantics are extremely important for template metaprogramming. Example test case:
template<typename T>
void DeserializeEnum(T& enumerator, T const& default_value = T{});

Internally, the method above will attempt to stream in a string and map it to a proper enumerator. If the string does not map to a valid enumerator, it will instead set it to the value of default_value. This template works just fine for true scoped enumerations, but not with your struct declared by the ENUM macro.

Thanks for this, this is the kind of feedback I need to decide what the default constructor should do. What do you think about the considerations here?

After reading the section you linked, I feel like maybe you're overthinking the problem. Despite the complex implementation to support what you have today, I think the design is already defined for you. IMHO, semantics should be modeled around existing scoped enumeration functionality. This makes the question of whether to have a default constructor obvious: Yes.
From a unit test perspective, every possible usage of a zero-initialized scoped enum should also be a valid and passing test for your custom class. That means when you use it in a switch statement, that might mean hitting the default case if it is zero initialized and there is no corresponding enumerator with the value 0.
As per my SO question you kindly responded to, I had devised a solution that utilized X Macros per one of the suggestions there.  I have no way of knowing all of the various ideas you have tried to implement, but I figured to keep semantics the same I'd have to somehow make my macro magic define a true scoped enumeration. A class to simulate the behavior just wouldn't work, especially when you need to have type safety for the enumerators as well as make them usable in case statements.
My goals were much simpler than yours. I did not need the numerous safety checks you provided. The most common problem to solve and the thing that incurs the most maintenance burden when it comes to enumerations is serialization.

Enum mappings between string and enumerator should be automatic and transparent
When adding, modifying, or removing an enumerator, the corresponding change to the string mapping should be automatic.
Automatic << and >> operators should be defined for said enumeration.

These are the only guarantees you can really make without worrying about special cases. For example, if I were to go out of my way to make sure that no enumerators were left out of switch statements for this enum, that would be more of an annoyance because depending on business rules I may not want to check all enumerators and only care about a few, as far as switching goes.
If I am to use your better enums library for my needs, I need them to be an absolute drop in replacement for scoped enums.

I am confused by several statements above. I'll reply first with what seems to be most relevant to the title of the issue.
I doubt all users are looking for a drop-in replacement for built-in enums, especially given that this library originated with a user that wasn't. I agree that having no default constructor is surprising and restrictive for C++, and I agree that replacing built-in enums is a valid and common use case. However, I am still looking for stronger arguments before I make such a decision for all users of the library. There are two reasons why I hesitate:

I can't make Better Enums a full drop-in replacement for built-in enums anyway, due to some type trickery that I have to do, unless I switch to a type traits approach (see branch type-traits and here – although note, I plan to simplify the implementation, so some reasons listed against type traits will no longer apply).
Committing to this default constructor behavior makes Better Enums much less useful for other use cases – the ones in which programs maintain the invariant that no invalid enum value exists during execution. In this view, built-in enums are broken for more reasons than just poor serialization support – they are too lax and nowhere near sufficiently type-safe.

It would be nice to support built-in-enum-like default constructors without causing problems for such users – perhaps as some kind of opt-in or opt-out feature?

Regarding the rest:

After reading the section you linked, I feel like maybe you're overthinking the problem. Despite the complex implementation to support what you have today, I think the requirements are simple and the design is already defined for you. IMHO, semantics should be modeled around existing scoped enumeration functionality. This makes the question of whether to have a default constructor obvious: Yes.

I am not sure what some of this is referring to. Use cases and the question of a default constructor were discussed above, but the complexity of the implementation has nothing to do with the default constructor question. First, the implementation is not that complex, but what complexity there is has to do with the design limitations of C++, differences between compilers, differences between C++11 and C++98, string conversions, and some experimental features I am going to remove to a branch.

From a unit test perspective, every possible usage of a zero-initialized scoped enum should also be a valid and passing test for your custom class. That means when you use it in a switch statement, that might mean hitting the default case if it is zero initialized and there is no corresponding enumerator with the value 0.

If you have a Better Enum with value 0 and there is no corresponding enumerator and case, that is exactly the behavior you will get.

A class to simulate the behavior just wouldn't work, especially when you need to have type safety for the enumerators as well as make them usable in case statements.

What do you mean by this? The implicit conversions to integers that are allowed by the code that supports case? Apart from that, Better Enums are classes, yet have all the remaining type safety of C++11 scoped enums, and some more on top, and are still usable in case. Converting to integers is annoying, and I'd love to get rid of it, but the great danger is convertibility from integers.

My goals were much simpler than yours. I did not need the numerous safety checks you provided

Fair enough, but other users want the safety checks. By the way, the safety checks fall into one category: making sure you can't convert a string or integer that does not represent an enumerator to a value of enum type. There is no way to avoid doing a check when converting from strings anyway, so that leaves the check when converting from integers and the lack of a default constructor as the only "excess" safety measures that could be removed. The integer check can be opted out of in the current release. So, I don't see what you mean by "numerous" – did I misunderstand what you are referring to?

The most common problem to solve and the thing that incurs the most maintenance burden when it comes to enumerations is serialization.

This is indeed one of the biggest problems, but there is also the cost of detecting validation bugs and maintaining validity checking code throughout the program.

In conclusion, I think the best options for supporting your usage would be to either:

add default constructors that leave the enum value uninitialized, and make it possible to opt out of this feature for people who don't want that, or
modernize the type-traits branch so that you can have direct access to built-in enums, with serialization and validation functions on the side.

I think my main holdup (and the comments regarding "complexity" were more related to this) is that you keep mentioning the integer <-> enum implicit conversions. This is true with unscoped enums, but not true with scoped enums. There are huge semantic differences between the two. I prefer the latter, and it's a built-in feature of the language that scoped enums are truly type safe.
Is there some other type safety issue you're referring to, even after considering scoped enum semantics and guarantees?

By "keep" mentioning, I assume you mean in the documentation, not here – right? That is only because I want to be clear and honest about what is missing relative to scoped enums. Believe me, I am aware of the differences between old enums and new enums.

Yes, there are remaining type safety issues. Scoped enums are definitely not type safe – just more type safe than old enums. It's a welcome improvement, but still frustrating for some use cases.
Specifically, it's too easy to get a scoped enum with undefined value by default construction. That is about as unsafe as an implicit conversion from integer, and a much more serious safety issue than implicit conversion to integer.
Contrary to how C++ is defined, the expectation of many people, and the practice in many other languages, is that an enum should have the value of one of its enumerands. Introduction forms that break this expectation, especially silently, break type safety, because they break the main elimination form, switch. Examples of broken introduction forms would be implicit unchecked conversions from integers (not that these were present), casts, _from_integral_unchecked, and the default constructor we are discussing.
Suppose you have such introduction forms. To be truly robust, almost every switch now needs a default case, with obnoxious handling even if the rest of the cases are exhaustive. It is especially annoying because default tends to suppress compilers' exhaustiveness checking, which otherwise makes code more maintainable. Other things also break, such as conversion to string, which now has to be able to fail, and the caller has to deal with the possibility of failure.
To correctly avoid these complications in each case where they ought to be superfluous, the user has to be able to reason that only valid values are ever eliminated, and the reasoning has to be repeated each time the program is modified. The point of type safety is to make this reasoning trivial by guaranteeing this property for the user.
By comparison with these mistakes, an elimination that can silently convert an enum to a value of a type that is not restrictive is unfortunate, but not as big a deal. That's why I preferred to wrap in a class without a default constructor, at the cost of getting conversion semantics more similar to old enums – though, see this.

Of course, according to C++, enums don't have to have the value of one of their enumerands. Scoped enums are pretty much type safe up to this definition. But unscoped enums are type safe up to their definition as well – it's a circular argument. And, these are broken definitions in the opinions of many people, just like lack of serialization is broken in the opinions of many people.
And of course, Better Enums are still not type safe even without the default constructor, since there are still casts and _from_integral_unchecked. But those aren't implicit unless you implement an implicit conversion, and hopefully you can lint for them. If your project is small enough, you can simply be sure not to use them. So, Better Enums is also only an improvement in type safety.
It does break some programs (as does forbidding implicit conversion to integer). I am willing to change that in the interest of sane usage. It would be nice to see a definite use case, where the code isn't conceptually broken or can't make use of something like std::aligned_storage. I would change it for large "broken" codebases too, though.
I think imposing a default constructor globally on all programs using this library is a very "brutal" way to solve the problem of deserialization with defaults. You may also be using default constructors in other ways, but my point is you are assigning extra semantics to default constructors by your usage. I would be happy to support you usage somehow, but I don't want to damage other users who don't need these semantics and don't want the other implications of a default constructor.
If your code base is not immutable, perhaps you can switch to using a type trait, whose default behavior is to use a default constructor?

Also, why do you want default construction in this case? Or, what should the default constructor do? If it leaves the value undefined, and the surrounding code doesn't pre-initialize the memory, then how do you distinguish failure from a valid deserialized value? Or is that irrelevant in your code base?

If you think of enums as just semantic wrappers over integral types (which is really what they are) it makes more sense. Value initializing an enum is not undefined behavior as you mentioned. The value zero is within the limits of all numeric types in C++ which does not make the behavior undefined as you mentioned.
In the absence or abstinence of exceptions, value initialization is a great way to provide a stub value as a return if serialization fails. At that level, we aren't functioning on enumerations for some business logic. We handle them as primitive types.
Now does it makes sense to do anything with an enum that's been zero initialized but zero does not map to an enumerator? Of course not. But those aren't rules I defined. The language defined them. Maybe I'm the one in the wrong here making the assumption that it was your intention for your enums to be a semantic drop in replacement for normal enums.
In fact, after hearing your ideals, that does not seem to be the case. Maybe you shouldn't change anything. After all, given what you are trying to do, it doesn't make sense to allow it.

I didn't mention any undefined behavior at all. I mentioned a defined behavior of a default constructor that leaves the value of the enum undefined. I actually don't think that's even what is needed to get zero-initialization with a class type – I think I would need to have a = default default constructor.
In any case, do all your enum declarations begin with some sort of invalid value that represents deserialization failure? This is very similar to how Better Enums was used in the project it was originally created for, except there the default value didn't have to have representation 0. I may be able to support both in some sane way.

To quote you from your last 2 responses:

it's too easy to get a scoped enum with undefined value by default construction

and

If it leaves the value undefined, and the surrounding code doesn't pre-initialize the memory, then how do you distinguish failure from a valid deserialized value?

"Undefined" has a very specific definition in the standard. Nothing about value initializing an enum leaves it in an undefined state. The standard clearly defines it will be zero initialized when it is value initialized. Also enums are not default constructed. I apologize for initially using this term, it was a mistake on my part. They are value initialized in the very first example I gave you with the template function. To be crystal clear, the specific scenario I'm referring to is:
enum class MyEnumType { One=1, Two=2, Three=3 };
MyEnumType the_variable{}; // Value initialization; NOT default construction

the_variable will represent integral value 0 in this case, instead of an undefined value if I had not value initialized it (removing the {} would have this negative effect).
If you're referring to your own implementation, maybe that's where we're off on the wrong page here. But I'm strictly referring to built in enums.

Yes, that's why we may be on the wrong page, though I have been following what you are saying, with the exception of you having to remind me that your deserializer would use value-initialization on Better Enums in response to one of my questions.
I've been talking about how and whether to make Better Enums default constructible as per the issue title, in order to emulate zero initialization of scoped enums. I've been avoiding restriction to just talking about value initialization or zero initialization because that is a consequence of the site of the constructor call, not a property or function of the constructor (unless the constructor forces zero initialization of course, but that would fail to emulate scoped enums with automatic storage and unspecified value, and also be a rather arbitrary choice for a library to make, for other reasons).
Given value initialization is a property of the call site, I cannot directly control value initialization from inside Better Enums, but I can support it with the right choice of constructors – that's why it makes sense to talk about constructors and the implementation. It's just the next logical step in the conversation, and why I take it there. I do understand what you're saying, what your scenario is, and what is value initialization, and I am not sure why you think that I might not.
What I am saying is that what is necessary to support zero initialization for a class type, which is a default constructor of some kind, and probably an implicit one, is not an exact solution for just your scenario. It will produce undesirable effects at other kinds of call sites and in other enum usage patterns. I am giving this as a reason for my reluctance to just support it. I'm also inviting you to consider alternatives, or maybe suggest novel solutions or considerations that I haven't come up with, or correct misconceptions I may have about how to support zero initialization, if you should please to do so.
I also don't understand the problem with me mentioning the constructor leaving the value undefined (or perhaps, to be more precise, which value will result from construction is left undefined). Isn't this what the constructor would have to do to support zero initialization? Perhaps I should have called the state indeterminate, but it's certainly not undefined behavior. And, setting context aside, it is what you inherently get when you create a scoped enum without a value. Whether the context forces zero initialization of the enum or not is an entirely separate matter, and some contexts don't. Scoped enums don't have any special default value on their own (unlike objects with an explicit default constructor, for example, which is much harder to avoid calling) – and this is both a part of the type safety issue I was just explaining above, and the reason why emulation with a default constructor is slightly tricky.
The only other way I can think of getting zero initialization is to hardcode it into an explicit constructor, but that seems dubious. Is this what you had in mind?
So, if you don't mind, let's move along to the practicals – would you prefer Better Enums generate a plain scoped enum so you can have regular C++ semantics, with a parallel traits type you can use for serialization and optional validation? Would you prefer Better Enums generate wrapping classes that support some kind of pluggable default constructor policy? I suppose I can look into implementing the second one and get back to you when I have something that works.

With the commit above, you could create a wrapper header that looks like this:
#define BETTER_ENUMS_DEFAULT_CONSTRUCTOR(Enum) \
  public:                                      \
    Enum() = default;

#include <enum.h>

Then, use that in place of enum.h in your code base. The following program will then compile:
#include <customized_enum.h>
#include <cstdio>

BETTER_ENUM(Foo, int, a, b)

enum class Bar {c, d};

int main()
{
    Foo foo;
    Bar bar;

    printf("%i %i\n", foo._to_integral(), static_cast<int>(bar));

    return 0;
}

This prints garbage such as<PHONE_NUMBER> 32767 when I run it. Using value initialization on the variables (Foo foo{}, Bar bar{}) results in the output 0 0 instead, as desired.

Nice change. Have you given any thought to making this the default behavior? Seems desirable. It would give you the ability to add some sort of is_valid() method to verify that it properly maps to an enumerator, assuming you don't already have such a thing, or even assuming it is useful.

Yes, and maybe it is ultimately the right thing to do for the vast majority of users. But absent more feedback, I want to remain conservative with respect to type safety.
Regarding is_valid, here is one overload that is already present: is_valid.


Refactor linkerd-tcp to accomodate routing.

Prototype
The initial implementation is basically a prototype. It proves the concept, but it has
severe deficiencies that cause performance (and probably correctness) problems.
Specifically, it implements its own polling... poorly.
At startup, the configuration is parsed. For each proxy, the namerd and serving
configurations are split and connectd by an async channel so that namerd updates are
processed outside of the serving thread. All of the namerd watchers are collected to be
run together with the admin server. Once all of the proxy configurations are processed,
the application is run.
The admin thread is started, initiating all namerd polling and starting the admin server.
Simultaneously, all of the proxies are run in the main thread. For each of these, a
connector is created to determine how all downstream connections are established for
the proxy. A balancer is created with the connector and a stream of namerd updates. An
acceptor is created for each listening interface, which manifests as a stream of
connections, connections. The balancer is made shareable across servers by creating an
async channel and each server's connections are streamed into a sink clone. The balancer
is driven to process all of these connections.
The balancer implements a Sink that manages all I/O and connection management. Each
time Balancer::start_send or Balancer::poll_complete is called, the following work is
done:

all conneciton streams are checked for I/O and data is transfered;
closed connections are reaped;
service discovery is checked for updates;
new connections are established;
stats are recorded;

Lessons/Problems
Inflexible
This model doesn't really reflect that of linkerd. We have no mechanism to route
connections. All connections are simply forwarded. We cannot, for instance, route based on
client credentials or SNI destination.
Inefficient
Currently, each balancer is effectively a scheduler, and a pretty poor one at that. I/O
processing should be far more granular and we shouldn't update load balancer endpoints in
the I/O path (unless absolutely necessary).
Timeouts
We need several types of timeouts that are not currently implemented:

Connection timeout: time from incoming connection to outbound established.
Stream lifetime: maximum time a stream may stay open.
Idle timeout: maximum time a connection may stay open without transmitting data.

Proposal
linkerd-tcp should become a stream router. In the same way that linkerd routes requests,
linkerd-tcp should route connections. The following is a rough, evolving sketch of how
linkerd-tcp should be refactored to accomodate this:
The linkerd-tcp configuration should support one or more routers. Each router is
configured with one or more servers. A server, which may or may not terminate TLS,
produces a stream of incoming connections comprising an envelope--a source identity (an
address, but maybe more) and a destination name--and a bidirectional data stream. The
server may choose the destination by static configuration or as some function of the
connection (e.g. client credentials, SNI, etc). Each connection envelope may be annotated
with a standard set of metadata including, for example, an optional connect deadline,
stream deadline, etc.
The streams of all incoming connections for a router are merged into a single stream of
enveloped connections. This stream is forwarded to a binder. A binder is responsible
for maintaining a cache of balancers by destination name. When a balancer does not exist
in the cache, a new namerd lookup is initiated and its result stream (and value) is cached
so that future connections may resolve quickly. The binder obtains a balancer for each
destination name that maintains a list of endpoints and their load (in terms of
connections, throughput, etc).
If the inbound connection has not expired (i.e. due to a timeout), it is dispatched to the
balancer for processing. The balancer maintains a reactor handle and initiates I/O and
balancer state management on the reactor.
 ------       ------
| srv0 | ... | srvN |
 ------   |   ------
          |
          | (Envelope, IoStream)
          V
 -------------------      -------------
| binder            |----| interpreter |
 -------------------      -------------
  |
  V
 ----------
| balancer |
 ----------
  |
  V
 ----------
| endpoint |
 ----------
  |
  V
 --------
| duplex |
 --------

@olix0r this should have been closed by ea507f7.
FYI this doesn't do what you think:

Fixes #1 #2 #3"

Each issue needs its own "fixes":

Fixes #1
Fixes #2
Fixes #3


Anamorphic lenses?

Does this code support images from anamorphic lenses?
Would the intrinsic data be calculated correctly?
Also, how many parameters are returned for the distortion matrix?
Thanks!

FlowMap currently only supports pinhole projection with a uniform (shared across x and y) focal length and a principal point at the image center. It doesn't estimate distortion parameters. However, if you're interested in estimating distortion parameters, you could try to add them as regressed/directly optimized variables. I would be happy to provide more details on how to do so if you're interested!

As for anamorphic lenses, you could probably modify this function to take the anamorphic projection into account. For example, if the anamorphic projection just squeezes the normal projection by 2x on the X axis, you would have to account for the factor of two on line 17.


Operator-api and quotaapp deployed conditionally

Deploy these apps only if they are enabled

Feature: HCPCFS-2864

Pull Request Test Coverage Report for Build 4789

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 89.245%

Totals

Change from base Build 4774:
0.0%

Covered Lines:
9402

Relevant Lines:
10169

💛  - Coveralls