LU factorization in the linalg extension

It seems that many libraries that are candidates to implement the Array API namespace already implement the LU factorization (with variations in API and with the notable exception of numpy).
However LU is not part of the list of linear algebra operations of the current state of the SPEC:

https://data-apis.org/array-api/latest/extensions/linear_algebra_functions.html#objects-in-api

Are there any plans to consider it for inclusion?

Thanks for asking @ogrisel. I had a look through the initial issues which considered the various linalg APIs, and LU decomposition was not considered at all there. The main reason I think being that the overview started from what is present in NumPy, and then looked at matching APIs in other libraries.
I think it's an uphill battle for now. It would require adding it to numpy.linalg, moving it in other libraries with numpy-matching APIs (e.g., https://docs.cupy.dev/en/stable/reference/scipy_linalg.html#decompositions is in the wrong place), and then aligning on APIs also with PyTorch & co. Finally, there's lu but also lu_solve and lu_factor - would it be just one of those, or 2/3?
It seems to me that LU decomposition is important enough that it's worth working on. So we could figure out what the optimal API for it would be, and then adding it to array-api-compat so it can be used in scikit-learn and SciPy. That can be done on pretty short notice I think. From there to actually standardizing it would take quite a long time I suspect (but nothing is really blocked on not having that done).

The signatures to consider:

SciPy/cupyx.scipy/jax.scipy: lu(a, permute_l=False, overwrite_a=False, check_finite=True)
PyTorch: torch.linalg.lu(A, *, pivot=True, out=None)

The overwrite_a, check_finite and out keywords should all be out of scope for the standard.
The permute_l/pivot keywords do seem relevant to include. They control the return values in a different way. SciPy's permute_l returns 3 arrays if False, 2 arrays if True. That breaks a key design rule for the array API standard (no polymorphic APIs), so we can't do that. The PyTorch pivot=True behavior is okay, it always returns: a named tuple (P, L, U), and leaves P as an empty array for the non-default pivot=False.
PyTorch defaults to partial pivoting, and the keyword allows no pivoting. An LU decomposition with full pivoting is also a thing mathematically, but it does not seem implemented. JAX also has jax.lax.linalg.lu, which only does partial pivoting.
So it seems like lu(x, /) -> tuple(array, array, array): which defaults to partial pivoting is the minimum needed, the question is whether the other pivoting mode(s) is/are needed.

dask.array.linalg.lu has no keywords at all, and no info in the docstring about what is implemented. From the tests it's clear that it matches the SciPy default (permute_l=False).

For PyTorch, the non-default flavor is only implemented on GPU:
>>> A = torch.randn(3, 2)
... P, L, U = torch.linalg.lu(A)
>>> A = torch.randn(3, 2)
... P, L, U = torch.linalg.lu(A, pivot=False)
Traceback (most recent call last):
  Cell In[6], line 2
    P, L, U = torch.linalg.lu(A, pivot=False)
RuntimeError: linalg.lu_factor: LU without pivoting is not implemented on the CPU

Its docstring also notes: The LU decomposition without pivoting may not exist if any of the principal minors of A is singular.
tl;dr maybe the best way to go is to only implement partial pivoting?

Maybe we can start with a function with no argument that always returns PLU (that is only implement scipy's permute_L=False and torch's pivot=True) and it will be up to the consumer to compute.
On the other hand, I think it would be good to have an option wot do the PL product automatically and avoid allocating P. Should array API expose two methods? xp.linalg.lu that outputs a 3-tuple (P, L, U) a second function xp.linalg.permuted_lu that precomputes the PL product and always outputs a 2-tuple (P @ L, U)?

Its docstring also notes: The LU decomposition without pivoting may not exist if any of the principal minors of A is singular.

Also note, from PyTorch's doc:

The LU decomposition is almost never unique, as often there are different permutation matrices that can yield different LU decompositions. As such, different platforms, like SciPy, or inputs on different devices, may produce different valid decompositions.

Such a disclaimer should probably be mentioned in the Array API spec.

We do use the "permute_l=True" case in scikit-learn.

It would be easy to provide a fallback implementation that uses an extra temporary allocation + mm product for libraries that do not natively support scipy's permute_l=True.
But it's not clear if pytorch' pivot=False is equivalent to scipy permute_l=True or doing something different.

We do use the "permute_l=True" case in scikit-learn.

Oops yes, I didn't read well.

But it's not clear if pytorch' pivot=False is equivalent to scipy permute_l=True or doing something different.

It looks like it's doing the exact same thing:
>>> import torch
>>> import numpy as np
>>> from scipy import linalg

>>> t = torch.rand(20, 10, device='cuda')  # must be 'cuda', because `pivot=False` is not supported on CPU
>>> Pt, Lt, Ut = torch.linalg.lu(t.to('cuda'), pivot=False)
>>> Lt.shape
torch.Size([20, 10])
>>> Ut.shape
torch.Size([10, 10])
>>> Pt
tensor([], device='cuda:0')

>>> Ln, Un = linalg.lu(t.to('cpu').numpy(), permute_l=True)
>>> Ln.shape
(20, 10)
>>> Un.shape
(10, 10)
>>> np.testing.assert_allclose(Lt.to('cpu'), Ln)
...
AssertionError:
Not equal to tolerance rtol=1e-07, atol=0

Mismatched elements: 190 / 200 (95%)
Max absolute difference: 56.958973
Max relative difference: 181.88818

>>> (Lt @ Ut - t).max()
tensor(2.1011e-06, device='cuda:0')
>>> (Ln @ Un - t.to('cpu').numpy()).max()
1.1920929e-07

So both give valid decompositions with the same shapes for L and U, and P either empty or not returned; numerical values are very different but that's expected.
One other thing to point out, the non-pivoting case does result in a decomposition with larger errors for PyTorch:
>>> Pt, Lt, Ut = torch.linalg.lu(t)
>>> (Pt @ Lt @ Ut - t).abs().max()
tensor(1.4901e-07, device='cuda:0')
>>> Pt, Lt, Ut = torch.linalg.lu(t, pivot=False)
>>> (Lt @ Ut - t).abs().max()
tensor(2.1011e-06, device='cuda:0')

>>> Pn, Ln, Un = linalg.lu(x)
>>> np.abs((Pn @ Ln @ Un - x)).max()
1.1920929e-07
>>> PLn, Un = linalg.lu(x, permute_l=True)
>>> np.abs((PLn @ Un - x)).max()
1.1920929e-07

SciPy's pivoting decomposition seems to be a lot faster for small arrays, and has similar performance for large arrays when they are square or wide, and is several times slower when they're tall:
>>> %timeit linalg.lu(x)  # shape (20, 10)
8.68 µs ± 38.8 ns per loop (mean ± std. dev. of 7 runs, 100,000 loops each)
>>> %timeit linalg.lu(x, permute_l=True)
21.7 µs ± 80.2 ns per loop (mean ± std. dev. of 7 runs, 10,000 loops each)

>>> %timeit linalg.lu(x)  # shape (400, 300)
951 µs ± 2.27 µs per loop (mean ± std. dev. of 7 runs, 1,000 loops each)
>>> %timeit linalg.lu(x, permute_l=True)
832 µs ± 7.62 µs per loop (mean ± std. dev. of 7 runs, 1,000 loops each)
>>> %timeit Pn @ Ln
190 µs ± 42.7 µs per loop (mean ± std. dev. of 7 runs, 1,000 loops each)

>>> x = np.random.randn(1000, 1000)
>>> %timeit linalg.lu(x)
8.49 ms ± 9.89 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)
>>> %timeit linalg.lu(x, permute_l=True)
7.94 ms ± 19.5 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

>>> x = np.random.randn(1000, 50)  # tall array
>>> %timeit linalg.lu(x)
734 µs ± 2.21 µs per loop (mean ± std. dev. of 7 runs, 1,000 loops each)
>>> %timeit linalg.lu(x, permute_l=True)
250 µs ± 2.21 µs per loop (mean ± std. dev. of 7 runs, 1,000 loops each)
>>> x = np.random.randn(50, 1000)  # wide array
>>> %timeit linalg.lu(x)
220 µs ± 303 ns per loop (mean ± std. dev. of 7 runs, 1,000 loops each)
>>> %timeit linalg.lu(x, permute_l=True)
222 µs ± 4.48 µs per loop (mean ± std. dev. of 7 runs, 1,000 loops each)

Given that scikit-learn does use permute_l=True and I suspect the tall array case is quite common for ML applications, there does seem to be a case for providing both flavors.

For completeness, some PyTorch GPU timings:
>>> t = torch.rand(1000, 1000, device='cuda')  # square tensor
>>> %timeit torch.linalg.lu(t)
7.11 ms ± 382 µs per loop (mean ± std. dev. of 7 runs, 1 loop each)
>>> %timeit torch.linalg.lu(t, pivot=False)
1.28 ms ± 2.47 µs per loop (mean ± std. dev. of 7 runs, 1,000 loops each)

>>> t = torch.rand(1000, 50, device='cuda')  # tall tensor
>>> %timeit torch.linalg.lu(t)
2.15 ms ± 54.8 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)
>>> %timeit torch.linalg.lu(t, pivot=False)
343 µs ± 6.58 µs per loop (mean ± std. dev. of 7 runs, 1,000 loops each)

>>> t = torch.rand(50, 1000, device='cuda')  # wide tensor
>>> %timeit torch.linalg.lu(t)
1.21 ms ± 2.23 µs per loop (mean ± std. dev. of 7 runs, 1,000 loops each)
>>> %timeit torch.linalg.lu(t, pivot=False)
488 µs ± 800 ns per loop (mean ± std. dev. of 7 runs, 1,000 loops each)

The performance gain is even larger there. So we have a default algorithm that's slower but stable, and an opt-in to a significantly faster algorithm.

@lezcano @nikitaved it'd be nice to get your opinion on this one. I can't find a PyTorch feature request for LU decomposition with pivot=False on CPU, despite it being much faster potentially. Is there a reason why it's only implemented on GPU?

