IncompleteCheckpointException causes substitution of input function return value by checkpoint output

Snakemake version
5.32.0
Describe the bug
I have a rule that uses an input function returning a dict with two elements, yet applying unpack on it seems to result in an InputFiles object with only one element. At some point, the input function waits for a checkpoint. The lone element obtained upon unpacking happens to match the thing waited for in checkpointing.
Minimal example
No minimal example yet, sorry: On minimal example attempts so far, I did not have this bug. I need to add some checkpointing into it to see what happens.
My input function is something like that:
def get_cell_cons_fasta(wildcards):
    # ...
    ali_fnames = {"TRA": [], "TRB": []}
    for chain in ["TRA", "TRB"]:
        # ...
        split_fa_dir = Path(checkpoints.split_merged.get(**wildcards, cell_id=cell_ids[chain]).output.split_dir)
        # ... [including some logging code that allows me to check the value of split_fa_dir]
        # ... [and some code appending file paths to ali_fnames[chain]]
    return {
        "a_ali_fnames": ali_fnames["TRA"],
        "b_ali_fnames": ali_fnames["TRB"]}

My rule is something like this:
rule summarize_consensus_sequences:
    input:
        unpack(get_cell_cons_fasta),
    # ...
    run:
        with open(log.log, "w") as log_fh:
            pseudo_input = get_cell_cons_fasta(wildcards)
            print(f"pseudo_input:\n{dir(pseudo_input)}\n{type(pseudo_input)}\n{len(pseudo_input)}\n{pseudo_input.keys()}\n{pseudo_input}", file=log_fh)
            print(f"input:\n{dir(input)}\n{type(input)}\n{len(input)}\n{input.keys()}\n{input}", file=log_fh)
            # ...

