incorrect evaluation results visualized for CenterPose

Hello
I trained TAO CenterPose using the centerpose.ipynb notebook. However, the evaluation results seems weird and not correct.
Could you please provide or update the notebook with the results of your evaluation?
I am not sure how this could be fixed or what has caused it?

Epoch 39: 100%|█| 127/127 [01:29<00:00,  1.43it/s, loss=17.2, v_num=0, train_losTraining loop in progress
`Trainer.fit` stopped: `max_epochs=40` reached.
Epoch 39: 100%|█| 127/127 [01:29<00:00,  1.42it/s, loss=17.2, v_num=0, train_los
Training loop complete.
Training finished successfully
Telemetry data couldn't be sent, but the command ran successfully.
[Error]: module 'urllib3.exceptions' has no attribute 'SubjectAltNameWarning'
Execution status: PASS
2024-02-29 16:03:21,618 [TAO Toolkit] [INFO] nvidia_tao_cli.components.docker_handler.docker_handler 363: Stopping container.

This is what I got for evaluation
2024-02-29 16:08:41,839 [TAO Toolkit] [INFO] root 160: Registry: ['nvcr.io']
2024-02-29 16:08:41,880 [TAO Toolkit] [INFO] nvidia_tao_cli.components.instance_handler.local_instance 360: Running command in container: nvcr.io/nvidia/tao/tao-toolkit:5.2.0-pyt2.1.0
2024-02-29 16:08:41,897 [TAO Toolkit] [INFO] nvidia_tao_cli.components.docker_handler.docker_handler 301: Printing tty value True
There was a problem when trying to write in your cache folder (/.cache/huggingface/hub). You should set the environment variable TRANSFORMERS_CACHE to a writable directory.
There was a problem when trying to write in your cache folder (/.cache/huggingface/hub). You should set the environment variable TRANSFORMERS_CACHE to a writable directory.
sys:1: UserWarning:
'evaluate.yaml' is validated against ConfigStore schema with the same name.
This behavior is deprecated in Hydra 1.1 and will be removed in Hydra 1.2.
See https://hydra.cc/docs/next/upgrades/1.0_to_1.1/automatic_schema_matching for migration instructions.
<frozen core.hydra.hydra_runner>:-1: UserWarning:
'evaluate.yaml' is validated against ConfigStore schema with the same name.
This behavior is deprecated in Hydra 1.1 and will be removed in Hydra 1.2.
See https://hydra.cc/docs/next/upgrades/1.0_to_1.1/automatic_schema_matching for migration instructions.
/usr/local/lib/python3.10/dist-packages/hydra/_internal/hydra.py:119: UserWarning: Future Hydra versions will no longer change working directory at job runtime by default.
See https://hydra.cc/docs/next/upgrades/1.1_to_1.2/changes_to_job_working_dir/ for more information.
  ret = run_job(
Evaluate results will be saved at: /results
Starting CenterPose evaluation
Initializing test cereal_box data.
Loaded test 185 samples
No pretrained configuration specified for convnext_base_in22k model. Using a default. Please add a config to the model pretrained_cfg registry or pass explicitly.
GPU available: True (cuda), used: True
TPU available: False, using: 0 TPU cores
IPU available: False, using: 0 IPUs
HPU available: False, using: 0 HPUs
Missing logger folder: /results/lightning_logs
Initializing test cereal_box data.
Loaded test 185 samples
LOCAL_RANK: 0 - CUDA_VISIBLE_DEVICES: [0]
Testing DataLoader 0:   0%|                              | 0/47 [00:00<?, ?it/s]/usr/local/lib/python3.10/dist-packages/torch/utils/checkpoint.py:428: UserWarning: torch.utils.checkpoint: please pass in use_reentrant=True or use_reentrant=False explicitly. The default value of use_reentrant will be updated to be False in the future. To maintain current behavior, pass use_reentrant=True. It is recommended that you use use_reentrant=False. Refer to docs for more details on the differences between the two variants.
  warnings.warn(
/usr/local/lib/python3.10/dist-packages/torch/utils/checkpoint.py:61: UserWarning: None of the inputs have requires_grad=True. Gradients will be None
  warnings.warn(
Testing DataLoader 0: 100%|█████████████████████| 47/47 [00:17<00:00,  2.74it/s]**********************Start logging Evaluation Results **********************
*************** 3D IoU *****************
3D IoU: 0.09549
*************** 2D MPE *****************
2D MPE: 0.23279
Evaluation metrics generated.
Testing DataLoader 0: 100%|█████████████████████| 47/47 [00:17<00:00,  2.74it/s]
Evaluation finished successfully
Telemetry data couldn't be sent, but the command ran successfully.
[Error]: module 'urllib3.exceptions' has no attribute 'SubjectAltNameWarning'
Execution status: PASS
2024-02-29 16:09:07,611 [TAO Toolkit] [INFO] nvidia_tao_cli.components.docker_handler.docker_handler 363: Stopping container.

This is what I got for visualization cell:
2024-02-29 16:09:24,494 [TAO Toolkit] [INFO] root 160: Registry: ['nvcr.io']
2024-02-29 16:09:24,537 [TAO Toolkit] [INFO] nvidia_tao_cli.components.instance_handler.local_instance 360: Running command in container: nvcr.io/nvidia/tao/tao-toolkit:5.2.0-pyt2.1.0
2024-02-29 16:09:24,553 [TAO Toolkit] [INFO] nvidia_tao_cli.components.docker_handler.docker_handler 301: Printing tty value True
There was a problem when trying to write in your cache folder (/.cache/huggingface/hub). You should set the environment variable TRANSFORMERS_CACHE to a writable directory.
There was a problem when trying to write in your cache folder (/.cache/huggingface/hub). You should set the environment variable TRANSFORMERS_CACHE to a writable directory.
sys:1: UserWarning:
'infer.yaml' is validated against ConfigStore schema with the same name.
This behavior is deprecated in Hydra 1.1 and will be removed in Hydra 1.2.
See https://hydra.cc/docs/next/upgrades/1.0_to_1.1/automatic_schema_matching for migration instructions.
<frozen core.hydra.hydra_runner>:-1: UserWarning:
'infer.yaml' is validated against ConfigStore schema with the same name.
This behavior is deprecated in Hydra 1.1 and will be removed in Hydra 1.2.
See https://hydra.cc/docs/next/upgrades/1.0_to_1.1/automatic_schema_matching for migration instructions.
/usr/local/lib/python3.10/dist-packages/hydra/_internal/hydra.py:119: UserWarning: Future Hydra versions will no longer change working directory at job runtime by default.
See https://hydra.cc/docs/next/upgrades/1.1_to_1.2/changes_to_job_working_dir/ for more information.
  ret = run_job(
Inference results will be saved at: /results/inference
Starting CenterPose inference
Initializing 185 inference images.
No pretrained configuration specified for convnext_base_in22k model. Using a default. Please add a config to the model pretrained_cfg registry or pass explicitly.
GPU available: True (cuda), used: True
TPU available: False, using: 0 TPU cores
IPU available: False, using: 0 IPUs
HPU available: False, using: 0 HPUs
Missing logger folder: /results/inference/lightning_logs
Initializing 185 inference images.
LOCAL_RANK: 0 - CUDA_VISIBLE_DEVICES: [0]
Predicting DataLoader 0:   0%|                           | 0/47 [00:00<?, ?it/s]/usr/local/lib/python3.10/dist-packages/torch/utils/checkpoint.py:428: UserWarning: torch.utils.checkpoint: please pass in use_reentrant=True or use_reentrant=False explicitly. The default value of use_reentrant will be updated to be False in the future. To maintain current behavior, pass use_reentrant=True. It is recommended that you use use_reentrant=False. Refer to docs for more details on the differences between the two variants.
  warnings.warn(
/usr/local/lib/python3.10/dist-packages/torch/utils/checkpoint.py:61: UserWarning: None of the inputs have requires_grad=True. Gradients will be None
  warnings.warn(
Predicting DataLoader 0: 100%|██████████████████| 47/47 [00:20<00:00,  2.26it/s]
Inference finished successfully.
Telemetry data couldn't be sent, but the command ran successfully.
[Error]: module 'urllib3.exceptions' has no attribute 'SubjectAltNameWarning'
Execution status: PASS
2024-02-29 16:09:53,877 [TAO Toolkit] [INFO] nvidia_tao_cli.components.docker_handler.docker_handler 363: Stopping container.

and
Looking in indexes: https://pypi.org/simple, https://pypi.ngc.nvidia.com/
Collecting matplotlib==3.3.3
  Downloading matplotlib-3.3.3.tar.gz (37.9 MB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 37.9/37.9 MB 8.0 MB/s eta 0:00:00m eta 0:00:01[36m0:00:01
  Preparing metadata (setup.py) ... done
Requirement already satisfied: cycler>=0.10 in /home/mona/.local/lib/python3.10/site-packages (from matplotlib==3.3.3) (0.11.0)
Requirement already satisfied: kiwisolver>=1.0.1 in /home/mona/.local/lib/python3.10/site-packages (from matplotlib==3.3.3) (1.4.4)
Requirement already satisfied: numpy>=1.15 in /home/mona/anaconda3/envs/sdgpose/lib/python3.10/site-packages (from matplotlib==3.3.3) (1.25.2)
Requirement already satisfied: pillow>=6.2.0 in /home/mona/anaconda3/envs/sdgpose/lib/python3.10/site-packages (from matplotlib==3.3.3) (10.0.0)
Requirement already satisfied: pyparsing!=2.0.4,!=2.1.2,!=2.1.6,>=2.0.3 in /home/mona/anaconda3/envs/sdgpose/lib/python3.10/site-packages (from matplotlib==3.3.3) (3.1.1)
Requirement already satisfied: python-dateutil>=2.1 in /home/mona/.local/lib/python3.10/site-packages (from matplotlib==3.3.3) (2.8.2)
Requirement already satisfied: six>=1.5 in /home/mona/anaconda3/envs/sdgpose/lib/python3.10/site-packages (from python-dateutil>=2.1->matplotlib==3.3.3) (1.15.0)
Building wheels for collected packages: matplotlib
  Building wheel for matplotlib (setup.py) ... done
  Created wheel for matplotlib: filename=matplotlib-3.3.3-cp310-cp310-linux_x86_64.whl size=8463990 sha256=088646468530213880688be2d4375b3d7ed79de3679cd9e467f8fa8b4b37ade4
  Stored in directory: /tmp/pip-ephem-wheel-cache-256m56c6/wheels/33/5f/fa/7686ebdceeeb90490e122e35f2a9e6c09affb891787d0921a6
Successfully built matplotlib
Installing collected packages: matplotlib
  Attempting uninstall: matplotlib
    Found existing installation: matplotlib 3.7.1
    Uninstalling matplotlib-3.7.1:
      Successfully uninstalled matplotlib-3.7.1
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
open3d 0.16.0 requires nbformat==5.5.0, but you have nbformat 5.9.2 which is incompatible.
Successfully installed matplotlib-3.3.3

[notice] A new release of pip is available: 23.2.1 -> 24.0
[notice] To update, run: pip install --upgrade pip

Hi @monajalal. Can you confirm if you are using the default settings? Note that the sample spec/default settings are not meant to produce SOTA (state-of-the-art) accuracy on the Objectron dataset. To reproduce SOTA, you should set TRAIN_FR as 15, epoch as 140, and DATA_DOWNLOAD as -1 to match the original parameters.


Glossary needs to expand to relevant terms, not just governed terms.

Tried to search on HEGIS.  Got no hit in glossary.  Yet it would handy to list the HEGIS categories and codes there.   vs searching each term.

Did you create a "HEGIS" term?
On Sat, Oct 1, 2016 at 5:29 AM, ssporins<EMAIL_ADDRESS>wrote:

Tried to search on HEGIS. Got no hit in glossary. Yet it would handy to
list the HEGIS categories and codes there. vs searching each term.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ndoit/fenrir/issues/319, or mute the thread
https://github.com/notifications/unsubscribe-auth/AGxpV0FSHcDm-71Kfyb2yi6ShpzmJ6uwks5qvigHgaJpZM4KLto7
.

The issue here is that the word "HEGIS" is not written any where in the definition of "Space Use Code" or "Space Use Category".  If this key word were included in the description then this would not be an issue.  I am closing this issue and I'll send Augie a note.


[TSCBasic] Don't delete empty tmpdir

Only delete tmpdir when explicitly asked by clients.
https://github.com/apple/swift-tools-support-core/pull/63

@swift-ci smoke test


Improve the base diffing algorithm

Hi, folks. I was so inspired by jsdiff library, that I decided to port it to Python, see pydiff (@kpdecker, I hope I am not violating anything, but if so, then let me know please).
The current implementation of the algorithm tends to perform additions first, and then removals, and sometimes even swapping added and removed parts afterwards doesn't help too much, because we might already obtain a "bad" solution.
Let me show you an example.

The content of the strings doesn't matter, the most interesting part here is the clause C, where there are a deleted part AND IBOOKS STORE and an inserted part , AND SOMETHING ELSE.
Using jsdiff.diffWords for comparing these string we obtain the following diff:
[ { count: 2, value: 'TERMS ' },
  { count: 1, added: undefined, removed: true, value: 'AND' },
  { count: 1, added: true, removed: undefined, value: 'OR' },
  { count: 50,
    value: ' CONDITIONS\nA. TERMS OF SALE\nB. ITUNES STORE TERMS AND CONDITIONS\nC. MAC APP STORE, APP STORE, APP STORE FOR APPLE TV ' },
  { count: 2, added: true, removed: undefined, value: 'TERMS ' },
  { count: 2, value: 'AND ' },
  { count: 1, added: undefined, removed: true, value: 'IBOOKS' },
  { count: 2,
    added: true,
    removed: undefined,
    value: 'CONDITIONS,' },
  { count: 1, value: ' ' },
  { count: 1, added: undefined, removed: true, value: 'STORE' },
  { count: 1, added: true, removed: undefined, value: 'AND' },
  { count: 1, value: ' ' },
  { count: 1, added: undefined, removed: true, value: 'TERMS' },
  { count: 1, added: true, removed: undefined, value: 'SOMETHING' },
  { count: 1, value: ' ' },
  { count: 1, added: undefined, removed: true, value: 'AND' },
  { count: 1, added: true, removed: undefined, value: 'ELSE' },
  { count: 1, value: '\n' },
  { count: 2,
    added: undefined,
    removed: true,
    value: 'CONDITIONS\n' },
  { count: 17,
    value: 'D. APPLE MUSIC TERMS AND CONDITIONS\nTHE LEGAL ' },
  { count: 1, added: undefined, removed: true, value: 'AGREEMENTS' },
  { count: 1, added: true, removed: undefined, value: 'CONTRACTS' },
  { count: 60,
    value: ' SET OUT BELOW GOVERN YOUR USE OF THE ITUNES STORE, MAC APP STORE, APP STORE, APP STORE FOR APPLE TV, IBOOKS STORE AND APPLE MUSIC SERVICES ("SERVICES").' } ]

Though this diff is optimal in terms of edit distance (17 removals/additions), it is not good enough, it is too complicated and has too many components.
But there exists yet another optimal diff with 17 changes (obtained in Python):
[{'count': 2, 'value': 'TERMS '},
 {'count': 1, 'removed': True, 'added': None, 'value': 'AND'},
 {'count': 1, 'removed': None, 'added': True, 'value': 'OR'},
 {'count': 50, 'value': ' CONDITIONS\nA. TERMS OF SALE\nB. ITUNES STORE TERMS AND CONDITIONS\nC.

IMHO, this diff looks much better, because it has less components and thus are more human-readable. Also it tries to remove as many tokens as possible, and only then tries to add tokens, and as a result we get bigger disjoint groups of removed/added tokens instead of many one-word changes like removed/added, removed/add etc.
What do you think about this change? Do you find it reasonable? When I started porting JS code to Python, I tried to make Python-output to be as close as possible to JS-output, but I decided to make an additional step ahead to improve readability of diffs, and now I am suggesting to back-port this change to jsdiff. I don't have any JS implementation yet, but my Python implementation can be used as a baseline.
Any suggestions, comments, alternative opinions, and also criticism are welcome :)
Thank you for attention.

Any thoughts?

I haven't looked at the implementation yet, but I agree that the output is preferable. I think the reason the output seems better is not purely attributable to humans preferring diffs with longer chunks removed/added (although that's part of it); instead it's that more of the edits in the diff your Python version produces are insertions or deletions of spaces, and more of the edits in the diff jsdiff produces are insertions or deletions of words.
It's illustrative to visualise just how they would diff the text
AND IBOOKS STORE TERMS AND CONDITIONS

against
TERMS AND CONDITIONS, AND SOMETHING ELSE

Here is what your library comes up with. (-s are deletions; +s are insertions; numbers on the third row are cumulative edit costs after the block of insertions/deletions they appear beneath):
AND IBOOKS STORE TERMS AND CONDITIONS+ ++++++++++++++++++
-----------------TERMS AND CONDITIONS, AND SOMETHING ELSE
        6                            7          12

And here's what jsdiff comes up with:
++++++AND IBOOKS +++++++++++ STORE+++ TERMS+++++++++ AND++++ CONDITIONS
TERMS AND ------ CONDITIONS, -----AND -----SOMETHING ---ELSE ----------
  2         3        5         6   7    8      9     10  11      12

I think everyone would agree your version is better, in the sense that it's a more intuitive diff to a human. But I only half-agree with you about why. You say it is because your version has fewer components - i.e. after you join together adjacent insertions/deletions, there are only 3 in your diff versus 10 in jsdiff's - and that humans in general prefer diffs with fewer components. I agree that's a factor that makes diffs more intuitive, but I think it's secondary here. More important is that your diff preserved three out of six words ("TERMS", "AND"m "CONDITIONS") in the text, whereas jsdiff's diff preserved only ONE WORD (namely "AND").
The idea that these two word diffs can even be considered to have the same edit distance when one deleted/added a total of 10 words and the other deleted/added only 6 words seems crazy! The only reason they do from the algorithm's perspective is that deleting a space between words is considered to be as costly as deleting a word, and therefore these two strategies both roughly come out as inserting/deleting "half" of each text:

lining up all the spaces ("half" of each text as measured by edit distance score!) from the two texts and then replacing literally all the words (the other "half" of the text)
lining up the second half of the first text with the perfectly-matching first half of the second text, then deleting the entirety of the non-matching half, including spaces

A side effect of preferring fewer contiguous sequences of insertions/deletions is that your algorithm tends to prefer the second strategy, which does yield a better result, but I view as kind of indirectly working around a more fundamental problem here, which is that those two strategies shouldn't be considered to have equal edit distance in the first place! According to the docs, diffWords does its diff "ignoring whitespace", but here we are treating a diff that preserves only 2/12 words in the two texts as equal to one that preserves 6/12 words purely because the former preserves more whitespace. If we want to live up to the description in the README, whitespace insertions and deletions should cost zero, and then we'd probably get something similar to your diff anyway.
(I'll still take a look at your implementation, though, and it may be that it would still be superior even if the edit cost bug above were fixed.)

I just took a look and I revise my opinion; although I still think your change to the algorithm is good, I think it doesn't even tend to produce diffs with longer runs of deletion/additions or to favour deleting spaces over words in diffWords. I think the fact that it produces a cleaner diff in this case is 100% coincidence.
If I understand right, the one pertinent change is this condition in base.py...
if diag == -edit_dist or diag != edit_dist and \
        self._get_endpoint(add_path, diag - 1)[0] <= \
        self._get_endpoint(remove_path, diag + 1)[0]:

which differs from the equivalent condition in base.js:
if (!canAdd || (canRemove && addPath.newPos < removePath.newPos)) {

The context of these lines is that we're trying to figure out the furthest we can get onto diagonal diagonalPath of the edit graph with editLength edits, and we're choosing between taking the furthest-reaching path of length editLength-1 on diagonal diagonalPath+1 and adding a move corresponding to deleting a token from the old sequence, or taking the furthest-reaching path of length editLength-1 on diagonal diagonalPath-1 and adding a move corresponding to adding a token from the new sequence. Both conditions agree that if one of those options will place you strictly further along diagonalPath than the other, you should take it. But they disagree about how to break a tie; pydiff favours doing an insert, while jsdiff favours doing a removal. Counterintuitively, that means pydiff favours paths that do removals earlier (because when we're choosing between stepping onto a diagonal via a character deletion or stepping to the same spot on that diagonal via a character insertion, that's respectively equivalent to continuing a path that has already done one extra insertion or continuing a path that has already done one extra removal).
Let's illustrate the change by considering diffing abcd (old) against acbd (new). Here's the edit graph...

First we consider how far we can get along the graph with 0 edits. That's easy: we preserve the a, and then we're stuck:

Next we consider how far we can get on each diagonal with 1 edit. With 1 edit we can move to either diagonal 1 or -1, respectively corresponding to an insertion of a c and a deletion of a b. Either way we then greedily include the next character, which is common:

Next we consider how far we can get on each diagonal with 2 edits. There's only one path to diagonal 2 or -2, but there are two ways to get to diagonal 0, shown here as dotted lines, and they both get to exactly the same point on the diagonal, which means neither is more optimal than the other:

These correspond to the following diffs:

Keep "a", delete "b", keep "c", insert "b", keep "d"
Keep "a", insert "c", keep "b", delete "c", keep "d"

In jsdiff, we break the tie by preferring to add a deletion onto a path that has already done an extra insertion - i.e. we choose option 2:

In pydiff, we break the tie by preferring to add an insertion onto a path that has already done an extra deletion - i.e. we choose option 1:

This is the better choice, because by convention diff tools prefer breaking these ties by putting deletions first. If you diff the file
a
b
c
d

against
a
c
b
d

by running diff old.txt new.txt you'll see that diff prefers a diff that does a deletion first and then an insertion.
BUT! this does not in any way whatsoever skew pydiff in favour of a diff with fewer components. The fact that it had that effect in this particular example is pure coincidence.
You might intuitively think this surely must be the case by symmetry. If you reverse which of two texts you treat as the "old" vs "new" text, then you just get the mirror image edit graph where the insertion-first paths are now removal-first paths. So in any situation where pydiff's rule results in simpler diffs, then by symmetry, if you reverse the order of the arguments to the diffing function, you must get a situation where pydiff's rule results in more complicated diffs.
We can see this in action with the example above:
>>> from pprint import pprint
>>> import pydiff
>>> old = "AND IBOOKS STORE TERMS AND CONDITIONS"
>>> new = "TERMS AND CONDITIONS, AND SOMETHING ELSE"
>>> pprint(pydiff.diff_words(old,new))
[{'added': None, 'count': 6, 'removed': True, 'value': 'AND IBOOKS STORE '},
 {'count': 5, 'value': 'TERMS AND CONDITIONS'},
 {'added': True, 'count': 7, 'removed': None, 'value': ', AND SOMETHING ELSE'}]
>>> pprint(pydiff.diff_words(new,old))
[{'added': None, 'count': 2, 'removed': True, 'value': 'TERMS '},
 {'count': 2, 'value': 'AND '},
 {'added': None, 'count': 2, 'removed': True, 'value': 'CONDITIONS,'},
 {'added': True, 'count': 1, 'removed': None, 'value': 'IBOOKS'},
 {'count': 1, 'value': ' '},
 {'added': None, 'count': 1, 'removed': True, 'value': 'AND'},
 {'added': True, 'count': 1, 'removed': None, 'value': 'STORE'},
 {'count': 1, 'value': ' '},
 {'added': None, 'count': 1, 'removed': True, 'value': 'SOMETHING'},
 {'added': True, 'count': 1, 'removed': None, 'value': 'TERMS'},
 {'count': 1, 'value': ' '},
 {'added': None, 'count': 1, 'removed': True, 'value': 'ELSE'},
 {'added': True, 'count': 3, 'removed': None, 'value': 'AND CONDITIONS'}]
>>>
mark@fractal:~$ cd jsdiff
mark@fractal:~/jsdiff$ node
Welcome to Node.js v21.1.0.
Type ".help" for more information.
> diff = require('.')
{
  Diff: [Getter],
  diffChars: [Getter],
  diffWords: [Getter],
  diffWordsWithSpace: [Getter],
  diffLines: [Getter],
  diffTrimmedLines: [Getter],
  diffSentences: [Getter],
  diffCss: [Getter],
  diffJson: [Getter],
  canonicalize: [Getter],
  diffArrays: [Getter],
  applyPatch: [Getter],
  applyPatches: [Getter],
  parsePatch: [Getter],
  merge: [Getter],
  structuredPatch: [Getter],
  createTwoFilesPatch: [Getter],
  createPatch: [Getter],
  convertChangesToDMP: [Getter],
  convertChangesToXML: [Getter]
}
> old = "AND IBOOKS STORE TERMS AND CONDITIONS"
'AND IBOOKS STORE TERMS AND CONDITIONS'
> nyoo = "TERMS AND CONDITIONS, AND SOMETHING ELSE"
'TERMS AND CONDITIONS, AND SOMETHING ELSE'
> diff.diffWords(old, nyoo)
[
  { count: 2, added: true, removed: undefined, value: 'TERMS ' },
  { count: 2, value: 'AND ' },
  { count: 1, added: undefined, removed: true, value: 'IBOOKS' },
  { count: 2, added: true, removed: undefined, value: 'CONDITIONS,' },
  { count: 1, value: ' ' },
  { count: 1, added: undefined, removed: true, value: 'STORE' },
  { count: 1, added: true, removed: undefined, value: 'AND' },
  { count: 1, value: ' ' },
  { count: 1, added: undefined, removed: true, value: 'TERMS' },
  { count: 1, added: true, removed: undefined, value: 'SOMETHING' },
  { count: 1, value: ' ' },
  {
    count: 3,
    added: undefined,
    removed: true,
    value: 'AND CONDITIONS'
  },
  { count: 1, added: true, removed: undefined, value: 'ELSE' }
]
> diff.diffWords(nyoo, old)
[
  {
    count: 6,
    added: true,
    removed: undefined,
    value: 'AND IBOOKS STORE '
  },
  { count: 5, value: 'TERMS AND CONDITIONS' },
  {
    count: 7,
    added: undefined,
    removed: true,
    value: ', AND SOMETHING ELSE'
  }
]

Sure, when you diff AND IBOOKS STORE TERMS AND CONDITIONS against TERMS AND CONDITIONS, AND SOMETHING ELSE, pydiff gives a result with 3 change objects and jsdiff gives a result with 13 change objects. Looks very bad for jsdiff. But that automatically means that when you diff TERMS AND CONDITIONS, AND SOMETHING ELSE against AND IBOOKS STORE TERMS AND CONDITIONS, jsdiff will give you a result with 3 change objects while pydiff will give you one with 13 change objects - and sure enough, that's what happens! Every scenario where pydiff outperforms jsdiff on this metric has a mirror scenario where jsdiff equally outperforms pydiff. There's no general sense in which pydiff's algorithm can be expected to yield results with fewer change objects.
Despite all the above, I still think we should make the suggested change, just for consistency with the convention followed by other diffing tools. But the reduction in the number of change objects returned by calls to diffWords that this issue suggests will be delivered as a result of such a change is 100% illusory, and anyone expecting to see such an improvement is going to be disappointed.

I've got a PR at https://github.com/kpdecker/jsdiff/pull/439 making us favour delete-then-insert paths over insert-then-delete paths, which brings us into alignment with the Myers diff paper and with the Unix diff tool. It won't merge for a while since it's kind of a breaking change (given that it changes what results jsdiff gives) and I have some important non-breaking changes I very deliberately want to release before we release any breaking ones, but it'll probably go out at some point in January. I'm gonna go ahead and close this issue now, though, just to help me keep track of what I do and don't still need to do.
I'd welcome a review of https://github.com/kpdecker/jsdiff/pull/439!


Question: why not mendoza?

Not to be rude, just if something is missing for you?

@pepe No, it's not rude. In fact, it's a good question. I did have a look at Mendoza but there were three reasons I decided to roll my own:

I wanted a project that would give me an excuse to play around with Conjure.
I wanted to write my content files in CommonMark and with YAML-style frontmatter.
I just wanted to write some Janet :D

I am planning on using Temple for templates. I don't suppose you have any experience using them, do you? I'm curious whether you can have templates that you use within other templates. It sounds like maybe you can (the README says that 'Templates can be used recursively') but I'm not sure how you'd do it.

All reasons are perfectly valid! Thank you.
I used temple only for some basic Janet code (sic) generation in chidi https://github.com/good-place/chidi/tree/master/chidi/generate no nesting what so ever. But the thing is that it is quite clear code, you can examine yourself. Also, I have the experience with @bakpakin, that what is in README is in code.
PS: I would love to have Conjure for kakoune editor :-).

Well, if nothing more I gave Mendoza a bigger shot finally, and I like it.
I am looking forward to checking Statically!


Suport for images/audio in zip, in api and as external links

So we need to support all three cases here

[ ] images/audio are relative paths in the API itself and we have to download
[x] images/audio are external links that we have to download (already supported)
[ ] images/audio are uploaded with the zip file (sub-issue #520)

we will have case 3 done when this issue https://github.com/fossasia/open-event-webapp/issues/520 is solved

@championswimmer Case 3 is done https://github.com/fossasia/open-event-webapp/pull/521

@championswimmer  Can you please help me in this  images/audio are relative paths in the API itself and we have to download ?

point no.1 done here https://github.com/fossasia/open-event-webapp/issues/522


feat: Adds support for airflow macros and variables as params

<description>
Resolves <issue nr here>

Keep in mind:

[x] Documentation updates
[x] Changelog updates

Hey Bartłomiej! The change looks really good, I have tested it in battlefield and everything worked as expected.
Thank you for your contribution! :rocket:

Released as 0.5.3: https://pypi.org/project/kedro-airflow-k8s/0.5.3/


Drop list support in optimize_for

Description
optimize_for API takes args and aux params and was initially modeled on the Symbol Bind API that accepts both list and dictionary types. However, the list use-case is no longer used. Currently args/aux comes from load_checkpoint API which returns dictionaries. With the support for custom graph passes, backends can add/remove params from args/aux. This is not feasible with lists. This PR removes support for lists for args/aux.
Checklist
Essentials
Please feel free to remove inapplicable items for your PR.

[ ] The PR title starts with [MXNET-$JIRA_ID], where $JIRA_ID refers to the relevant JIRA issue created (except PRs with tiny changes)
[ ] Changes are complete (i.e. I finished coding on this PR)
[ ] All changes have test coverage:
Unit tests are added for small changes to verify correctness (e.g. adding a new operator)
Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore)
Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL)
[ ] Code is well-documented:
For user-facing API changes, API doc string has been updated.
For new C++ functions in header files, their functionalities and arguments are documented.
For new examples, README.md is added to explain the what the example does, the source of the dataset, expected performance on test set and reference to the original paper if applicable
Check the API doc at https://mxnet-ci-doc.s3-accelerate.dualstack.amazonaws.com/PR-$PR_ID/$BUILD_ID/index.html
[ ] To the best of my knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

Changes

[ ] Feature1, tests, (and when applicable, API doc)
[ ] Feature2, tests, (and when applicable, API doc)

Comments

If this change is a backward incompatible change, why must this change be made.
Interesting edge cases to note here

Except for the small typo in the warning, LGTM!

@mxnet-label-bot add [pr-awaiting-merge]
@ptrendx ready when you are


Resource Panel - Copy URL isn't a valid Fusion URL

Environment
Fusion 1.7.0
Delta 1.7.0
Chrome 100.0.4896.88
MacOS 12.3
Steps to reproduce

open a public studio
open an entity
3a. Click Copy > URL : https://bbp.epfl.ch/public/thalamus/resources/https%253A%252F%252Fbbp.epfl.ch%252Fneurosciencegraph%252Fdata%252Fa3bb1dab-0493-4c4b-a345-7bd5902a3b47
3b. Copy > URL (with revision) : https://bbp.epfl.ch/public/thalamus/resources/https%253A%252F%252Fbbp.epfl.ch%252Fneurosciencegraph%252Fdata%252Fa3bb1dab-0493-4c4b-a345-7bd5902a3b47?rev=10

Both options lack the webapp path after the server: /nexus/web/
Possible issues:

deployment configuration ?

Behaviour is now different but still appears to fail.
Steps:

open this entity (BBP only)
open the menu and click Copy ID
paste it again in a new browser window, it looks like https://staging.nise.bbp.epfl.ch/nexus                    /bbp_test/akk_snap_test1/resources/https%253A%252F%252Fbbp.epfl.ch%252Fneurosciencegraph%252Fdata%252Fcircuits%252Fadc4155f-8865-48e4-9dd3-818d5a04ba2f

If I remove the superfluous spaces it appears to load the resource as expected.
I now see the /nexus after the host that was previously missing. But now I also see some %20 (encoded space).

https://github.com/BlueBrain/nexus-web/pull/1106


notOK() assertion showing expected as undefined

We are using assertion for an element to disapper, i.e., wait until spinner disappears and seeing expected undefined if spinner stays more than expected time
Testcafe Step: -    await t.expect(Selector(.'spinner').exists).notOk("Wait For Spinner");

AssertionError: Wait For Spinner: expected true to be falsy

expected - actual

-true
+undefined

since expected showing as undefined browser is not getting closed and spinning forever. Could you please help
TestCafe version - 1.9

We are looking into this issue in the context of the following thread: #5473


Wrapped links are invalid

Hi! When my terminal width is too narrow, text automatically wraps which ends up breaking long links. Below is a screenshot:

This means that only the first line of the hyperlink is active: https://github.com/ValveSoftware/steam-for- which gives a 404, obviously. I have attempted to read through glow's documentation and issues for anyone referencing this issue but have found no such mention of it.
Additionally, I notice that with glow, the markdown fails to make the text an actual hyperlink, instead just coloring it and underlining it.
Using escape sequences, it is possible to do this in terminal:

This acts as a valid hyperlink, and is additionally immune to this sort of text wrapping issue, as demonstrated here:

Not sure if this would best be solved with code changes to this repo, or if this may be better targeted towards glow.
Thanks!

I have created an issue within the glow repository after doing some additional testing. It appears to be a bug within glow, not this program. The solution I have proposed here and in the glow issue should resolve things. If glow takes too long to fix this, it could potentially be implemented as a hacky fix within this program until glow fixes it on their end.

This is definitely an issue with glow.
I don't think I want to implement a fix here, it's outside the scope of this project. I'll keep up with the issue in glow.
If you can find a maintainable solution for this repo, I'd be more than happy to look at a PR, though.
Thank you for bringing this to my attention.

Upon closer inspection, this doesn't seem to be an issue with glow, you should be able to configure this.
You can invoke glow with the -s flag and provide a custom style definition in json, see this page for details. I think using the prefix, suffix, and block_prefix/block_suffix, you should be able to wrap links in this escape sequence.
I'm sceptical about whether we should use that as a default, though, since not many terminal emulators seem to actually support this escape sequence.
Here's the relevant PR for alacritty, for example.
If you're interested, you could see if you manage to create a style definition for this, it shouldn't be that hard, afterwards, we could think about trying to detect that ability, but I don't want to add much complexity to this script, so I can't promise anything about merging such functionality.

Isn't this related to the terminal's capability to create links automatically from text?
I cannot reproduce this on alacritty or gnome-terminal. What terminal are you using @EricAndrechek?

I'm sceptical about whether we should use that as a default, though, since not many terminal emulators seem to actually support this escape sequence.

That's what I was talking about. You can reproduce their issue using kitty though.

Upon closer inspection, this doesn't seem to be an issue with glow, you should be able to configure this.

I say it is an issue with glow, as I believe it should do that for you. When I write [a link](https://example.com) in markdown "a link", it creates a hyperlink. I don't have to specify line breaks or anything, it sorts that out for me. If the link wraps to a new line, the whole thing is still valid, it doesn't separate the URL onto two different lines making both lines invalid.

Isn't this related to the terminal's capability to create links automatically from text?

As to this comment, I don't believe so, no. In my testing with gnome-terminal, running
echo "https://example.com/really-long-link-to-test-a-line-break-that-is-well-over-the-default-80-character-line-length-to-force-the-terminal-to-automatically-wrap-this-text"

will automatically wrap as handled by the terminal, and is still a valid and clickable link, as shown below.

Glow/glamour handles rendering the markdown differently than expected, however. The markdown is not turned into a hyperlink within the terminal, which I understand as it means that even if your terminal doesn't support the special hyperlink escape sequences it can still identify the full link to automatically turn it into a clickable link, or allow you to copy and paste it into a web browser. Here is an illustration of the differences I am talking about:

IMO, the first hyperlink option is easily the cleanest, but I understand that it may not work on every terminal. The second option clearly works as an alternative, which is fine. The problem arises with the third method. Glow identifies that the terminal width is 80 and manually tells the text to wrap, instead of letting the terminal handle it. This breaks the link. If I tell glow to ignore the terminal width and use a wrap length longer than the link, the terminal wraps it automatically and the link still works.

Ok - follow up here. I attempted to using the styling json for glamour/glow to make the hyperlinking work, but unfortunately the order glamour puts them in is incorrect for what the hyperlink expects, and without making modifications to glow this seems impossible. My json was as follows:
{
    "link": {
        "block_prefix": "\\033\\\\",
        "block_suffix": "\\033]8;;\\033\\\\\n"
    },
    "link_text": {
        "block_prefix": "\\033]8;;"
    }
}

But unfortunately, glow doesn't actually listen to the escape sequences:

Wrapping the whole thing inside an echo will have it listen to the escape sequences and render correctly:

But as you can see, the link and the link_text are flipped. This is not the way the terminal hyperlink expects it. Again, not an easy fix to this other than modifying glamour's code. Luckily, there seem to already be some people aware of this and working on it: Glamour: Feature: Support 'modern' anchors through ANSI OSC 8 escapes, and Github CLI: Auto-detected links with new lines result in 404s when clicked

Thanks for your research!
As it's not an issue with this project, I'll close this issue.


no highliting when cmake compilation fails

Hi, my code was not highliting the errors and I took entire day to realize it was because the cmake C++ part of the code was failing to compile.
Maybe add this failure info at least on the output?

So in a nutshell what is happening is that a dependency fails to build with an error, and we end up just eating that error without showing the user any such information right?

Yes. If the build.rs fails, then nothing is displayed and the error highlighting does not work, which made me unaware of what was happening

So I just checked, if you have a dependency whose build script fails to build r-a does show you a warning status

I've noticed that the popup can get so large that it appears under the cursor, which causes VS Code / Electron to immediately hide it again, which then makes it pop up again, using a lot of CPU, so I'm guessing we aren't meant to put that much text in it :)
I'm not really sure how to do better here – we could emit an actual diagnostic and put it in the workspace's Cargo.toml, or print it to stderr when the rust-analyzer logo is clicked, but neither seems ideal.

What about opening a new special page filled by rust-analyzer just like for example the memory stats? Also is it possible for the problems pane to refer to such special page? Or can it only refer to regular source files?


fix: evaluate expression from root

Refactors the evaluation of expressions to allow evaluation from root to leaves.

Splits concerns into different transformers,
Instead of transformers rule logic is contained in decorator patterns,
Expression tree is evaluated from top to bottom (recursively).

Fixes #66

Few minor comments outstanding

Addressed the outstanding issues :+1:


Remove deprecation from radio button list

Only a part of this component was deprecated in the past, the warning for this was updated a few months ago include the entire thing. This isn't correct, so instead we'd like to remove the warning all together and add it again when we're starting the work on the new replacement widget.

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

Just to note: I have already accepted the license agreement, but for some reason it never works for me

With the latest Radio Button List release, the deprecation has been removed from the name of it. PM and SDM have agreed to revert the deprecation for this widget until we can point people to a replacement.


Fix updating of password

Brings in:

[ ] https://github.com/alphagov/digitalmarketplace-utils/pull/170

Discussion point: is it right to say it's the user who is updating their password here—they're not logged in—is it something we can really know?

As they have clicked the link from an email received at that email address I think it is OK to say that that email address is updating the password.

:+1: once Travis is happy.


Document my (krader1961) Elvish support modules

I've edited out the formatting changes. As I've explained elsewhere, this repository is not subject to style enforcements.

I've edited out the formatting changes. As I've explained elsewhere, this repository is not subject to style enforcements.

Why not keep them? Without those directives I now have to complicate my Vim configuration to only run prettier on some, rather than all, Markdown files.


Hardcode channel properties

Hardcode channel configuration in the feature pack

Closing as this turns out to be not needed.


Fixing issue with tojpg not being deleted

Fixes #894
Issue
Some JPG files are not deleted, when they were generated through tojpg Twig filter that was used on a PNG file.
Solution
Change generated tojpg files to have tojpg in the filename.
Added two more calls to delete_generated_files with specific regex for the tojpg
Impact
Negligibly slower
Usage
No change
Considerations
I tried combining the two calls to one, but couldn't get it to work with glob correctly.

Thanks @connorjburton — the doctors have cleared me for GitHub usage again. This looks good!


Various improvements for Ada

Hello,
At @Adacore, we have started to use cv2pdb to translate GCC’s DWARF output for Ada into PDB/CodeView. We found several bugs, which we tried to fix (for instance array size computation with non-zero low bound index), and also several kinds of types for which we could add translation (for instance enumeration types).
Do you think these changes can be merged? For the record, we tested them by hand on several Ada examples, and are currently trying to develop an automated testsuite, probably based on Microsoft’s CDB command-line debugger. However we haven’t checked the effect on D programs.
Thank you in advance for having a look! :-)

I hope it’s for the better, indeed. ;-) Thank you for your review! I’ve just pushed modified commits following it. As I’ve done some work since yesterday, I also added a couple of commits on top of it.
I’m curious: do you know which languages/compilers have users that rely on cv2pdb? As for D, so if I understand correctly, DMD/LDC already generate CodeView info in various PE sections, and so in this context, cv2pdb’s only job is to extract this info to store it as a PDB file, right?

do you know which languages/compilers have users that rely on cv2pdb?

It seems used by a number of people with mingw and C++ and Haskell. IIRC it has also has been considered with Rust (before LLVM got CodeView support).

As for D, so if I understand correctly, DMD/LDC already generate CodeView info in various PE sections, and so in this context, cv2pdb’s only job is to extract this info to store it as a PDB file, right?

No, DMD and LDC can generate COFF object files with embedded CodeView information that the MS linker can extract and combine to generate the PDB file.
cv2pdb is still used for DMD's ancient additional tool chain based on OMF object files and the Digital Mars linker. dmd/optlink emit CodeView 4 debug info which is not well supported by current debuggers and needs to be converted to something more recent.

That’s interesting. Thank you for the explanation!

Alright, so I’ve added a PDB corruption fix on top of the stack of fixes, plus the small fix (and then a typo fix…) mentionned in review. I think I’ll stop here, sorry if the back-and-forth complexified your review. :-)

I see a nice improvement for enums in the little test case that I have, but can't really test it a lot as my small test suite already fails with current master, so I'm going to merge this.
I'll fix up a few signed/unsigned warnings regarding -1u after that changing it to ~0.
Thanks a lot for your contribution.

Great, thank you very much for your review and merge!


Option to disable  "Handlers - restarting daemons after a config change" ?

Is that possible to disable "## Handlers - restarting daemons after a config change" ?
I'm doing some test about config generation and it takes more than 40min to run the playbook because of the restart of the 40 OSDs, which is quite long in my case.
Thx
Yoann

Not possible and I don't think it'll ever be.

so doing something like that is not possible ? (it a quick and dirt stuff, can definitely be better)
https://github.com/EPFL-IC/ceph-ansible/commit/ca7b7977ce8737505385d617d7eeba08c59bec41

@mistur feel free to submit a PR and we will discuss this further, thanks!

Closed due to inactivity, feel free to re-open if needed. Thanks!


Issue with cameras not showing up in my feed but the motion sensors from the cameras are operational.

I have been encountering " ERROR (stream_worker) [homeassistant.components.stream.worker] Error opening stream rtsp://:@...:8554/Video-50" and also the same error ending in /Video-40 for the other camera I am trying to set up.
Still learning all of this but all of the HA and the rest of my vivint equipment is working really nice.  Thanks alot for all of your work!
**I have gotten it all running. Thank you so much for this wonderful integration.

Yeah, I see that stream_worker error on mine occasionally, too. I think the issue is from the camera and/or stream component rather than from this integration itself.


CUDA differs from Rust

Reproducing the behavior
This program:
@List/Cons = (a (b ((@List/Cons/tag (a (b c))) c)))

@List/Cons/tag = 1

@List/Nil = ((@List/Nil/tag a) a)

@List/Nil/tag = 0

@id = (a a)

@list = c
  & @List/Cons ~ (1 (b c))
  & @List/Cons ~ (2 (a b))
  & @List/Cons ~ (3 (@List/Nil a))

@main = e
  & @map ~ ((a b) (d e))
  & @map ~ (a (@list b))
  & @List/Cons ~ (@id (@List/Nil d))

// @main__C0 = (a b)
//   & @map ~ (a (@list b))

@map = (a ((@map__C1 (a b)) b))

@map__C0 = (* (a (d ({(a b) c} f))))
  & @List/Cons ~ (b (e f))
  & @map ~ (c (d e))

@map__C1 = (?(((* @List/Nil) @map__C0) a) a)

Reduces to (in the rust runtime):
Result: ((@List/Cons/tag (((@List/Cons/tag (1 (((@List/Cons/tag (* (((@List/Cons/tag (* (@List/Nil vc4))) vc4) vb3))) vb3) va2))) va2) (@List/Nil vec))) vec)
- ITRS: 179
- TIME: 0.00s
- MIPS: 11.22

Reduces to (in the c runtime):
Result: ((@List/Cons/tag (((@List/Cons/tag (1 (((@List/Cons/tag (* (((@List/Cons/tag (* (@List/Nil xc00003b))) xc00003b) xc00002b))) xc00002b) xc00001b))) xc00001b) (@List/Nil x10000003))) x10000003)
- ITRS: 181
- TIME: 0.00s
- MIPS: 0.22

Reduces to (in the cuda runtime):
Result: ((@List/Nil/tag x2081) x2081)
- ITRS: 181
- LEAK: 2
- TIME: 0.10s
- MIPS: 0.00

Narrowed it down to the following:

when running CUDA and C without IO, then they agree with the rust implementation. The C and CUDA runtimes disagree with each other because of the following code difference:

// C implementation
Port expand(Net* net, Book* book, Port port) {
  Port old = vars_load(net, get_val(ROOT));
  Port got = peek(net, port);
  while (get_tag(got) == REF) {
    boot_redex(net, new_pair(new_port(REF,get_val(got)), ROOT));
    normalize(net, book);
    got = peek(net, vars_load(net, get_val(ROOT)));
  }
  // "offending" line below.
  vars_create(net, get_val(ROOT), old);
  return got;
}

Port gnet_expand(GNet* gnet, Port port) {
  Port old = gnet_vars_load(gnet, get_val(ROOT));
  Port got = gnet_peek(gnet, port);
  while (get_tag(got) == REF) {
    gnet_boot_redex(gnet, new_pair(new_port(REF,get_val(got)), ROOT));
    gnet_normalize(gnet);
    got = gnet_peek(gnet, gnet_vars_load(gnet, get_val(ROOT)));
  }
  // missing an equivalent `vars_create`
  return got;
}

It's unclear to me which is correct.

This difference in gnet_expand and expand was a bug is fixed here: https://github.com/HigherOrderCO/HVM/pull/401, this might resolve this issue.


[Feature]: Input page number and go straight there

Is there an existing issue for this?

[X] I have searched the existing issues

Summary
It's frustrating to click 'next-page' for countless times when I need to go to page 100
Why should this be worked on?
Table's pagination UI won't let me manually input a page number I want to go to. It's frustrating to click 'next-page' for countless times when I need to go to page 100. Is there a feature already available that I'm not aware of? I'm on latest ce btw.

My bad, I was referring to the table widget :)

This is a duplicate of #24973


Distinguish between terminal compaction failures and intermittent failures

Description
This PR addresses the need for better monitoring of compaction task failures by introducing two new metrics:
task/failed/acquireLock/count: Tracks the number of times a compaction task fails to acquire a lock. This metric is useful for identifying transient issues, such as conflicts with other ingestion jobs. To filter compaction tasks, look for group id starting with coordinator-issued_compact
compact/failed/schemaError/count: Monitors the number of compaction failures due to schema mismatches within the same interval. This metric requires user intervention for resolution.
By adding these metrics, we aim to provide more granular insights into the different types of compaction failures, enabling quicker diagnosis and resolution.

Release note

Added two new metrics task/failed/acquireLock/count and compact/failed/schemaError/count for monitoring compaction failures.

Key changed/added classes in this PR

LockAcquisitionFailedException indicate that a lock acquisition has failed

This PR has:

[x] been self-reviewed.

[ ] using the concurrency checklist (Remove this item if the PR doesn't have any relation to concurrency.)

[ ] added documentation for new or modified features or behaviors.
[ ] a release note entry in the PR description.
[ ] added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
[ ] added or updated version, license, or notice information in licenses.yaml
[ ] added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
[ ] added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.
[ ] added integration tests.
[ ] been tested in a test Druid cluster.

This is not a good metric name. If a task can fail for 10 reasons, we don't have to add 10 different metrics. The right way to do is to through one metric and adding a dimension to denote the failure reason.

Close this for now as we may do this in a different way


Postman integration

Postman has first class support for socket io: https://blog.postman.com/postman-now-supports-socket-io/

fern-postman has been added

@dannysheridan @dsinghvi  are we tracking the "live updating postman" somehwere?

Yes.  https://github.com/fern-api/fern/issues/284


Fixed visitor feature in SkyHanni

this is no joke

This is a better solution though:
https://github.com/hannibal002/SkyHanni/commit/b7e4d63c3ec4331b2332b7b02c2ecef3f19487b5


Create reference files and indexes

All mapping workflows will require reference files and accompanying indexes. To create these, we will use a Nextflow workflow.
This workflow should download all necessary reference files (hg38 sequence, GTF, etc.), storing them in s3://ccdl-nextflow-data/reference. My current preference is to download  these reference files from Ensembl, and group all files by Ensembl version.
These should then be indexed for both salmon and kallisto. For salmon, we will start with the simplest index of just the cDNA, with the potential to add decoy-aware mapping in the future.

I am going to consider this done when the basic steps are completed in #6 and #7. More focused issues for later steps are in #11 and #12

Considering this closed by #7, specific extensions in other issues, as, noted: https://github.com/AlexsLemonade/alsf-scpca/issues/3#issuecomment-677801813


How to generate class embedding files?

Hi, thanks for you great job.
I just get confused how do you generate these classes embedding files(fastext, glove).
How does the index in classes embedding files match to the class id?
Could provide a little more details about generating class embedding files?
Thanks!

Hi @GuangyuanLiu1999 ,
Thanks for showing interest in our work. The class embedding files can be:

taken directly as a reference from previous repositories that provided them, like our repository, https://github.com/salman-h-khan/PL-ZSD_Release, etc.
generated yourself by downloading pretrained word2vec/glove/fasttext (whichever embedding you need) embeddings and obtaining the specific vectors for each object class following https://radimrehurek.com/gensim/models/word2vec.html tutorial.

Note that in both these cases, there might be differences in the vector elements you obtain, as some people apply different vector normalizations before using them as semantic vectors.
Moreover, to follow our work you need to have semantic vector of a "background" class which can be obtained from our given fasttext.npy. You might obtain that semantic vector even yourself, for example, by averaging the vectors of all object classes[1], or by assigning a fixed vector[2,3]. However, performance might not be the same.

To answer the indexing issue, before the training of our cWGAN starts, in https://github.com/sandipan211/ZSD-SC-Resolver/blob/main/trainer.py, we first load the class embedding matrix, for which utils can be found at https://github.com/sandipan211/ZSD-SC-Resolver/blob/70eb6f7be3118c19b9892edd465b32e86cca6d0a/generate.py#L8. The mapping of classes with labels/ids can be found at https://github.com/sandipan211/ZSD-SC-Resolver/blob/70eb6f7be3118c19b9892edd465b32e86cca6d0a/mmdetection/splits.py.
[1] Rahman, Shafin, Salman Khan, and Fatih Porikli. "Zero-shot object detection: Learning to simultaneously recognize and localize novel concepts." Computer Vision–ACCV 2018: 14th Asian Conference on Computer Vision, Perth, Australia, December 2–6, 2018, Revised Selected Papers, Part I 14. Springer International Publishing, 2019.
[2] Bansal, Ankan, et al. "Zero-shot object detection." Proceedings of the European Conference on Computer Vision (ECCV). 2018.
[3] Zhu, Pengkai, Hanxiao Wang, and Venkatesh Saligrama. "Don't even look once: Synthesizing features for zero-shot detection." Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition. 2020.

Hi @GuangyuanLiu1999 ,
Thanks for showing interest in our work. The class embedding files can be:

taken directly as a reference from previous repositories that provided them, like our repository, PL-ZSD, etc.
generated yourself by downloading pretrained word2vec/glove/fasttext (whichever embedding you need) embeddings and obtaining the specific vectors for each object class following this tutorial.

Note that in both these cases, there might be differences in the vector elements you obtain, as some people apply different vector normalizations before using them as semantic vectors.
Moreover, to follow our work you need to have semantic vector of a "background" class which can be obtained from our given fasttext.npy. You might obtain that semantic vector even yourself, for example, by averaging the vectors of all object classes[1], or by assigning a fixed vector[2,3]. However, performance might not be the same.

To answer the indexing issue, before the training of our cWGAN starts, in trainer.py, we first load the class embedding matrix, for which utils can be found at generate.py. The mapping of classes with labels/ids can be found at splits.py.
[1] Rahman, Shafin, Salman Khan, and Fatih Porikli. "Zero-shot object detection: Learning to simultaneously recognize and localize novel concepts." Computer Vision–ACCV 2018: 14th Asian Conference on Computer Vision, Perth, Australia, December 2–6, 2018, Revised Selected Papers, Part I 14. Springer International Publishing, 2019. [2] Bansal, Ankan, et al. "Zero-shot object detection." Proceedings of the European Conference on Computer Vision (ECCV). 2018. [3] Zhu, Pengkai, Hanxiao Wang, and Venkatesh Saligrama. "Don't even look once: Synthesizing features for zero-shot detection." Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition. 2020.

Thank you very much for your serious reply. I will seriously follow your prompts to do experiments, and I would like to express my heartfelt thanks to you again.


Update latest base images versions

Change-type: patch
Signed-off-by: Trong Nghia Nguyen<EMAIL_ADDRESS>

Please make sure to read the CONTRIBUTING document before opening the PR for relevant information on contributing to the documentation. Thanks!

@balena-ci I self-certify!


Multiple whatsapp sessions

I need a hint of the best way to handle multiple whatsapp sessions (each one for a different whatsapp identifier), in other words, we have to work with a inconstant amount of whatsapp sessions.
Does this lib work fine with multiple whatsapps? Would it be necessary to create an instance for each one (running on different server ports)?

I am also looking for the solution of multiple sessions on single VM. Does any one achieve this, please provide a hint.

how many clients with same IP  address will WhatsApp allow ?

I am also looking for the solution ..

I think the answer would be yes.
You need to run as many node clients as sessions you need.
My approch would be:

Run API server
Run HTTP server
Create and run a main luncher client to setup and execute a single process (node client) for every session you need to handle. This would be kind of a dashboard to view how many users (whatsapp sessions) are connected.

What do you think?

Any updates on what is the best method to use?


[range] Range Selection cannot be toggled on / off

https://www.ag-grid.com/forum/showthread.php?tid=4553

tracked by AG-166
https://ag-grid.atlassian.net/browse/AG-166


social links

Fixes error where site wouldn't build
https://stackoverflow.com/questions/74408145/minima-theme-build-shows-liquid-exception-invalid-syntax-for-include-tag-file


QUESTION: How to disable swipe-back but not disable drawer-swipe

Version
Tell us which versions you are using:

react-native-router-flux v4.0.0-beta.17
react-native v0.46.4

Now, when implementing a drawer, swiping left opens the drawer AND pops the scene. The only workaround is to disable gestures altogether by using panHandlers or disableGestures but that's not the behaviour i'd like. My question: is it possible at this moment to only disable swipe-back gestures but not drawer-init-gestures per scene?

Try adding type="replace in drawer Scene.
This works for me.
<Scene key="drawer" drawer contentComponent={SideBar} type="replace" hideNavBar={true}>
      <Scene key="main" >
          <Scene key="scarlet" component={ScarletScreen} title="Scarlet" />
    </Scene>
</Scene>

@abeltje1 I don't understand your issue. Check Example project, tab2_2 - it has panHandlers disabled but you still can open drawer by swipe.

@aksonov you're right, on my simulator I couldnt swipe for some reason but on phone it actually works, sorry. Is the reverse also possible? (Disable drawer swipe but not back swipe)?
Thanks for your response!

It is not supported yet: https://github.com/react-community/react-navigation/issues/390

@aksonov ,
Below is my Router,

<ReduxRouter getSceneStyle={getSceneStyle}>
<Scene overlay>
<Scene navigationBarStyle={[{backgroundColor: '#005685'}]} leftButtonTextStyle={{ color: 'green' }} backButtonTextStyle={{ color: 'red' }} initial>
<Scene key="modal" modal hideNavBar>
<Scene key="drawer" drawer contentComponent={SideDrawer} >
<Scene key='root' >
<Scene key="HomeComponent" component={HomeComponent} initial renderTitle={() => { return <AppLogo name="App Name" />; }} />
<Scene back={true} key="SecondPage" component={SecondComponent} renderTitle={() => { return <AppLogo name="App Name" />; }} />
<Scene back={true} key="ThirdPage" component={ThirdComponent} renderTitle={() => { return <AppLogo name="App Name" />; }} />
</Scene>
</Scene>
</Scene>
</Scene>
</Scene>
</ReduxRouter>

Current behavior:  Drawer is visible on 'HomeComponent' and i have disabled it on other scenes using "back={true}".
But on SecondComponent & ThirdComponent swipe back opens drawer and also goes to back page on closing of drawer.
Expected:

Drawer on all page and back button on all page except HomeComponent.
OR
Drawer on HomeComponent and back button on rest of the pages .
(Drawer or back button  back button must be disabled on thease page, to avoid comflict)

Any solution or any alternate ways to overcome this issue ?
Anybody please help.
Thanks in advance.

@preetampatil3d did you found any solution for your case?


Add accessibilityElementsHidden Prop To View Comp.

accessibilityElementsHidden is used to control wheter elemetns contained
within a view are hidden from accessiblity services that query the
screen.
On iOS, it simply reflects UIKit's accessibilityElementsHidden, on
Android it is implemented with importantForAccessibility.
This commit also improves accessiblity of Navigation Experimental
CardStack by marking inactive (off screen) scenes invsible.
Closes #9725

Previous discussion on this issue happened on this pull request. It looks like @omeid created a new PR because the previous pull request was languishing. This PR is important to me because without it the Navigator Experimental is unaccessible on iOS.

@RubenSandwich Yes, that pull request had to be rebased so many times I somehow missed some files in the process and it was rather messy, so I made this one.

I think that breaking the current importantForAccessibility behavior is too much of a cost to pay for this. Would it be possible to just make importantForAccessibility work on iOS as well? Another issue is that we intend to deprecate NavigationExperimental, so we are trying to avoid adding any more functionality there.

Hi @lacker,
This is not really breaking importantForAccessiblity, it marks it deprecated in favour of accessiblityElementsHidden.
However, as per initial conversation about this feature, if there is reasons to keep importantForAccessiblity, we should consider how we go about it.
re NavigationExperimental, this is not really doing much there, it is just making sure the compoent is not totally inaccessable, which is a big shame.

Well, marking it as deprecated is implying that we'll remove it eventually, so it's introducing a breaking change, even if the day it breaks is not today.

My understanding is that deprecation is implying the intention of removing something; and this phase exists to ease the transition and provide an oppurtunity for reconsideration.
Regardless of semantics, as someone who is using this feature in both Android and iOS I would be interested to know what is the usecase for importantForAccessiblity that isn't possible with accessiblityElementsHidden and see how we can accommodate said requirments in a platform consistent way. Please also see #10918 for a bit of background.
Also, thanks for looking into this issue. It is something that I would really love to get fixed upstream so I don't have to manage my local fork. :(

The main use case for importantForAccessibility I am thinking about here is just not breaking peoples' current applications. We started making the accessibility API in this way, so unless there's a really good reason we should keep doing it in this way. Would it be possible to just make it work on iOS without doing a deprecation / migration sort of thing?

The reason for that is because importantForAccessiblity is a superset of accessiblityElementsHidden so impossible to make it crossplatfrom in a consistent way.
In detail; It is not possible to have a consistent importantForAccessiblity because on iOS, accessiblityElementsHidden is a boolean which corsponds to Android's importantForAccessiblity values yes (accessibilityElementsHidden=false) and noHideDescendants (accessibilityElementsHidden=true). However, iOS has no equivalent for importantForAccessiblity=auto and importantForAccessiblity=no.

Hmm. OK, unfortunately that leaves me in the situation of being strongly suspicious this is not the right way to solve the problem, but not being sure what the right way is to give you some helpful direction.

It may not be the prefect solution but I doubt anyone is using auto or no, or that their requirement couldn't be handled with yes and noHideDescendants which is provided by accessiblityElementsHidden.
Regardless, It is worth considering that as it stands, every react-naitve app that use navigation-experimental on iOS is embrassingly unaccessable from a VoiceOver point of view, to draw a parallel, it is so bad that is on par with having  opacity: 0.5 set for every component from a visual point of view.

@lacker regarding your previous comment

Another issue is that we intend to deprecate NavigationExperimental, so we are trying to avoid adding any more functionality there.

That makes sense but I believe the problem is bigger than NavigationExperimental.  Because of your above comments I tried react-navigation and found it too has the same accessibility problem.
Since iOS doesn't have an equivalent to android's importantForAccessibility prop exposed to the js layer I don't think these navigation libraries can do anything about this short of rendering one screen at a time.
My understanding is that while react-navigation is still in beta it's going to be the recommended approach going forward for navigation.  If so this PR or something similar will be required to make ADA compliant apps on iOS.
If not this approach do you have any suggestions on which approach to take?  Expose accessibilityElementsHidden for iOS only and leave importantForAccessibility android only?

The main use case for importantForAccessibility I am thinking about here is just not breaking peoples' current applications.

Generally I agree, but seems deprecating looks like the best option here. We usually have almost 3-4 months before finally removing the feature, so I believe people will have enough time to do it. Also isn't this just a quick search and replace?

If not this approach do you have any suggestions on which approach to take? Expose accessibilityElementsHidden for iOS only and leave importantForAccessibility android only?

I think it's not good to introduce more fragmentation in the APIs.

@omeid Are you sure that your implementation of accessibilityElementsHidden behaves the same on iOS and Android? I see a couple of potential inconsistencies:

The doc comment for the accessibilityElementsHidden prop says true means that the view and all of its descendants are hidden. However, Apple's docs say true hides the descendants but not the view.
The doc comment for the accessibilityElementsHidden prop makes it sound like null (default) means the OS uses heuristics to determine whether or not the view should be hidden. However, Apple's docs say the default value is false.

Do you know how iOS determines what is visible to the screen reader? For example, is a View with opacity 0 visible to the screen reader? As of commit https://github.com/facebook/react-native/commit/54beee261667539d0314abc6bc39363784e41e37 (RN 39) the NavigationExperimental now sets the opacity of the previous page to 0 (previously it was 0.3). The commit was intended to reduce overdraw on Android but I'm wondering if it also happened to make the previous page invisible to the iOS and Android screen readers.

@rigdern

The doc comment for the accessibilityElementsHidden prop says true means that the view and all of its descendants are hidden. However, Apple's docs say true hides the descendants but not the view.

The documentation could be improved, however it is not inconsistent from Android, as we use importantForAccessiblity=noHideDescendants on Android, which is functionally identical.

The doc comment for the accessibilityElementsHidden prop makes it sound like null (default) means the OS uses heuristics to determine whether or not the view should be hidden. However, Apple's docs say the default value is false.

Android does some heuristics, for example --it considers opacity-- but iOS does not, it is still the OS decisions though.

Do you know how iOS determines what is visible to the screen reader? For example, is a View with opacity 0 visible to the screen reader? As of commit 54beee2 (RN 39) the NavigationExperimental now sets the opacity of the previous page to 0 (previously it was 0.3). The commit was intended to reduce overdraw on Android but I'm wondering if it also happened to make the previous page invisible to the iOS and Android screen readers.

On Android, opacity 0 actually does help with accessibility as the default importantForAccessiblity=auto considers it, on iOS, it makes no difference.

@omeid, thanks for the response.

The doc comment for the accessibilityElementsHidden prop says true means that the view and all of its descendants are hidden. However, Apple's docs say true hides the descendants but not the view.

The documentation could be improved, however it is not inconsistent from Android, as we use importantForAccessiblity=noHideDescendants on Android, which is functionally identical.

After looking at the iOS and Android docs, it sounds to me like the prop works differently on iOS and Android for accessibilityElementsHidden=true:

iOS: The descendants are hidden
Android: The descendants and the view are hidden

Do you agree?

After looking at the iOS and Android docs, it sounds to me like the prop works differently on iOS and > Android for accessibilityElementsHidden=true:

iOS: The descendants are hidden
Android: The descendants and the view are hidden

Do you agree?

No. Please see the implementation; on Android accessibilityElementsHidden=true corresponds to importantForAccessiblity=noHideDescendants, on iOS it corresponds to accessibilityElementsHidden=true, the fact that it has the same name on iOS is merely conventional.

@omeid I'm confused about which part of my statement you disagree with. Let's take a step back.
The following is my understanding of how your PR works. When the prop accessibilityElementsHidden is true:

On iOS: the descendants are hidden
On Android: the descendants and the view are hidden

Do you agree with this? If not, can you edit my above description to correct it?

Why do you think importantForAccessiblity=noHideDescendants would hide the view as well? Please read the code.

@omeid My understanding that it'll hide the view as well came from reading the Android docs for IMPORTANT_FOR_ACCESSIBILITY_NO_HIDE_DESCENDANTS: https://developer.android.com/reference/android/view/View.html#IMPORTANT_FOR_ACCESSIBILITY_NO_HIDE_DESCENDANTS

You are right, it will hide the view as well, and as I have been using this for High Order Components I have overlooked that difference.
Can you provide an example where this inconsistency would result in inconsistent accessibility behaviour so that me and those interested could look for a solution?

To rigdern's point if accessibilityElementsHidden={true} is set on a touchable element, according to what previously was discussed in this PR and RN documentation

accessible (iOS, Android)
When true, indicates that the view is an accessibility element. When a view is an accessibility element, it groups its children into a single selectable component. By default, all touchable elements are accessible.

while the children and Android touchable element will not be accessible the iOS touchable element will be. (not tested)
What if this PR updates accessible to default to false on touchable elements (and anything else defaulting accessible to true) when accessibilityElementsHidden={true}?

@sdg9 I think that is adding too much complexity and making assumptions about developers caring enough about accessibility to set the correct values, setting touchable elements to false will break many multi-cell touchable-(row/list item) components that are fairly common. It will also break many Appium driven tests for said components.

I think a better solution is to also set isAccessibilityElement to reflect accessibilityElementsHidden on iOS to make it react-native's accessibilityElementsHidden behave the same on both iOS and Android: Hide the element and it's children.
Thoughts? Hints on implementation reference to follow?

@omeid just to be clear I threw out the idea to defaultaccessible={false} on touchable elements ONLY WHEN accessibilityElementsHidden={true} to behave consistent with android.  If accessibilityElementsHidden isn't true toucahble elements would still default accessible={true}.
I agree this would be confusing though.  Basically ADA docs on accessible would say

By default, all touchable elements are accessible... except when they're not.

My use case is like yours I only care about this at the screen level so the difference in behavior between Android and iOS is a non-issue as I'm setting accessibilityElementsHidden on a View or ScrollView.

@sdg9 Alright, I must have misunderstood your comment then.
So one solution is to sync isAccessibilityElement  and accessibilityElementsHidden on iOS with react-native's accessibilityElementsHidden, which is trivial.
However, what happens to accessible?
Mark accessible and ``accessibilityElementsHidden` as conflicting?

Can you provide an example where this inconsistency would result in inconsistent accessibility behaviour so that me and those interested could look for a solution?

@omeid I don't have a specific real world scenario to share. Given our understanding of the inconsistency of the prop implementations, it shouldn't be too hard to make a contrived one. Whatever solution we end up with here, the prop should have consistent behavior across iOS and Android.
Instead of introducing accessibilityElementsHidden, have you considered implementing importantForAccessibility for iOS? Based on the discussion here, it sounds like the implementation would look like this:

When importantForAccessibility is 'yes':

isAccessibilityElement = true
accessibilityElementsHidden = false

When importantForAccessibility is 'no':

isAccessibilityElement = false
accessibilityElementsHidden = false

When importantForAccessibility is 'no-hide-descendants':

isAccessibilityElement = false
accessibilityElementsHidden = true

When importantForAccessibility is 'auto' or nulll:

Revert isAccessibilityElement  and accessibilityElementsHidden to their default values.

This would avoid us having to deprecate importantForAccessibility.

That is doable, however, the question of what happens to accessible prob remains. The accessible prob on iOS is effectively isAccessibilityElement. Deprecate it? as it doesn't exist on Android anyways.

Heads up @omeid and @rigdern I was playing around with the following

When importantForAccessibility is 'yes':

isAccessibilityElement = true
accessibilityElementsHidden = false

and see some unexpected behavior.  Setting isAccessibilityElement to true in iOS will make the View accessible but you cannot drill down into children that should otherwise be accessible (tested on simulator using accessibility inspector).  In android children remain accessible.
This technically would be a breaking change as people using yes may need to switch to no or auto/null to retain existing functionality in iOS.

what happens to accessible prop

@omeid That's a great question. Given the implementation I mentioned above, the functionality of accessible and importantForAccessibility overlap on iOS. But on Android, accessible and importantForAccessibility have no overlap in functionality. This inconsistency in how the props work between iOS and Android is not ideal.
@sdg9 mentioned that the implementation of importantForAccessibility that I proposed above results in inconsistent behavior between iOS and Android:

iOS will make the View accessible but you cannot drill down into children ... In android children remain accessible.

It sounds to me like we need to more deeply understand the iOS and Android accessibility APIs. Then we can use that understanding to implement accessibility props in React Native that offer consistent behvavior across iOS and Android.

Consistent behaviour is really important, what is more important is that there exists some/any mechanism that allows one to write reasonably accessible Apps.
I think over 6 months of bike-shedding on this issue while hundreds to thousands react-native apps that are completely inaccessible are deployed is pretty inconsiderate.
The semantics of accessibility is different on iOS and Android, by the virtue of this difference, it maybe necessary to make some compromises and work the solution out by way of an experimental APIs phase.
Also, on iOS, an accessible element can not have accessible children, so when you set accessibleElementsHidden=true, it is assumed that the element is not accessible, which is exactly what happens in Android with importantForAccessiblity=noHideDescendants.
So the objection to this pull request being inconsistent is merely a question of difference in semantics, unless, you can provide an example where this inconsistency is manifested in a difference in accessible behaviour.

@omeid I feel your pain

what is more important is that there exists some/any mechanism that allows one to write reasonably accessible Apps.

At the end of the day all I need to be able to do is set iOS's native property accessibilityElementsHidden=true as it will resolve NavigationExperimental's ADA issue and react-navigation's ADA issue.  It is logical to align with importantForAccessibility="no-hide-descendants" but I think we have to align the iOS and Android behavior around "yes" first.
To summarize the current implementation

React Native
iOS
Android

accessible
isAccessibilityElement
setFocusable

importantForAccessibility
N/A
importantForAccessibility

and not implemented but discussed

React Native
iOS
Android

accessibilityElementsHidden
accessibilityElementsHidden
N/A

iOS has two booleans to work with: isAccessibilityElement and accessibilityElementsHidden
Android has importantForAccessibility accepting 4 different inputs.
It sounds logical to map the permutations of iOS's 2 booleans to Android's 4 inputs thus avoiding fragmentation in the react native apis.
Then we discovered

on iOS, an accessible element can not have accessible children

which is NOT how Android behaves when setting importantForAccessibility="yes".
I believe we can alter the suggestion from @rigdern to achieve consistent behavior between platforms by using iOS's default value for isAccessibilityElement when setting importantForAccessibility="yes".
After all Android's docs do not say that importantForAccessibility="yes" makes the view accessible but rather

The view is important for accessibility.

This would mean React Native's importantForAccessibility prop would never set iOS's isAccessibilityElement=true.  If we ever explicitly wanted to set a view as accessible we'd still need to set the accessible=true prop.

when can we expect accessibilityElementsHidden prop implemented ?
or is there any workaround to hide the accessibility label of previous screens ?
Thanks!

@omeid It'd be great if you could take a look at this, accessibility should be a real priority

@kirankalyan5 and anyone else still waiting on this as a workaround I found that maintaining my own  React Native fork with this single commit was sufficient for my use case.  Now importantForAccessibility works and behaves as I want in iOS builds.  No more iOS ADA bleed through to previous pages!
I just do something like
importantForAccessibility={this.props.isActive ? 'yes' : 'no-hide-descendants'}

to each card (using react-navigation) so they know when to be accessible or not.

@sdg9 where's isActive coming from? I don't believe react-navigation supports this yet when pushing cards onto a navigation stack

@lprhodes I will be starting a new react native project in a couple of days and will try to chase this again. I agree, this is a massive problem for a18y.

@lprhodes isActive is defined in react-navigation on the scene
I actually had to then pass it to my SceneView in CardStack.  I couldn't use theirs straight up so I made my own tweak changing
      <SceneView
        screenProps={this.props.screenProps}
        navigation={navigation}
        component={SceneComponent}
      />

to
      <SceneView
        screenProps={this.props.screenProps}
        navigation={navigation}
        component={SceneComponent}
        isActive={scene.isActive}
      />

So in summary in CardStack I had to pass isActive down to the SceneView, and in the Card I had to then use that isActive (on the view) to set importantForAccessibility properly.  Combine that change in react-navigation with this react-native commit I maintain, voila I have accessibility working properly without pages on the back stack showing through.

Thanks @sdg9, that was the missing piece I was looking for. Unfortunately all tabs appear to be active, do you use a work-around for that?

@lprhodes in my use case I don't use TabNavigator, only StackNavigator, so unfortunately I cannot comment on that.

Hi there,
we tried implementing the solution you described above (thanks @sdg9 for your help) but setting the importantForAccessibility={this.props.scene.isActive ? 'yes' : 'no-hide-descendants'} was not enough for not leaking the touch interactions: when more then one scene was rendered, the touch interaction would be captured by both the active and inactive scenes.
Since our app is highly focused on handling the accessibility for unpaired users, we opted for changing the _renderCard function in the react-navigation/src/views/CardStack/CardStack.js:
_renderCard = (scene: NavigationScene): React.Node => {
    const { screenInterpolator } = this._getTransitionConfig();
    const style = screenInterpolator && screenInterpolator({ ...this.props, scene });

    const SceneComponent = this.props.router.getComponentForRouteName(scene.route.routeName);
    // We do not render the views down the stack except the active one.
    // Be aware that this is an horrible solution for fixing the leaking touch interactions
    // that break the accessibility.
    if (!scene.isActive) {
      return <View key={`card_${scene.key}`} />;
    }
    return (
      <Card
        {...this.props}
        key={`card_${scene.key}`}
        style={[style, this.props.cardStyle]}
        scene={scene}
        importantForAccessibility={scene.isActive ? 'yes' : 'no-hide-descendants'}
        accessible={false}
      >
        {this._renderInnerScene(SceneComponent, scene)}
      </Card>
    );
  };

Hope it helps.
cc @andreatosatto90

+1

This PR could be closed as functionality you are trying to add is already implemented in master:
https://github.com/facebook/react-native/commit/31288161e188723456fdb336c494f3c8a3f5b0a8

Unfort because of lack traction with landing this issue and me having moved on from react-native for a while now. I am going to close it.


How to get started ?

Support Question
I am interested to learn about glue and also contribute.
Looking at the README or other available documentation, it is not clear how to deploy it ?
It is also not clear what other tools can you integrate this with or how to use it ?
Can you please give some pointers to get started ?
Thanks,
-- Hemant

Thanks Ana !! This is helpful.
So, what type of contribution are you looking for in the project ?
Thanks,
-- Hemant

Any type of contribution is welcome. It can be either suggesting optimization of the model, adding new domains, or clarifying definitions that are covered by the model.
Best,
Ana


Added namespaced factory

Codecov Report

Merging #54 into master will decrease coverage by 0.36%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master      #54      +/-   ##
==========================================
- Coverage   22.23%   21.87%   -0.37%
==========================================
  Files          36       37       +1
  Lines         652      663      +11
==========================================
  Hits          145      145
- Misses        507      518      +11

Impacted Files
Coverage Δ

src/Factory/NamespacedFactory.php
0% <0%> (ø)

Continue to review full report at Codecov.

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


Design fixes (issue fixed for sidebar,dashboard and api configuration component)

This looks good to me. Merging it. Thanks!

Thanks For your contribution!


Initialise elastic search as part of a standard deployment

Elastic search in a specific version should be initialised as part of the deployment of the backend.
This means that the correct elastic search load file should be part of the backend ontology read on startup.
This issue is dependent on this issue of the fhir-ontology-generator: https://github.com/medizininformatik-initiative/fhir-ontology-generator/issues/29

Just to clarify...is the following assumption correct?

The files necessary to create the index in elastic search and then fill it with the current (at that point of time) documents will be included in the backend.zip file from the ontology generator
Those files will be packaged with the docker image (equivalent to the database migration script containing the ui profiles)
On startup, it will be checked if the index is present and at the exact same version - if not, it will be (if necessary) deleted and newly created? Or will it throw an error and deny starting?
There will not be a download of those files during backend startup
Changes to the elastic search index will require new images to be built and deployed. (Not the changes to the availability, but to the mapping or general content)

yes
yes
delete and create new
yes
yes


Rework Testing Location

This PR is meant to aid with #885. Also Closes #870. This is what is does:

moves Tests to root dir
moves test targets from Demo.xcworkspace to Moya.xcodeproj
switches CircleCI to run tests from the main project
adds a CircleCI task to build the Demo project
greatly speeds up build time by caching carthage builds
fixes an error where rake test:carthage wasn't actually testing the current commit

Current coverage is 87.98% (diff: 100%)

Merging #886 into master will increase coverage by 12.98%

@@             master       #886   diff @@
==========================================
  Files            19         34     +15
  Lines           688       2696   +2008
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits            516       2372   +1856
- Misses          172        324    +152
  Partials          0          0

Powered by Codecov. Last update c1fb3fa...8540e3a

What I understand from this is

You moved the tests into Moya.xcodeproj
You actually got the tests to run & updated Rake things, and cocoapods things, and implemented caching

If we could cherrypick all the 2 commits from this branch onto redo-spm-layout, and then merge the PR into #885, then we'll have this PR done, and 2/3 of the TODOs on #855 done as well

It's a little bit more than that. Let me take a stab at combining them. I know how to make the changes again. I'll push the commits right to your branch.

awesome, I'll take a look 👍

I've deleted the branch; please restore if needed!

All good. Thanks. Uneeded now.


[WIP] archives: Add endpoint to fetch topic history of web public streams.

In this PR we basically work on adding the topics backend for public archives. It is really gonna be just an endpoint which can return topics history for web public streams without need for authentication!
Currently PR contains 2 commits to get stuff done in this direction.
<2nd commits message>
In this commit we add a new endpoint so as to have a way of fetching
topic history for a given stream id without having to be logged in.
This can only happen if the said stream is web public otherwise we
just return an empty topics list. This endpoint is quite analogous
to get_topics_backend which is used by our main web app.
In this commit we also do a bit of duplication regarding the query
responsible for fetching all the topics from DB. Basically this
query is exactly the same as what we have in the
get_topic_history_for_stream function in actions.py. Basically
duplicating now is the right thing to do because this query is
really gonna change when we add another criteria for filtering
messages which is:
Only topics for messages which were sent during the period the
corresponding stream was web public should be returned.
Now when we will do this, the query will change and thus it won't
really be a code duplication!

@adnrs96 thanks for working on this!  I posted a few comments and merged the first commit.

@timabbott I updated this. Can you please take a look. Thanks!

Merged, after rewriting the second commit as bf1ad714da3487d6f1a1d6056683e73fc5ea5dea to be correct and to actually test the corner cases in question.  Thanks @adnrs96!


macOS: media capture permission missing

Description
I'm trying to capture output from a virtual camera with OpenCV, however there seem to be some permissions missing: https://developer.apple.com/documentation/avfoundation/cameras_and_media_capture/requesting_authorization_for_media_capture_on_macos?language=objc
Area for Triage:

Apple
Question, Bug, or Feature?:
Bug
Virtual environments affected

[ ] Ubuntu 16.04
[ ] Ubuntu 18.04
[ ] Ubuntu 20.04
[x] macOS 10.15
[ ] macOS 11.0
[ ] Windows Server 2016 R2
[ ] Windows Server 2019

Image version

20210510.1
Expected behavior
macOS should not interactively ask for permissions in CI.
Actual behavior
Not sure, but likely a permission prompt pops up.
Repro steps
Install OBS (or just the virtual camera with https://github.com/letmaik/pyvirtualcam/blob/master/.github/scripts/install-macos-obs-virtual-cam.sh), then run:
# pip install opencv-python
import cv2
vc = cv2.VideoCapture(0)
assert vc.isOpened()

Linked: https://github.com/opencv/opencv/issues/20094 https://github.com/opencv/opencv-python/issues/291

Hello @letmaik,
We will investigate the issue.

Hello @letmaik,
Unfortunately, at this time it's not possible to prove required permissions on agent machines, since there is no way to accept pop-up window with permissions access. We had similar request, but could not find any suitable solution for this. Maybe you have ideas or a probable solution for this?
We are looking forward to your reply.

@letmaik I'm going to close the issue.
If additional assistance is required, do not hesitate to contact us.

I understand there may not be an immediate solution but it is still an unresolved issue. Why not keep the issue open? Other CI providers seem to have resolved this issue, and I'd rather not switch away from GitHub Actions because of this.

@letmaik Unfortunately, at this time, we made a decision to keep System Integrity Protection enabled on our macOS images( please refer the link for more information). However, with SIP enabled, it is not possible to automatically accept a security pop-up window.


Bump golang/x/net from v0.22.0 to v0.24.0

Mitigates https://pkg.go.dev/vuln/GO-2024-2687
[skip codecov]

Also bumps crypto.

Also bumps crypto.

Yeah, x/net must depend on x/crypto - I did go get golang.org/x/net and crypto came along for the ride. :cowboy_hat_face:


[WIP][OSD-6506] Refactor Account Reuse Logic

OSD-6506

Refactor Account Reuse Logic
Refactored chunks of AccountController reconcile loop into smaller functions
Split IAM code found here into its own separate PR to make reviewing easier - will rebase this PR once other is merged

the PR has a WIP label, is that still valid?

Codecov Report

Merging #596 (6d5d186) into master (577cc09) will decrease coverage by 0.59%.
The diff coverage is 3.84%.

@@            Coverage Diff             @@
##           master     #596      +/-   ##
==========================================
- Coverage   19.71%   19.11%   -0.60%
==========================================
  Files          46       46
  Lines        4373     4437      +64
==========================================
- Hits          862      848      -14
- Misses       3457     3537      +80
+ Partials       54       52       -2

Impacted Files
Coverage Δ

pkg/controller/account/account_controller.go
4.74% <0.00%> (-0.51%)
:arrow_down:

pkg/controller/account/byoc.go
35.06% <0.00%> (ø)

pkg/controller/account/ec2.go
0.00% <0.00%> (ø)

pkg/controller/account/iam.go
52.50% <0.00%> (-1.01%)
:arrow_down:

pkg/controller/accountclaim/reuse.go
32.32% <0.00%> (-2.22%)
:arrow_down:

...ountaccess/awsfederatedaccountaccess_controller.go
0.00% <0.00%> (ø)

...controller/accountclaim/accountclaim_controller.go
5.92% <7.86%> (-2.25%)
:arrow_down:

test/fixtures/clientErrors.go
50.00% <0.00%> (-50.00%)
:arrow_down:

pkg/controller/utils/utils.go
43.54% <0.00%> (-3.23%)
:arrow_down:

... and 2 more

/lgtm


Default values are completely removed for Avro Records with Union fields

This issue appears to have been introduced with Issue #88 which resolves issues with default values and union fields, however when a record has a field of union type all default values are removed and set to null in the resultant schema. For instance, I have a schema such as:
{
      "namespace": "avro",
      "type": "record",
      "name": "UnionRecord",
      "fields": [
          {
              "name": "union_field",
              "type": ["null", "string"],
              "default": null
          }, {
              "name": "int_field",
              "type": "int",
              "default": 5
          }
      ]
}

When pulling this in from the schema registry the field 'int_field' no longer has the default value so any migrations from old schemas are failing as a result. The default value is in the schema when looking at the schema registry UI as well as while tracing through the code it is pulled down and shows up in the schema up until the schema is processed through the com.hortonworks.registries.schemaregistry.avro.AvroSchemaResolver#handleUnionFieldsWithNull method at which point the returned schema has lost the default value for the "int_field".
The actual issue appears to be related to this line:
updatedFields.add(new Schema.Field(field.name(),
                                                   fieldSchema,
                                                   field.doc(),
                                                   currentFieldTypeIsUnion ? NullNode.getInstance() : null,
                                                   field.order()));

However if I change it to
updatedFields.add(new Schema.Field(field.name(),
                                                   fieldSchema,
                                                   field.doc(),
                                                   currentFieldTypeIsUnion ? NullNode.getInstance() : field.defaultValue(),
                                                   field.order()));

everything appears to work correctly again.

@enoren your logic change seems sensible for me, are you able to raise a PR?

@michaelandrepearce Done - https://github.com/hortonworks/registry/pull/301

Raised/merged #309 for adding tests