pivot=False is often quite risky, as the class of matrices for which the decomposition has a not-so-nice structure (all its principal minors must be away from zero). For example, it does not exist for a matrix A with A[0,0] = 0. With this limitation, there are very few families of matrices for which this property holds. One of the few families for which this condition holds is positive definite matrices (by Sylvester's criterion), but then the LU decomposition is just good ol' Cholesky, for which we have a specific algorithm that's x2 faster.
Partial pivoting is often a good compromise between stability and speed when compared to, say, full pivoting or other more general decompositions. For this reasons, I don't think that there are many practical cases where you would want to have a regular LU decomposition.

For example, it does not exist for a matrix A with A[0,0] = 0. With this limitation, there are very few families of matrices for which this property holds.

I would not say few, there are plenty of matrices that satisfy such conditions, like full-rank matrices with non-zero diagonals. And in most cases diagonals are pre-conditioned anyway. Besides, pivot=True is the default, so I would assume the user is aware of the structure of matrices at hand when pivot=False is chosen.

Partial pivoting is often a good compromise between stability and speed when compared to, say, full pivoting or other more general decompositions. For this reasons, I don't think that there are many practical cases where you would want to have a regular LU decomposition.
There are cases when a single decomposition of a non-symmetric matrix leads to solving linear systems when the rhs comes in a stream. I would suspect that having pivots in this case is also detrimental to performance because of the need to re-order rhs.

The diagonal case you mentioned I don't think it's correct, but it's true that there is at least one family of matrices that I know of for which LU decompositions exist, which is column diagonally-dominant matrices.
At any rate, in most cases you do want partial pivoting due to stability reasons, so yeah. This could be implemented in PyTorch, so it shouldn't stop the array API from standarising it. I just think it shouldn't be the default.
Also, in terms of standarisation, I prefer the API we have in PyTorch for lu_solve over the one exposed in SciPy. In particular, we don't expose the trans parameter, but simply act on the strides of the input tensor to choose the best value for this parameter. We also act on the conj-bit that PyTorch implements to solve A^H X = B, but I don't know if NumPy implements that.

The diagonal case you mentioned I don't think it's correct, but it's true that there is at least one family of matrices that I know of for which LU decompositions exist, which is column diagonally-dominant matrices.

Agree. Fixed and changed to diagonal dominance which I meant in the first place :)

But it's not clear if pytorch' pivot=False is equivalent to scipy permute_l=True or doing something different.

It looks like it's doing the exact same thing.

I am not sure but I cannot quickly check since I do not have access to a cuda GPU at the moment:
By reading the docstring of torch.linalg.lu, I am under the impression that the returned L is always lower triangular with ones on the diagonal, whether or not pivot=False while this is not the case for scipy.linalg.lu: permute_l=True would return the product P @ L which is unlikely to be lower triangular.

Also in the case of randomized_range_finder used internally by scikit-learn's PCA(solver="randomized"), I confirm that we are interested in applying LU with tall matrices for which the permutation matrix P would not fit in memory, hence implicitly precomputing the P @ L product is necessary (otherwise one would get a crash instead of a slowdown).

If you have a tall matrix, what you often want to do is to compute the PLU of the transposed matrix and use it to solve the given system.

Also, thank you for digging this up https://github.com/data-apis/array-api/issues/627#issuecomment-1556881760. It looks like

@lezcano I agree. I think the matrix P should not be returned as a matrix, but rather as a vector encoding the permutation. I would suggest that vector to be the image of range(min(M, N)) under the permutation. That way we could have (L*U)[p[i], j] == X[i,j]. The empty P array would be understood as the identity permutation.

Cc @ilayn who is currently making changes to scipy.linalg.lu

@oleksandr-pavlyk  I was referring to the output of linalg.lu_factor which returns the permutation encoded as a vector, but not with the usual encoding. linalg.lu_factor is just an interface into BLAS' getrf, so it returns the pivots with the same format as BLAS does.
For these functions, a minimal set of functions from which all the others can be implemented is given by:

linalg.lu_factor which would just be modelled after scipy.linalg.lu_factor (which is BLAS' getrf)
Something along the lines as linalg.qr_multiply that could be called linalg.lu_multiply (name TBD), with signature lu_multiply(pivots: Array, B: Array, trans: bool = False) that, given the pivots in BLAS'  format and a matrix B, it computes P @ B if not trans else P^T @ B

With those two, you can implement lu_solve in terms of them and solve_triangular. You can also implement linalg.lu in terms of these + tril/triu. IMO, I would be +1 to providing linalg.lu_solve even if it's redundant, and I'd suggest not to include linalg.lu.

It looks to me that we don't want to include the permute_l function, as it's just not useful. The matrix P@L does not have any structure, and it may not be used to solve a system in any way.

In the use case in scikit-learn (https://github.com/data-apis/array-api/issues/627#issuecomment-1556898302) we use P @ L as a cheap normalization step (as alternative to QR) in randomized SVD solver after each power iteration. This happens at step 2 of the algorithm presented on page 9 of https://arxiv.org/abs/0909.4061.
While the original paper does not use this LU-based normalization trick, scikit-learn took inspiration from @tygert and @ajtulloch's alternative implementation published in https://github.com/facebookarchive/fbpca. See section 5. of:
http://tygert.com/implement.pdf
We could subsequently confirm with our own benchmarks that the LU-based renormalization would improve the speed-accuracy trade-off of our randomized SVD solver.
I don't see how we could implement this pattern with the lu_factor / lu_solve API.

The SciPy signature is going to have another keyword here denoted by p_indices for lack of a better word to return the permutation as a 1D array. See https://github.com/scipy/scipy/pull/18358
lu(a, permute_l=False, overwrite_a=False, check_finite=True, p_indices=False)
and now supports ndarrays of arbitrary size (pertaining to memory constraints). No Fortran code is going to be used and existing infra is being deprecated starting 1.12.
overwrite_a and check_finite stuff are LAPACK-isms that does not need any standardizations and at some point I'll propose a deprecation in the future by moving things to Cython native code.

I don't see how we could implement this pattern with the lu_factor / lu_solve API.

In the API proposed in https://github.com/data-apis/array-api/issues/627#issuecomment-1557278813, there is a specific function to compute P @ B for an arbitrary B matrix, so that's how you would compute P @ L.
On a different note, that's a rather interesting trick for the implementation of that algorithm, which sacrifices a bit of stability, but not too much :) Now, I do not know a priory why would you need P @ L rather than just L, but that's a story for another day.

Omitting all pivoting with a rank-deficient matrix for which the randomization may be less than perfect sounds potentially numerically unstable to me.

I think a confusion here is coming from the fact that using permute_l=False in scipy seems to hint that it'll perform an LU decomposition without pivoting. This is not the case. As discussed above, there is no way to perform an LU decomposition without pivoting in scipy (and I argue in https://github.com/data-apis/array-api/issues/627#issuecomment-1554786038 that neither should be in this API, at least for now).
With that out of the way, my point is that, when doing an LU decomposition with partial pivoting, L and P @ L will have exactly the same rank (they will both be full rank, regardless of the rank of the initial matrix). Given this, I argue that using L is, a priori, as good a choice as using P@L. This may be done by
X = linalg.lu_factor(A)[0]
L = np.tril(X, k=-1)
k = min(L.shape)
L[:k,:k] += numpy.eye(k)

If you want to keep the information of the rank of the input matrix, you should keep the U, potentially dividing by the non-zero elements of the diagonal. Or even better, you should look into performing an LDU factorisation.
But again, all this part is deviating from the main topic of conversation. The point here is that all these things (permute_l=False/True) with the API proposed in https://github.com/data-apis/array-api/issues/627#issuecomment-1557278813

Something along the lines as linalg.qr_multiply that could be called linalg.lu_multiply (name TBD), with signature lu_multiply(pivots: Array, B: Array, trans: bool = False) that, given the pivots in BLAS' format and a matrix B, it computes P @ B if not trans else P^T @ B

One way to cleanly implement this would be to standardize a Linear Operator API as part of the Array API spec but I guess this is out-of-scope for now (since it is kind of related to sparse arrays).
For reference, here are some implementations of linear operators in the ecosystem:

scipy.sparse.linalg.LinearOperator
tf.linalg.LinearOperator
linear-operator for PyTorch

I experimented in a branch of scikit-learn to use the new scipy API from the lu_no_fortran branch to return the permutation data as integer indices (as an alternative to precomputing and returning the P @ L product) for the use case of LU-based normalization in randomized SVD following @tygert's paper cited above.

https://github.com/ogrisel/scikit-learn/pull/16

In conclusion:

discarding the permutation info is empirically detrimental as @tygert anticipated above,
using matrix_p=False (to return an array of indices instead of P) followed by fancy indexing L to apply the permutation is fast enough for our use case in scikit-learn (compared to letting scipy precompute the P @ L product internally using permute_l=True).
I also checked that the new Cython + LAPACK code in SciPy for the permute_l=True case was as fast as the old fortran code.

In my opinion, the standard xp.linalg.lu should:

always return the permutation info as an array of indices for the sake of memory usage,
not expose the permute_l=True option of scipy because it can be quickly reproduced via fancy indexing,
not expose the pivot=False option of PyTorch because it can fail in a data dependent way and not all libraries will be willing to implement this option,
always return 3 arrays (non polymorphing API).

Here is a summary of the typical snippet following the API I would expect in the standard (if we ignore any API backward compatibility concerns):
X = xp.asarray(np.random.randn(42, 43))
P_indices, L, U = xp.linalg.lu(X)
assert xp.linalg.norm(X - L[P_indices] @ U) < 1e-12

This means that scipy would implement this with its new options by default. But maybe numpy.array_api could.
Not sure how to deal with backward compat for pytorch either.

It is true that the lu_multiply proposed in https://github.com/data-apis/array-api/issues/627#issuecomment-1557278813 can be implemented in terms of advanced indexing (or more generally, a torch.scatter in the batched case). Now, what I don't like of the API proposed in https://github.com/data-apis/array-api/issues/627#issuecomment-1559723949 is that it doesn't allow for the most common use case of this API which is calling a lu_factor and a lu_solve to solve a system of linear equations (or more than one when they share their lhs). This is rather typical when solving matrix ODEs numerically, for example.
I would propose then to just have one function:
lu_factor(X: Array, p_indices: bool = False) -> Tuple[Array, Array]
The semantics of this function would be:

When called with p_indices=False, it would return the matrix and the pivots returned by BLAS
When called with p_indices=True, the matrix would still be that returned by BLAS, but the pivots would define a 0-indexed permutation, so that they can be used as indices within an advanced indexing operation.

Note that p_indices is what https://github.com/scipy/scipy/pull/18358/ calls matrix_p. Choose whichever name you like best.
Uses of this API:

The most obvious one: Its output can be fed into lu_solve as-is to implement a linalg.solve
One may extract the L returned by scipy.linalg.lu doing as discussed in https://github.com/data-apis/array-api/issues/627#issuecomment-1558897210. The U may be got by simply calling triu on the output of this function.
If you set p_indices=True, you may compute P @ B for an arbitrary matrix B by doing B[perm] where perm is the second array (vector in the non-batched case) that this function returns
As corollary of the previous point, one may compute the matrix P explicitly by doing P = xp.eye(n)[perm]
If one wants to compute P.T @ B for a given matrix (as you need to do to compute the adjoint of lu_solve) one can do that noting that the inverse permutation of a permutation vector perm is given by argsort(perm)

Since you folks are working with insane amount of data and tools I can't even begin to understand to handle that data, just a few remarks about the speed of LU or any other linalg stuff in SciPy

Quite some performance is lost in check_finite across the board. If you have alternative ways to guarantee finiteness then you'll get much more out of that implementation.
Another performance eater is the Fortran-nannying; swapping the C-memory layout to Fortran-layout and back. I tried my best to keep the number of copy operations to 2 (one to lapack one from lapack) but I can't claim expertise. Hence probably I still left quite a bit of performance on the table there. We are working on getting rid of this Fortran ping-pong.
There is nothing magical happening in getrf and I would cautiously encourage for alternative getrf implementations for distributed cases. I will try to make that happen somewhere this summer to reclaim that performance with a pure C-layout implementation.
The permutation is not necessarily needed to be pushed into the array since it shuffles the memory order and costs performance especially if a copy is created. Instead a permuted solver can go a long way. LAPACK doesn't offer this but as per previous point, rows are contiguous on C-layout and offers quite a nice cache-friendly operations in LU case.

That is to say, instead of
Bp = B[p, :]

for r in range(n):
    foo = Bp[r, :] @ bla

you can do
for r in range(n):
    foo = B[p[r], :] @ bla

without any data motion on B.

Note that p_indices is what https://github.com/scipy/scipy/pull/18358 calls matrix_p. Choose whichever name you like best.

While I have the audience, if you have a better naming please do so, we considered
p_indices
perm_as_1d
p_as_1d
p_as_vec
perm_vector
return_1d
return_vector

and many other ugly candidates. We went with matrix_p out of desperation and to rhyme with permute_l

I think I find p_indices more explicit. Or maybe p_as_indices to avoid confusion with a local variable that could be used to receive the returned integer array.

@lezcano I am not sure I understand your proposal in: https://github.com/data-apis/array-api/issues/627#issuecomment-1559831514, in particular "pivots returned by BLAS". Could you please illustrate how your API proposal would feel from an end-user perspective?

My proposal accounts for having
# p_indices=False
assert xp.linalg.lu_factor(X) == scipy.linalg.lu_factor(X)

# p_indices=True
A, perm = xp.linalg.lu_factor(X, p_indices=True)
assert A == scipy.linalg.lu_factor(X)[0]
assertperm = scipy.linalg.lu(X, matrix_p=True)[2]

The full snipped would look like:
# p_indices=False: Solve a linear system
A, P = xp.linalg.lu_factor(X)
sol = xp.linalg_solve(A, P, Y)
assert xp.linalg.norm(X @ sol - Y) < 1e-12

# Reconstruct the full PLU decomposition
A, p_indices = xp.linalg.lu_factor(X, p_indices=True)
L, U = xp.fill_diagonal(xp.tril(A), 1), xp.triu(A)
assert xp.linalg.norm(X - L[p_indices] @ U) < 1e-12

The idea behind this API is based in three principles but here is where I may be wrong and it may be helpful for other members of the standarisation committee to chip in:

In almost all cases, this function will be used through the p_indices=False API to solve linear systems or compute a determinant.
The API should be easily implementable for all libraries (CPU / CUDA) with the current tools (most libraries rely on Blas / cuBLAS / Magma implementations)
The API should be expressive enough yet compact.

As discussed above, the proposed xp.linalg.lu_factor allows for implementing both scipy.linalg.lu_factor and scipy.linalg.lu using just one function.
I think the conciseness point here is important, as in PyTorch we used to have lu_factor, and then lu_unpack. This second one would unpack the L, U and the pivots. In my opinion, integrating the unpacking of the returned permutation into a set of indices (i.e. a permutation as defined in mathematics) provides for an even more concise API.

find the original suggestion in https://github.com/data-apis/array-api/issues/627#issuecomment-1559723949 way more user-friendly.

The suggestion in that comment does not account for the most common case, which is using the LU decomposition to solve a linear system.
When it comes to the user-friendliness, I believe that the array API is not in the business of offering plenty of auxiliary functions, but to have enough expressibility so that common constructs can be expressed efficiently in it. Auxiliary functions could potentially go into a library that builds on top of the array API. For example, using this explicit construction in your experiments in https://github.com/ogrisel/scikit-learn/pull/16 would save you from instantiating U explicitly, halving the peak memory and saving one full read and write over the data, and potentially allowing you to perform the computation of L  in place, saving even more memory and one further allocation.
When it comes to efficiency, note that using the NumPy API (that is, without fusion of operations) it's not possible to do better efficency-wise than the described tril + diagonal_fill + triu when it comes to computing the L and the U explicitly.

Note, that if there is a concern with backward compat with existing libraries and default parameters,

The proposed API is BC with other libraries, as its defaults are the same as those from SciPy and PyTorch

Also: what is the stance of the Array API standardization committee on "soft" polymorphic functions where the number of array element in a tuple of results does not dependent on the value of the function argument but the dtype and ndim of such arrays do (as would be the case with the p_indices kwargs)

p_indices does not change the shape of the output. It simply performs an iterative algorithm on the indices. Here's the algorithm as implemented in PyTorch:
https://github.com/pytorch/pytorch/blob/4882cd08013733a5dbe299871ad7e974bce074b3/aten/src/ATen/native/BatchLinearAlgebraKernel.cpp#L1119-L1128

Thanks for the explicit summary.

p_indices does not change the shape of the output.

I am not sure what you mean by shape. I would expect the following:
>>> A, p_indices = xp.linalg.lu_factor(X, p_indices=True)
>>> p_indices.dtype.kind
'i'
>>> p_indices.ndim
1

while:
>>> A, P = xp.linalg.lu_factor(X, p_indices=False)
>>> P.dtype.kind
'f'
>>> P.ndim
2

this is what I meant by "soft polymorphic outputs".

When p_indices=False, xp.linalg.lu_factor would return the same thing as scipy.linalg.lu_factor. In particular, it returns a 1D indexed array that can be fed into lu_solve.
If you want to recover the full 2D matrix P,  you would do as discussed in the penultimate point in https://github.com/data-apis/array-api/issues/627#issuecomment-1559831514

[...] one may compute the matrix P explicitly by doing P = xp.eye(n)[perm]

where perm = xp.linalg.lu_factor(X, p_indices=True)[1]

I new realize that I misunderstood how the piv arrays returned by LAPACK actually work. The example in the docstring of scipy.linalg.lu_factor seems to be broken.
I find that exposing those low level 1-based indexed pivot info quite confusing anyway. I have the feeling this should not be part of the standard API or at least not with the default options.

I can fix the docs if something is broken. What kind of issue do you have with it?
And about exposing it, yes that's what I meant in the last part of https://github.com/data-apis/array-api/issues/627#issuecomment-1559360092 about the "mistake". Note that they are pivot "swaps" not permutations.

Which API would you guys then propose that can be implemented with the current tools (BLAS/cuBLAS/cuSolver/MAGMA) that allows for solving linear systems fast, possibly with a common lhs?

My vote goes to Factorize class like Julia or Rust implements. The name can be something else but polyalgorithm is a must in this day and age for these operations. lu_factor, chol_solve etc in my opinion belong to the fortran age.
If you have an array A and pass it to Factorize or whatever the name, then you store your array factorization depending on the properties of A. It can be discovered at load time, or can be enforced as Factorize(A) or Factorize(A, assume_a='sym'). Then you can call solve on it and it will use whatever factorization is stored internally. You can repeat solve with different RHS or can perform different ops like .update(), .downdate(), det, rcond() in a lazy loading way. It can also hold multiple factorizations.
If you need explicit factorization then you can still call lu, qr and so on. That's also sparse and dense agnostic and pretty much what matlab offers as the most famous convenience. You don't focus on the operation itself you focus on the data you provide and the algorithms handle the complication.
Otherwise we will repeat the same fortran api yet another two decades. That's pretty much what I wanted to do in https://github.com/scipy/scipy/pull/12824 but then I lost my way due to other things. It tries to address the discovery part for solve. The idea is that the linalg APIs have moved on and it is quite inconvenient to fight with lapack api just to get a single operation with internal arrays, convert things from internal lapack representation to usable Scientific Python ways etc.
We are now trying to reduce our Fortran77 codebase in SciPy which is taking quite some time and after that I am hoping to get back to this again. Anyways, that's a rough sketch but that's kind of my wish to have in the end.

I can fix the docs if something is broken. What kind of issue do you have with it?

I thought the examples was broken (I thought I had copied and pasted the snippets and it would fail) but it's actually not the case. Still I think it can be helpful to be more explicit: https://github.com/scipy/scipy/pull/18594
For some reason I thought that I read somewhere that piv would be 1-based indexed but it's actually 0-based indexed in scipy. So everything is fine.

I find the proposal in https://github.com/data-apis/array-api/issues/627#issuecomment-1568892925 interesting. Would it be possible to implement it on top of the existing building blocks available in numpy/scipy, torch and co?
If it can be done, (e.g. maybe in a proof of concept repo), maybe it can help move the spec discussion forward if it is backed by working code.


[wasm] Port CoreFoundation/PlugIn.subproj

Just add WASI platform as a Unix-y platform

@swift-ci test


🐛  Request textDocument/formatting failed

Environment information
CLI:
  Version:                      1.8.1
  Color support:                true

Platform:
  CPU Architecture:             x86_64
  OS:                           macos

Environment:
  BIOME_LOG_DIR:                unset
  NO_COLOR:                     unset
  TERM:                         "xterm-256color"
  JS_RUNTIME_VERSION:           "v18.19.1"
  JS_RUNTIME_NAME:              "node"
  NODE_PACKAGE_MANAGER:         "yarn/1.22.22"

Biome Configuration:
  Status:                       Loaded successfully
  Formatter disabled:           false
  Linter disabled:              false
  Organize imports disabled:    false
  VCS disabled:                 true

Workspace:
  Open Documents:               0

What happened?
Hi, i'm new into the biome environment
today i tried to install it and configure biome in my react project
i removed every eslint and prettier related dev deps
and configured biome
"@biomejs/biome": "1.8.1",
biome.json
{
	"$schema": "https://biomejs.dev/schemas/1.8.1/schema.json",
	"organizeImports": {
		"enabled": true
	},
	"linter": {
		"enabled": true,
		"rules": {
			"recommended": true
		}
	}
}

i'm using VScode so i installed the recommended vscode plugin
after that i get this error
  Request textDocument/formatting failed.
  Message: missing field tabSize
  Code: -32602

where this property should be added? and why isn't automatically added when the yarn biome init is being fired?
Expected result
it should not throw an error
Code of Conduct

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

Biome doesn't have a tabSize option. It seems your editor is calling some other formatter. Make sure that your default formatter is set to be Biome for the file extensions you're trying to format.
https://biomejs.dev/reference/vscode/#default-formatter


Create all-in-one scheme

as described here (if makes sense for us)

Might not be possible to do because we use pods in the test targets

not possible if you want to use Cocoapods inside the project ATM


test: iteritems -> items

This allows the lit configuration to be python 2 and 3 compatible.

Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.

Resolves SR-NNNN.

CC: @tachoknight @drexin

@swift-ci please test


docs(subscriptions): change websocket protocol prefix

Summary
Just tried using GraphQL Subscriptions with subscriptions-transport-ws. I can only get it to work when using ws://. No response whatsoever when using the wss:// prefix. Not sure what is causing this because they should specify the same protocol, but I guess it would be a good change either way for consistency with other resources like the Apollo Docs.
Set of changes
Changed wss:// to ws://

ws is commonly used for localhost setups for remotes you'll need to use wss (equivalent of https)

ws is commonly used for localhost setups for remotes you'll need to use wss (equivalent of https)

ws is commonly used for localhost setups for remotes you'll need to use wss (equivalent of https)

since the doc uri's contain localhost, it would make sense to use ws:// then 👍🏻

ws is commonly used for localhost setups for remotes you'll need to use wss (equivalent of https)

since the doc uri's contain localhost, it would make sense to use ws:// then 👍🏻


Get enconding from OpenSubtitles provider

OpenSubtitles returns 'SubEncoding' that we can use to avoid guess_encoding()

Thanks for the PR, I added a few comments.

Antoine,
I changed my patch according to your proposals.
I had to put try-except block around self.content.decode because OpenSubtitles API returns garbage in SubEncoding for specific subtitles (eg. IDSubtitleFile=1954443141 has SubEncoding='CP1252|ISO-8859-')
Added simple condition on encoding initialization to one test.

Can this get merged? I'm getting some errors where subliminal thinks the encoding is Latin (even though charade says 0.99 Greek (it is Greek) and I'm getting corrupted UTF8 output. This would fix that.

Sorry I thought I commented that PR already.
Please filter out invalid encodings when setting the property rather than the try/catch block on the text property. The encoding property being part of the public API I don't want garbage there.

Hi, encoding attribute contains the original value as it came from from the OS provider.
I can't sanitize its value within the constructor, as I need to have content available (to ensure that content is decodable).
The most I could to is to update self.encoding value according to output of guess_encoding(), in case that self.content.decode(self.encoding) fails. It would fix the value of encoding attribute when accessing text property. But I'm not much happy with this either as it would bring strange side-effect to Subtitle.text property.
If you're not satisfied with proposed solution, feel free to close this PR as I'm out of other ideas, sorry :-)

It's no big deal if the encoding is the wrong one, that's still better than nothing. What I mean is check at least it is a valid codec with something like https://docs.python.org/2/library/codecs.html#codecs.getdecoder or similar when setting the property. Even better, try to split using | and get the first one if this is common in OpenSubtitles

@Diaoul I've just updated my PR. As you can see, I used codecs.CodecInfo object to:

ensure the encoding provided is supported by Python
get proper codec name, effectively translating all aliases and making case conversions (e.g. 'WinDows-1250' == 'windows_1250' == 'CP1250' == 'cp1250')

So Subtitle.encoding now gets either canonical name of supported codec, or None if input value is empty, unsupported or garbled beyond repair.
I intentionally don't attempt to parse SubEncoding because its value randomly depends on how much broken is OpenSubtitles database ;) Method guess_encoding() is more reliable in this case.

LGTM, thanks!


[Slider] The touch event is bubbled up to parent controls

[x] This is not a v0.x issue.
[x] I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior 🤔

The slider should swallow the touch events to other parent controls cannot react to these events and to another action for the same interaction.
Current Behavior 😯

Currently, the events bubbles up to parent controls, which means that if the slider is inside a swipeable area, it will switch tabs instead of changing the value.
Steps to Reproduce 🕹

Link: https://codesandbox.io/s/7zz0209nr1

Take any control that listens and reacts to touch events
Place the slider inside
Try to change the value of the slider with touch gestures

Context 🔦

I'm building an app that has a simple tab control which is swipeable (as in the demo) and sliders inside to change settings. On mobile, it is not possible to use these sliders.
Your Environment 🌎

Tech
Version

Material-UI
v3.9.2

React
16.8.4

Browser
Google Chrome 72.0.3626.121 on desktop, Google Chrome on Android

TypeScript
3.3.3333

Addition
In Chrome on Windows, I get the error in the console, the same in Firefox.
react-dom.development.js:1575 [Intervention] Unable to preventDefault inside passive event listener due to target being treated as passive. See https://www.chromestatus.com/features/5093566007214080

I think that preventDefault() would prevent the bubbling of the event and maybe fix this bug and obviously it doesn't work.
Video

The correct thing would probably be to apply touch-action: pan-x; or touch-action: pan-y; to the slider depending on the orientation, however I think that is a compatibility nightmare, so maybe it should always apply touch-action: manipulation; and call it a day?

According to the specification, I think putting a slider in a swipeable tab is discouraged.


chore: Show Schemathesis.io test report URL

Codecov Report

Merging #1263 (de645ed) into master (212ef23) will decrease coverage by 0.13%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #1263      +/-   ##
==========================================
- Coverage   99.41%   99.28%   -0.14%
==========================================
  Files          81       82       +1
  Lines        6104     6112       +8
  Branches     1008     1010       +2
==========================================
  Hits         6068     6068
- Misses         18       23       +5
- Partials       18       21       +3

Flag
Coverage Δ

unittests
99.28% <100.00%> (-0.10%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

src/schemathesis/cli/output/default.py
100.00% <100.00%> (ø)

src/schemathesis/service/client.py
100.00% <100.00%> (ø)

src/schemathesis/service/events.py
100.00% <100.00%> (ø)

src/schemathesis/service/models.py
100.00% <100.00%> (ø)

src/schemathesis/service/worker.py
100.00% <100.00%> (ø)

src/schemathesis/_compat.py
77.77% <0.00%> (-11.12%)
:arrow_down:

src/schemathesis/extra/pytest_plugin.py
98.23% <0.00%> (-1.77%)
:arrow_down:

src/schemathesis/cli/callbacks.py
98.27% <0.00%> (-1.73%)
:arrow_down:

src/schemathesis/cli/cassettes.py
98.43% <0.00%> (-1.57%)
:arrow_down:

... and 2 more

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 212ef23...de645ed. Read the comment docs.


store calls in some s3-like thing

since we do not have an infinitely(?) scalable db to work with ala spanner, if we store calls and logs in some [theoretically] infinitely scalable storage system like s3 or its api compatible friend in other clouds then our load on the [currently] sql db we are using will be really minimal, mostly just doing reads to serve caches with a very low write rate for crud stuff on apps & routes.
if we keep calls [and/or logs] in the sql db then we are going to hit scaling issues very quickly there for sharded mysql (or w/e sql db), and those sql guys generally don't like eating high write rate loads to begin with. obviously we're pushing the problem elsewhere, but blob stores tend to eat high write workloads a little better (s3 is stupid fast, on the order of milliseconds for smaller blobs, mostly network latency).
issue here is mostly abstraction I guess, aside from thinking this is a good idea. need to get GetCall / PutCall into the LogStore api (with a real log store implementation). if we do this then we probably won't have to worry too too much about the sql db we're using.
if we hook up a decent mq then it's also a relatively good option for us to send logs / calls to that to get quick response times at the end of calls and we can have a process that runs around and eats the queues and puts them into some more persistent storage (like s3), this would also give some flexibility vs just depositing into an s3 bucket but our calls / logs api would be 'eventually consistent' (most likely, unless we wanna search queues -- and we really don't).
another option is to not store call invocations / logs for sync or async requests at all, and make users add hooks to get log output and status updates (for async, specifically, sync gets output as is), which seems like an interesting and appealing option (operationally speaking, especially).
possibly for internal discussion, but likely useful to discuss in the open world as they'll run into this problem too...

in progress


Snabbdom 1.0 require breaks webpack build

I was using Snabbdom v0.7 in a project with webpack and not having any issues. I started a new project and when I did npm install I got version 1. I'm using the same webpack config (other than the project name) and it now fails with these errors:

ERROR in ./src/view/browserView/index.js
Module not found: Error: Can't resolve 'snabbdom' in 'C:\Users\Me\Projects\my-app\src\view\browserView'
@ ./src/view/browserView/index.js 1:17-36
@ ./src/inBrowserApp.js

ERROR in ./src/view/browserView/index.js
Module not found: Error: Can't resolve 'snabbdom/modules/attributes' in 'C:\Users\Me\Projects\my-app\src\view\browserView'
@ ./src/view/browserView/index.js 4:4-42
@ ./src/inBrowserApp.js

ERROR in ./src/view/browserView/index.js
Module not found: Error: Can't resolve 'snabbdom/modules/class' in 'C:\Users\Me\Projects\my-app\src\view\browserView'
@ ./src/view/browserView/index.js 5:4-37
@ ./src/inBrowserApp.js

ERROR in ./src/view/browserView/index.js
Module not found: Error: Can't resolve 'snabbdom/modules/eventlisteners' in 'C:\Users\Me\Projects\my-app\src\view\browserView'
@ ./src/view/browserView/index.js 8:4-46
@ ./src/inBrowserApp.js

ERROR in ./src/view/browserView/index.js
Module not found: Error: Can't resolve 'snabbdom/modules/props' in 'C:\Users\Me\Projects\my-app\src\view\browserView'
@ ./src/view/browserView/index.js 6:4-37
@ ./src/inBrowserApp.js

ERROR in ./src/view/browserView/index.js
Module not found: Error: Can't resolve 'snabbdom/modules/style' in 'C:\Users\Me\Projects\my-app\src\view\browserView'
@ ./src/view/browserView/index.js 7:4-37
@ ./src/inBrowserApp.js

ERROR in ./src/view/browserView/index.js
Module not found: Error: Can't resolve 'snabbdom/tovnode' in 'C:\Users\Me\Projects\my-app\src\view\browserView'
@ ./src/view/browserView/index.js 2:16-43
@ ./src/inBrowserApp.js

Okay, I saw that v1 introduced breaking changes, cool. So I grabbed the new imports from the README but I'm still getting these for every import from webpack:

ERROR in ./src/view/browserView/index.js
Module not found: Error: Can't resolve 'snabbdom/init' in 'C:\Users\Me\Projects\my-app\src\view\browserView'
@ ./src/view/browserView/index.js 1:13-37
@ ./src/inBrowserApp.js

Thank you, @mekane for using snabbdom. Please see https://github.com/snabbdom/snabbdom/issues/723#issuecomment-653721314.


Crash when changing glTF import settings

Godot version
4.0.beta7
System information
Windows 10
Issue description
Godot crashes when I try to change the import settings for a binary glTF file.
Steps to reproduce
Double-click the .glb file in the file system.
Minimal reproduction project
GltfCrash.zip

I can't reproduce with either beta 7 or the latest master on a macOS computer. The import settings open fine.

Likely duplicate of https://github.com/godotengine/godot/issues/69604, fixed in beta 8 already.

This is not fixed in beta 8. It crashes as well.

I don't seem to be able to reproduce the bug either with the provided project, on Linux with beta 7, beta 8 or master.
Could you give more details on the Steps to reproduce?
You mention that it crashes when changing import settings, but then the steps to reproduce are only to double click the file. Does it crash when double clicking? When changing some specific settings? Which ones? When pressing Reimport?

In detail:

Open the project
Expand the animations folder
Double-click the fall_animation.glb file

The pre-importing progress dialog is shown briefly and then Godot crashes. This is 100% reproducible on my Windows machine on either beta 7 or beta 8. I could try it on another OS and get back to you.
https://github.com/godotengine/godot/issues/69625 is fixed in beta 8 for me.

If I delete the fall_animation.glb.import file, it no longer crashes. That at least gives me a workaround.
I suppose if this is just an issue with incompatible import settings from a previous beta build, it's probably not worth fixing.

I was unable to reproduce the issue on Mac, so this seems to be Windows-specific.
Given that deleting the .import file (which was created by beta7) resolved the problem, I think that closing this issue makes sense.


[TEAMS][ERROR  Adaptive Card with video]

I can´t show an adaptiveCard in###  teams with video.
This is json I use, help please. Thanks!
{
"$schema": "http://adaptivecards.io/schemas/adaptive-card.json",
"type": "AdaptiveCard",
"version": "1.1",
"fallbackText": "This card requires Media to be viewed. Ask your platform to update to Adaptive Cards v1.1 for this and more!",
"body": [
{
"type": "Media",
"poster": "{ThumbnailUrl}",
"sources": [
{
"mimeType": "video/mp4",
"url": ""
}
]
}
]
}

Hi @LizMoreno, Teams doesn't currently support adaptive cards with Media content. We're looking to support that in the future, but currently do not have a timeline for that.


Unable to use package on electron

First, some notes about my project.
The project is a Desktop App to view and edit SQLite DB.  I use Electron and Express.
During development and testing of Express API, I only start the "server.js" file, which only starts Express without the FrontEnd (Electron).
"better-sqlite3-multiple-ciphers" works just fine and passes all CRUD tests.
When I try to start the project from electron using command "electron .", The server starts in the background and Electron opens the home page (indicating that "express static" is working properly). But when I use the API to do CRUD operations, I get that error
"better-sqlite3-multiple-ciphers" was compiled against a different Node.js version using
NODE_MODULE_VERSION 115. This version of Node.js requires
NODE_MODULE_VERSION 125. Please try re-compiling or re-installing
the module (for instance, using npm rebuild or npm install).
I tried npm rebuild and npm install but it was in vain.
I also tried 4 versions of node and also it was in vain.
The 4 versions were:-
22.3.0
22.1.0
21.7.3
20.11.0
I am obviously a beginner and This is my first real project.
Thanks in advance!

Finally, after three hours of trying, I managed to get the project working.

First, I had to recompile the package. I install electron-build as a Dev Dependency
Second, I got an error while compiling where it said "distutils" is not found. After some digging, I discoverd that it has been removed from Python 3.12. So, I installed python 3.9 and retried to compile again and it didn't work.
Finally, I had to use electron 27.3  which is not the latest.

It was a long journy and it was quite excity!


InfluxQLNode documentation needs improvement

Hi,
I reading through the Kapacitor documentation and I think the influxQL node section isn't very clear.
For instance the example doesn't seem relevant to the topic.
stream
     |window()
         .period(10s)
         .every(10s)
     // Sum the values for each 10s window of data.
     |sum('value')

Note the "|InfluxQLNode(...)" isn't there... At the moment, newbies like me will have to guess the arguments for the node.Probably a copy paste error as InfluxQLNode doesn't support the .period and .every.
properties.
Also, since it doesn't support the period property I suppose there is no way we can take advantage of the stateful information we get from the typical |Query(...)? That is, we need to know ahead in time what we want to SELECT and build the query?
Thanks!
Sam

Hi @SamuelToh I think there is a bit of misunderstanding on how this works. This probably means that we need to update the documentation a bit. Would you mind taking this to https://community.influxdata.com for further discussion. We try to keep github issues to bugs and feature requests.

@nhaugo  will do thanks.


Bug Report: links are not clickable

Environment
Windows build number: Microsoft Windows [Version 10.0.18362.295]
Windows Terminal version (if applicable): Version: 0.3.2171.0

Steps to reproduce

Open any shell (tried with WSL [bash, Ubuntu 18.04.3 LTS], cmd, PwoerShell PowerShell Core)
Run some command that produces output containing a URL e.g. echo http://www.github.com

Expected behavior
The URL is clickable, i.e. the console recognises that the text is a web link and allows it to be handled as such.
Actual behavior
The URL is not clickable - it's just text
This works in terminal in VSCode

Dupe of #574. Thanks!

Whoops, thanks!


Output of jupyter displayed in Jupyter output panel is not user friendly

We're displaying the raw JSON RPC comms, instead of the output messages.
{"jsonrpc": "2.0", "method": "log", "params": {"level": "INFO", "msg": "getting attr for stdout: encoding"}}Content-Length: 140
Content-Type: application/vscode-jsonrpc; charset=utf8

{"jsonrpc": "2.0", "method": "log", "params": {"level": "INFO", "msg": "write to stderr: [I 16:01:12.461 NotebookApp] [beakerx] enabled\n"}}Content-Length: 129
Content-Type: application/vscode-jsonrpc; charset=utf8

{"jsonrpc": "2.0", "method": "output", "params": {"source": "stderr", "out": "[I 16:01:12.461 NotebookApp] [beakerx] enabled\n"}}Content-Length: 239
Content-Type: application/vscode-jsonrpc; charset=utf8

{"jsonrpc": "2.0", "method": "log", "params": {"level": "INFO", "msg": "write to stderr: [I 16:01:12.546 NotebookApp] JupyterLab extension loaded from /Users/donjayamanne/opt/miniconda3/envs/env1/lib/python3.7/site-packages/jupyterlab\n"}}Content-Length: 228
Content-Type: application/vscode-jsonrpc; charset=utf8

Validated


Vivaldi-snapshot condition for Arch

#104
Currently I can't download & make vivaldi-snapshot from AUR  to test, but this should work

Yes, It should work if the snapshot version is installed.
Thank you for your contribution.


Sentry Transaction Name

Health checks are not being filtered out by Sentry properly, and this is causing us to blow past our usage quotas.

done here https://github.com/CounterpartyXCP/counterparty-core/pull/1763


feat(worker):Implementing testing pattern in github actions

Here we implement our first  iteration for our test pattern
To test this piece  of work  you can go for one of the two routes:

CLI , go and check if you have golang 1.19. if not get it , then run go test ./.... and all test should run :)
VScode in your activity bar check for the testing option , then  go for either github/mergestat/mergestat or github_actions.go folders and run the play button and all test should run