Example log content for one of this rule's instance:
pseudo_input:
['__class__', '__contains__', '__delattr__', '__delitem__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__getitem__'
, '__gt__', '__hash__', '__init__', '__init_subclass__', '__iter__', '__le__', '__len__', '__lt__', '__ne__', '__new__', '__reduce__', '__reduce_ex__
', '__repr__', '__reversed__', '__setattr__', '__setitem__', '__sizeof__', '__str__', '__subclasshook__', 'clear', 'copy', 'fromkeys', 'get', 'items'
, 'keys', 'pop', 'popitem', 'setdefault', 'update', 'values']
<class 'dict'>
2
dict_keys(['a_ali_fnames', 'b_ali_fnames'])
{'a_ali_fnames': ['/home/bli/tests/tmp/scTCR/TCR_seq_20190801_demux_out/demultiplexing_All/2/matched_R1_R2/consensuses/GCAGA_D12_TRA/GCAGA_D12_TRA_1_
aligned_clustalo_with_consensus.fasta'], 'b_ali_fnames': ['/home/bli/tests/tmp/scTCR/TCR_seq_20190801_demux_out/demultiplexing_All/2/matched_R1_R2/co
nsensuses/GCAGA_H12_TRB/GCAGA_H12_TRB_1_aligned_clustalo_with_consensus.fasta']}
input:
['__add__', '__class__', '__contains__', '__delattr__', '__delitem__', '__dict__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattr
ibute__', '__getitem__', '__gt__', '__hash__', '__iadd__', '__imul__', '__init__', '__init_subclass__', '__iter__', '__le__', '__len__', '__lt__', '_
_module__', '__mul__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__reversed__', '__rmul__', '__setattr__', '__setitem__', '__s
izeof__', '__str__', '__subclasshook__', '__weakref__', '_add_name', '_allitems', '_allowed_overrides', '_clone', '_get_names', '_insert_items', '_na
mes', '_plainstrings', '_set_name', '_stripped_constraints', '_take_names', '_used_attribute', 'append', 'clear', 'copy', 'count', 'extend', 'get', '
index', 'insert', 'items', 'keys', 'pop', 'remove', 'reverse', 'size', 'size_mb', 'sort']
<class 'snakemake.io.InputFiles'>
1
dict_keys([])
/home/bli/tests/tmp/scTCR/TCR_seq_20190801_demux_out/demultiplexing_All/2/matched_R1_R2/split/GCAGA_D12_TRA

We can see that the dict returned by the input function has two items, with keys "'a_ali_fnames" and "b_ali_fnames", but that the input object resulting from unpacking this has only one "thing", which actually happens to match the value of split_fa_dir when the input function was on the "TRA" round of its for loop, as I can see by looking at the log generated by the input function: /home/bli/tests/tmp/scTCR/TCR_seq_20190801_demux_out/demultiplexing_All/2/matched_R1_R2/split/GCAGA_D12_TRA.
Additional context
I had very strange bugs while developping this workflow on a slurm cluster, including things apparently related to checkpointing and discrepancies between reported rule instance input between the main log and logs generated by slurm cluster jobs. It is only after deciding to simplify the situation by eliminating the cluster factor (working on a normal linux computer) that I came up with the above bug, which may be at the root of my previous difficulties.
I will try to reproduce it on a simplified example now, but this looks quite weird for the moment.

I think I more or less reproduced the bug on a not-so-minimal example:
from pathlib import Path
from random import randint
import sys

rule all:
    input:
        "all.txt"

wildcard_constraints:
    letter = "A|B",

checkpoint create_input:
    output:
        out_dir = directory("{letter}"),
    run:
        Path(output.out_dir).mkdir(parents=True, exist_ok=True)
        prefix = wildcards.letter.lower()
        assert prefix in {"a", "b"}, prefix
        for i in range(randint(1, 5)):
            shell(f"touch {output.out_dir}/{prefix}_{i}.txt")

def get_filenums(out_dir):
    for filename in out_dir.glob("*.txt"):
        #print(f"filename (inside): {filename}")
        filenum = filename.name[:-4].split("_")[1]
        #print(f"filenum (inside): {filenum}")
        yield filenum

def get_infile(wildcards):
    out_dir = Path(checkpoints.create_input.get(**wildcards).output.out_dir)
    print(f"We want a file in {out_dir}")
    print(f"Will return this one: {wildcards.prefix}_{wildcards.i}.txt")
    return out_dir.joinpath(f"{wildcards.prefix}_{wildcards.i}.txt")

rule intermediate:
    input:
        infile = get_infile,
    output:
        outfile = "intermediate/{letter}/{prefix}_{i}.txt"
    run:
        print(f"input for intermediate rule: {input.infile}")
        parent = Path(output.outfile).parent
        parent.mkdir(parents=True, exist_ok=True)
        print(f"created {parent}")
        cmd = f"cp {input.infile} {output.outfile}"
        print(f"cmd:\n{cmd}")
        shell(cmd)

def find_input(wildcards):
    expected_files = {"A": [], "B": []}
    a_out_dir = Path(checkpoints.create_input.get(**wildcards, letter="A").output.out_dir)
    for filenum in get_filenums(a_out_dir):
        print(f"filenum: {filenum}")
        expected_files["A"].append(f"intermediate/A/a_{filenum}.txt")
    b_out_dir = Path(checkpoints.create_input.get(**wildcards, letter="B").output.out_dir)
    for filenum in get_filenums(b_out_dir):
        print(f"filenum: {filenum}")
        expected_files["B"].append(f"intermediate/B/b_{filenum}.txt")
    print("expected files")
    print(expected_files)
    return expected_files

rule do:
    input:
        unpack(find_input),
    output:
        "all.txt"
    run:
        pseudo_input = find_input(wildcards)
        print(pseudo_input)
        print(pseudo_input.keys())
        print(input)
        print(input.keys())
        if hasattr(input, "A") and len(input.A):
            print(input.A)
        else:
            print("No A")
        if hasattr(input, "B") and len(input.B):
            print(input.B)
        else:
            print("No B")
        shell("touch all.txt")

This fails during the execution of the intermediate rule because it tries cp B intermediate/B/b_1.txt:
The stdout log for this rule says:
input for intermediate rule: B
created intermediate/B
cmd:
cp B intermediate/B/b_1.txt

And the stderr log says:
cp: -r not specified; omitting directory 'B'
...
CalledProcessError in line 53 of /home/bli/tests/tmp/scTCR/debug/test.snakefile:
Command 'set -euo pipefail;  cp B intermediate/B/b_1.txt' returned non-zero exit status 1.

The stdout log ends with manifestations of get_infile being executed, apparently as expected:
We want a file in A
Will return this one: a_0.txt
We want a file in A
Will return this one: a_1.txt
We want a file in A
Will return this one: a_2.txt
We want a file in A
Will return this one: a_3.txt
We want a file in A
Will return this one: a_4.txt
We want a file in B
Will return this one: b_0.txt
We want a file in B
Will return this one: b_1.txt
We want a file in B
Will return this one: b_2.txt

I'm not sure anymore that unpack is involved.

I think I more or less reproduced the bug on a not-so-minimal example:
from pathlib import Path
from random import randint
import sys

rule all:
    input:
        "all.txt"

wildcard_constraints:
    letter = "A|B",

checkpoint create_input:
    output:
        out_dir = directory("{letter}"),
    run:
        Path(output.out_dir).mkdir(parents=True, exist_ok=True)
        prefix = wildcards.letter.lower()
        assert prefix in {"a", "b"}, prefix
        for i in range(randint(1, 5)):
            shell(f"touch {output.out_dir}/{prefix}_{i}.txt")

def get_filenums(out_dir):
    for filename in out_dir.glob("*.txt"):
        #print(f"filename (inside): {filename}")
        filenum = filename.name[:-4].split("_")[1]
        #print(f"filenum (inside): {filenum}")
        yield filenum

def get_infile(wildcards):
    out_dir = Path(checkpoints.create_input.get(**wildcards).output.out_dir)
    print(f"We want a file in {out_dir}")
    print(f"Will return this one: {wildcards.prefix}_{wildcards.i}.txt")
    return out_dir.joinpath(f"{wildcards.prefix}_{wildcards.i}.txt")

rule intermediate:
    input:
        infile = get_infile,
    output:
        outfile = "intermediate/{letter}/{prefix}_{i}.txt"
    run:
        print(f"input for intermediate rule: {input.infile}")
        parent = Path(output.outfile).parent
        parent.mkdir(parents=True, exist_ok=True)
        print(f"created {parent}")
        cmd = f"cp {input.infile} {output.outfile}"
        print(f"cmd:\n{cmd}")
        shell(cmd)

def find_input(wildcards):
    expected_files = {"A": [], "B": []}
    a_out_dir = Path(checkpoints.create_input.get(**wildcards, letter="A").output.out_dir)
    for filenum in get_filenums(a_out_dir):
        print(f"filenum: {filenum}")
        expected_files["A"].append(f"intermediate/A/a_{filenum}.txt")
    b_out_dir = Path(checkpoints.create_input.get(**wildcards, letter="B").output.out_dir)
    for filenum in get_filenums(b_out_dir):
        print(f"filenum: {filenum}")
        expected_files["B"].append(f"intermediate/B/b_{filenum}.txt")
    print("expected files")
    print(expected_files)
    return expected_files

rule do:
    input:
        unpack(find_input),
    output:
        "all.txt"
    run:
        pseudo_input = find_input(wildcards)
        print(pseudo_input)
        print(pseudo_input.keys())
        print(input)
        print(input.keys())
        if hasattr(input, "A") and len(input.A):
            print(input.A)
        else:
            print("No A")
        if hasattr(input, "B") and len(input.B):
            print(input.B)
        else:
            print("No B")
        shell("touch all.txt")

This fails during the execution of the intermediate rule because it tries cp B intermediate/B/b_1.txt:
The stdout log for this rule says:
input for intermediate rule: B
created intermediate/B
cmd:
cp B intermediate/B/b_1.txt

And the stderr log says:
cp: -r not specified; omitting directory 'B'
...
CalledProcessError in line 53 of /home/bli/tests/tmp/scTCR/debug/test.snakefile:
Command 'set -euo pipefail;  cp B intermediate/B/b_1.txt' returned non-zero exit status 1.

The stdout log ends with manifestations of get_infile being executed, apparently as expected:
We want a file in A
Will return this one: a_0.txt
We want a file in A
Will return this one: a_1.txt
We want a file in A
Will return this one: a_2.txt
We want a file in A
Will return this one: a_3.txt
We want a file in A
Will return this one: a_4.txt
We want a file in B
Will return this one: b_0.txt
We want a file in B
Will return this one: b_1.txt
We want a file in B
Will return this one: b_2.txt

I'm not sure anymore that unpack is involved.

I'm trying to follow what is going on using print statements in snakemake's code, and the wrong input I get seems to be returned by handle_incomplete_checkpoint (defined in rules.py), which returns exception.targetfile.
If I'm following correctly, this is set when instantiating IncompleteCheckpointException (defined in exceptions.py), which occurs in checkpoints.py in the get method of Checkpoint, which returns something that is basically the output of the checkpoint.
I don't know what the expected logic was, but the rest of the input function (which should compute the actual desired input based in the output of the checkpoint) is somewhat ignored.
@johanneskoester Any idea when and how the rest of the input function was supposed to be executed?

I'm trying to follow what is going on using print statements in snakemake's code, and the wrong input I get seems to be returned by handle_incomplete_checkpoint (defined in rules.py), which returns exception.targetfile.
If I'm following correctly, this is set when instantiating IncompleteCheckpointException (defined in exceptions.py), which occurs in checkpoints.py in the get method of Checkpoint, which returns something that is basically the output of the checkpoint.
I don't know what the expected logic was, but the rest of the input function (which should compute the actual desired input based in the output of the checkpoint) is somewhat ignored.
@johanneskoester Any idea when and how the rest of the input function was supposed to be executed?

I notice that loop variable item is replaced in _apply_wildcards. This can replace an input function object by the result of apply_input_function, which, as per the previous observations, can be the checkpoint output.

I notice that loop variable item is replaced in _apply_wildcards. This can replace an input function object by the result of apply_input_function, which, as per the previous observations, can be the checkpoint output.

Could the problem arise because I'm waiting for the same checkpoint in different input functions?

I can indeed compare two not-so-minimal examples, one with the same checkpoint waited for in different input functions, and the other using different checkpoints. The second one doesn't exhibit the "wrong input" behaviour.
First case:
from pathlib import Path
from random import randint
import sys

rule all:
    input:
        "results/all.txt"

wildcard_constraints:
    letter = "A|B",

checkpoint create_input:
    output:
        out_dir = directory("results/{letter}"),
    run:
        print("checkpoint create_input: creating", output.out_dir)
        Path(output.out_dir).mkdir(parents=True, exist_ok=True)
        prefix = wildcards.letter.lower()
        assert prefix in {"a", "b"}, prefix
        for i in range(randint(1, 5)):
            shell(f"touch {output.out_dir}/{prefix}_{i}.txt")
        print("checkpoint create_input:", output.out_dir, "should be ready and contain input files.")

def get_filenums(out_dir):
    for filename in out_dir.glob("*.txt"):
        #print(f"filename (inside): {filename}")
        filenum = filename.name[:-4].split("_")[1]
        #print(f"filenum (inside): {filenum}")
        yield filenum

def get_infile(wildcards):
    print("get_infile: Waiting for out_dir from checkpoint create_input with the following wildcards:", wildcards)
    out_dir = Path(checkpoints.create_input.get(**wildcards).output.out_dir)
    print(f"get_infile: We want a file in {out_dir}")
    result = out_dir.joinpath(f"{wildcards.prefix}_{wildcards.i}.txt")
    print(f"get_infile will return this one:", result)
    return out_dir.joinpath(f"{wildcards.prefix}_{wildcards.i}.txt")

rule intermediate:
    input:
        infile = get_infile,
    output:
        outfile = "results/intermediate/{letter}/{prefix}_{i}.txt"
    run:
        print(f"input for intermediate rule: {input.infile}")
        if config.get("nocrash", False):
            pseudo_input = get_infile(wildcards)
            print(f"pseudo_input for intermediate rule: {pseudo_input}")
            cmd = f"cp {pseudo_input} {output.outfile}"
        else:
            cmd = f"cp {input.infile} {output.outfile}"
        parent = Path(output.outfile).parent
        parent.mkdir(parents=True, exist_ok=True)
        print(f"created {parent}")
        print(f"cmd:\n{cmd}")
        shell(cmd)

def find_input(wildcards):
    expected_files = {"A": [], "B": []}
    a_out_dir = Path(checkpoints.create_input.get(**wildcards, letter="A").output.out_dir)
    for filenum in get_filenums(a_out_dir):
        print(f"filenum: {filenum}")
        expected_files["A"].append(f"results/intermediate/A/a_{filenum}.txt")
    b_out_dir = Path(checkpoints.create_input.get(**wildcards, letter="B").output.out_dir)
    for filenum in get_filenums(b_out_dir):
        print(f"filenum: {filenum}")
        expected_files["B"].append(f"results/intermediate/B/b_{filenum}.txt")
    print("expected files")
    print(expected_files)
    return expected_files

rule do:
    input:
        unpack(find_input),
    output:
        "results/all.txt"
    run:
        pseudo_input = find_input(wildcards)
        print(pseudo_input)
        print(pseudo_input.keys())
        print(input)
        print(input.keys())
        if hasattr(input, "A") and len(input.A):
            print(input.A)
        else:
            print("No A")
        if hasattr(input, "B") and len(input.B):
            print(input.B)
        else:
            print("No B")
        shell("touch results/all.txt")

Second case:
from pathlib import Path
from random import randint
import sys

rule all:
    input:
        "results/all.txt"

wildcard_constraints:
    letter = "A|B",

checkpoint create_input:
    output:
        out_dir = directory("results/{letter}"),
    run:
        print("checkpoint create_input: creating", output.out_dir)
        Path(output.out_dir).mkdir(parents=True, exist_ok=True)
        prefix = wildcards.letter.lower()
        assert prefix in {"a", "b"}, prefix
        for i in range(randint(1, 5)):
            shell(f"touch {output.out_dir}/{prefix}_{i}.txt")
        print("checkpoint create_input:", output.out_dir, "should be ready and contain input files.")

def get_filenums(out_dir):
    for filename in out_dir.glob("*.txt"):
        #print(f"filename (inside): {filename}")
        filenum = filename.name[:-4].split("_")[1]
        #print(f"filenum (inside): {filenum}")
        yield filenum

def get_infile(wildcards):
    print("get_infile: Waiting for out_dir from checkpoint create_input with the following wildcards:", wildcards)
    out_dir = Path(checkpoints.create_input.get(**wildcards).output.out_dir)
    print(f"get_infile: We want a file in {out_dir}")
    result = out_dir.joinpath(f"{wildcards.prefix}_{wildcards.i}.txt")
    print(f"get_infile will return this one:", result)
    return out_dir.joinpath(f"{wildcards.prefix}_{wildcards.i}.txt")

checkpoint intermediate:
    input:
        infile = get_infile,
    output:
        outfile = "results/intermediate/{letter}/{prefix}_{i}.txt"
    run:
        print(f"input for intermediate rule: {input.infile}")
        if config.get("nocrash", False):
            pseudo_input = get_infile(wildcards)
            print(f"pseudo_input for intermediate rule: {pseudo_input}")
            cmd = f"cp {pseudo_input} {output.outfile}"
        else:
            cmd = f"cp {input.infile} {output.outfile}"
        parent = Path(output.outfile).parent
        parent.mkdir(parents=True, exist_ok=True)
        print(f"created {parent}")
        print(f"cmd:\n{cmd}")
        shell(cmd)

def find_input(wildcards):
    expected_files = {"A": [], "B": []}
    a_out_dir = Path(checkpoints.intermediate.get(**wildcards, letter="A", prefix="a", i="0").output.outfile).parent
    for filenum in get_filenums(a_out_dir):
        print(f"filenum: {filenum}")
        expected_files["A"].append(f"results/intermediate/A/a_{filenum}.txt")
    b_out_dir = Path(checkpoints.intermediate.get(**wildcards, letter="B", prefix="b", i="0").output.outfile).parent
    for filenum in get_filenums(b_out_dir):
        print(f"filenum: {filenum}")
        expected_files["B"].append(f"results/intermediate/B/b_{filenum}.txt")
    print("expected files")
    print(expected_files)
    return expected_files

rule do:
    input:
        unpack(find_input),
    output:
        "results/all.txt"
    run:
        pseudo_input = find_input(wildcards)
        print(pseudo_input)
        print(pseudo_input.keys())
        print(input)
        print(input.keys())
        if hasattr(input, "A") and len(input.A):
            print(input.A)
        else:
            print("No A")
        if hasattr(input, "B") and len(input.B):
            print(input.B)
        else:
            print("No B")
        shell("touch results/all.txt")

Could the problem arise because I'm waiting for the same checkpoint in different input functions?

I can indeed compare two not-so-minimal examples, one with the same checkpoint waited for in different input functions, and the other using different checkpoints. The second one doesn't exhibit the "wrong input" behaviour.
First case:
from pathlib import Path
from random import randint
import sys

rule all:
    input:
        "results/all.txt"

wildcard_constraints:
    letter = "A|B",

checkpoint create_input:
    output:
        out_dir = directory("results/{letter}"),
    run:
        print("checkpoint create_input: creating", output.out_dir)
        Path(output.out_dir).mkdir(parents=True, exist_ok=True)
        prefix = wildcards.letter.lower()
        assert prefix in {"a", "b"}, prefix
        for i in range(randint(1, 5)):
            shell(f"touch {output.out_dir}/{prefix}_{i}.txt")
        print("checkpoint create_input:", output.out_dir, "should be ready and contain input files.")

def get_filenums(out_dir):
    for filename in out_dir.glob("*.txt"):
        #print(f"filename (inside): {filename}")
        filenum = filename.name[:-4].split("_")[1]
        #print(f"filenum (inside): {filenum}")
        yield filenum

def get_infile(wildcards):
    print("get_infile: Waiting for out_dir from checkpoint create_input with the following wildcards:", wildcards)
    out_dir = Path(checkpoints.create_input.get(**wildcards).output.out_dir)
    print(f"get_infile: We want a file in {out_dir}")
    result = out_dir.joinpath(f"{wildcards.prefix}_{wildcards.i}.txt")
    print(f"get_infile will return this one:", result)
    return out_dir.joinpath(f"{wildcards.prefix}_{wildcards.i}.txt")

rule intermediate:
    input:
        infile = get_infile,
    output:
        outfile = "results/intermediate/{letter}/{prefix}_{i}.txt"
    run:
        print(f"input for intermediate rule: {input.infile}")
        if config.get("nocrash", False):
            pseudo_input = get_infile(wildcards)
            print(f"pseudo_input for intermediate rule: {pseudo_input}")
            cmd = f"cp {pseudo_input} {output.outfile}"
        else:
            cmd = f"cp {input.infile} {output.outfile}"
        parent = Path(output.outfile).parent
        parent.mkdir(parents=True, exist_ok=True)
        print(f"created {parent}")
        print(f"cmd:\n{cmd}")
        shell(cmd)

def find_input(wildcards):
    expected_files = {"A": [], "B": []}
    a_out_dir = Path(checkpoints.create_input.get(**wildcards, letter="A").output.out_dir)
    for filenum in get_filenums(a_out_dir):
        print(f"filenum: {filenum}")
        expected_files["A"].append(f"results/intermediate/A/a_{filenum}.txt")
    b_out_dir = Path(checkpoints.create_input.get(**wildcards, letter="B").output.out_dir)
    for filenum in get_filenums(b_out_dir):
        print(f"filenum: {filenum}")
        expected_files["B"].append(f"results/intermediate/B/b_{filenum}.txt")
    print("expected files")
    print(expected_files)
    return expected_files

rule do:
    input:
        unpack(find_input),
    output:
        "results/all.txt"
    run:
        pseudo_input = find_input(wildcards)
        print(pseudo_input)
        print(pseudo_input.keys())
        print(input)
        print(input.keys())
        if hasattr(input, "A") and len(input.A):
            print(input.A)
        else:
            print("No A")
        if hasattr(input, "B") and len(input.B):
            print(input.B)
        else:
            print("No B")
        shell("touch results/all.txt")

Second case:
from pathlib import Path
from random import randint
import sys

rule all:
    input:
        "results/all.txt"

wildcard_constraints:
    letter = "A|B",

checkpoint create_input:
    output:
        out_dir = directory("results/{letter}"),
    run:
        print("checkpoint create_input: creating", output.out_dir)
        Path(output.out_dir).mkdir(parents=True, exist_ok=True)
        prefix = wildcards.letter.lower()
        assert prefix in {"a", "b"}, prefix
        for i in range(randint(1, 5)):
            shell(f"touch {output.out_dir}/{prefix}_{i}.txt")
        print("checkpoint create_input:", output.out_dir, "should be ready and contain input files.")

def get_filenums(out_dir):
    for filename in out_dir.glob("*.txt"):
        #print(f"filename (inside): {filename}")
        filenum = filename.name[:-4].split("_")[1]
        #print(f"filenum (inside): {filenum}")
        yield filenum

def get_infile(wildcards):
    print("get_infile: Waiting for out_dir from checkpoint create_input with the following wildcards:", wildcards)
    out_dir = Path(checkpoints.create_input.get(**wildcards).output.out_dir)
    print(f"get_infile: We want a file in {out_dir}")
    result = out_dir.joinpath(f"{wildcards.prefix}_{wildcards.i}.txt")
    print(f"get_infile will return this one:", result)
    return out_dir.joinpath(f"{wildcards.prefix}_{wildcards.i}.txt")

checkpoint intermediate:
    input:
        infile = get_infile,
    output:
        outfile = "results/intermediate/{letter}/{prefix}_{i}.txt"
    run:
        print(f"input for intermediate rule: {input.infile}")
        if config.get("nocrash", False):
            pseudo_input = get_infile(wildcards)
            print(f"pseudo_input for intermediate rule: {pseudo_input}")
            cmd = f"cp {pseudo_input} {output.outfile}"
        else:
            cmd = f"cp {input.infile} {output.outfile}"
        parent = Path(output.outfile).parent
        parent.mkdir(parents=True, exist_ok=True)
        print(f"created {parent}")
        print(f"cmd:\n{cmd}")
        shell(cmd)

def find_input(wildcards):
    expected_files = {"A": [], "B": []}
    a_out_dir = Path(checkpoints.intermediate.get(**wildcards, letter="A", prefix="a", i="0").output.outfile).parent
    for filenum in get_filenums(a_out_dir):
        print(f"filenum: {filenum}")
        expected_files["A"].append(f"results/intermediate/A/a_{filenum}.txt")
    b_out_dir = Path(checkpoints.intermediate.get(**wildcards, letter="B", prefix="b", i="0").output.outfile).parent
    for filenum in get_filenums(b_out_dir):
        print(f"filenum: {filenum}")
        expected_files["B"].append(f"results/intermediate/B/b_{filenum}.txt")
    print("expected files")
    print(expected_files)
    return expected_files

rule do:
    input:
        unpack(find_input),
    output:
        "results/all.txt"
    run:
        pseudo_input = find_input(wildcards)
        print(pseudo_input)
        print(pseudo_input.keys())
        print(input)
        print(input.keys())
        if hasattr(input, "A") and len(input.A):
            print(input.A)
        else:
            print("No A")
        if hasattr(input, "B") and len(input.B):
            print(input.B)
        else:
            print("No B")
        shell("touch results/all.txt")

I confirmed that your minimal examples failed on 5.32.0, but they all complete with 7.1.1.
Okay to close?


Removed source code comments with unoptimal TODO/FIXME items

RX iGate should not drop removed duplicates or filter packets it deems incorrect by content, as that is error-prone and hides broken packets in a way that no-one can diagnose them. The recipient on the APRS-IS can decode, ignore or report bad packets.
Removed source code comments which suggested doing so.

Agreed. Thanks

Related question: What should the policy be for APRS I-gates on validating AX.25 PID fields as 0xF0? Or are we not too concerned with non-APRS traffic leaking onto the -IS?

Well, I personally think it should validate that. It's not great if there's, for example, APRS trackers built and distributed with incorrect PID and it accidentally works.
There was the precedent of trying OpenTrac protocol on 144.390 using a different AX.25 PID; a lot of igates did not check the PID and it created quite a bit of confusion.

Merged


botplay

not sure if erizur allows this but since im tired of spamming (and some engines like Psych and Kade, have Botplay) i decided to make botplay a real option so you dont have to compile just for botplay (it was unused in vs dave so why not)
also this might need testing since its buggy but its sort of on par with kade's botplay so please dont blame me for that

hmm lets review

actually nvm good point

nice but why do we even need botplay first of all its not like people are gonna make fansongs that are spammy lol

botplay doesnt work well with spammy fansongs tho!!!! but its probably for those who are too lazy to spam yet is bad at fnf

hope erizur allows this since im bad at fnf myself so ye

well since @CharlesCatYT you decided to abandon the PR, I'll fix the issues myself then

well since @CharlesCatYT you decided to abandon the PR, I'll fix the issues myself then

i didnt, i was busy on other shit

alright


feat: query builder for cursor pagination

:tada: This PR is included in version 0.5.0 :tada:
The release is available on:

GitHub release
v0.5.0

Your semantic-release bot :package::rocket:


flush when Exception fire in case isNeedFlush = false

Pull Request Test Coverage Report for Build 7152

0 of 1 (0.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 20.107%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

sharding-proxy/sharding-proxy-frontend/sharding-proxy-frontend-core/src/main/java/org/apache/shardingsphere/shardingproxy/frontend/command/CommandExecutorTask.java
0
1
0.0%

Totals

Change from base Build 7151:
0.0%

Covered Lines:
8188

Relevant Lines:
40722

💛  - Coveralls


[RFC] First class type support

This is kind of part of #214 but it stands for itself too.
Something like:
@attr.s(check_types=True)
class C:
    x = attr.ib(type=int)

ought to work.
Regardless of checking the type, the type information has to be accessible somewhere so we can have first-class deserialization support.

+1

This would be awesome! Is the goal to enable type checking within attrs itself? and to support types as listed in typing.py? There's a few caveats that we've discovered, diving in.
1 is there's no standardized type checking behavior for collections in typing. From my understanding, this is still an area that needs more work:
https://github.com/python/typing/issues/136
Most people have been writing their own type validation libraries to compensate:
https://pypi.python.org/pypi/typeguard
All in all, I'm a huge fan of this direction. Just wondering what the choice is for type checker.

We don’t have concrete plans yet!  Mostly because we want to make types & serialization first class concepts in attrs while doing this. :)

Wait, wrong ticket! :) Yeah, no still no idea yet!

I have a couple thoughts on this, if you're looking for ideas.
The type parameters should probably be equivalent to adding two behavior: validate and convert:
new_style = attr.ib(type=int)
old_style = attr.ib(validator=validators.instance_of(int), converter=int)

This works pretty well for primitive types. There's some nastiness with more complex types, which attrs probably shouldn't solve. For example, I'd expect to be able to do something like:
from datetime import daytime

@attr.s
class X:
    date = attr.ib(type=datetime)

# epoch
x = X(date=1092183940129)
# ISO 8601 string
x = X(date="2017-06-30T14:14:57Z")

but these would fail, because the datetime constructor takes none of these.
I would argue probably just not handling this case, and letting people override with whatever complex converters they prefer:
attr.ib(type=datetime, converter=my_complex_converter)

The other part is using or supporting typing modules. this will require some choices in behavior (e.g. validating types recursively, or just validating the top level collection for collection types). I prefer recursive validation and conversion, personally.

Yes, feel  free to dump all your thoughts.  The more input we get beforehand, the less mistakes we’re likely to make. :)

OK, let's split the proposal into sub-features for easier commenting.
Create the type metadata

Adding a type parameter to attr.ib().

@attr.s
class C:
    x = attr.ib(type=int)

Presumably fields(C).x.type would be int then. I'm generally in favor of this. I already have a system like this in place for cattrs, except it uses metadata. I think this should be the backup though, for Pythons before 3.6. The 3.6 syntax reads much better for me.
@attr.s
class C:
    x: int = attr.ib()

So basically like #214, but with the type argument for older Pythons.
So what do we do with this data?
Static checks
My personal opinion is that static analysis is the future here. This means writing a MyPy plugin (which coincidentally I kinda promised to do, but I won't get around to until my main vacation at the end of July, probably), and maybe getting other vendors (flake8, pylint, pycharm...) in this space to cooperate too.
Static analysis has two major advantages. The first is that some types are impossible or exceedingly difficult to check for in runtime - think Iterator[int]. The other is performance. Generics in general are problematic.
@attr.s
class C:
    x: List[int] = attr.ib()

inst = C(list(range(1000)))  # Do what - iterate over the entire list?
inst.x.append('a string')  # No one will complain in the runtime here.

Even if you have simple type annotations, without generics, the isinstance calls are kinda heavy. IIRC for ints it's actually less expensive to use a convert=int than validator=instance_of(int), even though they aren't exactly the same.
This isn't me getting into static vs dynamic typing, just stating the fact that static types are a tool with advantages over doing it in runtime. We're getting them in Python and it's exciting!
We will still need validators since validators can check the values of types, and MyPy can't. So you will always need a validator to ensure your int is positive, for example.
Now, as I mentioned, this is probably the future. We can't really rely on this today since MyPy doesn't even support the easy cases of attrs classes.
Runtime checks
There is still value in runtime checking, of course. Not everyone will be able or willing to run MyPy over their code base, or maybe you want checks in the REPL, so us having a nice API for this would be good. This will require a little logic in our type validation, since not all types from typing can be used with isinstance.
The runtime type checks should be opt-in. I'm not sure if the opt-in should be on the class level (I feel like we'd need an opt-out at the attribute level) or at the attribute level, or both.
Let's experiment with some ideas for attribute-level opt-in.
from attr.validators import validate_type

def positive(_, __, val):
    if val <= 0:
        raise ValueError

@attr.s
class C:
    x: int = attr.ib(validator=validate_type)  # Magic! Requires additional support in attrs.
    y: int = attr.ib(validator=[validate_type, positive])
    z: int = attr.ib(validator=validate_type(positive))

I agree that at least, introducing the type attribute and doing nothing but attaching it to the field would be great. It's a fantastic building block to build off of.
It would also be great to fold in the type definition into the attr.ib object, if possible, so
x = attr.ib(type=int)

and
x: int = attr.ib()

are functionally equal (if both are declared, attr.ib(type=foo) could take precedence).
I know there's an existing PR around attrs support for MyPy, so that'll handle the static checks at some point.
Personally, I'm more interested in the dynamic checks. I'd like to integrate it as a serializer for an API validation library I've been working on (http://transmute-core.readthedocs.io/en/latest/), and attrs has a great philosophy with performance as a feature.
Regarding the way validation is declared, validate_type seems syntactically the nicest. Although the complexities of type validation is definitely a larger ordeal. A lot of choices as @Tinche points out. validate_type could do shallow or deep validation, and that's control you may want to leave to the user.
Providing simple integrations with existing runtime type checking / conversion tooling might be better. e.g. typeguard or cattrs.

I'm drinking Aperol Spritz by Lake Como right now but briefly:

Yes, I want .type as a building block and a dedicated validator that doesn't take further arguments.  Everything just composes nicely.  We may add a specific argument to attr.s that implicitly adds the validator to all fields.  We'll see.  As it should be obvious by now, I'm very anti runtime costs.  :)
I think declaring two types should blow up.

More when I'm back after EP.  Although I may sprint on it.

Turns out I didn’t and went to San Marino instead!

Anyhow, so far we seem to have a consensus that:

we add a new field to the Attribute class called type
which can be set using x = attr.ib(type=int) if your life sucks and you can’t use Python 3.6
using  x: int = attr.ib() if life is wonderful.
Additionally we’ll add a validator called check_type which will look at the type attribute and check.

Correct?
So far that seems rather straightforward.
I’d just like to make 100% sure that it won’t paint us in a corner re: deserialization?  I’d like explicit comments from the two who built deserialization on top of attrs: @glyph and @Tinche

I'm 100% on board with what you wrote FWIW.

FYI this is a very busy weekend for me but this is definitely in my queue to look at soon.

Cool, but don't overthink it.   This is but a first building block. :)

👊 @glyph
(that’s a fist bump, not an attempt of intimidation thru violence :))

