Timeout waiting for kernel_info reply

I imagine this could easily be an issue outside of the MATLAB kernel, but I've tried a completely new anaconda3 install and I'm still running into this issue. I had everything up and running previously, but coming back to this VM instance (on Google Cloud Compute) after a while, now things aren't working. I seem to be timing out waiting on kernel_info reply. This happens upon opening any notebook that uses the MATLAB kernel. From within Python, I can run engine.start_matlab() and interact with Matlab without any issues. The issue is also present using the built-in system python.
Any clue as to how I might debug this?
Here's the output of jupyter lab --debug, similar story using regular jupyter notebook as well.
[D 21:44:41.081 LabApp] Initializing websocket connection /api/kernels/24f05a15-e3a5-4db2-bfa6-151c143914bc/channels
[D 21:44:41.083 LabApp] Requesting kernel info from 24f05a15-e3a5-4db2-bfa6-151c143914bc
[D 21:44:41.083 LabApp] Connecting to: tcp://<IP_ADDRESS>:47723
[D 21:44:41.381 LabApp] Initializing websocket connection /api/kernels/24f05a15-e3a5-4db2-bfa6-151c143914bc/channels
[D 21:44:41.382 LabApp] Waiting for pending kernel_info request
[D 21:44:48.189 LabApp] 200 GET /api/sessions?1526939088160 (<IP_ADDRESS>) 1.23ms
[D 21:44:48.193 LabApp] 200 GET /api/terminals?1526939088162 (<IP_ADDRESS>) 0.61ms
[D 21:44:48.244 LabApp] 200 GET /api/contents/?content=1&1526939088210 (<IP_ADDRESS>) 4.22ms
[D 21:44:49.540 LabApp] activity on 24f05a15-e3a5-4db2-bfa6-151c143914bc: stream
[D 21:44:49.541 LabApp] activity on 24f05a15-e3a5-4db2-bfa6-151c143914bc: stream
[D 21:44:49.542 LabApp] activity on 24f05a15-e3a5-4db2-bfa6-151c143914bc: stream
[I 21:44:49.975 LabApp] KernelRestarter: restarting kernel (1/5), keep random ports
[D 21:44:49.976 LabApp] Starting kernel: ['/home/djoshea/anaconda3/envs/jupyter/bin/python', '-m', 'imatlab', '-f', '/run/user/1001/jupyter/kernel-24f05a15-e3a5-4db2-bfa6-151c143914bc.json']
[D 21:44:49.979 LabApp] Connecting to: tcp://<IP_ADDRESS>:51173
[W 21:44:51.086 LabApp] Timeout waiting for kernel_info reply from 24f05a15-e3a5-4db2-bfa6-151c143914bc
[D 21:44:51.087 LabApp] 101 GET /api/kernels/24f05a15-e3a5-4db2-bfa6-151c143914bc/channels?session_id=58c735d37a99058e960c60298a65bd04 (<IP_ADDRESS>) 10006.42ms
[D 21:44:51.088 LabApp] Opening websocket /api/kernels/24f05a15-e3a5-4db2-bfa6-151c143914bc/channels
[D 21:44:51.088 LabApp] Getting buffer for 24f05a15-e3a5-4db2-bfa6-151c143914bc
[D 21:44:51.088 LabApp] Connecting to: tcp://<IP_ADDRESS>:47723
[D 21:44:51.088 LabApp] Connecting to: tcp://<IP_ADDRESS>:49611
[D 21:44:51.089 LabApp] Connecting to: tcp://<IP_ADDRESS>:47527
[D 21:44:51.090 LabApp] 101 GET /api/kernels/24f05a15-e3a5-4db2-bfa6-151c143914bc/channels?session_id=91cac07509a19b3216b68ba3da3f6196 (<IP_ADDRESS>) 9709.14ms
[D 21:44:51.090 LabApp] Opening websocket /api/kernels/24f05a15-e3a5-4db2-bfa6-151c143914bc/channels
[D 21:44:51.090 LabApp] Getting buffer for 24f05a15-e3a5-4db2-bfa6-151c143914bc
[D 21:44:51.090 LabApp] Connecting to: tcp://<IP_ADDRESS>:47723
[D 21:44:51.090 LabApp] Connecting to: tcp://<IP_ADDRESS>:49611
[D 21:44:51.090 LabApp] Connecting to: tcp://<IP_ADDRESS>:47527
[D 21:44:51.179 LabApp] Initializing websocket connection /api/kernels/24f05a15-e3a5-4db2-bfa6-151c143914bc/channels
[D 21:44:51.182 LabApp] 101 GET /api/kernels/24f05a15-e3a5-4db2-bfa6-151c143914bc/channels?session_id=b3bb58fb9829974d9f5782a3894c7bc0 (<IP_ADDRESS>) 3.33ms
[D 21:44:51.182 LabApp] Opening websocket /api/kernels/24f05a15-e3a5-4db2-bfa6-151c143914bc/channels
[D 21:44:51.182 LabApp] Getting buffer for 24f05a15-e3a5-4db2-bfa6-151c143914bc
[D 21:44:51.182 LabApp] Connecting to: tcp://<IP_ADDRESS>:47723
[D 21:44:51.183 LabApp] Connecting to: tcp://<IP_ADDRESS>:49611
[D 21:44:51.183 LabApp] Connecting to: tcp://<IP_ADDRESS>:47527
[D 21:44:52.980 LabApp] KernelRestarter: restart apparently succeeded

And here's the environment I've setup using a fresh conda environment with python 3.6, then running conda install -c conda-forge jupyterlab, installing the matlabengine directly from within the Matlab 2017a directory, and then installing imatlab via python -mpip install git+https://github.com/imatlab/imatlab and python -mimatlab install, though I did need to relocate the installed kernel to sit within my conda env. This has all worked for me before.
(jupyter) ➜  ~ conda list
# packages in environment at /home/djoshea/anaconda3/envs/jupyter:
#
# Name                    Version                   Build  Channel
backcall                  0.1.0                      py_0    conda-forge
bleach                    2.1.3                      py_0    conda-forge
ca-certificates           2018.4.16                     0    conda-forge
certifi                   2018.4.16                py36_0    conda-forge
chardet                   3.0.4                     <pip>
decorator                 4.3.0                      py_0    conda-forge
entrypoints               0.2.3                    py36_1    conda-forge
gmp                       6.1.2                         0    conda-forge
html5lib                  1.0.1                      py_0    conda-forge
idna                      2.6                       <pip>
imatlab                   0.2.post34+g15e2523           <pip>
ipykernel                 4.8.2                    py36_0    conda-forge
ipython                   6.4.0                    py36_0    conda-forge
ipython_genutils          0.2.0                    py36_0    conda-forge
jedi                      0.12.0                   py36_0    conda-forge
jinja2                    2.10                     py36_0    conda-forge
jsonschema                2.6.0                    py36_1    conda-forge
jupyter_client            5.2.3                    py36_0    conda-forge
jupyter_core              4.4.0                      py_0    conda-forge
jupyterlab                0.32.1                   py36_0    conda-forge
jupyterlab_launcher       0.10.5                   py36_0    conda-forge
libedit                   3.1.20170329         h6b74fdf_2
libffi                    3.2.1                hd88cf55_4
libgcc-ng                 7.2.0                hdf63c60_3
libsodium                 1.0.16                        0    conda-forge
libstdcxx-ng              7.2.0                hdf63c60_3
markupsafe                1.0                      py36_0    conda-forge
matlabengineforpython     R2017b                    <pip>
mistune                   0.8.3                    py36_1    conda-forge
nbconvert                 5.3.1                      py_1    conda-forge
nbformat                  4.4.0                    py36_0    conda-forge
ncurses                   6.1                  hf484d3e_0
notebook                  5.5.0                    py36_0    conda-forge
openssl                   1.0.2o                        0    conda-forge
pandoc                    2.2.1                         0    conda-forge
pandocfilters             1.4.2                    py36_0    conda-forge
parso                     0.2.0                      py_0    conda-forge
pexpect                   4.5.0                    py36_0    conda-forge
pickleshare               0.7.4                    py36_0    conda-forge
pip                       10.0.1                   py36_0
plotly                    2.6.0                     <pip>
prompt_toolkit            1.0.15                   py36_0    conda-forge
ptyprocess                0.5.2                    py36_0    conda-forge
pygments                  2.2.0                    py36_0    conda-forge
python                    3.6.5                hc3d631a_2
python-dateutil           2.7.3                      py_0    conda-forge
pytz                      2018.4                    <pip>
pyzmq                     17.0.0                   py36_4    conda-forge
readline                  7.0                  ha6073c6_4
requests                  2.18.4                    <pip>
send2trash                1.5.0                      py_0    conda-forge
setuptools                39.1.0                   py36_0
simplegeneric             0.8.1                    py36_0    conda-forge
six                       1.11.0                   py36_1    conda-forge
sqlite                    3.23.1               he433501_0
terminado                 0.8.1                    py36_0    conda-forge
testpath                  0.3.1                    py36_0    conda-forge
tk                        8.6.7                hc745277_3
tornado                   5.0.2                    py36_0    conda-forge
traitlets                 4.3.2                    py36_0    conda-forge
urllib3                   1.22                      <pip>
wcwidth                   0.1.7                    py36_0    conda-forge
webencodings              0.5                      py36_0    conda-forge
wheel                     0.31.1                   py36_0
widgetsnbextension        3.2.1                     <pip>
xz                        5.2.4                h14c3975_4
zeromq                    4.2.5                         1    conda-forge
zlib                      1.2.11               ha838bed_2

python --version
Python 3.6.5 :: Anaconda, Inc.

lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 17.10
Release:   17.10
Codename:  artful

Does an old version of imatlab work? Can you bisect the failure?

I'm having trouble finding a working configuration now. I had everything working with the latest github master (including your last commit 26 days ago), so the only thing that could have changed is versions of jupyter (especially now since I just did a fresh install) and its ilk, or system wide settings / packages. The kernel is still working for me on my laptop (MacOS) and on a different gcloud VM instance, so it has to be something about the environment.
I'm trying to debug this kernel_info timeout but I'm not sure how to push further because my knowledge of ipython's internals is limited.

Is there a way to print debugging info from inside the _kernel.py source so that I can figure out how far it gets in the code before the kernel is restarting?

Jupyter captures all outputs, so the trick is to open an actual log file and write stuff into it.

Thanks, do you mean open a log file from within the python code of imatlab? (As opposed to some flag to jupyter notebook that I missed).

Yup, boring old open("/tmp/logfile.txt", "w").write("here")

Okay, thanks for the logging suggestion - that was critical. I figured it out. MatlabKernel's __init__ creates a MatlabHistory instance, which in turn parses the History.xml file. I'm not entirely sure why, but my History.xml apparently was taking longer than 10s to parse. So I'd see a log message just before parsing, and never see the one after parsing has completed. This presumably lead to the repeated timeouts.
Simply deleting my History.xml file has fixed the issue. Maybe it would be worth noting this in the Readme that deleting the History file may fix timeout issues? I suppose wrapping the parse operation to ensure it completes in a reasonable amount of time would fix this too, though certainly more code to write.
Thanks for your help!

Hmm...
The parsing is done by the very boring stdlib's ElementTree (https://github.com/imatlab/imatlab/blob/master/lib/imatlab/_kernel.py#L68).  How big was the history file?
Do you know where the jupyter timeout is set?

@anntzer , Any chance creating a conda package for this project?

Please do not report the same issue in two different threads.

@djoshea, this looks to be equivalent to #38, where History.xml never finishes getting read because there's a bad character in there somewhere.

Ah, had forgotten to close this. Yes, I imagine there was something awry with the file, but I was never able to reproduce the issue and hadn't kept the original History.xml file around. So I'll close this, assuming it's the same as #38 and can be resolved by deleting the history.


Adding Different Difficulty Levels in the Game [95-Whack a Mole]