To verify that the tests are running againts nil validation , please go to mergestat/internal/helper/helper.go
and comment lines 57 to 60 .Now  test  that do this convertions from int to int32 should fail because of a nil pointer exception
resolves #539

@ramiroJCB thank you for addressing all of my comments.  It was so great to do actual debugging locally and stepping through code as well as seeing the tests pass and fail. The tests are very fast too!


master shows in the prompt and I want to undo it

So I did a sloppy "git init" in my home directory and it keeps showing master before the prompt afterwards. How can I remove master now or how can I undo it? I just want to see it if a directory is really really really a git repo not something I just accidentally did a "git init" in.
~   master          ls

@lamiastella  Done. 2af5141
Here is how it looks now.

Closing as resolved.
2af5141

@lamiastella I just realized, that your problem was a different thing and not what I replied. My apologies for not properly reading your issue.
If you created a dummy git repo in your home directory, just delete .git directory.
if test -d ~/.git
    rm -rf ~/.git
end


GFF-to-GBK removed

Hi,
I'm wondering why you removed GFF-to-GBK from your tool list ?
https://github.com/vipints/GFFtools-GX/commit/c99274597ef7856e7b89d1afbbef33bd04295722
One of my users want to use something like that.
Thanks by advance

Sorry for the delay, I didn't see much need for a GBK file for handling the feature annotation back in that day and decided to retire the program from the tools list. are you still interested on this?

