snakemake cannot run multithreading scripts

Hi,
I have a script that uses multithreading, but the scripts cannot recgonize snakemake and caused an error "NameError: name 'snakemake' is not defined" when running with Snakemake. Not sure it was caused by snakemake itself or the script itself. Here is the related issue:
https://github.com/aertslab/pySCENIC/issues/523

It's like user "ghulp" commented in your issue to pyscenic: You could call your script via the shell directive as any no-snakemake script (along with flags and parameters) or show your code.

Are you still interested in getting help? This is not a bug. Snakemake can run multithreaded scripts, as Snakemake scripts or as from the shell.
BTW: the folks at Stack Overflow are really helpful when it comes to Snakemake.

Hi, I am on Chinese spring festival now. I'll try to call the script from shell because It doesn't work as snakemake scripts
script:
    scripts/pyscenic.py

In order to work as a "Snakemake script", it has to adhere to a set of requirements, see the docs, here. Without knowing the code, there is little anyone can do.

Hi,
I still cannot run pyscenic.py script, but I can run all other scripts. Here is all code I used:
rule pyscenic_module:
    input:
        adata ="scvi_integration/integration.h5ad"
    output:
        df_motifs = "pyscenic_module/df_motifs.csv",
        regulon_pkl = "pyscenic_module/integration_regulons.p",
        regulon_df = "pyscenic_module/integration_regulons.xlsx",
        auc_mtx = "pyscenic_module/integration_auc_mtx.csv",
        regulons_umap = "pyscenic_module/umap_integration_regulons.pdf",
        adata = "pyscenic_module/integration.h5ad",
        rss = "pyscenic_module/integration_rss/rss.csv",
        clustermap = "pyscenic_module/integration_clustermap.pdf",
        cluster_rows = "pyscenic_module/integration_clustermap_rows.csv",
        cluster_columns = "pyscenic_module/integration_clustermap_columns.csv"
    params:
        sc_plot = "pyscenic_module",
        rss_plot = "pyscenic_module/integration_rss/"
    threads: 10
    script:
        "scripts/pyscenic_module.py"

And this is the scripts:
import os
import pickle
import pandas as pd
import scanpy as sc

from arboreto.utils import load_tf_names
from arboreto.algo import grnboost2

from ctxcore.rnkdb import FeatherRankingDatabase as RankingDatabase
from pyscenic.utils import modules_from_adjacencies, load_motifs
from pyscenic.prune import prune2df, df2regulons
from pyscenic.aucell import aucell

from pyscenic.export import add_scenic_metadata
from pyscenic.rss import regulon_specificity_scores
from pyscenic.plotting import plot_rss

import matplotlib
import seaborn as sns
from matplotlib import pyplot as plt
matplotlib.use('Agg')
sc.settings.figdir = snakemake.params.sc_plot

# Generate expression matrix from anndata object
adata = sc.read_h5ad(snakemake.input.adata)
ex_matrix = pd.DataFrame(adata.layers['counts'].A,index=adata.obs_names,columns=adata.var_names)
# Load Transcription Factors
tf_names = load_tf_names(snakemake.config["scenic"]["TFs"])
# Load motif annotataions
motifs = snakemake.config["scenic"]["motifs"]
# Load ranking databases
db_fnames = snakemake.config["scenic"]["databases"].split(",")
def name(fname):
    return os.path.splitext(os.path.basename(fname))[0]
dbs = [RankingDatabase(fname=fname, name=name(fname)) for fname in db_fnames]
# Infer co-expression
adjacencies = grnboost2(ex_matrix, tf_names=tf_names, verbose=True)
# Add TF to the module and remove modules that have less than 20 genes
modules = list(modules_from_adjacencies(adjacencies, ex_matrix))
# Calculate a list of enriched motif and the corresponding target genes for all modules
df_motifs = prune2df(dbs, modules, motifs, num_workers=snakemake.threads)
# Save motifs and load again becuase of the bug reported in https://github.com/aertslab/pySCENIC/issues/509
df_motifs.to_csv(snakemake.output.df_motifs)
df_motifs = load_motifs(snakemake.output.df_motifs)
# Create regulons from this table of enriched motifs
regulons = df2regulons(df)

# Save the enriched motifs and discovered regulons to disk
with open(snakemake.output.regulon_pkl, "wb") as f:
    pickle.dump(regulons, f)
# Export regulons as a table
regulon_df =  pd.DataFrame(columns = ["regulon_name", "transcription_factor", "genes","weights", "score", "context"])
for i in range(len(regulons)):
    regulon = regulons[i]
    regulon_dict = dict({"regulon_name": regulon.name,"transcription_factor": regulon.transcription_factor,"genes":list(regulon.genes),
                    "weights":list(regulon.weights),"score":regulon.score,"context":list(regulon.context)})
    regulon_df = pd.concat([regulon_df, pd.DataFrame.from_dict(regulon_dict,orient="index").T], ignore_index=True)

regulon_df.genes = regulon_df.genes.apply(lambda x: ", ".join(x))
regulon_df.weights = regulon_df.weights.apply(lambda x: str(x))
regulon_df.weights = regulon_df.weights.apply(lambda x: x.replace('[', ''))
regulon_df.weights = regulon_df.weights.apply(lambda x: x.replace(']', ''))
regulon_df.context = regulon_df.context.apply(lambda x: ", ".join(x))
regulon_df.to_excel(snakemake.output.regulon_df,index=False) # Some strings are too long to save as csv

# Enrichment of a regulon is measured as the Area Under the recovery curve (AUC)
auc_mtx = aucell(ex_matrix, regulons, num_workers=snakemake.threads)
auc_mtx = auc_mtx[auc_mtx.columns[auc_mtx.sum(axis=0)!=0]] # Some columns are all zeros and need to be removed to run sns.clustermap
auc_mtx.to_csv(snakemake.output.auc_mtx)
# Integration with scanpy
add_scenic_metadata(adata, auc_mtx, regulons)
top6 = ["Regulon("+i+")" for i in auc_mtx.columns[0:6]]
sc.pl.umap(adata, color=top6, ncols=3, save="_integration_regulons.pdf")

Then I run snakemake using snakemake -j 30 -s multiSC.smk pyscenic_module/df_motifs.csv, the same error still occurred:

And by the way, I can run python version of pySCENIC inside snakemake rule successfully using run

Can you post full traceback as well as the wrapper script generated by snakemake? I wonder if this is a pickling issue

I doubt it's something related to dask.
"pySCENIC can be run on a single desktop machine but easily scales to multi-core clusters to analyze thousands of cells in no time. The latter is achieved via the dask framework for distributed computing"
But in fact, pySCENIC has a poor compatibility with dask:
https://github.com/aertslab/pySCENIC/issues/22
https://github.com/aertslab/pySCENIC/issues/524

The full traceback is too verbose so I copied the first 300 lines here and you can find the full one in the attachment.
Building DAG of jobs...
Using shell: /usr/bin/bash
Provided cores: 30
Rules claiming more threads will be scaled down.
Job stats:
job                count