Is your feature request related to a problem? Please describe.
Description
The default movement of the mole is very fast, and its very difficult to play it.
Describe the solution you'd like.
Solution
To resolve this issue we can add, different difficulty modes in the game, namely easy, medium and hard, that will decide the speed of mole.
Describe alternatives you've considered.
Adding an easy mode to slow down the mole will help the beginners to play the game as well.
Add any other context or screenshots about the feature request here.
https://github.com/swapnilsparsh/30DaysOfJavaScript/assets/141745373/da89af9b-eba9-472f-92c6-31467650aca7

@Dhruv-Gaba Thank you for providing your insight but it is not required as of now


input: kbd_matrix: add an kbd_matrix_state shell command

Add a "input kbd_matrix_state" shell command. This prints the state of a keyboard matrix in a much more compact representation than the normal input event dump, but also keeps track of any key seen during the execution and reports that on the "off" command. The output can be used to help setting the actual-key-mask property (https://github.com/zephyrproject-rtos/zephyr/pull/65703).

@gmarull @keith-zephyr ping


Removes duplicate property for "teams tab list" command. Closes #5900

Removes duplicate property called teamsAppTabId for teams tab list command. Closes #5900

Hi, since we had to align our v9 branch with the latest v8, some merge conflicts crept into your PR. Could you realign your changes with the latest v9, please? If you need any assistance, don't hesitate to ping us.

Hi @SmitaNachan, could you also update the v9 upgrade guidance and recheck our sample scripts for needed changes, please? Much appreciated 🙏

Due to an upcoming breaking change connected to CLI for Microsoft 365 login experience we will need to do a v9 release a bit sooner than we anticipated. Due to that we had to change the target of this PR to v10 which will be the next regular major release.

Hi @SmitaNachan did you have some time to resolve the conflicts and process the last feedback?

Hi @milanholemans
Ready for review

Hi @milanholemans
Can you please review and merge, before there are any more conflicts to resolve 😁

@SmitaNachan FYI, I rebased your PR with the latest main to save some time. Note that the branch on your local machine will be out of sync now.

Merged manually, thank you!


ImportError: cannot import name '_new_empty_tensor' from 'torchvision.ops'

Hi guys,
I'm trying to run: bash script/train/a0_train_stage1_res50.sh  res50_stage1
But unfortunately, I'm getting the following error:
Traceback (most recent call last):
  File "/home/cristopher/Workspace/LETR/src/main.py", line 13, in <module>
    import datasets
  File "/home/cristopher/Workspace/LETR/src/datasets/__init__.py", line 5, in <module>
    from .coco import build as build_coco
  File "/home/cristopher/Workspace/LETR/src/datasets/coco.py", line 10, in <module>
    import datasets.transforms as T
  File "/home/cristopher/Workspace/LETR/src/datasets/transforms.py", line 18, in <module>
    from util.misc import interpolate
  File "/home/cristopher/Workspace/LETR/src/util/misc.py", line 22, in <module>
    from torchvision.ops import _new_empty_tensor
ImportError: cannot import name '_new_empty_tensor' from 'torchvision.ops' (/home/cristopher/miniconda3/envs/letr/lib/python3.9/site-packages/torchvision/ops/__init__.py)
Traceback (most recent call last):
  File "/home/cristopher/Workspace/LETR/src/main.py", line 13, in <module>
    import datasets
  File "/home/cristopher/Workspace/LETR/src/datasets/__init__.py", line 5, in <module>
    from .coco import build as build_coco
  File "/home/cristopher/Workspace/LETR/src/datasets/coco.py", line 10, in <module>
    import datasets.transforms as T
  File "/home/cristopher/Workspace/LETR/src/datasets/transforms.py", line 18, in <module>
    from util.misc import interpolate
  File "/home/cristopher/Workspace/LETR/src/util/misc.py", line 22, in <module>
    from torchvision.ops import _new_empty_tensor
ImportError: cannot import name '_new_empty_tensor' from 'torchvision.ops' (/home/cristopher/miniconda3/envs/letr/lib/python3.9/site-packages/torchvision/ops/__init__.py)
Traceback (most recent call last):
Traceback (most recent call last):
  File "/home/cristopher/Workspace/LETR/src/main.py", line 13, in <module>
  File "/home/cristopher/Workspace/LETR/src/main.py", line 13, in <module>
        import datasetsimport datasets

  File "/home/cristopher/Workspace/LETR/src/datasets/__init__.py", line 5, in <module>
  File "/home/cristopher/Workspace/LETR/src/datasets/__init__.py", line 5, in <module>
        from .coco import build as build_cocofrom .coco import build as build_coco

  File "/home/cristopher/Workspace/LETR/src/datasets/coco.py", line 10, in <module>
  File "/home/cristopher/Workspace/LETR/src/datasets/coco.py", line 10, in <module>
        import datasets.transforms as Timport datasets.transforms as T

  File "/home/cristopher/Workspace/LETR/src/datasets/transforms.py", line 18, in <module>
  File "/home/cristopher/Workspace/LETR/src/datasets/transforms.py", line 18, in <module>
        from util.misc import interpolatefrom util.misc import interpolate

  File "/home/cristopher/Workspace/LETR/src/util/misc.py", line 22, in <module>
  File "/home/cristopher/Workspace/LETR/src/util/misc.py", line 22, in <module>
        from torchvision.ops import _new_empty_tensorfrom torchvision.ops import _new_empty_tensor

ImportErrorImportError: : cannot import name '_new_empty_tensor' from 'torchvision.ops' (/home/cristopher/miniconda3/envs/letr/lib/python3.9/site-packages/torchvision/ops/__init__.py)cannot import name '_new_empty_tensor' from 'torchvision.ops' (/home/cristopher/miniconda3/envs/letr/lib/python3.9/site-packages/torchvision/ops/__init__.py)

My setup has the following packages:
pytorch                   1.9.0           py3.9_cuda10.2_cudnn7.6.5_0    pytorch
torchvision               0.10.0                   pypi_0    pypi

I tried finding what was the actual problem, and had failed so far.

This version of the combination worked.

python: 3.7.10
pytorch: 1.8.0+cu111
torchvision: 0.9.0+cu11

If you are working on Colab, you can downgrade with the following command.
!pip install torch==1.8.0+cu111 torchvision==0.9.0+cu111 -f https://download.pytorch.org/whl/torch_stable.html

And then, I realized. At least, the following lines have a bug that judges torchvision version as 0.1 when it is 0.10.
https://github.com/mlpc-ucsd/LETR/blob/master/src/util/misc.py#L21
if float(torchvision.__version__[:3]) < 0.7:

Thank you for your input. This is the behavior for version '0.10'. A simple tweak solved it, but a lot of other problems emerged. I'll try addressing this myself, and then, maybe, returning a PR.
if float(torchvision.__version__[:3]) < 0.7:

returns
'0.1'


Add IsRegex Function (Issue #155)

Add IsRegex validator function which is based on RE2syntax (the syntax that go lang uses)

Q
A

Documentation
yes

Bugfix
no

BC Break
no

New Feature
yes

RFC
no

QA
no

Description

Thank you!


UI: Don't allow to de-select the PG connector type

When doing so (blue indicator bar on the PG tile disappears), I still can proceed to the next wizard page, but when validating there, an error is raised.

Pending PR #185 - User is allowed to deselect, but next button disables.  Also addresses console error on deselect.

Pr merged, closing this.


Add extension and onlyGenPaths options

The extension option allows the plugin to run on any specified extension
The onlyGenPaths option only stores the path in the metadata without
'moving' the file.
Feel free to change the option names or tell me to fix things or whatever. Hopefully this is helpful.

Thanks for the PR.
Could you resolve the conflicts or create a new PR based off master?

Having a path option that is out of sync with the actual path is not a good idea


Add global enabled configuration option

Sometimes you would like to disable auditing globally rather than specifying it per entity. As an example, when developing locally you wouldn't necessarily need auditing enabled but in production you would.
This pull request reduces the need for doing this per entity:
dh_doctrine_audit:
    entities:
        App\Entity\Example1:
            enabled: '%env(bool:AUDITING_ENABLED)%'
        App\Entity\Example2:
            enabled: '%env(bool:AUDITING_ENABLED)%'
        App\Entity\Example3:
            enabled: '%env(bool:AUDITING_ENABLED)%'

and allows you to simplify this, keeping your configuration clean, like so:
dh_doctrine_audit:
    global_enabled: '%env(bool:AUDITING_ENABLED)%'

The default value global_enabled is to audit as.

I close this PR as enabling/disabling was already part of the code (at runtime only). Though, there was no way to do it through configuration file. This is now done in PR #79.
Thanks anyway @MylesKingsnorth01!


Extract direction of effect from variant annotations

PGKB says they now provide the deconstructed sentences for the clinical annotations in their downloads, so it should be possible to pull out directionality related to the genotype-phenotype association.

I have finally located this, it is in variant annotations which looks to be very useful - one example with a few columns excluded:

Variant/Haplotypes
Gene
Drug(s)
Phenotype Category
Sentence
Alleles
isPlural
Is/Is Not associated
Direction of effect
Functional terms
Gene/gene product
When treated with/exposed to/when assayed with
Multiple drugs And/or
Cell type
Comparison Allele(s) or Genotype(s)

rs1349931378
CYP2C19
mephenytoin, omeprazole
Metabolism/PK
Allele A is associated with decreased activity...
A
Is
Associated with
decreased
activity of
CYP2C19
when assayed with
or
in 293FT cells
G

The following is a summary of the notebook here, looking into variant annotation tables generally and direction of effect more specifically.
@tcezard @dsuveges @ireneisdoomed @tskir Please have a look if you like and leave your comments/questions, otherwise we'll go through this notebook at a subsequent meeting.
Overview
PharmGKB provides 3 variant annotation tables, described in the readme as follows:

var_pheno_ann.tsv: Contains associations in which the variant affects a phenotype, with or without drug information. [13,517 rows in the 2024-05 data dump]
var_drug_ann.tsv: Contains associations in which the variant affects a drug dose, response, metabolism, etc. [11,901 rows]
var_fa_ann.tsv: Contains in vitro and functional analysis-type associations. [2,009 rows]

These variant annotations (plus drug labels/guidelines, not covered here) provide evidence for the clinical annotations, connected via an evidence ID.  The three types of variant annotations have different but overlapping columns; in general, each row describes an assertion made by a publication (PMID) about the effect of one or more allele/genotypes. See examples here and some breakdown of how the information is provided here.
Taken together, the variant annotations provide evidence for all clinical annotations and some kind of direction of effect for nearly all (>96%). If we select either of the larger tables, we get evidence for about half of all clincial annotations.
Direction of effect representation
If we focus on only one of these tables, we need "only" go through an exercise of selecting which columns we want to extract, and which (if any) we want to map. If we want to use all three tables, since the column schema differs among them, we could do the same thing and have lots of optional attributes to cover all three types of annotation, or just use the free-text sentence that is provided for each annotation.
If we want to use all three tables but present them in a unified and structured way, we need to come up with a generic representation of what "direction of effect" means. Based on the sentence breakdown I came up with one suggestion, but this obviously would require much more discussion:

Direction of effect (decreased, increased, or none)
PD/PK term | Functional term | Side effect/efficacy/other (e.g. response to, activity of, severity of)
Drug | Gene/gene product | Phenotype (e.g. ivacaftor, CFTR, side effect: bone density)

This tells us the direction (1) and what the effect is (2&3). Of course we need some other fields to connect things, but this could be the core "direction of effect" concept.
Of the above, (1) is always either "decreased" or "increased", (2) takes values in a relatively small but not fixed vocabulary (could perhaps be mapped to an EFO term), and (3) is open and would probably ideally be mapped. The values that appear can be found here.
Allele / genotype representation
This is really about how to connect the direction of effect to our current evidence strings. Associating variant annotations to clinical annotations via PMID or evidence ID is the most straightfoward method. Logically, however, direction of effect annotations should be allele / genotype specific, so I looked briefly into how these are represented in the new tables - basically, can we get a direction of effect per genotype or haplotype ID.
I think this is mostly doable, as the representation is consistent with what we've seen in the clinical annotations tables. The exception is that sometimes they've provided a metabolyzer type instead of an allele/genotype for comparison in the variant annotation. See here for an example. Honestly I have no idea how we could handle these right now.
Some questions to consider

Which tables do we want to include?

Basically are we interested in all the types of effects described

Which columns do we want to use? (for v1 at least)

Direction of effect can be quite a complex concept, what parts do we want to use as-is (strings) vs. map to ids vs. omit entirely?

How do we want to make the association with clinical annotations?

via allele/genotype, via PMID, something else?
aggregated (as PMID is currently) or exploded (as allele/genotype)?

As discussed, this spreadsheet contains examples of clinical annotations with their allele/genotype annotations and variant annotations. There are 4 clinical annotations in total, including one with "metabolyzer type" comparisons which we didn't have time to cover in the meeting. The data is split into tabs by variant annotation type and includes all columns, though I've hidden some to make things a bit easier to read.
Let me know any questions or thoughts you have!

@tcezard @DSuveges @ireneisdoomed @tskir - I've been looking into how to associate variant annotations with clinical annotations at the level of genotype/allele. We can go over this together in our next meeting, but meanwhile feel free to leave your thoughts and questions.
I've done a rough proof-of-concept of what the associations might look like. The algorithm is not particularly clever, it basically amounts to decomposing genotype/allele strings until we get to alleles, and doing exact string matching to line things up. It also makes a core assumption, which is that annotations on alleles can be associated with any genotype containing that allele. So if we have variant annotations on alleles C and T, both will be associated with genotype CT. Conversely, if we have a variant annotation on genotype *1/*18, it will be associated with alleles *1 and *18.
You can see the algorithm itself in the notebook here and the results on a handful of examples in the spreadsheet here (with columns removed for readability).
I also ran this on the entire dataset and found it could successfully associate 93.7% of variant annotations, and it found at least one variant annotation for 65.1% of clinical annotation genotypes. There are definitely some tricky cases I know it fails on, and probably some I don't know about! Also, the approximately 2/3 clinical annotation genotype coverage is not unexpected given that we often don't have variant annotations for the ref/ref genotype.
I've got at least a couple questions for us to discuss:

Does the assumption highlighted above (about genotypes/allele associations) seem reasonable?
What we should do about ref/ref genotypes?

I think we should start by reiterating what we are aiming to get out of the association between genotype and variant annotation:

A set of decomposed statement for each genotypes that are hopefully concordant and can be summarised programatically (assuming all the statments have the same direction of effects)
A set of statements associated with each genotype that can be fed to chat-gpt to help summarise the direction of effects
A set of publications associated with each genotype to give confidence in each statement as they could provide independent sources.

This being said, the algorithm is good enough for a first pass and without starting to explode the * alleles in their individual rs components we might not get much better.
For the ref/ref genotypes, they should be associated with the evidence that mentions this allele and not the other. OT could on its side highlight this genotype as the ref/ref so not associated with any evidence
I though we said previously that all Clinical annotation had at least one piece of evidence associated from either of the 3 source. Is the 65% due to the fact that we are counting the exploded clinical annotation per genotype id ?

I though we said previously that all Clinical annotation had at least one piece of evidence associated from either of the 3 source. Is the 65% due to the fact that we are counting the exploded clinical annotation per genotype id ?

Yes that's exactly it. I just checked coverage of clinical annotations not exploded by genotype, and it's 99.3%. (Of course if we just wanted to associate variant annotations with clinical annotations, not exploding by allele/genotype, our coverage would be 100% as we can do this directly by IDs...)

@DSuveges @ireneisdoomed Hi all, based on past discussions I've looked a bit into how we might extract or summarise direction of effect information from associated variant annotations. I've written this up in a document along with some examples of what the evidence strings could look like, just as a first step. Please take a look and leave your comments.


Repo sync for protected CLA branch

The pull request is created from main638083621155906167sync_temp to main to fix git push error for protected CLA branch

Learn Build status updates of commit be9b574:
:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the learn.microsoft.com contributor guidesPost your question in the Learn support channel


[SUPPORT] Query about the product

Tips before filing an issue

Have you gone through our FAQs?

Join the mailing list to engage in conversations and get faster support at<EMAIL_ADDRESS>

If you have triaged this as a bug, then file an issue directly.

Describe the problem you faced
The user query is: Hello again . There there
Additional context
Add any other context about the problem here.
Stacktrace
Add the stacktrace of the error.

gg

gg

hey

kk

kk


Reacting to YesSql API changes

Fixing a build error.
/cc @sebastienros

I am also working on this, but trying to fix two things at the same time, which is why I will probably fail ;)

@sebastienros Give me a sec

It works now :smiley:


iOS 14 Support

On current iOS 14 Public Beta (18A5319i) the App is just showing a black screen. Furthermore in Settings->Privacy->Health no active App is recognised.

Please see our FAQ and the iOS Beta release notes. The Exposure Notification Framework is not yet available in iOS 14 Betas: https://www.coronawarn.app/en/faq/#ios_14_beta
Mit freundlichen Grüßen/Best regards,
SW
Corona Warn-App Open Source Team


USE_GCC=4.4 CONFIG=opt TEST=build failed

Using worker: worker-linux-3da96de7-2.bb.travis-ci.org:travis-linux-19
travis_fold:start:system_info
Build system information
Build language: cpp
Build image provisioning date and time
Wed Feb  4 18:22:50 UTC 2015
Operating System Details
Distributor ID:	Ubuntu
Description:	Ubuntu 12.04 LTS
Release:	12.04
Codename:	precise
Linux Version
2.6.32-042stab090.5
Cookbooks Version
23bb455 https://github.com/travis-ci/travis-cookbooks/tree/23bb455
GCC version
gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
LLVM version
clang version 3.4 (tags/RELEASE_34/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
Pre-installed Ruby versions
ruby-1.9.3-p551
Pre-installed Node.js versions
v0.10.36
Pre-installed Go versions
1.4.1
Redis version
redis-server 2.8.19
riak version
2.0.2
MongoDB version
MongoDB 2.4.12
CouchDB version
couchdb 1.6.1
Neo4j version
1.9.4
Cassandra version
2.0.9
RabbitMQ Version
3.4.3
ElasticSearch version
1.4.0
Installed Sphinx versions
2.0.10
2.1.9
2.2.6
Default Sphinx version
2.2.6
Installed Firefox version
firefox 31.0esr
PhantomJS version
1.9.8
ant -version
Apache Ant(TM) version 1.8.2 compiled on December 3 2011
mvn -version
Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T17:29:23+00:00)
Maven home: /usr/local/maven
Java version: 1.7.0_76, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-7-oracle/jre
Default locale: en, platform encoding: UTF-8
OS name: "linux", version: "2.6.32-042stab090.5", arch: "amd64", family: "unix"
travis_fold:end:system_info

travis_fold:start:git.checkout
travis_time:start:015840d0
$ git clone --depth=50 git://github.com/grpc/grpc.git grpc/grpc
Cloning into 'grpc/grpc'...
remote: Counting objects: 23170, done.
Receiving objects:   0% (1/23170)
Receiving objects:   1% (232/23170)
Receiving objects:   2% (464/23170)
Receiving objects:   3% (696/23170)
Receiving objects:   4% (927/23170)
Receiving objects:   5% (1159/23170)
Receiving objects:   6% (1391/23170)
Receiving objects:   7% (1622/23170)
Receiving objects:   8% (1854/23170)
Receiving objects:   9% (2086/23170)
Receiving objects:  10% (2317/23170)
Receiving objects:  11% (2549/23170)
Receiving objects:  12% (2781/23170)
Receiving objects:  13% (3013/23170)
Receiving objects:  14% (3244/23170)
Receiving objects:  15% (3476/23170)
Receiving objects:  16% (3708/23170)
Receiving objects:  17% (3939/23170)
Receiving objects:  18% (4171/23170)
Receiving objects:  19% (4403/23170)
Receiving objects:  20% (4634/23170)
Receiving objects:  21% (4866/23170)
Receiving objects:  22% (5098/23170)
Receiving objects:  23% (5330/23170)
Receiving objects:  24% (5561/23170)
Receiving objects:  25% (5793/23170)
Receiving objects:  26% (6025/23170)
Receiving objects:  27% (6256/23170)
Receiving objects:  28% (6488/23170)
Receiving objects:  29% (6720/23170)
Receiving objects:  30% (6951/23170)
Receiving objects:  31% (7183/23170)
Receiving objects:  32% (7415/23170)
Receiving objects:  33% (7647/23170)
Receiving objects:  34% (7878/23170)
Receiving objects:  35% (8110/23170)
Receiving objects:  36% (8342/23170)
Receiving objects:  37% (8573/23170)
Receiving objects:  38% (8805/23170)
Receiving objects:  39% (9037/23170)
Receiving objects:  40% (9268/23170)
Receiving objects:  41% (9500/23170)
Receiving objects:  42% (9732/23170)
Receiving objects:  43% (9964/23170)
Receiving objects:  44% (10195/23170)
Receiving objects:  45% (10427/23170)
Receiving objects:  46% (10659/23170)
Receiving objects:  47% (10890/23170)
Receiving objects:  48% (11122/23170)
Receiving objects:  49% (11354/23170)
Receiving objects:  50% (11585/23170)
Receiving objects:  51% (11817/23170)
Receiving objects:  52% (12049/23170)
Receiving objects:  53% (12281/23170)
Receiving objects:  54% (12512/23170)
Receiving objects:  55% (12744/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  56% (12976/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  57% (13207/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  58% (13439/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  59% (13671/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  60% (13902/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  61% (14134/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  62% (14366/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  63% (14598/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  64% (14829/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  65% (15061/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  66% (15293/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  67% (15524/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  68% (15756/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  69% (15988/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  70% (16219/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  71% (16451/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  72% (16683/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  73% (16915/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  74% (17146/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  75% (17378/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  76% (17610/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  77% (17841/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  78% (18073/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  79% (18305/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  80% (18536/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  81% (18768/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  82% (19000/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  83% (19232/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  84% (19463/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  85% (19695/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  86% (19927/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  87% (20158/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  88% (20390/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  89% (20622/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  90% (20853/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  91% (21085/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  92% (21317/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  93% (21549/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  94% (21780/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  95% (22012/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  96% (22244/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  97% (22475/23170), 4.46 MiB | 8.89 MiB/s
remote: Total 23170 (delta 16727), reused 20012 (delta 13984), pack-reused 0
Receiving objects:  98% (22707/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects:  99% (22939/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects: 100% (23170/23170), 4.46 MiB | 8.89 MiB/s
Receiving objects: 100% (23170/23170), 7.25 MiB | 8.89 MiB/s, done.

Checking connectivity... done.
travis_time:end:015840d0:start=1431395788112028198,finish=1431395793052085900,duration=4940057702
$ cd grpc/grpc
travis_time:start:018692e8
$ git fetch origin +refs/pull/1549/merge:
remote: Counting objects: 9, done.
remote: Compressing objects:  11% (1/9)
remote: Compressing objects:  22% (2/9)
remote: Compressing objects:  33% (3/9)
remote: Compressing objects:  44% (4/9)
remote: Compressing objects:  55% (5/9)
remote: Compressing objects:  66% (6/9)
remote: Compressing objects:  77% (7/9)
remote: Compressing objects:  88% (8/9)
remote: Compressing objects: 100% (9/9)
remote: Compressing objects: 100% (9/9), done.
remote: Total 9 (delta 7), reused 2 (delta 0), pack-reused 0
Unpacking objects:  11% (1/9)
Unpacking objects:  22% (2/9)
Unpacking objects:  33% (3/9)
Unpacking objects:  44% (4/9)
Unpacking objects:  55% (5/9)
Unpacking objects:  66% (6/9)
Unpacking objects:  77% (7/9)
Unpacking objects:  88% (8/9)
Unpacking objects: 100% (9/9)
Unpacking objects: 100% (9/9), done.
From git://github.com/grpc/grpc

branch            refs/pull/1549/merge -> FETCH_HEAD
travis_time:end:018692e8:start=1431395793060423491,finish=1431395793296705105,duration=236281614
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout
travis_fold:start:git.submodule
travis_time:start:1f84f614
$ git submodule init
Submodule 'third_party/gflags' (https://github.com/gflags/gflags.git) registered for path 'third_party/gflags'
Submodule 'third_party/openssl' (https://github.com/openssl/openssl.git) registered for path 'third_party/openssl'
Submodule 'third_party/protobuf' (https://github.com/google/protobuf.git) registered for path 'third_party/protobuf'
Submodule 'third_party/zlib' (https://github.com/madler/zlib) registered for path 'third_party/zlib'
travis_time:end:1f84f614:start=1431395793341003347,finish=1431395793458513143,duration=117509796
travis_time:start:037e1de8
$ git submodule update
Cloning into 'third_party/gflags'...
remote: Counting objects: 1767, done.

Checking connectivity... done.
Submodule path 'third_party/gflags': checked out '05b155ff59114735ec8cd089f669c4c3d8f59029'
Cloning into 'third_party/openssl'...
remote: Counting objects: 166740, done.
Receiving objects:   0% (1/166740)
Receiving objects:   1% (1668/166740)
Receiving objects:   2% (3335/166740)
Receiving objects:   3% (5003/166740)
Receiving objects:   4% (6670/166740)
Receiving objects:   5% (8337/166740)
Receiving objects:   6% (10005/166740)
Receiving objects:   7% (11672/166740)
Receiving objects:   8% (13340/166740)
Receiving objects:   9% (15007/166740)
Receiving objects:  10% (16674/166740), 3.41 MiB | 6.79 MiB/s
Receiving objects:  11% (18342/166740), 3.41 MiB | 6.79 MiB/s
Receiving objects:  12% (20009/166740), 3.41 MiB | 6.79 MiB/s
Receiving objects:  13% (21677/166740), 3.41 MiB | 6.79 MiB/s
Receiving objects:  14% (23344/166740), 3.41 MiB | 6.79 MiB/s
Receiving objects:  15% (25011/166740), 3.41 MiB | 6.79 MiB/s
Receiving objects:  16% (26679/166740), 3.41 MiB | 6.79 MiB/s
Receiving objects:  16% (26818/166740), 3.41 MiB | 6.79 MiB/s
Receiving objects:  17% (28346/166740), 8.76 MiB | 8.74 MiB/s
Receiving objects:  18% (30014/166740), 8.76 MiB | 8.74 MiB/s
Receiving objects:  19% (31681/166740), 8.76 MiB | 8.74 MiB/s
Receiving objects:  20% (33348/166740), 17.66 MiB | 11.75 MiB/s
Receiving objects:  21% (35016/166740), 17.66 MiB | 11.75 MiB/s
Receiving objects:  22% (36683/166740), 17.66 MiB | 11.75 MiB/s
Receiving objects:  23% (38351/166740), 17.66 MiB | 11.75 MiB/s
Receiving objects:  24% (40018/166740), 17.66 MiB | 11.75 MiB/s
Receiving objects:  25% (41685/166740), 17.66 MiB | 11.75 MiB/s
Receiving objects:  25% (42033/166740), 17.66 MiB | 11.75 MiB/s
Receiving objects:  26% (43353/166740), 27.72 MiB | 13.83 MiB/s
Receiving objects:  27% (45020/166740), 27.72 MiB | 13.83 MiB/s
Receiving objects:  28% (46688/166740), 27.72 MiB | 13.83 MiB/s
Receiving objects:  29% (48355/166740), 27.72 MiB | 13.83 MiB/s
Receiving objects:  30% (50022/166740), 27.72 MiB | 13.83 MiB/s
Receiving objects:  31% (51690/166740), 27.72 MiB | 13.83 MiB/s
Receiving objects:  32% (53357/166740), 27.72 MiB | 13.83 MiB/s
Receiving objects:  33% (55025/166740), 27.72 MiB | 13.83 MiB/s
Receiving objects:  34% (56692/166740), 38.19 MiB | 15.24 MiB/s
Receiving objects:  35% (58359/166740), 38.19 MiB | 15.24 MiB/s
Receiving objects:  36% (60027/166740), 38.19 MiB | 15.24 MiB/s
Receiving objects:  37% (61694/166740), 38.19 MiB | 15.24 MiB/s
Receiving objects:  38% (63362/166740), 38.19 MiB | 15.24 MiB/s
Receiving objects:  39% (65029/166740), 38.19 MiB | 15.24 MiB/s
Receiving objects:  40% (66696/166740), 38.19 MiB | 15.24 MiB/s
Receiving objects:  41% (68364/166740), 38.19 MiB | 15.24 MiB/s
Receiving objects:  42% (70031/166740), 38.19 MiB | 15.24 MiB/s
Receiving objects:  43% (71699/166740), 38.19 MiB | 15.24 MiB/s
Receiving objects:  44% (73366/166740), 38.19 MiB | 15.24 MiB/s
Receiving objects:  45% (75033/166740), 38.19 MiB | 15.24 MiB/s
Receiving objects:  46% (76701/166740), 38.19 MiB | 15.24 MiB/s
Receiving objects:  47% (78368/166740), 38.19 MiB | 15.24 MiB/s
Receiving objects:  48% (80036/166740), 38.19 MiB | 15.24 MiB/s
Receiving objects:  49% (81703/166740), 38.19 MiB | 15.24 MiB/s
Receiving objects:  50% (83370/166740), 38.19 MiB | 15.24 MiB/s
Receiving objects:  51% (85038/166740), 38.19 MiB | 15.24 MiB/s
Receiving objects:  52% (86705/166740), 38.19 MiB | 15.24 MiB/s
Receiving objects:  52% (87684/166740), 38.19 MiB | 15.24 MiB/s
Receiving objects:  53% (88373/166740), 47.02 MiB | 15.64 MiB/s
Receiving objects:  54% (90040/166740), 47.02 MiB | 15.64 MiB/s
Receiving objects:  55% (91707/166740), 47.02 MiB | 15.64 MiB/s
Receiving objects:  56% (93375/166740), 47.02 MiB | 15.64 MiB/s
Receiving objects:  57% (95042/166740), 47.02 MiB | 15.64 MiB/s
Receiving objects:  58% (96710/166740), 47.02 MiB | 15.64 MiB/s
Receiving objects:  59% (98377/166740), 47.02 MiB | 15.64 MiB/s
Receiving objects:  60% (100044/166740), 47.02 MiB | 15.64 MiB/s
Receiving objects:  61% (101712/166740), 47.02 MiB | 15.64 MiB/s
Receiving objects:  62% (103379/166740), 47.02 MiB | 15.64 MiB/s
Receiving objects:  63% (105047/166740), 47.02 MiB | 15.64 MiB/s
Receiving objects:  64% (106714/166740), 47.02 MiB | 15.64 MiB/s
Receiving objects:  65% (108381/166740), 47.02 MiB | 15.64 MiB/s
Receiving objects:  66% (110049/166740), 47.02 MiB | 15.64 MiB/s
Receiving objects:  67% (111716/166740), 47.02 MiB | 15.64 MiB/s
Receiving objects:  68% (113384/166740), 47.02 MiB | 15.64 MiB/s
Receiving objects:  69% (115051/166740), 47.02 MiB | 15.64 MiB/s
Receiving objects:  70% (116718/166740), 47.02 MiB | 15.64 MiB/s
Receiving objects:  71% (118386/166740), 47.02 MiB | 15.64 MiB/s
Receiving objects:  72% (120053/166740), 47.02 MiB | 15.64 MiB/s
Receiving objects:  73% (121721/166740), 47.02 MiB | 15.64 MiB/s
Receiving objects:  74% (123388/166740), 47.02 MiB | 15.64 MiB/s
Receiving objects:  75% (125055/166740), 47.02 MiB | 15.64 MiB/s
Receiving objects:  76% (126723/166740), 47.02 MiB | 15.64 MiB/s
Receiving objects:  77% (128390/166740), 47.02 MiB | 15.64 MiB/s
Receiving objects:  78% (130058/166740), 56.26 MiB | 16.04 MiB/s
Receiving objects:  79% (131725/166740), 56.26 MiB | 16.04 MiB/s
Receiving objects:  80% (133392/166740), 56.26 MiB | 16.04 MiB/s
Receiving objects:  81% (135060/166740), 56.26 MiB | 16.04 MiB/s
Receiving objects:  82% (136727/166740), 56.26 MiB | 16.04 MiB/s
Receiving objects:  83% (138395/166740), 56.26 MiB | 16.04 MiB/s
Receiving objects:  84% (140062/166740), 56.26 MiB | 16.04 MiB/s
Receiving objects:  85% (141729/166740), 56.26 MiB | 16.04 MiB/s
Receiving objects:  86% (143397/166740), 56.26 MiB | 16.04 MiB/s
Receiving objects:  87% (145064/166740), 56.26 MiB | 16.04 MiB/s
Receiving objects:  88% (146732/166740), 56.26 MiB | 16.04 MiB/s
Receiving objects:  89% (148399/166740), 56.26 MiB | 16.04 MiB/s
Receiving objects:  90% (150066/166740), 56.26 MiB | 16.04 MiB/s
Receiving objects:  91% (151734/166740), 56.26 MiB | 16.04 MiB/s
Receiving objects:  92% (153401/166740), 56.26 MiB | 16.04 MiB/s
Receiving objects:  93% (155069/166740), 56.26 MiB | 16.04 MiB/s
Receiving objects:  94% (156736/166740), 56.26 MiB | 16.04 MiB/s
Receiving objects:  95% (158403/166740), 56.26 MiB | 16.04 MiB/s
Receiving objects:  96% (160071/166740), 56.26 MiB | 16.04 MiB/s
Receiving objects:  97% (161738/166740), 56.26 MiB | 16.04 MiB/s
Receiving objects:  97% (161804/166740), 56.26 MiB | 16.04 MiB/s
Receiving objects:  98% (163406/166740), 61.48 MiB | 15.34 MiB/s
Receiving objects:  99% (165073/166740), 61.48 MiB | 15.34 MiB/s
remote: Total 166740 (delta 215), reused 0 (delta 0), pack-reused 166248
Receiving objects: 100% (166740/166740), 61.48 MiB | 15.34 MiB/s
Receiving objects: 100% (166740/166740), 63.53 MiB | 15.34 MiB/s, done.

Checking connectivity... done.
Submodule path 'third_party/openssl': checked out '3df69d3aefde7671053d4e3c242b228e5d79c83f'
Cloning into 'third_party/protobuf'...
remote: Counting objects: 20308, done.
Receiving objects:   0% (1/20308)
Receiving objects:   1% (204/20308)
Receiving objects:   2% (407/20308)
Receiving objects:   3% (610/20308)
Receiving objects:   4% (813/20308)
Receiving objects:   5% (1016/20308)
Receiving objects:   6% (1219/20308)
Receiving objects:   7% (1422/20308)
Receiving objects:   8% (1625/20308)
Receiving objects:   9% (1828/20308)
Receiving objects:  10% (2031/20308)
Receiving objects:  11% (2234/20308)
Receiving objects:  12% (2437/20308)
Receiving objects:  13% (2641/20308)
Receiving objects:  14% (2844/20308)
Receiving objects:  15% (3047/20308)
Receiving objects:  16% (3250/20308)
Receiving objects:  17% (3453/20308)
Receiving objects:  18% (3656/20308)
Receiving objects:  19% (3859/20308), 4.05 MiB | 8.07 MiB/s
Receiving objects:  20% (4062/20308), 4.05 MiB | 8.07 MiB/s
Receiving objects:  21% (4265/20308), 4.05 MiB | 8.07 MiB/s
Receiving objects:  22% (4468/20308), 4.05 MiB | 8.07 MiB/s
Receiving objects:  23% (4671/20308), 4.05 MiB | 8.07 MiB/s
Receiving objects:  24% (4874/20308), 4.05 MiB | 8.07 MiB/s
Receiving objects:  25% (5077/20308), 4.05 MiB | 8.07 MiB/s
Receiving objects:  26% (5281/20308), 4.05 MiB | 8.07 MiB/s
Receiving objects:  27% (5484/20308), 4.05 MiB | 8.07 MiB/s
Receiving objects:  28% (5687/20308), 4.05 MiB | 8.07 MiB/s
Receiving objects:  29% (5890/20308), 4.05 MiB | 8.07 MiB/s
Receiving objects:  30% (6093/20308), 4.05 MiB | 8.07 MiB/s
Receiving objects:  31% (6296/20308), 4.05 MiB | 8.07 MiB/s
Receiving objects:  32% (6499/20308), 4.05 MiB | 8.07 MiB/s
Receiving objects:  33% (6702/20308), 4.05 MiB | 8.07 MiB/s
Receiving objects:  34% (6905/20308), 4.05 MiB | 8.07 MiB/s
Receiving objects:  35% (7108/20308), 4.05 MiB | 8.07 MiB/s
Receiving objects:  35% (7292/20308), 8.73 MiB | 8.63 MiB/s
Receiving objects:  36% (7311/20308), 8.73 MiB | 8.63 MiB/s
Receiving objects:  37% (7514/20308), 16.63 MiB | 10.99 MiB/s
Receiving objects:  38% (7718/20308), 16.63 MiB | 10.99 MiB/s
Receiving objects:  39% (7921/20308), 16.63 MiB | 10.99 MiB/s
Receiving objects:  40% (8124/20308), 16.63 MiB | 10.99 MiB/s
Receiving objects:  41% (8327/20308), 16.63 MiB | 10.99 MiB/s
Receiving objects:  42% (8530/20308), 16.63 MiB | 10.99 MiB/s
Receiving objects:  43% (8733/20308), 16.63 MiB | 10.99 MiB/s
Receiving objects:  44% (8936/20308), 16.63 MiB | 10.99 MiB/s
Receiving objects:  45% (9139/20308), 16.63 MiB | 10.99 MiB/s
Receiving objects:  46% (9342/20308), 16.63 MiB | 10.99 MiB/s
Receiving objects:  47% (9545/20308), 16.63 MiB | 10.99 MiB/s
Receiving objects:  48% (9748/20308), 16.63 MiB | 10.99 MiB/s
Receiving objects:  49% (9951/20308), 16.63 MiB | 10.99 MiB/s
Receiving objects:  50% (10154/20308), 16.63 MiB | 10.99 MiB/s
Receiving objects:  51% (10358/20308), 16.63 MiB | 10.99 MiB/s
Receiving objects:  52% (10561/20308), 16.63 MiB | 10.99 MiB/s
Receiving objects:  53% (10764/20308), 16.63 MiB | 10.99 MiB/s
Receiving objects:  54% (10967/20308), 16.63 MiB | 10.99 MiB/s
Receiving objects:  55% (11170/20308), 16.63 MiB | 10.99 MiB/s
Receiving objects:  56% (11373/20308), 16.63 MiB | 10.99 MiB/s
Receiving objects:  57% (11576/20308), 16.63 MiB | 10.99 MiB/s
Receiving objects:  58% (11779/20308), 16.63 MiB | 10.99 MiB/s
Receiving objects:  59% (11982/20308), 16.63 MiB | 10.99 MiB/s
Receiving objects:  60% (12185/20308), 16.63 MiB | 10.99 MiB/s
Receiving objects:  61% (12388/20308), 16.63 MiB | 10.99 MiB/s
Receiving objects:  62% (12591/20308), 16.63 MiB | 10.99 MiB/s
Receiving objects:  63% (12795/20308), 16.63 MiB | 10.99 MiB/s
Receiving objects:  64% (12998/20308), 16.63 MiB | 10.99 MiB/s
Receiving objects:  64% (13157/20308), 16.63 MiB | 10.99 MiB/s
Receiving objects:  65% (13201/20308), 22.92 MiB | 11.37 MiB/s
Receiving objects:  66% (13404/20308), 22.92 MiB | 11.37 MiB/s
Receiving objects:  67% (13607/20308), 22.92 MiB | 11.37 MiB/s
Receiving objects:  68% (13810/20308), 22.92 MiB | 11.37 MiB/s
Receiving objects:  69% (14013/20308), 22.92 MiB | 11.37 MiB/s
Receiving objects:  70% (14216/20308), 22.92 MiB | 11.37 MiB/s
Receiving objects:  71% (14419/20308), 22.92 MiB | 11.37 MiB/s
Receiving objects:  72% (14622/20308), 22.92 MiB | 11.37 MiB/s
Receiving objects:  73% (14825/20308), 22.92 MiB | 11.37 MiB/s
Receiving objects:  74% (15028/20308), 22.92 MiB | 11.37 MiB/s
Receiving objects:  75% (15231/20308), 22.92 MiB | 11.37 MiB/s
Receiving objects:  76% (15435/20308), 22.92 MiB | 11.37 MiB/s
Receiving objects:  77% (15638/20308), 22.92 MiB | 11.37 MiB/s
Receiving objects:  78% (15841/20308), 22.92 MiB | 11.37 MiB/s
Receiving objects:  79% (16044/20308), 22.92 MiB | 11.37 MiB/s
Receiving objects:  80% (16247/20308), 22.92 MiB | 11.37 MiB/s
Receiving objects:  81% (16450/20308), 22.92 MiB | 11.37 MiB/s
Receiving objects:  82% (16653/20308), 22.92 MiB | 11.37 MiB/s
Receiving objects:  83% (16856/20308), 22.92 MiB | 11.37 MiB/s
Receiving objects:  84% (17059/20308), 22.92 MiB | 11.37 MiB/s
Receiving objects:  85% (17262/20308), 22.92 MiB | 11.37 MiB/s
Receiving objects:  86% (17465/20308), 22.92 MiB | 11.37 MiB/s
Receiving objects:  87% (17668/20308), 22.92 MiB | 11.37 MiB/s
Receiving objects:  88% (17872/20308), 22.92 MiB | 11.37 MiB/s
Receiving objects:  89% (18075/20308), 22.92 MiB | 11.37 MiB/s
Receiving objects:  90% (18278/20308), 22.92 MiB | 11.37 MiB/s
Receiving objects:  91% (18481/20308), 22.92 MiB | 11.37 MiB/s
Receiving objects:  92% (18684/20308), 22.92 MiB | 11.37 MiB/s
Receiving objects:  93% (18887/20308), 22.92 MiB | 11.37 MiB/s
Receiving objects:  94% (19090/20308), 22.92 MiB | 11.37 MiB/s
Receiving objects:  95% (19293/20308), 22.92 MiB | 11.37 MiB/s
Receiving objects:  96% (19496/20308), 22.92 MiB | 11.37 MiB/s
Receiving objects:  97% (19699/20308), 22.92 MiB | 11.37 MiB/s
Receiving objects:  98% (19902/20308), 22.92 MiB | 11.37 MiB/s
remote: Total 20308 (delta 0), reused 0 (delta 0), pack-reused 20308
Receiving objects:  99% (20105/20308), 22.92 MiB | 11.37 MiB/s
Receiving objects: 100% (20308/20308), 22.92 MiB | 11.37 MiB/s
Receiving objects: 100% (20308/20308), 26.09 MiB | 11.37 MiB/s, done.

Checking connectivity... done.
Submodule path 'third_party/protobuf': checked out '644a6a1da71385e9d7a7a26b3476c93fdd71788c'
Cloning into 'third_party/zlib'...
remote: Counting objects: 4194, done.

Checking connectivity... done.
Submodule path 'third_party/zlib': checked out '50893291621658f355bc5b4d450a8d06a563053d'
travis_time:end:037e1de8:start=1431395793466554901,finish=1431395813082711274,duration=19616156373
travis_fold:end:git.submodule

Setting environment variables from .travis.yml
$ export RUBY_VERSION=2.1
$ export COVERALLS_PARALLEL=true
$ export CPPFLAGS=-I/tmp/prebuilt/include
$ export NUGET="mono nuget.exe"
$ export USE_GCC=4.4
$ export CONFIG=opt
$ export TEST=build

$ export CXX=g++
$ export CC=gcc
$ g++ --version
g++ (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
travis_fold:start:before_install.1
travis_time:start:0c5d2398
$ sudo add-apt-repository ppa:yjwong/gflags -y
Executing: gpg --ignore-time-conflict --no-options --no-default-keyring --secret-keyring /tmp/tmp.ML76gJkVji --trustdb-name /etc/apt/trustdb.gpg --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg --keyring /etc/apt/trusted.gpg.d//apt.postgresql.org.gpg --keyserver hkp://keyserver.ubuntu.com:80/ --recv C43E6E8C0749A3D89575D9945E91ACA7C851003A
gpg: requesting key C851003A from hkp server keyserver.ubuntu.com
gpg: key C851003A: public key "Launchpad PPA for Wong Yong Jie" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
travis_time:end:0c5d2398:start=1431395813103792103,finish=1431395815545183271,duration=2441391168
travis_fold:end:before_install.1
travis_fold:start:before_install.2
travis_time:start:0acf6e12
$ sudo add-apt-repository ppa:h-rayflood/llvm -y
Executing: gpg --ignore-time-conflict --no-options --no-default-keyring --secret-keyring /tmp/tmp.cHrryeit7Q --trustdb-name /etc/apt/trustdb.gpg --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg --keyring /etc/apt/trusted.gpg.d//apt.postgresql.org.gpg --keyserver hkp://keyserver.ubuntu.com:80/ --recv EF9300D9D55E308863EA191B9DB3C0CF23957A28
gpg: requesting key 23957A28 from hkp server keyserver.ubuntu.com
gpg: key 23957A28: public key "Launchpad PPA for hATrayflood" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
travis_time:end:0acf6e12:start=1431395815554427577,finish=1431395816860141747,duration=1305714170
travis_fold:end:before_install.2
travis_fold:start:before_install.3
travis_time:start:08df68c0
$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF
Executing: gpg --ignore-time-conflict --no-options --no-default-keyring --secret-keyring /tmp/tmp.sqchonL6pr --trustdb-name /etc/apt/trustdb.gpg --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg --keyring /etc/apt/trusted.gpg.d//apt.postgresql.org.gpg --keyserver keyserver.ubuntu.com --recv-keys 3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF
gpg: requesting key D3D831EF from hkp server keyserver.ubuntu.com
gpg: key D3D831EF: public key "Xamarin Public Jenkins (auto-signing<EMAIL_ADDRESS>imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
travis_time:end:08df68c0:start=1431395816869460149,finish=1431395817190678451,duration=321218302
travis_fold:end:before_install.3
travis_fold:start:before_install.4
travis_time:start:2a66d0f5
$ echo "deb http://download.mono-project.com/repo/debian wheezy main" | sudo tee /etc/apt/sources.list.d/mono-xamarin.list
deb http://download.mono-project.com/repo/debian wheezy main
travis_time:end:2a66d0f5:start=1431395817199668469,finish=1431395817217416522,duration=17748053
travis_fold:end:before_install.4
travis_fold:start:before_install.5
travis_time:start:10469166
$ echo "deb http://download.mono-project.com/repo/debian wheezy-libtiff-compat main" | sudo tee -a /etc/apt/sources.list.d/mono-xamarin.list
deb http://download.mono-project.com/repo/debian wheezy-libtiff-compat main
travis_time:end:10469166:start=1431395817226008755,finish=1431395817243344836,duration=17336081
travis_fold:end:before_install.5
travis_fold:start:before_install.6
travis_time:start:070f4ad5
$ sudo apt-get update -qq
E: Could not get lock /var/lib/dpkg/lock - open (11: Resource temporarily unavailable)
E: Unable to lock the administration directory (/var/lib/dpkg/), is another process using it?
travis_time:end:070f4ad5:start=1431395817251816499,finish=1431395823811963634,duration=6560147135

The command "sudo apt-get update -qq" failed and exited with 100 during .
Your build has been stopped.

Yeah well, that one is a travis issue, not something we have any influence whatsoever.


Updates Literal types section.

Update the translation of "hello world" to "hola mundo" in Literal Types

Thanks


Lib not working with DHD devices

Unfortunately this lib is still not working with certain DHD devices, e.g. with all DHD-52 systems!
What can we do to resolve the issues?
Can you please confirm compatibility of this lib with the Ember+ specs and the compatibility especially with DHD devices.
Many Thanks,
Bernd

Hi Bernd,
I'm using this library for connecting to DHD 52 devices, as a consumer, seems to work fine. What are the issues you're having?
Check my pull request for adjustments and adaptation for .NET standard, there is some slight modifications but nothing mayor.
Best regards
Roger

Hi Roger,
I think that I contact Bernd with this Issue.
I'm using the Proppfrexx ember-viewer from Radio42 and it's working with the library:
Lawo.EmberPlusSharp.dll
If I connect to the DHD 52 XC System than I get this message:
The provider failed to send the children for the element with the path /Device/Routing/matrix.
Reconnecting...
It's connecting again and than the same message.
and so on...
I can say in the options: Ignore matrix elements If I do than I get the database of the elements.
But the message:  "please wait it's getting database provider"  is still running in a popup screen.
But if I restarted it than it's okay!
I hope you understand it.
Many Thanks,
Frank

Thanks for all the help.
It is now confirmed, that it is working!
There are two important things to notice with DHD:

Disable (Ignore) any Matrix elements (this is even the default and therefore hidden in the ProppFrexx GPIO Ember+ implementation)
Take care about globalnames in DHD configuration and use simple ones (e.g. no space or special char)

@radio42 Good to hear this.
Is the Lawo.EmberPlusSharp.Model.EmberOption.IgnoreMatrices extention you added in your application no longer needed ignoring Matrix-elements? (Especially with DHD series 52 providers..)

Not that I know of, but I am not a DHD Series 52 owner, so I can not test this.
Last time I heard from Lawo, that DHD is sending matirx values in a different format, which is not fully compliant - whereas DHD said it is according to the specs. So unless either DHD or Lawo moves, I am afraid, that this is still the case.


Apply texture transform for v0.27.x

I'm going to leave this one unmerged for now, because the Unity metadata work is nearly done and then we shouldn't need it anymore.

I'm going to close this now that https://github.com/CesiumGS/cesium-unity/pull/389 is merged!


Cool mod please make compatible with sinytra connector

please make 1.20.1 better compatible, the zombies with babies that stack cause the game to stop working, the game basically just freezes.
This mod is really really cool please make it compatible for forge users.

Hi, I will try to make it compatible in the next release, I will keep you updated when it's tested and functional

Thanks so much!


Question: Crashes in Tkhtml30.dylib on Mac (Intel)

Hi. I'm seeing frequent crashes when loading files in the Htmlframe on Mac (Intel, OSX 10.15.7) without any specific pattern. 90% of the error messages say
Assertion failed: (pV), function nodeGetMargins, file ../src/htmllayout.c, line 314
The code in question is
HtmlComputedValues *pV = HtmlNodeComputedValues(pNode);
assert(pV);

This happens with the latest tkinterweb as well as 3.19.2
Does this ring any bells?
Thanks.

I think I've solved it, or rather you did, since I found the solution in one of your other posts. Adding the following did the trick:
html_frame.set_maximum_thread_count(0)


'lookup failed: 'request.host'' in istio-telemetry with Istio 1.1.1

Describe the bug
I upgrade istio from 1.1.0 into 1.1.1. After I installed istio 1.1.1 and refresh all the pods with sidecar proxy. I apply follwoing Metric which works well in istio 1.1.0 and 1.0.6. And I found that the following Metric didn't work well and there are lots of logs in istio-telemetry showed

2019-03-28T05:11:08.973358Z	warn	input set condition evaluation error: id='4', error='lookup failed: 'request.host''

#  instance
apiVersion: "config.istio.io/v1alpha2"
kind: metric
metadata:
  name: qunherequest
spec:
  value: "1"
  dimensions:
    host: request.host | "unknown"
    qunheCode: response.headers["x-qunhe-code"] | "unknown"
    requestPath: request.url_path | "unknown"
    requestMethod: request.method | "unknown"
    responseCode: response.code | 0
    destinationName: destination.service.name | "unknown"
    destinationType: destination.labels["type"] | "unknown"
    # destinationNamespace: destination.service.namespace | "unknown"
  monitored_resource_type: '"UNSPECIFIED"'
---
# prometheus handler
apiVersion: "config.istio.io/v1alpha2"
kind: prometheus
metadata:
  name: qunherequesthandler
spec:
  metrics:
  - name: qunhe_request_total # Prometheus
    instance_name: qunherequest.metric.istio-system # Mixer Instance
    kind: COUNTER
    label_names:
    - host
    - qunheCode
    - requestPath
    - requestMethod
    - responseCode
    - destinationName
    - destinationType
---
#
apiVersion: "config.istio.io/v1alpha2"
kind: rule
metadata:
  name: qunherequestrule
spec:
  match: match(request.host,"*.coohom.com") == true && match(request.url_path,"/gateway/*") == false
  actions:
  - handler: qunherequesthandler.prometheus.istio-system
    instances:
    - qunherequest.metric.istio-system

Steps to reproduce the bug
Install Istio 1.1.1 , and apply the Metric
Version
Kubernetes 1.13.1 , Istio 1.1.1
Installation
Istio installed by  helm install

similar error with Istio 1.1.1:
2019-03-29T03:23:08.488849Z     error   error creating instance: destination='tracespan:handler.zipkin.istio-system(zipkin)', error='evaluation failed at [default.tracespan.istio-system]'StartTime': 'lookup failed: 'request.time'''
Version
Kubernetes v1.10.10 , Istio 1.1.1
Installation
Istio installed by helm install
apiVersion: "config.istio.io/v1alpha2"
kind: tracespan
metadata:
  name: default
  namespace: istio-system
spec:
  traceId: request.headers["x-b3-traceid"] | ""
  spanId: request.headers["x-b3-spanid"] | ""
  parentSpanId: request.headers["x-b3-parentspanid"] | ""
  spanName: request.path | "/"
  startTime: request.time
  endTime: response.time
  httpStatusCode: response.code | 0
  sourceName: source.workload.name | ""
  sourceIp: source.ip | ip("<IP_ADDRESS>")
  destinationName: destination.workload.name | ""
  destinationIp: destination.ip | ip("<IP_ADDRESS>")
  requestSize: request.size | 0
  requestTotalSize: request.total_size | 0
  responseSize: response.size | 0
  responseTotalSize: response.total_size | 0
  apiProtocol: api.protocol | ""
  rewriteClientSpanId: "false"
  spanTags:
    http.host: request.host | ""
    http.method: request.method | ""
    http.path: request.path | ""
    http.user_agent: request.useragent | ""
    principal: request.auth.principal | "unknown"
    source.version: source.labels["version"] | "unknown"
    destination.version: destination.labels["version"] | "unknown"
---
apiVersion: "config.istio.io/v1alpha2"
kind: zipkin
metadata:
  name: handler
  namespace: istio-system
spec:
  url: "http://zipkin.istio-system:9411/api/v1/spans"
  sampleProbability: 1.0
---
apiVersion: "config.istio.io/v1alpha2"
kind: rule
metadata:
  name: zipkin
  namespace: istio-system
spec:
  match: "true" # If omitted match is true.
  actions:
  - handler: handler.zipkin
    instances:
    - default.tracespan.istio-system
---

Is it possible that you are matching on what is considered TCP traffic?  Your match rules will fire for all traffic. My suspicion is that something is different regarding your config and the mapping to protocols.

Is it possible that you are matching on what is considered TCP traffic? Your match rules will fire for all traffic. My suspicion is that something is different regarding your config and the mapping to protocols.

Thanks douglas! Yes, after changed the match expression to 'context.protocol == "http" || context.protocol == "grpc"', it worked!
But now i encountered a new problem, when use the mixer-based tracing, I can't see the ingressgateway and mixer span in the trace, but envoy-based tracing works fine.  Is the match expression incorrect?  Is there any info about that?


Fix heading links and add missing word for grammar

I think the grammar change is necessary, though I'm not a native speaker. GitHub (and some other Markdown implementations) require a space before the heading title. It is possible to see in the rendered web page that currently the headings are displayed as simple paragraphs.
Hope this helps.
Purpose of PR:
Please give a short description of what this PR is for.
Important ToDos
Please mark each with an "x"

[ ] A JIRA ticket exists (if not, please create this first)[https://issues.apache.org/jira/browse/ZEPPELIN/]
[ ] Title of PR is "MAHOUT-XXXX Brief Description of Changes" where XXXX is the JIRA number.
[ ] Created unit tests where appropriate
[ ] Added licenses correct on newly added files
[ ] Assigned JIRA to self
[ ] Added documentation in scala docs/java docs, and to website
[ ] Successfully built and ran all unit tests, verified that all tests pass locally.

If all of these things aren't complete, but you still feel it is
appropriate to open a PR, please add [WIP] after MAHOUT-XXXX before the
descriptions- e.g. "MAHOUT-XXXX [WIP] Description of Change"
Does this change break earlier versions?
Is this the beginning of a larger project for which a feature branch should be made?

hey @kinow thanks for the contribution!
you're right, the old site had different standard than jekyll this issue persists throughout.
We (like every project) always need help with docs, and a couple of tips for future PRs (that I hope you make :) )

Website spelling/grammar/markdown fixes don't need a JIRA, however it is helpful if you instead start the title of the PR with WEBSITE -  e.g. WEBSITE - Fix heading links and add missing word for grammar
In general- we'll hopefully be updating the website soon so that website/oldsite won't be in use.  Would be better to focus energies on website/front or website/docs.  Those are the 'live versions' (even though "old site" is still the defacto for a lot of the front.
We haven't automated the website build process just yet, so it may take a few days for your changes to be reflected.

Thanks again!

Not a problem @rawkintrevo Notes taken, will pay attention when contributing again in the future :-)


[CLOSED] Remove document controller subclasses

 Issue by bestie
Friday 10 October 2014 at 15:52 GMT
Originally opened as https://github.com/alphagov/specialist-publisher/pull/279

bestie included the following code: https://github.com/alphagov/specialist-publisher/pull/279/commits

 Comment by kalleth
Wednesday 15 October 2014 at 10:43 GMT

I'm not sure why the require_relative is needed here - modifying it to require 'specialist_publisher' works fine in development and in the test suite. I've added that as a separate commit.

 Comment by kalleth
Wednesday 15 October 2014 at 10:49 GMT

@Themitchell I've addressed your comments above in 604eb1f and fc253c2. I'm happy with this PR other than my two commits -- can you hit merge if you feel the same? :)

 Comment by Themitchell
Thursday 16 October 2014 at 13:51 GMT

:+1:


Fix S3.rename didn't correctly remove the old file

In the current pfio, S3.rename just copies the content into a new file, not removing the original one.
Fixing rename
>>> with pfio.v2.from_url('s3://suzuo/writer/test') as fs:
...     with fs.open('foo.dat', 'wb') as f:
...         f.write(b'hello world')
...
...     print('ls before', list(fs.list()))
...     fs.rename('foo.dat', 'bar.dat')
...     print('ls after', list(fs.list()))

ls before ['foo.dat']
ls after ['bar.dat', 'foo.dat']

This is because that rename calls remove to delete the source object with the key normalized, which is then normalized again inside the remove. So remove tries to remove the specified key that does not exist instead of the original source one that we actually need to delete.
https://github.com/pfnet/pfio/blob/2.0.1/pfio/v2/s3.py#L523
This PR fixes the unnecessary normalization when calling remove in rename.
Fixing remove
One of the reasons why the incorrect rename behavior is missed would be because remove didn't raise anything even if the specified target doesn't actually exist.
This S3 behavior is inconsistent to other filesystems.
Since it seems to be a constraint comes from boto3 or perhaps S3 itself, I added an explicit existence check.
Test refactoring
In addition, since S3 test cases it getting increased, I DRYed fixtures to make each test case a little simpler.
The following conventional test case
@mock_s3
def test_foo():
    bucket = "test-dummy-bucket"
    key = "it's me!deadbeef"
    secret = "asedf;lkjdf;a'lksjd"
    with S3(bucket, create_bucket=True):
        with from_url('s3://test-dummy-bucket/',
                      aws_access_key_id=key,
                      aws_secret_access_key=secret) as s3:
            ...
        with open_url('s3://test-dummy-bucket/xxxx', 'rb'
                      aws_access_key_id=key,
                      aws_secret_access_key=secret) as f:
            ...

can be equivalently rewritten as:
def test_foo(s3_fixture):
    with from_url('s3://test-dummy-bucket/', **s3_fixture.aws_kwargs) as s3:
        ...
    with open_url('s3://test-dummy-bucket/xxxx', 'rb', **s2_fixture.aws_kwargs) as f:
        ...

/test

/test

/test

/test


Make sure form messages are showing for all superforms

Superform allows for a message store to make it easy to give feedback to users. Make sure it's working on all forms, including member edits aka preventing submission until the form passes muster

superform messages should be unified as a toast to display to users


Add UI for incorrect credentials?

Currently there is logging for incorrect credentials, but there is no way to see in the interface that the credentials have been saved, updated, are incorrect, or are already saved and won't be replaced since they are the same.

I keep getting "already configured" when trying to update my credentials

I keep getting "already configured" when trying to update my credentials

Hmmmm ok so the logging is just simply not very clear, rather than the application being wrong, since I tried to clear my credentials and save and when I checked the config.json in application support, the credentials were cleared.

Hmmmm ok so the logging is just simply not very clear, rather than the application being wrong, since I tried to clear my credentials and save and when I checked the config.json in application support, the credentials were cleared.

So I think the strategy here would be to try to connect in the config dialog itself, and show the error there. What is problematic in the current codebase is "restarting" already running session with different credentials, and that's what these "already configured" errors mean. It should work if you restart the app, although I agree it's not ideal.

So I think the strategy here would be to try to connect in the config dialog itself, and show the error there. What is problematic in the current codebase is "restarting" already running session with different credentials, and that's what these "already configured" errors mean. It should work if you restart the app, although I agree it's not ideal.

+1 for this change welcomed. The good thing is, pssst compiles and runs well on Ubuntu 20.04, now only if I would have a Spotify account ;) Tried it since this is good example for a rust app with Druid GUI.

+1 for this change welcomed. The good thing is, pssst compiles and runs well on Ubuntu 20.04, now only if I would have a Spotify account ;) Tried it since this is good example for a rust app with Druid GUI.

I think it would also be useful to include a string representation of the error. AuthFailed { 11 } is the error I got, but it took digging through keyexchange.proto to find that this meant "Premium account required".

Credential dialog is a bit nicer now, closing. Feel free to open issues in case of any problems!


[zh] Remove BoundServiceAccountTokenVolume from service-account-admin page

The line is useless, maybe caused by heritage.

/retitle [zh] Remove BoundServiceAccountTokenVolume from service-account-admin page
/assign @tengqm

Thanks for catch!
/lgtm

/approve


adjust implementation of Database trait from revm in helios to not block the executor

Updated revm to v3 in helios in https://github.com/eigerco/helios/pull/3 as a first step


WIP: Host summary

We should have this include the host info (memory, cpu, storage, cloud) from @cloudnautique too.


Cargo doesn't respect dependency renaming when using --package flag for running examples

Problem
I have a workspace with dependences. One of my member crates has the same name as a dependency, so I rename the dependency using
b = { version = "x.x.x", package = "a" }

My version of the a crate has examples, but those examples clash in name with another crate.
Given this, I try to run the example from my a crate using
cargo run --example example_name --package a

but Cargo gives an error like the following
error: There are multiple `a` packages in your project, and the specification `a` is ambiguous.
Please re-run this command with one of the following specifications:
<EMAIL_ADDRESS>  <- this is my version
<EMAIL_ADDRESS>  <- this is the dependency

I would expect Cargo to respect my renaming if I try to use the --package flag when running examples, but it does not.
Steps
No response
Possible Solution(s)
No response
Notes
No response
Version
cargo 1.76.0 (c84b36747 2024-01-18)
release: 1.76.0
commit-hash: c84b367471a2db61d2c2c6aab605b14130b8a31b
commit-date: 2024-01-18
host: aarch64-unknown-linux-gnu
libgit2: 1.7.1 (sys:0.18.1 vendored)
libcurl: 8.5.0-DEV (sys:0.4.70+curl-8.5.0 vendored ssl:OpenSSL/1.1.1w)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Ubuntu 22.4.0 [64-bit]

Thanks for the report. One thing worth pointing out that -p/--package accepts a Package ID Spec, which is used as a unique identifier. The spec needs to be unique across different kinds of sources like crates.io index, private registries, git dependencies and local path dependencies. It doesn't record any renames as renames are not necessary to uniquely identify a package. For simplicity reasons, I personally don't think the spec will evolve to record that bit of information.
That being said, you're not wrong. If I recall correctly, cargo run doesn't support running a binary from arbitrary dependency in the dependency graph. Only workspace members can be specified by -p for cargo run. It looks like a bug! Do you mind providing a minimal reproducible example so that we can investigate?

I am going to close due to lack of a minimal set of steps to reproduce, and it has been inactive for a while. Here are tips about how to create a minimal, complete, and verifiable example.
Feel free to comment below or open a new issue if there is any update.


Stripping release artifacts

An issue was raised upon looking at the PL/Rust Debian package file sizes as a result of the release process -- the file sizes looked fairly big.
The question becomes:  Should we strip anything in release mode for PL/Rust? If so, what should be stripped and how should it be stripped?
One suggestion was to update the profile for the PL/Rust project, as in: https://doc.rust-lang.org/cargo/reference/profiles.html#strip
Another suggestion was to potentially strip the user-created functions, but there was concerned this could break dynamic loading.

This is done now.


Remove enterprise-edge extension

This checklist is used to make sure that common guidelines for a pull request are followed.

For new extensions:

[ ] My extension description/summary conforms to the Extension Summary Guidelines.

About Extension Publish
There is a pipeline to automatically build, upload and publish extension wheels.
Once your pull request is merged into main branch, a new pull request will be created to update src/index.json automatically.
The precondition is to put your code inside this repository and upgrade the version in the pull request but do not modify src/index.json.

@yonzhan we've already moved all of these commands to the core CLI  and would like to prevent future customers from installing the enterprise-edge extension. I'm assuming that we can do that by removing the source from this repo and removing enterprise-edge entry from the index.json. Is that correct?

@kairu-ms @jsntcy for awareness

@StrawnSC Yes, the source code can be removed directly.
But if the az extension add -n enterprise-edge command is used in some users' scripts to install this extension, remove index.json may cause breaking change to them, so it is recommended to remove index.json during the breaking change window of CLI (Build Event and Ignite Event)
For more details about CLI breaking change process, please refer to this doc breakingchange_release_process.md

@zhoxing-ms are we good to merge + release this?


Healthcare ASEAN link is not working

Was purposefully broken for demo, but fixed by @daphnecys  :D haha thank you! Nvm I should get a better example anyway

Oh actually I re-broke it when I merged my changes


[Bug] Initial Loss Value Unavailable in TensorBoard Logs

Related to Issue #444 :

Fixing tensorboard logs to always include the loss/metrics values at iteration 0 (evaluating models before training) and fix inconsistencies wrt iteration numbers when logging training and validation values.
Avoiding logging math.nan in tensorboard for the training loss.

Closes issue #444.


Support for file projection in run command

Overview
This PR adds support for projecting configuration properties as temporary files, based on a new well-known block called files. For each property, a temporary file is created containing the property value, and an environment variable is set pointing to the temporary file. Note that the file contents may be dynamically generated using interpolation.
Example
This feature is designed for a key scenario of projecting a kubeconfig file based on a Pulumi environment. Here's how that would work:
Define an environment:
# import an environment that provides AWS credentials (`AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`).
imports:
  - dev-sandbox

# define a kubeconfig file.
values:
  files:
    KUBECONFIG: |
      apiVersion: v1
      clusters:
      - cluster:
          certificate-authority-data: LS0tLS1...
          server: https://....gr7.us-west-2.eks.amazonaws.com
        name: arn:aws:eks:us-west-2:616138583583:cluster/mycluster
      contexts:
      - context:
          cluster: arn:aws:eks:us-west-2:616138583583:cluster/mycluster
          user: arn:aws:eks:us-west-2:616138583583:cluster/mycluster
        name: arn:aws:eks:us-west-2:616138583583:cluster/mycluster
      current-context: arn:aws:eks:us-west-2:616138583583:cluster/mycluster
      kind: Config
      preferences: {}
      users:
      - name: arn:aws:eks:us-west-2:616138583583:cluster/mycluster
        user:
          exec:
            apiVersion: client.authentication.k8s.io/v1beta1
            args:
            - --region
            - us-west-2
            - eks
            - get-token
            - --cluster-name
            - mycluster
            - --output
            - json
            command: aws

Run the environment and observe there's a KUBECONFIG environment variable that points to a temporary file containing the desired configuration:
$ esc run -i eron-kubernetes-test -- sh -c 'cat $KUBECONFIG'
apiVersion: v1
clusters:
- cluster:
...

This enables:
$ esc run -i eron-kubernetes-test -- kubectl get ns
NAME              STATUS   AGE
default           Active   46d
kube-node-lease   Active   46d
kube-public       Active   46d
kube-system       Active   46d

What are the semantics of files for consumption by tools other than esc run where there is not an "end time" for cleanup?  Or is this block something that only matters for esc run?
I feel like perhaps we want to approach this in a way that doesn't require a new top level special key?  Is there any option for that?  Where we could somehow have the consumer (esc run in this case) be explicit about the keys it wants to map?  Like esc run myenv --file kubeconfig:KUBECONFIG -- kubectl get ns?

The lack of an "end time" is why I focused on run. I'm new to the project but I get the sense that various commands operate over well-known subsets. For example, esc open -f dotenv works exclusively with environmentVariables. Special keys seem foundational in Pulumi ESC and not to be feared.

Special keys seem foundational in Pulumi ESC and not to be feared.

I agree with this, FWIW.
I'll take a look at this PR today or tomorrow. I have a feeling that I'm going to need to give it some bake time.
One aside--I suspect is that it will be a best practice to define things like the contents of the kubeconfig in a "normal" value, then reference that from projections. Maybe I'm wrong about that but it smells promising to me, as the definition can then be shared around various projections as necessary. In this case that might mean defining the kubeconfig itself directly under values, then projecting it as a file by referencing it like
  files:
    KUBECONFIG: ${kubeconfig}

Do we want to stick with files as the section name, or should we be explicit about the fact that they're ephemeral? Something like ephemeralFiles, perhaps? We discussed that there may be other use cases for files that persist.

Do we want to stick with files as the section name, or should we be explicit about the fact that they're ephemeral? Something like ephemeralFiles, perhaps? We discussed that there may be other use cases for files that persist.

Personally I'm good with files. If we were to change the name I'd suggest tempFiles.


Web Socket - Docker not working

Have tried on both linux and windows. Using docker and the install

docker run -i -t --rm -v <PROJECTS_FOLDER>:/app/data/projects:rw -p 9001:9001 scrapinghub/portia

If I type in localhost:9001 all I get is 502 Bad Gateway
If I type in http://localhost:9001/static I can create a project but when I try and build a scraper I just get web socket errors and cant do anything

WebSocket connection to 'ws://localhost:9001/ws' failed: Error during WebSocket handshake: Unexpected response code: 502
What is going on here?

Me too!
Docker not working

I have the same problem like @zanjs - could you solve it?

@tholu  I'm sorry!
I can not do anything.

Can you try it now? One of the libraries Portia depends on dropped python 2 support so I've pinned to the older version of the library instead

Works now for me, did this:
docker pull scrapinghub/portia:latest
docker run -i -t --rm -v projects:/app/data/projects:rw -p 9001:9001 scrapinghub/portia

still same problem


Fix for >u64 slots in Pointer addresses

Pointer addresses with slots that don't fit in uint (u64) have been
found on testnet. To facilitate parsing these this updates Pointer to
use bigints and updates the variable nat encoding/decoding functions to
handle larger sizes.

Tx hash on testnet for anybody who is looking into this in the future: 95a5ef2f1121a197fc9bedb039787eb723e98825b4fd4df86c17ec0e3f4dc722


Multiple Private Folder Support

This pull request implements support for multiple private folders (and public if in interactive mode), allowing to sync directories in bulk. Interactive mode also allows to select different configs for each private directory using the allDifferent boolean, which can be set during syncing with interactive enabled.

Looks great, I'll do some tests locally later when I have the time but looking at the code everything looks good, thank you for contributing
I also just noticed I accidentally forgot to uncomment some of my interactive questions but Ill do it after the merge.

I decided to do some tests right now instead of later and it works really well, good job!


Improve topology view pod --> service --> pod traffic

Today show in the topoplogy view::
A ---------> B
!
!----------> S
So that customers are not aware that there is no direct traffic from A --> B and instead the traffic is actually thru S. We need to make it clear that A -->B is not direct traffic. This can be done by using https://github.com/netobserv/flowlogs-pipeline/issues/214 configuration into L2 and changing the edges in the visualization (for example lighter gray, or dotted ... ).
Note: This might be a temporal solution until we will be able to identify the traffic as starting in the S node and not in A.

^^^ @amorenoz FYI

@jpinsonneau I believe that we had good conversation on that area but we are a bit stuck :-(  maybe we need a session dedicated to this issue ... show how this looks in the UI and discuss what we should do??

Do we need https://github.com/netobserv/flowlogs-pipeline/issues/214 first ?
Else yes we can find a time slot to discuss about this subject :+1:

@jpinsonneau I am not sure that https://github.com/netobserv/flowlogs-pipeline/issues/214 will solve this. I thought it might help but we never ended the test. the last statement from @amorenoz was that it might be that what I saw in my environment was due to some other things and not based on changes to the MAC address by OVS/N but maybe even if this is correct it does make sense to think on this area over a meeting.


Add BPCA to contrast algo's?

https://www.myndex.com/BPCA/
"The Bridge PCA tool corrects some of the worst failings of the WCAG 2 math and methods, such as calculating contrast for "Dark Mode". "

I see the BPCA tool is "forked from https://github.com/LeaVerou/contrast-ratio".
Looking for the actual normative definition of the math.

This looks like it

Hi Chris @svgeesus and Adam @argyleink
Bridge PCA has an added scaling over part of the range to fail the same colors that WCAG 2 incorrectly fails, but importantly, fails many color pairs that WCAG 2 incorrectly passes. As such, it is stricter that WCAG 2 but also a bit less flexible than APCA. The flexibility is given up in order to be backwards compatible to WCAG 2.
It has its own repo:
https://github.com/Myndex/bridge-pca
The function BPCAcontrast(txtY,bgY) works just like APCA, returning a polarity sensitive value (-108 to +106)
The function bridgeRatio(Lc,txtY,bgY) takes the BPCA Lc value, and converts it to a WCAG 2 style ratio, and as such is a "drop in replacement" for WCAG 2 math, usable with the WCAG 2 contrast SCs.
Please let me know if you have any questions here...

Which one should we report as being BPCA, I assume the one scaled to WCAG2 values?

Hi Chris @svgeesus

Which one should we report as being BPCA, I assume the one scaled to WCAG2 values?

Okay, so on the BPCA tool, there are two outputs. One, an Lc value, and the other, a ratio.
They are both scaled in such a way that backwards compatibility to WCAG 2 is maintained.
But, the Lc value is for use with the "BPCA enhanced" guidelines, and the ratio is intended as a "drop in replacement" for the WCAG 2 SCs such as 1.4.3 and so on.
Side Note:
BridgePCA was developed only to address some aspersions from a small group of trolls. It maintains backwards compatibility at the loss of some useful flexibility. It's a way to "force fit" WCAG_2 guidelines into something less harmful, but because WCAG_2 ignores spatial frequency as a primary driver of contrast, Bridge PCA is restricted from relaxing contrast on low-spatial frequency elements, which is specifically needed yet missing in WCAG 2.
For instance, WCAG_2 SC 1.4.11 is not supported by actual science, only some self-referential cites that arguably have no place in a standards document. 1.4.11 makes some logical leaps and ignores the primary drivers of contrast perception.

Just making a note of some soon to release changes:

BPCA is going to become non-polar.

WCAG 2.x is not polarity aware, and so BridgePCA as a drop in  replacement should not be either.
Switching to non-polar mode (essentially light mode only) actually eliminates most of the backwards compatibility issues in a natural way.
The one issue with non-polar mode is that negates the maximum contrast guideline, which only applies to negative screen contrast (Lc -90).


Set up proxies to be used by tests to ensure client libraries can connect through...proxies...

#175 tracks the requirement for client libraries to be able to connect through proxies. Just as it is a common requirement to support it, it is also a common requirement to verify said support. Having proxies that are set up to use auth (digest and basic) would presumably be needed for this.

FYI: @bterlson, @mssfang

One idea I had:

Run HTTP proxy in a docker container.
Run tests in docker container with no outbound internet and only access to proxy container.
Run tests, verify access through proxy works and direct access fails.

@JimSuplizio, pretty sure this very old issue is covered by the work you're planning to do with recordings.  Feel free to reword/fix/close this issue as you see fit and as it aligns with the recording epic you're working on.

I will transfer this issue to sdk-tools and apply label to it. Test-proxy definitely supports this scenario if the policies on client side are set up properly.
The way it should work is

Request with original URI.
core package detects presence of HTTP_PROXY environment variable and updates target URI/headers.
Test-proxy policy applies last and updates the already updated target URI/headers to route to test proxy.
Test-proxy makes request to the proxy server, records result as normal.


can't be render use relay

styled-components is a great practice for write css-in-js and also popular,  unfortunately, it's seems that there is little problem when use it with relay
// home.js
...
export const Home = styled.div`
  background-color: rgba(0,0,0,.04);
`

// app.js
import { Home } from 'path/to/home'
...

class App extends React.Component {
  render(){
    return <QueryRenderer
    environment={AppEnvironment}
    query={appQuery}
    variables={{}}
    render={({ error, props }) => {
      if (error) {
        return
Error!
;
      }
      if (!props) {
        return
Loading...
;
      }
      return <Home>Home page</Home>
      // this will be work
      // return
Home page

    }}
  />
  }
}
ReactDOM.render(createElement(App), document.getElementById('app'))

the page is render nothing and throw this warnning
Warning: Functions are not valid as a React child. This may happen if you return a Component instead of <Component /> from render. Or maybe you meant to call this function rather than return it.
    in templateFunction (at index.jsx:40)
    in ReactRelayQueryRenderer (at index.jsx:28)
    in App

Any suggestions on this?

thank you so much for reply, there is a very simple test to it, try this example

If you remove the additional function after export default it will work. So your code should look like export default styled.div.

Here is a working example: https://codesandbox.io/s/x3143rqpjp


Nightly used when 2021 edition is specified no matter what channel

for example:
?eval channel=stable
#![feature(iter_zip)]

gives
error[E0554]: `#![feature]` may not be used on the stable release channel
 --> src/main.rs:1:1
  |
1 | #![feature(iter_zip)]
  | ^^^^^^^^^^^^^^^^^^^^^

For more information about this error, try `rustc --explain E0554`.

but
?eval channel=stable edition=2021
#![feature(iter_zip)]

gives:
()

The Rust community server is running an old version from a time where 2021 edition was only available on nightly:
https://github.com/kangalioo/rustbot/blob/fc09bafa87a6356f35a7974c0db073e9b71ff318/src/playground/play_eval.rs#L25-L30
This code was since removed by #22, when 2021 edition reached stable (relevant part of commit).


Voice public change language functionality

add flow and functionality to change language preferences

@gsvr plz review

:+1:


terraform-providers.packet: v2.9.0 -> v3.2.0

Motivation for this change
Things done

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

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

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

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

3 packages built:

terraform-full
terraform-providers.packet
terraform_0_11-full

Result of nixpkgs-review pr 105790 run on x86_64-darwin 1

2 packages marked as broken and skipped:

terraform-full
terraform_0_11-full

1 package built:

terraform-providers.packet


no png file found for pinout

the link doesn't point to anything, is there a pinout available? Super useful guide otherwise - reminded me to update my boards

Thank you for bringing this to our attention! I've resolved the issue, and the link should now point to the correct resource. A pinout is available, and I've updated the guide accordingly. I'm glad you found the guide useful, and I appreciate your reminder to update your boards.
If you have any other questions or feedback, feel free to reach out!


/keybase: No such file or directory

I installed keybase on Mac OS from the installer on your website. I then added the mac as a new device. According to keybase status KBFS is running (version 1.0.2-20171122003301+247bbfc6).
However, it is not accessible from the terminal, as your documentation suggests it should be:
cd /keybase
-bash: cd: /keybase: No such file or directory

cd /keybase/private
-bash: cd: /keybase/private: No such file or directory

cd /keybase/public
-bash: cd: /keybase/public: No such file or directory

@fladd: check the Folders tab of the Keybase GUI.  There might be a link for installing the kernel extension, which is required for file system access now.  Recent macOS changes forced us to not install the kext by default, so now you have to do it afterwards.

@strib Indeed, that was the case. Might be a good idea to add this to the installation instructions.


New package: bootandy.dust version 0.8.4

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?

[x] Does your manifest conform to the 1.4 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Note: dependency issue.
Microsoft Reviewers: Open in CodeFlow

Hi @kimwonj77,
The package installs normally, but requires Microsoft.VCRedist.2015+.x64 (or x86) to run:

/AzurePipelines run

Closing as of #109460


Histogram renders incorrectly if the data is entirely zeroes and ones

This might actually be a more general issue of calculating the domain, but I'll leave the problem statement more specific for now.
Here's a sandbox: https://codesandbox.io/s/3rqvwxo42p
Two issues:

The second bin (the one containing all the ones) is missing entirely.
The density for the first bin is calculated incorrectly, as can be seen in the height of the bar and the value in the tooltip.

Hey @kaiyoma, thanks for raising this issue.
This is definitely a bug, and related to #100. Will have a fix out shortly. Basically I was trimming the last bin for numeric unbinned data, which led to both errors you're seeing.

Fixed by #119

should be fixed in<EMAIL_ADDRESS>


Missing metrics in the documentation

Hey all,
Is it normal that the documentation is missing a couple of metrics that's actually being exported ?
For example, the following metrics:

elasticsearch_node_stats_json_parse_failures
elasticsearch_node_stats_total_scrapes
elasticsearch_node_stats_up

elasticsearch_nodes_roles

elasticsearch_cluster_health_json_parse_failures
elasticsearch_cluster_health_total_scrapes
elasticsearch_cluster_health_up

Besides the metrics elasticsearch_nodes_roles, these look like what would be a standard implementation of prometheus metrics, which could explain why they're not documented.
Thanks !

when this issue going to fix? i have lot of problems to troubleshoot.