That (type attribute) seems like a solid first step.

@Tinche I'm thinking about your validate_type examples and I think it has legs.
But I'm wondering if it could also have global (ew?) switch of some sort.  Since type validation, as you note, can be expensive, it's nice to do it statically if possible, but…
The runtime case I'd want to check is when unit testing, I think, just in case the static analysis toolchain is missing something.  At least today, there are a lot of cases where mypy let's things slip, because it was hard to annotate something correctly so someone used Any, or you are getting a value from a library with no type hints or your code is only partly hinted, etc.
So I think there's a use case for: do validation when unit testing but not otherwise.
Perhaps I'm asking for a more fine-grained version of attr.set_run_validators…

Personally I'd rather have validation turned on all the time by default; I care more about correctness than speed.  I want to rely on this to validate types when constructing them from wire formats.  On PyPy, these isinstance checks will be no-opped out on the loops where they pass anyway, won't we?

@wsanchez fun fact: the reason behind attr.set_run_validators is precisely your use case. :)   Because I want more checks at tests and less at runtime.  attrs grew since its introduction, so things are more complicated now…
@glyph I agree on correctness > speed, however adding an implicit handbrake like this makes me uneasy.  The big question is: has static type checking a future in Python or not?  IOW: there will be a check_types in any case, but we’ll have to decide it’s default.
I personally tend to False, especially because we’ll most likely need to introduce a dependency on something like type guard, to do it properly.

@glyph I'm mostly in your camp, just trying to be sympathetic to the argument that sometimes, the validation is expensive overkill.  That is, I might have a model object that, when I deserialize to it from JSON, I totally wan't validation, but when I read it from the database that I'm confident only have valid data, I might want to skip the validation, because I can test that pretty thoroughly.
I don't know what magic PyPy does to be smarter than me, and perhaps I should never optimize anything because PyPy will always do it better.  Though I can't use PyPy yet, because at this point, I'm entered the "if it's not >=Py3.6, it's BULLSHIT" phase of my life.  :-)

It's a good phase of life – enjoying not myself too.
In seriousness: unless someone comes up with a magical solution to validating types that goes beyond isinstance and doesn't introduce a new dependency, the default is settled.

I am using isinstance in my thing, but I'm not using the type directly.  Specifically, here's a relevant function, which isn't complete:
def appropriate_type(T):
    if isunion(T):
        return tuple(appropriate_type(arg) for arg in T.__args__)
    if issubclass(T, typing.List):
        return list
    if issubclass(T, typing.Dict):
        return dict
    if issubclass(T, typing.Set):
        return set
    return T

FWIW, the relevant function seems to be https://github.com/agronholm/typeguard/blob/master/typeguard.py#L348
Also the pkg is by @agronholm and I have a hunch he may be open to persuasion to donate a validator to us. :)
I’m still against adding a handbrake by default – it just feels wrong. :|

How would you feel if we added an alternate, non-type-checked classmethod constructor?  Foo.raw for example?

a nocheck argument is a nice piece in general. great to just instantiate things as fast as possible if you're really confident the data is valid.
I'm +1 for no default type checking. It's a big change from the existing assumption that the validation is explicit, and I really like attrs because it's a nice syntax around creating classes, and keeps the classes lean.

If you don't want this type of type checking, don't pass type=?

@glyph I thought the idea was that type= is superfluous:
   x: int = attribute()   # Implies type=int

type could be useful for other things, like feeding data for serializers or extracting schema information from it.
maybe it is ok as a default...
$ python -m timeit 'isinstance("boo", str)'
10000000 loops, best of 3: 0.116 usec per loop

116 nanoseconds a check. Even if you checked 1000 objects with 10 attributes each, that only adds 1 millisecond per second of cost.

Performance is even better, here:
★ pypy3 -m timeit 'isinstance("boo", str)'
WARNING: timeit is a very unreliable tool. use perf or something else for real measurements
pypy3 -m pip install perf
pypy3 -m perf timeit 'isinstance("boo", str)'
------------------------------------------------------------
1000000000 loops, average of 7: 0.000761 +- 1.25e-05 usec per loop (using standard deviation)

(CPython says 10000000 loops, best of 3: 0.0734 usec per loop)

@glyph I thought the idea was that type= is superfluous:
x: int = attribute()   # Implies type=int

Sure; if you don't want it checked, don't pass the annotation (or say @attr.s(dont_run_validators=True)) or something.

Calling isinstance isn't the right validator implementation here, is it?  That doesn't work for many of typing module types.

I can't already use validator=instance_of.  Making that automatic is nice and all, but "first class type support" is more than that:
x: Dict[str, Tuple[Foo, Bar]] = attribute()  # Implies type=Dict[str, Tuple[Foo, Bar]]

Yeah, isinstance isn't 100% right, it's just the most common validator implementation.
I guess I can see why we might not want to do "deep" validation necessarily, especially of mutable types, given that they might be modified to not be type-compliant later.

GH
Yes, as it has been said a few times now: type checking is gonna be about more than just isinstance.  And as Wilfredo put it well: "first class support" is more than what we used to think about this kind of things.   For me it's infrastructure to enable cool things – things we haven't thought of before.   Type checking is just one of them and probably the most boring one.
It feels especially anachronistic to bake in runtime checks by default if you'd assume that static analysis/mypy become a generally usable thing.

In any case I think we have a general agreement about what to do.   What's missing is the decision what to do by default.  I suggest we discuss that once we have a type check implementation ready and can talk about performance implications more confidently.
But to me it still feel very antithetical to attrs' emphasis on performance and explicitness.

@glyph: I'd argue that interfaces are what matters, not the implementing class, so isinstance may be common, but it's certainly inferior.  ("type" seems a misnomer in Python.)
I think the mutable object argument is a bit of a red herring, FWIW.
@hynek:  I don't care what the default is; I think classes should be frozen by default, but I'm fine with adding frozen=True to all of my classes.  Meh.  I agree that not on by default seems safest, especially since I'm arguing for full typing support, which probably means a dependency on typeguard or similar.
Have we settled on the mechanics of specifying a type accepted by __init__ versus the ivar type?  Is it this:
@attrs(check_types=True)
class C:
    numbers: MutableSequence[int] = attribute(type=Sequence, convert=list)
    foo: Deferred[Foo] = attribute(type=Awaitable[Foo], convert=ensureDeferred)

No, current state of affairs is that foo = attr.ib(type=X) is legacy syntax for  foo: X = attr.ib()
Your examples should raise a conflict error I reckon.  I understand what you’re driving at (cf. convert) but I can’t think of a good way to implement it.  More likely maybe an additional attr.ib(init_type=Y).

