NIFI-6501: Add config to limit buffer queue size in CaptureChangeMySQL

Thank you for submitting a contribution to Apache NiFi.
Please provide a short description of the PR here:
Description of PR
Enables X functionality; fixes bug NIFI-YYYY.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:

[x] Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?

[x] Does your PR title start with NIFI-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.

[x] Has your PR been rebased against the latest commit within the target branch (typically master)?

[x] Is your initial contribution a single, squashed commit? Additional commits in response to PR reviewer feedback should be made on this branch and pushed to allow change tracking. Do not squash or use --force when pushing to allow for clean monitoring of changes.

For code changes:

[x] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder?
[ ] Have you written or updated unit tests to verify your changes?
[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[ ] If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly?
[ ] If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly?
[x] If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties?

For documentation related changes:

[x] Have you ensured that format looks appropriate for the output in which it is rendered?

Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.

@ijokarumawak kindly review this PR.

Next time, when you submit a new PR, please start creating a local branch from the latest master, in order to submit a clean PR.  It fixes a major bug that is still present in the current version of NiFi
@pushpavanthar @ijokarumawak


Provide the ability to configure --cache and --max-sql-memory

Also bump the version used by a test, since these flags are only in 1.1
cockroachdb releases.

LGTM although I am absolutely not familiar with this.

Yeah, I'm sorry to ask you, but we don't have anyone familiar with it right now.


download problems due to website change tele5.de

Could not download. Last saturday no problems...
H:[...]>youtube-dl.exe --no-check-certificate -v https://tele5.de/mediathek/fargo/das-krokodil-dilemma/
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['--no-check-certificate', '-v', 'https://tele5.de/mediathek/fargo/das-krokodil-dilemma/']
[debug] Encodings: locale cp1252, fs mbcs, out cp850, pref cp1252
[debug] youtube-dl version 2021.12.17
[debug] Python version 3.4.4 (CPython) - Windows-10-10.0.19041
[debug] exe versions: none
[debug] Proxy map: {}
[debug] Using fake IP <IP_ADDRESS> (DE) as X-Forwarded-For.
[Tele5] das-krokodil-dilemma: Downloading webpage
ERROR: Unable to extract jwplatform id; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; type  youtube-dl -U  to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.
Traceback (most recent call last):
File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmpupik7c6w\build\youtube_dl\YoutubeDL.py", line 815, in wrapper
File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmpupik7c6w\build\youtube_dl\YoutubeDL.py", line 836, in __extract_info
File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmpupik7c6w\build\youtube_dl\extractor\common.py", line 534, in extract
File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmpupik7c6w\build\youtube_dl\extractor\tele5.py", line 102, in _real_extract
File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmpupik7c6w\build\youtube_dl\extractor\tele5.py", line 95, in extract_id
File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmpupik7c6w\build\youtube_dl\extractor\common.py", line 1021, in _html_search_regex
File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmpupik7c6w\build\youtube_dl\extractor\common.py", line 1012, in _search_regex
youtube_dl.utils.RegexNotFoundError: Unable to extract jwplatform id; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; type  youtube-dl -U  to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.

Duplicate of #30499.


Remove SuppressWarning from msgs.hh to fix warnings

🦟 Bug fix

Fixes a bunch of warnings introduced in https://github.com/ignitionrobotics/ign-msgs/pull/243
Requires https://github.com/ignitionrobotics/ign-cmake/pull/234

Summary

Prevent the deprecated header from being included by anyone who includes msgs.hh.
This is technically not a soft tick, because someone relying on the suppression macros from msgs.hh would be broken, but I think there's probably zero people doing this.
Checklist

[x] Signed all commits for DCO
[ ] Added tests
[ ] Updated documentation (as needed)
[ ] Updated migration guide (as needed)
[x] codecheck passed (See contributing)
[x] All tests passed (See test coverage)
[x] While waiting for a review on your PR, please help review another open pull request to support the maintainers

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by messages.
🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸

Migration note updated in 0fbde9f


Tweak CI config a bit with yaml reference

Same as #1 but reopen PR to address https://github.com/mercari/RxRedux/pull/1#issuecomment-446089196.

Codecov Report

Merging #3 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master       #3   +/-   ##
=======================================
  Coverage   96.17%   96.17%
=======================================
  Files           2        2
  Lines         157      157
  Branches        5        5
=======================================
  Hits          151      151
  Misses          2        2
  Partials        4        4

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 a78a715...fc42963. Read the comment docs.


When will you share your code? Thanks.

Appreciate your work.

Appreciate your work.

Hi, code will be released around June 2022.

Waiting  for  it

Is cnn dead?

Is cnn dead?

No.

Code and models have been released.


Service bus Track 2 Performance test

This is for track 2 library

Identify benchmarking data

Setup performance test environment

Write test cases for performance test

Execute performance test and capture results

Duplicate of #9919


fix: add chinese language date translation

[x] fix: fix date translations

Closes #793

Please read this before review/merge changes


next manual, 2.18

Summary:
Corrections and suggestions for the manual after the 2.18 release should be included as comments and I'll fix them all before the next release.
Current Version:
v2.17.0

One of my labmates dug up a few issues.
Pg 194, Mixture Models, the model in the section "Estimating Parameters of a Mixture" needs a few updates to compile:
change ordered mu[K] to ordered[K] mu
change real log_theta[K] = log(theta) to vector[K] log_theta = log(theta)
change real lps[K] = log_theta to vector[K] lps = log_theta

Page 288, where it reads

If the variable u has a distribution, then logit(u)...

it should read

If the variable u has a Uniform(0, 1) distribution, then logit(u)...

I think.

On 27. Multiple Indexing and Range Indexing, it is stated in the manual that:
for (n in 1:N)
y[n] ~ normal(alpha[ii[n]] + beta[ii[n]] * x[n], sigma);
is equivalent to:
y ~ normal( rows_dot_product(alpha[ii] + beta[ii] , x), sigma);
is this correct?
Or should it be:
y ~ normal( alpha[ii] + rows_dot_product(beta[ii] , x), sigma);

Thanks, @Ctross---definitely a typo  --- the alpha[ii] should be on the outside.

From Dirk Nachbar on http://discourse.mc-stan.org/t/typo-page-77/3151

[ ] matirx[M, M] x; --- should be matrix

From http://discourse.mc-stan.org/t/reparameterization-example-in-manual/3199

[ ] vector[K] alpha = kappa * theta; shold be * phi
[ ] thank IambicPentameter (Discourse handle) for reporting

[ ] add the Ben Goodrich trick for sampling from a truncated distribution as implemented by lcomm (Discourse handle).  See:

http://discourse.mc-stan.org/t/rng-for-truncated-distributions/3122/7

From Trung Dung at http://discourse.mc-stan.org/t/a-typo-in-the-manual/3312
"I think this sentence in the manual 2.17.0, “Stan provides elementwise matrix division and multiplication operations, a .* b and a ./b.” should be changed to “Stan provides elementwise matrix multiplication and division operations, a .* b and a ./b.”

[ ] add general section in language spec on data declaration for arguments
[ ] add to section 2.16 "Control Parameters for ODE Solving" the constraint that the control parameters must be data and that if they are legal values, the result is an error
[ ] move subsection "Arguments to the ODE Solvers" in 48.3. Stiff Solver to its own section because it applies to all;

[ ] add that they throw errors if the values aren't legal for the control parameters

*[ ] fix the conflicting doc and clarifythat it really is the algorithm, but all our algorithms respect the rejection/error distinction
From @syclik:
We've got some conflicting doc now (stan reference 2.17.0). Appendix D says

An example warning message is an informational message about ill-formed input to an underlying function, which results in a Metropolis rejection during sampling or a reduction in step size for optimization, without causing a fatal error. An example error message is when either sampling or optimization cannot find a region of non- zero probability or when a program being parsed is ill formed. When an error arises, whatever program is running cannot continue and the entire execution must halt.

That's right, but could be made clearer. This conflicts with 26.2:

When an index is provided that is out of bounds, Stan throws a rejection error and computation on the current log density and gradient evaluation is halted and the algorithm is left to clean up the error.

Just noticed today that in Section 20.2 Coding an Algebraic System, the real[] x_i parameter of the function system should be int[] x_i.

Typo on page 294 of manual (in section 22.4): alpha = L + exp(my_vec_raw); --> alpha = L + exp(alpha_raw);

From @rbecerril on https://github.com/stan-dev/stan/issues/2469

[ ] fix integration bound in section 49.7, "Cumulative distribution functions"---it's listed as a lower bound of 0 rather than -infinity for the normal

[ ] add discussion of interpretation of Dirichlet prior from this discourse thread

data {
  int<lower = 1> K;
  real<lower = 0> alpha;
}
generated quantities {
  vector[K] theta = dirichlet_rng(rep_vector(alpha, K));
}

Here are the first 10 draws for alpha = 0.001.
iterations   [,1]   [,2]   [,3]   [,4]   [,5]   [,6]   [,7]   [,8]  [,9]  [,10]
      [1,] 3e-203  0e+00 2e-298 9e-106  1e+00  0e+00  0e+00  1e-47 0e+00 4e-279
      [2,]  1e+00  0e+00 5e-279  2e-14 1e-275  0e+00 3e-285 9e-147 0e+00  0e+00
      [3,] 1e-308  0e+00 1e-213  0e+00  0e+00  8e-75  0e+00  1e+00 4e-58 7e-112
      [4,] 6e-166  5e-65  3e-68 3e-147  0e+00  1e+00 3e-249  0e+00 0e+00  0e+00
      [5,]  2e-91  0e+00  0e+00  0e+00  1e-60  0e+00 4e-312  1e+00 0e+00  0e+00
      [6,] 1e-114  0e+00  0e+00 1e-231  1e+00 1e-302  4e-67  0e+00 0e+00  3e-16
      [7,] 3e-311  5e-53 3e-249  0e+00  1e+00 5e-309  0e+00  0e+00 0e+00  0e+00
      [8,] 9e-267  0e+00  1e+00  0e+00  4e-20  0e+00 5e-143 4e-147 2e-90  0e+00
      [9,]  1e+00  0e+00 3e-230 5e-100  0e+00 3e-234 7e-121  6e-76 0e+00  0e+00
     [10,]  0e+00 3e-173  2e-96 3e-164  1e+00  0e+00 4e-257 1e-178 0e+00  2e-06

Here are the first 10 draws for alpha = 1
iterations [,1] [,2] [,3] [,4]  [,5]  [,6]  [,7]  [,8]  [,9] [,10]
      [1,] 0.17 0.05 0.07 0.17 0.034 0.133 0.026 0.032 0.271  0.05
      [2,] 0.08 0.02 0.12 0.07 0.521 0.008 0.069 0.043 0.008  0.06
      [3,] 0.02 0.03 0.22 0.29 0.171 0.096 0.086 0.002 0.051  0.03
      [4,] 0.04 0.03 0.21 0.13 0.041 0.009 0.098 0.037 0.224  0.18
      [5,] 0.11 0.22 0.02 0.01 0.059 0.183 0.333 0.041 0.010  0.01
      [6,] 0.19 0.05 0.22 0.03 0.007 0.093 0.036 0.209 0.025  0.13
      [7,] 0.01 0.14 0.18 0.14 0.128 0.051 0.119 0.092 0.077  0.05
      [8,] 0.03 0.06 0.04 0.10 0.049 0.060 0.009 0.227 0.203  0.22
      [9,] 0.03 0.20 0.01 0.05 0.012 0.237 0.112 0.143 0.038  0.17
     [10,] 0.05 0.08 0.06 0.15 0.137 0.106 0.040 0.132 0.070  0.17

And here are the first 10 for alpha = 1000
iterations [,1] [,2] [,3] [,4] [,5] [,6] [,7] [,8] [,9] [,10]
      [1,]  0.1 0.10  0.1  0.1 0.10 0.10 0.10  0.1 0.10   0.1
      [2,]  0.1 0.10  0.1  0.1 0.10 0.10 0.11  0.1 0.10   0.1
      [3,]  0.1 0.10  0.1  0.1 0.10 0.10 0.10  0.1 0.10   0.1
      [4,]  0.1 0.10  0.1  0.1 0.10 0.10 0.10  0.1 0.10   0.1
      [5,]  0.1 0.10  0.1  0.1 0.10 0.10 0.10  0.1 0.10   0.1
      [6,]  0.1 0.10  0.1  0.1 0.10 0.10 0.09  0.1 0.11   0.1
      [7,]  0.1 0.10  0.1  0.1 0.10 0.09 0.10  0.1 0.10   0.1
      [8,]  0.1 0.09  0.1  0.1 0.10 0.10 0.10  0.1 0.10   0.1
      [9,]  0.1 0.11  0.1  0.1 0.09 0.10 0.10  0.1 0.09   0.1
     [10,]  0.1 0.10  0.1  0.1 0.10 0.10 0.10  0.1 0.10   0.1

As the parameter alpha increases, the simplexes produced are increasingly uniform.

Moved from #2470 submitted by Erik Erhardt:

[ ] on pl 48 in "Partial Array Assignment" section:  "as is is y" should be "as is y"

[ ] break out posterior inference chapter (?)
[ ] explain how to compute KL divergence from posterior to arbitrary density (not sure what it'd useful for)

[ ] explain @bgoodri's missing data trick

X == X_miss + X_obs

so
X * beta == X_miss * beta + X_obs * beta

and we can use csr_matrix_times_vector for the multiplies.

In the preface, under the "You Can Help" section, the Google user's group is mentioned as the preferred way of communication with the Stan team. Perhaps you want to link to the discourse forums now.

Thanks, @luisdamiano --- I'll get rid of it.  I thought I grepped and found the last of those, but apparently not.

In page 482, manual 2.17 "The pre-multiplication case is similar, with b * inv(m) being more efficiently coded as as a / m."
I think it should be "The pre-multiplication case is similar, with b * inv(m) being more efficiently coded as as b / m."

[ ] fix typo:
[ ] thank Gary Appleseed

From https://github.com/garyappleseed on https://github.com/stan-dev/rstan/issues/500:

real[] x_i should be int[] x_i

There is a typo showing code that won't work. This would be obvious to anyone who knew anything about these issues, but I didn't and it took me a lot of work and some guessing to get it. This was complicated by the fact that the error message wasn't very clear. Anyway, the manual has two lines in a row starting with real[], and the second one should be int[].

The manual states, "The conditional operator has the same behavior as the ifelse function in R." However, ifelse in R is vectorized, while the conditional operator is not (according to here). The statement of similarity between the two should be qualified to note this discrepancy since ifelse in R is used primarily for vectors.

From #PR2504  Language reference section, page 279, (line 765 of language tex):
"the number of rows of \code{a}" -> "the number of columns of \code{a}".

Correlation matrices, and their Cholesky factors are described before covariance matrices. Moving the sentence that motivates the use of Cholesky factors to the first part lends to better exposition:
index 6a9f0e618..ec9d9799b 100644
--- a/src/docs/stan-reference/language.tex
+++ b/src/docs/stan-reference/language.tex
@@ -792,7 +792,8 @@ unconstrained matrices, if their dimensions match, and vice-versa.
 \subsection{Cholesky Factors of Correlation Matrices}

 Matrix variables may be constrained to represent the Cholesky factors
-of a correlation matrix.
+of a correlation matrix. This is often more convenient or more
+efficient than representing correlation matrices directly.

 A Cholesky factor for a correlation matrix $L$ is a $K \times K$
 lower-triangular matrix with positive diagonal entries and rows that
@@ -827,9 +828,8 @@ $K$ is the value of the data variable \code{K}.

 \subsection{Cholesky Factors of Covariance Matrices}

-Matrix variables may be constrained to represent the Cholesky factors
-of a covariance matrix.  This is often more convenient or more
-efficient than representing covariance matrices directly.
+Akin to correlation matrices, matrix variables may be constrained to
+represent the Cholesky factors of a covariance matrix.

 A Cholesky factor $L$ is an $M \times N$ lower-triangular matrix (if
 $m < n$ then $L[m,n] =0$) with a positive diagonal ($L[k,k] = 0$) and

Correct Cholesky factor variable reference in the correlation part. Also add a reference to the underlying correlation matrices and used the latex capitalized sigma even though that seems non-standard in this section of the reference, did not check the rest.
diff --git a/src/docs/stan-reference/language.tex b/src/docs/stan-reference/language.tex
index ec9d9799b..b10c6750b 100644
--- a/src/docs/stan-reference/language.tex
+++ b/src/docs/stan-reference/language.tex
@@ -795,7 +795,7 @@ Matrix variables may be constrained to represent the Cholesky factors
 of a correlation matrix. This is often more convenient or more
 efficient than representing correlation matrices directly.

-A Cholesky factor for a correlation matrix $L$ is a $K \times K$
+A Cholesky factor $L$ for a correlation matrix $\Sigma$ is a $K \times K$
 lower-triangular matrix with positive diagonal entries and rows that
 are of length 1 (i.e., $\sum_{n=1}^K L_{m,n}^2 = 1$).  If $L$ is a
 Cholesky factor for a correlation matrix, then $L\,L^{\top}$ is a

hypergeometric_rng signature in manual is: int hypergeometric_rng(int N, real a, real b)
But it should be: int hypergeometric_rng(int N, int a, int b)
(source: https://github.com/stan-dev/math/blob/develop/stan/math/prim/scal/prob/hypergeometric_rng.hpp#L14)

In Sec 10.1 of the manual (p162), the AR(1) model is defined as
y[n] ~ normal(alpha + beta * y[n-1], sigma).
Just below there, the parameter alpha is defined as the intercept, but that is not correct. Rather, the intercept of the defined model would instead be
intercept = alpha / (1 - beta).
If you want to define the model in terms of an explicit intercept alpha, then it should be rewritten as
y[n] ~ normal(alpha + beta * (y[n-1] - alpha), sigma).

Thanks, https://github.com/mdscheuerell---I'll fix it for the next release.

section Stan Modeling Language /  Expressions /  Variables / Reserved Names
should include keyword target (is this part of the Stan language?  implementation?)

Include example of sum-to-zero with standard-normal marginals:
parameters {
  vector[N - 1] mu_prefix;
}
transformed parameters {
  vector[N] mu = append_row(mu_prefix, -sum(mu_prefix));
}
model {
  mu ~ normal(0, inv(sqrt(1 - inv(N))));
}

Also, a discussion of using QR to achieve sum-to-zero by Aaron Goodman in the Stan forums.

From @ksvanhorn in #2525
Summary:  One part of the manual says that integer division rounds towards 0, another says that it rounds down. These are inconsistent if one of the arguments is negative.
Description: In the intro to Section 40.1 "Integer-Valued Arithmetic Operations", it says "...integer division implicitly rounds the result... If one of the integer arguments to division is negative, the latest C++ specification (C++11), requires rounding toward zero." The example is given that -1 / 2 evaluates to 0
But on the next page, the documentation for operator/(int, int) says
operator/(x,y) = floor(x,y)

which is rounding down. That is, -1 / 2 evaluates to -1.
There may also be an issue with the documentation for operator%, which states
operator%(x,y) = x mod y = x - y * floor(x/y)

The manual (Section 3.3, subsection "Expressions as Bounds") that "Variables used in constraints can be any variable that has been defined at the point the constraint is used." But what if the variables are declared first, then defined later in the same block? For example,
transformed parameters {
  real alphap;
  real<lower=alphap> betap;
  alphap = sqrt(alpha);
  betap = alphap * beta;
}

The variable alphap has been declared, but not defined, at the point where we declare betap. However, Stan seems to be fine with this; the following program using the above block compiles and runs fine:
data {
  int N;
  vector[N] y;
}
parameters {
  real<lower=0, upper=1> alpha;
  real<lower=1> beta;
}
transformed parameters {
  real alphap;
  real<lower=alphap> betap;
  alphap = sqrt(alpha);
  betap = alphap * beta;
}
model {
  beta ~ pareto(1, 2);
  y ~ normal(betap, alphap);
}

It's not clear from the manual whether this is accidental or intended. It does seem to make sense, as the transformed parameters block used above should be equivalent to
transformed parameters {
  real alphap = sqrt(alpha);
  real<lower=alphap> betap = alphap * beta;
}

the key sentence here is tucked away in section Assigning Constrained Variables:

Checks are carried out at the end of each relevant block of statements to ensure constraints are enforced. This includes run-time size checks

This should also be copied into the discussion in section Constrained Data Types and we should include the above example (or something similar).

Thanks, @ksvanhorn.  I'll fix as follows.

[ ] fix language to say "declared" rather than "defined"
[ ] provide example of what @mitzimorris is saying about checks coming at end, using @ksvanhorn's example to illustrate
[ ] explain how parameter block is different in that the constraints define unconstraining transforms and that parameters (like data) are defined externally

The multivariate probit model specified in the manual (pages 157-160) doesn't compile. The error (for me at least) is in the functions block:
functions {
  int sum(int[,] a) {
  int s = 0;
  for (i in 1:size(a))
    s += sum(a[i]);
  return s;
  }
}

the function is called ‘sum’, which is also something else in C++ I believe so it errors when compiling. Changing the name (and where the function is used in the transformed data block) solved the issue.

@bob-carpenter is this a problem for the Stan compiler?
the parser incorrectly thinks sum(a[i]) is a recursive call, even though a[i] is a 1-d array.
adding forward declaration also fixes this problem,
functions {
  int sum1(int[,] a);

  int sum1(int[,] a) {
  int s = 0;
  for (i in 1:size(a))
    s += sum(a[i]);
  return s;
  }
}

@bob-carpenter - is this an error for Stan parser?

the parser should recognize that fn call sum(a[i]) has arg which is 1-d int array.
generated code suggests that parser isn't seeing indexing on a[i]

Apologies that was my fault as I assumed it was just a typo in the manual naming the function!

@samuel-watson Please continue to report wherever you think is appropriate.  We'd rather get reports than not get them.  The devs can deal with triage and moving things around if the root cause is known to be elsewhere.

[ ] fix to read tau < y for support
[ ] move 3/2 into exponent

Thanks, @pasjor.  I just dove into the code and verified that indeed it requires tau < y because it throws an excpetion if y <= tau.  It also has to be that way to be consistent with the formula as written.
And that it should be exponent 3/2 --- there's a 1.5 multipler in the code to match.
I'm not sure whether to trust the code to resolve the rest of the issues.  There are calls to sin that I can't make line up with the formula, either.  Anyone have a definitive read on what these should be?  I only see alpha being squared.
@syclik ---  The doc is a bit incomplete on this density in the code (math/prim/scal/prob/wiener_lpdf.hpp).  It also looks like it's missing a check for either tau < y or y < tau if that's supposed to be enforced.  It also has redundant check_not_nan calls.

Ok. Mind spawning a new issue?

The precedence of the range indexing operator ":" should be documented.   E.g., the sum-to-zero centering code example in section 9.7 contains expression:  beta[1 : K - 1] = beta_raw;
R users (and others) might think that ":" binds tighter than subtraction here, and would therefore write this as beta[1 : (K - 1)] = beta_raw;  - this isn't necessary, but this should be made clear in the section on range indexing.

@bob-carpenter:
As far as i know there are two equivalent formulas for the density (although they really dont look similar).
The first involves sin-functions and i guess that is the implementation you refer to. It appears though that the second formula is stated in the manual. Both formulas can be found in Navarro & Fuss (2009). Fast and accurate calculations for first-passage times in Wiener diffusion models.

This is how it's always devolved---multiple definitions and outside references I don't have the background to fully comprehenend.  If someone can give me a definitive set of definitions for everything that match our code, I'm happy to change the doc, which is what this issue is about.

I just got burned by inv(matrix) =/= inverse(matrix).
pg. 482 describes how to use matrix division instead, but gives inv(m) * a as an example instead of inverse(m) * a

Is map_rect documented already? We need to cover the function itself, explain MPI over threading precedence and maybe even give some recommendations on using this facility? For example, it's best to calculate the log-prob and one should watch a little bit for the order of job chunks as it determines how things are scheduled.

@wds15  Yes, map_rect is documented, but not the changes to how it's configured.  Is that something done at an OS level?  I may need to have you write these sections.  Alternatively, feel free to write up what you think needs to go in there and I can just insert and format if that's easier.

Page 518 from Stan Manual v2.17.0, section 52.3. Negative Binomial Distribution (log alternative parameterization).
"Stan Functions" is highlighted as a new section and is rendered as a numbered section 52.4. Stan Functions. It should be coded as an italic paragraph instead. This happens between the description for the functions neg_binomial_2_log and neg_binomial_2_log_lpmf.
Please, let me know if I'm not being clear.

@yizhang-cae  The matrix_exp function is documented in "Linear Algebra Functions and Solvers".  You can find all the functions in the index.

typo at page 255 v 2.17:
y ~ bernoulli_logit(a + f);
should be:
z ~ bernoulli_logit(a + f);

Section 21.5, second paragraph, last sentence:

In such cases, replacing the fixed prior with a hierarchical prior such as normal(mu, sigma), where mu and sigma are new parameters, with their own hyperpriors.

Either "replacing" should have been "replace", or the sentence isn't complete. Reading the paragraph is seems as if the last bit of the paragraph is missing, as the explanation for the suggested action is missing.


Change employment appeal tribunal decision sub-categories validation

Domain experts want employment appeal tribunal decision sub-categories not to be mandatory as some parent categories do not have any sub-categories.
Remove the validation requiring tribunal_decision_sub_categories be present.

This looks straight forward enough.  Merging.


Can't address into Type using path syntax

It's fairly common to be writing Types into Noms for the botrunner reg dataset, but paths have no way to descend into those.
Case in point:
> ./noms show db::foo/reg.value.inputs[0]@type'
Type

> ./noms show db::foo/reg.value.inputs[0]'
struct Photo {
  blob: Ref<Blob>,
  id: struct ID {
    owner: String,
    value: String,
  },
  orientation: Number,
}

> ./noms show db::foo/reg.value.inputs[0].blob
Object not found

There are 2 relevant complex types (see https://godoc.org/github.com/attic-labs/noms/go/types): struct types, and compound types.

It's logical to continue to use the .blob syntax for struct types, like I tried to do above.
We can use the [0] syntax for compound types, i.e. [0] would be the ref/set/list value type, and the map key type, and [1] would be the map value type.

@arv @aboodman

You could also use .elem and .key/.value but for some reason [0] and [1] seem more expected to me.

[n] would also be better for union types.

How would you address the name of a struct :( ?
@name I suppose. Annotations to the rescue again.
On Thu, Aug 17, 2017 at 7:15 AM Erik Arvidsson<EMAIL_ADDRESS>wrote:

[n] would also be better for union types.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/attic-labs/noms/issues/3622#issuecomment-323086689,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAE6BIgMZCqiZ8NC6pQ6nb9jVPQ9USiEks5sZEsNgaJpZM4O5n20
.

Does the name of the struct need to be addressed (for both struct values and struct types)?
If so I agree @name is the way to g.


Allow us to sort domain groups by all columns

Currently, domain groups are sorted by the "Group Name" column. The problem is that we cannot sort the groups by ID and/or Domain count.
Can we select the way the domain groups are sorted?

ad3df5e5d5bc33cdbcf2f953885740d495a42faf


Always replace with full-width character

Description of your pull request and other information
The ⧸ (U+29F8) is ugly and looks weird in my terminal so use ／ (U+FF0F) instead (like the comment above that code suggests).
Before submitting a pull request make sure you have:

[x] At least skimmed through contributing guidelines including yt-dlp coding conventions
[x] Searched the bugtracker for similar pull requests
[x] Checked the code with flake8 and ran relevant tests

In order to be accepted and merged into yt-dlp each piece of code must be in public domain or released under Unlicense. Check all of the following options that apply:

[x] I am the original author of this code and I am willing to release it under Unlicense
[ ] I am not the original author of this code but it is in public domain or released under Unlicense (provide reliable evidence)

What is the purpose of your pull request?

[ ] Fix or improvement to an extractor (Make sure to add/update tests)
[ ] New extractor (Piracy websites will not be accepted)
[x] Core bug fix/improvement
[ ] New feature (It is strongly recommended to open an issue first)

https://github.com/yt-dlp/yt-dlp/issues/4547#issuecomment-1972682765

⧸ looks good in the file viewer but kinda sucks in the terminal/editor while ／ looks bad in both. I guess no change is the lesser evil.

Pretty much. Also depends on what terminal/file explorer you are using and the fonts. If you don't like the default behavior, use --replace-in-metadata to get whichever you prefer.


Parallel GreatExpectationsOperator tasks corrupt great_expectations.yml

I have several GreatExpectationOperator tasks running concurrently. I would get an error often letting me know that the great_expectations.yml file could not be parsed. Inspecting the file, I noticed the file would normally have at the end of the file ult: false. It corresponded with the parsing error in the Airflow logs page of the task.
I suspect a race condition is happening when the great_expectations.yml file is generated due to needing to update the datasource section for a job. After changing GreatExpectationOperator tasks to run one at a time, the great_expectations.yml file has not been corrupted any longer.

Hi, is this an issue that maintainers are aware of? Is there some sort of workaround for this? Possibly preventing the great_expectations.yml from being overwritten when a GreatExpectationOperator task is run in Airflow?

Hey @antelmoa  I haven't encountered the issue you mentioned. Could you please share the error stack trace? Additionally, it would be great if you could provide some details on how you're using it. This information would be helpful for debugging. Thank you!

Hi, sorry for the wait on this.

Could you please share the error stack trace? Additionally, it would be great if you could provide some details on how you're using it.

This is in my local environment. I have a DAG that is running three GreatExpectationsOperator tasks at the same time. Please see my attached image.

If you notice the runs on the left, two runs were successful, but then the latest run failed. The failed tasks had the following error:
[2024-03-22, 20:49:57 UTC] {{base.py:1716}} ERROR - Error while processing DataContextConfig: n_result
[2024-03-22, 20:49:57 UTC] {{base.py:145}} ERROR - Encountered errors during loading config.  See ValidationError for more details.
[2024-03-22, 20:49:57 UTC] {{taskinstance.py:2728}} ERROR - Task failed with exception
Traceback (most recent call last):
  File "/venv/lib/python3.9/site-packages/airflow/models/taskinstance.py", line 444, in _execute_task
    result = _execute_callable(context=context, **execute_callable_kwargs)
  File "/venv/lib/python3.9/site-packages/airflow/models/taskinstance.py", line 414, in _execute_callable
    return execute_callable(context=context, **execute_callable_kwargs)
  File "/venv/lib/python3.9/site-packages/great_expectations_provider/operators/great_expectations.py", line 586, in execute
    self.data_context = ge.data_context.FileDataContext(
  File "/venv/lib/python3.9/site-packages/great_expectations/data_context/data_context/file_data_context.py", line 66, in __init__
    self._project_config = self._init_project_config(project_config)
  File "/venv/lib/python3.9/site-packages/great_expectations/data_context/data_context/file_data_context.py", line 111, in _init_project_config
    project_config = FileDataContext._load_file_backed_project_config(
  File "/venv/lib/python3.9/site-packages/great_expectations/data_context/data_context/file_data_context.py", line 213, in _load_file_backed_project_config
    return DataContextConfig.from_commented_map(
  File "/venv/lib/python3.9/site-packages/great_expectations/data_context/types/base.py", line 139, in from_commented_map
    config: Union[dict, BYC] = schema_instance.load(commented_map)
  File "/venv/lib/python3.9/site-packages/marshmallow/schema.py", line 722, in load
    return self._do_load(
  File "/venv/lib/python3.9/site-packages/marshmallow/schema.py", line 908, in _do_load
    self.handle_error(exc, data, many=many, partial=partial)
  File "/venv/lib/python3.9/site-packages/great_expectations/data_context/types/base.py", line 1717, in handle_error
    raise gx_exceptions.InvalidDataContextConfigError(
great_expectations.exceptions.exceptions.InvalidDataContextConfigError: Error while processing DataContextConfig: n_result

I went to the great_expectations.yml file and these were the contents at the end of the file:
anonymous_usage_statistics:
  data_context_id: 23027672-4b48-4dc5-9b58-59d10d75164a
  enabled: false
notebooks:
include_rendered_content:
  globally: false
  expectation_suite: false
  expectation_validation_result: false
n_result: false

Not the n_result:false at the end which is what the stack trace mentioned as the issue. I suspect since this file gets updated dynamically, eventually the tasks corrupt the configuration.


Update anti-virus-optimization-for-windows-containers.md

Hi @bprakash, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. Real humans will now evaluate your PR.

TTYL, MSBOT;

@bprakash: thanks for the PR, the change should appear on the rendered page now.
@EliotSeattle fyi


Release notes for 1.10a11

Pushing out another alpha release because it fixes a permissions issue.
https://github.com/simonw/datasette/milestone/32

https://github.com/simonw/datasette/issues/2279
https://github.com/simonw/datasette/issues/2278
https://github.com/simonw/datasette/issues/2263

https://github.com/simonw/datasette/compare/1.0a10...103b4decbd2350a74da09b61bc3b26159b9159a2

Now live here: https://docs.datasette.io/en/latest/changelog.html#a11-2024-02-19


Add Terminals-Are-Sexy (to Development-Environment)

Terminals Are Sexy
https://github.com/k4m4/terminals-are-sexy

A curated list of Terminal frameworks, plugins & resources for CLI lovers.

GitHub Repo: here
Project Site: here
(NOTE: I have included a travis-ci badge, implemented to run with the awesome_bot for link validation purposes.)
By submitting this pull request I confirm I've read and complied with the below requirements.
Failure to properly do so will just result in the pull request being closed and everyone's time wasted. Please read it twice. Most people miss many things.

I have read and understood the contribution guidelines and the instructions for creating a list.
This pull request has a descriptive title. For example, Add Name of List, not Update readme.md or Add awesome list.
The entry in the Awesome list should include a short description about the list project/theme (not the list itself), and should be added at the bottom of the appropriate category.
The list I added

has been around for at least 30 days,
is the result of hard work and is the best I could possibly produce,
is a non-generated Markdown file in a GitHub repo,
is not a duplicate,
includes a succinct description of the project/theme at the top (example),
includes a project logo/illustration (whenever possible) at the top right of the readme (example). (The logo should link to the project website or any relevant website. The logo should be high-DPI, so set it to maximum half the width of the original image.),
only has awesome items with descriptions (Awesome lists are curations of the best, not of everything),
contains the awesome badge on the right side of the list heading,
has a Table of Contents section named Contents as the first section,
has an appropriate license (Meaning something like CC0, NOT a code licence like MIT, BSD, Apache, etc) (If you use a license badge, it should be SVG, not PNG),
has contribution guidelines,
has been checked for inconsistent formatting, spelling, and grammar:

Each link description starts with an uppercase character and ends with a period.
Drop all the A / An prefixes in the descriptions.
Consistent naming. For example, Node.js, not NodeJS or node.js.

Not followed:

Drop all the A / An prefixes in the descriptions.
Has an appropriate license (Meaning something like CC0, NOT a code licence like MIT, BSD, Apache, etc) (If you use a license badge, it should be SVG, not PNG)
Does not include a travis badge.

Also, make sure to linkify all of the parts of the table of contents and add the topics awesome, awesome-list, and list.

All done.

[X] Drop all the A / An prefixes in the descriptions.
[X] Has an appropriate license (Meaning something like CC0, NOT a code licence like MIT, BSD, -Apache, etc) (If you use a license badge, it should be SVG, not PNG).
[X] Does not include a travis badge.
[X] Add the topics awesome, awesome-list, and list.

@legodude17

Last thing is that some of the parts of the Contents section are not links. I think it would be better if they were. E.g. the parts under the Shells heading in the Contents section.

That wouldn't work since those parts are not headings, and thus could not be referenced by link.
@legodude17

That wouldn't work since those parts are not headings, and thus could not be referenced by link.

Just remove them from the Table of Contents.
Terminals Are Sexy should also not be in the TOC.

stackoverflow => Stack Overflow
Everything on zsh. => Everything on ZSH.
OS X => macOS
Mac OS X => macOS

The Other Sexy Lists has many unrelated lists, like awesome-python, awesome-sec-talks, public-apis, seclists, security-cheatsheets. They are just noise. Focus on linking to relevant lists and resources.

Descriptions should not start with the link name:
iTerm2 is a terminal emulator for Mac OS X that does amazing things. => Terminal emulator for Mac OS X that does amazing things.

All done.

[x] Remove subheadings from the Table of Contents.
[x] Remove Terminals Are Sexy from the Table of Contents.
[x] stackoverflow => Stack Overflow
[x] OS X => macOS
[x] Mac OS X => macOS
[x] Remove unrelated lists from Other Sexy Lists
[x] Remove projects' names from descriptions

Note: https://github.com/sindresorhus/awesome/pull/911/files#r112407029

ping

Added :)

Apologies for the delayed response. Thanks for the merge! :) @sindresorhus


wasmtime: Remove redundant epoch check on function entry

The epoch interruption implementation caches the current deadline in a register, and avoids reloading that cache until the cached deadline has passed.
However, the first epoch check happens immediately after the cache has been populated on function entry, so there's never a reason to reload the cache at that point. It only needs to be reloaded in loops. So this commit eliminates the double-check on function entry.
When Cranelift optimizations are enabled, the alias analysis pass correctly detected that this load was redundant, and the egraph pass optimized away the icmp as well. However, since we don't do conditional constant propagation, the branch couldn't be optimized away. On x86 this lowered to a redundant cmp/jae pair of instructions in every function entry, which this commit eliminates.
To keep track of what code we're generating for epoch interruptions, I've also added disas tests with a trivial infinite loop.

Ah, I've wondered where that stray branch came from but never tracked it down -- thanks for finding this!


[RESTEASY-1998] Prepare test for resteasy.preferJacksonOverJsonB property for client on deployment

Prepare test for resteasy.preferJacksonOverJsonB property for client on deployment
Jira: https://issues.jboss.org/browse/RESTEASY-1998
Master PR: https://github.com/resteasy/Resteasy/pull/1668

retest this please

@asoldano Test errors on Travis are irrelevant

Superseded by #1733


ClockPanel: fix background color not working

The ColorPicker applies the colour name (red, blue, yellow, etc) as a string to background-color which works for standard colour names as they're css color keywords. Picking anything else results in a grey background.
This is a second (more compatible) approach based on the feedback I received in my original attempt (#93) to fix this.
Fixes: #92
I've struggled to get this working for anything less than 7.3 in this branch due to changes in getColorForTheme the types so pinned everything to that version. I'm not sure how best to approach that if we want to continue to support 7.0+. 🤔

Tested with Grafana 8.0.1 : fixed - Thanks.


First notebook tutorial

Adresses #70
I am creating a notebook that covers the configfile setup in detail, fits a simple transit, calculates a set of limb darkening coefficients, provides a simplified example of the whole marginalisation procedure and has some final notes about how to run the main script.

As it turns out, the false plot at the end of the notebook was wrong because it was plotting the initial model before plotting it as opposed to plotting a fit model. This was due to the fact that we reset the transit model after each fit, which means that once the loop of all fits is complete, the model got reinitialized.
I have moved the model reset to the top of the fitting loop (which makes more sense anyway, as you want to make sure your model is reset to the input parameters before you perform the fit) and I opened a new issue #88 to evaluate whether we want to move this reset to the top of the fitting also in our main script marginalisation.py. I think the answer is yes, but in that script we access all fit parameters through the diagnostics arrays rather than the model directly, so it's not an issue (yet?).
As for the very last section of the notebook, this was intended to be a primer and general instructions on how to run the full code. I don't think any specific examples make much sense in that part, as we covered those in the initial parts of the notebook. I can see though how this last bit looks very sad and lonely and confusing though, @hrwakeford do you have any ideas on how to make that last bit a little clearer? This would probably be best in not a notebook, but since we didn't set up any documentation yet apart from the readme and this tutorial, it doesn't really have anywhere else to live and I do think it is useful to have it somewhere, albeit maybe in a slightly different form.

@hrwakeford I fixed some more typos but will leave this to you now if you want to make some changes. I won't touch this until we have consulted over what to do with that last section in the notebook.

With regards to the last part of the notebook I think that we should keep it there but make it look a little different. We can deal with that on the next review.

Concerning the error in the notebook, can you confirm that this does not happen when you run the notebook for the first time after opening it? I can recreate the error when I run the notebook fully once, and then try to use Cell --> Run all again.
This is because the very first cell with code uses a relative path to find the repository in the first place. When this cell is run a second time, the relative path puts you in the wrong place, since it's been run twice now. I can fix this by adding a cell to define a function that always finds the correct absolute path. The alternative is to write in bold red letters not to run that cell twice, but I think I prefer the first option.
As for the data, that is an easy fix. However, do we want data that has a relatively obvious global slope in it, like we have it now? I can drop in the data you provided very easily, would you want me to sneak in a linear slope into that? @hrwakeford

@hrwakeford I have added a warning to not run the import cell twice as the functions I wanted to use to get the absolute path to the notebook location only gave me errors.
As for the new data in the notebook, do you want me to add a linear slope to the data you posted above (see my comment above)?

I have made some changes to the notebook and pushed those.
The changes include:

descriptions of limb-darkening to include reference to stellar model not limb-darkening models, and stellar parameters not limb-darkening parameters. (These can stay as referenced in the config file I just want to make sure the documentation is done).
Changed the data_y array to the new one computed, including a different random_scatter array that adds simple gaussian noise instead of structured noise. This will keep it simpler for the two examples in the notebook. The data_y also now contains a slight slope that is not fit in the first run but is in the second one so the comparative description is accurate.
small typos.

@hrwakeford this is good to go now. If you approve the changes, feel free to merge this PR.

I also left the outputs in the notebook - this is usually not a good idea since the figures in notebooks are giant, but since this is our only tutorial notebook, we might want to keep the outputs visible without having to run it.


Several syntax-highlighting enhancements

In a nutshell, I took what Aiden Reilly started with redefining the AsciiDoc syntax into the new .sublime-syntax format and finished all of the commented out "to-do"s.

I'll need some time to review all your PRs in detail, hopefully I'll manage later on in the day, once I've finished dealing with an ongoing work.
I'm quite reluctant to accept PRs directly in master and I'd prefer them to go in the dev branch, so that before they end up being used in production by users of this package we have a chance to test everything well and polish documentation, etc. I also tend to make my commits on dev first, until I'm happy that the new features are ready to be finalized into master.
Also, I see that all PRs (#12, #13 and #14) are failing the Travis CI build, which means that there are issues with code styles formatting. I haven't yet had the chance to look into the details, but I can see that the Travis build log for this PR is reporting formatting issues with the following files:
~~~ ERROR! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The following files didn't pass the validation test:

Color_Schemes/AsciiDoc_Base16.sublime-color-scheme
Color_Schemes/AsciiDoc_DarkViolet.sublime-color-scheme
Color_Schemes/AsciiDoc_Equilibrium_Gray_Light.sublime-color-scheme
Syntaxes/Asciidoctor.sublime-syntax

Run ECLint locally for detailed information about the problems.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/// Aborting All Tests ///

I'll just close this outright and re-submit a new PR against dev.


Add seconds after epoch to copr rpms to tie break versioning

Signed-off-by: baude<EMAIL_ADDRESS>

LGTM

LGTM

@rh-atomic-bot r+


Minor changes

Added change from MVC_SPEC-64 to changelog
Added a Facelets hello world example
Clarified that CDI support is only optional for view engines not implementations

Awesome! Thanks a lot! Look great! One question though:
I'm a bit surprised that the <h:* tags work as expected. My impression was, that only the <ui:* Facelets tags work as expected. But I never tried this to be honest. It feels weird to use JSF components for rendering the MVC view.

Thanks for the hint! I started a discussion in the mvc-spec users-list.

I moved the Facelets commit to PR #11.

I just merged this one. I had to merge manually because of merge conflicts in the PDF file. But everything looks fine so far. Thanks a lot!


Using specific opencv-submodule headers and support for opencv 2 &  3

Hi,
I tried to compile today AKAZE and I had problems. I use to have different opencv installations with different sub-modules enabled (depending on the needs of the specific project). So, if you try to include the general   opencv.hpp header and you don't have installed some of the sub-headers listed in that file, the compilation fails (Actually, that could be considered like a opencv bug ... I will take a look in order to see if that's reported).
Then the call to cv::ORB::create() with several arguments also gave me problems with the last versions of opencv2. I think that the current version is suitable only for opencv3 (that it's still in beta version). I know that the API of the features2d module has been changing a lot in the last months/years, but I think it's a good idea to be keep compatibility with the opencv2 version.

Thanks for the pull request. When moving to AKAZE 1.5 I changed the code for OpenCV 3.0. But I guess it does not hurt to have some compatibility with previous OpenCV versions.

Sure, it was a pleasure to do this small contribution. I also want to congratulate you for the feature detector & descriptor you have developed. I've found your publications about this topic really interesting :)


oh-my-zsh: 2022-07-26 -> 2022-08-10

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for oh-my-zsh is: "A framework for managing your zsh configuration"
meta.homepage for oh-my-zsh is: "https://ohmyz.sh/"
meta.changelog for oh-my-zsh is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2022-08-10 with grep in /nix/store/knc1p5rch84smzqdk0b536nbjgfrkb2c-oh-my-zsh-2022-08-10
found 2022-08-10 in filename of file in /nix/store/knc1p5rch84smzqdk0b536nbjgfrkb2c-oh-my-zsh-2022-08-10

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
oh-my-zsh

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/knc1p5rch84smzqdk0b536nbjgfrkb2c-oh-my-zsh-2022-08-10 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A oh-my-zsh https://github.com/r-ryantm/nixpkgs/archive/8180b124bf8690ff3455c7def3832cd68727fb3e.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/knc1p5rch84smzqdk0b536nbjgfrkb2c-oh-my-zsh-2022-08-10
ls -la /nix/store/knc1p5rch84smzqdk0b536nbjgfrkb2c-oh-my-zsh-2022-08-10/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

oh-my-zsh

Maintainer pings
cc @NeQuissimus for testing.

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

1 package built:

oh-my-zsh


Support arrow local functions

Fixes # .
Changes proposed in this pull request:

The feature this implements is to support expression bodies in local functions (two C#7 features together).


[Feature] Add attribute in device tracker "connected_in" (Node in Aimesh)

The problem
Is it possible to add an attribute in device_tracker that shows which node (Aimesh) the device is connected ?
This would help a lot in bayesian sensors for presence detection or device balancing
Specific device(s)?
No response
Firmware type
No response

Hello, @wallacemreis,
Thanks for your feedback! 👍🏻
The full AiMesh functionality is planned for the integration. Unfortunately, I still don't have a second device for all the needed tests, so I cannot yet guarantee any timeframe. But it will be implemented. I'll check if a node attribute for the device_tracker can be implemented sooner.

Please, check the new version 0.17.0 of the integration which implements some of the AiMesh features. More details here

The AiMesh functions in 0.17.0 are good. I'd love the feature that @wallacemreis requests as well, and this looks like a promising start.
A question out of curiosity, the "level" attribute that is displayed on my AiMesh nodes is always 0. What does it mean?

@dennisgranasen,
Hello. Actually, device trackers already have attribute showing which node they are connected to. It's called node and shows the MAC address of the node.
The level is literally the level in the AiMesh hierarchy. The main router is always 0. All the nodes connected with a wired connection are also 0 (by AiMesh definition). Nodes connected wirelessly to level 0 (parents) are level 1 (children). The next children will be level 2 and so on.
In case all of your nodes are level 0 - I suppose - they are connected in the wired mode? If not, please, open a new issue regarding the topic.

Wow, thanks. I failed to notice that attribute on device trackers, that's
great!
You are right that my mesh nodes use a wired backbone, so level 0 is
correct then! Thanks for clarifying. Perhaps this information should be in
the wiki, or maybe it is too obvious to everyone but me?
Den tis 10 jan. 2023 kl 16:41 skrev Yevhenii Vaskivskyi <
@.***>:

@dennisgranasen https://github.com/dennisgranasen,
Hello. Actually, device trackers already have attribute showing which node
they are connected to. It's called node and shows the MAC address of the
node.
The level is literally the level in the AiMesh hierarchy. The main router
is always 0. All the nodes connected with a wired connection are also 0
(by AiMesh definition). Nodes connected wirelessly to level 0 (parents)
are level 1 (children). The next children will be level 2 and so on.
In case all of your nodes are level 0 - I suppose - they are connected in
the wired mode? If not, please, open a new issue regarding the topic.
—
Reply to this email directly, view it on GitHub
https://github.com/Vaskivskyi/ha-asusrouter/issues/203#issuecomment-1377462019,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJNC63ATBELOUSVLQAPPGDLWRV7JNANCNFSM572HGNLA
.
You are receiving this because you were mentioned.Message ID:
@.***>

@dennisgranasen,
Unfortunately, I did not have time yet to add all the details to the documentation - development itself and debugging is taking too much time to fit into 24 hours. But I will add this info as well as some more soon

You are doing great work Yevhenii!

I think we can close this issue


BUG: (Rare) corner case in ivp with terminating events

Describe your issue.
I am performing several millions of integrations with solve_ivp and I am occasionally stumbling upon what I think is an edge case that is not being handled.
The error is raised by the constructor of OdeSolution, here:
https://github.com/scipy/scipy/blob/ece78377d322f891b1ca2d248ac82caa3411837e/scipy/integrate/_ivp/common.py#L156-L159
Specifically, I found that the last two entries in ts are identical. Let's see how that comes to be.
The array that is fed to the constructor of OdeSolution is called ts in the solve_ivp function is ivp.py. ts is built by taking the old and the new timestep returned by the integration. If there's a terminating event, ts also is extended with the time and value of the event itself:
https://github.com/scipy/scipy/blob/ece78377d322f891b1ca2d248ac82caa3411837e/scipy/integrate/_ivp/ivp.py#L621-L630
Now, the corner case arises when the value that satisfies the event equation is the one of the bracketing values for the root finder.
Now, this seems extremely unlikely. In practice, I found this can happen when the event equation dramatically changes behavior near the termination condition.
I suspect the problem might manifest itself in the other branch of the if t_eval is None statement.
I can open a PR to fix this bug if someone guides me in how to address it properly.
Reproducing Code Example
Code is too complex to report here.

Error message
Traceback (most recent call last):
  File "/home/u20/gabrielebozzola/.cache/pypoetry/virtualenvs/kray-ZRW9TZmG-py3.8/bin/kray", line 5, in <module>
    main()
  File "/home/u20/gabrielebozzola/kray/kray/kray.py", line 66, in main
    args.func(args)
  File "/home/u20/gabrielebozzola/kray/kray/kray_ray_trace.py", line 93, in ray_trace
    affine_parameters, ray = ray_trace_one(
  File "/home/u20/gabrielebozzola/kray/kray/ray_tracing.py", line 288, in ray_trace_one
    solution = solve_ivp(
  File "/home/u20/gabrielebozzola/.cache/pypoetry/virtualenvs/kray-ZRW9TZmG-py3.8/lib/python3.8/site-packages/scipy/integrate/_ivp/ivp.py", line 666, in solve_ivp
    sol = OdeSolution(ts, interpolants)
  File "/home/u20/gabrielebozzola/.cache/pypoetry/virtualenvs/kray-ZRW9TZmG-py3.8/lib/python3.8/site-packages/scipy/integrate/_ivp/common.py", line 157, in __init__
    raise ValueError(f"`ts` must be strictly increasing or decreasing.")
ValueError: `ts` must be strictly increasing or decreasing.

SciPy/NumPy/Python version information
1.8.0 1.22.3 sys.version_info(major=3, minor=8, micro=2, releaselevel='final', serial=0)

There could be more to it than what you described. brentq includes the bracketing values in the root-finding process. So, say the initial-value problem integration goes from t1 to t2, the root is at t1 < t3 < t2, t_old = t3 - Δt and t = t3. brentq should then find t = t3 as a root and solve_ivp will stop the integration accordingly. However, it seems that this is not the case and the integration proceeds further, only to terminate at the next step. Could it be that there is a rounding approximation when assembling ts, such that t3 + dt, which is the real root, becomes t3?

There could be more to it than what you described. brentq includes the bracketing values in the root-finding process. So, say the initial-value problem integration goes from t1 to t2, the root is at t1 < t3 < t2, t_old = t3 - Δt and t = t3. brentq should then find t = t3 as a root and solve_ivp will stop the integration accordingly. However, it seems that this is not the case and the integration proceeds further, only to terminate at the next step. Could it be that there is a rounding approximation when assembling ts, such that t3 + dt, which is the real root, becomes t3?

I don't think so, I printed out values to see and I didn't find hints of numerical issues. I think what's happening is that brentq finds that the root is at t_old, so ts will have two copies of it.

But t_old has to be t of the previous step. So why did not brentq find t of the previous step as a root?

But t_old has to be t of the previous step. So why did not brentq find t of the previous step as a root?

I think that this has to do with the character of the terminating equation. When I print out that value of the equation I find that it is not 0, but -1e-3, while at t it is a large positive number. I guess brentq cannot find the correct root in here.
Suppose your equation were ln(y) and your integration is driving y towards 0. If you have a terminating condition for y = 0, you'll run into troubles. My case is similar as in everything is well defined and nice on one side, and not necessarily as nice on the other.

Are you using LSODA as your solver ? It is known that the curre t pyrgon interface does not handle correctly the dense output (e.g. tile interpolation between each step). Since this dense output is used by Brentq to find the time at which an event is triggered. It may happen that you end up having an event which is always true in the last time step, simply because the dense output is wrong.
If that's the case, you can try other solvers, e.g. BDF or RK45 which do not suffer from this issue.

Are you using LSODA as your solver ? It is known that the curre t pyrgon interface does not handle correctly the dense output (e.g. tile interpolation between each step). Since this dense output is used by Brentq to find the time at which an event is triggered. It may happen that you end up having an event which is always true in the last time step, simply because the dense output is wrong. If that's the case, you can try other solvers, e.g. BDF or RK45 which do not suffer from this issue.

Yes, I think that this was with LSODA and the problem did not occur with RK45 and the same integration.

I believe this issue should have been closed by gh-14552.

I've been having the same issue with method="Radau" and method="DOP853".


Only background image in riv asset is visible in rive texture unity. Foreground Images are not read.

rive animation with a background png image, an animated trim path and foreground png image on top of the path and background image.
when this is imported into flutter rive skia renderer (or impeller) the foreground is read and rendered on top of everything.
When imported into rive unity the foreground image is not read and rive texture is just background and path.

only happens with jpg and psd.


State docs example is (currently) inaccurate

The docs example for problems with self-referential state updates claims the compiler gives up and displays 4, which it probably did in the past, but it now gives up and displays 5.
There is also a tense issue in the line, "This example display 4 because Typst simply gives up after a few attempts."

This is seemingly not an issue anymore, because the description no longer talks about 4.


feat: enhance cnpg_collector_pg_wal metrics for default exporter

This feature provides more value for metrics cnpg_collector_pg_wal in default exporter,
the goal is to provide an easy way to monitor the disk usage by relying on the WAL logic.
Closes: #1374
Signed-off-by: Tao Li<EMAIL_ADDRESS>

/test limit=local

/test limit=local

/test limit=local

/test limit=local

/ok-to-merge


Validate function gets called with old result

When using a validate function, it will always be called with the 1st submitted result that failed validation, even if subsequent results are in fact valid.
Example to reproduce:
import survey

def validator(value):
    if len(value) > 5:
        raise survey.widgets.Abort(f"Input {value} is too long!")

survey.routines.input('Provide input: ', validate=validator)

When initially providing the input '123456', it fails validation with the message:

Input 123456 is too long!

Subsequent valid inputs of length <= 5 will fail with the same message.
I believe the issue lies with survey.widgets.Widget._invoke_validate():
https://github.com/Exahilosys/survey/blob/e7d5e9803b312b8fca21960052c21f8b2d0b2437/survey/_widgets.py#L158-L163
After the validate() call, the result is marked as to be reevaluated again with self._product = self._product_mark. However, if validation raises an exception, this line is never reached. Maybe having this in a try-finally clause would work as intended?

An alternative solution could be to return a boolean instead raising an exception from the validation logic. This would make the code flow a bit easier to understand.
That would however be a significant API change... maybe left for a larger release than just a bug-fix.


Functionality to adjust exponential backoff associated with max_retries option

Confirm this is a feature request for the Python library and not the underlying OpenAI API.

[X] This is a feature request for the Python library

Describe the feature or improvement you're requesting
Functionality to adjust exponential backoff associated with max_retries option. Looking in the documentation it's stated that certain errors are automatically retried 2 times by default, with a short exponential backoff, if it's possible it's ideal to control the value of the exponential backoff either manually or should be dynamically associated with rate limited duration in case of a 429 error since just short exponential backoffs are not helpfull in this case!
Additional context
No response

If there is a response header retry-after: 5, for example, this library will wait 5 seconds before retry. Note there's also retry-after-ms: 4321 which would wait 4.321 seconds.
In case of a 429, OpenAI's API currently does this (for at least some kinds of 429s - please share if you encounter a request which doesn't) so it will indeed wait a usefully long period of time.
It is currently possible to configure the number of retries with max_retries, as documented in the readme.
I agree it would be nice to configure the base exponential wait, so I'll leave this ticket open, but in transparency I don't anticipate closing it soon.

hey @rattrayalex
Thanks for the response!
Correct if i am wrong but I have tried to look through the code and i have not found any kind of specific  exponential back off calculation  for 429 errors  here and here.
Looks like the maximum exponential back off will go is 60 seconds defined as a magic number bellow or else it's between INITIAL_RETRY_DELAY and MAX_RETRY_DELAY of values 0.8 and 8
def _calculate_retry_timeout(
        self,
        remaining_retries: int,
        options: FinalRequestOptions,
        response_headers: Optional[httpx.Headers] = None,
    ) -> float:
        max_retries = options.get_max_retries(self.max_retries)

        # If the API asks us to wait a certain amount of time (and it's a reasonable amount), just do what it says.
        retry_after = self._parse_retry_after_header(response_headers)
        if retry_after is not None and 0 < retry_after <= 60:
            return retry_after

        nb_retries = max_retries - remaining_retries

        # Apply exponential backoff, but not more than the max.
        sleep_seconds = min(INITIAL_RETRY_DELAY * pow(2.0, nb_retries), MAX_RETRY_DELAY)

        # Apply some jitter, plus-or-minus half a second.
        jitter = 1 - 0.25 * random()
        timeout = sleep_seconds * jitter
        return timeout if timeout >= 0 else 0
        ```

It's this code:
max_retries = options.get_max_retries(self.max_retries)

# If the API asks us to wait a certain amount of time (and it's a reasonable amount), just do what it says.
retry_after = self._parse_retry_after_header(response_headers)
if retry_after is not None and 0 < retry_after <= 60:
    return retry_after

When the API responds with a 429, it sends Retry-After and Retry-After-MS headers.

Got it!
I was referring to the use of  rate limit headers but i assume retry-after is more or less based on the bellow headers and others.
x-ratelimit-reset-requests    |	The time until the rate limit (based on requests) resets to its initial state
x-ratelimit-reset-tokens       |    The time until the rate limit (based on tokens) resets to its initial state.

Thanks!


Request location only when necessary in MapView

Details

Fixed Issues

$ https://github.com/Expensify/App/issues/36491
PROPOSAL: https://github.com/Expensify/App/issues/36491#issuecomment-1943937917
Tests

Make sure the location permission is unset and app is allowed to ask permission.
Click on '+' -> 'request money' -> 'distance tab'
Notice that we are prompted for location permission
Dismiss it without granting and continue after entering miscellaneous waypoints.
Make sure we are not prompted for location on the next page.
After creating request, try to edit distance
Make sure we are not prompted for location permission.

[x] Verify that no errors appear in the JS console

Offline tests

QA Steps

Make sure the location permission is unset and app is allowed to ask permission.
Click on '+' -> 'request money' -> 'distance tab'
Notice that we are prompted for location permission
Dismiss it without granting and continue after entering miscellaneous waypoints.
Make sure we are not prompted for location on the next page.
After creating request, try to edit distance
Make sure we are not prompted for location permission.

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

https://github.com/Expensify/App/assets/77237602/3ab28653-6383-46b6-abb6-5765c00672fb

Android: mWeb Chrome

https://github.com/Expensify/App/assets/77237602/0108b744-0120-4f78-86db-300900bb102e

iOS: Native

https://github.com/Expensify/App/assets/77237602/a9caf4ff-8e5c-4199-9e76-dd3d88d6b8c5

iOS: mWeb Safari

https://github.com/Expensify/App/assets/77237602/492bba4e-ea19-4ac4-9b8d-751917cd9711

MacOS: Chrome / Safari

https://github.com/Expensify/App/assets/77237602/92bd2745-a1f9-4c0d-8b3f-212c98e52dde

MacOS: Desktop

https://github.com/Expensify/App/assets/77237602/39cb636d-6b1b-42b3-9778-2ff61959d05d

Reviewer Checklist

[ ] I have verified the author checklist is complete (all boxes are checked off).
[ ] I verified the correct issue is linked in the ### Fixed Issues section above
[ ] I verified testing steps are clear and they cover the changes made in this PR

[ ] I verified the steps for local testing are in the Tests section
[ ] I verified the steps for Staging and/or Production testing are in the QA steps section
[ ] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[ ] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[ ] I checked that screenshots or videos are included for tests on all platforms
[ ] I included screenshots or videos for tests on all platforms
[ ] I verified tests pass on all platforms & I tested again on:

[ ] Android: Native
[ ] Android: mWeb Chrome
[ ] iOS: Native
[ ] iOS: mWeb Safari
[ ] MacOS: Chrome / Safari
[ ] MacOS: Desktop

[ ] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[ ] I verified proper code patterns were followed (see Reviewing the code)

[ ] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[ ] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[ ] I verified that comments were added to code that is not self explanatory
[ ] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[ ] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[ ] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[ ] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[ ] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I verified that this PR follows the guidelines as stated in the Review Guidelines
[ ] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[ ] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[ ] All JSX used for rendering exists in the render method
[ ] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[ ] If any new file was added I verified that:

[ ] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[ ] If a new CSS style is added I verified that:

[ ] A similar style doesn't already exist
[ ] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)

[ ] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[ ] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[ ] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[ ] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[ ] If the PR modifies the form input styles:

[ ] I verified that all the inputs inside a form are aligned with each other.
[ ] I added Design label so the design team can review the changes.

[ ] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[ ] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[ ] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native

https://github.com/Expensify/App/assets/16493223/5e7be2d1-fb00-4235-8c4f-c3d430d57f0d

Android: mWeb Chrome

https://github.com/Expensify/App/assets/16493223/1de30c42-f579-48c2-ab69-588ac02682a2

iOS: Native

https://github.com/Expensify/App/assets/16493223/d664f3ab-70c1-4355-82db-e052e20b737f

iOS: mWeb Safari

https://github.com/Expensify/App/assets/16493223/2220ecae-bc8b-4a92-a18a-0e3576379025

MacOS: Chrome / Safari

https://github.com/Expensify/App/assets/16493223/1aef8bfd-63fe-4d21-945f-7ca04f6d7235

MacOS: Desktop

Please add missing screenshots / videos

@s77rt Added all the videos! Sorry for the delay.. Android simulator was (and still is) having issues

@esh-g Can you please check https://github.com/Expensify/App/pull/36761#discussion_r1495088668

@s77rt Replied!

Made the change @s77rt!

@esh-g Please run prettier (lint failing)

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/chiragsalian in version: 1.4.44-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/puneetlath in version: 1.4.44-13 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


votemute command

To avoid selfbots(in lounge), spammers with flashing emojis, injustice towards anyone, toxicity etc... Max mute value is 2 hours.

Finally

Btw how lond does tbe user get muted for?

member chooses for how long target will be muted for, 5 seconds to 2 hours

My concern is that we'd merge this command code so late that the new bot rewrite is then being used. Unless that has halted, new changes to the bot shouldn't be need, and instead be suggested to the new rewrite.

My concern is that we'd merge this command code so late that the new bot rewrite is then being used. Unless that has halted, new changes to the bot shouldn't be need, and instead be suggested to the new rewrite.

My concern is that we'd merge this command code so late that the new bot rewrite is then being used. Unless that has halted, new changes to the bot shouldn't be need, and instead be suggested to the new rewrite.

where rewrite

My concern is that we'd merge this command code so late that the new bot rewrite is then being used. Unless that has halted, new changes to the bot shouldn't be need, and instead be suggested to the new rewrite.

where rewrite

Whenever egg and Jamie finish it.


netdata: enable cgroup accounting

Motivation for this change
Fixes https://github.com/NixOS/nixpkgs/issues/29095
Not needed when https://github.com/NixOS/nixpkgs/pull/66984 get merged
Things done

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

[x] NixOS
[ ] macOS
[ ] other Linux distributions

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

I verified that cgroup accounting is actually enabled by:

build test vm with [davidak:~/code/nixpkgs]$ nix-build nixos/tests/netdata.nix -A driver
run test vm with result/bin/nixos-run-vms
login as root (empty password)
run systemd-cgtop (you should see RAM usage and maybe CPU when any process is doing anything)

@davidak can we add a generic test to nixos/tests/systemd.nix that checks if systemd.enableCgroupAccounting actually works, and to what extend?

@flokli sure, that would be great. but unrelated to this PR. can you create another issue or PR for that?

Fixed by https://github.com/NixOS/nixpkgs/pull/66984 \o/

We should probably still enable it in the module, so nix will complain to the user if they want to enable netdata, but manually disabled cgroup accounting.

@flokli good point!

Thanks!


context.getType is FILL_BUTTON when crafting from the craftables tab

The context type passed to recipe transfer handlers is FILL_BUTTON, even though the interaction originates from the craftables tab.
EMI version 1.1.3+1.20.4

Fixed in EMI 1.1.4


Correct typo in Title for tutorial-shadow-it.md

@jonade : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@jonade Thanks for your feedback. We've submitted a documentation change based on your suggestion, and the updated article should be live by tomorrow. Please let us know if there's anything more we can do for you. To follow up on this issue, leave us a comment with an @mention.


No way to register a class method as callback in the same class?

Steps to reproduce
Define a class within whose constructor method (new), try to register a method as callback:

vim9script

class MyClass
  this.job: job

  def new()
    this.job = job_start('cat', {
      out_cb: this.OnRequest, # <--- here
    })
  enddef

  def OnRequest(ch: channel, msg: string)
    echo msg
  enddef

endclass

=> E722: Missing comma in Dictionary: OnRequest,

If changed to out_cb: function('this.OnRequest'), => E475: Invalid argument: this.OnRequest

vim9script

def OnRequest(c: MyClass, ch: channel, msg: string)
  echo msg
  c.Do()
enddef

class MyClass
  this.job: job

  def new()
    this.job = job_start('cat', {
      out_cb: function(OnRequest, [this]),
    })
  enddef

  def Do()
  enddef

endclass

var t = MyClass.new()

=> E1010: Type not recognized: MyClass

vim9script

def OnRequest(c: any, ch: channel, msg: string)
  echo msg
  c.Do()
enddef

class MyClass
  this.job: job

  def new()
    this.job = job_start('echo a', {
      out_cb: function(OnRequest, [this]),
    })
  enddef

  def Do()
  enddef

endclass

var t = MyClass.new()

=>
Error detected while processing function <SNR>185_OnRequest:
line    2:
E715: Dictionary required

vim9script

def OnRequest(c: any, ch: channel, msg: string)
  echo msg
  c.Do()
enddef

class MyClass
  this.job: job

  def new()
    this.job = job_start('echo a', {
      out_cb: function(OnRequest, [], this),
    })
  enddef

  def Do()
  enddef

endclass

var t = MyClass.new()

=>
Error detected while compiling /home/lilydjwg/tmpfs/a.vim[22]..function new:
line    2:
E1013: Argument 3: type mismatch, expected dict<any> but got object<MyClass>

Expected behaviour
There should be a way to register class method as callback inside the class' method.
Version of Vim
9.0.1566
Environment
Arch Linux
Logs and stack traces
No response

Please try 9.0.1569 or later.  At least the first example appears to be fixed now.

With 9.0.1570, the same error is only delayed to the time when the class is initialized, e.g.
vim9script

class MyClass
  this.job: job

  def new()
    this.job = job_start('cat', {
      out_cb: this.OnRequest, # <--- here
    })
  enddef

  def OnRequest(ch: channel, msg: string)
    echo msg
  enddef

endclass

var c = MyClass.new()

And it's back.

A workaround with a bit of indirection
vim9script

class MyClass
  this.job: job

  def new()
    var CB = (ch: channel, msg: string) => this.OnRequest(ch, msg)
    this.job = job_start('cat', {
      out_cb: CB, # <--- here
    })
  enddef

  def OnRequest(ch: channel, msg: string)
    echo msg
  enddef

endclass

var c = MyClass.new()

Thanks, that worked!

closed by 29bb67f1beefc7fd393dbfd9ee77d92f1db3a3c0


Update/Add Clang 15.0.0+

Tool name
Clang
Tool license
Apache License v2.0 with LLVM Exceptions
Add or update?

[X] Add
[X] Update

Desired version
15.0.0+
Approximate size
676 MB
Brief description of tool
C-like languages use the Clang frontend. This component compiles C, C++, Objective-C, and Objective-C++ code into LLVM bitcode -- and from there into object files, using LLVM.
URL for tool's homepage
http://clang.llvm.org/
Provide a basic test case to validate the tool's functionality.
clang++ --version

Platforms where you need the tool

[X] Azure DevOps
[X] GitHub Actions

Runner images where you need the tool

[ ] Ubuntu 18.04
[ ] Ubuntu 20.04
[X] Ubuntu 22.04
[ ] macOS 10.15
[ ] macOS 11
[ ] macOS 12
[ ] Windows Server 2019
[ ] Windows Server 2022

Can this tool be installed during the build?
apt-get install -y clang-15 lldb-15 lld-15 clang-format-15 clang-tidy-15

Tool installation time in runtime
Approx. 5 minutes
Are you willing to submit a PR?
Yes if possible

Hey @IGR2014.
clang-15 is not available in Ubuntu 22.04 repos - https://packages.ubuntu.com/search?keywords=clang-15

Oh, so only 22.04 official packages for 22.04 ?
Thanks, got it...


Teacher: As a teacher I want to be able to publish/unpublish a assignment to create several in advance.

Support for front end implemented, back end missing - returning to backlog.


fix: reset invalid resources after successful invalidation

closes #10677
Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

[x] It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
[x] This message body should clearly illustrate what problems it solves.
[x] Ideally, include a test that fails without this PR but passes with it.

Tests

[x] Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

[x] If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

Hi, this PR is most likely the culprit for https://github.com/sveltejs/kit/issues/11461 (and maybe https://github.com/sveltejs/kit/issues/9355#issuecomment-1892067287) which triggers multiple (at least 2) versions of $page concurrently living in client even on a Svelte4 build, which is a quite sneaky bug I think more people are affected by it than reported (in our case it took several days for a user to report it despite careful inspection first).
Coincidentally or not this PR also solves https://github.com/sveltejs/kit/issues/10359 which I tried to debug a few days ago (before migrating to SK2 then noticing it was solved) and came to the same conclusion as @Rich-Harris  (invalidated.length = 0 in invalidate()) but it quickly appeared that it was messing with the invalidation of parent pages (ie not triggering) .
Before that PR the reset of invalidated happened after the navigation_result, see:
https://github.com/sveltejs/kit/blob/b2b1951e9004a263646154ce46b3fe85df48209d/packages/kit/src/runtime/client/client.js#L1063)
which had the effect of calling load_route twice (which triggered the double invalidation issue).
I don't know the history of the file but having the reset there instead of the obvious place this PR moves it felt like there was a reason for it (maybe this one).
The fix I found was to check if the parent had changed before flagging the dependencies to be invalidated :
if (!parent_changed) {
	for (const href of uses.dependencies) {
		if (invalidated.some((fn) => fn(new URL(href)))) return true;
	}
}

and let the reset where it was. I didn't do enough testing to make sure it was the right fix (although all tests seemed to pass) especially on this $page issue.
I could try to help if needed although my knowledge of client.js is quite limited!

The fix I found (in SK1) was to check if the parent had changed before flagging the dependencies to be invalidated in has_changed() :
// has_changed()
if (!parent_changed) {
	for (const href of uses.dependencies) {
		if (invalidated.some((fn) => fn(new URL(href)))) return true;
	}
}

and let the reset where it was. I didn't do enough testing to make sure it was the right fix (although all tests seemed to pass, although at least one seems to be missing).

@gterras  Did you find any fix in SK2?

Did you find any fix in SK2? The fix you sent only works if I remove the newly-added invalidated.length = 0;

Didn't have time to look into it yet (also not sure if a working PR would be acknowledged or awkwardly ignored by the team) but a fully working fix would definitely need more than that. Crucially it also needs least two tests first (double invalidation + unsync parent $page).
As said in my first comment the initial placement of the invalidation reset is weird enough to be there for a reason. I suspect invalidation has never really properly worked in SK history. This PR also doesn't remove the old reset which seems to be there "just in case" which seems to show invalidation logic is fully understood by no one.
I'll try to look into it soon if I find the time.


Activating autocomplete on first letter instead of third?

I find it really annoying that the autocomplete doesn't activate until the third letter is entered, is there a way to change this? Been looking through the issues but no one else seem to be as frustrated by this as I am, perhaps I've missed a setting somewhere?
Thanks in advance.

@chrillewoodz
The autocomplete directive has a min-length attribute that can be used to set the amount of characters required before the suggestions display.
http://mbenford.github.io/ngTagsInput/documentation/api#autoComplete

Just found it after I looked really hard one more time, but thanks for your reply! :)

just a note for anyone wondering: a min-length is also available on ng-tags-input but limits the length of newly input tags, which is not to be confused with the attribute on the auto-complete element.

<AutoCompleteTextView
        android:id="@+id/auto_complete_tv"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:completionThreshold="1"
        android:hint="Name" />

by android:completionThreshold="1" you can activate autocomplete on first letter instead of third


Feature/ref no

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

What is the current behavior? (You can also link to an open issue here)

What is the new behavior (if this is a feature change)?

Other information:

Please don't remove tests. Unit tests are very important to test various scenarios. I have attached a detailed guide how to setup data driven unit tests. Feel free to reach out to me in case of any issues.
Also the reference numbers can take multiple form. Need to think of an more exhaustive solution.


fixe meta robot proxy.html

change conent to content

yes, will add noindex meta tagsent from Android21.03.2019 4:59 PM codati<EMAIL_ADDRESS>napisał(a):change conent to content
—You are receiving this because you are subscribed to this thread.Reply to this email directly, view it on GitHub, or mute the thread.

and fix typosent from Android21.03.2019 10:41 PM Jakub Jankiewicz<EMAIL_ADDRESS>napisał(a):yes, will add noindex meta tagsent from Android21.03.2019 4:59 PM codati<EMAIL_ADDRESS>napisał(a):change conent to content
—You are receiving this because you are subscribed to this thread.Reply to this email directly, view it on GitHub, or mute the thread.

Fixed.

thank you (: