Test failures for gges and qz for float32 input in macOS CI

These started showing up consistently over the last day (example log). Only in the macOS tests (meson) job. That job uses conda-forge, the root cause is very likely the new build (0.23.1 build _3) of OpenBLAS pushed to https://anaconda.org/conda-forge/openblas about 16 hours ago.
___________________________ test_gges_tgexc[float32] ___________________________
[gw0] darwin -- Python 3.10.6 /Users/runner/miniconda3/envs/scipy-dev/bin/python
scipy/linalg/tests/test_lapack.py:3087: in test_gges_tgexc
    assert_allclose(q @ s @ z.conj().T, a, rtol=0, atol=atol)
E   AssertionError:
E   Not equal to tolerance rtol=0, atol=1.19209e-05
E
E   Mismatched elements: 100 / 100 (100%)
E   Max absolute difference: 0.5596407
E   Max relative difference: 45.19812
E    x: array([[ 0.269565,  0.510163,  0.307816,  0.720287,  0.713599,  0.25576 ,
E            0.131274,  0.843207,  0.835774,  1.005878],
E          [ 0.364995, -0.002645,  0.148027,  0.409446,  0.200136,  0.596843,...
E    y: array([[0.191519, 0.622109, 0.437728, 0.785359, 0.779976, 0.272593,
E           0.276464, 0.801872, 0.958139, 0.875933],
E          [0.357817, 0.500995, 0.683463, 0.712702, 0.370251, 0.561196,...
        a          = array([[0.19151945, 0.62210876, 0.43772775, 0.7853586 , 0.77997583,
        0.2725926 , 0.27646425, 0.8018722 , 0.9581...43 , 0.9514288 , 0.48035917,
        0.50255954, 0.53687817, 0.81920207, 0.05711564, 0.66942173]],
      dtype=float32)
        atol       = 1.1920928955078125e-05
        b          = array([[0.7671166 , 0.70811534, 0.7968672 , 0.55776083, 0.9658365 ,
        0.1471569 , 0.029647  , 0.59389347, 0.1140...526, 0.7370865 , 0.12702939,
        0.3696499 , 0.604334  , 0.10310444, 0.8023742 , 0.94555324]],
      dtype=float32)
        d1         = -10.973611
        d2         = 0.65421426
        dtype      = <class 'numpy.float32'>
        gges       = <fortran object>
        n          = 10
        q          = array([[ 0.36440596,  0.14539199, -0.48573047,  0.18267933, -0.10118745,
         0.15227516, -0.48237514,  0.06109872....19003534, -0.15249437,
        -0.1685543 , -0.12377075, -0.35968414, -0.3202702 , -0.10042791]],
      dtype=float32)
        result     = (array([[-1.00654995e+00, -1.57352880e-01, -7.44751692e-02,
        -1.94980763e-03,  1.06006734e-01,  7.20489264e-01,... 0.36549678, 0.9152956 ,
       1.0120404 , 0.9464567 , 0.94311225, 0.        , 0.9372638 ],
      dtype=float32), ...)
        s          = array([[-1.00654995e+00, -1.57352880e-01, -7.44751692e-02,
        -1.94980763e-03,  1.06006734e-01,  7.20489264e-01,
...,  0.00000000e+00,
         0.00000000e+00,  0.00000000e+00,  0.00000000e+00,
         3.35054606e-01]], dtype=float32)
        t          = array([[ 0.09172459,  0.18612614, -0.10655626, -0.10534273, -0.5556871 ,
         0.8352932 , -0.11271314,  0.13819972....        ,  0.        ,
         0.        ,  0.        ,  0.        ,  0.        ,  0.9372638 ]],
      dtype=float32)
        tgexc      = <fortran object>
        z          = array([[ 0.45143077,  0.07711446,  0.04053342, -0.06187871, -0.2751032 ,
        -0.56598544, -0.22434531, -0.289968  ....21228388, -0.15313199,
         0.13994187, -0.6340214 ,  0.16412702,  0.56076413,  0.37706485]],
      dtype=float32)
___________________________ test_gges_tgsen[float32] ___________________________
[gw0] darwin -- Python 3.10.6 /Users/runner/miniconda3/envs/scipy-dev/bin/python
scipy/linalg/tests/test_lapack.py:3257: in test_gges_tgsen
    assert_allclose(q @ s @ z.conj().T, a, rtol=0, atol=atol)
E   AssertionError:
E   Not equal to tolerance rtol=0, atol=1.19209e-05
E
E   Mismatched elements: 100 / 100 (100%)
E   Max absolute difference: 0.5596407
E   Max relative difference: 45.19812
E    x: array([[ 0.269565,  0.510163,  0.307816,  0.720287,  0.713599,  0.25576 ,
E            0.131274,  0.843207,  0.835774,  1.005878],
E          [ 0.364995, -0.002645,  0.148027,  0.409446,  0.200136,  0.596843,...
E    y: array([[0.191519, 0.622109, 0.437728, 0.785359, 0.779976, 0.272593,
E           0.276464, 0.801872, 0.958139, 0.875933],
E          [0.357817, 0.500995, 0.683463, 0.712702, 0.370251, 0.561196,...
        a          = array([[0.19151945, 0.62210876, 0.43772775, 0.7853586 , 0.77997583,
        0.2725926 , 0.27646425, 0.8018722 , 0.9581...43 , 0.9514288 , 0.48035917,
        0.50255954, 0.53687817, 0.81920207, 0.05711564, 0.66942173]],
      dtype=float32)
        atol       = 1.1920928955078125e-05
        b          = array([[0.7671166 , 0.70811534, 0.7968672 , 0.55776083, 0.9658365 ,
        0.1471569 , 0.029647  , 0.59389347, 0.1140...526, 0.7370865 , 0.12702939,
        0.3696499 , 0.604334  , 0.10310444, 0.8023742 , 0.94555324]],
      dtype=float32)
        d1         = -10.973611
        d2         = 0.65421426
        dtype      = <class 'numpy.float32'>
        gges       = <fortran object>
        n          = 10
        q          = array([[ 0.36440596,  0.14539199, -0.48573047,  0.18267933, -0.10118745,
         0.15227516, -0.48237514,  0.06109872....19003534, -0.15249437,
        -0.1685543 , -0.12377075, -0.35968414, -0.3202702 , -0.10042791]],
      dtype=float32)
        result     = (array([[-1.00654995e+00, -1.57352880e-01, -7.44751692e-02,
        -1.94980763e-03,  1.06006734e-01,  7.20489264e-01,... 0.36549678, 0.9152956 ,
       1.0120404 , 0.9464567 , 0.94311225, 0.        , 0.9372638 ],
      dtype=float32), ...)
        s          = array([[-1.00654995e+00, -1.57352880e-01, -7.44751692e-02,
        -1.94980763e-03,  1.06006734e-01,  7.20489264e-01,
...,  0.00000000e+00,
         0.00000000e+00,  0.00000000e+00,  0.00000000e+00,
         3.35054606e-01]], dtype=float32)
        t          = array([[ 0.09172459,  0.18612614, -0.10655626, -0.10534273, -0.5556871 ,
         0.8352932 , -0.11271314,  0.13819972....        ,  0.        ,
         0.        ,  0.        ,  0.        ,  0.        ,  0.9372638 ]],
      dtype=float32)
        tgsen      = <fortran object>
        tgsen_lwork = <fortran object>
        z          = array([[ 0.45143077,  0.07711446,  0.04053342, -0.06187871, -0.2751032 ,
        -0.56598544, -0.22434531, -0.289968  ....21228388, -0.15313199,
         0.13994187, -0.6340214 ,  0.16412702,  0.56076413,  0.37706485]],
      dtype=float32)
____________________________ TestQZ.test_qz_single _____________________________
[gw1] darwin -- Python 3.10.6 /Users/runner/miniconda3/envs/scipy-dev/bin/python
scipy/linalg/tests/test_decomp.py:2039: in test_qz_single
    assert_array_almost_equal(Q @ AA @ Z.T, A, decimal=5)
E   AssertionError:
E   Arrays are not almost equal to 5 decimals
E
E   Mismatched elements: 25 / 25 (100%)
E   Max absolute difference: 1.9282217
E   Max relative difference: 12.652091
E    x: array([[ 0.25942,  0.42247,  0.29118,  1.3622 ,  0.07058],
E          [ 1.54704,  1.04254,  0.65235, -1.17932,  1.4969 ],
E          [ 0.37006,  0.76962, -0.09774,  1.07189, -0.13269],...
E    y: array([[0.92962, 0.31638, 0.18392, 0.20456, 0.56773],
E          [0.59554, 0.96451, 0.65318, 0.74891, 0.65357],
E          [0.74771, 0.96131, 0.00839, 0.10644, 0.2987 ],...
        A          = array([[0.9296161 , 0.31637555, 0.18391882, 0.20456028, 0.567725  ],
       [0.5955447 , 0.9645145 , 0.6531771 , 0.748...93, 0.9646476 , 0.7236853 ],
       [0.6424753 , 0.7174536 , 0.467599  , 0.32558468, 0.4396446 ]],
      dtype=float32)
        AA         = array([[ 0.39677864, -0.87905234,  0.31681818,  0.25420108, -0.31528485],
       [ 0.        ,  2.6049669 ,  0.5027338...10585941, -0.06299087],
       [ 0.        ,  0.        ,  0.        ,  0.        , -0.35764655]],
      dtype=float32)
        B          = array([[0.72968906, 0.99401456, 0.6768737 , 0.7908225 , 0.17091426],
       [0.02684928, 0.8003702 , 0.9037225 , 0.024...4 , 0.09596852, 0.21895005],
       [0.25871906, 0.46810576, 0.4593732 , 0.7095098 , 0.178053  ]],
      dtype=float32)
        BB         = array([[ 0.0964531 , -0.7481051 ,  0.0091472 , -0.6136254 ,  0.07135387],
       [ 0.        ,  2.5299823 ,  0.       ...        ,  0.01339715],
       [ 0.        ,  0.        ,  0.        ,  0.        ,  0.80180556]],
      dtype=float32)
        Q          = array([[-0.5236176 ,  0.43169242,  0.54998064, -0.28841138, -0.39218202],
       [ 0.10638957,  0.3615428 , -0.7044734...05049007,  0.65567476],
       [-0.04425064,  0.36560142, -0.14396492,  0.8444302 , -0.36137164]],
      dtype=float32)
        Z          = array([[-4.1415977e-01,  4.8910376e-01,  6.0941523e-01,  2.2133094e-01,
         4.1094345e-01],
       [ 8.1124866e-0...e-01],
       [-2.1641581e-01,  2.0534211e-01, -2.5105488e-01, -8.4537733e-01,
         3.6511230e-01]], dtype=float32)
        n          = 5
        self       = <scipy.linalg.tests.test_decomp.TestQZ object at 0x12de02ad0>
=========================== short test summary info ============================
FAILED scipy/linalg/tests/test_lapack.py::test_gges_tgexc[float32] - Assertio...
FAILED scipy/linalg/tests/test_lapack.py::test_gges_tgsen[float32] - Assertio...
FAILED scipy/linalg/tests/test_decomp.py::TestQZ::test_qz_single - AssertionE...

The one change in that build is https://github.com/conda-forge/openblas-feedstock/pull/146. Most of that is arm64-specific, for the x86_64 part the Fortran compiler is upgraded from Gfortran 9 to 11 though.

Note that qz is implemented in Python and uses gges internally, so there is only one problem here it looks like gges with float32 input.

On arm64 I also see new (but different) failures:
_____________________________________________________________ TestQRupdate_D.test_unsupported_dtypes ______________________________________________________________
scipy/linalg/tests/test_decomp_update.py:1561: in test_unsupported_dtypes
    r = r0.real.astype(dtype)
E   RuntimeWarning: invalid value encountered in cast
        a          = array([[0.36852295+0.70656594j, 0.97637554+0.88157274j,
        0.73179659+0.53904779j, 0.68487472+0.25772088j,
      ...842j, 0.1716864 +0.8069605j ,
        0.29238511+0.90236963j, 0.08459105+0.7541054j ,
        0.83912041+0.23152167j]])
        dts        = ['int8', 'int16', 'int32', 'int64', 'uint8', 'uint16', ...]
        dtype      = 'uint32'
        q          = array([[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
       [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
       [0, 0, 0, 0, 0, 0, 0,..., 0, 0, 0, 0],
       [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
       [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]], dtype=uint32)
        q0         = array([[-0.11519073-0.22085421j,  0.40310762+0.25545139j,
         0.20641454-0.02725359j,  0.04916084+0.1205459j ,
  ...,
         0.07221112-0.17945509j,  0.10256997-0.11285204j,
        -0.05898739+0.03267021j,  0.56949722-0.06679237j]])
        r          = array([[65533, 65534, 65535, 65534, 65534, 65534, 65534],
       [    0,     1,     0,     0,     0,     0,     0],
  ... 0,     0,     0,     0,     0,     0,     0],
       [    0,     0,     0,     0,     0,     0,     0]], dtype=uint16)
        r0         = array([[-3.19924142+0.j        , -2.18995473+0.2389295j ,
        -1.64672593+0.4729315j , -2.40332574+0.41776413j,
  ...,  0.        +0.j        ,
         0.        +0.j        ,  0.        +0.j        ,
         0.        +0.j        ]])
        self       = <scipy.linalg.tests.test_decomp_update.TestQRupdate_D object at 0x144bba580>
        u          = array([0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], dtype=uint16)
        u0         = array([0.97255678+0.26777079j, 0.36071622+0.78994569j,
       0.28201392+0.67496934j, 0.70583085+0.81774514j,
       0...358533j,
       0.09839256+0.43700129j, 0.56218546+0.88397738j,
       0.9777969 +0.18651321j, 0.14721884+0.59979179j])
        v          = array([0, 0, 0, 0, 0, 0, 0], dtype=uint16)
        v0         = array([0.01989467+0.01116458j, 0.23820349+0.06328583j,
       0.58360935+0.43995546j, 0.63492416+0.60213318j,
       0.45233787+0.88219112j, 0.63913689+0.71684251j,
       0.03427202+0.81291815j])
_____________________________________________________________________ test_solve_discrete_are _____________________________________________________________________
scipy/linalg/tests/test_solvers.py:528: in test_solve_discrete_are
    _test_factory(case, min_decimal[ind])
        _test_factory = <function test_solve_discrete_are.<locals>._test_factory at 0x144e44ee0>
        case       = (array([[      0., 1000000.],
       [      0.,       0.]]), array([[0],
       [1]]), array([[1., 0.],
       [0., 1.]]), array([[1]]), None)
        cases      = [(array([[ 2.+0.j,  1.-2.j],
       [ 0.+0.j, -0.-3.j]]), array([[0],
       [1]]), array([[1, 0],
       [0, 2]]), ar...0.005, 0.   ],
       [0.   , 0.02 ]]), array([[0.33333333, 0.        ],
       [0.        , 3.        ]]), None), ...]
        ind        = 15
        min_decimal = (12, 14, 13, 14, 13, 16, ...)
scipy/linalg/tests/test_solvers.py:525: in _test_factory
    assert_array_almost_equal(res, np.zeros_like(res), decimal=dec)
        a          = array([[      0., 1000000.],
       [      0.,       0.]])
        b          = array([[0],
       [1]])
        case       = (array([[      0., 1000000.],
       [      0.,       0.]]), array([[0],
       [1]]), array([[1., 0.],
       [0., 1.]]), array([[1]]), None)
        dec        = 2
        knownfailure = None
        q          = array([[1., 0.],
       [0., 1.]])
        r          = array([[1]])
        res        = array([[0.00000000e+00, 1.22970054e-20],
       [1.22970054e-20, 1.63574219e-02]])
        x          = array([[ 1.00000000e+00, -1.22970054e-20],
       [-1.22970054e-20,  1.00000000e+12]])
/Users/rgommers/mambaforge/envs/scipy-dev/lib/python3.9/contextlib.py:79: in inner
    return func(*args, **kwds)
        args       = (array([[0.00000000e+00, 1.22970054e-20],
       [1.22970054e-20, 1.63574219e-02]]), array([[0., 0.],
       [0., 0.]]))
        func       = <function assert_array_almost_equal at 0x122465e50>
        kwds       = {'decimal': 2}
        self       = <contextlib._GeneratorContextManager object at 0x12246a3a0>
/Users/rgommers/mambaforge/envs/scipy-dev/lib/python3.9/contextlib.py:79: in inner
    return func(*args, **kwds)
E   AssertionError:
E   Arrays are not almost equal to 2 decimals
E
E   Mismatched elements: 1 / 4 (25%)
E   Max absolute difference: 0.01635742
E   Max relative difference: inf
E    x: array([[0.00e+00, 1.23e-20],
E          [1.23e-20, 1.64e-02]])
E    y: array([[0., 0.],
E          [0., 0.]])
        args       = (<function assert_array_almost_equal.<locals>.compare at 0x144e448b0>, array([[0.00000000e+00, 1.22970054e-20],
       [1.22970054e-20, 1.63574219e-02]]), array([[0., 0.],
       [0., 0.]]))
        func       = <function assert_array_compare at 0x122465ca0>
        kwds       = {'err_msg': '', 'header': 'Arrays are not almost equal to 2 decimals', 'precision': 2, 'verbose': True}
        self       = <contextlib._GeneratorContextManager object at 0x12246a310>
===================================================================== short test summary info =====================================================================
FAILED scipy/linalg/tests/test_decomp_update.py::TestQRdelete_f::test_unsupported_dtypes - RuntimeWarning: invalid value encountered in cast
FAILED scipy/linalg/tests/test_decomp_update.py::TestQRdelete_F::test_unsupported_dtypes - RuntimeWarning: invalid value encountered in cast
FAILED scipy/linalg/tests/test_decomp_update.py::TestQRdelete_d::test_unsupported_dtypes - RuntimeWarning: invalid value encountered in cast
FAILED scipy/linalg/tests/test_decomp_update.py::TestQRdelete_D::test_unsupported_dtypes - RuntimeWarning: invalid value encountered in cast
FAILED scipy/linalg/tests/test_decomp_update.py::TestQRinsert_f::test_unsupported_dtypes - RuntimeWarning: invalid value encountered in cast
FAILED scipy/linalg/tests/test_decomp_update.py::TestQRinsert_F::test_unsupported_dtypes - RuntimeWarning: invalid value encountered in cast
FAILED scipy/linalg/tests/test_decomp_update.py::TestQRinsert_d::test_unsupported_dtypes - RuntimeWarning: invalid value encountered in cast
FAILED scipy/linalg/tests/test_decomp_update.py::TestQRinsert_D::test_unsupported_dtypes - RuntimeWarning: invalid value encountered in cast
FAILED scipy/linalg/tests/test_decomp_update.py::TestQRupdate_f::test_unsupported_dtypes - RuntimeWarning: invalid value encountered in cast
FAILED scipy/linalg/tests/test_decomp_update.py::TestQRupdate_F::test_unsupported_dtypes - RuntimeWarning: invalid value encountered in cast
FAILED scipy/linalg/tests/test_decomp_update.py::TestQRupdate_d::test_unsupported_dtypes - RuntimeWarning: invalid value encountered in cast
FAILED scipy/linalg/tests/test_decomp_update.py::TestQRupdate_D::test_unsupported_dtypes - RuntimeWarning: invalid value encountered in cast
FAILED scipy/linalg/tests/test_solvers.py::test_solve_discrete_are - AssertionError:

The qr failures are all the same ("invalid value in cast"), so I just copied one of the tracebacks.

Depends on how you've installed or built SciPy. If a dev build according to the docs with dev.py, then:
$ python dev.py test -s linalg  # for the whole linalg module
$ python dev.py test -t scipy.linalg.tests.test_lapack  # for a specific file
$ python dev.py test -t scipy.linalg.tests.test_lapack::test_gges_tgexc  # for a specific test failing here

If you have SciPy installed, e.g. from conda-forge, then you can use pytest in a similar way:
$ pytest --pyargs scipy.linalg.tests.test_lapack
$ pytest --pyargs scipy.linalg.tests.test_lapack::test_gges_tgexc

The x86-64 build log has a bunch of -Wconversion warnings for sgges:

2022-09-01T18:29:33.4498390Z $BUILD_PREFIX/bin/x86_64-apple-darwin13.4.0-gfortran -march=core2 -mtune=haswell -ftree-vectorize -fPIC -fstack-protector -O2 -pipe -isystem $PREFIX/include -fdebug-prefix-map=$SRC_DIR=/usr/local/src/conda/openblas-0.3.21 -fdebug-prefix-map=$PREFIX=/usr/local/src/conda-prefix -frecursive -O2 -m128bit-long-double -Wall -frecursive -fno-optimize-sibling-calls -m64 -fdefault-integer-8 -fopenmp -fPIC -c -o sgges.o sgges.f
2022-09-01T18:29:33.4551650Z sggbal.f:340:20:
2022-09-01T18:29:33.4656340Z
2022-09-01T18:29:33.4759930Z   340 |       LSCALE( M ) = I
2022-09-01T18:29:33.4827060Z       |                    1
2022-09-01T18:29:33.4930060Z Warning: Possible change of value in conversion from INTEGER(8) to REAL(4) at (1) [-Wconversion]
2022-09-01T18:29:33.5016680Z sggbal.f:349:20:
2022-09-01T18:29:33.5103390Z
2022-09-01T18:29:33.5133300Z   349 |       RSCALE( M ) = J
2022-09-01T18:29:33.5220650Z       |                    1
2022-09-01T18:29:33.5268710Z Warning: Possible change of value in conversion from INTEGER(8) to REAL(4) at (1) [-Wconversion]
2022-09-01T18:29:33.5323880Z sggbal.f:525:14:
2022-09-01T18:29:33.5336790Z
2022-09-01T18:29:33.5371860Z   525 |          IR = LSCALE( I ) + SIGN( HALF, LSCALE( I ) )
2022-09-01T18:29:33.5426640Z       |              1
2022-09-01T18:29:33.5439640Z Warning: Possible change of value in conversion from REAL(4) to INTEGER(8) at (1) [-Wconversion]
2022-09-01T18:29:33.5474220Z sggbal.f:533:14:
2022-09-01T18:29:33.5528860Z
2022-09-01T18:29:33.5541710Z   533 |          JC = RSCALE( I ) + SIGN( HALF, RSCALE( I ) )
2022-09-01T18:29:33.5594210Z       |              1
2022-09-01T18:29:33.5632650Z Warning: Possible change of value in conversion from REAL(4) to INTEGER(8) at (1) [-Wconversion]
2022-09-01T18:29:33.5735070Z sgges.f:409:21:
2022-09-01T18:29:33.5776050Z
2022-09-01T18:29:33.5785510Z   409 |          WORK( 1 ) = MAXWRK
2022-09-01T18:29:33.5875790Z       |                     1
2022-09-01T18:29:33.5984170Z Warning: Possible change of value in conversion from INTEGER(8) to REAL(4) at (1) [-Wconversion]
2022-09-01T18:29:33.6067450Z sgges.f:671:18:
2022-09-01T18:29:33.6168620Z
2022-09-01T18:29:33.6285770Z   671 |       WORK( 1 ) = MAXWRK
2022-09-01T18:29:33.6370830Z       |                  1
2022-09-01T18:29:33.6388960Z Warning: Possible change of value in conversion from INTEGER(8) to REAL(4) at (1) [-Wconversion]
2022-09-01T18:29:33.6475620Z $BUILD_PREFIX/bin/x86_64-apple-darwin13.4.0-gfortran -march=core2 -mtune=haswell -ftree-vectorize -fPIC -fstack-protector -O2 -pipe -isystem $PREFIX/include -fdebug-prefix-map=$SRC_DIR=/usr/local/src/conda/openblas-0.3.21 -fdebug-prefix-map=$PREFIX=/usr/local/src/conda-prefix -frecursive -O2 -m128bit-long-double -Wall -frecursive -fno-optimize-sibling-calls -m64 -fdefault-integer-8 -fopenmp -fPIC -c -o sgges3.o sgges3.f
2022-09-01T18:29:33.6491860Z sgges3.f:411:21:
2022-09-01T18:29:33.6578700Z
2022-09-01T18:29:33.6593730Z   411 |          WORK( 1 ) = LWKOPT
2022-09-01T18:29:33.6681530Z       |                     1
2022-09-01T18:29:33.6696390Z Warning: Possible change of value in conversion from INTEGER(8) to REAL(4) at (1) [-Wconversion]
2022-09-01T18:29:33.6768810Z sgges3.f:662:18:
2022-09-01T18:29:33.6783390Z
2022-09-01T18:29:33.6798350Z   662 |       WORK( 1 ) = LWKOPT
2022-09-01T18:29:33.6871500Z       |                  1
2022-09-01T18:29:33.6886570Z Warning: Possible change of value in conversion from INTEGER(8) to REAL(4) at (1) [-Wconversion]
2022-09-01T18:29:33.7450620Z $BUILD_PREFIX/bin/x86_64-apple-darwin13.4.0-gfortran -march=core2 -mtune=haswell -ftree-vectorize -fPIC -fstack-protector -O2 -pipe -isystem $PREFIX/include -fdebug-prefix-map=$SRC_DIR=/usr/local/src/conda/openblas-0.3.21 -fdebug-prefix-map=$PREFIX=/usr/local/src/conda-prefix -frecursive -O2 -m128bit-long-double -Wall -frecursive -fno-optimize-sibling-calls -m64 -fdefault-integer-8 -fopenmp -fPIC -c -o sggesx.o sggesx.f
2022-09-01T18:29:33.7805580Z sggesx.f:513:21:
2022-09-01T18:29:33.7906910Z
2022-09-01T18:29:33.7955740Z   513 |          WORK( 1 ) = LWRK
2022-09-01T18:29:33.8057420Z       |                     1
2022-09-01T18:29:33.8087500Z Warning: Possible change of value in conversion from INTEGER(8) to REAL(4) at (1) [-Wconversion]
2022-09-01T18:29:33.8106550Z sggesx.f:810:18:
2022-09-01T18:29:33.8153950Z
2022-09-01T18:29:33.8255870Z   810 |       WORK( 1 ) = MAXWRK
2022-09-01T18:29:33.8267520Z       |                  1
2022-09-01T18:29:33.8370210Z Warning: Possible change of value in conversion from INTEGER(8) to REAL(4) at (1) [-Wconversion]

No idea if those are relevant though, such warnings are par for the course for old Fortran code.
I think the last fix in this set of wrappers was gh-13397. @ilayn any thoughts here?

If it was a wrapper issue we would probably see a segfault rather than precision problem And precision violation is ever so little increased . So I am cautiously looking at OpenBLAS but can't be sure. @martin-frbg is there anything happened regarding ?gges or ?tgsen or some other place lately to your knowledge?

@ilayn nothing comes to mind except the general update to Reference-LAPACK 3.10.1 - do you see these problems only on mac ?

@martin-frbg yes, they started appearing on macOS when gfortran was upgraded from version 9 to 11. No other changes.

The issue in CI was fixed by xfail-ing the relevant tests in gh-17057. The sgges issue needs reassessing before the next release. Things seem to work with OpenBLAS 0.3.18, but are broken with 0.3.20/21. As long as we continue to ship 0.3.18 in our own wheels we should be good there - but that doesn't help conda-forge, Debian et al.

1.10 was released, resetting the milestone to 1.11

Problems that disappear when run alone might suggest something like numpy/numpy#17547 where floating point registers were not restored after a function call.

I have now inherited an i5 macbook, so may be able to look into this from the OpenBLAS side once I find my way around.

Maybe I am confused, but I think the problem only shows up on macOs arm64, i.e. the AppleSilicon hardware.

Oh well. Could be that I misread, but Ralf mentioned the conda update to gfortran-11 on x86_64 above ? Arm64 would actually be more likely as the new AppleSilicon support in 0.3.21 is mostly cobbled together from Cavium ThunderX2 bits while anything earlier would have fallen back to the ARMV8 target (that is more like an old Cortex A57)

Ralf mentioned the conda update to gfortran-11 on x86_64

I think that was in reaction to the build warnings.
Is there a way to tell @ngam's setup to use the older kernels with a export OPENBLAS_CORETYPE= directive so we could narrow the problem down?

Normally export OPENBLAS_CORETYPE=ARMV8 would work for DYNAMIC_ARCH builds (such as what I assume the conda-forge one is), but I just looked at the code to confirm -  and we currently do not support the M1 (et al.) natively in dynamic_arch builds anyway, so it should already be using ARMV8. (That is, unless ngam built OpenBLAS from source on the AppleSilicon hardware without specifiying DYNAMIC_ARCH=1). Curioser and curioser...

The logs of the failed CI run are gone, so we will need someone to tell us whether the problem is with x86_64 or arm64.

And there has not been any change in "ARMV8" target kernels since 0.3.18 AFAICT (the last one was my mass cleanup of assembly files to free up the x18 register for OSX' own use). OTOH any general problem with the ARMV8 target (which has some overlap with individual Cortex types as mentioned) would be expected to show up on non-OSX platforms as well. Unless of course this is somehow related to either the M1 port of gfortran or OpenBLAS' update to LAPACK-3.11.

Hi @ngam. First: do the failures appear on x86_64 or arm64 (i.e. what is the output of platform.machine())?

The failing tests were skipped. You could try backing out this change and testing again

Trying now on the M1 in the GCC compile farm and pytest/scipy/openblas installed via pip. Both pytest runs pass with either the original (0.3.18) libopenblas.0.dylib or my own build from current develop (and the xfails in the testsuite backed out). Will try to get things installed on the local x86_64 macbook next. (@ngam can you tell what x86_64 hardware your tests were run on ? export OPENBLAS_VERBOSE=2 can be used to print the selected cpu TARGET at runtime

test_lapack failures now reproduced on my macbook with the conda 0.3.21, have not checked older or newer version yet. (as an aside, running just "conda install numpy" without additional qualifiers appears to select a mkl build on this platform)

That macbook is sloooow, but current indication is that the issue is already fixed in current develop branch, almost certainly by either of the PRs to handle perceived defects in the tree-vectorizer that has become active by default at O2 in recent GCC releases. Also 0.3.18 shows the same failure pattern as 0.3.21 when built with the new compiler.

Thanks. So if I understand correctly, this may be solved by packaging an interim OpenBLAS 0.3.21+ off the develop branch. That should be relatively easy to put together so it can be tested in SciPy.

Yes, and/or get conda-forge to rebuild their openblas package with -fno-tree-vectorize set for gfortran.

Once #17950 goes in, it could be followed up by using the recently uploaded v0.3.20-571-g3dec11c6, which is the current HEAD of develop. It is hash 3dec11c6, which is 571 commits past v0.3.20. The v0.3.21 tag is not part of the develop branch, so the name is a bit off.

Oops, I must have forgotten to do the mergeback from the release branch then, sorry. (Not sure if it is still safe to do now, or if it is just one more reason to get 0.3.22 out ASAP)

do the mergeback

I think changing it now has more potential to do damage than to help, I just wanted to explain why the new lib build has an old name. Thanks for digging into this.

Now that #17950 is merged, it should be easier to try to upgrade OpenBLAS to v0.3.20-571-g3dec11c6 and remove the xfails to see if the newer OpenBLAS fixed the problem

I noticed that those OpenBLAS v0.3.20 tarballs were available. I don't understand what's going on with the versioning. Why are those tarballs available when 0.3.21 should be more recent?

I tried to explain the versioning above. TL;DR: v0.3.20-571-g3dec11c6 is after v0.3.21.

see mattip's post above https://github.com/scipy/scipy/issues/16949#issuecomment-1424048761 - I messed up by forgetting to merge the 0.3.21 tag from the release-0.3 branch back onto develop so packaging a snapshot of the latter will still show 0.3.20

Does numpy/scipy have a policy on using non release versions of OpenBLAS?
I have a macosx_arm64 computer. I'll try re-enabling the tests in https://github.com/scipy/scipy/pull/17057/files#diff-447d26812e91bd5b73f8192b28b4f52c5d0a1eaf97e6d1a22657fed4a70226d5, and see if they're fixed by updating the OpenBLAS install to v0.3.20-571-g3dec11c6

Does numpy/scipy have a policy on using non release versions of OpenBLAS?

Any version that works is fine I think, no policy beyond that. A dev version with a fix we need is also not much different from picking a release version and applying some patches to it.

I re-enabled the tests in test_decomp and test_lapack, and ran python dev.py test -t scipy.linalg.tests.test_decomp, python dev.py test -t scipy.linalg.tests.test_lapack. Both came back green. I used the most recent build of OpenBLAS, openblas-v0.3.20-571-g3dec11c6-macosx_11_0_arm64-gf_5272328.tar.gz.
This was using Python3.10.6.
A few things came to my attention during the build phase:

when I tried running the tests I got the Apple security warning libopenblas.... is from an untrusted source. I had to manually enable that in the security settings. I've never had that issue before.
there are a whole lot of ld: warning: -undefined dynamic_lookup may not work with chained fixups.
there are a bunch of warnings because boost uses sprintf, e.g.:
../scipy/_lib/boost/boost/lexical_cast/detail/converter_lexical_streams.hpp:297:21: warning: 'sprintf' is deprecated: This function is provided for compatibility reasons only.  Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead. [-Wdeprecated-declarations]

It would be nice if the latter were fixed upstream. I don't know about the former.
I'll make a PR to update the OpenBLAS version. Hopefully there are no problems with any other platform/machine.

The boost warnings will probably go away after the switch to Boost.Math. I haven't seen the ld: warning: -undefined dynamic_lookup ones before.

when I tried running the tests I got the Apple security warning libopenblas

That's bad, perhaps something went wrong with code signing in that OpenBLAS build?

The lexical_cast warnings are fixed in the next boost release.
To install the OpenBLAS bundle I simply expanded the tarball and copied arm64-builds into /opt. I'm not sure if there's another way to do it.

#18012 was merged. Did that solve the issue?


Get Password and Username from Input Stream

Noticed that whenever I had to share my code or Colab Notebook seemed like I need to replace my password. So, Made sure It gets the username, password from the user unless otherwise specified explicitly.
Also Changed the Order of Parameters from
( Email , Password , Modelname ) to ( Modelname , Email , Password ) for the same and updated the instructions in the README.md

I am also currently working on scaling this up for multi-models and having a one-time sign in instead of calling the function multiple times, will create another PR once that's complete.


How can use hyper-tls for server

Hi,
Is it possible use hyper-tls for hyper server "0.12" ?

Not really... But I'd welcome adding some API to ease this!

@seanmonstar I was just about to open a similar issue for this. As you're looking for a PR, do you have preferences around what this API would look like or should I submit the PR and review it then?

I haven't thought much about it, if you want to suggest something now, I can comment, or we can just review in a PR.

@seanmonstar My initial thoughts are, for starters, to provide From implementations for native_tls::TlsStream to hyper_tls::TlsStream and hyper_tls::MaybeHttpsStream. Even that would suffice for usage in the Server struct I type parameter based on the traits that both hyper_tls structs implement. The user could at least that way handle all of the certificate/socket address creation through native_tls. I'm looking at this as a first step as this is kind of a blocker for me right now. I think there's room for improvements and abstractions later on but this feels like a good "get this working" step for now. Does that sound good? If so, I'll start on a PR.

Sure!

PR #28 created. Lemme know if you have any feedback there. Thanks!

I've gotten a working example with MaybeHttpsStream. It definitely needs some work as it is currently very verbose. Should I post my findings here or open a new issue?

@uncotion Here is a working example of a TLS server using the updated From trait additions.

I see that Warp has an implementation of all this. Would it be an option to move that implementation here?

@timbru sort of! Warp uses rustls, while this crate is currently using native-tls. However, it'd be a fine place to start, and just adapt to the native-tls types.

@seanmonstar do you mean that it should use native-tls directly? Or could it be built on existing work in tokio-tls. I need to do more research - I am fairly new to this - but it seems to implement a lot of what is needed, and it's already a dependency.

I just meet the same problem, and after searching, I found that maybe it's not hyper's duty to do, but tokio. the "tokio-rustls" crate gives a demo, https://github.com/tokio-rs/tls/blob/master/tokio-rustls/examples/server/src/main.rs, it show that after get a tcp stream, wrap it to a tls stream, and pass it to the http handler. I also found that hyper can deal with request in connection level, so i think the way is,
let acceptor = TlsAcceptor::from(Arc::new(tlsconfig));
let listener = TcpListener::bind(&"<IP_ADDRESS>:25025".to_string()).await?;

loop {
        let (tcp_stream, _) = listener.accept().await?;
        let acceptor = acceptor.clone();

        tokio::spawn(async move {
            let mut tls_stream = acceptor.accept(stream).await?;
            if let Err(e) = Http::new()
                .http1_keep_alive(true)
                .serve_connection(tls_stream, service_fn(custom_handler))
                .await {
                eprintln!("Error, {}", e)
            }
        });
}

Hi,
Is it possible use hyper-tls for hyper server "0.12" ?

Thanks to @HunterGitHub, I found tokio-rs/tls is now based upon native-tls, not rustls anymore.
So, by tweaking this example , it's not too hard to make it hyper-tls compatible.
Full example linked HERE (w/details on using openssl/curl/wget)
The main two differences from @HunterGitHub's example is auto http1/http2 upgrading, and use of TokioIo.
I am really curious how and what @seanmonstar would refactor from native_tls and tokio_native_tls into hyper-hls to create the server functionality.
async fn hello(_: Request<hyper::body::Incoming>) -> Result<Response<Full<Bytes>>, Infallible> {
    Ok(Response::new(Full::new(Bytes::from("Hello, World!"))))
}

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    // Bind the server's socket
    let addr = "<IP_ADDRESS>:12345".to_string();
    let listen: TcpListener = TcpListener::bind(&addr).await?;

    let pem = include_bytes!("cert.pem");
    let key = include_bytes!("key.pem");
    let cert = Identity::from_pkcs8(pem, key)?;

    let tls_acceptor = native_tls::TlsAcceptor::builder(cert).build()?;
    let tls_acceptor = tokio_native_tls::TlsAcceptor::from(tls_acceptor);

    loop {
        let (socket, _) = listen.accept().await?;
        let tls_acceptor = tls_acceptor.clone();
        let server = auto::Builder::new(TokioExecutor::new()); //http1 or http2

        tokio::spawn(async move {
            let tls_stream = tls_acceptor.accept(socket).await.unwrap();
            let io = TokioIo::new(tls_stream);
            let service = service_fn(hello);
            server.serve_connection(io, service).await.unwrap()
        });
    }
}


freshping: Creating a mapping for complete_event_type.

This is a follow-up to https://github.com/zulip/zulip/pull/19274. We map the supported event types to a
more suitable format for events.
Self-review checklist

[ ] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[ ] Explains differences from previous plans (e.g., issue description).
[ ] Highlights technical choices and bugs encountered.
[ ] Calls out remaining decisions and concerns.
[ ] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[ ] Each commit is a coherent idea.
[ ] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[ ] Visual appearance of the changes.
[ ] Responsiveness and internationalization.
[ ] Strings and tooltips.
[ ] End-to-end functionality of buttons, interactions and flows.
[ ] Corner cases, error conditions, and easily imagined bugs.

Merged, thanks @PIG208!


Add goat counter support

https://www.goatcounter.com/

great rationale from GoatCounter https://github.com/zgoat/goatcounter/blob/master/docs/rationale.markdown

@arp242, what I love from GoatCounter is its rationale.

Cheers, thanks. I should really clean that up a bit and make it a page on the main website, but for the most part I'd rather be working on the project than all the marketing and other stuff 😅


debian package

i created one: http://sid.ethz.ch/debian/ptable
but there would be a name conflict https://packages.debian.org/sid/source/ptable

Hi, thank you. I see. Could the package be named "cptable" for example or would I have to change the repository and binary names as well?

A search at https://packages.debian.org/search?searchon=contents&keywords=ptable&mode=path&suite=stable&arch=any says there's /usr/bin/ptable already from another package, and src:ptable (debian source package is also already used).
cptable appears to be free. but what is "cptable" for?

Good. Yes, it's a periodic table for the terminal coded in C, so that's why I thought of renaming it to cptable.

cptable i would have called it pt or peta dunno. would there also be command line options like -h and a non-interactive mode?


az load support for zip artifacts upload

Changes

vendored_sdk upgrade for ZIP artifacts
az load CLI support for ZIP artifacts upload to a test
fixes on return types post typespec generated sdk upgrade
bug fix to allow relative path of files to upload when load test create with config file

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

General Guidelines

[ ] Have you run azdev style <YOUR_EXT> locally? (pip install azdev required)
[ ] Have you run python scripts/ci/test_index.py -q locally? (pip install wheel==0.30.0 required)
[ ] My extension version conforms to the Extension version schema

For new extensions:

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

About Extension Publish
There is a pipeline to automatically build, upload and publish extension wheels.
Once your pull request is merged into main branch, a new pull request will be created to update src/index.json automatically.
You only need to update the version information in file setup.py and historical information in file HISTORY.rst in your PR but do not modify src/index.json.

Thank you for your contribution! We will review the pull request and get back to you soon.

Please fix CI issues

Please fix CI issues

I have an ongoing PR from Sept which fixes the CI issues, waiting on its review and approval https://github.com/Azure/azure-cli-extensions/pull/8014


Migration to PHP 5.5 and Zend Framework 2.5

The work on this PR will be split into smaller, more manageable PRs


open files in new tab or new window

Is it possible for files (JPG, PNG, PDF etc.) to be displayed in the design of the page?
Alternatively, would it be possible to open files in a new window or new tab?

Can you clarify what you mean? The plugin sheet supports all media types. All browsers already support opening links in a new tab or window.

My understanding of this request is:
Either open files embedded in the page so you can still navigate and see the graph OR open them in a separate tab so you don't disrupt navigation

Ohh, I think you are using HTML Documents export mode and opening the files locally. Locally opened files do not support this while online files do. I'll see if there's anything I can do to support this locally.
As far as opening in a new tab, can you not just right click on a link to open in a new tab?


Syslog data format native support

A JVM-only extension is underway.

@oscerd do you mind if I work on this one?

Please go ahead and sorry for this long delay from my side.


travisCI: Install pkg-config

See build results for #263

Good to merge? @sjackman

I'd prefer to understand why packages that depend on pkg-config aren't installing it correctly. Are you able to do some troubleshooting into the root cause?

Changing depends_on 'pkg-config => :build in cloog.rb to a hard dependency?

@saketkc Do you mean get rid of => :build? This bug finally came up on Docker:
https://registry.hub.docker.com/u/sjackman/linuxbrew-bottle/build_id/22230/code/be6fqn4fpychd89sahnraqw/
==> Installing gcc dependency: cloog
Error: /home/linuxbrew/.linuxbrew/opt/pkg-config not present or broken
Please reinstall pkg-config. Sorry :(

Yes, I think we should get rid of :build

Just for cloog? All the other formula that depend on pkg-config use => :build. Why would only cloog be broken? I think this is a Homebrew bug, but I haven't been able to figure it out.

I just got this trying to install neovim:
==> Installing neovim/neovim/neovim dependency: makedepend
Error: /home/meta/.linuxbrew/opt/pkg-config not present or broken

Hi, Matthew. Does brew install pkg-config before brew install neovim resolve your issue?

Oh! Revelation, @saketkc! I found the root cause of this bug. When Homebrew does its dependency analysis it determines that it will install a bottle of makedepend, because there are Mac bottles available. When it instead installs makedepend by source, it finds that pkg-config is not installed. It didn't install pkg-config, because pkg-config is not required by makedepend bottle.
The real fix would be for the dependency logic to check that a bottle is available for this architecture.
@xu-cheng Any thoughts on this bug?

When it instead installs makedepend by source, it finds that pkg-config is not installed. It didn't install pkg-config, because pkg-config is not required by makedepend bottle.

That's unlikely as pkg-config should be installed when installing makedepend from source.

The real fix would be for the dependency logic to check that a bottle is available for this architecture

This logic exists for all along.
Is there a minimal example to reproduce this bug so I can debug? Also @jacknagel should know more  than me about dependency issues.

I would need more detailed build output and some steps to reproduce, otherwise I can only guess.

% brew install pkg-config
Error: pkg-config cannot be built with any available compilers.
To install this formula, you may need to:
  brew install gcc
% gcc --version
gcc (GCC) 4.9.2 20150212 (Red Hat 4.9.2-6)
% which pkg-config
/usr/bin/pkg-config
% pkg-config --version
0.28

Is this minimal enough?
% brew install -v bug264.rb
==> Installing bug264 dependency: makedepend
Error: /home/meta/.linuxbrew/opt/pkg-config not present or broken
Please reinstall pkg-config. Sorry :(
% cat bug264.rb
class Bug264 < Formula
  homepage "https://github.com/Homebrew/linuxbrew/pull/264"
  url "https://raw.githubusercontent.com/Homebrew/homebrew/master/README.md"
  version "1.0"
  depends_on "makedepend" => :build

  def install
    puts "Done."
  end
end

...or am I misunderstanding?

Thanks for the example, Matthew. That's perfect.

@lpar

Error: pkg-config cannot be built with any available compilers.

Follow these instructions: https://github.com/Homebrew/linuxbrew/wiki/Standalone-Installation#create-symlinks-for-gcc

Creating symlinks doesn't help. Same errors.
If you mean you want me to continue and install a whole new GCC and toolchain, that's a bit of a deal-killer.

@lpar You have two separate errors, Matthew. The solution to "Error: pkg-config cannot be built with any available compilers." is to create a symlink named gcc-4.9 in your path pointing to /usr/bin/gcc.
The error "pkg-config not present or broken" we're troubleshooting here, but once you have the compiler symlink should be fixed with brew install pkg-config.

Doesn't seem to be.
% brew install pkg-config
Error: pkg-config cannot be built with any available compilers.
To install this formula, you may need to:
  brew install gcc
% gcc-4.9 --version
gcc-4.9 (GCC) 4.9.2 20150212 (Red Hat 4.9.2-6)
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I can't reproduce this using upstream Homebrew. I don't have a linux VM or anything to test on, but if someone can give me access to such a system I'd be happy to investigate further.

@jacknagel If you have access to docker you can docker pull sjackman/linuxbrew

@lpar Hmm, that's frustrating. Can you report which -a gcc-4.9 and brew --prefix?
If you're willing to try a brew install gcc which will install GCC 5.1, it will likely resolve your issue.

Also try brew tap homebrew/versions

On a fresh Ubuntu install, I see this:
$ brew install -v bug264.rb
==> Installing dependencies for bug264: pkg-config, makedepend
==> Installing bug264 dependency: pkg-config
==> Downloading http://pkgconfig.freedesktop.org/releases/pkg-config-0.28.tar.gz

OK...
% which -a gcc-4.9
/usr/local/bin/gcc-4.9
% ls -la /usr/local/bin/gcc-4.9
lrwxrwxrwx. 1 root root 8 2015-06-04 12:15 /usr/local/bin/gcc-4.9 -> /bin/gcc
% ls -la /bin/gcc
-rwxr-xr-x. 2 root root<PHONE_NUMBER>-02-12 05:12 /bin/gcc
% ls -la /usr/bin/gcc
-rwxr-xr-x. 2 root root<PHONE_NUMBER>-02-12 05:12 /usr/bin/gcc

I made the links manually. Obviously /usr/local/bin is on my path. /usr/bin/gcc and /bin/gcc are identical according to sha256sum.
I'm using Fedora 21 if that helps. Also, it occurs to me that I'm running zsh, which might not be the case for anyone else. Ruby version is 2.2.2p95, installed via rbenv and ruby-build.
brew tap homebrew/versions doesn't seem to help anything.

OK, since it's a Friday I did some debugging, and I've found out why it's not detecting any working compilers.
In Library/Homebrew/os/mac.rb, OS::Mac#locate, it attempts to find GCC using File.executable on line 28 -- but it only looks in /usr/bin, it doesn't check any other path. If I move my symlinks to /usr/bin rather than /usr/local/bin then gcc-4.9 is found and I can brew install pkg-config.

@lpar It checks not only /usr/bin/ but two lines down also $(brew --prefix)/bin. You should put your symlinks in there.

@jacknagel On Linuxbrew, the installation of bottles is disabled unless the user has the glibc and patchelf formulas installed, because those two formula are required to be able to use Linuxbrew bottles (see here for code). Perhaps that logic is somehow related to this issue. I'll do some troubleshooting, see if I can reproduce the issue, and get back to you.

Yes, it does also check ~/.linuxbrew/bin. However, I think it ought to check the path and not require that the user create symlinks in order to use the distro's standard compiler.

Homebrew/Linuxbrew ignores most of the users' environment variables, including PATH by design to ensure reproducible builds.

and not require that the user create symlinks in order to use the distro's standard compiler

I agree with this. I simply haven't got around to fixing the issue. Feel free to submit a pull request.

Note that nice distros like Debian and Ubuntu that include versioned compiler names like /usr/bin/gcc-4.9 work just fine.

I've finally resolved this issue. I had modified pour_bottle? to check that glibc and patchelf are installed, but I had not modified install_bottle_for?. I mistakenly thought that install_bottle_for? calls FormulaInstaller::pour_bottle?, but it's actually calling Formula::pour_bottle?, which always returns true.


Rendering slow, fuzzy and incomplete

In FF 19, this pdf works not.
http://beta.arcig.cz/~bernard/vyuka-m/6krychli.pdf

I'm looking in a class of bugs involving the tiling pattern. Assigning this one to myself so that it stays on my to-do list.
Here is the uncompressed PDF from https://github.com/mozilla/pdf.js/issues/2825#issuecomment-24234561 to make debugging easier.
6krychli-uncompressed.pdf


Newly implemented simclr loss function seems to be wrong?

Correct me if I'm wrong but when using mutiple gpus, the newly implemented simclr loss seems to be wrong.
The problem is in pos_mask.fill_diagonal(False)
As a simple example, for z with shape (N x 2, d) with 2 gpus, the positive mask for the first gpu is correct since the similarities computed are in the shape of (N, N x 2) with the first N dimensions (along dim=1) belonging to view 1, which would be the same as the query view and thus correctly set as False.
However, for gpu 2, the computed similarities would be of shape (N, N x 2) with the last N dimensions(along dim=1) belonging to the same view as the query view. Thus the correct pos_mask would be to set the "second group's diagonals" as False.
Maybe I misunderstood how exaclty the gather function works (from my knowledge, it outputs a list ordered as the rank, thus the gathered outputs for all gpus would be the same order) or some other part of the implementation.

Indeed the diagonal is wrong and we should set it according to the rank of the device. Already pushed the fix here:
https://github.com/vturrisi/solo-learn/blob/06dd435f220f1b72a035d858c98de7b9ce0327ae/solo/losses/simclr.py#L51-L52


Azure OpenAI: remove incorrect 'purpose' check on FileClient.GetFiles()

Closes #44912 -- many thanks to @SergeyMenshykh for the report!

API change check
API changes are not detected in this pull request.


[COM Server Demo] Exception throw following run steps

In Registered COM step 3:

Follow the instructions for COM server registration that were emitted during the build.

For my case it is:
regsvr32.exe "C:\Users\ruiyli\Projects\samples\core\extensions\COMServerDemo\COMServer\bin\Debug\net7.0\COMServer.comhost.dll"

RegSvc32 throws exception:

COMServer.comhost.dll was loaded but the call to DllRegisterServer failed with error code 0x8007005.

I missed this:

The following commands must be executed from an elevated command prompt.
Now it passed:


Entitas DSL (Domain Specific Language)

The current code generator
The code generator is very flexible and can be customized heavily to fit all your need.
It currently works like this:

ICodeGeneratorDataProvider converts a specific source format into ComponentInfo[]
ICodeGenerator converts ComponentInfo[] into CodeGenFile[]
ICodeGenFilePostProcessor writes files to disc.

Again:

DataProvider(source) returns ComponentInfo[] (source to intermediate format)
Generators(ComponentInfo[]) => CodeGenFile[] (intermediate format to source code)
PostProcessor (source code to disk)

Example:
You write a new PositionComponent (source)

TypeReflectionProvider(sourceCode) uses reflection to create ComponentInfo[] (intermediate format)
ComponentExtensionsGenerator (and others) create CodeGenFile[] based on ComponentInfo[] (result)

source => intermediate format => result
As we all know, the TypeReflectionProvider uses reflection based on the last compiled assembly. This means, if there are compile errors the assembly is not updated and generating again won't include any changes made to the source code until it can compile again.
That's why we're working on a new code generator DataProvider based on Roslyn to be able to create the intermediate format even when the solution does not compile.
Once we have it, we can simply swap the current ICodeGeneratorDataProvider which is the TypeReflectionProvider with the RoslynDataProvider and we're done. Everything works because the source analysis is decoupled from the actual code generation.
That means we can write any kind of ICodeGeneratorDataProvider that converts any kind of source into the intermediate format and swap it. E.g. a JsonDataProvider that can parse a json where all components are defined.
Suggestion
We could write a custom DSL which defines all components in a single file and we can create a new DSLDataProvider to convert this source into ComponentInfo[]. This file is not affected if there a compile errors or not. That means, we can regenerate anytime we want.
This would be an alternative to the RoslynDataProvider. Currently, Roslyn doesn't fully work on all platforms, that's why I'm looking to find alternatives.
Let me know what you think.

If you have doubts or arguments against it, let me know.

Looks good, but when Roslyn will work in those platforms? The DSL solution looks like a temp workaround until it works (and in those platforms where Roslyn works is better to use it because you don't need to write that DSL)
In any case, the concept is cool !
PS: Question, i'm currently on windows, how would be for me the swap to Roslyn ? I need to install something ? Or will be bundled with entitas releases?

Afaik it's up to the Microsoft/Xamarin/Mono guys to implement missing features for all platforms. I cannot really tell when / if.
It's planned that any new code generator will be bundled with Entitas, so nothing to do on your part.

I'm not sure if you are aware of this yet, but all of the uFrame ECS system was open sourced recently: link. uFrame was also using a code generator that did not rely on reflection. Maybe something can be lifted from there?

They use CodeDom. I did not look at CodeDom yet, but now would be a perfect time to do so :)

Nice, I wish I could give you any pointers but I never had time to dive into that part of uFrame..

That was already a good hint to finally fiddle with CodeDom :) Thanks

Will close because of #77


chore: add CI job to run lean4checker periodically

I propose we turn this on, and see if it works. Once it does, we then remove the lean4checker step from regular CI.

@adomani, cron jobs do not run on PRs. They have to be tested in production. :-)

maintainer merge

bors merge


track muted / unmuted events should specify track type

At the moment, Track Muted and Track Unmuted Events are used for both pausing and resuming videos or audio ( microphones ), but the TrackMuted & TrackUnmuted Event Structs don't specify which track got muted or unmuted

The TrackMuted and TrackUnmuted doesn't contain the Track struct but the TrackPublication.
This is because you can receive these events without being subscribed to these tracks.
If you're subscribed to the track, use this method to get the current Track struct


Analyzer checks "class C" class declaration in a very strange way.

Dart SDK Version: 2.1.0-dev.6.0
OS: Windows 10
Here is a sample code which declares a class C<X extends C>:
//class A<X extends C> {}
class C<X extends C> {}
main() {}

It fails with compile time error both in analyzer and dart:

Analyzing test1.dart...
error - Type parameter bound types must be instantiated at test1.dart:2:19 - strong_mode_not_instantiated_bound
1 error found.

See also bugs #33152, #31810.
This is very strange, but if I uncomment a first line in the code, i.e. have:
class A<X extends C> {}
class C<X extends C> {}
main() {}

this test still fails with the same compile error with dart, however with dartanalyzer it starts to pass unexpectedly, analyzer sample output is:

Analyzing test1.dart...
No issues found!

So I believe analyzer should behave in the same way with both sample code examples above.

I'm looking into this now.

Fix out for review: https://dart-review.googlesource.com/c/sdk/+/78867


Button not selected after clicking

Describe the bug
While editing a Camunda Form, clicking a button field right in the button does not select it.
Clicking on the borders or within the field space outside the button, achieves expected behavior.
Steps to reproduce

Create a form
Add a button with a long field label
Click the button itself

It will not select it.
Expected behavior
Expected behavior: Button field is selected and options are loaded on the right panel
Environment
Camunda Modeler system information

Version: 5.10.0
Operating System: Windows 10 amd64
Plugins:
Execution Platform: Form - Camunda Platform 7

Additional context
No response

Could you share a screen capture? That helps a ton to establish the context to your issue. Thanks!

Never mind my previous comment, I think I was able to reproduce the issue. Is that what you're referring to?

CC @Skaiir @pinussilvestrus.

Thanks for letting us know 👍 I think this issue is present for quite a while, but wasn't reported beforehand.
I added this to our board so it can go through our Inbox grooming.

This will most likely fixed as we currently work on changes in the editor state of the form fields (cf. https://github.com/bpmn-io/form-js/issues/396). So happy to take this one and report once fixed 👍

I just checked and we already fixed that via<EMAIL_ADDRESS>It works for me in the current Desktop Modeler nightly 👍
I'm closing this as it will be fixed in the upcoming minor release. Feel free to re-open if you still see an issue.


[Question] Which API?

Hi,
thank you for your work.
I'm no expert programmer, so I can not check your code.
But I'm interested in how it works. So you are using an API from revolut? Which one, is there a public documentation? Can everyone use it, or are you providing your personal API Key for this tool?
Since I can not check your application, I would try to build something like this on my own in python for personal use. Just need to know how the communication with revolut works.

Hey,
Are you a programmer or are you not, since you mentioned being able to develop in python?
The API code is in ... src/api.ts! It's using the official revolut API, there is no documentation for it.
Cheers.

thanks, nowadays it is not as simple, I know basics of python and know APIs and how to connect to them. But that's basically all I know, so it is really hard for me to read and understand your code, also because I dont know the language you are using.
So back to my question:
ok, in your code I see baseurl is "api.revolut.com". But when I google for revolut and API I find business API: https://developers.revolut.com/docs/#business-api and banking API https://developers.revolut.com/docs/#open-banking-api .
So, you aren't using one of them, but instead you are using an non public API, only ment to be used by the revolut app (and therefore the lack of documentation)?
I just want to understand the API you are using and how authentication and so on works. I could easily write a python script for the business API documentation, but this is obviously not what you are using.


SDS tests verbose and might create flakyness

Unit tests show logs like the following ( repeated many many times).
It's likely some SDS tests fails to close socket, and may result in flakes down the road.
Also it's hard to debug other problems.
2019-03-26T17:16:01.636681Z	error	SDS grpc server for workload proxies failed to start: grpc: the server has been stopped
2019-03-26T17:16:01.636718Z	error	SDS grpc server for ingress gateway proxy failed to start: grpc: the server has been stopped
2019-03-26T17:16:01.636740Z	error	SDS grpc server for workload proxies failed to start: grpc: the server has been stopped
2019-03-26T17:16:01.636829Z	error	SDS grpc server for workload proxies failed to start: grpc: the server has been stopped
2019-03-26T17:16:01.636917Z	info	Start SDS grpc server for ingress gateway proxy
2019-03-26T17:16:01.636965Z	info	Start SDS grpc server for ingress gateway proxy
2019-03-26T17:16:01.637000Z	info	Start SDS grpc server for ingress gateway proxy
2019-03-26T17:16:01.637006Z	error	SDS grpc server for ingress gateway proxy failed to start: grpc: the server has been stopped
2019-03-26T17:16:01.637095Z	error	SDS grpc server for ingress gateway proxy failed to start: grpc: the server has been stopped
2019-03-26T17:16:01.637112Z	error	SDS grpc server for ingress gateway proxy failed to start: grpc: the server has been stopped
2019-03-26T17:16:01.637188Z	info	Start SDS grpc server for ingress gateway proxy
2019-03-26T17:16:01.637293Z	info	Start SDS grpc server for ingress gateway proxy
2019-03-26T17:16:01.637348Z	error	SDS grpc server for ingress gateway proxy failed to start: grpc: the server has been stopped
2019-03-26T17:16:01.637363Z	info	Start SDS grpc server
2019-03-26T17:16:01.637469Z	error	SDS grpc server for workload proxies failed to start: grpc: the server has been stopped
2019-03-26T17:16:01.637492Z	info	Start SDS grpc server
2019-03-26T17:16:01.637493Z	error	SDS grpc server for ingress gateway proxy failed to start: grpc: the server has been stopped
2019-03-26T17:16:01.637518Z	info	Start SDS grpc server
2019-03-26T17:16:01.637571Z	info	Start SDS grpc server for ingress gateway proxy
2019-03-26T17:16:01.637595Z	info	Start SDS grpc server
2019-03-26T17:16:01.637635Z	error	SDS grpc server for workload proxies failed to start: grpc: the server has been stopped
2019-03-26T17:16:01.637635Z	info	Start SDS grpc server for ingress gateway proxy
2019-03-26T17:16:01.637663Z	error	SDS grpc server for workload proxies failed to start: grpc: the server has been stopped
2019-03-26T17:16:01.637683Z	error	SDS grpc server for ingress gateway proxy failed to start: grpc: the server has been stopped
2019-03-26T17:16:01.637801Z	error	SDS grpc server for workload proxies failed to start: grpc: the server has been stopped
2019-03-26T17:16:01.637840Z	error	SDS grpc server for ingress gateway proxy failed to start: grpc: the server has been stopped
2019-03-26T17:16:01.637964Z	info	Start SDS grpc server
2019-03-26T17:16:01.637992Z	info	Start SDS grpc server for ingress gateway proxy
2019-03-26T17:16:01.638002Z	info	Start SDS grpc server for ingress gateway proxy
2019-03-26T17:16:01.638125Z	info	Start SDS grpc server
2019-03-26T17:16:01.638172Z	info	Start SDS grpc server
2019-03-26T17:16:01.638211Z	info	Start SDS grpc server for ingress gateway proxy
2019-03-26T17:16:01.638239Z	error	SDS grpc server for workload proxies failed to start: grpc: the server has been stopped
2019-03-26T17:16:01.638247Z	info	Start SDS grpc server
2019-03-26T17:16:01.638275Z	error	SDS grpc server for workload proxies failed to start: grpc: the server has been stopped
2019-03-26T17:16:01.638298Z	error	SDS grpc server for workload proxies failed to start: grpc: the server has been stopped
2019-03-26T17:16:01.638332Z	error	SDS grpc server for ingress gateway proxy failed to start: grpc: the server has been stopped
2019-03-26T17:16:01.638361Z	error	SDS grpc server for ingress gateway proxy failed to start: grpc: the server has been stopped
2019-03-26T17:16:01.638424Z	error	SDS grpc server for workload proxies failed to start: grpc: the server has been stopped
2019-03-26T17:16:01.638455Z	error	SDS grpc server for ingress gateway proxy failed to start: grpc: the server has been stopped
2019-03-26T17:16:01.638466Z	info	Start SDS grpc server
2019-03-26T17:16:01.638538Z	error	SDS grpc server for workload proxies failed to start: grpc: the server has been stopped
2019-03-26T17:16:01.638653Z	info	Start SDS grpc server
2019-03-26T17:16:01.638671Z	info	Start SDS grpc server for ingress gateway proxy
2019-03-26T17:16:01.638727Z	info	Start SDS grpc server for ingress gateway proxy

Please provide the unit test info and the reproduce steps.

Can't find the commit, but we fixed this


Nested query param behavior changed when content type specified

This is a follow-up to #284 (and the related work in #286).
While that work was sufficient to restore the pre-refactoring handling of nested parameters, that had an undiscovered caveat: it only worked when a content type was not specified.
So this test passes...
(deftest test-nested-query-params
  (let [req {:query-params {:foo {:bar "baz"}}}
        {:keys [query-string]} (reduce #(%2 %1) req middleware/default-middleware)]
    (is (= "foo[bar]=baz" (URLDecoder/decode query-string)))))

But this one fails:
(deftest test-nested-query-params-with-content-type
  (let [req {:query-params {:foo {:bar "baz"}}
             :content-type :json}
        {:keys [query-string]} (reduce #(%2 %1) req middleware/default-middleware)]
    (is (= "foo[bar]=baz" (URLDecoder/decode query-string)))))

;; FAIL in (test-nested-query-params-with-content-type) (client_middleware_test.clj:33)
;; expected: "foo[bar]=baz"
;;   actual: "foo={:bar \"baz\"}"
;;     diff: - "foo[bar]=baz"
;;           + "foo={:bar \"baz\"}"

🤔
The culprit is this conditional. This doesn't really seem like necessary behavior—but I'd welcome help in thinking through the various cases and what I might be missing—and it is certainly a change from how things worked before the refactoring.

Hmmm.  I don't see an obvious relationship between form-urlencoded bodies and nested query params, but I'll need to look at the RFCs to make sure it's not some weird quirk of the extended HTTP spec.  If anyone already knows one way or another, I'd be happy to hear from them.

@camdez @ztellman This behavior was ported from clj_http that has the same issue (introduced after request body coercion was added).
https://github.com/dakrone/clj-http/issues/427

Following up. The issue mentioned above on the clj-http side was closed by adding new params on how to control nested params behavior. I'm going to port the solution to aleph as well. Will update my PR on :multi-param-style, otherwise it would introduce a lot of conflicts.


Embedding async

01d77d0 internalizes async, which is a requirement for Bioconductor. However, if users want to use gemmaAPI with async = T, they still need to either use the async package, as:
async::synchronise(getGeneEvidence('XIST', async = T))

OR, they could use the unexported gemmaAPI:::async and gemmaAPI:::synchronise:
gemmaAPI:::synchronise(getGeneEvidence('XIST', async = T))

Using it from the async package would be preferable, but unusual since it's not a dependency. I'm not sure how this is usually handled since I've never seen it done before. Alternatively, the functions can be exported in gemmaAPI (by adding the appropriate roxygen2 tag) so they can be used normally, but this is also unusual since this isn't the async package...
Not sure what the best decision is, here. Maybe ask Gabor what the intended design is? Maybe he's already told you @yavyx

The necessary async functions are being exported after 51d5f8f29fb397694d689b0de83ed2e9cc96b1a6, and everything is working as expected.

The question becomes: are all the (possibly) necessary functions exported? async has a number of them (https://github.com/gaborcsardi/async).
My intuition is that it is better to soft-depend on async instead of exporting from aaa-async.R and have people download it themselves if they want to use the asynchronous requests. That way, they have access to all the functions.


Problem in Lanczos with Hilbert space greater than 2^32 (Sz=0)

Hi,
using the xcode version #49f8fe7, @riccardo-rende and I tried to diagonalize an Heisenberg chain using this code :
#include <xdiag/all.hpp>

using namespace xdiag;

int main() try {

  int n_sites = 36;
  int nup = n_sites / 2;
  Spinhalf block(n_sites, nup);

  // Define the nearest-neighbor Heisenberg model
  BondList bonds;
  for (int i = 0; i < n_sites; ++i) {
    bonds += Bond("HB", "J", {i, (i + 1) % n_sites});
  }
  bonds["J"] = 1.0;

  set_verbosity(2);                  // set verbosity for monitoring progress
  double e0 = eigval0(bonds, block); // compute ground state energy

  Log("Ground state energy: {:.12f}", e0);

} catch (Error e) {
  error_trace(e);
}

We checked that up to L=32 we get the correct results.
However, for L=34 we obtain the following error:
Warning: Tmatrix zero dimensional in eig0_cplx
Ground state energy: nan

and for L=36 the code runs but the energy is wrong, namely it goes below the exact one :
Exact energy per site : -0.44378432839067183
Lanczos energy per site after 64 iterations : -0.4737482323668045

The same happens for the square lattice, the energy for the 4x4 is correct, instead for the 6x6 goes below the exact one.

Dear @llviteritti, thank you very much. This is actually the first issue someone is raising so it is good to know first people are using the code. This is a bug, that will need to be fixed. I will look into it and keep you updated.

I just tried to reproduce the error without success. On my side, the correct results are computed. I was using the Intel MKL linear algebra backend, which has a 64 bit interface.
It would be good to know if you are using a 32bit Lapack implementation. I think XDiag should warn or even throw an error if this is indeed the case.

Dear @awietek, thank you for your quick reply.
We have now installed XDiag with the Intel MKL linear algebra backend and the simulations are running for L=36.
We will update you as soon as the Lanczos iterations are complete.

Ah, cool, that's good to hear. Do you get the right energy now? Still, something like this should not happen. An error should be thrown at compile time if one tries to link to 32 bit, or an error at runtime if it's linked to 32 bit but the vector is too big. I'd like to understand this better.

Yes, now we get the right energies! Thank you again.

Good to know. I am keeping this issue open, since there should be a solution to when one is trying to link to a 32 bit Lapack implementation.

@llviteritti I now added a security check which checks that the block dimension is not too big if a 32 bit Lapack backend is used. Could you let me know if with your initial setup this error gets thrown correctly on your machine? If so I will close the issue.

Using the latest version of the commit #2640a8d and BLAS with 32-bit interface, now gives the error:
Trying to create a block whose dimension is too large for the backend BLAS routines. Your backend BLAS routines have a 32 bit interface, and a vector beyond a dimension of 2^31 cannot be represented. If you want to still perform this calculation, you will need to compile XDiag with a 64 bit backend, for example the ILP64 interface of IntelMKL.
So it should be fine now. Thank you very much for the support!

Thanks for checking. Yes, this is exactly what should be shown. I'll be closing this then


Broken test: ES6: Use export to Reuse a Code Block

Describe your problem and how to reproduce it:
There should be two possible ways to pass the test. The instructions point both of them out and say "Either approach is perfectly acceptable.". But the second approach doesn't pass the test.

export const foo = "bar";
export const bar = "foo";
2.
const foo = "bar";
const bar = "foo";
export { foo, bar }
Add a Link to the page with the problem:
https://learn.freecodecamp.org/javascript-algorithms-and-data-structures/es6/use-export-to-reuse-a-code-block
Tell us about your browser and operating system:

Browser Name: Mozilla Firefox Quantum
Browser Version: 68.0.2 (64-bit)
Operating System: Linux Mint 19.2 "Tina"

If possible, add a screenshot here (you can drag and drop, png, jpg, gif, etc. in this box):

It is clearly written that the code has to be solved by the first option i.e
export const foo = "bar";
export const bar = "foo";
For this specific problem, only the above-stated solution would be correct.

Fair enough, it does say to utilize the first way. I still think it would be better if the challenge would allow for both solutions, but due to the current instructions this does not qualify as a broken test. Please ignore/delete post.

@RogiNicba This challenge has been rewritten but has not yet been released to production.  You can take a look at it here.  If you feel there is still an issue with this challenge, please reply back.  If there are no further issues, please close it.
Thank you.


support Scala 2.13.0-RC3

@seratch
Please merge and publish for Scalate's 2.13.0-RC3 support.

done> publishing jars https://oss.sonatype.org/content/repositories/staging/org/scalatra/scalate/scalamd_2.13.0-RC3/


API Gateway To Lambda: timeout cannot be over 29 seconds

AWS API Gateway timeout limit for integrations was previously 29 seconds. There has been an update to allow increasing the Gateway integration timeouts past the previous limit. https://aws.amazon.com/about-aws/whats-new/2024/06/amazon-api-gateway-integration-timeout-limit-29-seconds/
However, when implementing a Gateway API to Lambda, it seems that when synth'ing the stack, this seems to hit a validation error.
Reproduction Steps
const ApiGateway = new ApiGatewayToLambda(
      this,
      'MyAPIGW',
      {
        lambdaFunctionProps: {
          runtime: Runtime.PROVIDED_AL2,
          handler: 'bootstrap',
          code: Code.fromAsset(join(__dirname, '..', '..', 'target', 'bin', 'linux', 'amd64', 'lambda', 'runtime')),
          timeout: Duration.minutes(5),
          environment: {
            ...
          },
        },
        apiGatewayProps: {
          defaultCorsPreflightOptions: {
            allowOrigins: ['*'],
            allowMethods: [HttpMethod.POST],
          },
          integrationOptions: {
            timeout: Duration.seconds(60),
          },
        },
      },
    );

Error Log
WARN AWS_SOLUTIONS_CONSTRUCTS_WARNING:  Possible override of timeout value.
Failed to synthesize: Error: Integration timeout must be between 50 milliseconds and 29 seconds.

Environment

CDK CLI Version      : 2.145.0 (build fdf53ba)
CDK Framework Version: 2.145.0
AWS Solutions Constructs Version     : 2.60.0
OS                   : MacOS
Language             : English

This is :bug: Bug Report

Based on quick triage, this error seems to propagate from the aws-cdk core library: https://github.com/aws/aws-cdk/blob/db3e77d4b32a7464b38f8502d7c113ac163e17dc/packages/aws-cdk-lib/aws-apigateway/lib/integration.ts#L207-L209

Fixed in aws-cdk release https://github.com/aws/aws-cdk/releases/tag/v2.147.0

Sorry for the slow response, thanks for following up.


Add "replace"

Add an equivalent of https://developer.hashicorp.com/terraform/language/functions/replace

Looks like the code for this is in place: https://github.com/pulumi/pulumi-std/blob/master/std/replace.go
But something means it's not connected in correctly.


weights for the trained model?

Can you provide the weights that got 70% mAP on VID dataset?

Here's my public Google drive of the models: models. They are referenced in the detect-to-track repo but I must have forget to reference the trained model in this repo.


test: abstract commits with GitMock

Change-Id: Ibbe59fe3142f05896f792d19a45792c8195e043b
Depends-On: #335

This pull request is part of a stack:

test: add coverage on PR content (#334)
feat: remove the change ID from the PR description (#335)
test: abstract commits with GitMock (#336) 👈

@mergifyio rebase


buildbot: Revert "buildbot: 3.11.2 -> 3.11.3"

This reverts commit 02d17ed973a443359ab9898b26a50d8766735909.
Buildbot 3.11.3 has broken git changerequest checking, revert until this is fixed with the 3.11.4 release. See 1 for more details.
Description of changes

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

@Emantor can you check if https://github.com/NixOS/nixpkgs/pull/316872 also fixes the issue?


CORS

HTML src is allowed but GET XMLHttpRequest is not allowed because of CORS
Ideas:
💭 Make a hidden canvas element, get the Image, canvas...🤔
💭 Avoid string blob of the image in the first place 😔...stay defiant son

The server will be responsible for handing the request and encoding. All the app has todo is display --- minimal effort.

resolved via @569b69e

[ ] Request poster api on view
[ ] Delete old posters (add created field)


chore(deps): upgrade dev dependencies

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-dev-dependencies-k8s-29-main" workflow

⚪ Backport skipped
The pull request was not backported as there were no branches to backport to. If this is a mistake, please apply the desired version labels or run the backport tool manually.
Manual backport
To create the backport manually run:
backport --pr 4119

Questions ?
Please refer to the Backport tool documentation


Support Nuking CloudFormation StackSets and Stacks

This implements the removal of StackSets and Stacks with wait groups to ensure that the status moves to DELETED before considering the item nuked.
Note: there is a chance that when targeting stacks only that if it's part of a StackSet it could trigger an error which will be logged.

[ ] Update Documentation
[ ] Update Tests
[x] Update Code

These are issues that this PR potentially resolves.

Potentially Resolves https://github.com/gruntwork-io/cloud-nuke/issues/95
Potentially Resolves https://github.com/gruntwork-io/cloud-nuke/issues/149

I'm working on docs and tests. Also found an issue when stacks depend on each other if not deleted in the correct way the current implementation won't work, working on a fix.

It looks like to delete properly each stack's output has to be queried for import use, then a dependency graph built and deleted in order.

@ekristen thanks for your contribution, is this still something you plan on working on? We're in the process of cleaning old PRs and will be closing this in the coming weeks if not.


Candidate review tooling

I was just thinking the process for reviewing candidates by their Github probably overlaps a bunch with how a hiring manager would review candidate Github activity. Just thought I'd suggest checking into what sort of tooling is available that we could maybe re-purpose for this effort. 🤔

this will be covered on #170


Trigger compilation from CI on PRs

Triggers a custom version of the nightly build CI action on PRs. This gives an inline report of whether the build worked for each PR.

funnilly the winbuild is failing on this :)

funnilly the winbuild is failing on this :)

It will fail until the changes from https://github.com/flucoma/flucoma-max/pull/95 get merged.

I could guess that - I just resisted merging 95

Await the reviewers review :)


CommandBarFlyout style updates

CommandBarFlyoutAppBarButton* brushes were mostly not being used. I updated the button styles and also added padding around the backplate. Also, I adjusted all the margins for the icon and checkmark when present, so that the icon/checkmark line up underneath the first primary control icon, and don't overlap each other.

/azp run


Increase doc comment lint strictness and satisfy most of the warnings.

I see ways to more significantly improve some of the docs you changed, but I guess that is not the purpose of this PR, so I'll just say LGTM.

Of course, me too, c.f. this comment.

One unfortunate problem of this change is that we now get a cascade of warnings from swift-lint for all comments that start with a back-quote, like:
/// `true` iff the parameter has a default argument.
public let hasDefault: Bool

We’re using swift-lint in addition to swift-format?Sent from my iPhoneOn Dec 3, 2023, at 3:38 AM, Dimi Racordon @.***> wrote:
One unfortunate problem of this change is that we now get a cascade of warnings from swift-lint for all comments that start with a back-quote, like:
/// true iff the parameter has a default argument.
public let hasDefault: Bool
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you modified the open/close state.Message ID: @.***>

I meant swift-format. corrected my message.


Import from the root of js-combinatorics

Change-type: patch
Signed-off-by: Carol Schulze<EMAIL_ADDRESS>

@balena-ci I self-certify!

@balena-ci retest


React 18.0.0 dependency update

Describe the bug
Dependency update. Especially the new Expo SDK 46 is shipped with React 18
Platform & Dependencies

React Native or Expo version: SDK 46
Reanimated version: 2.9.1
React Native Gesture Handler version: 2.5.0

False Alarm-ish. So installing using npx expo install was grabbing wrong version and failing with react 18 dependency issue. Closing.


Add browserify support for external bundles.

The pattern-plate server browserify transform does not support external bundles.

I just made a pull request with the wished functionality. Please give feedback for potential improvements.

Would be amazing if you outlined

what the use case is
what API changes this yields
what changes on build and demo output this yields

Thanks! :fist:

Sure,

Use case: it is common for projects to have external bundles or dependencies outside of the generated browserify bundle. Most of this cases or constraints are out of the developers reach.
In such cases you don't want to have duplications causing negative side effects to the project. external bundles allows you to reference these external files within your application without including them in your bundle. It actually makes absolutely sense to include ignore and exclude too because this issue is not an isolated  use case, but rather a necessary functionality that a browserify transform  for the patternplate should provide.

API changes: well I already made a pull request with an initial draft of how an external bundle could look like in the Browserify transform. (Pull Request)[https://github.com/sinnerschrader/patternplate-server/pull/29]. Nevertheless I am even more convinced that external, exclude and ignore bundles should be included. To that we can discuss on my next pull request :)

Currently the external bundle is based pretty much on the same implementation of the current transform, speak, within the browserify transforms configuration there is a new  "external" property containing an empty array. The array accepts a string list (paths) of the files to externalize. If the array is empty the transform does nothing,  otherwise .external() will be added to the browserify object containing the list of files to externalize. I tested it on the Patternplate too and there was no problem whatsoever to include the list in the Patternplate transforms configuration.

Build & Demo output changes: this changes are only relevant to the build task and should not be included in Demo. The build output changes are pretty straightforward, the externalized files will not be included the bundle ;)

Ok sounds good, some notes:

First off: Thanks for bringing this up, it is a glaring omission from browserify-transform
Left some comments on the changes
Does this allow for externalization of patterns? In my mind it should. Same goes for ignoring and exclusion
How does this affect patterns with library JS that do not have any demo?
I'd rather see ignore and exclude in the same PR, pseudo code:

function applyBundlerConfig(bundler, method, configs) {
  const fn = bundler[method];
  configs.map(fn);
  return bundler;
}

applyBundlerConfig(bundler, 'external', options.external);
applyBundlerConfig(bundler, 'ignore', options.ignore);
applyBundlerConfig(bundler, 'exclude', options.exclude);

Side note: Add yourself to the package.json contributors field as part of this PR ;)

More pseudo code
['external', 'exclude', 'ignore'].forEach(methodName => applyBundlerConfig(bundler, methodName, options[methodName]));

Ok cool :)
I will make the changes and make the pull request as discussed.
Pull request follows soon.
All best

The pull request have been updated. Support for the bundle.external(),  bundle.ignore(), bundle.exclude() methods is now available. Appreciate if you take a look at it and give some feedback.

@Palmaswell is this still an issue?


Width of Tabs not calculated correctly

The plugin uses outerWidth() to get the width of the tab elements. This function gives a rounded value of the width.
If the tabs all have a real width of 100.4px outerWidth() will return 100. Having a lot of tabs this rounding error sums up to a value where it will prevent the fixed width box from rendering correctly.
I think code like this should be used to determine the width: this.getBoundingClientRect().right - this.getBoundingClientRect().left. I am not sure but I think this also makes the margin calculation in setMovableContainerWidth() (line 437) unnecessary.

I just found out that this might have changed in jQuery 3. I cannot reproduce it with jQuery 3. See https://jquery.com/upgrade-guide/3.0/#breaking-change-width-height-css-quot-width-quot-and-css-quot-height-quot-can-return-non-integer-values


chore(gitignore): add laravel folder

Running the test locally initialises a /laravel/ folder, but that folder is not ignored by git.

thanks!

I realise only now that this was actually not necessary. The issue is that the tests/laravel-test.sh and tests/lumen-test.sh depend on the current working directory to be the git repository root, and git repository's dirname to be "psalm-plugin-laravel". If these conditions are fulfilled, laravel and lumen are installed outside of the repository, so the gitignore isn't necessary.
On the other hand, it would probably be better to install both libraries inside the repository (or even inside the tests folder), but ignore lumen as well, if that has no negative side-effects.
/cc @mr-feek

sounds fine to me


Next JS

Thanks for the work!
Doesn't work in Next JS. Any chance you have some docs/examples of usages in Next JS?
I tried to do a dynamic import but then I don't have access to initParticlesEngine, when I try to do a dynamic import of that, it says it's a hook that cannot be used inside a useEffect.
Any help appreciated.

There are two samples using Next.js here: https://github.com/tsparticles/react/tree/main/apps
Be aware that currently there's a known issue: https://github.com/tsparticles/react/issues/83


Add AES-[128/192/256]-CTR encrypt method.

I have rebased your code and merge.
shadowsocks/shadowsocks-go@d83094c93e96b89a16fe1312d892f7c69cb669cf
and fix close mistake.
shadowsocks/shadowsocks-go@4bb1d5df51317c2119bb016a0c3a25c1266b67b4


Add ability to use scoped routes, and named routes

I had the need to use scoped and named routes in my API:
namespace 'api' do
  namespace 'v1' do
    scope ':brewery_id' do
      jsonapi_resources :recipes do
          jsonapi_resources :recipe_grains, path: :grains
          jsonapi_resources :recipe_hops, path: :hops
          jsonapi_resources :recipe_mash_rests, path: :mash_rests
        end
    end
  end
end

This pull request allows for the path option to work.
For the scoping, just add:
def scope_id
  ...
end

To define your scope to your controller and you're good to go.

Thanks. Could you please squash your commits (or equivalent) so the .idea folder isn't in the commit log. Also, please make sure all tests pass and the project has 100% coverage. This can be done with: COVERAGE=true rake test

Build is running right now, but should be good to go.

Please add some tests to show how this will be used. Make sure you show how related resources references will be serialized. There are many options on the rails scope method. How does this change work with them? It would be good to add some documentation to the readme to cover the usage of this.
Why did you name the controller method scope_id?
Also, please squash your commits so the .idea directory addition and removal isn't in the change log. See http://stackoverflow.com/questions/5667884/how-to-squash-commits-in-git-after-they-have-been-pushed

Please add some tests to show how this will be used. Make sure you show how related resources references will be serialized. There are many options on the rails scope method. How does this change work with them? It would be good to add some documentation to the readme to cover the usage of this.

Will do. I dug into the Rails implementation of scope in routing, and I think I will have to implement this differently. I really implemented it for my specific use case, but there are several other things to think about. I think this logic probably belongs in the route_ext.rb patch. I'll make sure to add tests for all the other use cases.

Why did you name the controller method scope_id?

There really wasn't much of a reason, other than I was using an id to scope my routes. I'll rethink this with the refactor. Seems like someone could use a dasherized scope, among other things, so scope_id is not necessarily the best name.

Also, please squash your commits so the .idea directory addition and removal isn't in the change log. See http://stackoverflow.com/questions/5667884/how-to-squash-commits-in-git-after-they-have-been-pushed

Pretty sure I already did that? The .idea commits aren't showing up in the commit history anymore as far as I can see.

scoped route is nice, any update on this?

@maxhungry Just life getting in the way of me fixing this PR. Feel free to fork and hack away if you want! Thanks for the reminder though. I'll try to set some time aside to get this going again.

@thibaudgg @maxhungry @lgebhardt I'm going to have to punt on this. I am involved in way too many projects right now, and just looked at the code base and the master branch has diverged quite a bit since I last looked at this. Sorry everyone! I hope someone is brave enough to take over on it.


make part5_agg2_60seconds work for fragmentation metrics only, or explain in the vignette better

To generate fragmentation metrics, we need to include part5_agg2_60seconds=TRUE. However, this messes up all of the other metrics in the part5 summary outputs because all of it is calculated on 60s, not 5s data.
Solutions:

Can this be made clear in the vignette for other users who may not realise this?
OR
If possible, can this function work externally to the generation of the other traditional part5 outputs so we don't need to run it twice? one to get our daily summary variables based on 5s epochs, then again aggregated to generate fragmentation metrics?

A development somewhat related is also to have the function to generate csv outputs based on a 60s aggregate for timestamps in instances such as graphing purposes, when the actual summary metrics are made using 5s epochs.

Thanks, great suggestion. I think both documentation and extra argument are needed.
Here, it may be helpful to think about a new input arguments to eventually replace part5_agg2_60seconds to make it all more flexible. For example one argument for each functionality, such as: epochSize.part5.timeuse = 5 and epochSize.part5.frag = 60.

Thanks Vincent, that would be an excellent solution if it was made that way.


Update themes.yml

Added new theme

@ramswaroop  Thanks for adding Photography. Note: You're missing the preview screenshoot pic 250x200 px. Please add if you want to add your theme.  Cheers.

@ramswaroop  Are you still interested in adding your theme?

Yes, would be adding the thumbnail in a while.

@ramswaroop I added the missing screenshoot 250x200 px. Cheers.


TypeError: Cannot assign to read only property 'jsx' of object '#'

when i want to use typescript template then npm start get this error.
i know this is duplicate .
but i think this error is important to solve.

reference
https://github.com/facebook/create-react-app/issues/9868

i have the error yet.
no affected

I'm getting the same error. After installing unmet peer dependencies and changing the tsconfig.json the errors are gone. See:
https://stackoverflow.com/questions/64932747/yarn-create-react-app-with-typescript-throwing-errors

I have the same issue, you can override it by removing the tsconfig.json and run yarn start will populate a new tsconfig.json and will work!

I have the same issue, you can override it by removing the tsconfig.json and run yarn start will populate a new tsconfig.json and will work!
P.S you can't modify the tsconfig.json file!

this work, thanks

'cp' is not recognized as an internal or external command

'yarn' is not recognized as an internal or external command

I have the same issue, you can override it by removing the tsconfig.json and run yarn start will populate a new tsconfig.json and will work!
P.S you can't modify the tsconfig.json file!
there's a solution for this #9868 (comment)

This is only works once. If you stop the server and restart it throws the same error. Seems to be an issue with Typescript itself. I did a rollback to v4.0.5 and changed the jsx option to react and it works fine.
package.json
+"typescript": "^4.0.5",
-"typescript": "^4.1.2",

tsconfig.json
+"jsx": "react"
-"jsx": "react-jsx"

Can be closed. Fixed in in release<EMAIL_ADDRESS>

i am confused.
what should i do now to fix?
should i run create-react-app again?

I had this issue until I

updated my react-scripts to 4.0.1
updated my typescript version to 4.1.2
updated my package.json to reflect the changes
ran npm start - no errors.

After updating, I didn't even have to re-generate my tsconfig.json


🐛[BUG][Breadcrumb] Page was automatically reloaded when clicking on breadcrumb

Hi,
Currently, I use pro-layout version 5.0.15. I'm facing reload a page when I click on a breadcrumb. It's quite not good behavior.

you can try
itemRender={(route, params, routes, paths) => {
        const first = routes.indexOf(route) === 0;
        return first ? (
          <Link to={paths.join('/')}>{route.breadcrumbName}</Link>
        ) : (
          {route.breadcrumbName}
        );
      }}

my doc is bad

Thank you for your support @chenshuai2144 . This is my approach:
  itemRender: (route, params, routes, paths) => {
    const isNotLast = !!routes
      .filter((_: any, index: number) => index !== routes.length - 1)
      .find((item: any) => item.path === route.path);
    return isNotLast ? (
      <Link to={route.path}>{route.breadcrumbName}</Link>
    ) : (
      {route.breadcrumbName}
    );
  },

I think we need to update the document for pro-layout usually. I can't find it in README or somewhere like that.


Standalone ZGM player?

I'm trying to debug some issues with generating ZGM files from VGM files. Is there a standalone player that can be used to confirm the ZGM file sounds correct?

I don't have the answer, but I think the Discord is a better place for questions: https://discord.gg/xmnBWQS


Provide memory/RAM size recommendations

Currently, we only recommend at least 2GB of memory per node for a production instance - https://www.cockroachlabs.com/docs/stable/recommended-production-settings.html. This doesn't take into account dataset size or any other factors. We should have some general guidelines for either, amount of memory per core, or amount of memory per data stored.

Closing in favor of https://github.com/cockroachdb/docs/issues/3936.