Sorry, yes, right, type was the wrong name to suggest there; init_type is good.
Of course, more bad-ass would be looking at the type of the first arg to convert and using that.  Mwahahaha.  …must be bed time.

Just my 2 cents: Type checking of collections is quite brittle and potentially expensive, which is one reason why I recommend type checks to be disabled in production in typeguard's documentation. The abstract collection types in particular cannot be safely type checked. There are other subtle issues as well, like a misleading error message when you have an annotation like Union[List[int], str] and you pass it a list containing, say, a float.
Also, there is a new emerging type checker called pytypes. I've had a hand in that project as well and it has merged a few major features from typeguard already. I'm hoping that it will evolve eventually to the point where I can deprecate typeguard in its favor, but it's not there yet.

I think it would be great to get an immediate PR for annotating an attribute with a type, accessible from an instance via .type.  IMHO small, focused PRs are a great way to keep the ball rolling, and everyone seems to be in agreement on the design of this necessary first step.
Once that is complete, various parties can get to work on the static and runtime typing checking tasks, and rally around more focused issue discussions.  I'd be glad to help @Tinche with the mypy plugin (I've been messing around with some of my own).

That's certainly the plan.
Only open question to me is whether it makes any sense to artificially set __annotations__ if a user supplies .ib(type) in order to be backward compatible.   Opinions @ambv?

Only open question to me is whether it makes any sense to artificially set annotations if a user supplies .ib(type)

This is the first step, the second being copying from __annotations__ to Attribute.type? If so, I'd say no, if you want it in __annotations__, use a type annotation.

Please don't modify __annotations__. You will want to have real annotations present for static code analysis tools like mypy or PyCharm.

Please don't modify annotations. You will want to have real annotations present for static code analysis tools like mypy or PyCharm.

Modifying __annotations__ at runtime has no effect on static type analysis, which by definition never imports or runs your code.  That said, my initial reaction is that I think __annotations__  should be copied to Attribute.type and not the other way around.

Modifying annotations at runtime has no effect on static type analysis, which by definition never imports or runs your code. That said, my initial reaction is that I think annotations should be copied to Attribute.type and not the other way around.

The examples I've seen so far would forego the annotations and instead pass the type off to attr.ib() and have that used for run-time type checking. Therefore I agree with you.

I just added a PR for the parts we all seem to agree on.  Pop on by and let me know what you think.

Two more thoughts:

I like the suggestion from @Tinche for opt-in validation:
from attr.validators import validate_type

@attr.s
class C:
    x: int = attr.ib(validator=validate_type)

We can also automatically handle defaults to some degree. e.g.:

int -> int()
str -> str()
typing.List[str] -> Factory(list) (the real class can be retrieved from typing.List.__extra__)
typing.Dict[str, int] -> Factory(dict) (same as above)

A way of specifying this using something similar to 1 would be great:
@attr.s
class C:
    x: int = attr.ib(default=default_from_type)

Same goes for conversion.  It should also be opt-in.

For convenience, we could combine all 3 in one go by providing a dict with each of the type-aware keyword arguments:
import attr
from attr import use_type

@attr.s
class C:
    x: int = attr.ib(**use_type)

Sounds good to me.

FTR, the reason why I’m thinking about modifying __annotations__ is that IIUC, on Python 2, people are gonna have to write:
@attr.s
class C(object):
    x = attr.ib(type=int)  # type: int

Although I concur, that it should be probably solved in mypy.
The use_type magic goes  a bit too far for attrs proper but we can revisit that topic once the groundwork is done.

FTR, the reason why I’m thinking about modifying __annotations__ is that IIUC, on Python 2, people are gonna have to write:
@attr.s
class C(object):
    x = attr.ib(type=int)  # type: int

Static analysis and type annotations are pretty new, so before proceeding I should make a few non-obvious things clear so that we're all on the same page:

the __annotations__ attribute is provided for runtime access to annotations:

it is available on function objects to inspect argument types as of python 3.4 (PEP 3107)
it is available on any object with attributes to inspect attribute types as of python 3.6 (PEP 526)

type comments do not affect __annotations__ (the attribute is not present prior to python 3.4). __annotations__ are a direct corollary to (or bi-product of?) syntax support.
the __annotations__ attribute does not affect static type checking. thus modifying it at runtime would have no affect on mypy.

Getting back to the original point:  we can avoid the need for type comments in python 2.7 by providing pyi stubs with an overload specific to signatures that include the type argument.  Here's a sketch:
from typing import Any, Mapping, Type, TypeVar, overload
T = TypeVar('T')
@overload
def attr(default: Any = ..., metadata: Mapping = ...) -> Any: ...
@overload
def attr(default: Any = ..., metadata: Mapping = ..., type: Type[T] = ...) -> T: ...

This says that if attr receives a type argument the function will return an instance of type.  Otherwise, it returns Any (i.e. unknown).
That makes clear to static type-checkers that in your example x is an int without the need for type comments.  So this is fine again:
@attr.s
class C(object):
     x = attr.ib(type=int)

Hm, that actually looks quite clever!

I'll throw my 2c in here -- I've written a little PoC library a while ago that codegens runtime type checkers in an efficient fashion given the type annotations: http://github.com/aldanor/typo. It can handle most basic type classes, but also things like Tuple[T, Dict[U, T]] with type vars and bounds.
Compared to other similar libraries, specifying x: int literally results in if isinstance(x, int) at runtime and doesn't involve a gazillion closures and lookups and decorators around it, which for simple type checks like the latter is an important thing to have.
It gets pretty complicated with generic type vars though (specifically, with union-type ones) since you have to generate some pretty complicated code to deal with generics inside sum-types (not going into further details but it's fairly hairy). If you ban generics inside sum-types then it becomes very simple and straightforward -- e.g. constraints like Tuple[T, Dict[U, T]] are handled quite easily.
Maybe some pieces could be reused or partially reused in here, saving everyone a bit of time :)

We have recently merged generic type support, maybe you'd like to play with it a bit and give feedback?
I'm don't think we'll rush adding the actual checking anytime soon.   Maybe we'll even point at external solution, so feel free to experiment.

First class support is in thanks to #239, we can open new issues on what to do with those type now.

I was trying to find https://github.com/aldanor/typo today but instead I ran across https://github.com/RussBaz/enforce which looks like it may be a fairly full-featured version of the same thing.

There is also https://github.com/Stewori/pytypes
May the best project win.
On Tue, Nov 14, 2017 at 4:37 PM Glyph<EMAIL_ADDRESS>wrote:

I was trying to find https://github.com/aldanor/typo today but instead I
ran across https://github.com/RussBaz/enforce which looks like it may be
a fairly full-featured version of the same thing.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/python-attrs/attrs/issues/215#issuecomment-344447705,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAD3ExNEMEFKt-RbcCG4I_VwqdxFp-oEks5s2jI6gaJpZM4OFBOJ
.

First class support is in thanks to #239, we can open new issues on what to do with those type now.

Where is the discussion about runtime automatic type checking happening?

There is none so far.  I believe a good first step would be to add generic class-wide validators (@attr.s(validator=whatever)) and then make type checking a special case of it, possibly with some syntactic sugar.

Thanks. Shall we open a separate issue or re-open this one?

I think a new one would be best.


Refactor multiselect

Description of the Change
Refactor multiselect with callbacks
Benefits
Multiselect is done
Possible Drawbacks
selectOneOfLazy is not implemented
Usage Examples or Tests
See multiselect test

Codecov Report

Merging #159 into master will increase coverage by 0.15%.
The diff coverage is 76.53%.

@@            Coverage Diff             @@
##           master     #159      +/-   ##
==========================================
+ Coverage   74.27%   74.42%   +0.15%
==========================================
  Files         310      320      +10
  Lines        8209     8688     +479
  Branches     4248     4492     +244
==========================================
+ Hits         6097     6466     +369
- Misses       1116     1181      +65
- Partials      996     1041      +45

Impacted Files
Coverage Δ

...re/transaction_pool/impl/transaction_pool_impl.cpp
80.19% <ø> (ø)
:arrow_up:

test/core/libp2p/transport/upgrader_test.cpp
100% <ø> (ø)
:arrow_up:

core/libp2p/protocol_muxer/protocol_muxer.hpp
100% <ø> (ø)
:arrow_up:

.../libp2p/protocol_muxer/multiselect/multiselect.hpp
100% <ø> (ø)

...re/transaction_pool/impl/transaction_pool_impl.hpp
100% <ø> (ø)
:arrow_up:

...ore/libp2p/protocol_muxer/message_manager_test.cpp
57.44% <0%> (ø)

...bp2p/protocol_muxer/multiselect/message_writer.cpp
100% <100%> (ø)

...p2p/protocol_muxer/multiselect/message_manager.cpp
80.21% <100%> (ø)

...mock/libp2p/protocol_muxer/protocol_muxer_mock.hpp
100% <100%> (ø)
:arrow_up:

...p/protocol_muxer/multiselect/multiselect_error.cpp
11.11% <11.11%> (ø)

... and 15 more

Continue to review full report at Codecov.

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


Fix regression when using custom transport_socket envoyfilter

Fixes https://github.com/istio/istio/issues/33385

@howardjohn: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

lint_istio
60d95bfe85051dabd1b5ca8c538212da555a97b3
link
/test lint_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@howardjohn: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

lint_istio
60d95bfe85051dabd1b5ca8c538212da555a97b3
link
/test lint_istio

unit-tests_istio
60d95bfe85051dabd1b5ca8c538212da555a97b3
link
/test unit-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

Looks good. Apart from that comment.

@howardjohn: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

lint_istio
60d95bfe85051dabd1b5ca8c538212da555a97b3
link
/test lint_istio

unit-tests_istio
60d95bfe85051dabd1b5ca8c538212da555a97b3
link
/test unit-tests_istio

integ-telemetry-mc-k8s-tests_istio
08de4e1d8e75ce2a5cd4bdf3cd70d2f121682eae
link
/test integ-telemetry-mc-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@howardjohn: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

unit-tests_istio
60d95bfe85051dabd1b5ca8c538212da555a97b3
link
/test unit-tests_istio

integ-telemetry-mc-k8s-tests_istio
08de4e1d8e75ce2a5cd4bdf3cd70d2f121682eae
link
/test integ-telemetry-mc-k8s-tests_istio

lint_istio
08de4e1d8e75ce2a5cd4bdf3cd70d2f121682eae
link
/test lint_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@howardjohn: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-telemetry-mc-k8s-tests_istio
08de4e1d8e75ce2a5cd4bdf3cd70d2f121682eae
link
/test integ-telemetry-mc-k8s-tests_istio

lint_istio
08de4e1d8e75ce2a5cd4bdf3cd70d2f121682eae
link
/test lint_istio