of course, it's still very useful. like someone created a gene annotation in gff3, but the file can't be processed by the Geneious, so I need to convert it to gbk for a trial, in order to compare the gene annotation with known gbk downloaded from genBank (.gb).


Single-Side Borders Not Working

Describe the bug
Single side border properties do not display a border according to the rimble docs which state that all border properties from styled-system are supported.

The spec from styled-system supports styling a single side to any component.

https://github.com/styled-system/styled-system/blob/master/docs/table.md#border
To Reproduce
Steps to reproduce the behavior:

Create Box component
Add borderRight... props
No borders visible

Expected behavior
Should show right side border only.
Screenshots
https://codesandbox.io/embed/border-right-bug-038i1
Rimble UI Version

0.9.6 (latest)

Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

My guess is that these properties are part of styled system 5. This library uses styled-system 4. Can you verify @MikeLockz ?
See #301

@gesquinca Ya those props are for 5x. Opened a new ticket on the storefront to update the link in the docs to point to the props tables for 4.x version.
Will be resolved by https://github.com/ConsenSys/rimble-storefront/issues/56


remove Nix language syntax summary

this belongs to the Nix package manager manual.
depends on https://github.com/NixOS/nix/pull/6906

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/tweag-nix-dev-update-35/21701/1


me.carda:AndroidAwnCore not found

Launching lib/main.dart on moto one action in debug mode...
Running Gradle task 'assembleDebug'...
FAILURE: Build failed with an exception.

What went wrong:
Execution failed for task ':app:checkDebugAarMetadata'.

Could not resolve all files for configuration ':app:debugRuntimeClasspath'.
Could not find me.carda:AndroidAwnCore:0.7.5.
Searched in the following locations:
- https://dl.google.com/dl/android/maven2/me/carda/AndroidAwnCore/0.7.5/AndroidAwnCore-0.7.5.pom
- https://repo.maven.apache.org/maven2/me/carda/AndroidAwnCore/0.7.5/AndroidAwnCore-0.7.5.pom
- https://storage.googleapis.com/download.flutter.io/me/carda/AndroidAwnCore/0.7.5/AndroidAwnCore-0.7.5.pom
- https://jitpack.io/me/carda/AndroidAwnCore/0.7.5/AndroidAwnCore-0.7.5.pom
- https://jcenter.bintray.com/me/carda/AndroidAwnCore/0.7.5/AndroidAwnCore-0.7.5.pom
- https://www.jitpack.io/me/carda/AndroidAwnCore/0.7.5/AndroidAwnCore-0.7.5.pom
Required by:
project :app > project :awesome_notifications

Try:

Run with --stacktrace option to get the stack trace.
Run with --info or --debug option to get more log output.
Run with --scan to get full insights.

Get more help at https://help.gradle.org

BUILD FAILED in 32s
Exception: Gradle task assembleDebug failed with exit code 1

same problem

I fixed this problem by changing flutter channel mater to stable!

I fixed this problem by changing flutter channel mater to stable!

did not work with me

Open your android folder using the android studio and resync your project. Sometimes the jitpack server fails to delivery the package download.

Restart Android Studio also solved this error, i faced it again 10 minutes ago.


Generic Readers and Writers for Non-Root Tags

Potentially could also be related to #47, there does seem to be a requirement that I thought wasn't very common, where one might need to parse standalone tag types, ones that aren't directly nested inside a plain root tag type, or complete NBT file. This brings to reason how NBTify function calls could be helpful to build new parsers from scratch with it's underlying implementation.
I initially decided to not worry about this kind of feature to start with, since it does bring the complexity up a bit. Seeing more and more what people hope to build with it though, NBTify isn't holding up to their needs of wanting to build parsers that do such.
The main use for this is for NBT packet handlers, for making servers and parsers for reading data that goes over the network. Some of the format for those isn't stored with plain NBT like they tend to be in the files, where it is an object or list at the root. The packets could have their own individual need of being parsed, because the format doesn't explicitly package them together very nicely. So exposing a set of APIs for parsing non-root tags (with explicit format options) seems like a nice way to go.
That has been part of my concern too, initially I didn't want to break my auto format detection with unexpectedly accepting non-root tag types at the top of regular files, since those are expected (for the most part) to be a root tag type. Maybe it could make sense to just add a flag to the root tag type check? That actually makes a lot of sense, and it wouldn't make the API too complex either. We'll see. It would work awesome with the auto-detection too, I'd heavily recommend passing in explicit format options though, especially for custom formats like Bedrock uses.
Another portion to this, I've been meaning to implement for myself too, in regards to standalone SNBT tags, this would be for SNBT value editing in Dovetail's tree view. When you click on a key to edit it's value, you would get the SNBT for that single tag in the input, and editing that on it's own will change the value in the tree once you exit the input. That would involve allowing the parsing of non-root tags as well, since those could be any of the tag types specifically.

Funny how the time for this is all messed up, I did this during the time change, it says "opened this issue in 17 minutes", because it was from last hour, but we added an hour, so GitHub is confused. But the 'reference' above says 1 minute ago, so it was placed first in the order.

From Discord:
Ok exploring things a bit

Just using the CLI to demo it easily, it works great for parsing arbitrary tag types.
What do you think makes more sense, for adding a flag to read() specifically for something to the effect of rootCheck: false, or should it be a new function you import called readTag()? It would likely be a better name but yeah.
It would be to the concept of having NBT.readFile() or NBT.readTag().
Do you know if there are any occurences where the standalone non-root tags have compression?
Because this demo handles that, but it might just be overboard.
This is an example of why it could make sense for having a standalone function for it, because doing this accidentally is a big deal for sure ("successfully" reading the contents of a tag, but it happens to work in another format, even though the intended information is different, the bytes just might happen to work properly when parsing the other way around).


missing com.google.crypto.tink.integration.awskms.AwsKmsClient in version 1.3.0-rc1

Hi guys, i try to use following snippet from your documentation page but there is no AwsKmsClient, nor integration package at all in most recent version:
KeysetHandle keysetHandle = KeysetHandle.read(
JsonKeysetReader.withFile(new File(keysetFilename)),
new AwsKmsClient().getAead(masterKeyUri));
What is the substitute? Could you please provide equivalent?

Since 1.3.0.-rc1 the support for AWS/GCP KMS is in separate packages, see https://repo1.maven.org/maven2/com/google/crypto/tink/, so e.g. to use AWS KMS one should add also add dependency on tink-awskms.  Please re-open if it doesn't work for you.


Update install.sh to install in other Systems

I've added more information so it can install on other linux distribution other than Debian flavours.
Anything you can arrange.
I've placed some comments on the file to be easy read

Hey Tiago , thanks for the submiting this pull request.
You did a Good Job ;)

Hey Tiago , thanks for the submiting this pull request.
You did a Good Job ;)


Handling dateline crossing geometry

I'm running into a problem when creating a STAC Item from an image, when the image crosses the dateline.
I've looked at the code, and obviously the original author realised this would be a problem, as there is a TODO comment saying # TODO: Handle dateline crossing geometry at https://github.com/developmentseed/rio-stac/blob/master/rio_stac/stac.py#L23
Do you have any suggestions how to handle this? I'd be very happy to do a PR, but this is my first time dealing with things spanning the dateline and I'm not sure how best to handle it.

@robintw sorry for the late reply.
While answering this issue I found out a pretty simple fix: use rasterio/gdal 😄
could you confirm that https://github.com/developmentseed/rio-stac/pull/30 works for you 🙏

Thanks for the response. I'm off work this week, but I'll try this early next week and get back to you.


[Question] Why is it safe to check only last children in find_ancestor?

https://github.com/paritytech/finality-grandpa/blob/master/src/vote_graph.rs#L233
Or is it a bug?

Oh got it, because each chain will be the same after reach merge point.


NEP: Stack Isolation for NeoVM

This NEP proposes that stack isolation of the NeoVM evaluation stack should be carried out to ensure the security of dynamic invocations and provide support for future new features.

CALL and APPCALL should copy all values but working on isolated way too, or this opCodes should not
be modified ?
Nodes shoud reject any new contract with old OpCodes on deploy? (how deal with this)
Are defined the new OpCode values?

0xBX have a hole
What do you think?
CALL_I = 0xB0,
CALL_E = 0xB1,
CALL_ED = 0xB2,
CALL_ET = 0xB3,
CALL_EDT = 0xB4

0xBX is OK.

In witch branch are DYNAMICCALL implemented? @localhuman

In master.  We got rid of DYNAMICCALL opcode  and use APPCALL instead.

This change is urgently needed in order to safely do dynamic calls to untrusted contracts, and the AltStack needs to be isolated as well, as that is where contract global/local variables are stored. Very often StorageContext is saved in a named variable at the beginning of a contract, which could lead to any number of cross-contract security issues.

Is someone other than Erik even working on NEO. No one seems to pay any heed to this PR

Is someone other than Erik even working on NEO. No one seems to pay any heed to this PR.

Be patient, I'm working on it.

You can check the progress of the development for NEP-8 in this branch: https://github.com/neo-project/neo-vm/tree/feature/nep-8

On the other hand, some features, such as exception handling, also require stack isolation to be implemented.

Will exception handling be addressed in NEP-8 or another NEP?

Will exception handling be addressed in NEP-8 or another NEP?

It's not in NEP-8.

@erikzhang what's the status of this NEP? When will it be live?

The implementation has been completed. But it has not been deployed to the mainnet.

@erikzhang do you have an estimate of when this will be deployed? I'm really looking forward to using this feature.

If all goes well, it will be deployed to the testnet next week.

@erikzhang Great news! We've already updated neo-one to support stack isolation, and actually require it for the typescript compiler, so the sooner the better :)

FYI; neo-python and neo-boa now also have support for NEP8


[BUG] Stack Smashing on stack allocated tensors

Describe the bug
Passing stack allocated tensor objects to some MagmaDNN functions causes stack smashing errors. The bug is somewhat unpredictable. It does not happen every run.
To Reproduce
model::NeuralNetwork<float> model( ... );

/* stack allocated */
Tensor<float> x( ... );
Tensor<float> y( ... );

/* this causes a stack smashing error, a non-negligent percentage of runs */
model.fit(&x, &y, ... );

Expected behavior
No stack smashing.
Environment:

OS: Ubuntu 18.10
CUDA Version: 10.1
CBLAS: OpenBLAS
Magma Version: 2.5.2
CuDNN Version: 7.6
MagmaDNN Version 1.0

Additional context
Due to magmadnn::Tensor<T>'s copy constructor and MemoryManager copying.

A new branch has been created to overhaul MagmaDNN's memory system.
New Branch: memory-fixes
The goal of this branch is to replace most pointer use in MagmaDNN with references or smart pointers. This aligns with a modern c++ approach.

Here as an outline of how MagmaDNN's memory management will be refactored into a more modern c++ style.
Remove pointers where possible
In MagmaDNN v1.0, just about everything works in pointers. All of the ::magmadnn::math functions take Tensor<T>* pointers rather than plain tensors. This was necessary due to the lack of copy/move/assign semantics for the ::magmadnn::Tensor<T> class. Also operators and other tensor containers allocate, instantiate, and manage tensor pointers.
This is C-style and an unsafe programming style. Modern C++ favors references over pointers. Where resource management is necessary (::magmadnn::MemoryManager) it is favorable to use smart pointers and rather than raw pointers.
First we shall change Tensors and the MemoryManager class to use smart pointers. Tensors will use reference counting to avoid copying of data pointers.
Then proper copy/move/assign semantics are required for the Tensor class. This should be simple if std::shared_ptr is used for the MemoryManager. Then default copying should suffice.
Finally, the ::magmadnn::math library needs to be rewritten to utilize tensor references rather than pointers. This is a more appropriate C++ style interface. It also removes the possibility of nullptr values.
An example func:
void add(const Tensor& a, const Tensor& b, Tensor& out) { ... }

Operations will still needs pointers to children and parents. This is inherent to the graph data structure. However, rather than ::magmadnn::op::add( ... ) returning a raw allocated pointer, it should now add a std::unique_ptr to a central Graph class and return the non-owner raw pointer. The raw pointer can now be used in an algorithmic sense rather than for resource management.
Const Correctness
A significant portion of MagmaDNN routines are not const correct. We will be enforcing const correctness on member functions and ::magmadnn::math function parameters. This is for type safety, to prevent bugs, and provide a cleaner more complete interface.
Remove Type Templating
Currently Operations and math functions are restricted by type. We will remove the type template argument from most of these. For example, ::magmadnn::Tensor<T> will become just ::magmadnn::Tensor. Data type will be signified by some enum DataType, which specifies the supported values.
Valgrind and Cuda-memcheck Testing
We will run and check various MagmaDNN routines against valgrind and cuda-memcheck to be certain of its memory behaviour and performance.

Just to comment on the above memory strategy proposed for MagmaDNN: it will break a lot (pretty much all) existing code. This is unfortunate, but the memory update is necessary for growing the framework and there are also not that many users currently.


Add more reducer tests for new actions

Add the following action tests (without our middleware)

load
changeName
changeDesignParameterViolation
changeStateVariableViolation
saveStateVariableConstraints
restoreStateVariableConstraints
changeResultTerminationCondition
changeResultViolatedConstraintCount
changeSystemControlsValue
changeLabelsValue
search - no-op
seek - no-op

Merged into master, closing


Nested Entries are not fetched.

