Sampling error in tests

🐞 Problem
I have recently started to get a weird error after running pytest.

        This is a :class:`~astropy.units.Quantity`-aware version of
        :func:`numpy.testing.assert_allclose`.
        """
        import numpy as np
        from astropy.units.quantity import _unquantify_allclose_arguments
>       np.testing.assert_allclose(*_unquantify_allclose_arguments(
            actual, desired, rtol, atol), **kwargs)
E       AssertionError:
E       Not equal to tolerance rtol=1e-07, atol=1e-14
E
E       Mismatched elements: 1 / 1 (100%)
E       Max absolute difference: 1.02749662e-14
E       Max relative difference: 1.63661977
E        x: array(-3.996803e-15)
E        y: array(6.278163e-15)

../poli/lib/python3.8/site-packages/astropy/tests/helper.py:491: AssertionError
----------------------------------------------------------------------------- Hypothesis -----------------------------------------------------------------------------
Falsifying example: test_sample_closed_starts_and_ends_at_min_anomaly_if_in_range_and_no_max_given(
    min_nu=<Quantity 6.2781633e-15 rad>, ecc=<Quantity 0.99161489>,
)

Ouput of pip freeze:

alabaster==0.7.12
anyio==2.0.2
apipkg==1.5
appdirs==1.4.4
argon2-cffi==20.1.0
astroid==2.4.2
astropy==4.2
astropy-sphinx-theme==1.1
astroquery==0.4.1
async-generator==1.10
attrs==20.3.0
Babel==2.9.0
backcall==0.2.0
beautifulsoup4==4.9.3
black==20.8b1
bleach==3.2.1
certifi==2020.12.5
cffi==1.14.4
chardet==4.0.0
click==7.1.2
cognitive-complexity==1.2.0
colorama==0.4.4
confuse==1.4.0
coverage==5.3.1
cryptography==3.3.1
cycler==0.10.0
czml3==0.5.4
decorator==4.4.2
defusedxml==0.6.0
distlib==0.3.1
docutils==0.16
entrypoints==0.3
execnet==1.8.0
filelock==3.0.12
flake8==3.8.4
flake8-cognitive-complexity==0.1.0
flake8-polyfill==1.0.2
flit==3.0.0
flit-core==3.0.0
future==0.18.2
html5lib==1.1
htmlmin==0.1.12
hypothesis==6.0.1
idna==2.10
ImageHash==4.2.0
imagesize==1.2.0
iniconfig==1.1.1
ipykernel==5.4.3
ipython==7.19.0
ipython-genutils==0.2.0
ipywidgets==7.6.3
isort==5.7.0
jedi==0.18.0
jeepney==0.6.0
Jinja2==2.11.2
joblib==1.0.0
jplephem==2.15
json5==0.9.5
jsonschema==3.2.0
jupyter-client==6.1.11
jupyter-core==4.7.0
jupyter-server==1.2.1
jupyterlab==3.0.4
jupyterlab-pygments==0.1.2
jupyterlab-server==2.1.2
jupyterlab-widgets==1.0.0
jupytext==1.9.1
keyring==21.8.0
kiwisolver==1.3.1
lazy-object-proxy==1.4.3
llvmlite==0.35.0
mando==0.6.4
markdown-it-py==0.6.1
MarkupSafe==1.1.1
matplotlib==3.3.3
mccabe==0.6.1
mdit-py-plugins==0.2.4
missingno==0.4.2
mistune==0.8.4
mypy==0.790
mypy-extensions==0.4.3
myst-parser==0.13.3
nbclassic==0.2.6
nbclient==0.5.1
nbconvert==6.0.7
nbformat==5.0.8
nbsphinx==0.8.0
nest-asyncio==1.4.3
networkx==2.5
nodejs==0.1.1
notebook==6.1.6
NotFound==1.0.2
npm==0.1.1
numba==0.52.0
numpy==1.20.0
numpydoc==1.1.0
optional-django==0.1.0
packaging==20.8
pandas==1.2.0
pandoc==1.0.2
pandocfilters==1.4.3
parso==0.8.1
pathspec==0.8.1
patsy==0.5.1
pexpect==4.8.0
phik==0.11.0
pickleshare==0.7.5
Pillow==8.1.0
plotly==4.14.3
plotly-express==0.4.1
pluggy==0.13.1
ply==3.11
poliastro==0.15.dev0
prometheus-client==0.9.0
prompt-toolkit==3.0.10
ptyprocess==0.7.0
py==1.10.0
pycodestyle==2.6.0
pycparser==2.20
pyerfa==<IP_ADDRESS>
pyflakes==2.2.0
Pygments==2.7.4
pyparsing==2.4.7
pyrsistent==0.17.3
pytest==6.2.2
pytest-cov==2.5.1
pytest-doctestplus==0.9.0
pytest-mpl==0.12
pytest-mypy==0.8.0
pytest-remotedata==0.3.2
python-dateutil==2.8.1
pytoml==0.1.21
pytz==2020.5
PyWavelets==1.1.1
PyYAML==5.3.1
pyzmq==20.0.0
radon==4.3.2
regex==2020.11.13
requests==2.25.1
retrying==1.3.3
scipy==1.6.0
seaborn==0.11.1
SecretStorage==3.3.0
Send2Trash==1.5.0
six==1.15.0
sniffio==1.2.0
snowballstemmer==2.0.0
sortedcontainers==2.3.0
soupsieve==2.1
Sphinx==3.4.3
sphinx-astropy==1.3
sphinx-autoapi==1.5.1
sphinx-automodapi==0.13
sphinx-gallery==0.8.2
sphinx-hoverxref==0.5b1
sphinx-notfound-page==0.6
sphinx-rtd-theme==0.5.0
sphinxcontrib-applehelp==1.0.2
sphinxcontrib-devhelp==1.0.2
sphinxcontrib-htmlhelp==1.0.3
sphinxcontrib-jsmath==1.0.1
sphinxcontrib-qthelp==1.0.3
sphinxcontrib-serializinghtml==1.1.4
statsmodels==0.12.1
tangled-up-in-unicode==0.0.6
Tcl==0.2
terminado==0.9.2
testpath==0.4.4
toml==0.10.2
tornado==6.1
tox==3.21.1
tqdm==4.56.0
traitlets==5.0.5
typed-ast==1.4.2
typing-extensions==<IP_ADDRESS>
Unidecode==1.1.2
urllib3==1.26.2
virtualenv==20.3.1
visions==0.6.0
w3lib==1.22.0
wcwidth==0.2.5
webencodings==0.5.1
widgetsnbextension==3.5.1
wrapt==1.12.1

📋  Steps to solve the problem
Investigate tests, specifically focusing on what eccentricities are being used to test them.
Notes

The error traceback clearly states that we use falsifying examples for testing. Specifically, the problem seems to be in the eccentricity used: 0.99161489 (giving -3.996803e-15 as the final true anomaly) where instead it must have used 0.88680956 which would have yielded a correct final true anomaly (6.278163e-15). See the test here
This mostly seems to be a problem in the testing part of the code and not in the source code implementation.
I am currently investigating the cause and am not sure if this is only me or if it is really a bug.

Please let me know if this is really a problem.
Thanks!!

Hi @Yash-10, I tested locally and was not able to get any kind of error, all unit tests were passing... The CI do not show any error neither. Could you please try to update your local repository to main one and check if this still happens to you?

Note that hypothesis tests a random combination of parameters every time, intelligently using this combination. And if it finds 1 combination that makes the test fail, it will save it to reproduce in the future. So, this test failure that you reported my be legitimate, but you will need to add it as an example: https://hypothesis.readthedocs.io/en/latest/reproducing.html?highlight=example#hypothesis.example

Thanks @astrojuanlu adding it as an @example does solve the error. Although I was able to resolve the error by adding it as an example earlier, I was not sure if this error had some bigger implications.
So the learning is that: If we get an AssertionError for hypothesis due to a falsifying example, add it as an example so that hypothesis would not go on to check other examples not listed in your examples.
Now it seems to be resolved, thanks again for pointing out!
I would close this issue now....

So, adding it as example fixed it? That's... Not what I expected 🤔 I thought that it would keep failing until we addressed it. Will try it locally in case I can reproduce it.

Sorry for late reply @astrojuanlu I was too fast to come to a conclusion. Adding @example still gives the error, as expected, it had solved the error by adding a slightly different set of combinations as an example, not the one that currently gives the error.
Some preliminary analysis:

Changing the atol argument solves the error locally:

+ assert_quantity_allclose(result[0], min_nu, atol=1.2e-14 * u.rad)
+ assert_quantity_allclose(result[-1], min_nu, atol=1.2e-14 * u.rad)

- assert_quantity_allclose(result[0], min_nu, atol=1e-14 * u.rad)
- assert_quantity_allclose(result[-1], min_nu, atol=1e-14 * u.rad)

but there probably needs to be a better fix for this. But since hypothesis uses random combinations of parameters, it might make sense to just change the atol argument in such cases because this doesn't signify issues with implementation accuracies but rather setting an unrealistic atol.
I tried to plot the absolute differences of result[0] and result[-1] which theoretically must be the same and practically under the limit set by atol.

For ecc = 0.88680956:

The values inside the list are the absolute differences, and the graph just plots them. As expected, all are below 1e-14.

For ecc = 0.99161489

As can be seen, min_nu's between 6e-15 and 7e-15 shoot the difference above 1e-14,
Hopefully not an overkill, but a plausible fix could be to set an atol value slightly higher than the highest difference we get by plotting such graphs because even 1.2e-14 could fail for some situations. Moreover, this process needs to be repeated for many eccentricities to be sure that this error doesn't occur anymore.
I had seen this error come up during some CI routines too.
What do you think @astrojuanlu ? Please correct me if I am not interpreting anything appropriately.
Thanks!

As can be seen from the merging of a recent PR, such unrelated sampling errors do occur sometimes. For example, see here.
This issue probably needs some investigation.
@astrojuanlu Does the above analysis support the process of fixing such errors. If not, I will dive deep into understanding hypothesis and try to find a solution for this issue :)

@Yash-10 it's great analysis indeed! I think we have enough information at least to start. Perhaps, as you say, having a slightly larger atol is enough. But the plots are greatly appreciated anyway 😍

Hello @astrojuanlu I have further analyzed the problem:
The mismatch between min_nu before and after sampling the orbit seems to increase rapidly as the eccentricity of the orbit reaches closer to 1. To confirm this, I tried to plot the variation of the absolute difference of the min_nu's.

The eccentricities used are: [0.5, 0.8, 0.9, 0.99, 0.999, 0.9999]. As seen, the difference has already shooted 4e-14. As one would expect, as eccentricity becomes exactly 1 (ecc=1 => parabolic orbit), we would get a division by zero error.
Taking the eccentricity to the maximum possible value (as per the limitations of numerical precision: ecc=0.9999999999999999), the difference reaches 3.287386274308801e-08 which is ~1e7 times the expected difference.
As a result, it seems that just changing atol is not a good choice. I noticed some issues that deal with a related concept: for example in #908, there's already a lot of discussion done, although I would have to take a closer look to understand the details presented there.
Well, now it could be a non-trivial problem and the corresponding fix more involved.

Oh wow, near-parabolic orbits there we go again... 😱
This is an excellent investigation, thanks for taking the time to dig into this. I'm so happy that we are using hypothesis to surface these sort of problems. Will give this some thought over the weekend, if anyone has more ideas feel free to share here.

I was looking at this note: https://arc.aiaa.org/doi/10.2514/3.49468, although I am skeptical of the relevance here, but there's a line which says:

For near parabolic orbit, E and H are small and a direct computation is sensitive to error.

Plot
Eccentricities used: [0.3, 0.5, 0.8, 0.9, 0.99, 0.999, 0.9999, 0.999999, 0.99999999, 0.999999999]

From this, what I started to think is that the errors might be because of the way eccentric anomaly (E) is calculated currently i.e. using the half-angle formula. From the formula:

If the true anomaly is 0, then the eccentric anomaly is exactly 0 1, irrespective of the closeness of ecc to 1. As a result, getting sampling errors for orbits with nu = 0 * u.rad is mostly not going to be a problem.

Moreover, the problem could be in cases where:

The true anomaly (nu) is close to zero.
The eccentricity (e) is close to 1.

because each of them will contribute in making the eccentric anomaly close to zero.
If both 1 and 2 are satisfied, then it's highly likely to get errors in sampling. This can be verified from the falsifying example while testing that started this discussion:
min_nu=<Quantity 6.2781633e-15 rad>, ecc=<Quantity 0.99161489>

Here, min_nu is very close to 0 and ecc is very close to 1.
So, could this be a potential place to investigate @astrojuanlu ? Please correct me if I have interpreted something incorrectly.
Thanks!
Footnotes

Although nu = 0 could imply the eccentric anomaly to be either 0 or pi, np.arctan returns values only in the range [-pi/2, +pi/2] => According to me, we will get 0 always and never pi.

Would it be better to use np.arctan2 instead of np.arctan since np.arctan2 returns values in the range [-pi, +pi] whereas np.arctan doesn't?

I noticed some related logic that was probably introduced in #908 (here) where the mean anomaly is recalculated if the orbit is near-parabolic and then nu is calculated. So I would need to take a look at the discussion there, to understand why this was done. Looks interesting!
# Near parabolic, recompute M
n = np.sqrt(k / (2 * q ** 3))
M = n * delta_t
D = M_to_D_near_parabolic(M, ecc)
nu = D_to_nu(D)

@astrojuanlu Could you let me know your thoughts on the above analysis?
Thanks!

I was looking at this note: https://arc.aiaa.org/doi/10.2514/3.49468

Nice! I didn't know about this paper.
Our treatment of near-parabolic orbits is based on Farnocchia et al "Robust resolution of Kepler’s equation in all eccentricity regimes" https://doi.org/10.1007/s10569-013-9476-9 . If you want to understand what's happening there, it's very important that you read that paper carefully. After a lot of effort we managed to get this right in #908 and its follow-ups (thanks to the pandemic!)

Bear in mind that the dangerous combination is ecc -> 1 and E -> pi, because ecc = 1 and E = pi is mathematically impossible.

Our treatment of near-parabolic orbits is based on Farnocchia et al "Robust resolution of Kepler’s equation in all eccentricity regimes" https://doi.org/10.1007/s10569-013-9476-9 . If you want to understand what's happening there, it's very important that you read that paper carefully

Thank you so much @astrojuanlu I will surely read that paper.

After a lot of effort we managed to get this right in #908 and its follow-ups (thanks to the pandemic!)

Yes, it was indeed a long PR and great effort!!

Bear in mind that the dangerous combination is ecc -> 1 and E -> pi, because ecc = 1 and E = pi is mathematically impossible.

Thanks, I will keep that in mind. It was interesting to see the heavy dependence of E on ecc in near-parabolic regions!

We are wondering if this can be related to #1276 somehow, although it seems unlikely

@Yash-10 is this test still failing for you? I noticed a @reproduce_failure decorator we could try to use. If configured correctly, it will output information like this:
You can reproduce this example by temporarily adding @reproduce_failure(..., b'AAAA//AAAAAAAAEA') as a decorator on your test case

There have been some changes in NumPy and numba during this last year, so maybe it's worth trying again in a new installation.
On the other hand, now that I know that numba and numpy might get slightly different numerical results depending on the CPU architecture, it's worth adding the output of numba -s for your computer.

Ok, I tried running the tests again, and now I do not get any errors!

Marvelous! Closing


Spelling

Thank you for correction our bad spelling and typos :)

Made few more tweaks here https://github.com/openwhisk/openwhisk/commit/af1f1cc4ce086aee0c8424838480c8ef67082738. If it's alright with you I will squash all the commits (including mine) into one and commit.

Go ahead

Rebased, squashed and merged as https://github.com/openwhisk/openwhisk/commit/6386717735f0f24e8eba90db4395292e5ea0c2ee.
Thanks for the fixes!!

Hi @jsloyer I'm glad to hear back from you, I remember you from Apache Cordova project.
It looks like you had fun fixing our spelling errors 😄
I'm curious if you have any plans on using OpenWhisk on any of your current projects.
It would be valuable to hear your feedback and point of view on the project the good, bad and the ugly.
You know how to reach me if you want to have a short hangout, as always don't be shy to reach out for anything here on Github or our Slack  👍

ping @jsoref

It's a possibility. The reason I touched this project was because a company mentioned it in their focus.


An interal compiler error

Error: Internal compile error: Jumping from stack depth of 3 to block with stack depth of 1

let globalA;
let globalB = 42;
function ramGet(addr) {
    if (addr === 0) return 0x01;
    if (addr === 1) return 0x00;
    if (addr === 2) return 0x02;
    if (addr === 3) return 0x00;
    print('Access violation: 0x' + addr.toString(16));
    return 0xff;
}
let pc = 0;
function foo() {
    let ins = ramGet(pc);
    // blink_on
    if (ins === 0x01) {
        print('Lamp ON');
    }
    if (ins === 0x00) {
        print('Lamp OFF');
    }
    if (ins === 0x02) {
        pc = (ramGet(pc + 1));
    } else {
        pc = (pc + 1);
    }
}
print(foo());

Well, i don't think that is expected.
This is the IR (when i forced it to compile by pulling out the assertion, forgive me the TERRIBLE variable making or not-making):

xvf.js:#entry(param0) {
    entry:
       LoadArg param0
       StoreGlobal xvf.js:exports
       Literal undefined
       StoreGlobal xvf.js:globalA
       Literal 42
       StoreGlobal xvf.js:globalB
       Literal 0
       StoreGlobal xvf.js:pc
       LoadGlobal global:print
       Literal undefined
       LoadGlobal xvf.js:foo
       Literal undefined
       Call 1
       Call 2
       Pop 1
       var0$5 = Literal undefined
       Return var0$5
}
xvf.js:ramGet(param0, param1) {
    entry:
       param1 = LoadArg param1
       LoadVar param1
       Literal 0
       BinOp ===
       var0$7 = Branch block1 block2
    block1:
       var1$7 = Literal 1
       Return var1$7
    block2:
       var1$7 = LoadVar var0$7
       Literal 1
       BinOp ===
       var0$8 = Branch block3 block4
    block3:
       var1$9 = Literal 0
       Return var1$9
    block4:
       var1$9 = LoadVar var0$8
       Literal 2
       BinOp ===
       var0$9 = Branch block5 block6
    block5:
       var1$11 = Literal 2
       Return var1$11
    block6:
       var1$11 = LoadVar var0$9
       Literal 3
       BinOp ===
       var0$10 = Branch block7 block8
    block7:
       var1$13 = Literal 0
       Return var1$13
    block8:
       var1$13 = LoadGlobal global:print
       Literal undefined
       Literal "Access violation: 0x"
       var4$0 = LoadVar var0$10
       Dup
       Literal "toString"
       ObjectGet
       LoadVar var4$0
       Literal 16
       Call 2
       var4$0 = StoreVar var4$0
       BinOp +
       var1$13 = Call 2
       var0$10 = Pop 1
       var1$14 = Literal 255
       Return var1$14
}
xvf.js:foo(param0) {
    entry:
       var0$11 = LoadGlobal xvf.js:ramGet
       Literal undefined
       LoadGlobal xvf.js:pc
       var0$11 = Call 2
       LoadVar var0$11
       Literal 1
       BinOp ===
       var0$12 = Branch block1 block2
    block1:
       LoadGlobal global:print
       Literal undefined
       Literal "Lamp ON"
       Call 2
       var0$12 = Pop 1
       ; Fallthrough
    block2:
       LoadVar var0$12
       Literal 0
       BinOp ===
       var0$13 = Branch block3 block4
    block3:
       LoadGlobal global:print
       Literal undefined
       Literal "Lamp OFF"
       Call 2
       var0$13 = Pop 1
       ; Fallthrough
    block4:
       LoadVar var0$13
       Literal 2
       BinOp ===
       Branch block5 block6
    block5:
       var1$25 = LoadGlobal xvf.js:ramGet
       Literal undefined
       LoadGlobal xvf.js:pc
       Literal 1
       BinOp +
       var1$25 = Call 2
       LoadVar var1$25
       var1$25 = StoreGlobal xvf.js:pc
       Pop 1
       Jump block7
    block6:
       LoadGlobal xvf.js:pc
       Literal 1
       var1$28 = BinOp +
       LoadVar var1$28
       var1$28 = StoreGlobal xvf.js:pc
       Pop 1
       ; Fallthrough
    block7:
       var1$29 = Literal undefined
       Return var1$29
}

Oddly enough, these appear at jumps to block 4, 6 and 8. You do not see them because my IR dumper is smart smart and stops dumping when it hits a Return. Obviously.
Uncommenting that gives this IR:

xvf.js:#entry(param0) {
    entry:
       LoadArg param0
       StoreGlobal xvf.js:exports
       Literal undefined
       StoreGlobal xvf.js:globalA
       Literal 42
       StoreGlobal xvf.js:globalB
       Literal 0
       StoreGlobal xvf.js:pc
       LoadGlobal global:print
       Literal undefined
       LoadGlobal xvf.js:foo
       Literal undefined
       Call 1
       Call 2
       Pop 1
       var0$5 = Literal undefined
       Return var0$5
       Return
}
xvf.js:ramGet(param0, param1) {
    entry:
       param1 = LoadArg param1
       LoadVar param1
       Literal 0
       BinOp ===
       var0$7 = Branch block1 block2
    block1:
       var1$7 = Literal 1
       Return var1$7
       Return
       ; Fallthrough
    block2:
       var1$7 = LoadVar var0$7
       Literal 1
       BinOp ===
       var0$8 = Branch block3 block4
    block3:
       var1$9 = Literal 0
       Return var1$9
       Return
       ; Fallthrough
    block4:
       var1$9 = LoadVar var0$8
       Literal 2
       BinOp ===
       var0$9 = Branch block5 block6
    block5:
       var1$11 = Literal 2
       Return var1$11
       Return
       ; Fallthrough
    block6:
       var1$11 = LoadVar var0$9
       Literal 3
       BinOp ===
       var0$10 = Branch block7 block8
    block7:
       var1$13 = Literal 0
       Return var1$13
       Return
       ; Fallthrough
    block8:
       var1$13 = LoadGlobal global:print
       Literal undefined
       Literal "Access violation: 0x"
       var4$0 = LoadVar var0$10
       Dup
       Literal "toString"
       ObjectGet
       LoadVar var4$0
       Literal 16
       Call 2
       var4$0 = StoreVar var4$0
       BinOp +
       var1$13 = Call 2
       var0$10 = Pop 1
       var1$14 = Literal 255
       Return var1$14
       Return
       var3$42 = Literal undefined
       Return var3$42
       Return
}
xvf.js:foo(param0) {
    entry:
       var0$11 = LoadGlobal xvf.js:ramGet
       Literal undefined
       LoadGlobal xvf.js:pc
       var0$11 = Call 2
       LoadVar var0$11
       Literal 1
       BinOp ===
       var0$12 = Branch block1 block2
    block1:
       LoadGlobal global:print
       Literal undefined
       Literal "Lamp ON"
       Call 2
       var0$12 = Pop 1
       ; Fallthrough
    block2:
       LoadVar var0$12
       Literal 0
       BinOp ===
       var0$13 = Branch block3 block4
    block3:
       LoadGlobal global:print
       Literal undefined
       Literal "Lamp OFF"
       Call 2
       var0$13 = Pop 1
       ; Fallthrough
    block4:
       LoadVar var0$13
       Literal 2
       BinOp ===
       Branch block5 block6
    block5:
       var1$25 = LoadGlobal xvf.js:ramGet
       Literal undefined
       LoadGlobal xvf.js:pc
       Literal 1
       BinOp +
       var1$25 = Call 2
       LoadVar var1$25
       var1$25 = StoreGlobal xvf.js:pc
       Pop 1
       Jump block7
    block6:
       LoadGlobal xvf.js:pc
       Literal 1
       var1$28 = BinOp +
       LoadVar var1$28
       var1$28 = StoreGlobal xvf.js:pc
       Pop 1
       ; Fallthrough
    block7:
       var1$29 = Literal undefined
       Return var1$29
       Return
}

The thing is, none of these jumps appear. The reason again is because my tool is smart smart and figures out it is a fallthrough. So it just adds a comment ; Fallthrough. And calls it a day.
Solution: Stop parsing a block on a Return. Actually, stop doing anything then. Even parsing the code. It is dead code. Why bother?

Great, thanks for highlighting this bug!
Ok, the stack depth issue should be fixed now on master. Running your example code for me yields:

The only thing I changed to run this is that I changed print to console.log.
Let me know if this fixes your issue.

(the undefined printout on the terminal is because it's doing console.log(foo()) when foo doesn't return a value)

Stop parsing a block on a Return. Actually, stop doing anything then. Even parsing the code. It is dead code. Why bother?

The following Microvium source code should not run:
// script.mvms
foo();
function foo() {
  console.log('foo');
  return;
  This line is unreachable and syntactically invalid, but definitely *should* give an error
}

Running in node and microvium both give syntax errors (albeit worded differently).

I'm not sure how it would even make sense to stop parsing at a runtime error.

Do not stop parsing, but stop the codegen. I don't think it is necessary to codegen dead code, that is all. But it is fixed, so i'm closing.


perf(cruby): reuse XPathContext objects

What problem is this PR intended to solve?
Issue #3266 discusses a potential optimization by re-using XPathContext objects (which are relatively expensive to initialize).
This PR makes the following changes:

the XPathContext object ...

can accept nil as the value arg to #register_ns and #register_variable to deregister the namespace or variable
tracks namespaces and variables registered through those two methods
has a new #reset method that deregisters all namespaces and variables registered
has a new #node= method to set the current node being searched

all the Searchable methods ...

use a thread-local XPathContext object that is only available in a block yielded by #get_xpath_context
and that context object is #reset when the block returns

There is an escape hatch that I will leave undocumented, which is to set the env var NOKOGIRI_DEOPTIMIZE_XPATH, out of an abundance of caution.

I originally implemented a much simpler approach, which cleared all registered variables and functions, however the standard XPath 1.0 functions were all also deregistered; and calling xmlXPathRegisterAllFunctions to re-register them took us back to the original performance profile.
The win here is to avoid re-calling xmlXPathRegisterAllFunctions, and for that we track registered variables and namespaces, and de-register them after the query eval completes.
Have you included adequate test coverage?
Yes.
Does this change affect the behavior of either the C or the Java implementations?
CRuby only.

Going to merge this so I can ship a 1.18 release candidate today. But if you have any feedback, the final release is still a couple of weeks away.

Note that if you use a single XPath context and support custom XPath extension functions, a custom function could evaluate XPath expressions recursively which will lead to corruption of context variables. This is mostly due to some design mistakes in libxml2. So you should backup and restore the following members of xmlXPathContext before and after evaluating an expression:

doc
node
contextSize
proximityPosition

Other settings that could change like namespaces should be backed and restored up as well. Or you could simply disallow recursive evaluation in some way.

@nwellnhof thank you for the advice! doc and node are being set explicitly every time, but I'll save/restore contextSize and proximityPosition before the final release.

@nwellnhof Would it be OK to set contextSize and proximityPosition back to their defaults before every evaluation, rather than saving/restoring? Looks like xmlXPathNewContext sets them to -1.

See https://github.com/sparklemotion/nokogiri/pull/3386

doc and node are being set explicitly every time

That's not enough. Consider:

xmlXPathEval is called for the first time and context->node is set.
An extension function is called which evaluates another XPath expression.
xmlXPathEval is called for the second time and context->node is set to a new value.
xmlXPathEval returns but context->node still contains the new value.
The rest of the original evaluation continues with the wrong context node.

Looks like xmlXPathNewContext sets them to -1.

I'd suggest to set both values to 1 once after creating an XPath context, but it doesn't matter much outside of XSLT.

@nwellnhof Oh! That makes sense, I misunderstood your original message. It hadn't even occurred to me that people would want to do that.
Alternatively, I could create a new xpath context object if there's a recursive call being made.

Yes, it seems unlikely that Nokogiri users would want to do that. But in libxslt, this happens all the time.
I think the underlying issue is that context creation is too slow in libxml2 because the XPath functions are registered each time. If this was fixed, it shouldn't be too costly to recreate a context for each evaluation.

@nwellnhof Yes, in my benchmark, xmlXPathRegisterAllFunctions dominated the initialization overhead.

@nwellnhof If it's interesting, I implemented a branch in #3388 where I copy an initialized xmlXPathContext struct (i.e., I deep-copy funcHash instead of calling xmlXPathRegisterAllFunctions) and it's slightly faster but not an overwhelming win.

I reworked XPath function lookup here: https://gitlab.gnome.org/GNOME/libxml2/-/commit/bf5fcf6e646bb51a0f6a3655a1d64bea97274867
xmlXPathNewContext should be a lot faster now.

@nwellnhof Thanks for that!
Here's how the above benchmark looks for small ~6kb files:
Comparison:
         small: edge:   306454.7 i/s
      small: patched:   225456.0 i/s - 1.36x  slower
         small: main:   124554.9 i/s - 2.46x  slower

where:

"edge" is Nokogiri v1.18.0.rc1 re-using the context object
"patched" is using libxml2 v2.13.5 with gnome/libxml2@bf5fcf6e patched in
"main" is Nokogiri v1.17 creating a new XPathContext for each query

Maybe I'm missing something, but looking at commit cef057ff5f7572ba827e5214b1e42e2448e60d28, I can't see where namespaces (or variables) are unregistered from the global context after evaluation.
On another note, if you really want to speed up XPath processing, you should think about supporting compiled expressions.

@nwellnhof I reverted most of this PR in #3389, which I just merged. So what's on main no longer re-uses the XPathContext struct/object.

@nwellnhof re: compiled expressions, I did build it:
https://github.com/sparklemotion/nokogiri/pull/3380
but I was not able to benchmark much of a difference. Any advice you'd have on gaining a better understanding of when this would be an improvement would be very valuable.
I also have a branch that enabled the XPath cache, and it did show some pretty good speedup on some blunt benchmarks, but I don't know enough about how it works to give people advice on when to enable it.

but I was not able to benchmark much of a difference. Any advice you'd have on gaining a better understanding of when this would be an improvement would be very valuable.

It should be most noticeable with expressions that evaluate quickly like @attr. But maybe compilation isn't that much of an overhead after all. The XPath compiler also still misses some important optimizations.

I also have a branch that enabled the XPath cache, and it did show some pretty good speedup on some blunt benchmarks, but I don't know enough about how it works to give people advice on when to enable it.

The cache speeds up allocation of XPath objects. In general, it's good idea to enable it.
Another useful optimization is xmlXPathOrderDocElems which speeds up sorting of node sets.


Receiving warning/recommendation: "XCGLogger.swift - Static declarations are implicitly 'final'

I'm receiving the following warning/recommendation when I build using Xcode 10 - beta 2/Swift 4.2
XCGLogger/XCGLogger.swift:96:21: Static declarations are implicitly 'final'; use 'public' instead of 'open'.
I've made the change locally and am reporting it in anticipation for a fix in a subsequent release.

I look at the code, the static struct initialisation is no more needed here and for the queue
So we could use
    public static let `default` = XCGLogger(identifier: XCGLogger.Constants.defaultInstanceIdentifier)

Still a problem with Xcode 10 beta 6, just a few days prior to Xcode 10 release.


Install infra and nova operator for dataplane kuttl tests

We need the crds, though the extent of testing we do is fine without the controller-manager.

@rabi with the latest re-architecture I think NovaExternalCompute is going to go away. We can however merge this now, and then remove that dependency at a later time.

@dprince dataplane kuttl jobs are broken because we changed recently to not create all crds before hand. This is required atm to fix those jobs.

recheck

recheck

recheck

recheck


Release version?

Hi Geoffrey,
is there any chance to get a tag release for Pathspec (e.g. 0.1.0)?
I'd like to use it in a package and avoid future breakage.
(Preferably after merging https://github.com/g-Off/Pathspec/pull/2)
Thanks!

Merged and tagged. Thanks again for the PR!

Thanks, @g-Off!


[fix] spread argument syntax support

This fixes the support for spread arguments in arrow function, ex: (...a: any[]) => {}

Hi, thanks for the contribution. Could you add a test for this? Thanks!

Sure! I edited my commit.

Thanks!


Multi-object detection and extraction in longslit spectroscopy

Multi objects can be identified but there is no handling for them

There a preliminary implementation of this. Need to run a few tests and probably improve the extraction method in order to avoid contamination or cross-contamination of sources.
The name of the output files for multiple targets will be: original_filename_1.fits, original_filename_2.fits ... original_filename_N.fits and for single ones will be simply original_filename.fits also consider the g  as prefix.

It would be good to have a performance parameter for object separation. Remember that you will not be able to detect different sources if they are too close. People say that they can not be resolved. That depends on their separation and on the observed seeing. Considering that the spacial fwhm is the seeing, they normally can only be resolved if they are separated by more than a fwhm / 2.

We will simulate data with more than one target and see how the identification works and then do the same for extraction.

This issue is not specific enough and is very old.
See #258


[FEATURE REQUEST] Update ssm-municipalLicence

What feature are you suggesting?

Is it possible to adjust the new licence to have the same appearance as the current licence? - n.n

We find the [new] licence very plain looking and not very professional in appearance.  I would like the City Crest to be bigger and maybe a border around it or something to spice it up (look more professional).  Not sure if that is done with adding some color? - n.n

Is your feature request related to a problem?
No.
Are there any workarounds?  Are there any alternative solutions that would work?
No.
Are there any other helpful details?
The licence in current system was created with a drag-and-drop reporting tool, so there are a variety of alignments that cannot easily be created in HTML.

I printed a general licence and the changes made are good, however I want to still work on the appearance of the licence, make it look more professional. ... We can use the City Crest as a watermark on the licence and use the colored crest.  Could you please make these changes to the licence? - n.n

I really like it, but was hoping to make a couple of small adjustments! Lol!  Can we remove the interior boxes/lines.  Only leave the external border.  Could we try making the external border lines darker and if possible, have the licence fill the page or space it out a little better (center of page)? - n.n

If possible could we space out the information to fill the page.  I don’t like the white space at the bottom of the page. - n.n

I just printed it and I love all the changes!  Thank you so much!! - n.n


[WFCORE-4419] Remove deprecated ParseUtil methods

https://issues.jboss.org/browse/WFCORE-4419

@jmesnil Oh, you mean the method in ParseUtils itself. That's a mistake; thanks, I'll correct. Leaving them commented in the logger file is standard practice.

I removed the commented ParseUtils method.

@bstansberry thanks


Improve help messages and flag explanations

Currently most flags and commands don't have a proper explanation or examples.
Many still display the default cobra help message.

Hello Max!
Whats up? I was wondering if you have interest in the feature of showing the release version on command messages. Also, in eliminate the word Error: from messages and move them to the bottom, this make me feel things are too bad.

Hi @joaoepj, regarding the versions: sounds good, I'm open to anything really :) Just open a PR and I will have a look.
I'm not sure I know what you mean in regards to the Error messages. Do you have an example of what your want to change?

Ok! I'll do my homework and eventually open the PR. I realize the error messages are a feature of cobra lib and need to do more tests.

Hi @joaoepj, regarding the versions: sounds good, I'm open to anything really :) Just open a PR and I will have a look. I'm not sure I know what you mean in regards to the Error messages. Do you have an example of what your want to change?


Configurable front page

Implements #544 and #533.
Firstly I moved the "population" - number of nodes - to the same row as other metrics that show the number of nodes in various states.
Then I added 2 new configuration settings to allow disabling 2 sections of that page:

RESOURCES_STATS_ENABLED
NODES_STATUS_DETAIL_ENABLED

Both are set to True by default for backward compatibility.
I also organized the docs for all the settings in the README.

A screenshot showing the updated front page with both sections disabled. Note where the "total population" metric is located now.

Hm, I need to fix the tests...

I also forgot to update def index(env), so we still actually get the data that we do not show in the template... 🤦

Oups, disabling NODES_STATUS_DETAIL_ENABLED breaks failed/pending/changed/unreported metrics...

Thanks @sebastianrakel , but I have to make it work with RESOURCES_STATS_ENABLED=True and NODES_STATUS_DETAIL_ENABLED=False without actually all the processing that would be done if NODES_STATUS_DETAIL_ENABLED=True.


Linux: frequent crashes on startup

Description
The Re-Logic intro screen comes up, fades away, and the screen stays black after. The process has to be killed manually.
Steps to Reproduce

Start the game from Steam
Hope for the best

Expected behavior
The tModLoader "finding mods"  screen should come up.
Actual behavior
Doesn't.
Reproduction frequency
~60-80% of startups.
Versions
This happens on <IP_ADDRESS>, don't know if happens on other versions.
Mods
Happens without mods enabled.
Additional Information
I tested without tModLoader about 6 times and the game starts fine always. With tModLoader it only works seldom. I can't find any error logs for the crashes/freezes.
I've had 2 ingame crashes and one of those produced a log in ~/.steam/steam/steamapps/common/Terraria/client-crashlog.txt. I use the Calamity mod and I don't know if it's related to it, tModLoader or something else but I'll include the log here. I'm not sure this warrants another issue.
8/20/2017 8:24:41 AM
System.TypeLoadException: Failure has occurred while loading a type.
at Terraria.Social.Steam.CoreSocialModule.Initialize () [0x00039] in <6bf9c39ff4674fd3a65b4dd3174fc083>:0
at Terraria.Social.SocialAPI.Initialize (System.Nullable`1[T] mode) [0x00053] in <6bf9c39ff4674fd3a65b4dd3174fc083>:0
at Terraria.Program.LaunchGame (System.String[] args, System.Boolean monoArgs) [0x000d4] in <6bf9c39ff4674fd3a65b4dd3174fc083>:0

No mention of your distro ? that's kind of a wild guess for them then

Oh, distro is Bunsenlabs, that is basically Debian Jessie with openbox. If there's any more possibly relevant information I can of course provide it.

@RfzVd Check whether Steamworks.NET.dll, libCSteamworks.so and libsteam_api.so all exist. If not, validate.

This also happens for me on mac OS 10.11.6 - running tmodloader 0.10.1
I've never left it running when the black screen happens, I usually just force quit and try again via steam. Sometimes it takes 4-5 tries before it actually loads.
My system.log file has lines which look like the following (I'm unsure if they're relevant or not):
WindowServer[175]: disable_update_timeout: UI updates were forcibly disabled by application "Terraria" for over 1.00 seconds. Server has re-enabled them.
WindowServer[175]: common_reenable_update: UI updates were finally reenabled by application "Terraria" after 7.98 seconds [0.13fps] (server forcibly re-enabled them after 1.00 seconds [1.00fps])

Can confirm with Linux version (native steam) on Archlinux. For me it works all the time after a restart. Maybe something related to graphic driver? (I'm using nvidia.)
@PoroCYon I'm missing Steamworks.NET.dll, but have libCSteamworks.so and libsteam_api.so. Repairing on steam will clear tModLoader (1 file replaced).

muesli4: Steamworks.NET.dll is embedded inside Terraria.exe and must be manually extracted. The other dynamic libs you listed run native code, while there must be a wrapper present (which, in this case, should be Steamworks.NET.dll).
Also, try getting a stack trace, somehow (see also the mono(1) manpage). I doubt it is a driver issue, but you never know with nvidia ¯\_(ツ)_/¯. If your GPU is supported by nouveau, you should try that instead.
Here's how to extract Steamworks.NET.dll:
$ csharp # execute this in the directory `Terraria.exe` resides in
> using System.IO;
> using System.Reflection;
> var asm = Assembly.LoadFrom("Terraria.exe");
> var str = asm.GetManifestResourceStream("Terraria.Libraries.Steamworks.NET.Linux.Steamworks.NET.dll");
> var fs = File.OpenWrite("Steamworks.NET.dll");
> str.CopyTo(fs);
> fs.Close();
> quit;

I had this problem earlier today and was able to get it to work by having Terraria disable compositing on startup using plasma's window settings or changing the compositing mode to xrender. It also worked fine when running it using integrated intel graphics instead of amd. Sorry if this is a bit hard to follow and unhelpful, but I'm just putting my experience here.

This could be a compositor issue, but I'm not entirely sure. I had to change some stuff in FNA and change some environment variables in order to get Terraria to work on my (rather exotic) setup. You could try these and report whether they worked. (If it doesn't, try tweaking the environment variables.)
Envvars (i.e. how I run Terraria):
# FNA_SONG_DISABLE_THREADS and FNA_KEYBOARD_USE_SCANCODES aren't crucial for this
#FNA_SONG_DISABLE_THREADS=1 FNA_KEYBOARD_USE_SCANCODES=1 \
LD_LIBRARY_PATH="$(pwd)/lib64:${LD_LIBRARY_PATH:-/usr/lib}" \
FNA_OPENGL_DISABLE_LATESWAPTEAR=1 FNA_OPENGL_FORCE_CORE_PROFILE=1 \
FNA_GRAPHICS_FORCE_GLDEVICE=ModernGLDevice \
mono --debug=mdb-optimizations Terraria.exe # --debug flag used for better stacktraces

Change LD_LIBRARY_PATH to the path where the native libraries reside, FNA_OPENGL_DISABLE_LATESWAPTEAR and maybe FNA_OPENGL_FORCE_CORE_PROFILE and FNA_GRAPHICS_FORCE_GLDEVICE should be tweaked if it doesn't work.
Here's the patch: (Apply this to the FNA source, then recompile.)
diff --git a/src/FNAPlatform/ModernGLDevice.cs b/src/FNAPlatform/ModernGLDevice.cs
index f89ab62..91df36a 100644
--- a/src/FNAPlatform/ModernGLDevice.cs
+++ b/src/FNAPlatform/ModernGLDevice.cs
@@ -8,7 +8,7 @@
 #endregion

 #region THREADED_GL Option
-// #define THREADED_GL
+#define THREADED_GL
 /* Ah, so I see you've run into some issues with threaded GL...

  *
diff --git a/src/FNAPlatform/OpenGLDevice.cs b/src/FNAPlatform/OpenGLDevice.cs
index 9ae0d7f..5c096a2 100644
--- a/src/FNAPlatform/OpenGLDevice.cs
+++ b/src/FNAPlatform/OpenGLDevice.cs
@@ -8,7 +8,7 @@
 #endregion

 #region THREADED_GL Option
-// #define THREADED_GL
+#define THREADED_GL
 /* Ah, so I see you've run into some issues with threaded GL...

  *
diff --git a/src/FNAPlatform/SDL2_FNAPlatform.cs b/src/FNAPlatform/SDL2_FNAPlatform.cs
index dfa7937..511ef92 100644
--- a/src/FNAPlatform/SDL2_FNAPlatform.cs
+++ b/src/FNAPlatform/SDL2_FNAPlatform.cs
@@ -868,11 +868,11 @@ namespace Microsoft.Xna.Framework
 				{
 					if (SDL.SDL_GL_SetSwapInterval(-1) != -1)
 					{
-						FNALoggerEXT.LogInfo("Using EXT_swap_control_tear VSync!");
+						//FNALoggerEXT.LogInfo("Using EXT_swap_control_tear VSync!");
 					}
 					else
 					{
-						FNALoggerEXT.LogInfo("EXT_swap_control_tear unsupported. Fall back to standard VSync.");
+						//FNALoggerEXT.LogInfo("EXT_swap_control_tear unsupported. Fall back to standard VSync.");
 						SDL.SDL_ClearError();
 						SDL.SDL_GL_SetSwapInterval(1);
 					}

Should be fixed https://github.com/blushiemagic/tModLoader/commit/09518af7ede1711bcee902a1fe5ae9c7bbd62210

Still is broken for me... not fixed?

It's fixed in the next release.

It's fixed in the next release.

Hi, my friend has this same problem. Do you have an ETA for the stable v0.11? If he installs the new version will he be able to play with me on v0.10.x?
It seems you didn't provide builds for Linux, do I have to compile it myself? How can I do that?
Thank you.

If you and your friend both obtain the beta release from the discord channel you should be able to test it out for us.
Would be greatly appreciated

Just downloaded and tested v0.11 from discord beta channel, it's working great on MacOS 10.11 and 10.12 (latest versions) !
Thanks for the update.

Good to hear, thanks for the update.

Still crashes on Linux Mint 19.1. Exact same problems listed in main topic. I am using TModLoader 0.10.5.


Match python and cpp arrow versions

Although in theory there shouldn't be a hard link between versions of arrow across our different languages, the arrow conda projects seem to make libarrow and arrow-cpp require the same version. This means if rerun-cpp needs a different version of arrow that rerun-py we can't use both in the same conda package.
Specifically this prevents us from having a pixi project which includes arrow-cpp and also rerun-sdk to streamline launching via spawn

Note that supporting Python 3.12 (#3699 ) will require PyArrow 14.

we match cpp & arrow by now!


Can't install yabai from homebrew

Can't install yabai from homebrew:
OS: Monterey 12.5
hardware: MacBook Pro M1 Max chip
~ csrutil status
System Integrity Protection status: disabled.

~ brew install yabai
Warning: No available formula with the name "yabai".
==> Searching for similarly named formulae...
Error: No similarly named formulae found.
==> Searching for a previously deleted formula (in the last month)...
Error: No previously deleted formula found.
==> Searching taps on GitHub...
Error: No formulae found in taps.

Installation command is brew install koekeishiya/formulae/yabai.
ref: https://github.com/koekeishiya/yabai/wiki/Installing-yabai-(latest-release)

Thanks!


Invoke-WebRequest Error

The Dockerfile for apache has problems when build. Could I use something like COPY apache.zip c:/ ?
Step 3/6 : RUN powershell -Command      $ErrorActionPreference = 'Stop';        Invoke-WebRequest -Method Get -Uri http://home.apache.org/~steffenal/VC15/binaries/httpd-2.4.34-win64-VC15.zip -OutFile c:\apache.zip ;         Expand-Archive -Path c:\apache.zip -DestinationPath c:\ ;    Remove-Item c:\apache.zip -Force
---> Running in 99730dd6e3e0
Invoke-WebRequest : Unable to read data from the transport connection. The
connection was closed before all data could be read. Expected 17772903 bytes,
read 3638356 bytes.
At line:1 char:34

... e = 'Stop'; Invoke-WebRequest -Method Get -Uri http://home.apache.org ...

            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

CategoryInfo          : NotSpecified: (:) [Invoke-WebRequest], IOExcepti
on
FullyQualifiedErrorId : System.IO.IOException,Microsoft.PowerShell.Comma
nds.InvokeWebRequestCommand

you can try using the command "[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12" before call invoke-webrequest?

We hugely appreciate your contribution, feedback, and support to our technical documentation.
We’ve phased out GitHub Issues on this repository as the feedback mechanism for content and have replaced it with a new feedback system. For more information see, Content User Feedback. As part of this rollout, we are migrating your issue where our team will use your comments to improve the documentation experience. Unfortunately, this does mean you won't be able to access this issue after the migration is complete.
All issues will be migrated by Thursday 29th August 2024.
Once again, thank you for your valuable feedback, we hope you’ll continue to contribute using our new feedback system.


failed init with amd rx580sp

Error though
Using output DVI-D-1
Opening libva device from DRM device /dev/dri/renderD128
[AVHWDeviceContext @ 0x55ee0f50c9c0] Failed to initialise VAAPI connection: -1 (unknown libva error).
thread 'main' panicked at src/avhw.rs:34:13:
assertion `left == right` failed: failed to open /dev/dri/renderD128
  left: -5
 right: 0
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

❯ wl-screenrec
Using output eDP-1
Opening libva device from DRM device /dev/dri/renderD128
[AVHWDeviceContext @ 0x55f2e4b0b4c0] libva: /usr/lib/dri/i965_drv_video.so init failed
[AVHWDeviceContext @ 0x55f2e4b0b4c0] Failed to initialise VAAPI connection: -1 (unknown libva error).
thread 'main' panicked at 'assertion failed: (left == right)
left: -5,
right: 0: failed to open /dev/dri/renderD128', src/avhw.rs:34:13
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
 CPU : Intel i7-10510U (8) @ 1.800GHz
 GPU : Intel CometLake-U GT2 [UHD Graphics]
 GPU Driver : i915

@glepnir make sure you've followed your distribution's setup instructions for vaapi, then if that doesn't work please post the output of vainfo and let me know if wf-recorder -c h264_vaapi -d /dev/dri/card0 works correctly.
@kRHYME7 please open a new issue with your bug with the same info--your hardware is pretty different and I'd like to keep them separate.

vainfo output
Trying display: wayland
vainfo: VA-API version: 1.20 (libva 2.20.0)
vainfo: Driver version: Mesa Gallium driver 23.2.1-arch1.2 for AMD Radeon RX 580 Series (polaris10, LLVM 16.0.6, DRM 3.54, 6.5.8-arch1-1)
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointEncSlice
      VAProfileH264High               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointEncSlice
      VAProfileHEVCMain               : VAEntrypointVLD
      VAProfileHEVCMain               : VAEntrypointEncSlice
      VAProfileHEVCMain10             : VAEntrypointVLD
      VAProfileJPEGBaseline           : VAEntrypointVLD
      VAProfileNone                   : VAEntrypointVideoProc

Does wf-recorder -c h264_vaapi -d /dev/dri/card0 work?


Documentation: add sumatrapdf instructions to installation instructions

Additions

Instructions for forward/inverse search
Note on existence of Jetbrains toolbox
Note on end of overleaf git support

Changes

Splitted Mac instructions into separate set.

Thanks for the review, updated!


Automatically select the first image of the assets page

This fix a bug in the assets page.
When the user opens a new popup, the first preview image should be automatically selected without requiring a click.

Thanks!


NN-4961 Remove Multi image docker build :-(

Addressed with

https://github.com/ministryofjustice/hmpps-manage-adjudications-api/pull/313
https://github.com/ministryofjustice/hmpps-manage-adjudications-api/pull/314
Closing this one


Collectibles

Improved how collectible data is generated
Updated dialogs for red containers - they now state what is in the box.
Adjusted coordinates of the containers
Renamed the layer from "Containers" to "Collectibles"

Also cleaned up and removed unused code


Radio buttons in radiogroup are to close to each other

Bug, feature request, or proposal:
Bug/proposal
What is the expected behavior?
Mutpiple radiobuttons on a single line within a a radiogroup should have enough space between them.
What is the current behavior?
Currently there is not enough space.
What are the steps to reproduce?
https://stackblitz.com/angular/lpxkqqdqebp?file=app%2Fradio-overview-example.ts
What is the use-case or motivation for changing an existing behavior?
Without any styling it looks awkward. Some default padding should be applied when in a radiogroup.
Which versions of Angular, Material, OS, TypeScript, browsers are affected?
cli 6.0.5
material 6.1.0
Chrome 66
FireFox 60
Is there anything else we should know?

In general we try to avoid adding margins to the outer-most Material components, because they depend on things like the consumer's grid system and can be broken easily if we do some changes.

Closing as this is working as expected.  You should be able to adjust the padding/margin within your application by targeting the radio buttons

Closing as this is working as expected.  You should be able to adjust the padding/margin within your application by targeting the radio buttons


Hyper.is Does not recognize some characters

I use a spanish keyboard and sometimes I have to use accents and the letter "ñ" but when I tyoe it instead of the character shows: (args:1)
http://imgur.com/a/vGNYd

Hyper 1.3.3
Electron 1.4.16
linux x64 4.8.0-36-generic

Hey there, please try again with the new Hyper v2 release and open a new issue if the problem stills exists. Thank you!


feat(command): rename variable parts

TODO:

has bug with deleting part
impl up and down commands (do nothing if editingIndex isnt undefined)

@ILScc Check keybindings, everything works fine to me. Try to alt+k in shortcuts UI editor and remove all ctrl+l or ctrl+o handlers (you can restore them later in shortcuts.json)

Ensure that:

Editing any part performs casing normalization (it should make first-uppercase if not first)
It does the same when moving parts
When I tested it, moving parts didn't work correctly

@zardoy  looks like I've managed to deal with moving parts :)
Can you please describe bug you mentioned above - I'll try fixing if it's still relevant

TODO:

has bug with deleting part
impl up and down commands (do nothing if editingIndex isnt undefined)

Yes, deleting part normalizes first character, but not editing. Imagine these two cases:

Edit part:

someCoolVariable -> someDecentVariable
When you select Cool part and replace it with decent you shouldn't care about first character, as you're editing one part. It should autocapitalized, if not first.

Append or prepend text in some part:

someCoolVariable -> someReallyCoolVariable
You can select Cool part and prepend the text with really
Also I checked that it doesn't work with all casings:
const im_should_not_be_capitalized = 5
// or
const a = {
    'some-prop': 5
}

Would be great to support them as well. I pushed 1 commit with that support.

I think it'd great also to refactor parts array to use proxy from valtio instead. Example: https://github.com/zardoy/npm-the-fastest/blob/0474087adb0d7070fa3f500368a5be9eefc1ae4c/src/features/statusbar.ts#L2
const parts = proxy([])
// subscribe and update first-letter uppercase in parts whenever they change

Instead of duplicating logic it'd be much cleaner

Now everything works, only two tasks remaining:

(small) allow to type big/small letter to change isPascalCase (or even refactor to get rid of it)
when editing: SomethingElse -> enter should add Else as a part

However it can be merged with these tasks in mind.


[FEATURE REQ] Event System topic misses Monitor Alert/Action group as destination.

API Spec link
https://learn.microsoft.com/en-us/rest/api/eventgrid/controlplane/system-topic-event-subscriptions/create-or-update?view=rest-eventgrid-controlplane-2022-06-15&tabs=HTTP
API Spec version
2024-06-01-preview, 2022-06-15
Please describe the feature.
It is not possible to set "monitor alert" for the system topic event types. The event data can be forwarded to an event hub, storage queue etc. However, the monitor alert (or action group) is missing from this list.
https://learn.microsoft.com/en-us/rest/api/eventgrid/controlplane/system-topic-event-subscriptions/create-or-update?view=rest-eventgrid-controlplane-2022-06-15&tabs=HTTP
I'm not really sure if the link for "API Spec link" is the right one. Please correct it in case it is incorrect.
There is an active issue in the Terraform provider which has many 👍  https://github.com/hashicorp/terraform-provider-azurerm/issues/24873

It looks like this is not true (anymore?):
Example for Microsoft.KeyVault system topic
subscription_id=...
resource_group_id=...
system_topic_name=...
action_group_name=...
subscription_name="testsub1"

url_base="https://management.azure.com/subscriptions/$subscription_id/resourceGroups/$resource_group/providers/Microsoft.EventGrid/systemTopics/$system_topic_name/eventSubscriptions/"
api_version="2024-06-01-preview"
url="$url_base/$subscription_name?api-version=$api_version"
action_group_resource_name="/subscriptions/$subscription_id/resourceGroups/$resource_group/providers/Microsoft.Insights/actionGroups/$action_group_name"

body=$(cat << EOF
{
  "properties": {
    "destination": {
      "endpointType": "MonitorAlert",
      "properties": {
        "actionGroups": [ "$action_group_resource_name" ],
        "description": "Sample description",
        "severity": "Sev2"
      }
    },
    "eventDeliverySchema": "CloudEventSchemaV1_0",
    "filter": {
    "includedEventTypes": [
        "Microsoft.KeyVault.SecretNearExpiry"
      ]
    }
  }
}
EOF
)

az rest --method put --url "$url" --body $body

BUT the terraform resource is still missing this... https://registry.terraform.io/providers/hashicorp/azurerm/4.8.0/docs/resources/eventgrid_system_topic_event_subscription


Remove upgrade-key module from SRML

The upgrade-key module is an historical artifact and should be removed from Substrate.
The sudo module does everything that this module would do
Need to make sure that no downstream dependencies need upgrade-key, like Substrate Node Template or any tutorials

FYI - https://docs.substrate.dev/docs/substrate-runtime-recipes still references the upgradeKey when talking about updating the runtime (in the screenshot)


New package: Pixell v0.1.0

Registering package: Pixell
Repository: https://github.com/simonsobs/Pixell.jl
Created by: @xzackli
Version: v0.1.0
Commit: 963a4ee4895a38c01a2ba317cbaf18ed8d9ecdf2
Reviewed by: @xzackli
Reference: https://github.com/simonsobs/Pixell.jl/commit/963a4ee4895a38c01a2ba317cbaf18ed8d9ecdf2#commitcomment-67275139
Description: next-generation sky map manipulation on rectangular pixels

This package is based on a python package of the same name, simonsobs/pixell. The name is pixel + ell (as in the degree of a spherical harmonic) because it manipulates rectangular pixels on the sphere.
I think this is a false positive on the package name similarity. Although both packages have a portmanteau name involving "pixel", I think it's very unlikely that humans would mistake Pixell for Sixel. The two packages also have very different functionalities and target audiences.


Add expansion errors to error console

When execute a command expansion in the UI it should propagate the errors into the console rather than just showing Error: internal error.
To replicate this easily, create an activity with 0 duration and run an expansion. Right now you'll get an error with the following message: invalid ISO 8601 string: null, but I'm going to improve that.

Our original intent with command expansion errors was that:

Errors that come from expansions (introduced by the user code of expansions) should be emitted in the expanded sequences themselves with the command stem of $$ERROR$$ so as to allow for partially successful expansion (and the appropriate tracing of that)
Errors related to expansion that are not specifically due to the expansion but a bug in our code should propagate normally as bug errors

I think the two types of errors should have different behaviors on the UI. The specifics of those behaviors I can't exactly specify.
I think having additional behavior for case 1 outside of it embedding it in the sequence in the UI is a good idea, but unsure of what exactly that should be - I think NOT in the error console because it's really not an "error" of the system, but a behavioral result of the users.
I think case 2 most likely belongs in the error console.

The specific error you listed is interesting because it's a little bit of 1 and a little bit of 2.
1 because it's a direct result of the user's expansion implementation (generating the null value)
2 because it occurs outside of the user code execution environment (trying to interpret the null as an iso string)
Ultimately though, this seems like an error in our implementation of catching the error and should be forced more squarely into 1 so it's clear that it's an issue the users need to address, not the Aerie team.
That's not the point of this issue though, so should probably be tracked elsewhere

This issue was specifically talking about your second case (in your first post), right now if we can't run the expansion due to an error so we just get a generic error message that isn't propagated from the sequencing server itself.
Interesting read about error handling from the expansions itself though, do we have this tracked somewhere as a decision or just does it just exist in code?

I don't know if we formally recorded this in documentation anywhere. We definitely should though because it's a core philosophy of command expansion strongly driven by previous solutions' command expansion behavior and mission feedback.
Generally, this philosophy of enabling partial success is a key concept for software that is intended not as a total replacement for users, but as an assist to users. It was a hard learned lesson for me over the last 6 years of mission software work.


Peer to peer code review

Highlights
Hello, @AbdusSattar-70, well done but there are some issues that you need to fix.

the score field is of type text, which may allow the addition of a string as well. Only a number is expected in the score field
https://user-images.githubusercontent.com/24216198/224926247-d399743c-b025-491f-81f7-64c306acdbb3.png)
the event listener for input is a form, I recommend you to listen to a click event to the submit button.
https://user-images.githubusercontent.com/24216198/224925444-151972b2-b12d-401f-9714-9678a9766ede.png)

Thanks for reviewing - I have resolved it #6


Improved Invocation Hook to use a chain of Providers

@DanielSperry and I did remote pair programming tonight and this is the result. :)

This is an improved invocation hook that allows a better control of the invocation flow, making possible customs annotations to work together, and invocation features to be implemented as extensions, keeping the orbit core clean.

That photo tells me that it's a good thing we don't have a human child together :)


✨ Don’t intercept the navigation on hasUAVisualTransition

Add check for hasUAVisualTransition

With https://chromium-review.googlesource.com/c/chromium/src/+/5804907 being fixed, this can now be merged.