unit-tests_istio
08de4e1d8e75ce2a5cd4bdf3cd70d2f121682eae
link
/test unit-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@howardjohn: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-telemetry-mc-k8s-tests_istio
08de4e1d8e75ce2a5cd4bdf3cd70d2f121682eae
link
/test integ-telemetry-mc-k8s-tests_istio

unit-tests_istio
08de4e1d8e75ce2a5cd4bdf3cd70d2f121682eae
link
/test unit-tests_istio

lint_istio
28fe3df35f6eb3989cd57157f5e79d381ce6e125
link
/test lint_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@howardjohn: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-telemetry-k8s-tests_istio
7b29307c34d932aa9aeb6403d58a8c53b5254f02
link
/test integ-telemetry-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

In response to a cherrypick label: #33386 failed to apply on top of branch "release-1.10":
Applying: Fix regression when using custom transport_socket envoyfilter
Using index info to reconstruct a base tree...
M	pilot/pkg/networking/core/v1alpha3/envoyfilter/cluster_patch.go
M	pilot/pkg/networking/core/v1alpha3/envoyfilter/cluster_patch_test.go
M	pilot/pkg/networking/core/v1alpha3/envoyfilter/listener_patch.go
M	pilot/pkg/networking/core/v1alpha3/envoyfilter/listener_patch_test.go
M	pkg/config/validation/validation.go
Falling back to patching base and 3-way merge...
Auto-merging pkg/config/validation/validation.go
Auto-merging pilot/pkg/networking/core/v1alpha3/envoyfilter/listener_patch_test.go
Auto-merging pilot/pkg/networking/core/v1alpha3/envoyfilter/listener_patch.go
CONFLICT (content): Merge conflict in pilot/pkg/networking/core/v1alpha3/envoyfilter/listener_patch.go
Auto-merging pilot/pkg/networking/core/v1alpha3/envoyfilter/cluster_patch_test.go
Auto-merging pilot/pkg/networking/core/v1alpha3/envoyfilter/cluster_patch.go
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 Fix regression when using custom transport_socket envoyfilter
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

In response to a cherrypick label: new issue created for failed cherrypick: #33409

In response to a cherrypick label: #33386 failed to apply on top of branch "release-1.9":
Applying: Fix regression when using custom transport_socket envoyfilter
Using index info to reconstruct a base tree...
M	pilot/pkg/networking/core/v1alpha3/envoyfilter/cluster_patch.go
M	pilot/pkg/networking/core/v1alpha3/envoyfilter/cluster_patch_test.go
M	pilot/pkg/networking/core/v1alpha3/envoyfilter/listener_patch.go
M	pilot/pkg/networking/core/v1alpha3/envoyfilter/listener_patch_test.go
M	pkg/config/validation/validation.go
Falling back to patching base and 3-way merge...
Auto-merging pkg/config/validation/validation.go
Auto-merging pilot/pkg/networking/core/v1alpha3/envoyfilter/listener_patch_test.go
CONFLICT (content): Merge conflict in pilot/pkg/networking/core/v1alpha3/envoyfilter/listener_patch_test.go
Auto-merging pilot/pkg/networking/core/v1alpha3/envoyfilter/listener_patch.go
CONFLICT (content): Merge conflict in pilot/pkg/networking/core/v1alpha3/envoyfilter/listener_patch.go
Auto-merging pilot/pkg/networking/core/v1alpha3/envoyfilter/cluster_patch_test.go
CONFLICT (content): Merge conflict in pilot/pkg/networking/core/v1alpha3/envoyfilter/cluster_patch_test.go
Auto-merging pilot/pkg/networking/core/v1alpha3/envoyfilter/cluster_patch.go
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 Fix regression when using custom transport_socket envoyfilter
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

In response to a cherrypick label: new issue created for failed cherrypick: #33410


Create .gitpod.yml

Summary
This PR makes it so when this repository is used to create a Gitpod workspace, the configuration used will be delegated to the mattermost-gitpod-config repo through its .gitpod.yml file.
This allows multiple repos to share the same Gitpod config, as well as keeping the commit history minimal in regards to the individual repos.
https://www.gitpod.io/docs/references/gitpod-yml
https://www.gitpod.io/docs/multi-repo-workspaces
Ticket Link
Fixes https://mattermost.atlassian.net/browse/MM-43928

/update-branch


Revert Click Feedback.

Connects to #1795.

@christopheschwyzer please review.

lgtm

Can you open another PR to re-add this ;)

ok


Support Laravel 5.4 webpack mix()

Added mix() facade function
Added example on readme file

Is there any reason this has not yet been merged in? It would be very helpful

June 29th and nothing on this? Has this package lost support?

I didn't want to use a fork anymore, especially after the latest symfony update so I've created a (fresh) new package that supports mix(). You can find it here: https://github.com/arubacao/asset-cdn


fix: helm lint should be called after dependency build

lint fails if a dependency is missing so...
Funny thing, this can't be circumvented by changing the pipeline to call helm dependency build before of jx gitops helm release because of https://github.com/helm/helm/issues/9164

Hi @yelhouti. Thanks for your PR.
I'm waiting for a jenkins-x or todo member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test label.
I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign rajdavies
You can assign the PR to them by writing /assign @rajdavies in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/assign @rajdavies

/ok-to-test
/lgtm

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: jstrachan
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [jstrachan]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


add workflow to rebuild linux docker image

close #148
add workflow to rebuild linux docker image on Dockerfile change
please add secrets.DOCKER_USERNAME and secrets.DOCKER_PASSWORD for workflow to run.

It works! Thank you! https://github.com/HumbleUI/JWM/runs/3692447045?check_suite_focus=true


Does this still require a nvidia license server?

I'm looking to set this up on my proxmox server but have a couple of questions...
Does this still require a license server?
Will this work on Proxmox 6.3-6?
I've got two cards in my test server, a quandro p2000, and a GTX 1660 super..  is there some way to use only one for this project, or will both be affected should I build this solution?
And I did sign up at nvidia for a trial license for 90 days, but there are a lot of different drivers, which one should I use for my hardware?
Thanks for this work, this is very exciting stuff!!

Yes, a license server and the appropriate licenses can be downloaded from the Nvidia licensing portal and installed on Linux or Windows.
We do have a public license server handing out licenses in our Discord server if you want to use that.

That would be awesome. I tried the discord link posted in another thread, but it says it expired. Can you shoot me one? Please and thank you.

https://discord.gg/qh6dvPtxvb

I'm looking to set this up on my proxmox server but have a couple of questions...
Does this still require a license server?

Yes.

Will this work on Proxmox 6.3-6

Yes

I've got two cards in my test server, a quandro p2000, and a GTX 1660 super.. is there some way to use only one for this project, or will both be affected should I build this solution?

One, and only one of the cards will be affected by vgpu_unlock, unfortunately the current version of vgpu_unlock does not have a way to select or report which one. Also simply installing the vGPU drivers will likely affect all cards.

And I did sign up at nvidia for a trial license for 90 days, but there are a lot of different drivers, which one should I use for my hardware?

You would probably want the "Linux with KVM" variant, version 12.1 (460.32.04).

This issue can now be closed safely.


what's the problem when i test on MOT16 dataset?

2020-04-26 10:19:16 [INFO]: Evaluate seq: MOT16-05
IDF1  IDP  IDR Rcll Prcn GT MT PT ML   FP FN IDs  FM  MOTA MOTP IDt IDa IDm
MOT16-05 0.0% 0.0% nan% nan% 0.0%  0  0  0  0 1747  0   0   0 -inf%  nan   0   0   0
OVERALL  0.0% 0.0% nan% nan% 0.0%  0  0  0  0 1747  0   0   0 -inf%  nan   0   0   0

2020-04-26 10:19:16 [INFO]: Evaluate seq: MOT16-05
IDF1 IDP IDR Rcll Prcn GT MT PT ML FP FN IDs FM MOTA MOTP IDt IDa IDm
MOT16-05 0.0% 0.0% nan% nan% 0.0% 0 0 0 0 1747 0 0 0 -inf% nan 0 0 0
OVERALL 0.0% 0.0% nan% nan% 0.0% 0 0 0 0 1747 0 0 0 -inf% nan 0 0 0

Check if the data being read from the results files is actually read. In my case, I had to modify the eval script a little to work.

@Nishzzz can you clarify the code that you modified? thanks

2020-04-26 10:19:16 [INFO]: Evaluate seq: MOT16-05
IDF1 IDP IDR Rcll Prcn GT MT PT ML FP FN IDs FM MOTA MOTP IDt IDa IDm
MOT16-05 0.0% 0.0% nan% nan% 0.0% 0 0 0 0 1747 0 0 0 -inf% nan 0 0 0
OVERALL 0.0% 0.0% nan% nan% 0.0% 0 0 0 0 1747 0 0 0 -inf% nan 0 0 0

Check if the data being read from the results files is actually read. In my case, I had to modify the eval script a little to work.

请问你怎么改的eval script？

Hi everyone, I managed to figure out how to change the code in yolov3_deepsort_eval.py such that it will run correctly. I realized that the documentation on how to do this is a bit lacking, so I'll chip in on how this can be done.
nowadays when you download the MOT16 data file from here, the "video" actually comes as a sequence of frames stored in MOT16/train/MOT16-XX/img1. You need to convert this into a video file for the tracker to track items in it. The resulting video (converted from frames in MOT16/train/MOT16-XX/img1) is the video that is being referred to on line 34 in yolov3_deepsort_eval.py (video_path = data_root+"/"+seq+"/video/video.mp4"). Change video_path to the path where your video is stored.
This is probably obvious, but on line 81 (data_root = 'data/dataset/MOT16/train/') data_root needs to refer to the root directory of the folder that you download from here.
This is probably obvious too, but for some reason, on line 36 (with VideoTracker(cfg, args, video_path, result_filename) as vdo_trk:) for some reason there are 4 arguments. This is incorrect, since the VideoTracker class in yolov3_deepsort.py only takes 3 arguments. The extra (incorrect) argument in this case is the last one, result_filename.  Two files are generated as a result of running the VideoTracker (from yolov3_deepsort.py) for an input video. These two files (results.avi and results.txt) are stored in the path that is provided in the argument "--save_path" (line 65). On line 65 (parser.add_argument("--save_path", type=str, default="./demo/demo.avi")) change default="./demo/demo.avi" to whichever path you want results.avi and result.txt to be stored. Note that if this is not changed, by default only demo.avi (which is results.avi in yolov3_deepsort.py) will be generated. If a path (as opposed to path to a specific file) is specified, then VideoTracker will generate and store the results of tracking as results.avi and results.txt, by default, as specified in line 59, 60 in yolov3_deepsort.py
(59: self.save_video_path = os.path.join(self.args.save_path, "results.avi")
60: self.save_results_path = os.path.join(self.args.save_path, "results.txt")).
Another work-around, of course, would be to specify a path as a flag when calling the function from the command line (i.e., python yolov3_deepsort_eval.py --save_path path/you/want/to/store/results/in).
Lastly, looking into line 33 (result_filename = os.path.join(result_root, '{}.txt'.format(seq))) one will notice that result_filename is actually meant to refer to the results.txt file that I mentioned above in (4). i.e., the results.txt file that is generated as a result of running the VideoTracker. You have to modify result_filename such that it refers to the path at which results.txt is stored for a given video. For instance, if --save_path is "./output/", then result_filename="./output/results.txt"
One major issue I noticed is that, even if the user passes in a path that does not lead to any legitimate results.txt file, the program does not give any indication (error/warning), that the user is running the program incorrectly. Instead, the mistake is reflected as a bunch of 0%s and nan's in the summary printed at the end of the program.
I hope this helps! If I'm missing anything, do leave a comment below!