I have categories, and each category has a Parent Category. Currently, this is the response i get (I've removed data that doesnt matter for this issue):
{
    data: {
        title: "Sub 2",
        parent_category: {
            title: "Sub 1",
            parent_category: "73b28d21-4243-47cb-99ff-d3bf757cad80",
        }
    }
}

I.e, it fetches the first Parent but the nested ones are not fetched.
If I change line 470 in Fetch.php from
return Content::find($value)->toArray(); to  return $this->goDeep(Content::find($value)->toArray()); I get the correct results. I don't fully understand the code though, so this might just be a bad idea.
What do you think? If this is OK I will happily submit a PR.

Hi @christoffertyrefors! Sounds like this could potentially be a bug... Thanks for reporting and offering to submit a PR.
However, since this Addon has suffered a few unplanned breaking changes in the past due to a lack of test-coverage, and since Statamic 3 is (somewhat) around the corner, I'm afraid support and PRs are currently on hold.
I recommend you either create a fork of this repo, or simply keep a local copy with your fix for the time being.
Thanks again!


Error during calling the first transaction after switching networks successfully

When you switch networks after connecting, the next transaction throws an error.

ThirdwebSDK invoke error Error: underlying network changed (event="changed", network={"chainId":10,"name":"unknown"}, detectedNetwork={"name":"homestead","chainId":1,"ensAddress":"0x00000000000C2E074eC69A0dFb2997BA6C7d2e1e"}, code=NETWORK_ERROR, version=providers/5.2.0)

just fixed this on main (will release soon)


Implement native ecc chip

Implement native ecc chip where base field of the target curve is scalar field of the native curve and the scalar field of the target field is non native. So that we can host circuits such as folding verification and IPA decider.

closing. implemented at https://github.com/kilic/halo2msm


Add an Example for Task.LastTaskResult Property

Please add an example for Task.LastTaskResult Property.
TODO (optional): Describe a specific scenario you would like to see addressed.
Help Topic: https://dahall.github.io/TaskScheduler/html/P_Microsoft_Win32_TaskScheduler_Task_LastTaskResult.htm

I added it, but it is so simple that I'm not sure it will help. LastTaskResult merely captures the exit code from the executable run by the ExecAction. Whatever the program returns will be available here. 99% of the time, that value is 0.


Streamline unit tests

Summary
This PR kicks off some changes to the unit test examples setup so that we can start cleaning up our unit tests to only load the examples that are relevant for that test. In the existing setup, we load all examples, which has become quite large over time. This repeated loading of all examples has caused unit tests to take >1h to run (especially after #735).

Splits up the EXAMPLES list into different groups: ROADS, NAMESPACED_ROADS, EVENT, BASIC, DBT etc. This list is now a dictionary that maps the group name to a list of requests. Most tests will just want to load one of these groups, but some will load more than one.
Adds a client_example_loader fixture that provides a callable for loading examples into a TestClient session
The existing client_with_examples fixture stays the same so that we can remain backwards compatible. As we clean up the unit tests, I would expect only a few tests to use this fixture, as most only operate in one of the groups above.
Added several convenience fixtures for the different groups like client_with_roads and client_with_service_setup. These might be able to be generated automatically based on the keys to EXAMPLES, but I haven't investigated.

Test Plan

[ ] PR has an associated issue: #
[ ] make check passes
[ ] make test shows 100% unit test coverage

Deployment Plan

This is great. Let's see how much we can speed up these server tests.


Make header responsive

Make header responsive for all screen sizes

I'm closing this and creating one with proper details


Use minimized stack for crash site if no ASAN logs available

Closes #841.
If all we have is a call stack, use the top of the "minimized stack" as the crash site, not the top of the full stack.
This only happens if we don't have ASAN logs available for the crash.

Codecov Report

Merging #2962 (109db37) into main (34b513e) will decrease coverage by 0.15%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #2962      +/-   ##
==========================================
- Coverage   29.07%   28.93%   -0.15%
==========================================
  Files         304      125     -179
  Lines       36335    13639   -22696
==========================================
- Hits        10566     3947    -6619
+ Misses      25769     9692   -16077

see 179 files with indirect coverage changes
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Function with pattern-match argument and body of Debug.crash breaks compilation

The following program:
module Main where

broken : (Int, Int) -> Int
broken (model, action) = Debug.crash ""

consistently causes an internal compiler error in elm 0.16 (at least on my and one of my coworker's Macs). The error message is:
$ rm -rf elm-stuff/ index.html build/
$ elm-make TestMain.elm --yes
Downloading elm-lang/core
Packages configured successfully!
[===========================================       ] - 28 / 32elm-make: the annotation added in 'depattern' should not be observed!
elm-make: thread blocked indefinitely in an MVar operation

where TestMain.elm contains the code above.
Both the tuple pattern match and the call to Debug.crash seem to be necessary. In particular, if you replace (model, action) with a simple variable the problem goes away. Also if you replace Debug.crash with another function of the same type, the problem goes away. For instance, this program:
module Main where

any : String -> a
any a = any a

broken : (Int, Int) -> Int
broken (model, action) = any ""

compiles without error.
I believe this is an elm-compiler issue rather than an elm-make issue because the error message the annotation added in 'depattern' should not be observed! is from the elm compiler (https://github.com/elm-lang/elm-compiler/blob/master/src/Optimize.hs#L391). Apologies if it should be filed with elm-make or somewhere else.

This is also reproducible with record deconstruction, and in 0.17.
Here are two SCCEs that reproduce in try-elm 0.17:
fn ( x, y ) = Debug.crash ""

fn { x, y } = Debug.crash ""

Output of both is:
elm-make: the annotation added in 'depattern' should not be observed!
elm-make: thread blocked indefinitely in an MVar operation

I just ran into this when I tried to do this:
Time.now |> Task.perform (\() -> Debug.crash "oh no!") Tick

changing this to
Time.now |> Task.perform (\_ -> Debug.crash "oh no!") Tick

does not produce the error.
(\() -> ... was replaced by \_ -> ...)

Another SCCE that triggers the same error in 0.18:
type Foo a
    = Foo a

broken : Foo a -> a
broken (Foo a) =
    Debug.crash "not implemented"

I found a simple workaround.
broken : (Int, Int) -> Int
broken (model, action) = Debug.crash "" ()

Appears to be the same issue as https://github.com/elm-lang/elm-make/issues/157

This goes through without problems in my development build, so this should be fixed in the next release. Thank you for reporting this very weird case!


run ovs kernel mechanism test

Signed-off-by: Periyasamy Palanisamy<EMAIL_ADDRESS>

@pperiyasamy
CI in this repo requires PR to be created from branch, not from fork. Please create a new PR from branch to make CI correctly running.
@denis-tingaikin
Can you please check if @pperiyasamy has required permissions for pushing into the branch?

@Bolodya1997 , @pperiyasamy
peri has required permissions, but to run CI PR should be created from the branch from this repository (no fork)

Follow up in #394


Is extraction of username from debit/ card in roadmap?

Currently there is no support for extraction of user name from debit/ credit card but is it in your roadmap or soon to be coming feature?

Please see #111 (and if you like, all the other duplicate questions: #127, #114, and #113).


tpmstream.io: add support for swtpm log file format

The swtpm program that is used to provide QEMU/KVM virtual machines with a virtual TPM can save a log of all TPM command packets.
The file format looks like this:
Ctrl Cmd: length 4
00 00 00 10
Ctrl Rsp: length 4
00 00 00 00
SWTPM_IO_Read: length 10
80 01 00 00 00 0A 00 00 01 81
SWTPM_IO_Write: length 10
80 01 00 00 00 0A 00 00 01 01
Ctrl Cmd: length 4
00 00 00 01
Ctrl Rsp: length 8
00 00 00 00 00 01 FF FF
SWTPM_IO_Read: length 12
80 01 00 00 00 0C 00 00 01 44 00 00
SWTPM_IO_Write: length 10
80 01 00 00 00 0A 00 00 00 00
SWTPM_IO_Read: length 22
80 01 00 00 00 16 00 00 01 7A 00 00 00 05 00 00
00 00 00 00 00 01
SWTPM_IO_Write: length 43
80 01 00 00 00 2B 00 00 00 00 00 00 00 00 05 00
....
"Ctrl Cmd" and "Ctrl Rsp" are markers for messages on SWTPM's control channel, followed by data, which should be ignored.
"SWTPM_IO_Read" and "SWTPM_IO_WRITE" are markers for TPM commands and responses respectively, where we can capture the following data and convert to binary.
This allows viewing the swtpm command stream using
tpmstream convert swtpm.log
the auto format detection looks for " Ctrl Cmd:" in the leading bytes. The format can also be requested explicitly
tpmstream convert --in swtpm-log swtpm.log

Awesome, qemu's TPM support is a common testbed, and being able to easily debug newly developing firmware will hopefully make peoples lives easier. I second this PR.
Also, tpmstream is really useful.

First up - sorry for the late reply and thank you for contributing!
Ah, parsing logs. This will surely bite me in the ass, but I'm willing to consider it.
FYI
tpmstream can parse pcapng files. That means, if you use swtpm socket, you could do something like this:
swtpm socket --tpm2 -p 2321 --ctrl type=tcp,port=2322 --log fd=1,level=5 --flags not-need-init --tpmstate dir=/tmp

$ tshark -i lo -f "port 2321"
Capturing on 'Loopback: lo'
 ** (tshark:2165370) 08:47:55.364018 [Main MESSAGE] -- Capture started.
 ** (tshark:2165370) 08:47:55.364260 [Main MESSAGE] -- File: "/tmp/wireshark_loLSXOS2.pcapng"
 ...

tpmstream co --in=pcapng /tmp/wireshark_loLSXOS2.pcapng

Review
Two issues: please remove the auto-detect. Not many people will expect tpmstream to auto-detect the swtpm-log format and this breaks parsing small blobs like 80 01. Please also add at least a smoke test.

swtpm.log
For your convenience, this is running the tpm2-tss test suite against swtpm. Parsing still breaks at some point, but that might very well be another tpmstream bug. Thought it might be helpful.

First up - sorry for the late reply and thank you for contributing!
Ah, parsing logs. This will surely bite me in the ass, but I'm willing to consider it.
FYI
tpmstream can parse pcapng files. That means, if you use swtpm socket, you could do something like this:
swtpm socket --tpm2 -p 2321 --ctrl type=tcp,port=2322 --log fd=1,level=5 --flags not-need-init --tpmstate dir=/tmp

My use case for this is that we're using swtpm to provide a virtual TPM for KVM virtual machines, managed by libvirt. The user does not have any mechanism for injecting arbitrary command line arguments to swtpm, and even if that were possible, in a production deployment many would not be allowed to make such a change. It is feasible, however, to tell users to turn on logging in the swtpm process, which is just a boolean flag they have to toggle and thus low risk of breaking a production deployment.
So basically when I'm dealing with support tickets from people using a TPM in their VM, I'd like to be able to tell them to toggle debugging and send me the swtpm logfile which I can then analyse with tpmstream.

Review
Two issues: please remove the auto-detect. Not many people will expect tpmstream to auto-detect the swtpm-log format and this breaks parsing small blobs like 80 01. Please also add at least a smoke test.

Sure will make both those changes.

swtpm.log
For your convenience, this is running the tpm2-tss test suite against swtpm. Parsing still breaks at some point, but that might very well be another tpmstream bug. Thought it might be helpful.

I had a look at the failure here, and my gut feeling is that there could be some bugs in the existing code. It is failing on the "ClearControl" command first, trying to decrypt a set of parameters. The code assumes at least one parameter exists, but in this case there are zero parameters. If I hack around that, then there's a second very similar problem dealing with encrypted parameters again which I didn't understand well enough to debug further.
I did find our other unrelated bug when I added tests, which I've fixed in a separate commit in the new set of patches.

I did find our other unrelated bug when I added tests, which I've fixed in a separate commit in the new set of patches.

Oh nevermind, I see you also just fixed the same problem with the constants meanwhile.


Feat: Alternatively using the original apiserver endpoint from the hub kubeconfig as registry endpoint

Signed-off-by: yue9944882<EMAIL_ADDRESS>
the server endpoint stored in-cluster cluster-info will be an internal ip/host address e.g. on the ACK provider. adding a --in-cluster-bootstrap=[true|false] flag (which is defaulted to true considering backward compatibility) will help those admin to alternatively let the registration agent adopt the original endpoint (which is mostly an external hostname) as the registration entry. otherwise the registration will be constantly failing to network/VPC isolation.

Looks good. Run make reviewable to format the code.


net.minecraft.container.AnvilContainer.pos wrong name

net.minecraft.container.AnvilContainer.pos (field_7770) does not denote a position.
It is a Property type, and it is used to store the level cost for combining 2 items in the GUI.

This was fixed by #479.


Add PDB check in IsEvictable

Adding PDB check for pods to avoid trigger 'NotAllowed' eviction
Ths PR created reference with #271

/assign @ravisantoshgudimetla

/assign @ingvagabund
Jan could you please take a look at this?

could you/anyone please explain why is this PR needed? May be I am missing something.
Descheduler uses eviction subresource for deleting/evicting pods. Eviction sub resource honors PDB. They why is this change required?

@aveshagarwal Although eviction API comply with PDB, but strategies still get not evictable pods from podutil.ListEvictablePodsOnNode, so to avoid giving a PDB.Allowed < 1 (zero) pod to strategies to calculate add this filter inside.

But descheduler mostly ignore errors when deleting pods and just moves on to other pods. So getting not allowed warning clearly shows that the pod is not evictable. I am still not sure how adding this change is going to be helpful?

@oif I agree with @aveshagarwal , if not PDB there may be other reasons not allowing a pod to be evicted in the future. That's what the eviction subresource is for. I.e. to take responsibility for deciding when a pod can be evicted. So it's ok for a strategy to list more pods than it can actually evict as long as the list itself is not used to calculate a condition which might negatively affect a cluster if computed incorrectly.

@aveshagarwal @ingvagabund
Yes, that view described above is reasonable and acceptable. So maybe close this  PR


enable customLocateFileHandler function for webIfc in IfcLoader

Description 📝
There is already an option in ifc-fragment-settings class to provide a custom file handler function for the WASM module (customLocateFileHandler).
This setting should be used in readIfcFile method.
Suggested solution 💡
No response
Alternative ⛕
No response
Additional context ☝
No response
Validations ✅

[X] Read the docs.
[X] Check that there isn't already an issue that requests the same feature to avoid creating a duplicate.

Fixed from<EMAIL_ADDRESS>

Thank you very much


Feature: AI/ML on Telegram

I'm interested in connecting NLP to Telegram. Specifically, when a scammer messages me, I want to be able to take their message and pass it to my python code to then process and spit back an AI driven reply, thereby wasting the spammers time/money.
I have seen the ability to create a bot that users can ask questions to receive a reply (similar to here: https://github.com/ibrdrahim/telegram-auto-reply). However, I would like to know if Telegram has an inbuilt API for me to be able to set off my python script based on my input after receiving the scam message, and then take it from there.
In other words,

Scammer messages me randomly and I recognize they are scammer because of their behavior (talking about mobile mining, attractive PFP, Asian phone number, etc...).
I type in keywords to allow AI to take over chat. For example, I type "Hello, dear".
The scammers messages are passed to GPT2 and then GPT2 sends realistic messages back to scammer through API.
Scammers are essentially DDOSed by GPT2.

I feel that there are no technological blocks to the AI side. But, before I take on this task, I want to see if the existing API will work with step 2, and if not, if this is a possible feature that could be added due to the increase in crypto scams (https://www.reddit.com/r/Scams/comments/njimju/pigbutchering_scam_sha_zhu_pan_photos_of_training/)

Telegram has nothing like that.

Just to be clear, it seems like I can already write a Telegram bot connected to AI, based on the following link (https://leihao0.github.io/How-to-auto-reply-send-msg-with-telegram/).
So, my thinking is that I should already be able to direct spammers to a new contact, which is my AI bot that will talk to them. So, my idea should already be doable to an extent.
The real question is if I can do this easier? Can I read information that is coming to my Telegram personal message and send it to my bot via a flag I decide on? Basically, I want the UX/UI to be very simple. Are you saying that there is no way for me to programmatically read messages from someone that is sending me messages to my regular number?

You can use tdlib to process every incoming message your account receives, feed them to a ML/AI algorithm that will decide what to answer, and send the reply. The docs contain more information and example

Thankyou @RememberTheAir I'll look into it.


after install client (npm install @prisma/client) causing some windows file lock issue

Bug description
I think I notice an issue (should be a bug)
Each project after running npm install @prisma/client
sam build will crash with the following.
I have tested many times that I keep getting this issue (via sam build) (sam is a aws serverless framework)
PermissionError: [WinError 32] The process cannot access the file because it is being used by another process:
'C:\\Users\\betim\\AppData\\Local\\Temp\\tmpfvrgu56z'

If I remove the package, all works as before.
So I would like to know if the @prisma/client has some permission or lock file issue, and this should be a bug to fix.
Thank you.
How to reproduce

npm install @prisma/client
sam build

Expected behavior
No response
Prisma information

// Add your schema.prisma

// Add your code using Prisma Client

Environment & setup

OS: Windows 11
Database: PostgreSQL
Node.js version: 18.13.0

Prisma Version

Can you leave more information on how to produce the issue? How does the project have to look like before for this to be triggered?

Hey @betimer,
Thanks for the additional info. Could you provide us with a reproduction repo? It'd be really helpful to move this issue forward.
Thank you 🙏

Hi @betimer
Just following up. Could you provide a reproduction repo? We're more than happy to move this forward with a bit more info.
Thanks!


Added theme support to the frontend using Ace themes.

This uses Ace's ext-themelist.js and localStorage to set and remember the user's favorite highlighting theme. It adds one <select> tag on the end of the others. All themes are listed alphabetically by their proper name. The default theme is still GitHub.
I've tested this locally using Chrome and web.py. Since it only touches the frontend it shouldn't interfere with any of the actual code evaluation.
This is what it looks like:

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nikomatsakis (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see CONTRIBUTING.md for more information.

Looks good to me, thanks!

Thank you @nikomatsakis, this is my first real contribution to rust. It feels good :)

@welbornprod good to hear. hope to see more!


I cannot reproduce the results of the paper

When i initialize RangeViT’s backbone with  ViTs pretrained on supervised ImageNet21k classification and fine-tuned on supervised image segmentation on Cityscapes with Segmenter (entry Cityscapes),I cannot reproduce the results of the paper regarding the nuScenes dataset .
My training configuration is as follows:
two GeForce RTX 4090 ,the batch-size of each GPU is sixteen .Other configurations follow your config file.
The environment is as follows:
pytorch==2.0.0,torchvision==1.15.1,cuda==11.7
As a result, the miou only reached 74.27.
Could you tell me why this situation happened?

Hi, have you tested his published model?

Hi, have you tested his published model?

Yes,i have tested his published model and obtained a structure consistent with the paper.But the results of my own training did not meet the requirements of the paper.


Documentation for distributed key generation

Can't find any documentation or explanation behind concept or security.

found: https://eprint.iacr.org/2019/961.pdf


Add support for duplicate txids.

When the server asks for new txids from the client it can't assume that
those txids doesn't already exist in its buffer.
The TxSubmission test suite has been updated so that it doesn't generate
unique txids anymore.

Fixes #2680 and #2682.

What's the status of this PR?

From my point of view it is ready and waiting on reviews.

@nfrisby can you take a look at this?

Rebasing on top of mater  should fix Windows CI build error.

This is tricky stuff! I'm glad you figured out the bug.
I apologize for only responding two weeks later now :(
I left a bunch of comments throughout, some of which are minor. Mostly about code clarity, suggestive names, etc.
The potentially blockers are the questions about efficiency (some expressions went from logarithmic to linear eg) but I don't know the relative sizes involved. Have you considered those trade-offs? If so, it'd be valuable to record your thoughts in the comments.

Thank you for your review. The current window size is 10, so I have not considered complexity.
The most obvious performance improvement would be to fetch requests in order (#1721). The arbitrary fetching order increases the time from when we receive a new Tx to when we can commit it to the mempool by several RTTs.
There are other TxSubmission related issues that I hope to get to address soon such as #2688, #2615, and #1736.
However this PR is only for duplicate TX id support.

The current window size is 10, so I have not considered complexity.

I think "the window size is small" resolves all my complexity concerns. I'm tempted to record that in a comment as relevant contextual information. Your call 👍.
Last question: do you want to factor out the io-sim wrapper before merging this PR?

The current window size is 10, so I have not considered complexity.

I think "the window size is small" resolves all my complexity concerns. I'm tempted to record that in a comment as relevant contextual information. Your call 👍.

I added a comment regarding the windows size.

Last question: do you want to factor out the io-sim wrapper before merging this PR?

I expect more resistance/comments on adding evaluateTrace to io-sim so I'm fine with just having it as a TODO.

Any reason not to bors this?

Any reason not to bors this?

I'm waiting for either @dcoutts or @coot . Hoping for 2021.

bors r+


it gives wrong numbers in calculating Weierstrass zeta function

I am doing the calculation that follows the equation (13) and (14) in https://doi.org/10.1063/1.5042618
I use tau = 1+sqrt(3)*im. It turns out that it gives incorrect results when tau varies slightly.

Looks like it might be an issue with a multiplication by im somewhere? The values seem to be swapped by a multiplication of the imaginary unit


mount applet: when called with no args, try /etc/mtab, /proc/mounts

Without mtab or procfs, calling 'mount' with no arguments will print no /etc/mtab, no /proc/mounts and usage.
With mtab or procfs, calling 'mount' with no arguments will print mount info. Trying /etc/mtab first, then /proc/mounts if mtab doesn't exist.

Interesting 😁
On Fri, 29 Nov 2019 at 17:55, aerth<EMAIL_ADDRESS>wrote:

@aerth commented on this pull request.
In applets/mount/mount_linux.go
https://github.com/surma/gobox/pull/15#discussion_r352013235:

@@ -20,14 +21,32 @@ func Mount(call []string) error {
return e
}

if flagSet.NArg() != 2 || *helpFlag {

println("`mount` [options] <device> <dir>")

flagSet.PrintDefaults()

println("\nAvailable options are:")

for opt := range flagMap {

	print(opt, ", ")

if flagSet.NArg() < 1 && !*helpFlag {

// try mtab

mountinfo, err := ioutil.ReadFile("/etc/mtab")

if there were no procfs, the mount command would have to keep /etc/mtab
up to date anyways, which we aren't doing.
so yeah, it should probably simply print /proc/mounts
fwiw, the mount program i have installed reads /proc/filesystems and
/proc/self/mountinfo
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/surma/gobox/pull/15?email_source=notifications&email_token=AAJ276RRDTAALKR52E2B4VTQWDDGPA5CNFSM4DCTBFM2YY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCNMHDFQ#discussion_r352013235,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJ276TEKBUFDRMEJ52QUT3QWDDGPANCNFSM4DCTBFMQ
.

--
James Mills / prologic
E<EMAIL_ADDRESS>W: prologic.shortcircuit.net.au