pyscenic_module        1
total                  1
Select jobs to execute...
[Fri Feb 23 09:28:46 2024]
rule pyscenic_module:
input: scvi_integration/integration.h5ad
output: pyscenic_module/df_motifs.csv, pyscenic_module/integration_regulons.p, pyscenic_module/integration_regulons.xlsx, pyscenic_module/integration_auc_mtx.csv, pyscenic_module/umap_integration_regulons.pdf, pyscenic_module/integration.h5ad, pyscenic_module/integration_rss/rss.csv, pyscenic_module/integration_clustermap.pdf, pyscenic_module/integration_clustermap_rows.csv, pyscenic_module/integration_clustermap_columns.csv
jobid: 0
reason: Missing output files: pyscenic_module/integration_rss/rss.csv
threads: 10
resources: tmpdir=/home/wangjw/data/temp
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:67: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:84: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:101: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/distributed/node.py:182: UserWarning: Port 8787 is already in use.
Perhaps you already have a cluster running?
Hosting the HTTP server on port 37737 instead
warnings.warn(
preparing dask client
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:67: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:84: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:101: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:67: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:84: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:101: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:67: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:84: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:101: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:67: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:84: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:101: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:67: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:84: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:101: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:67: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:84: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:101: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:67: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:84: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:101: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:67: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:84: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:101: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
Traceback (most recent call last):
File "", line 1, in
File "/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/multiprocessing/spawn.py", line 122, in spawn_main
exitcode = _main(fd, parent_sentinel)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/multiprocessing/spawn.py", line 131, in _main
prepare(preparation_data)
File "/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/multiprocessing/spawn.py", line 246, in prepare
_fixup_main_from_path(data['init_main_from_path'])
File "/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/multiprocessing/spawn.py", line 297, in _fixup_main_from_path
main_content = runpy.run_path(main_path,
^^^^^^^^^^^^^^^^^^^^^^^^^
File "", line 291, in run_path
File "", line 98, in _run_module_code
File "", line 88, in _run_code
File "/data/wjw/test/singlecell/multiple/scripts/pyscenic_module.py", line 22, in
sc.settings.figdir = snakemake.params.sc_plot
^^^^^^^^^
NameError: name 'snakemake' is not defined
Traceback (most recent call last):
File "", line 1, in
File "/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/multiprocessing/spawn.py", line 122, in spawn_main
exitcode = _main(fd, parent_sentinel)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/multiprocessing/spawn.py", line 131, in _main
prepare(preparation_data)
File "/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/multiprocessing/spawn.py", line 246, in prepare
_fixup_main_from_path(data['init_main_from_path'])
File "/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/multiprocessing/spawn.py", line 297, in _fixup_main_from_path
main_content = runpy.run_path(main_path,
^^^^^^^^^^^^^^^^^^^^^^^^^
File "", line 291, in run_path
File "", line 98, in _run_module_code
File "", line 88, in _run_code
File "/data/wjw/test/singlecell/multiple/scripts/pyscenic_module.py", line 22, in
sc.settings.figdir = snakemake.params.sc_plot
^^^^^^^^^
NameError: name 'snakemake' is not defined
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:67: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:84: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:101: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:67: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:84: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:101: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:67: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:84: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:101: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:67: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:84: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:101: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:67: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:84: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:101: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:67: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:84: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:101: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:67: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:84: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:101: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
Traceback (most recent call last):
File "", line 1, in
File "/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/multiprocessing/spawn.py", line 122, in spawn_main
exitcode = _main(fd, parent_sentinel)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/multiprocessing/spawn.py", line 131, in _main
prepare(preparation_data)
File "/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/multiprocessing/spawn.py", line 246, in prepare
_fixup_main_from_path(data['init_main_from_path'])
File "/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/multiprocessing/spawn.py", line 297, in _fixup_main_from_path
main_content = runpy.run_path(main_path,
^^^^^^^^^^^^^^^^^^^^^^^^^
File "", line 291, in run_path
File "", line 98, in _run_module_code
File "", line 88, in _run_code
File "/data/wjw/test/singlecell/multiple/scripts/pyscenic_module.py", line 22, in
sc.settings.figdir = snakemake.params.sc_plot
^^^^^^^^^
NameError: name 'snakemake' is not defined
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:67: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:84: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/site-packages/loompy/bus_file.py:101: NumbaDeprecationWarning: The 'nopython' keyword argument was not supplied to the 'numba.jit' decorator. The implicit default value for this argument is currently False, but it will be changed to True in Numba 0.59.0. See https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit for details.
@jit
Traceback (most recent call last):
File "", line 1, in
File "/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/multiprocessing/spawn.py", line 122, in spawn_main
exitcode = _main(fd, parent_sentinel)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/multiprocessing/spawn.py", line 131, in _main
prepare(preparation_data)
File "/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/multiprocessing/spawn.py", line 246, in prepare
_fixup_main_from_path(data['init_main_from_path'])
File "/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/multiprocessing/spawn.py", line 297, in _fixup_main_from_path
main_content = runpy.run_path(main_path,
^^^^^^^^^^^^^^^^^^^^^^^^^
File "", line 291, in run_path
File "", line 98, in _run_module_code
File "", line 88, in _run_code
File "/data/wjw/test/singlecell/multiple/scripts/pyscenic_module.py", line 22, in
sc.settings.figdir = snakemake.params.sc_plot
^^^^^^^^^
NameError: name 'snakemake' is not defined
Traceback (most recent call last):
File "", line 1, in
File "/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/multiprocessing/spawn.py", line 122, in spawn_main
exitcode = _main(fd, parent_sentinel)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/multiprocessing/spawn.py", line 131, in _main
prepare(preparation_data)
File "/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/multiprocessing/spawn.py", line 246, in prepare
_fixup_main_from_path(data['init_main_from_path'])
File "/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/multiprocessing/spawn.py", line 297, in _fixup_main_from_path
main_content = runpy.run_path(main_path,
^^^^^^^^^^^^^^^^^^^^^^^^^
File "", line 291, in run_path
File "", line 98, in _run_module_code
File "", line 88, in _run_code
File "/data/wjw/test/singlecell/multiple/scripts/pyscenic_module.py", line 22, in
sc.settings.figdir = snakemake.params.sc_plot
^^^^^^^^^
NameError: name 'snakemake' is not defined
Traceback (most recent call last):
File "", line 1, in
File "/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/multiprocessing/spawn.py", line 122, in spawn_main
exitcode = _main(fd, parent_sentinel)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/multiprocessing/spawn.py", line 131, in _main
prepare(preparation_data)
File "/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/multiprocessing/spawn.py", line 246, in prepare
_fixup_main_from_path(data['init_main_from_path'])
File "/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/multiprocessing/spawn.py", line 297, in _fixup_main_from_path
main_content = runpy.run_path(main_path,
^^^^^^^^^^^^^^^^^^^^^^^^^
File "", line 291, in run_path
File "", line 98, in _run_module_code
File "", line 88, in _run_code
File "/data/wjw/test/singlecell/multiple/scripts/pyscenic_module.py", line 22, in
sc.settings.figdir = snakemake.params.sc_plot
^^^^^^^^^
NameError: name 'snakemake' is not defined
Traceback (most recent call last):
File "", line 1, in
File "/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/multiprocessing/spawn.py", line 122, in spawn_main
exitcode = _main(fd, parent_sentinel)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/multiprocessing/spawn.py", line 131, in _main
prepare(preparation_data)
File "/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/multiprocessing/spawn.py", line 246, in prepare
_fixup_main_from_path(data['init_main_from_path'])
File "/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/multiprocessing/spawn.py", line 297, in _fixup_main_from_path
main_content = runpy.run_path(main_path,
^^^^^^^^^^^^^^^^^^^^^^^^^
File "", line 291, in run_path
File "", line 98, in _run_module_code
File "", line 88, in _run_code
File "/data/wjw/test/singlecell/multiple/scripts/pyscenic_module.py", line 22, in
sc.settings.figdir = snakemake.params.sc_plot
^^^^^^^^^
NameError: name 'snakemake' is not defined
Traceback (most recent call last):
File "", line 1, in
File "/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/multiprocessing/spawn.py", line 122, in spawn_main
exitcode = _main(fd, parent_sentinel)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/multiprocessing/spawn.py", line 131, in _main
prepare(preparation_data)
File "/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/multiprocessing/spawn.py", line 246, in prepare
_fixup_main_from_path(data['init_main_from_path'])
File "/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/multiprocessing/spawn.py", line 297, in _fixup_main_from_path
main_content = runpy.run_path(main_path,
^^^^^^^^^^^^^^^^^^^^^^^^^
File "", line 291, in run_path
File "", line 98, in _run_module_code
File "", line 88, in _run_code
File "/data/wjw/test/singlecell/multiple/scripts/pyscenic_module.py", line 22, in
sc.settings.figdir = snakemake.params.sc_plot
^^^^^^^^^
NameError: name 'snakemake' is not defined
Traceback (most recent call last):
File "", line 1, in
File "/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/multiprocessing/spawn.py", line 122, in spawn_main
exitcode = _main(fd, parent_sentinel)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/multiprocessing/spawn.py", line 131, in _main
prepare(preparation_data)
File "/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/multiprocessing/spawn.py", line 246, in prepare
_fixup_main_from_path(data['init_main_from_path'])
File "/home/wangjw/programs/miniconda3/envs/py311/lib/python3.11/multiprocessing/spawn.py", line 297, in _fixup_main_from_path
main_content = runpy.run_path(main_path,
^^^^^^^^^^^^^^^^^^^^^^^^^
File "", line 291, in run_path
File "", line 98, in _run_module_code
File "", line 88, in _run_code
File "/data/wjw/test/singlecell/multiple/scripts/pyscenic_module.py", line 22, in
sc.settings.figdir = snakemake.params.sc_plot
^^^^^^^^^
NameError: name 'snakemake' is not defined
Traceback (most recent call last):
Uploading nohup.out.txt…

My best guess is that when pysenic/dask spawns child processes, snakemake object is not properly serialized and passed on. I don't know how Dask handles multiprocessing but you can try the following:

Use only a single thread in your script and see if the error goes away
Wrap your code in a function and pass snakemake in as an argument
Modify your script to work as a cli python script and call it from shell directive instead of script directive

I finally call pyscenic_module.py from script directive by enclose the code in a if name == 'main': construct.
This is a known case but it didn't work before (about two years before), but now it works. I don't know why, however, it can solve my problem now !


Add Tilt and Skaffold.

Add Tilt and Skaffold.
Minor markdown cleanup.
Bump actions/checkout to v2.
Partially fixes #5. It adds Tilt and Skaffold, but this does not make them optional.
I'm not really a javascript/typescript coder, so I basically did a copy-paste from when you added Rancher CLI.
I haven't really tested this, I'm hoping that this PR will do that for me.

Seems like specifying version doesn't work. But it doesn't feel like that's something I broke?

@Raboo Thank you for the PR. I'll take a look!

 I've fixed it now.

Alright nice, so when does this get merged?

@Raboo looks everything good! I merge now

@Raboo
https://github.com/yokawasa/action-setup-kube-tools/releases/tag/v0.4.0
Thanks alot!!


How can I wait for a promise result in a HttpActionResult method?

Hi there!
What the title says, basically.
I have an HttpActionResult in my API that calls for a method in a Third-party API.
I have the following code:
var aux = thirdPartyApiClient.Model.CreateModel(myModel);
            Model myResult = new Model();
            aux.Catch((exception) => {
                throw new Exception(exception.Message);
            });
            aux.Then((model) =>
            {
                myResult = model;
                //return this.Ok(model.Code);
            });

The problem is - I don't know in the moment how to wait for this result before returning to my application that updated result.
How can I properly wait for this result, for all the method to finish (CreateModel method) before returning something as HttpActionResult?

Does the 3rd party API give you some sort of callback?

@ashleydavis  Wonderful library but I am also caught up in this same situation. Third party API performs some data manipulation and returns an updated response or fails with reasons where required. How does one wait for the then/done/catch callbacks before dispatching an IHttpActionResult response to the calling client?
Thanks

Old question I know but I figured I should write a response in case anyone else comes across this. It all boils down to how the 3rd party API you're using works, so there is no single solution that will always work without seeing more info.
It depends how the 3rd party API you're
If the API gives you a way to pass a function called when the request is completed, you can create a new Promise<T>() when you first send the request and then call .Resolve(data) on it once you have a result.
IPromise<string> HttpGet(string url)
{
    var promise = new Promise<string>();
    ThirdPartyAPI.Get(url, data => promise.Resolve(data));
    return promise;
}

Similarly, if there is an event triggered when the request completes you can connect that to a function that resolves your promise.
If you want to convert an async/await API to use Promises you should be able to use similar code but call ContinueWith on the async task and resolve your new promise inside the ContinueWith callback. I haven't tested this method though, since async/await already has most of the functionality of Promises built-in anyway.


Allow fuzzy comparison of floats

Allow a limited number of significant digits to be checked, reducing the patch to only larger changes.

Closed in favour of https://github.com/larsyencken/csvdiff/pull/30


[Landcover toolkit] Upgrade API version, minor tweaks

My understanding is that v186–191 are functionally equivalent, and that the fix for https://github.com/google/earthengine-api/issues/103 has not been released yet. May want to stay on r185 until it goes out. Hopefully that's v192?

Didn't realize that version didn't include the fix. I'll hold off on upgrading for now and roll the other commit into another PR. Thanks!


carbon.agents.cache.size always increasing in 0.9.13pre1

I am running the 0.9.13pre1 (specifically 36749eedce6be908109d5133bc173721d9662733) and I am noticing that the carbon.agents.*.cache.size is always increasing.
My setup is as follows. 2 physical servers, both with 32GB RAM and 10x15K SAS disks in a RAID10. For the metric load I am sending the servers disks keep up just fine.
All metrics come into server 1 which replicates metrics to itself (0.9.12 carbon) and server 2 (0.9.13pre1 carbon) over plain-text using carbon-c-relay. The carbon.conf for the [cache] section are exactly identical and I am running two caches on each physical server. As you can see I limit the MAX_UPDATES_PER_SECOND = 500 for each cache which makes sense on this hardware. However it is clear that 0.9.13pre1 cache.size always increases whereas 0.9.12 does not.
I have attached two images which are the exact same metric targets just different hosts.

Not that I dispute your findings, but the cache.size on the 2nd graph certainly looks like a counter and not a derivative. Can you double-check your target definition there?

Sure thing. I thought the same thing, here is the actual URL (hostname scrubbed).
0.9.13pre1
http://db5234.$dayjob.com/render/?width=586&height=308&_salt=1422370542.946&from=-14days&target=alias(sumSeries(carbon.agents.*.cache.queues)%2C"cache.queues")&target=alias(secondYAxis(sumSeries(carbon.agents.*.cache.size))%2C"cache.size")&target=alias(sumSeries(carbon.agents.*.metricsReceived)%2C"Metrics Received")&target=alias(sumSeries(carbon.agents.*.updateOperations)%2C"Update Operations")&title=0.9.13pre1 Carbon
0.9.12
http://db1317.$dayjob.com/render/?width=586&height=308&_salt=1422370542.946&from=-14days&target=alias(sumSeries(carbon.agents.*.cache.queues)%2C"cache.queues")&target=alias(secondYAxis(sumSeries(carbon.agents.*.cache.size))%2C"cache.size")&target=alias(sumSeries(carbon.agents.*.metricsReceived)%2C"Metrics Received")&target=alias(sumSeries(carbon.agents.*.updateOperations)%2C"Update Operations")&title=0.9.12 Carbon

I'm not seeing this on my test systems, but I am seeing something possibly even more strange.

Confirmed in raw output that cache.size is being reported with negative values. Perhaps this is related to #266. /cc @jssjr @drawks

It appears when I change the cache.size metric to be a nonNegativeDerivative it looks much better.  However, I am not sure this is accurate either...
0.9.13pre1
http://db5234.oak1.omniture.com/render/?width=586&height=308&_salt=1422370542.946&from=-14days&target=alias(sumSeries(carbon.agents.*.cache.queues)%2C"cache.queues")&target=alias(secondYAxis(nonNegativeDerivative(sumSeries(carbon.agents.*.cache.size)))%2C"cache.size")&target=alias(sumSeries(carbon.agents.*.metricsReceived)%2C"Metrics Received")&target=alias(sumSeries(carbon.agents.*.updateOperations)%2C"Update Operations")&title=0.9.13pre1 Carbon with nonNegativeDerivative applied for cache.size

I've just checked on my systems. cache.size seems to be a counter on 0.9.13 and an absolute value on 0.9.12

In cache.py, in the pop function, I have added two debug lines before returning datapoints:
    log.msg("pop:coun:%d" % (len(self.counts))
    log.msg("pop1:data:%d" % (self.size) )

You will notice a large difference, In my case the carbon-cache receive 35k metrics per minute, after only 3 minutes.
19/02/2015 11:36:07 :: pop:coun:38494
19/02/2015 11:36:07 :: pop:size:267276

counts is calculated this way:
  @property
  def counts(self):
    return [(metric, len(datapoints)) for (metric, datapoints) in self.items()]

It seems that issue also connected with #266 - at least I see no other related changes. IMO performance gain from #266 is much more significant than that issue. We can note that change in documentation and close the issue.

https://github.com/graphite-project/carbon/pull/266/files#diff-b95553eddf4a9a25750a9a1d17f2be0cR66 from #266 makes me think there is a bug here if the size is no longer decreasing. Either way, I'd prefer to fix this than change the expected behavior of carbon's internal instrumentation in a patch release.

#408 doesn't address the MetricsCache size leak completely.  Metric data points that are dropped because of duplicate timestamps are not accounted for.  #266 has a patch for this, but I don't believe it works correctly in all configurations.  This is what I suggest:
--- a/lib/carbon/cache.py
+++ b/lib/carbon/cache.py
@@ -69,6 +69,10 @@
       popped = super(_MetricCache, self).pop(metric)
       ordered = sorted(dict(popped).items(), key=lambda x: x[0])
       datapoints = (metric, deque(ordered))
+      # Adjust size counter if we've dropped multiple identical timestamps
+      dropped = len(popped) - len(datapoints[1])
+      if dropped > 0:
+        self.size -= dropped
     self.size -= len(datapoints[1])
     return datapoints

Hi @jjneely ,
Tried your patch, working fine, thanks!

@deniszh this patch must be applied on this branch https://github.com/jssjr/carbon/commits/fix_metricscache_leak
Am I right?

Yes, it's need to be combined with https://github.com/graphite-project/carbon/pull/408

@deniszh Would you mind closing this out once that patch gets submitted and merged?


Feature: Export plain Archive

Description
Instead of exporting ODEM results in custom DSpace SAF-format, it shall be possible to export data as plain (ZIP-)Archive.
When doing, it shall also be possible to customize even further whether only the created OCR-data needs to be included, this way no METS goes back (useful with VLS-Backend), or if the OCR-data shall be included in the METS as local files.

implemented and merged


how to shim randombytes?

What is the proper way to shim/monkeypatch/replace this library?
I.e. I need to use my version of randomBytes() function for an exotic platform that is not supported.
Tried browserify().external(['randombytes']) it doesn't work: error: Cannot find module 'randombytes'.
Obviously my module randombytes is available, so the error is bogus.
And because browserify never produces any logs I have no idea what was included in the bundle and how exactly it searches for the module in question.

I don't know if this question is in scope, and it's 4 years past


making pubsub idempotent and other fixes

• Does any part of it require special attention?
• Does it relate to or fix any issue? closes https://github.com/klothoplatform/klotho-pro/issues/26
Pubsub was not idempotent or able to find any modules not in the base path of klotho config. We also did not have the names lined up between what our infra launched and what code expected.
Needed to add proxy files at the end so the plugin doesnt reprocess them and see more subscribers/publishers than intended.
Need to make sure we arent overwriting our core resources.
Standard checks

Unit tests: Any special considerations?
Docs: Do we need to update any docs, internal or public?
Backwards compatibility: Will this break existing apps? If so, what would be the extra work required to keep them working? Well it wouldnt have worked now, so no because the naming of infra will be different

Are there tests (unit or integration) that we can add to prove the problem is fixed?


GPU memory management issue when running multi-GPU code

This is a great package for multi-GPU code in Julia. I've been experimenting it with several examples to learn how things work. I was able to run most tests successfully, but I encountered this issue when running this multi-GPU example. I am trying to understand why I would encounter this bug. Is this related to CUDA.jl or is it because I can not manage the device buffer if I am not a system manager.
alexandrechen@saturn:~/code-samples/ParallelStencil.jl/examples$ julia --project=../ diffusion3D_multigpucpu_novis_noperf.jl
Global grid: 256x256x256 (nprocs: 1, dims: 1x1x1; device support: CUDA)
ERROR: LoadError: ArgumentError: Cannot free an unmanaged buffer.
Stacktrace:
[1] unsafe_free!(xs::CUDA.CuArray{Float64, 1, CUDA.Mem.HostBuffer}, stream::CUDA.CuStream)
@ CUDA ~/.julia/packages/CUDA/BbliS/src/array.jl:73
[2] unsafe_free!(xs::CUDA.CuArray{Float64, 1, CUDA.Mem.HostBuffer})
@ CUDA ~/.julia/packages/CUDA/BbliS/src/array.jl:70
[3] (::ImplicitGlobalGrid_CUDAExt.var"#free_cubufs#1")(bufs::Vector{Vector{Any}})
@ ImplicitGlobalGrid_CUDAExt ~/.julia/packages/ImplicitGlobalGrid/WHNmB/src/CUDAExt/update_halo.jl:39
[4] free_update_halo_cubuffers()
@ ImplicitGlobalGrid_CUDAExt ~/.julia/packages/ImplicitGlobalGrid/WHNmB/src/CUDAExt/update_halo.jl:28
[5] free_update_halo_cubuffers
@ ~/.julia/packages/ImplicitGlobalGrid/WHNmB/src/CUDAExt/update_halo.jl:6 [inlined]
[6] free_update_halo_buffers()
@ ImplicitGlobalGrid ~/.julia/packages/ImplicitGlobalGrid/WHNmB/src/update_halo.jl:104
[7] finalize_global_grid(; finalize_MPI::Bool)
@ ImplicitGlobalGrid ~/.julia/packages/ImplicitGlobalGrid/WHNmB/src/finalize_global_grid.jl:17
[8] finalize_global_grid
@ ~/.julia/packages/ImplicitGlobalGrid/WHNmB/src/finalize_global_grid.jl:15 [inlined]
[9] diffusion3D()
@ Main /storage/users/alexandrechen/code-samples/ParallelStencil.jl/examples/diffusion3D_multigpucpu_novis_noperf.jl:51
[10] top-level scope
@ /storage/users/alexandrechen/code-samples/ParallelStencil.jl/examples/diffusion3D_multigpucpu_novis_noperf.jl:54
in expression starting at /storage/users/alexandrechen/code-samples/ParallelStencil.jl/examples/diffusion3D_multigpucpu_novis_noperf.jl:54

Hi, thanks for reporting this issue. To help, could you please provide the output of versioninfo() within Julia, and the output of CUDA.versioninfo()? Also, which version of ParallelStencil are you using? Thanks

Hi, thanks for your prompt response!
I am using the latest ParallelStencil from the main branch (git pulled today)
I got the following output for versioninfo() and CUDA.versioninfo()
julia> versioninfo()
Julia Version 1.9.4
Commit 8e5136fa297 (2023-11-14 08:46 UTC)
Build Info:
Official https://julialang.org/ release
Platform Info:
OS: Linux (x86_64-linux-gnu)
CPU: 208 × Intel(R) Xeon(R) Platinum 8367HC CPU @ 3.20GHz
WORD_SIZE: 64
LIBM: libopenlibm
LLVM: libLLVM-14.0.6 (ORCJIT, cooperlake)
Threads: 1 on 208 virtual cores
Environment:
LD_LIBRARY_PATH_modshare = /packages/cuda/12.3/nsight-compute-2023.3.1/target/linux-desktop-glibc_2_11_3-x64:1::1:/packages/cuda/12.3/lib64:1:/home/users/alexandrechen/code-samples/amgx/include:1:/packages/cuda/12.3/nsight-systems-2023.3.3/target-linux-x64:1:/packages/cuda/12.3/extras/CUPTI/lib64:1:/opt/openmpi-3.0.0/lib:1
LD_RUN_PATH_modshare = /packages/cuda/12.3/bin:1
LD_RUN_PATH = /packages/cuda/12.3/bin
LD_LIBRARY_PATH = /packages/cuda/12.3/nsight-systems-2023.3.3/target-linux-x64:/packages/cuda/12.3/nsight-compute-2023.3.1/target/linux-desktop-glibc_2_11_3-x64:/packages/cuda/12.3/extras/CUPTI/lib64:/packages/cuda/12.3/lib64:/home/users/alexandrechen/code-samples/amgx/include:/opt/openmpi-3.0.0/lib:
julia> CUDA.versioninfo()
CUDA toolkit 11.7, artifact installation
NVIDIA driver 525.85.12, for CUDA 12.0
CUDA driver 12.0
Libraries:

CUBLAS: 11.10.1
CURAND: 10.2.10
CUFFT: 10.7.2
CUSOLVER: 11.3.5
CUSPARSE: 11.7.3
CUPTI: 17.0.0
NVML: 12.0.0+525.85.12
CUDNN: 8.30.2 (for CUDA 11.5.0)
CUTENSOR: 1.4.0 (for CUDA 11.5.0)

Toolchain:

Julia: 1.9.4
LLVM: 14.0.6
PTX ISA support: 3.2, 4.0, 4.1, 4.2, 4.3, 5.0, 6.0, 6.1, 6.3, 6.4, 6.5, 7.0, 7.1, 7.2, 7.3, 7.4, 7.5
Device capability support: sm_35, sm_37, sm_50, sm_52, sm_53, sm_60, sm_61, sm_62, sm_70, sm_72, sm_75, sm_80, sm_86

3 devices:
0: NVIDIA A100 80GB PCIe (sm_80, 73.863 GiB / 80.000 GiB available)
1: NVIDIA A100-PCIE-40GB (sm_80, 39.410 GiB / 40.000 GiB available)
2: NVIDIA A100-PCIE-40GB (sm_80, 39.293 GiB / 40.000 GiB available)

Could you please print the CUDA version (from your project folder --project=../)?

Thanks @omlins! For this repo, I got the CUDA.jl version in this project folder that seems to be outdated with the Project version.
(ParallelStencil) pkg> status --outdated
Project ParallelStencil v0.6.0
Status /storage/users/alexandrechen/code-samples/ParallelStencil.jl/Project.toml
⌅ [052768ef] CUDA v3.13.1 (<v5.2.0) [compat]
I will update everything and see if I still have the same issues. If so, I will open the issue in the ImplicitGlobalGrid repo and provide CUDA.jl version information.

The problem is likely due to old dependencies. After I cleaned up the repo and upgraded every dependency to the latest version, multiple issues that I experienced previously were gone. Thanks for the help @omlins @luraess!

Thanks @omlins! For this repo, I got the CUDA.jl version in this project folder that seems to be outdated with the Project version.

@AlexandreChern , could you tell me where you got the outdated Project from? I did not quite get that...

Thanks @omlins! For this repo, I got the CUDA.jl version in this project folder that seems to be outdated with the Project version.

@AlexandreChern , could you tell me where you got the outdated Project from? I did not quite get that...

It cloned this repo (ParallelStencil.jl) 2 years ago, even though I did git pull recently, the dependencies in the project environment were not updated, especially CUDA.jl. That's probably why I have these issues.

@AlexandreChern : you should install Julia packages using the package manager, see here: https://pkgdocs.julialang.org/v1/managing-packages/#Adding-registered-packages
Then you won't run into these and many other issues...

@AlexandreChern : you should install Julia packages using the package manager, see here: https://pkgdocs.julialang.org/v1/managing-packages/#Adding-registered-packages Then you won't run into these and many other issues...

Sure I will do that in the future when I use Julia packages. I cloned the git repo because I thought it would be easier to access sample code and source code, but I guess this is not intended and it would mess up dependencies and package environments.

You could dev the package then and it would install into .julua/dev.


Updated Helpfile of Set-PnPTerm #Example4

Type

[ ] Bug Fix
[ ] New Feature
[X] Sample

Related Issues?
Wrong command in help file, example no. 4.
What is in this Pull Request ?
I changed the command of example no. 4 to the correct command.

Thanks @smsdaniel, good catch. Has been merged, the docs will be updated tomorrow !
Much appreciated 😊


Maven warning on Delombok

❗ please do not add sensitive information in issues, you can provide extra information via email using issue number as reference ❗
Describe the issue
During build, the following warning is generated:
/core/src/main/java/nl/nn/adapterframework/pipes/MessageSendingPipe.java:140: warning: Not generating setHideMethod(): A method with that name already exists
16:50:59  	private @Getter @Setter HideMethod hideMethod = HideMethod.ALL;

Reporter
Ricardo

To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Screenshots
If applicable, add screenshots to help explain your problem.
Configuration
Please provide the configuration of the Pipe or Receiver with the problem.

Input
Please provide an example of the input message.
Alternatively, provide a Ladybug report.

Environment
Please go to the console of your Frank, click on 'Information' and copy-paste the results here.

Additional Environment

DBMS: [e.g. Oracle, MSSQL, MariaDB, MySql, PostgreSQL]
Browser: [e.g. Chrome, Safari, Edge, Firefox]

Additional Context
Add any other context about the problem here. (f.e. ladybug report / test adapter with larva test)

removing the @Setter annotation from the field will solve this issue


MalmoEnv obs reshape bugs

This issue is reproducible by using Env(reshape=True).
There are two bugs on this line:
https://github.com/microsoft/malmo/blob/master/MalmoEnv/malmoenv/core.py#L331
First, there is a call to np.ndarray.reshape with an invalid keyword (dtype). This can be rewritten as obs = obs.reshape((self.height, self.width, self.depth)).astype(np.uint8).
Second, this line should be un-indented so that it is outside the while loop and only called before step returns; otherwise we might try to reshape empty arrays.
Third, the reset function needs the same logic to handle reshaping observations. One option is to add
    if self.reshape:
            obs = obs.reshape((self.height, self.width, self.depth)).astype(np.uint8)

at the end of _peek_obs.
Let me know if you would like me to make these changes in a pull request. Thanks!

Thanks for this. The reshape option came from adding some MarLo missions and missed a commit. But you have improved it further for reset(). I've created a new pull request #832.

Looks good, thanks!


make sure offset classes are displayed correctly

Offsets were being generated without a column prefix
The ordering of generateOffsetClass was a bit off from what's generated in the scss

Thanks!


Analyse fluctuations

Proposed changes:

...

Status (please check what you already did):

[ ] added some tests for the functionality
[ ] updated the documentation
[ ] updated the changelog (please check changelog for instructions)
[ ] reformat files using black (please check Readme for instructions)

/modeltest
num_repetitions: 3
include:
 - dataset: ["all"]
   config: ["all"]


Improve code and handle errors

Ah thank you! Lot of small things like this might missing from it!

That was such a fast merge. dammmm

Yeaah im working too on my side, and just checked the repo saw it, i read trough it and it was such a nice little addition. Thank you really!


Extensions: run with specific coloring and/or formatting options

Even supporting the currently configured state-wide options would suffice.
$ git config git-state.format
pretty

$ git state extensions run log  # won't be pretty formatted or colored in any way
# log
3d27727 chore(*): release v0.8.0
686c6cc docs(README): updates testing and supported versions
0cb09bd docs(README): update Travis badge
1a69685 refactor(Settings): merge all formatting options into format_
3cb6e3b chore(*): fix CodeClimate issues
ea874b2 build(CodeClimate): only upload results for Python 3.6 build
db34c3e chore(dependencies): update coverage, mock, and future
f018f21 chore(*): increase coverage
3c0e6cb chore(dependencies): add missing future dependency
d858a18 test(Settings): add missing method

To keep thing simple, just respect the global git-state options and not not implement run-specific --format and --color flags.


can not add property _tracking, Object is not extensible, AnimatedRegion

Question
I'm getting this  can not add property _tracking, Object is not extensible every time I call this.state.coordinate.timinig(newCoords,500).start(), I looked over similar issues but I couldn't find any solution it frustrating me
here is my code 👍
state = {
    coordinate : new MapView.AnimatedRegion({
    latitude: 40.74586,
    longitude: -73.98434
  })
  }

##React Native Environment Info:

    System:
      OS: macOS 10.14.3
      CPU: (8) x64 Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz
      Memory: 1.20 GB / 16.00 GB
      Shell: 3.2.57 - /bin/bash
    Binaries:
      Node: 10.16.0 - /usr/local/bin/node
      Yarn: 1.17.0 - /usr/local/bin/yarn
      npm: 6.9.0 - /usr/local/bin/npm
      Watchman: 4.9.0 - /usr/local/bin/watchman
    SDKs:
      iOS SDK:
        Platforms: iOS 12.2, macOS 10.14, tvOS 12.2, watchOS 5.2
      Android SDK:
        API Levels: 16, 19, 23, 25, 27, 28, 29
        Build Tools: 28.0.0, 28.0.1, 28.0.2, 28.0.3, 29.0.0
        System Images: android-23 | Intel x86 Atom_64, android-23 | Google APIs Intel x86 Atom_64, android-25 | Intel x86 Atom_64, android-29 | Google APIs Intel x86 Atom, android-29 | Google APIs Intel x86 Atom_64, android-29 | Google Play Intel x86 Atom, android-29 | Google Play Intel x86 Atom_64
    IDEs:
      Xcode: 10.2.1/10E1001 - /usr/bin/xcodebuild
    npmPackages:
      react: 16.8.3 => 16.8.3
      react-native: 0.59.3 => 0.59.3

##react-native-maps version  :0.23.0

Try doing this:
this.state.coordinate.timinig({ ...newCoords, duration: 500 }).start()

@raphaelv1  still return the same error, I think the problem is from timing  method itself

Please provide more of you code. It's impossible to help you this way. Are you using MapView.Animated?

@raphaelv1   Yes here is the code the animated Marker

  <Marker.Animated
                coordinate={{
                  latitude: this.state.coordinate.latitude,
                  longitude: this.state.coordinate.longitude
                }}
                identifier={`coordinate_${index}`}
                heading={coordinate.heading ? coordinate.heading : 0}
              >
       <Image source={coordinate.icon} style={{ height: 25, width: 25 }} resizeMode="contain" />
</Marker.Animated>

const newPosition={
       latitude: position.latitude,
       longitude: position.longitude,
       latitudeDelta: LONGITUDE_DELTA,
       longitudeDelta: LATITUDE_DELTA
}
this.state.coordinate.timing(newPosition,500).start();

or
this.state.coordinate.timing({ ...newPosition, duration: 500 }).start();

The problem is with Marker.Animated the timing function is running  I got the error with I try to consume the animated Value with Marker.Animated

I made a gist for the code you can check the code here Gist

@hayanisaid did u find any solution ?
In my case i am trying to use OverlayAnimated and i faced the same issue


Quotes missing from suggested template

Describe the bug
Copying and pasting the suggested templates into a new HA install produces an error and refuses to accept the templates.
Screenshots

Desktop (please complete the following information):

OS: Debian Buster
Browser: Chrome
Version: Latest

Additional context
It seems that the fix is simply to add a single quotation mark before and after the entire value_template entry as show below:

Check the README now. I believe I added your fix.


4.1.0-RC1 fails to deploy

JDK: java version "1.8.0_45" Java(TM) SE Runtime Environment (build 1.8.0_45-b14) Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)

Tomcat: 7.0.62

CAS: 4.1.0-RC1

Overlay: vanilla overlay with no customizations

After building and deployinmg to TC, getting the following exception, failing to deploy it:
...

Caused by: java.lang.NoClassDefFoundError: net/sourceforge/cobertura/coveragedata/LightClassmapListener
	at java.lang.Class.getDeclaredMethods0(Native Method)
	at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
	at java.lang.Class.getDeclaredMethods(Class.java:1975)
...

@leleuj When you created the release, did you run the cobertura plugin? I think you did because RC1 is now instrumented with references to cobertura. That plugin should never be run directly. Did it somehow end up part of the release process?

I think we might have to redo the release again, because this is obviously broken very badly.

Indeed, it seems so. Though, I used <cobertura.skip>true</cobertura.skip> in the nocheck profile. Taking a look at the build logs, I see: [INFO] Instrumentation was successful.. So the plugin was not really disabled and instrumentation must have happened.
The RC1 won't be of any use. Thus, I won't make any announcement. I'll commit the changes in the release process and cut a RC2 next week with the cobertura plugin disabled.

How is that plugin activated in the release process? Which set of steps or phases trigger it?

As far as I know, the only way that plugin gets activated is if it's explicitly invoked on the command line and its goal called out. Otherwise, there is no need to skip it. It's only used by the CI build system to report test coverage, and should not be run automatically. I don't think any changes to the build are required unless a phase in the release cycle triggers that plugin, which would be very very odd.

I need to investigate, but I only ran: mvn release:clean release:prepare and mvn release:perform.

@leleuj Would you rather I take a look and see if I can make sense of this? and if so, cut RC2? I'll be out travelling for the next couple of days, and so today is my only open window to assist.

Any analysis will be helpful. Thanks.

Sure. I'll take a look later today.

I was able to duplicate the problem. Disabled cobertura for the release, released RC2 and tested it. All systems go.

Thanks. Great!

Just updated the documentation: https://github.com/Jasig/cas/commit/4cd182937b71d6c9ff6454d4095df62c93489bc3


HSEARCH-4814 Use failure reporter in offloading operation submitter

https://hibernate.atlassian.net/browse/HSEARCH-4814
I might've missed the point, but I didn't find a use for the T in a BiConsumer<T, Throwable>, so I just went with a simple Consumer<Throwable>.
I also went ahead and wrapped the call to the executor.accept(..) with a try/catch even though it should happen in the same thread, but since we already have a reporter in place...
And replaced the offloading lambdas with a class.
BTW did this happen anywhere, or it's more of a precaution?

Test failure is unrelated, merging. Thanks!


[CXF 4.0.4+] Remove workaround for CXF-8983

The workaround for https://issues.apache.org/jira/browse/CXF-8983 can be removed when this change https://github.com/apache/cxf/pull/1725#event-12026851393 reaches Quarkus CXF.
The commit Workaround CXF-8983 by excluding cxf-rt-rs-security-jose-jaxrs and adding cxf-rt-rs-security-jose in Quarkus CXF should be reverted.

In the end, https://github.com/apache/cxf/pull/1725#event-12026851393 was included in CXF 4.0.4 the second attempt, so the workaround was never committed to Quarkus CXF main.


bundler fails when files are imported by directory name (CommonJS idiom)

My main .d.ts file contained a line like:
// ./foo is subdirectory containing an `index.d.ts` file
import * as foo from './foo';

This failed. I fixed it by replacing ./foo by ./foo/index.

Do you mean to the original .d.ts file? generated by tsc ??
Can you paste here the error output?
Thanks.

@bjouhier can you help me to reproduce the problem?

I have a fix for this.  See https://github.com/TypeStrong/dts-bundle/pull/40

I finally have the right fix for this with a test.
See https://github.com/TypeStrong/dts-bundle/pull/42

As the repository contributors seem to be absent I have created a fork of the package with the pending PR which solves this merged.
Just replace npm dts-bundle package by dts-bundle-hot-fix .

I will take a look to it the nexts days.

0.6.0 npm version released.
Thanks!


⚠ Hartman Foundation has degraded performance

In da65dff, Hartman Foundation (https://gordonhartman.com/) experienced degraded performance:

HTTP code: 200
Response time: 2648 ms

Resolved: Hartman Foundation performance has improved in b3bc4a0.


feat: add chat latency and api: generate prompt starters

What type of PR is this?
/kind feature

What this PR does / why we need it
Which issue(s) this PR fixes

Fixes #
Special notes for your reviewer

@Abirdcfly  can you rebase the the latest branch and re-generate the swagger docs

@Abirdcfly can you rebase the the latest branch and re-generate the swagger docs

Done


Add Truncated normal

The tests fail sometimes

Codecov Report

Merging #83 (68c0395) into main (55486b7) will increase coverage by 0.78%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main      #83      +/-   ##
==========================================
+ Coverage   71.58%   72.36%   +0.78%
==========================================
  Files          15       15
  Lines        1457     1491      +34
==========================================
+ Hits         1043     1079      +36
+ Misses        414      412       -2

Impacted Files
Coverage Δ

preliz/distributions/__init__.py
100.00% <ø> (ø)

preliz/tests/test_mle.py
100.00% <ø> (ø)

preliz/distributions/continuous.py
98.57% <100.00%> (+0.09%)
:arrow_up:

preliz/tests/test_distributions.py
100.00% <100.00%> (ø)

preliz/tests/test_maxent.py
100.00% <100.00%> (ø)

preliz/utils/optimization.py
69.29% <100.00%> (+0.82%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


MudTooltip with MudList - unexpected results

Bug type
Component
Component name
MudList / MudTooltip
What happened?
If more than one MudTooltip is used in a MudList, the list loses its formatting and is shown horizontally.
If only one MudTooltip is included, the list is shown correctly regardless of which item has the tooltip  e.g.
https://try.mudblazor.com/snippet/QEQQulRbpwBgPRez
Expected behavior
The MudList should be shown vertically as expected with the tooltips.
As a workaround it is possible to use the title attribute on the MudListItem
Reproduction link
https://try.mudblazor.com/snippet/wOwwElxlTchwwyby
Reproduction steps

...
Relevant log output
No response
Version (bug)
6.0.4
Version (working)
Not sure
What browsers are you seeing the problem on?
Chrome, Microsoft Edge
On what operating system are you experiencing the issue?
Windows
Pull Request

[ ] I would like to do a Pull Request

Code of Conduct

[X] I agree to follow this project's Code of Conduct

As an alternate (better?) workaround, the issue can be avoided by constraining the width of the MudList, as here:
https://try.mudblazor.com/snippet/mawwEwEZJrRHhSDs

https://try.mudblazor.com/snippet/GuGwkWEqsRVaGLLE RootClass="mud-width-full" works.
If you still have problem please comment or open new issue.


hmm upgrades

Coverage remained the same at 100.0% when pulling 18cd2f5ee036596540ca142f3a09bee242699f10 on upgrades into b8bf85b89fc391c73e3d818ae14c2c6da4c4e847 on master.

Coverage remained the same at 100.0% when pulling 18cd2f5ee036596540ca142f3a09bee242699f10 on upgrades into b8bf85b89fc391c73e3d818ae14c2c6da4c4e847 on master.

Coverage remained the same at 100.0% when pulling 18cd2f5ee036596540ca142f3a09bee242699f10 on upgrades into b8bf85b89fc391c73e3d818ae14c2c6da4c4e847 on master.

Coverage remained the same at 100.0% when pulling 18cd2f5ee036596540ca142f3a09bee242699f10 on upgrades into b8bf85b89fc391c73e3d818ae14c2c6da4c4e847 on master.


request: pages on AprilTags

common errors while trying to use them to relocalize
common errors with the localizer itself
sources of error from relocalization

I'll write up a short page on the incorrectness of the backdrop AprilTag x positions in the official SDK, as well as a fix you can implement while the SDK gets updated with the correct positions.
If people think it's a good idea, I can also write a page on how to derive your field coordinates from the AprilTags.

I think a good one would be integrating ATags into RR v1.0.


Fix searchnode tuning doc options for index

http://docs.vespa.ai/documentation/content/setup-proton-tuning.html#index
Incorrectly lists mlock as an valid option for io.search. If you try 'mlock' it will fallback to 'normal' but pass xml schema validation. Also mmap is the default and the others like directio etc has limited test coverage so I'm suggesting to simply remove the io.search options and only allow mmap as io.search option. Instead add a flag for the POPULATE mmap option which is more common in use.

Fixed in 7.423.20


add workflow for 1.3.7 windows

Signed-off-by: Tianle Huang<EMAIL_ADDRESS>Description
[Describe what this change achieves]
Issues Resolved
[List any issues this PR will resolve]
Check List

[ ] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

OpenSearch is not working https://github.com/opensearch-project/opensearch-dashboards-functional-test/actions/runs/3625672093/jobs/6113962233


Enum value names

I have the following enum:
namespace WebApi.Logic.CustomPages.Dtos
{
    public enum CustomPageFieldType
    {
        Text = 1,
        Numeric,
        Date,
        Numeric_Function,
        Dropdown_List,
        Checkbox
    }
}

However, when a class includes this as a property it is shown as type (integer, optional) = ['1', '2', '3', '4', '5', '6']integerEnum:1, 2, 3, 4, 5, 6,, and when exported using NSwag as a Typescript enum it has the following definition:
export enum CustomPageFieldResponseDtoType {
    _1 = 1,
    _2 = 2,
    _3 = 3,
    _4 = 4,
    _5 = 5,
    _6 = 6,
}

How can i get it so that the enum is exported as:
export enum CustomPageFieldResponseDtoType {
    Text = 1,
    Numeric = 2,
    Date = 3,
    Numeric_Function = 4,
    Dropdown_List = 5,
    Checkbox = 6,
}

Thanks

I too have this same issue

This is currently not supported by the spec, see #348. Tooling can try to use extensions to overcome it.

@webron thanks for the info, but are there any examples?

Examples for what? It's not supported.

@webron I thought you said tooling and extensions can help.

I said people can try using them, I don't know if that would work. I do not have examples for it.

This is currently not supported by the spec, see #348. Tooling can try to use extensions to overcome it.

I don't think that #348 matches exactly the question. Please reconsider your answer and take the first step. Otherwise Swashbuckle, NSwag and others will never be able to generate decent C# / Typescript / ... enums. We developers are quite desperate.


Hard to know what host header will actually be sent

While there may be some extra steps, I came up with a dance to figure out what host will actually be sent on the wire in https://github.com/openzipkin/zipkin-aws/pull/135/commits/bf291076dbe6c5a15810bf7fc24039e5958afb66
I don't think knowing the host in a decorator is a super-common use case, but AWS's signature algorithm does require it and it's currently quite magical understanding how to have this value (I needed the step debugger). Hopefully the current move-connection-to-front work can help with this too.
// Gets the host for use in signing. This requires a ceremony because Armeria doesn't reliably
  // provide this information.
  //
  // - Depending on whether the request comes from a health check or normal, ctx.endpoint().host()
  //   may be an IP address, while the actual host is in either HOST or AUTHORITY additional
  //   headers.
  //
  // - The host extracted from additional headers usually has a port attached, even for well-defined
  //   ones like HTTPS:443. Armeria strips this off in the end before sending the request it seems
  //   so we need to make sure to strip it here too.
static String host(ClientRequestContext ctx) {
    String host = ctx.additionalRequestHeaders().get(HOST);
    if (host == null) {
      host = ctx.additionalRequestHeaders().get(HttpHeaderNames.AUTHORITY);
    }
    if (host == null) {
      host = ctx.endpoint().host();
    }

     int colonIndex = host.indexOf(':');
    if (colonIndex >= 0) {
      host = host.substring(0, colonIndex);
    }

     return host;
  }

/cc @adriancole

Yeah i think we can move it as well. /cc @minwoox (who's working on it)

I think this issue can be closed now that a user can get the actual authority via ClientRequestContext.endpoint().authority(). Please feel free to reopen if you think it's not fixed yet.


Mobile cruve problem

This issue has been reported (by Flo) while starting a new charging session on the mobile application.

Issue occurs when
plugins the car
Starting the session from the e-mobility
The session charge in the car is delay (like to start at 11pm)
The strange curve above with 0.1kw is displayed in the dashboard but in the mobile app the curve is definitely wrong...

The strange curve above with 0.1kw is displayed in the dashboard but in the mobile app the curve is definitely wrong...

Ok, thanks Fred for the investigation, I will have a look !

Session ID<PHONE_NUMBER> in charge@home

Fixed

Issue seems not reproducible any longer.


Log rotation support?

Hi! First of all thanks for building up this awesome gem, I am using it a lot. Second, I don't know If this is the right place to make sugestions, If not please let me know where.
I could not find a way to use a customer logger. I would like to do something like this inside a block:
config.logger = Logger.new(Rails.root.join("log", "cron.error.log"), "daily")

Is it possible or maybe could it be considered a future feature?
Thank you!

You can use output redirection to choose a log file. You can then use logrotate to rotate the file.


fix(foundation): make patterns compatible with v flag

Resolves #1265 .

@Stef3st I suggest this as the solution for your error.


Variant filter representation

VCF format specifies that the FILT column can take on the following values:
"PASS" - variant passed all filters
Comma-separated list of failing filters - filters that the variant call failed
"." - no filter applied
(see http://gatkforums.broadinstitute.org/discussion/3401/filter-column-in-vcf-file-from-haplotypecaller for a discussion on the output of the haplotype caller)
Right now, we have two fields in VariantCallingAnnotations:
boolean variantIsPassing
array<string> variantFilters

This table indicates the value of each variable for the different scenarios:

Scenario
variantIsPassing
variantFilters

Variant Passed
true
empty

Variant failed filter
false
failing filter list

No filters applied
true
empty

@mlinderm brought up that there is some ambiguity - we don't know the difference between variant passing and no filters applied without checking another field (the list of filters applied), and also people doing analysis were only likely to check the boolean, since that's what is done with the VCF field.  The proposal is to go back to the original way, which was:
union { null, boolean }  variantIsFiltered = null;
array<string> failingFilters = null;

New table:

Scenario
variantIsFiltered
failingFilters

Variant Passed
false
empty

Variant failed filter
true
failing filter list

No filters applied
null
empty

Note that in the case where the variant passed, the passing filters should still be available from the VCF header.
Thoughts?

See also:
Adding quality, filtersFailed, and filtersPassed to Variant https://github.com/ga4gh/schemas/pull/304

Shall we close this?

Fixed by #1250


Various improvements to documentation

fix(doc): Fix broken link to compiler notebook.
doc: Add contributor's guide
fix(doc): Fix syntax error in markdown source (CONTRIBUTING.md)
doc: Initial work on improved engine pages

This PR refactors some parts of the documentation as a preparation for the final deliverable. It would be great to have it merged quickly so I can then ping other people to fill it more.
Notable changes:

Add "Application Showcase" section (for use-case inspired guidelines), currently with space and drones use-cases.
Initial work on presenting the available engines in a table with high-level features
"Problem Representation" page should act as an overview of the various problem classes with pointers to detailed presentations (done for hierarchical and scheduling)
Added a "Contributor's guide" page, currently with explanation to build and update the documentation.
Added a "What is Planning" page
Integrated ICAPS tutorial material (currently some overlap with the Quickstart)

@Framba-Luca could you fill in the docs/engines/04_testing_engine.rst file with documentation on how to run the report tool and what is expected for a valid integration.
@mikand: The "Planning Engine Examples" (docs/notebooks/engines/README.md) page was needed for a deliverable right?  It feel a bit strange where it currently is or could even be removed entirely.
@alvalentini Could you review the docs/showcases/01-space.md document and perhaps add an illustration.

@arbimo
The Planning Engines Example page is not needed in the ReadTheDocs documentation. We've included this link (https://github.com/aiplan4eu/unified-planning/tree/master/docs/notebooks/engines) in a deliverable and we only need to keep the file reachable through that link.

Thanks @alvalentini and @Framba-Luca I have made a few changes following your remarks and contributions. I think this is now ready. I will ping engine developers to validate and complete it once the documentation is easily visible.


Add vishnupsingh523's file

I have created a file which was an activity by github bot.

All of things which I have learnt were amazing 👍  and I have also enjoyed it a lot.


[FEATURE] [MC-VERSION] Short description of the feature

Heyy just a real quick question/request. Im wondering how can I make the camera go even further back, the reason I ask is simple, the valkyrie skies mod lets you make custom ships and boats, for ease of visibility on where you're going especially for larger ships.
efforts I've made to get this result, changed config files, haven't been able to figure out what i should change to do this
what i got right now.

the perspective im trying to at least get close to

In .../.minecraft/config/shouldersurfing.toml set perspective.offset.limits.unlimited_offset_z to true. Such that the section of the config file will look as follows:
[perspective.offset.limits]
#Whether or not z-offset adjustment has limits
unlimited_offset_z = true
#Whether or not y-offset adjustment has limits
unlimited_offset_y = false
#Whether or not x-offset adjustment has limits
unlimited_offset_x = false

If you have any fruther questions, feel free to leave another comment in this issue.


Setup capstone proyect Urban Art Festival "Creativity in the Streets

Added all the HTML code for the project structure
Some empty containers were also left in order to insert the content dynamically as requested by the program.
The JS file was coded for the proper interaction and I inserted content within the HTML
Added all the code to style the pages as requested

@taldr27 Thanks for the review Diego, I have made the requested changes


Npm run shortcut

Allow npm run commands to be shortened by having a command with the pattern npm:cmd expand to npm run cmd and set the default name (and prefix) for that process to cmd.
Possible solution for #46.

Any chance this could be released on npm?

Release, finally 🙌 install v3.6.0 now to get this and other goodness!

Any plans for the same shortcuts for yarn?

@tyscorp not really; if I was to dedicate more time to evolve concurrently, it would be for fixing existing issues.
However, now that we have npm as a base, it might be easier to get yarn support, so I'm not opposed to someone contributing it 🙂


Document Font styles used for the Design Assets

Document the Font styles used for all the Design Assets as we intend to have a common style used through out all our future designs. It'd be great to have all the design decisions well documented for future designers to follow.
For reference, these are the Design Assets that were recently added:

PR: Update README
PR: Windows Musawo Logo

Tasks:

[ ] Add the name of the font style/typeface used in the designs to the design assets README file
[ ] Similarly, add the color codes used in the designs to the design assets README file.

@Victorayo since you worked on the design assets, It's best you help us work on this issue. Thanks

Alright boss. Will get it to you within 24 hrs hopefully.

I've sent a request on it already boss.


ladda adds two  elements for progress bar demo

just reporting a possible issue.
if you take a look at the demo for the progress bar buttons,
you'll see the button element looks like this:
<button class="btn btn-danger ladda-button" data-style="expand-right">
expand-right

</button>

if I manually remove one of the ladda-spinner elements it still seems to work fine.
is the extra element intended?

I faced this problem because I needed to change the state of a instance that was already been create so I came up with this approach, not clean though:
To create the Ladda objects use this:
$(".ladda-button").ladda().ladda("bind");
And to access a specific object use:
$(object).data("ladda").stop();
I found this solution looking at the ladda.jquery file.


Individual snapshots

This PR supports creating every frame as an individual pngs.
It adds a puppeteer helper to communicate with the external context in order to pause between frames and let the files be generated.

Can skottie get the pixels of each frame? I want to generate a video for ffmpeg by getting the pixels of each frame.


Re-enable symbols generation on x86

We temporarily disabled the generation of symbols for runtime stores on x86 due to missing DiaSymReader binaires. The proposal here is to download the x86 shared runtime and add the required binary to the PATH to ensure symbol generation on x86 succeeds.
We need this for preview2

This looks good to me overall, but I'm a bit surprised we don't already have the corresponding shared runtime on the agent (so having to download it.) Are we making sure it's the correct version of the shared runtime?
I'll leave the sign-off to other folks in the reviewers list.

@muratg Our builds always installs the x64 version of the shared runtime and cli. Symbol generation on x86 seems to be a special case so I'm re-running part of KoreBuild.ps1 that installs shared runtimes. I resolve the version from the current CLI and use the same one to install the x86 runtime so it should be kept in sync with the rest of the build.

@JunTaoLuo With the recent changes in the CI, the shared runtime version coming from the CLI may not be matching the shared runtime we picked up through our Integration ("CoreCLR") build. Maybe another mechanism is required?
cc @mikeharder

@muratg I spoke with @mikeharder and this mechanism is fine. Here, I'm using dotnet --info to figure out the version of the current shared framework host which is auto-rolled forward to the latest version installed. When we install a newer version of the shared framework, I have verified we get the latest version instead of the one that was bundled with the CLI.


Replace std::unordered_map with absl::node_hash_map?

In a number of places throughout the test code, and likely also in user's anticipated behavior of Envoy, it seems that the unordered nature of an unordered map has been ignored. The results are compared to constant strings where the resulting iteration is predicted, and this does not conform to stdc++ unordered map's definition.
For examples, two secrets are documented in an expected list of secrets, and compared to the string dump of an unordered map by SecretManagerImplTest.ConfigDumpHandlerStaticSecrets. In the second case (already fixed) we elected to simplify a configuration to a single element, to avoid this predictable, but inverted ordering that occurs in the libc++/libstdc++ vs msvc cpp runtime library implementations of std::unordered_map.
The later example was discussed at some length https://github.com/envoyproxy/envoy/pull/11335#pullrequestreview-421444954 - however the suggestion to use absl::flat_hash_map turned out to be a non-starter because it is non-deterministic by design. A request to add determinism for purposes such as Envoy seeks turn out to be roundly rejected by the absl authors, see the feedback of the feature request https://github.com/abseil/abseil-cpp/issues/339 for their philosophy.
As a general solution to this and similar observations of small sets for testing that are implemented in Envoy by an unordered_map today, it still seems sensible to migrate to absl::flat_hash_map for the very reason given by the abesil authors. This will obviously break tests which will need to be modified, and possibly could break some user expectations based on expected sequencing. Do we have any thoughts on the Envoy project's approach to this set of issues?
Tagging @mattklein123 and @sunjayBhatia for feedback.

Utilities like ::testing::UnorderedElementsAre may help with test ordering issues.  If the problem is non-determinism in string representations created for the benefit of humans, it may make sense to sort those containers while generating the string representation.  There is some precedent for sorting while generating string representation in the admin interface.
https://github.com/envoyproxy/envoy/blob/91905443ca743a22a347006e3e447a3d84e4b6e1/source/server/admin/admin.cc#L396

One option here would be to bulk migrate from unordered_map to absl::node_hash_map. This should be compatible in all cases, and we can then block unordered_map via format check. This will force the issue and the solutions that @antoniovicente outlines.

Utilities like ::testing::UnorderedElementsAre may help with test ordering issues

Yep, we're experimenting with that and also the protobuf MessageDifferencer to compare proto messages with repeated fields. The MessageDifferencer::TreatAsSet is useful for comparing repeated fields have the same unordered contents.

On the switch to absl::node_hash_map, per https://abseil.io/docs/cpp/guides/container#recommendation-1 we could prefer new code that doesn't rely on pointer stability to use absl::flat_hash_map, but yeah as per the docs it is safest to switch to absl::node_hash_map immediately, though there may be existing places we can assert we don't need pointer stability and can prefer absl::flat_hash_map

There is some precedent for sorting while generating string representation in the admin interface.

Yeah, anything like this that doesn't have tests ensuring ordering seems like it should.

See: https://github.com/envoyproxy/envoy/pull/11879