Hi everyone, I managed to figure out how to change the code in yolov3_deepsort_eval.py such that it will run correctly. I realized that the documentation on how to do this is a bit lacking, so I'll chip in on how this can be done.
nowadays when you download the MOT16 data file from here, the "video" actually comes as a sequence of frames stored in MOT16/train/MOT16-XX/img1. You need to convert this into a video file for the tracker to track items in it. The resulting video (converted from frames in MOT16/train/MOT16-XX/img1) is the video that is being referred to on line 34 in yolov3_deepsort_eval.py (video_path = data_root+"/"+seq+"/video/video.mp4"). Change video_path to the path where your video is stored.
This is probably obvious, but on line 81 (data_root = 'data/dataset/MOT16/train/') data_root needs to refer to the root directory of the folder that you download from here.
This is probably obvious too, but for some reason, on line 36 (with VideoTracker(cfg, args, video_path, result_filename) as vdo_trk:) for some reason there are 4 arguments. This is incorrect, since the VideoTracker class in yolov3_deepsort.py only takes 3 arguments. The extra (incorrect) argument in this case is the last one, result_filename.  Two files are generated as a result of running the VideoTracker (from yolov3_deepsort.py) for an input video. These two files (results.avi and results.txt) are stored in the path that is provided in the argument "--save_path" (line 65). On line 65 (parser.add_argument("--save_path", type=str, default="./demo/demo.avi")) change default="./demo/demo.avi" to whichever path you want results.avi and result.txt to be stored. Note that if this is not changed, by default only demo.avi (which is results.avi in yolov3_deepsort.py) will be generated. If a path (as opposed to path to a specific file) is specified, then VideoTracker will generate and store the results of tracking as results.avi and results.txt, by default, as specified in line 59, 60 in yolov3_deepsort.py
(59: self.save_video_path = os.path.join(self.args.save_path, "results.avi")
60: self.save_results_path = os.path.join(self.args.save_path, "results.txt")).
Another work-around, of course, would be to specify a path as a flag when calling the function from the command line (i.e., python yolov3_deepsort_eval.py --save_path path/you/want/to/store/results/in).
Lastly, looking into line 33 (result_filename = os.path.join(result_root, '{}.txt'.format(seq))) one will notice that result_filename is actually meant to refer to the results.txt file that I mentioned above in (4). i.e., the results.txt file that is generated as a result of running the VideoTracker. You have to modify result_filename such that it refers to the path at which results.txt is stored for a given video. For instance, if --save_path is "./output/", then result_filename="./output/results.txt"
One major issue I noticed is that, even if the user passes in a path that does not lead to any legitimate results.txt file, the program does not give any indication (error/warning), that the user is running the program incorrectly. Instead, the mistake is reflected as a bunch of 0%s and nan's in the summary printed at the end of the program.
I hope this helps! If I'm missing anything, do leave a comment below!

would you please share the modified code to conduct evaluation on multiple sequences.
it will be a great help


Clarify request draining comments

@aL3891 @guardrex After reading the final version of https://github.com/dotnet/AspNetCore.Docs/pull/18075 I wanted to clarify a few more things.
Preview: https://review.docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-2.1&branch=tratcher%2Frequest-draining

@Tratcher Did you have more updates? It looks great here. :eyes:

:shipit:


USER STORY: Delete Product Functionality

As an admin, I will want a way to delete a product from the product page so that I can correct a mistake if the whole product I added is wrong or uneeded.
Delete product - (soft) delete a product from local DB:

Delete product button should (soft) delete product JSON data from your mongoDB using nestJS.
This is more of an update where a flag isHidden is set to true to hide the product.
Implemented on products page and product details page.
See nsc-events-android user story #54 https://github.com/SeattleColleges/nsc-events-android/issues/54.

Tasks:

[x]  Add boolean property to Product to track if an item is hidden. Use variable name isHidden.
If a creator clicks the delete button there will be an update to the database that sets the isHidden property to true
#https://github.com/SeattleColleges/belindas-closet-nestjs/issues/55
[ ]  Route needs setup on the backend to handle soft deletion.
[ ]  Frontend needs to make the call to backend to fulfill the request.

There should be a way to delete products (one at a time) from the update product page:

There should be a way to delete a product from the update individual product page:

Hi @intisarosman1, I was looking at the current state of the app for the product page and product update page. I just wanted to point a couple things out about how this should be changed:
Product page is fine:

When edit button is clicked, product update page should be displayed but NOT as it is now:

It should look more like the individual product update page minus the edit feature:

and you should be able to scroll down and delete other products from the product update page:


Mod list offline, autoupdate isn't functioning

Describe what you were trying to do and why
I'm simply trying to view the mod list. Also, autoupdate seems to be failing.
(For example, "Many More Fixes" is still 1.0.0 even though it's 1.0.1, mentioned here in the RW discord: https://discord.com/channels/291184728944410624/804088181904375819/807564814586216449)
To Reproduce
Unfortunately I'm not sure what's causing this or if it's just a local problem. Here are some logs.

No mods enabled. Opened game, viewed mod list, and exited: LogOutput.log

No mods enabled. Opened game, enabled "Many More Fixes" and ConfigMachine, viewed mod list, and exited: LogOutput.log

Expected behavior
Autoupdate works, the mod list is viewable.
Actual behavior
Autoupdate doesn't work, the mod list is always offline.
Screenshots

Additional context
My system is configured to use Cloudflare DNS, and I've heard some websites and APIs will reject that.

Oh woops, apologies for reporting a local problem then.
It actually stopped occurring after connecting an ethernet cable to my PC. I would've tried that before making the report, but I was living in a different room without one at the time.

Hi, I also seemingly have this issue. The mod browser refuses to load, and i've dug into the log to see the same error.
[Error  :     Realm] Error while adding mods: error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version
I don't use Cloudflare DNS, instead I use google's DNS if that matters at all. I've tried changing DNS, disabling firewall, checking certificates, using a VPN, restarting my PC, and reinstalling Rain World (several times), etc. etc.
Bepinex Output log: LogOutput.log
Is it perhaps an issue with the mod, or something else on my end?

Hello, I am also having the same issue, with the mod browser always offline, and the same error message in the log.
LogOutput.log
I tried reinstalling realm, reinstalling the game, changing my DNS, VPN, firewall settings, and the windows setting to activate the various tls versions but have been the getting the exact same result every single time.
I found with a bit a digging that people have had a similar error when using git. It didn't help me much but it might help you identify the source of the error.
https://github.com/glennhickey/progressiveCactus/issues/93
https://www.ibm.com/mysupport/s/question/0D50z00005q4Ff6CAE/error1407742essl-routinesssl23getserverhellotlsv1-alert-protocol-version?language=fr


Alignment refactor

[ENH]: removed bi-directional relationship between Alignment and AlignedSeqsData where .make_aligned in the ASD pointed to the Alignment

closing due to conflicts


Feature - user defined rooms to include

User setting to in/exclude rooms to show in the app

Great idea! This will be implemented next, together with setting a favourite room and a custom email signature.


Chunker error with Box remote

What is the problem you are having with rclone?
Very cool new feature! Thanks for your help with getting it working.
I get the following error when transferring a large file using the default settings with the chunker backend, with a Box remote repository:
DEBUG : projects/archive/INDIVGraphTheory.tar.gz__tmp.1564856403.001: Cancelling multipart upload: multipart upload failed to read source: EOF
What is your rclone version (output from rclone version)
rclone v1.48.mr02

os/arch: linux/amd64
go version: go1.12.6

Which OS you are using and how many bits (eg Windows 7, 64 bit)
Linux CentOS 7, 64 bit
Which cloud storage system are you using? (eg Google Drive)
Box
The command you were trying to run (eg rclone copy /tmp remote:tmp)
rclone sync / Chunker_Box_ProjectBackups_RawDataAndDocsDirs: -vv --log-file=logs/chunker_box_projectsrawdataanddocsdirs.log --filter-from FILTERFROM_projectsrawdataanddocsdirs_archiveonly.txt --copy-links --retries 1 --progress
A log from the command with the -vv flag (eg output from rclone -vv copy /tmp remote:tmp)
Attached. Note that I cancelled the process for this log since it would keep retrying but fail after the last attempt.
chunker_box_projectsrawdataanddocsdirs_2019-08-04T07:48_mod.log

I will not have access to desktop in 10+ days. Sorry for long radio silence.

Hi Michael
Chunker backend internally streams a file being split and consequently fails if an
underlying remote switches to multipart mode, (aka "parallel upload" mode, which is
confusingly called "chunking mode" somewhere in the rclone documentation).
To work around problems with multipart upload and chunker, you should
make multipart upload cutoff at least as large as the chunker chunk size, eg:
./rclone copy big.dat BoxChunkerRemote: --box-upload-cutoff=100M --chunker-chunk-size=100M
In future Chunker may implement some kind of on-disk caching to overcome this issue.

I tested your suggested solution and it worked. Thanks!


I want to translate the lang file to Chinese

I want to translate the lang file to Chinese

@FZDNSZYT There are two language files for Chinese; zh-cn and zh-tw, found in src/main/resources/languages. Feel free to update them and submit a PR


Implement simulator block to handle closed loop dynamics

@VenusPasandi is working on an improvement for the simulation of mechanical systems with closed loop dynamics.

yes, I am working on this in the branch feature/constrainedDynamics. I will be happy to hear suggestions for improving it.
@nunoguedelha @Giulero

I implemented the simulator block for the constrained dynamics which has two closed chain kinematics in d27c4a077706011f7b4523581b76a70bfbf62630. I need still to do some modifications:

[ ] Provide the possibility of the having any number of the closed chains.
[ ] Properly resolve the issue of dependent constraints for the closed chain kinematic,
[ ] Properly resolve the issue of the inversion of the rank-deficient matrices,
[ ] Clean the code

Hi @VenusPasandi , I haven't take a look a this yet, I'll try to do it ASAP.

I opened #64 to merge the simulator block for the closed-chain robots in to the master though we haven't addressed all the checkpoints in https://github.com/ami-iit/matlab-whole-body-simulator/issues/54#issuecomment-967248927. I think the remaining checkpoints are minor fixes that we can resolve them later.

Ciao @VenusPasandi , I saw you already opened one or a few issues tracking all the remaining points listed in https://github.com/ami-iit/matlab-whole-body-simulator/issues/54#issuecomment-967248927. I suggest you open an Epic to group those points, since the issue here is now closed.

Ciao @VenusPasandi , I saw you already opened one or a few issues tracking all the remaining points listed in #54 (comment). I suggest you open an Epic to group those points, since the issue here is now closed.

Ciao @nunoguedelha. Actually, the remaining points are not related to the closed chain dynamics but are general points. because of that I didn't group them. I am not sure if creating an Epic for all the improvements of the dynamics blocks is really usefull.

I see, indeed there are only two remaining and directly related to the closed loop. Never mind.


Add covid only flag for resend mutation

BACKEND PULL REQUEST
Related Issue

Used for #7766

Changes Proposed

Adds boolean flag to resentToReportStream mutation for only resending results to the covid pipeline

Testing

Added unit test for this case and will confirm with ReportStream once resending is complete

Spent some time trying to figure out why this sonarqube build is failing, but still not sure. It's complaining about the project containing .java files and asking to provide compiled classes with sonar.java.binaries or exclude them with sonar.exclusions, but it doesn't seem like anything in the PR should require modifying sonar config. If folks would like I can continue looking into this though!

Spent some time trying to figure out why this sonarqube build is failing, but still not sure. It's complaining about the project containing .java files and asking to provide compiled classes with sonar.java.binaries or exclude them with sonar.exclusions, but it doesn't seem like anything in the PR should require modifying sonar config. If folks would like I can continue looking into this though!

What ended up being the fix to this? Or did it just work itself out on its own?

Spent some time trying to figure out why this sonarqube build is failing, but still not sure. It's complaining about the project containing .java files and asking to provide compiled classes with sonar.java.binaries or exclude them with sonar.exclusions, but it doesn't seem like anything in the PR should require modifying sonar config. If folks would like I can continue looking into this though!

What ended up being the fix to this? Or did it just work itself out on its own?

I ran the testing workflow manually against this branch and everything passed so it seems like it is just a sonar hiccup for the PR

I'll merge this for now so I can resend those test events to reportstream but I can create a follow up ticket if we want to improve the ergonomics of this mutation


Replace simple_list/list with one list

Introduce an new Choice trait that is implemented for &str and
(T, V) where T: Display to abstract over lists where output = value
and lists where each item also carries an internal value
Add quick-error and a bunch of error cases.
Sadly, this means option in to the unstable "io" feature as termion
(which already depends on nightly) gives us an std::io::CharsError
(which is an unstable type).

Also:

Add some documentation
Split code into smaller modules
Add EditorConfig, Travis CI

You might want to add a license, by the way (Rust-default is MIT/Apache2, which I'm totally fine with).
Do you plan on upstreaming your termion changes?

You might want to add a license, by the way (Rust-default is MIT/Apache2, which I'm totally fine with).

Good point, I'll add an MIT license later.

Do you plan on upstreaming your termion changes?

Yeah, I should probably at least submit a pull request and hear what they have to say.

Apart from my comments, I think this looks really good :+1:

Added Typo, removed trailing newline – or was it the other way around?
Re https://github.com/Munksgaard/inquirer-rs/pull/1#discussion_r70884285: Whether or not to return indices for the "1-tuple" &str case is an interesting question. I'm not sure what use cases exist for that.
But–I think it might be better to not have &str as a special case anyway: Why not just define the trait for T: Display? I think we might need to tap into specialisation for that, but it should work (since or tuple impl might also be covered by T: Display iff tuples (T, V) where T: Display, V: Display impl Display themselves).

Do you want me to introduce the T: Display thing here on in another PR?

Do you want me to introduce the T: Display thing here on in another PR?

I think here is fine.

The current specialization implementation doesn't work here, as it doesn't allow impl<T: Display> Foo for T and impl<T: Display, V> Foo for (T, V) – (T, V) may impl Display, so it can be a T: Display and the tuple structure doesn't make it more specific (i.e., important) for some reason.

Sadly, not so simple anymore :/

Ha ha, good point. Perhaps it should be called enumerated-list now. :smile:


🚀 Feature: new frontend system legacy plugin converter

🔖 Feature description
The @backstage/core-compat-api package seems to exist to provide compatibility for the new frontend system. It seems like the bridge for existing plugins is missing. This may have been intentional but it seems possible?
🎤 Context
This would allow existing plugins to be used with the new frontend system.
✌ Possible Implementation
function convertLegacyPlugin(plugin: BackstagePlugin) {
  return createPlugin({
    id: plugin.getId(),
    extensions: Array.from(plugin.getApis()).map(factory =>
      createApiExtension({
        factory,
      }),
    ),
    routes: convertLegacyRouteRefs(plugin.routes),
    externalRoutes: convertLegacyRouteRefs(plugin.externalRoutes),
    featureFlags: Array.from(plugin.getFeatureFlags()),
  });
}

const app = createApp({
  features: [
    ...legacyFeatures,
    convertLegacyPlugin(catalogUnprocessedEntitiesPlugin)
  ],
});

👀 Have you spent some time to check if this feature request has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Are you willing to submit PR?
Yes I am willing to submit a PR!

Yep we'll likely look at adding this! 👍
The tricky bit are the extensions being provided through plugin.provide(...) in the old system, and how to handle those.

Initial implementation of this in #26057, appreciate feedback on that approach

Closing this for now as we don't have any planned work in this area at the moment, but still open to feedback.


How is it possible to charge transaction fees with multiple currencies?

There seems to be no example or solution for handling transaction costs for different currencies.
Take the example that you want to offer different extrinisics with different asset requirements. Say, you have extrinsic A, in which there happens to be a transfer of ACA token. Then you have another extrinsic B which utilizes a transfer with AUSD token. Your native currency on-chain is token ABC.
Now you want to avoid the situation that the users need to buy or have the ABC token for the transaction fee. So you would like to charge the currency ACA for extrinsic A and AUSD for extrinsic B. Sure, the hard part of this is that the prices between the tokens always change and we would like to have a security approach for charging transaction fees based on weights. But nevertheless do you have an approach in mind, how to quickly achieve that users don't need to have the native currency on a chain, when fees can be charged with other tokens?
I know that there is the possibility to just swap the non-native token on a pool for the native one and then use that. But this implies to use some sort of exchange mechanism which would lead to more time and cost requirements.
Do you already have a running solution for that?

Oh, I already see this. Thanks a lot for reading my message. But I try to find an easier way to avoid swapping and querying the spot prices. Even though yours is the cleaner approach, one can just use a parameter and change the WeightToFee for each currency over time.


Support skip attribute for enum

Motivation
Convert Rust enum to javascript completly.
Proposed Solution
Check skip attribute while macro paring enum
#[wasm_bindgen]
pub enum Colors {
    #[wasm_bindgen(skip)]
    Rgba(i16, i16, i16, f64),
    Red
}

#[wasm_bindgen]
impl Colors {
    #[wasm_bindgen(js_name = "Rgba")]
    pub fn rgba(r: i16, g: i16, b: i16, a: f64) -> Colors {
        Colors::Rgba(r, g, b, a)
    }
}

Thanks for the report! I'm not sure I completely understand, though. How would we represent the Rgba variant in JS?

oops,  completely in my words actually focus on the usage of the exported pkg, for example, the ideal way to use enums with inner value is like this:
import { Colors } from "../pkg";

//  a red color
const red: Colors = Colors.Red;

// a RGBA color
const rgba: Colors = Colors.Rgba(255, 255, 255, 255);

It seems like we exported the whole enum without skip, this is what my completely means...

Hm ok, it seems perhaps plausible but I'm still not sure how the values would be read in JS. In general I think this proposal would need to be fleshed out more before it gets a PR, perhaps even trying to write up some documentation for the feature beforehand?

Close this issue now, I'll reopen this when I fix my other two issues / pr or figure out some really reasonable explanation.


"Read only" mode

Hi!
For anonymous users, It would be nice to be able to use the plugin to display in "Read-Only" mode, having all the features (comment, reply, delete) disabled.
Have a good day,
Samuel

Thanks for participating this project! "Read-Only" mode is something that we have considered doing but is not the highest priority at the moment. Based on your pull-request, you seem to know what you are doing so feel free to create another pull-request out of "Read-Only" mode.

Hi Joona,
Thanks ! I also have quite higher priorities, but it's on my infinitly growing todo-list! It probably will have to wait since i'll be away for the next 5 weeks.
There is 3 ways i see to implement this:

Hide all mutable controls
Can be done by adding a css class to controls: ex:   .jquery-comments-mutable
When read-only mode activated,   $('.jquery-comments-mutable').hide();`

Disable all mutable controls, but let them be visible.
Can be done by adding a css class to controls: ex:   .jquery-comments-mutable
When read-only mode activated,   $('.jquery-comments-mutable').disable();`

Leave mutable controls activated, but ask for credentials/login
TBD using callbacks, ensuring the current state is preserved during the authentification process.

What do you think?
Samuel

I would just hide all the mutable controls: disabling them might confuse users as they don't necessarily know why the buttons are disabled and prompting for credentials can already be done with callbacks (check https://app.viima.com/viima/).

I'm happy to let you know that this feature has been implemented to version 1.1.0. The functionality can be enabled by setting the new variable "readOnly" to true


#99 Added Google for Work compatibility

added Google for Work compatibility with client and client_secret args that are used to sign the url
removed sensor parameter, not needed anymore (see https://developers.google.com/maps/articles/geolocation)
added language parameter
The rate limits are different for Google for Work (100K/day, 10/sec). Not sure how to implement this with ratelim decorators

Awesome stuff Palo!
Thanks for adding that Google for Work API, it was a bit hard for me to implement since I don't have an account.
Have you tested it to see if it works properly?


Changed ReadMe usage

I changed ResponsiveSizer to Sizer because ResponsiveSizer doesn't work.

duplicate of #20


Servicebus - Track2 - max_wait_time on receive sometimes seems to terminate slightly early on linux systems.

This is likely some sort of clock-skew bug, although it's manifesting in an interesting way.
On linux (windows may not have this problem, we were certainly not able to repro it locally outside of on linux VMs) test_queue_receiver_respects_max_wait_time_overrides will fail if the thresholds are +/- 1 second of the requested max_wait_time, if you're using python date_time to calculate your observable durations.
We should understand why this is and if this is a problem.

action time: test uamqp c_counter vs python time/datetime module

wait for customer feedback
open a new one to improve livetest stability