text:
Circulation Rules - 1st Pass

We need to write circulation rules so that we can test loans in the sandbox and determine if those rules are expressing our circulation policy correctly. This will also let us see how our material types and locations have mapped from the migrated Sierra item records. These rules will also intersect with work done by other pods and other staff and faculty outside the FOLIO groups so further consultation and refinement will no doubt be needed.
Recommend using example policies for overdue fine, lost item, and requests for the first pass so that we can focus on whether the structure of our circulation rules works. These can be found in the Juniper demo, or modeled on rules used by early adopters.
Essential tasks for first pass

[ ] #40
[x] Set patron groups
[ ] #38
[ ] Write fallback policy
[ ] Write loan policies
[ ] Choose priority for loan rules
[ ] Add example overdue fine policy
[ ] Add example lost item policy
[ ] Add example

Nice-to-have completed for first pass

[ ] Set "other settings" (allowable patron ids for scanning, etc.)
[ ] Write actual overdue fine policy
[ ] Write actual lost item fee policy

Future to-do items

[ ] Determine loan history settings
[ ] Set patron notice policies and write patron notice templates

[ ] Need to test print templates with thermal printing

[ ] Create request policies

[ ] (need to answer questions related to #59 )

[ ] Write request cancellation reasons

Added Discovery Pod because loan rules will determine hold functionality in EDS

Added Resource Sharing. Borrowed ILLs will need to have variable due date functionality because that is determined by the lending library. Lent ILLs will be more straightforward, usually a 16-week lend period. And then there is Prospector, which is a black hole in all of this.

authors: jwfuller katallm libraryfemme

repo: culibraries/folio


text:
cupy.scipy.sparse.csrmatrix gives unhelpful error message when np.ndarray is passed

Problem description
cupyx.scipy.sparse.csr_matrix((
    np.ones([4], np.int32),
    np.array([1, 2, 3, 4], np.int32),
    np.array([0, 2, 3])
))

gives following error.
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-18-ab346d4e12f0> in <module>()
      7     np.ones([4], np.int32),
      8     np.array([1, 2, 3, 4], np.int32),
----> 9     np.array([0, 2, 3])
     10 ))

/usr/local/lib/python3.6/dist-packages/cupyx/scipy/sparse/compressed.py in __init__(self, arg1, shape, dtype, copy)
     81                     base.isdense(indptr) and indptr.ndim == 1):
     82                 raise ValueError(
---> 83                     'data, indices, and indptr should be 1-D')
     84
     85             if len(data) != len(indices):

Input tensors are indeed 1-D. The problem is that trigger for this ValueError is:
            if not (base.isdense(data) and data.ndim == 1 and
                    base.isdense(indices) and indices.ndim == 1 and
                    base.isdense(indptr) and indptr.ndim == 1):
                raise ValueError(
                    'data, indices, and indptr should be 1-D')

https://github.com/cupy/cupy/blob/v5/cupyx/scipy/sparse/compressed.py#L79-L83
where,
def isdense(x):
    return isinstance(x, cupy.ndarray)

https://github.com/cupy/cupy/blob/v5/cupyx/scipy/sparse/sputils.py#L4-L5
Environment to reproduce
CuPy Version          : 5.0.0
CUDA Root             : /usr/local/cuda
CUDA Build Version    : 9020
CUDA Driver Version   : 9020
CUDA Runtime Version  : 9020
cuDNN Build Version   : 7201
cuDNN Version         : 7201
NCCL Build Version    : 2213

Suggestion
It should test input matrices first if they are cupy array or not, then check for sparse matrices or not.
It should give separate error messages for different reasons of failures.

Suggestion: Add the following code to cupyx/scipy/sparse/_compressed.py into the _compressed_sparse_matrix.__init__() function, from line 247:
            if not (isinstance(data,cupy.ndarray)):
                raise ValueError(f'We are terribly sorry to inform you, that "data" is not a cupy.ndarray but has type {type(data)}.')
            if not (isinstance(indices,cupy.ndarray)):
                raise ValueError(f'We are terribly sorry to inform you, that "indices" is not a cupy.ndarray but has type {type(indices)}.')
            if not (isinstance(indptr,cupy.ndarray)):
                raise ValueError(f'We are terribly sorry to inform you, that "indptr" is not a cupy.ndarray but has type {type(indptr)}.')

            if not (_base.isdense(data) and data.ndim == 1 and
                    _base.isdense(indices) and indices.ndim == 1 and
                    _base.isdense(indptr) and indptr.ndim == 1):

                raise ValueError(
                    'data, indices, and indptr should be 1-D. Check that all arrays are cupy arrays and not numpy!')

            if len(data) != len(indices):
                raise ValueError(f'indices and data should have the same size but they have sizes {len(data)} and {len(indices)}. The order of the input arguments is : data, indices, indptr ')

source: gharchive/issue

repo: cupy/cupy

license: MIT

license_type: permissive

license_source: github-api


text:
cupyx.scipy.signal.resample_poly fails for large upsampling factors when applied on 2D arrays

Description
For 2D input arrays, cupyx.scipy.signal.resample_poly works for small upsampling rates (see Example 1), but fails for large upsampling rates( see Example 2). The error message(copied below Example 2) is not very informative. Is this a VRAM limitation issue?
Note that cupyx.scipy.signal.resample works for both cases.
To Reproduce
# Example 1 (works)
import cupy as cp
from cupyx.scipy.signal import resample, resample_poly

x = cp.linspace(0, 10, 32, endpoint=False)
z = cp.cos(-x**2/6.0) + 1j*cp.sin(-x**2/6.0)
y = cp.zeros([8, 32], dtype=cp.complex64)
y[:,...] = z
print(f"y.shape = {y.shape}")

f_fft = resample(y, 96, axis=1)
f_poly = resample_poly(y, 3, 1, axis=1)
xnew = cp.linspace(0, 10, 96, endpoint=False)

plt.plot(cp.asnumpy(xnew), cp.asnumpy(cp.squeeze(f_fft[0,:])), 'b.-', cp.asnumpy(xnew), cp.asnumpy(cp.squeeze(f_poly[0,:])), 'r.-')
plt.plot(cp.asnumpy(x), cp.asnumpy(cp.squeeze(y[0,:])), 'ko-')
plt.plot(10, cp.asnumpy(y[0,0]), 'bo', 10, 0., 'ro')  # boundaries
plt.legend(['resample', 'resamp_poly', 'data'], loc='best')
plt.grid(True)
plt.show()

plt.plot(cp.asnumpy(xnew), cp.asnumpy(cp.squeeze(f_fft[1,:])), 'b.-', cp.asnumpy(xnew), cp.asnumpy(cp.squeeze(f_poly[1,:])), 'r.-')
plt.plot(cp.asnumpy(x), cp.asnumpy(cp.squeeze(y[1,:])), 'ko-')
plt.plot(10, cp.asnumpy(y[1,0]), 'bo', 10, 0., 'ro')  # boundaries
plt.legend(['resample', 'resamp_poly', 'data'], loc='best')
plt.grid(True)
plt.show()

# Example 2 (does not work)
import cupy as cp
from cupyx.scipy.signal import resample, resample_poly

x = cp.linspace(0, 10, 32, endpoint=False)
A = cp.zeros([8, 32], dtype=cp.complex64)

A[:,...] = cp.cos(-x**2/6.0) + 1j*cp.sin(-x**2/6.0)

print(f"A.shape = {A.shape}")

inp_samples = A.shape[-1]
osf = 960  # oversampling factor
req_samples = inp_samples * osf
f_fft = resample(A, req_samples, axis=1)
f_poly = resample_poly(A, osf, 1, axis=1)

print(f"f_fft.shape = {f_fft.shape}")
print(f"f_poly.shape = {f_poly.shape}")

xnew = cp.linspace(0, 10, req_samples, endpoint=False)

plt.plot(cp.asnumpy(xnew), cp.asnumpy(cp.squeeze(f_fft.real)), 'b.-', cp.asnumpy(xnew), cp.asnumpy(cp.squeeze(f_poly.real)), 'r.-')
plt.plot(cp.asnumpy(x), cp.asnumpy(cp.squeeze(A.real)), 'ko-')
plt.plot(10, cp.asnumpy(z[0].real), 'bo', 10, 0., 'ro')  # boundaries
plt.legend(['resample', 'resamp_poly', 'data'], loc='best')
plt.title('Real')
plt.grid(True)
plt.show()

plt.plot(cp.asnumpy(xnew), cp.asnumpy(cp.squeeze(f_fft.imag)), 'b.-', cp.asnumpy(xnew), cp.asnumpy(cp.squeeze(f_poly.imag)), 'r.-')
plt.plot(cp.asnumpy(x), cp.asnumpy(cp.squeeze(A.imag)), 'ko-')
plt.plot(10, cp.asnumpy(A[0].imag), 'bo', 10, 0., 'ro')  # boundaries
plt.legend(['resample', 'resamp_poly', 'data'], loc='best')
plt.title('Imag')
plt.grid(True)
plt.show()

> ---------------------------------------------------------------------------
> CUDADriverError                           Traceback (most recent call last)
> Cell In[16], [line 12](vscode-notebook-cell:?execution_count=16&line=12)
>      [10](vscode-notebook-cell:?execution_count=16&line=10) req_samples = inp_samples * osf
>      [11](vscode-notebook-cell:?execution_count=16&line=11) f_fft = resample(A, req_samples, axis=1)
> ---> [12](vscode-notebook-cell:?execution_count=16&line=12) f_poly = resample_poly(A, osf, 1, axis=1)
>      [14](vscode-notebook-cell:?execution_count=16&line=14) print(f"f_fft.shape = {f_fft.shape}")
>      [15](vscode-notebook-cell:?execution_count=16&line=15) print(f"f_poly.shape = {f_poly.shape}")
>
> File /usr/local/lib/python3.10/dist-packages/cupyx/scipy/signal/_resample.py:552, in resample_poly(x, up, down, axis, window, padtype, cval)
>     [549](https://vscode-remote+attached-002dcontainer-002b7b22636f6e7461696e65724e616d65223a222f6369323330332d6e706572696173616d792d636c65616e2d4a7046513435764f5a3362746b6f4b73222c2273657474696e6773223a7b22686f7374223a227373683a2f2f6e706572696173616d794062666c6f7073227d7d.vscode-resource.vscode-cdn.net/usr/local/lib/python3.10/dist-packages/cupyx/scipy/signal/_resample.py:549) n_pre_remove_end = n_pre_remove + n_out
>     [551](https://vscode-remote+attached-002dcontainer-002b7b22636f6e7461696e65724e616d65223a222f6369323330332d6e706572696173616d792d636c65616e2d4a7046513435764f5a3362746b6f4b73222c2273657474696e6773223a7b22686f7374223a227373683a2f2f6e706572696173616d794062666c6f7073227d7d.vscode-resource.vscode-cdn.net/usr/local/lib/python3.10/dist-packages/cupyx/scipy/signal/_resample.py:551) # filter then remove excess
> --> [552](https://vscode-remote+attached-002dcontainer-002b7b22636f6e7461696e65724e616d65223a222f6369323330332d6e706572696173616d792d636c65616e2d4a7046513435764f5a3362746b6f4b73222c2273657474696e6773223a7b22686f7374223a227373683a2f2f6e706572696173616d794062666c6f7073227d7d.vscode-resource.vscode-cdn.net/usr/local/lib/python3.10/dist-packages/cupyx/scipy/signal/_resample.py:552) y = upfirdn(h, x, up, down, axis)
>     [553](https://vscode-remote+attached-002dcontainer-002b7b22636f6e7461696e65724e616d65223a222f6369323330332d6e706572696173616d792d636c65616e2d4a7046513435764f5a3362746b6f4b73222c2273657474696e6773223a7b22686f7374223a227373683a2f2f6e706572696173616d794062666c6f7073227d7d.vscode-resource.vscode-cdn.net/usr/local/lib/python3.10/dist-packages/cupyx/scipy/signal/_resample.py:553) keep = [slice(None)] * x.ndim
>     [554](https://vscode-remote+attached-002dcontainer-002b7b22636f6e7461696e65724e616d65223a222f6369323330332d6e706572696173616d792d636c65616e2d4a7046513435764f5a3362746b6f4b73222c2273657474696e6773223a7b22686f7374223a227373683a2f2f6e706572696173616d794062666c6f7073227d7d.vscode-resource.vscode-cdn.net/usr/local/lib/python3.10/dist-packages/cupyx/scipy/signal/_resample.py:554) keep[axis] = slice(n_pre_remove, n_pre_remove_end)
>
> File /usr/local/lib/python3.10/dist-packages/cupyx/scipy/signal/_upfirdn.py:500, in upfirdn(h, x, up, down, axis, mode, cval)
>     [498](https://vscode-remote+attached-002dcontainer-002b7b22636f6e7461696e65724e616d65223a222f6369323330332d6e706572696173616d792d636c65616e2d4a7046513435764f5a3362746b6f4b73222c2273657474696e6773223a7b22686f7374223a227373683a2f2f6e706572696173616d794062666c6f7073227d7d.vscode-resource.vscode-cdn.net/usr/local/lib/python3.10/dist-packages/cupyx/scipy/signal/_upfirdn.py:498) ufd = _UpFIRDn(h, x.dtype, int(up), int(down))
>     [499](https://vscode-remote+attached-002dcontainer-002b7b22636f6e7461696e65724e616d65223a222f6369323330332d6e706572696173616d792d636c65616e2d4a7046513435764f5a3362746b6f4b73222c2273657474696e6773223a7b22686f7374223a227373683a2f2f6e706572696173616d794062666c6f7073227d7d.vscode-resource.vscode-cdn.net/usr/local/lib/python3.10/dist-packages/cupyx/scipy/signal/_upfirdn.py:499) # This is equivalent to (but faster than) using cp.apply_along_axis
> --> [500](https://vscode-remote+attached-002dcontainer-002b7b22636f6e7461696e65724e616d65223a222f6369323330332d6e706572696173616d792d636c65616e2d4a7046513435764f5a3362746b6f4b73222c2273657474696e6773223a7b22686f7374223a227373683a2f2f6e706572696173616d794062666c6f7073227d7d.vscode-resource.vscode-cdn.net/usr/local/lib/python3.10/dist-packages/cupyx/scipy/signal/_upfirdn.py:500) return ufd.apply_filter(x, axis)
>
> File /usr/local/lib/python3.10/dist-packages/cupyx/scipy/signal/_upfirdn.py:417, in _UpFIRDn.apply_filter(self, x, axis)
>     [414](https://vscode-remote+attached-002dcontainer-002b7b22636f6e7461696e65724e616d65223a222f6369323330332d6e706572696173616d792d636c65616e2d4a7046513435764f5a3362746b6f4b73222c2273657474696e6773223a7b22686f7374223a227373683a2f2f6e706572696173616d794062666c6f7073227d7d.vscode-resource.vscode-cdn.net/usr/local/lib/python3.10/dist-packages/cupyx/scipy/signal/_upfirdn.py:414)     # do computations
>     [415](https://vscode-remote+attached-002dcontainer-002b7b22636f6e7461696e65724e616d65223a222f6369323330332d6e706572696173616d792d636c65616e2d4a7046513435764f5a3362746b6f4b73222c2273657474696e6773223a7b22686f7374223a227373683a2f2f6e706572696173616d794062666c6f7073227d7d.vscode-resource.vscode-cdn.net/usr/local/lib/python3.10/dist-packages/cupyx/scipy/signal/_upfirdn.py:415)     kernel = UPFIRDN_MODULE.get_function(
>     [416](https://vscode-remote+attached-002dcontainer-002b7b22636f6e7461696e65724e616d65223a222f6369323330332d6e706572696173616d792d636c65616e2d4a7046513435764f5a3362746b6f4b73222c2273657474696e6773223a7b22686f7374223a227373683a2f2f6e706572696173616d794062666c6f7073227d7d.vscode-resource.vscode-cdn.net/usr/local/lib/python3.10/dist-packages/cupyx/scipy/signal/_upfirdn.py:416)         f'_cupy_upfirdn2D_{out.dtype.name}')
> --> [417](https://vscode-remote+attached-002dcontainer-002b7b22636f6e7461696e65724e616d65223a222f6369323330332d6e706572696173616d792d636c65616e2d4a7046513435764f5a3362746b6f4b73222c2273657474696e6773223a7b22686f7374223a227373683a2f2f6e706572696173616d794062666c6f7073227d7d.vscode-resource.vscode-cdn.net/usr/local/lib/python3.10/dist-packages/cupyx/scipy/signal/_upfirdn.py:417)     kernel(threadsperblock, blockspergrid,
>     [418](https://vscode-remote+attached-002dcontainer-002b7b22636f6e7461696e65724e616d65223a222f6369323330332d6e706572696173616d792d636c65616e2d4a7046513435764f5a3362746b6f4b73222c2273657474696e6773223a7b22686f7374223a227373683a2f2f6e706572696173616d794062666c6f7073227d7d.vscode-resource.vscode-cdn.net/usr/local/lib/python3.10/dist-packages/cupyx/scipy/signal/_upfirdn.py:418)            (x,
>     [419](https://vscode-remote+attached-002dcontainer-002b7b22636f6e7461696e65724e616d65223a222f6369323330332d6e706572696173616d792d636c65616e2d4a7046513435764f5a3362746b6f4b73222c2273657474696e6773223a7b22686f7374223a227373683a2f2f6e706572696173616d794062666c6f7073227d7d.vscode-resource.vscode-cdn.net/usr/local/lib/python3.10/dist-packages/cupyx/scipy/signal/_upfirdn.py:419)             x.shape[1],
>     [420](https://vscode-remote+attached-002dcontainer-002b7b22636f6e7461696e65724e616d65223a222f6369323330332d6e706572696173616d792d636c65616e2d4a7046513435764f5a3362746b6f4b73222c2273657474696e6773223a7b22686f7374223a227373683a2f2f6e706572696173616d794062666c6f7073227d7d.vscode-resource.vscode-cdn.net/usr/local/lib/python3.10/dist-packages/cupyx/scipy/signal/_upfirdn.py:420)             self._h_trans_flip,
>     [421](https://vscode-remote+attached-002dcontainer-002b7b22636f6e7461696e65724e616d65223a222f6369323330332d6e706572696173616d792d636c65616e2d4a7046513435764f5a3362746b6f4b73222c2273657474696e6773223a7b22686f7374223a227373683a2f2f6e706572696173616d794062666c6f7073227d7d.vscode-resource.vscode-cdn.net/usr/local/lib/python3.10/dist-packages/cupyx/scipy/signal/_upfirdn.py:421)             self._up,
>     [422](https://vscode-remote+attached-002dcontainer-002b7b22636f6e7461696e65724e616d65223a222f6369323330332d6e706572696173616d792d636c65616e2d4a7046513435764f5a3362746b6f4b73222c2273657474696e6773223a7b22686f7374223a227373683a2f2f6e706572696173616d794062666c6f7073227d7d.vscode-resource.vscode-cdn.net/usr/local/lib/python3.10/dist-packages/cupyx/scipy/signal/_upfirdn.py:422)             self._down,
>     [423](https://vscode-remote+attached-002dcontainer-002b7b22636f6e7461696e65724e616d65223a222f6369323330332d6e706572696173616d792d636c65616e2d4a7046513435764f5a3362746b6f4b73222c2273657474696e6773223a7b22686f7374223a227373683a2f2f6e706572696173616d794062666c6f7073227d7d.vscode-resource.vscode-cdn.net/usr/local/lib/python3.10/dist-packages/cupyx/scipy/signal/_upfirdn.py:423)             axis,
>     [424](https://vscode-remote+attached-002dcontainer-002b7b22636f6e7461696e65724e616d65223a222f6369323330332d6e706572696173616d792d636c65616e2d4a7046513435764f5a3362746b6f4b73222c2273657474696e6773223a7b22686f7374223a227373683a2f2f6e706572696173616d794062666c6f7073227d7d.vscode-resource.vscode-cdn.net/usr/local/lib/python3.10/dist-packages/cupyx/scipy/signal/_upfirdn.py:424)             x_shape_a,
>     [425](https://vscode-remote+attached-002dcontainer-002b7b22636f6e7461696e65724e616d65223a222f6369323330332d6e706572696173616d792d636c65616e2d4a7046513435764f5a3362746b6f4b73222c2273657474696e6773223a7b22686f7374223a227373683a2f2f6e706572696173616d794062666c6f7073227d7d.vscode-resource.vscode-cdn.net/usr/local/lib/python3.10/dist-packages/cupyx/scipy/signal/_upfirdn.py:425)             h_per_phase,
>     [426](https://vscode-remote+attached-002dcontainer-002b7b22636f6e7461696e65724e616d65223a222f6369323330332d6e706572696173616d792d636c65616e2d4a7046513435764f5a3362746b6f4b73222c2273657474696e6773223a7b22686f7374223a227373683a2f2f6e706572696173616d794062666c6f7073227d7d.vscode-resource.vscode-cdn.net/usr/local/lib/python3.10/dist-packages/cupyx/scipy/signal/_upfirdn.py:426)             padded_len,
>     [427](https://vscode-remote+attached-002dcontainer-002b7b22636f6e7461696e65724e616d65223a222f6369323330332d6e706572696173616d792d636c65616e2d4a7046513435764f5a3362746b6f4b73222c2273657474696e6773223a7b22686f7374223a227373683a2f2f6e706572696173616d794062666c6f7073227d7d.vscode-resource.vscode-cdn.net/usr/local/lib/python3.10/dist-packages/cupyx/scipy/signal/_upfirdn.py:427)             out,
>     [428](https://vscode-remote+attached-002dcontainer-002b7b22636f6e7461696e65724e616d65223a222f6369323330332d6e706572696173616d792d636c65616e2d4a7046513435764f5a3362746b6f4b73222c2273657474696e6773223a7b22686f7374223a227373683a2f2f6e706572696173616d794062666c6f7073227d7d.vscode-resource.vscode-cdn.net/usr/local/lib/python3.10/dist-packages/cupyx/scipy/signal/_upfirdn.py:428)             out.shape[0],
>     [429](https://vscode-remote+attached-002dcontainer-002b7b22636f6e7461696e65724e616d65223a222f6369323330332d6e706572696173616d792d636c65616e2d4a7046513435764f5a3362746b6f4b73222c2273657474696e6773223a7b22686f7374223a227373683a2f2f6e706572696173616d794062666c6f7073227d7d.vscode-resource.vscode-cdn.net/usr/local/lib/python3.10/dist-packages/cupyx/scipy/signal/_upfirdn.py:429)             out.shape[1]
>     [430](https://vscode-remote+attached-002dcontainer-002b7b22636f6e7461696e65724e616d65223a222f6369323330332d6e706572696173616d792d636c65616e2d4a7046513435764f5a3362746b6f4b73222c2273657474696e6773223a7b22686f7374223a227373683a2f2f6e706572696173616d794062666c6f7073227d7d.vscode-resource.vscode-cdn.net/usr/local/lib/python3.10/dist-packages/cupyx/scipy/signal/_upfirdn.py:430)             )
>     [431](https://vscode-remote+attached-002dcontainer-002b7b22636f6e7461696e65724e616d65223a222f6369323330332d6e706572696173616d792d636c65616e2d4a7046513435764f5a3362746b6f4b73222c2273657474696e6773223a7b22686f7374223a227373683a2f2f6e706572696173616d794062666c6f7073227d7d.vscode-resource.vscode-cdn.net/usr/local/lib/python3.10/dist-packages/cupyx/scipy/signal/_upfirdn.py:431)            )
>     [432](https://vscode-remote+attached-002dcontainer-002b7b22636f6e7461696e65724e616d65223a222f6369323330332d6e706572696173616d792d636c65616e2d4a7046513435764f5a3362746b6f4b73222c2273657474696e6773223a7b22686f7374223a227373683a2f2f6e706572696173616d794062666c6f7073227d7d.vscode-resource.vscode-cdn.net/usr/local/lib/python3.10/dist-packages/cupyx/scipy/signal/_upfirdn.py:432) else:
>     [433](https://vscode-remote+attached-002dcontainer-002b7b22636f6e7461696e65724e616d65223a222f6369323330332d6e706572696173616d792d636c65616e2d4a7046513435764f5a3362746b6f4b73222c2273657474696e6773223a7b22686f7374223a227373683a2f2f6e706572696173616d794062666c6f7073227d7d.vscode-resource.vscode-cdn.net/usr/local/lib/python3.10/dist-packages/cupyx/scipy/signal/_upfirdn.py:433)     raise NotImplementedError("upfirdn() requires ndim <= 2")

Installation
Wheel (pip install cupy-***)
Environment
OS                           : Linux-5.15.0-124-generic-x86_64-with-glibc2.35
Python Version               : 3.10.12
CuPy Version                 : 13.2.0
CuPy Platform                : NVIDIA CUDA
NumPy Version                : 1.24.3
SciPy Version                : 1.14.0
Cython Build Version         : 0.29.36
Cython Runtime Version       : 3.0.11
CUDA Root                    : /usr/local/cuda
nvcc PATH                    : /usr/local/cuda/bin/nvcc
CUDA Build Version           : 11080
CUDA Driver Version          : 12020
CUDA Runtime Version         : 11080 (linked to CuPy) / 11080 (locally installed)
cuBLAS Version               : (available)
cuFFT Version                : 10900
cuRAND Version               : 10300
cuSOLVER Version             : (11, 4, 1)
cuSPARSE Version             : (available)
NVRTC Version                : (11, 8)
Thrust Version               : 200200
CUB Build Version            : 200200
Jitify Build Version         : <unknown>
cuDNN Build Version          : 8801
cuDNN Version                : 8906
NCCL Build Version           : 21602
NCCL Runtime Version         : 21505
cuTENSOR Version             : None
cuSPARSELt Build Version     : None
Device 0 Name                : NVIDIA GeForce RTX 3090
Device 0 Compute Capability  : 86
Device 0 PCI Bus ID          : 0000:C1:00.0

Thanks for the report @naperman, this reproduced on my end as well.

@kmaehashi and @naperman Let me know if I can work on this issue

@dundermain I'd say please do, but I think @kmaehashi seems to be the only one in this thread who can authorize merge requests.

I'd also add the being able to use resample_poly on arrays of any dimension would be very useful. Currently, it supports only 2 dimensional arrays whereas resample support any dimension.

Here is the error I get when running Example 2 code:
>>> f_poly = resample_poly(A, osf, 1, axis=1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/maehashi/Development/cupy/cupyx/scipy/signal/_resample.py", line 552, in resample_poly
    y = upfirdn(h, x, up, down, axis)
  File "/home/maehashi/Development/cupy/cupyx/scipy/signal/_upfirdn.py", line 502, in upfirdn
    return ufd.apply_filter(x, axis)
  File "/home/maehashi/Development/cupy/cupyx/scipy/signal/_upfirdn.py", line 417, in apply_filter
    kernel(threadsperblock, blockspergrid,
  File "cupy/_core/raw.pyx", line 93, in cupy._core.raw.RawKernel.__call__
  File "cupy/cuda/function.pyx", line 223, in cupy.cuda.function.Function.__call__
  File "cupy/cuda/function.pyx", line 205, in cupy.cuda.function._launch
  File "cupy_backends/cuda/api/driver.pyx", line 273, in cupy_backends.cuda.api.driver.launchKernel
  File "cupy_backends/cuda/api/driver.pyx", line 63, in cupy_backends.cuda.api.driver.check_status
cupy_backends.cuda.api.driver.CUDADriverError: CUDA_ERROR_INVALID_VALUE: invalid argument

authors: dundermain kmaehashi naperman


text:
[backport] Fallback to synchronous transfer if pinned memory could not be allocated

Backport of #1593

[automatic post] Jenkins, test this please.

Jenkins CI test (for commit e06dd997ea01d1d7e1fb16bac0df608205aaed93, target branch v4) failed with status FAILURE.
(For contributors, please wait until the reviewer confirms the details of the error.)

LGTM!

source: gharchive/pull-request

authors: chainer-ci kmaehashi okuta


text:
[RFC] Disallow testing.numpy_cupy_raises without explicit error type

Fixes #2871

This inevitably breaks backward compatibility.
I want to make accept_error a positional required argument and others keyword-only.

Blocked by https://github.com/cupy/cupy/pull/2987

authors: kmaehashi niboshi


text:
[backport] Use custom index for pre-release wheels

Backport of #5772 by @kmaehashi

[automatic post] Jenkins, test this please.

Jenkins CI test (for commit 5c68b0424f6ad2e36d56c8d5ff2b87ef4807ccf7, target branch v9) succeeded!


text:
add test for argmin/argmax tie

This adds test case for xhttps://github.com/chainer/chainer/issues/1099.

LGTM!


text:
Fix reversal of labels for live link and features

Minor oversight in my PR #5 , resolving this in advance of larger refactor effort.

BEFORE:

AFTER:

repo: curatingbits/artblocksiobot


text:
Integration installation fails in Home Assistant 2023.6

IMPORTANT: Please search the issues, including closed issues, and the FAQ before opening a new issue. The template is mandatory; failure to use it will result in issue closure.
Describe the bug
After downloading the Alexa Media Player repository in HACS, restarting and clicking on the add integration button, an error pops up: "Config flow could not be loaded: {"message":"Invalid handler specified"}". Looking at the logs, the integration appears to fail to install due to this error: "ImportError: cannot import name 'formatargspec' from 'inspect'".
To Reproduce

After adding the Alexa Media Player repository in HACS and restarting, go to 'Settings' -> 'Devices and Services'
Click on 'Add Integration' and choose 'Alexa Media Player'
See error.

Expected behavior
Integration would get installed.
Screenshots
N/A
System details

Home-assistant (version): 2023.6
alexa_media (version from const.py or HA startup): 4.6.4
alexapy (version from pip show alexapy or HA startup): 1.26.8
Amazon 2FA is enabled (y/n). <!---We will not debug login issues if unanswered--->: y

Logs
Please provide logs.
2023-06-18 21:06:37.852 ERROR (MainThread) [homeassistant.config_entries] Error occurred loading flow for integration alexa_media: cannot import name 'formatargspec' from 'inspect' (/usr/local/lib/python3.11/inspect.py)
Additional context
Home Assistant 2023.6 appears to have upgraded Python to 3.11. Could it be related?

I'm experiencing the same issue, with the following error in the Home Assistant Core log...
State attributes for sensor.bedroom_dot_next_alarm exceed maximum size of 16384 bytes. This can cause database performance issues; Attributes will not be stored

My next_ alarm also doesn't work. Any workaround?

Hello. Same issue on my side. HACS was installed from scratch. When trying to install the Alexa integration I'll get the following logs:
Logger: homeassistant.config_entries
Source: config_entries.py:863
First occurred: 16:35:01 (1 occurrences)
Last logged: 16:35:01
Error occurred loading flow for integration alexa_media: cannot import name 'formatargspec' from 'inspect' (/usr/local/lib/python3.11/inspect.py)

Hello, same issue on my side after updating the HA:
Home Assistant 2023.6.3
Supervisor 2023.06.4
Operating System 10.3
Interface: 20230608.0 - latest
Log:
Logger: homeassistant.config_entries
Source: config_entries.py:863
First occurred: 16:07:21 (4 occurrences)
Last logged: 16:07:40
Error occurred loading flow for integration alexa_media: cannot import name 'formatargspec' from 'inspect' (/usr/local/lib/python3.11/inspect.py)

Updated wrapt to the latest version and it fixed it for me.

Similar issue not allowing installation because of alexapy 1.26.8, just modified that to 1.25.5 on
custom_components/alexa_media/manifest.json
Restarted HA and then installation went fine. Source:
https://github.com/custom-components/alexa_media_player/issues/1579

Tried the modification of manifest.json and didn't work.

Tried the modification of manifest.json and didn't work.

On this line:
"requirements": ["alexapy==1.25.5", "packaging>=20.3", "wrapt>=1.12.1"],

just recently updated the everything from a very old version. its probably been about 2-3 years old.  everything went fine except alexa media player.   having similar issue,  changed to 1.25.5. saved then rebooted but still does not work.

same here..

Yesterday I did the update of HA and I could reinstall it and now works good.
Supervisor 2023.08.1
Operating System 10.4

still same issue...I think is something with my host OS or docker version..I bring my HA from an old 2021 version to this one, after a traumatic upgrade this damn integration is the only one missing!...I don't want to star over just because of this one...
core-2023.8.1
Frontend 20230802.0 - latest
Host Operating System	Ubuntu 20.04.6 LTS
supervisor-2023.08.1
Docker Version 24.04
I can't remove the integration can someone explain me how?...even removing the folder inside custom_components and the integration still show up...anyway I manually delete the folder, reboot, reinstall the integration and the issue still persist, same message:  cannot import name 'formatargspec' from 'inspect' (/usr/local/lib/python3.11/inspect.py)
Any ideas what else to check or what other folder/file/thing can I try to delete to "refresh" HA and allow this thing to install?
Thanks!!

...in my case the fix was really weird, I leave it here in case someone else want to try it...
I think it was do to some requirement on the dock container that was not updated during the HA update..so the real problem was
It seems that the "formatargspec" thing that need to be in inspect.py is not..or something like that...after finding a simillar issue but with other project I found that it was somehow related to the "wrapt" library....I connect to the dock container and did an update:
pip install --upgrade wrapt
After that the integration aske me to re-configure the integration and they start working again...
P.S: to connect to the docker container:
docker exec -it $(docker ps -f name=homeassistant -q) bash

authors: JoseFerre Leakopf1 StuckInLoop jdserras jojo01fr mhenriquezschott naumz popy2k14 tonygentry


text:
Add support cocur/slugify version ^4.0

Please add support cocur/slugify in composer.json

Done.  Version 6.0.3 should have this now.

authors: StApostol cviebrock

repo: cviebrock/eloquent-sluggable

license: mit

license_source: bigquery


text:
ImportError: /lib64/libc.so.6: version `GLIBC_2.14' not found

Hello, I am trying to install cvxpy module on a linux-based OS (CentOS).  I followed the steps from the website https://www.cvxpy.org/install/index.html and it appeared to be correctly installed. However, when I open python and try to import the cvxpy module I get the following error message:

Surfing on internet I found some suggestions on how to fix it, mainly installing "conda install libgcc" but this didnt work.  I am working with Python 2.7 installed using miniconda.

It seems cannot find the correct version of libgcc. Add the miniconda lib path to LD_LIBRARY_PATH might fix this.
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$HOME/miniconda2/lib

As part of a general issue purge, I'm closing this until/if it comes up again. The installation process has changed so much it may have gone away.

authors: SteveDiamond alvaromc317 wiehern

repo: cvxgrp/cvxpy


text:
Adding support for critical hit highlighting

While I'm up to date on this repo... I noticed the "Crits On" field isn't used as anything other than a visible reference field on the sheet, which is a shame since Roll20 supports adjusting the range of values which trigger the critical green-border highlighting. This should handle that.
I've tested the expression I used here in my personal macros, though it'd be best to test the full sheet first. For reference, this is the sed script I used to add the critical success list:
sed -e "s/AR=..1d20+@{Acc}..}} {{AC=@{Move(.)/AR={{1d20cs>@{Move\1_critsOn}}} {{AC=@{Move\1/" ptu.html -i
I think it's best to drop the Crits On field from the roll template if it's being evaluated here. I separated that commit out though, so if you've a reason to keep it (possibly a technical one) that should be easy.

Very nice Marth. We might want to add some kind of note next to the dice roll so people know the crit range is being accounted for, just something like "(Crit when Green)" or some such, but still very nice.

True, plus I'm not sure how well Roll20 supports colourblind changing; I think the mouseover bolds the die result. I'd prefer to keep the template as small as possible, but there's still a couple of reasons to keep the explicit note of critical range. Oh well, that's why I separated that change out.

Mmhm. Oh, and if you'd like to test changes, I put your (sans crit section) version into this campaign.

The new replacement script, no longer squashing the Acc attribute and properly catching Struggle and misc moves:
s/AR=..1d20+@{Acc}..}} {{AC=@{([[:alnum:]]*)/AR=[[1d20cs>@{\1_critsOn}+@{Acc}]]}} {{AC=@{\1/

authors: KingMarth cwstra


text:
about 'otter.m'

Hi there，professor Fossen, I found that the motion equation of otter was  using the function of follows:

so i got 2 questions about it , because i wanna use it to simulate and finish my paper.
The FIRST is, in your book , it says:

therefore, could i say that, the model you use in the otter.m can only be used in motion of line motion? what if the USV follows a curve? Can i use it to follow the Polyline path？Or i have to use the following equation in your book :

and reconstruct the model?
The SECOND is , i didn't know much about the crossflow drag and strip theory:

but i had looked into some paper and found the strip theory is often used in the calculation of wave disturbance, so i wonder if the crossflow drag the same as wave disturbance? Also, i didn't know where the origin of the equations here:

though i know the Cd_2d coefficient is based on a curve of a paper.
Besides, i have some other questions about the model,  can you reply me the answer even though i know your time is limited and precious?
THIRD, you know the otter model is a 6DOF model, but usually we control the model of 3 degree, so it needs to simplify the model  and transform it into 3 DOF, but i wonder how to decouple the 6DOF model into 3DOF, the only way i could do is to delete the rows and columns of w\p\q ， i wonder if there is better way to do that?
FORTH,  about the hydrodynamic coefficients in this model.
i know all of the hydrodynamic coefficients you use have their experiments and statistics support, however, if i have to consider the variable mass of mp,which may change the draft , as a result , the  hydrodynamic coefficients as well as the draft may be variable all the time, so i wonder if these equations effective while the mass is changing?If it is not  effective, how can i consider the hydrodynamic coefficients of otter?

Thanks !

您好，已收到您的邮件，谢谢！

The otter.m model is a 6-DOF model, valid for all motions (not only straight lines). Your question regarding r = 0 is related to ocean currents. The model uses a horizontal ocean current with velocities uc and vc. There are no vertical currents wc. In addition, it is assumed that the time derivative of the ocean current velocity expressed in BODY is zero. This means that the S(omega) v_c term in

is assumed to be zero (only valid if r = 0 or small). You can remove this assumption by adding the S(w) v_c term in the model.  In practice, this term will be minimal. Note the Otter USV model is not affected by this. It is only the current model. However, I will add this term to the GitHub model since you are among many asking this question.

Wave disturbances are not related to the cross-flow drag formula. Strip theory means you slide the hull into pieces and use a 2-D formula for each piece. Then, you sum up along the x-axis (like an integral).  This is the reason you need the 2-D Hoerner formula for drag. The cross-flow drag formula is a nonlinear damping force in sway and yaw using the relative velocity (including the currents' contribution). It is not a wave force. The nonlinear damping terms are in addition to the linear damping terms.

You should not simplify your 6-DOF equations of motion. The model should be a high-fidelity 6-DOF model representation of the actual system. Instead, you should make a measurement model, selecting the states you need. You choose the measurements corresponding to surge, sway, and yaw. Then, you compute your control law for the same 3 DOFs. Finally, you define a 6-DOF vector for the control input and substitute your three controls into the vector's surge, sway, and yaw positions. The remaining three elements should be zero. Consequently, there is no need to decouple or reduce the model.

You have a new model if you change the load condition (mass, payload, etc.). Then, all mass parameters, CG, CB, and added mass terms change. You can interpolate or extrapolate the data; alternatively, do all computations from scratch for each load condition.

thanks a lot!

The otter.m has been updated on GitHub. It now includes the missing S(w) v_c term. The file ExOtter.m explains how to design a course autopilot using the 6-DOF model. No need for model reduction.

I see.
And I will see the updated codes immediately and update my simulation model as well.
Thanks for your kindness and patience.

authors: JasonWang2333 cybergalactic wtllll

repo: cybergalactic/MSS


text:
january as default start month

closes #92

This was fixed in one of my other PRs

ok, thanks

authors: FlanFlanagan gidden


text:
DBus

Please add DBus support so that it autostart on login
See https://github.com/davvid/lightdm/search?q=dbus&type=Code&utf8=✓ ?

Done, thanks for the suggestion bro ;) 6e7ceadf1158dd33de348b9ff89ae60126d622b2

dbus handling is removed, why? please reopen.
this might help: https://lists.freedesktop.org/archives/systemd-devel/2015-January/027711.html

nvm, environment stuff from systemd (interesting to look into nonetheless) is broken for the version i'm running. (one bad env var will freez systemd!). sorry for the noise.

authors: 257 cylgom oxodao

repo: cylgom/ly

license: WTFPL


text:
bug(main page): when previewing the "quick info" panel, the creators do not always center instantly.

browser
Edge
bug description
https://github.com/cyperdark/osuck-skins/assets/107962621/cd7e866e-6b16-40b2-a24c-af58c5b68cce

fixed

authors: GabuTheDev cyperdark

repo: cyperdark/osuck-skins


text:
Gitlab pipeline fails  with Cypress binary not installed

Gitlab pipeline fails  with Cypress binary not installed though i am using cypress/included:latest
Here is my job definition in my gitlab-ci.yml
# Install steps happens in different stage

Unit Test:
  image:  jfrog-mirai.ec.com/registry-1.docker.io/cypress/included:latest
  stage: Test
  script:
    - npm_config_registry=https://jfrog-mirai.ec.com/artifactory/api/npm/mirai-npm/ npx cypress install
    - npx cypress cache path
    - npx cypress cache list
    - npm run cypress:run:unit
  allow_failure: true
  cache:
    key: node_modules-$VERSION
    paths:
      - node_modules/
      - cache/Cypress
    policy: pull
  artifacts:
    when: always
    paths:
      - cypress/videos/**/*.mp4
      - cypress/screenshots/**/*.png
    expire_in: 1 day

output
Checking cache for node_modules-0.1.2-feature-cypress-non_protected...
Downloading cache.zip from https://st2ldm32humncy3rdva.blob.core.windows.net/gitlab-runner-shared-cache/runner/project/5144/node_modules-0.1.2-feature-cypress-non_protected
Successfully extracted cache
Executing "step_script" stage of the job script
00:03
$ npm_config_registry=https://jfrog-mirai.ec.com/artifactory/api/npm/mirai-npm/ npx cypress install
[STARTED] Task without title.
$ npx cypress cache path
/opt/.cache/Cypress
$ npx cypress cache list
┌─────────┬───────────┐
│ version │ last used │
└─────────┴───────────┘
$ npm run cypress:run:unit
> avt-app@0.0.0 cypress:run:unit
> cypress run --component
The cypress npm package is installed, but the Cypress binary is missing.
We expected the binary to be installed here: /opt/.cache/Cypress/13.12.0/Cypress/Cypress
Reasons it may be missing:
- You're caching 'node_modules' but are not caching this path: /root/.cache/Cypress
- You ran 'npm install' at an earlier build step but did not persist: /root/.cache/Cypress
Properly caching the binary will fix this error and avoid downloading and unzipping Cypress.
Alternatively, you can run 'cypress install' to download the binary again.
https://on.cypress.io/not-installed-ci-error
----------
Platform: linux-x64 (Debian - 12.6)
Cypress Version: 13.12.0
Uploading artifacts for failed job

@bharathmuppa
Your job definition shows you are using
image:  jfrog-mirai.ec.com/registry-1.docker.io/cypress/included:latest

jfrog-mirai.ec.com/registry-1.docker.io is not a registry controlled by Cypress.io
Use of the latest tag in production is not recommended.
In the Docker Hub registry on https://hub.docker.com/r/cypress/included the image reference cypress/included:latest is currently equivalent to cypress/included:13.13.1

Your log files indicate that your project is configured for Cypress Version: 13.12.0 which may be in conflict with the latest tag from your Docker registry.
You can try specifying
cypress/included:13.12.0 as your image
or you could try using a cypress/browsers image instead, for instance
cypress/browsers:node-20.14.0-chrome-126.0.6478.114-1-ff-127.0.1-edge-126.0.2592.61-1
There is no specific advice in this repository about using Cypress Docker images in GitLab. You can however find some documentation on the Cypress documentation site at https://docs.cypress.io/guides/continuous-integration/gitlab-ci.

This issue is not reproducible locally. Possibly the setting for the Cypress binary cache is being overridden. The Docker image uses /root/.cache/Cypress not /opt/.cache/Cypress:
git clone https://github.com/cypress-io/cypress-docker-images
cd cypress-docker-images/examples/basic
npm install cypress@13.12.0 -D
docker run -it --rm -v .:/e2e -w /e2e --entrypoint bash cypress/included:latest

root@46f8c91a41e8:/e2e# npx cypress install
root@46f8c91a41e8:/e2e# npx cypress cache path
/root/.cache/Cypress
root@46f8c91a41e8:/e2e# npx cypress cache list
┌─────────┬──────────────┐
│ version │ last used    │
├─────────┼──────────────┤
│ 13.12.0 │ a month ago  │
├─────────┼──────────────┤
│ 13.13.1 │ 14 hours ago │
└─────────┴──────────────┘

@bharathmuppa
Please let us know if the information was helpful to you and if you were able to resolve your issue by re-configuration.

Closing due to lack of response.

Thanks it worked @MikeMcC399
Problem is with the version as you explained, your help is much appreciated.

repo: cypress-io/cypress-docker-images


text:
Chrome is fingerprinted by incapsula but not firefox

After a few queries to this website https://www.carrefour.fr/evenements/mobilier-de-jardin, Chrome gets presented 2 re-captchas -> one by anti bot mitigation (Datadome) which even a regular browser gets and another re-captcha, presented this time by Incapsula.
However, Firefox gets only presented with the first re-captcha (Datadome)
I wonder if there is a property accessible in javascript which can flag the remote-debugging protocol.
Any idea where to look to avoid being flagged by a website ?

Component
Version

Operating system
Ubuntu

Node.js
v10.22.0

Chrome/Chromium/...
Firefox Nightly and Chrome

chrome-remote-interface
Last VERSION

Is Chrome running in a container?  NO

IIRC there was a way to tell that from JavaScript but I cannot remember exactly how...
Anyway I doubt they implement such an advanced check, I find it more likely that the rate of requests triggered that behaviour.
By the way I see no captcha when I'm navigating that page with Chrome, either inspected or not.

You can detect headless though, and headless basically means that Chrome is inspected. But the inverse is not true.
See this post about a Datadome guy.

@cyrus-and thanks for you answer.
I have tested both browsers, many times and with great scrutiny.
I can confirm that Firefox Nightly is the only one which does not trigger Imperva Incapsula, whereas Chrome, Opera will trigger a recaptcha test from Imperva Incapsula, meaning a javascript test is failing, after few requests (10 to 15 maximum) while Firefox Nightly will not trigger Imperva Incapsula, but only datadome check, after ~30-40 requests.
Standalone chrome is working without triggering the test.
I'll keep you posted if I find a way to check remote debugging from javascript.

@cyrus-and  I also confirm that I don't run the browser headless.

authors: cyrus-and lobstrio

repo: cyrus-and/chrome-remote-interface


text:
Empty "params" object

Some devtools targets don't accept messages without "params" property.
see: https://bugs.chromium.org/p/chromium/issues/detail?id=679350
This will be fixed in a future version but maybe it could be an idea to always send a "params" property with chrome-remote-interface anyway?

AFAIK there's no formal specification describing the format of the messages, that states whether the params can be omitted or not. But the fix for that issue says:

Some DevTools clients omit the "params" object for commands that don't take any parameters. Be less strict about requiring it to support these clients.

Suggesting that the strict behavior is to always include the params field in messages.
(/note to self)
So yes I think it's a good idea. Thanks for pointing this out!

authors: Janpot cyrus-and


text:
Error while trying to build helloworld example

>>> import sys, Cython, numpy; print(Cython.__version__, numpy.__version__, sys.version_info)
0.29.2 1.15.4 sys.version_info(major=3, minor=5, micro=0, releaselevel='final', serial=0)

Trying to recreate the helloworld example- I get a strange error
maded@uc4346b707fc2594ae9f1:~/dev/helloworld $ vim helloworld.pyx
maded@uc4346b707fc2594ae9f1:~/dev/helloworld $ vim setup.py
maded@uc4346b707fc2594ae9f1:~/dev/helloworld $ python setup.py build_ext --inplace
Traceback (most recent call last):
  File "setup.py", line 5, in <module>
    ext_modules = cythonize("helloworld.pyx")
  File "/home/local/ANT/maded/anaconda3/lib/python3.5/site-packages/Cython/Build/Dependencies.py", line 958, in cythonize
    ctx = c_options.create_context()
  File "/home/local/ANT/maded/anaconda3/lib/python3.5/site-packages/Cython/Compiler/Main.py", line 595, in create_context
    self.cplus, self.language_level, options=self)
  File "/home/local/ANT/maded/anaconda3/lib/python3.5/site-packages/Cython/Compiler/Main.py", line 78, in __init__
    from . import Builtin, CythonScope
  File "/home/local/ANT/maded/anaconda3/lib/python3.5/site-packages/Cython/Compiler/CythonScope.py", line 5, in <module>
    from .UtilityCode import CythonUtilityCode
  File "/home/local/ANT/maded/anaconda3/lib/python3.5/site-packages/Cython/Compiler/UtilityCode.py", line 3, in <module>
    from .TreeFragment import parse_from_strings, StringParseContext
  File "/home/local/ANT/maded/anaconda3/lib/python3.5/site-packages/Cython/Compiler/TreeFragment.py", line 21, in <module>
    from . import Parsing
  File "Cython/Compiler/Scanning.pxd", line 18, in init Cython.Compiler.Parsing
ValueError: Cython.Compiler.Scanning.CompileTimeScope has the wrong size, try recompiling. Expected 32, got 40

@rgommers Moving this from scipy https://github.com/scipy/scipy/issues/9744 to here

Cython was installed from pip

Pretty sure that you'll want to install Cython with conda if you use Python from conda. Can you try that?

Good catch - the pip was from the anaconda install too so I didnt expect this

authors: dmadeka rgommers

repo: cython/cython


text:
[ENH] Avoid shadow variables

We would like to use the -Wshadow C compiler flag to discover mistakes in our code. However, applying that flag across the board gives warnings from cython-generated code.
Here's an example
# cython: language_level = 3

def a(x):
    pass

def b():
    a(1)

With Cython version 0.29.17 it generates code that shadows local variables:
$ cython cythonshadow.pyx && gcc -Werror=shadow -I/usr/include/python3.8 cythonshadow.c  -c
cythonshadow.c: In function ‘__Pyx_PyObject_Call2Args’:
cythonshadow.c:1903:19: error: declaration of ‘args’ shadows a previous local [-Werror=shadow]
 1903 |         PyObject *args[2] = {arg1, arg2};
      |                   ^~~~
cythonshadow.c:1900:15: note: shadowed declaration is here
 1900 |     PyObject *args, *result = NULL;
      |               ^~~~
cythonshadow.c:1909:19: error: declaration of ‘args’ shadows a previous local [-Werror=shadow]
 1909 |         PyObject *args[2] = {arg1, arg2};
      |                   ^~~~
cythonshadow.c:1900:15: note: shadowed declaration is here
 1900 |     PyObject *args, *result = NULL;
      |               ^~~~
cc1: some warnings being treated as errors

If more people thinks this is desirable, I can prepare a pull request. Vote thumbs up! If people vote thumbs down and prefer readable generated code, let's just close the bug without action.

__Pyx_PyObject_Call2Args has simplified considerably for Cython 3 so in the long-term this specific warning will go away. However, I think we're generally trying to remove as many C warnings as is reasonably possible, so a PR against the 0.29.x branch would be welcome.

a PR against the 0.29.x branch would be welcome.

… if it shows a very low risk of breaking other people's code. If this is already fixed in the latest Cython releases, then the arguments for backporting (or creating) a fix need to be weighed off against the risk of breakage in a (very) stable release series.
Also, I'd rather like to avoid making 0.29.x diverge itself from the master branch, rather than only the other way round. That increases the risk of difficult to resolve merge conflicts and unnoticed merge accidents (such as: still works but generates dead/duplicate/useless code).

No worries, let's do it in measter.
However, I found that the code purposedly uses shadowed variables in the  __PYX_MARK_ERR_POS() macro. If this macro is expanded on a module level, it sets global variables __pyx_filename and __pyx_lineno. However, in a node level, it writes to local variables instead.
This was the first error in the test suite ran with CFLAGS="-Werror=shadow", maybe there are more places where shadowing is used as a feature.
I'll give up for now on this bug.

it sets global variables __pyx_filename and __pyx_lineno. However, in a node level, it writes to local variables instead.

Yes, local variables are the right thing to use here. I think we tried removing the global variables as part of the PEP-489 / module-local state changes. Probably still lingering in an unmerged PR somewhere, but I guess it could just be done independently.

(In case it wasn't clear: PR welcome.)

authors: da-woods kalvdans scoder


text:
[ Rfc ]Coercing sliced array to Python  object

fix for https://github.com/cython/cython/issues/2159
(I started it earlier and had to finish it)
Potentially I went to wrong way, ready to comments.

test

up

Hmm, hang on, I'm confused now. The previous implementation used Cython implemented utility functions. Why did you switch over to manual code generation? In fact, why not just change the existing carray.to_py conversion function to accept a start and end index?

Also, there's already a carray_slicing.pyx test. You can just add the new test there, no need for a new test file.

ok, thanks for the comments

I didn't right understand previous comment about movement code into separated node, now I see that I can simply enable utility for CArray type and to use them (if I right understood).
Thanks for the comments.

Seems I have found some additional bugs for converting c-array (and slice of c-array) to py  (comments have been added)
Commits I will fix later.

Changes by comments were done

I tryed __Pyx_PyFrozenSet_New(NULL) with PySet_Add and I had error, so I simple used __Pyx_PyFrozenSet_New.
Changes by comments were done.

up

When __Pyx_PyFrozenSet_New(NULL) is used, occurs error
...
SystemError: ../Objects/setobject.c:2334: bad argument to internal function
when I have checked source of Python, error is in check
if (!PySet_Check(a) &&
        (!PyFrozenSet_Check(a) || Py_REFCNT(a) != 1)) {
        PyErr_BadInternalCall();
}

more precisely in
Py_REFCNT(a) != 1.
Count of refferences of new frozenset object which is returned by __Pyx_PyFrozenSet_New(NULL) is more than one (in my case 22). It occurs since frozenset.tp_new for empty set returns empty frozenset-singleton.
So seems like  __Pyx_PyFrozenSet_New(NULL)  can't be used.

Note that __Pyx_PyFrozenSet_New(NULL) is not from CPython but from Cython, where it explicitly supports NULL:
https://github.com/cython/cython/blob/aa8b0d9b89030c0b9ace5698ae5131c623acefa4/Cython/Utility/Builtins.c#L444-L445

I saw it, and I meant the last part of function
#if CYTHON_USE_TYPE_SLOTS
    return PyFrozenSet_Type.tp_new(&PyFrozenSet_Type, $empty_tuple, NULL);
#else
    return PyObject_Call((PyObject*)&PyFrozenSet_Type, $empty_tuple, NULL);
#endif
}

more precisely
PyFrozenSet_Type.tp_new(&PyFrozenSet_Type, $empty_tuple, NULL);
-- this function returns frozenset-singleton (with ref-count 22), and if this singleton is used by PySet_Add, it creates error which is mentioned in my previous comment.

Ah, ok, understood. Then you were right before and we're back to first creating a (non-frozen) set or a tuple initially and then converting it to a frozenset afterwards. Creating a set instead of a tuple should be more (memory) efficient in the face of duplicate values. Converting a set into a frozenset is just a flat copy of the internal data structure, with all the hashing and deduplication already done.

BTW, @demiurg337, everything that you tried and that failed along the way and required you to take a different route with a special case, would best be remembered as a code comment in a suitable place. Otherwise, in a few months or years, someone will look at this code and say "there's room for optimisation", where we already knew at some point that there is none.

Comments were added, set is used for creation frozenset now.
Have I to merge the commits?
(I see possible structure like:
-- tests for carray slicing
-- test for c-array slice auto encoding
-- code for coercing slice of c-arrays to python object)
About bug with frozenset, issue has been openned
https://foss.heptapod.net/pypy/pypy/-/issues/3251

Changes by comments were done

Looks like travis didn't pick up the latest change. I'll close and reopen to trigger a build.

I have merged the commits (maybe too early)


text:
Changed external function declarations to not use DL_IMPORT.

Prior to this change, the DL_IMPORT macro was being used for
external function declarations. On Windows, that made it so
that functions declared in this manner had to be loaded from
a dll and not linked from an object file.
External declarations attempting to use a function directly from an
object file would fail with an obscure linker error.

I'm not really sure why all the business about the DL_IMPORT and DL_EXPORT macros is in there at all. It may be a good idea to remove it entirely. On the other hand, that could break code in unexpected places downstream. I don't know enough to say for sure what that would do.
These macros were deprecated in Python a long time ago and are still present in Python 2 for backwards compatibility. As to my knowledge, they aren't present in Python 3.
The definitions are at https://hg.python.org/cpython/file/648dcafa7e5f/Include/pyport.h#l806.

Any news on this?
I dug through the commit history and the last time this behavior was changed was in https://github.com/cython/cython/commit/0a56c99d77fe003e803e719643c40608edb2dfcf#diff-dac12aee9a0a30ee462caf55dd9865efR993
@dalcinl can you shed any light on this?

I believe this PR will break module sharing on Windows.
http://docs.cython.org/src/userguide/sharing_declarations.html#sharing-declarations

@sturlamolden importing functions between modules works fine for me when compiling on windows with mingw-w64. Do you have a specific example in mind?

Ran into this issue in the context of http://trac.sagemath.org/ticket/19868#comment:24
I agree with @insertinterestingnamehere that the DL_IMPORT macro should not be used. As they wrote it is not even present on Python 3, so exporting symbols will break when compiling for Windows on Python 3.
This is still necessary to have in general for linking C code to a dll.  However, as I wrote in the above Trac comment the better way to do this would be to add external symbols to the .def file generated by distutils' cygwincompiler.
So rather than outputting DL_IMPORT this should add to the Extension object's export_symbols list, if at all possible.

Perhaps this could be addressed like so:
The CompilationResult object can grow an attribute to hold the names of any external symbols that should be in a module. It should be easy enough to do this somewhere in ModuleNode (which I haven't fully understood yet).
The CompilationResultSet returned by compile is not currently returned by the cythonize_one function, but it should be.  If it were then cythonize could inspect the compilation results and make additional modifications to the Extension objects as needed.  It would also be kind of nice if an option were added to cythonize to optionally return the CompilationResultSet along with the module_list, as a tuple.  I've found myself wanting something like this before, for example to inspect the files generated by Cython--specifically what header files were generated.

So, after having worked with stuff like this a lot more, I still think this patch is a net gain. It does absolutely no harm to any of the existing functionality. On top of that, it's not the best idea to insist on using macros that have been deprecated for so incredibly long.
That said, as far as I know, it's not possible in general to fix this problem without knowing beforehand whether the needed symbol is coming from a dll or from a static object. MSVC allows dllimported functions to be used without __declspec(dllimport), but that isn't true of variables. The linker needs to know beforehand whether the variable is getting loaded from a dll or statically linked. Currently the only way to get this to work in all cases is to use the proper specifier in a header and then include it in the Cython file using a cdef extern from block. The only way to change that would be to add support for visibility specifiers to Cython, but these things are really handled much better by the C preprocessor.
It's not clear to me how an additional def file would help the situation since symbols declared extern are resolved by the linker and we need to know where the symbol is coming from before the linker sees any of this. Can you explain a bit more about how this helps the situation?
It's also concerning that we'd be saying these symbols are dllexported. Python modules are only supposed to export their initialization routine. Everything else should have hidden/internal/static visibility. I'm wary of letting modules implicitly export anything more than that.

Is it really a problem if a Python module does export other functions?  Because whether using __declspec(dllexport) or a DEF file the functions are still exported in the dll.  The extension module can still be imported fine regardless, and this is necessary to make C functions defined in a Cython module available to external C code, which is a supported use case AFAICT.

https://docs.python.org/3/extending/extending.html#providing-a-c-api-for-an-extension-module the second paragraph describes some issues there. Exporting things as a part of the shared object interface isn't strictly necessary either. Cython's public declarations export things directly as a part of the shared object's interface, but the API declarations do not. They route all needed functions and data through Python using capsules. Problems caused by leaked symbols are rare, but they are still better avoided. If we opted to allow dllexporting things to try to fix the symbol visibility issues, I'd really appreciate if it were an option that was at least left off by default.
That aside, are we certain marking things as exported (via dllexport or a def file) works for both functions and variables that are either statically or dynamically linked? I wouldn't be surprised if that tricked the compiler into doing the right thing, but I haven't verified that.

Thanks for the link--I'll give that a read and think about it some more.

Ok, I'm leaning toward seeing things @insertinterestingnamehere's way insofar as capsules should be used for sharing between Python modules. But I'm not entirely sure that's always appropriate--it seems like a bit of overkill.  What if I just want some C code to link to my Python module but not actually use anything that requires the Python interpreter?

Hmm. To cover that use case, exporting something as public should probably dllexport it as well. Even though capsules are the best practice, marking something as public was designed to export things as a part of the shared object interface.

Yup--portability issues aside sometimes we need this and the caveats discussed here are not a concern.
But the header file needs to still use a DL_IMPORT-like macro that marks a function or variable __declspec(dllexport) when building the module, but __declspec(dllimport) when building code that links to this module.  This is controlled by a macro that would only be defined when building the module--something like modulename_SHARED.  The alternative is using a .DEF file.

All Python modules are built as shared objects/dlls, so it seems reasonable to just make that one of the predefined macros set at the beginning of each Cython file. Generated public headers don't currently work when included in the same translation unit as the generated C file, so the public headers can probably just make a similar define to make things dllimported. That doesn't cover the use case where people are building multiple C files together into a single module, so we'll probably need some sort of preprocessor switch to make everything work right, but it won't be necessary in most cases.

Okay, small correction on that last one, all Cython modules, not necessarily all Python modules.

Generated public headers don't currently work when included in the same translation unit as the generated C file, so the public headers can probably just make a similar define to make things dllimported.

Not if the module also includes plain C files (not generated by Cython) that use functions defined in the Cython module.  There it's convenient to use the generated header file, but if that declares the function __decspec(dllimport) linking will fail, since dllimport mangles the name :)
Here's a simple example: https://gist.github.com/embray/12a67edb82b213217e31f408007898e6
If you run python setup.py build_ext --inplace you'll get an error:
x86_64-w64-mingw32-gcc.exe -shared -Wl,--enable-auto-image-base -pipe -s -DDL_IMPORT -s build/temp.mingw-2.7/foo.o build/temp.mingw-2.7/fooutil.o build/temp.mingw-2.7/foo.def -LC:/msys64/mingw64/lib/python2.7/config -LC:/msys64/mingw64/lib -lpython2.7 -o build/lib.mingw-2.7/foo.pyd
build/temp.mingw-2.7/fooutil.o:fooutil.c:(.text+0x26): undefined reference to `__imp_hello'
collect2.exe: error: ld returned 1 exit status

However, if you compile with
CFLAGS="-DPy_BUILD_CORE" python setup.py build_ext --inplace

this makes DL_IMPORT behave correctly for building the extension module.  This provides a  workaround for now but I completely agree DL_IMPORT should not by used by Cython at all.  This also exports the hello function which I want in this case:
dumpbin.exe -exports foo.pyd
Microsoft (R) COFF/PE Dumper Version 14.00.23506.0
Copyright (C) Microsoft Corporation.  All rights reserved.

Dump of file foo.pyd

File Type: DLL

  Section contains the following exports for foo.pyd
...
    ordinal hint RVA      name

          1    0 000014A0 hello
          2    1 00001587 initfoo

If I hand-edit "foo.h" to remove the DL_IMPORT from the declaration for hello the module builds fine, but hello is no longer exported.

Right. I think we're on the same page here. It'd be good if we could structure the defines in the main module source and generated header so that, in the most common case, where a single source file is used to create a single module, no additional flag to the compiler is necessary. Public symbols should definitely be dllexported by some macro (other than the deprecated one from the Python headers).

Ok, using a macro like DL_IMPORT looks like it will be easier than mucking around with DEF files, so long as Cython can handle it properly.  I'm working on a patch.

So one thing that's not obvious is what the best way is to make Cython force certain compiler options.  In this case it should attach a define_macros to each relevant Extension object. But it's not clear where the best place is to do that.

I found a good test in the test suite that demonstrates this problem: (tests/compile/declarations.srctree).  The test was even designed with this issue in mind, but it fails (this patch doesn't explicitly help since the files in that test are all hand-written).
The test writes a C file called external_declarations.c wherein a bunch of objects are declared DL_EXPORT. There's an accompanying header external_declarations.h where the same objects are declared DL_IMPORT.  All fine, for linkage from external code.
However, it also writes a declarations.pyx which contains cdef extern from "external_declarations.h", and when the resulting declarations.o and external_declarations.o are combined the linker fails:
$ CFLAGS="-O0" ./runtests.py -vv --no-cpp declarations
Python 2.7.10 (default, Jun  1 2015, 18:05:38)
[GCC 4.9.2]

Running tests against Cython 0.24 f68b5bd0fa620d0dc26166bffe5fe42d94068720 + uncommitted changes
Backends: c

runTest (__main__.EndToEndTest)
End-to-end declarations ... /usr/bin/python setup.py build_ext --inplace
running build_ext
cythoning declarations.pyx to declarations.c
building 'declarations' extension
creating build
creating build/temp.cygwin-2.4.1-x86_64-2.7
gcc -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -O0 -I/usr/include/python2.7 -c declarations.c -o build/temp.cygwin-2.4.1-x86_64-2.7/declarations.o
gcc -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -O0 -I/usr/include/python2.7 -c external_declarations.c -o build/temp.cygwin-2.4.1-x86_64-2.7/external_declarations.o
gcc -shared -Wl,--enable-auto-image-base -L. -O0 build/temp.cygwin-2.4.1-x86_64-2.7/declarations.o build/temp.cygwin-2.4.1-x86_64-2.7/external_declarations.o -L/usr/lib/python2.7/config -L/usr/lib -lpython2.7 -o /home/embray/src/cython/BUILD/compile/declarations/declarations.dll

build/temp.cygwin-2.4.1-x86_64-2.7/declarations.o: In function `__pyx_f_12declarations_f':
/home/embray/src/cython/BUILD/compile/declarations/declarations.c:632: undefined reference to `__imp_ifnp'
/home/embray/src/cython/BUILD/compile/declarations/declarations.c:632:(.text+0x17): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `__imp_ifnp'
collect2: error: ld returned 1 exit status
error: command 'gcc' failed with exit status 1

FAIL
runTest (__main__.CythonCompileTestCase)
compiling (c) e_declarations ... ok
runTest (__main__.CythonCompileTestCase)
compiling (c) compile_declarations ... ok
runTest (__main__.CythonCompileTestCase)
compiling (c) error_declarations ... ok

======================================================================
FAIL: runTest (__main__.EndToEndTest)
End-to-end declarations
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./runtests.py", line 1420, in runTest
    self.assertEqual(0, res, "non-zero exit status")
AssertionError: non-zero exit status

----------------------------------------------------------------------
Ran 4 tests in 6.240s

FAILED (failures=1)
ALL DONE

Another test that similarly demonstrates the problem is tests/compile/callingconvention.srctree :

See also #1671 which documents better how cdef public is supposed to be used.

Looking at this patch, I just realized that it's cdef extern: and not about cdef public. I opened #1687 to deal with cdef public. What kind of linkage should be used for cdef extern: is tricky because it depends on how it's used. There are certainly valid use cases where cdef extern: would be used with a DLL.
So I'd like to understand better what your use case is which requires the patch on this PR. If you're linking against a file that you compiled yourself from C, you could also compile it as one object file by using
cdef extern from "external_c_file.c":
    ...

Yah, I don't remember the particular use-case that made me start this PR. I think it was something like what you're thinking. The only catch is that the technique you describe doesn't help when interacting with static/shared libraries provided by languages other than C. The only reliable way I've found to get consistent behavior for this sort of thing in general is to provide any dllexport/import information in a header and then make the cython extern declaration pull everything from the header.

authors: embray insertinterestingnamehere jdemeyer sturlamolden


text:
Set upper limit on DuckDB version (<0.10.0) to avoid Arrow errors

Description
This PR sets an upper limit of <0.10.0 on DuckDB to avoid Arrow errors. The change comes about as a result of discussions in #163 (thank you @shntnu!). It looks like a fix is forthcoming via changes related to duckdb/duckdb#11157 . Just the same, I wasn't sure which release might next include the fix, so I focused on stability for existing users / capabilities for now.
References #163
What is the nature of your change?

[x] Bug fix (fixes an issue).
[ ] Enhancement (adds functionality).
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected).
[ ] This change requires a documentation update.

Checklist
Please ensure that all boxes are checked before indicating that a pull request is ready for review.

[x] I have read the CONTRIBUTING.md guidelines.
[x] My code follows the style guidelines of this project.
[x] I have performed a self-review of my own code.
[ ] I have commented my code, particularly in hard-to-understand areas.
[ ] I have made corresponding changes to the documentation.
[x] My changes generate no new warnings.
[x] New and existing unit tests pass locally with my changes.
[ ] I have added tests that prove my fix is effective or that my feature works.
[x] I have deleted all non-relevant text in this pull request template.

Thank you @gwaybio ! Going to merge this in. I've also labeled this as a patch release which will trigger v0.0.5 to be created on merge to help expedite reaching users with a fix.

repo: cytomining/CytoTable


text:
support multi-pos datasets that are not complete multi-well plate acquisitions

There is an apparent gap in data formats specified by OME-NGFF and supported by napari-ome-zarr plugin: they specify/support single FOV ND arrays or multi-FOV ND arrays acquired in a multi-well plate, but not simple multi-pos acquisitions.
We can represent this data as as a multi-well dataset to leverage the napari-ome-zarr plugin for visualization.
This topic requires a discussion among @ziw-liu , @Soorya19Pradeep , @jrbyrum13 , @Christianfoley , @ieivanov, @talonchandler  who either acquire or analyze multi-pos datasets.
I see two options:

Have a single column, with row names = position names in micro-manager acquisition .
Map the data to a square grid to make it easy to visualize with napari plugin, e.g., if we have 100 FOVs, sort them into 10 rows and 10 columns.

Votes & Ideas?

I think the current API is expressive enough to store arbitrary HCS-conformant layouts.
If there's a specific problem/question about usage, please open a separate issue.

authors: mattersoflight ziw-liu

repo: czbiohub/iohub


text:
Heart_FACS

All clusters have been reannotated. However, cluster 11 is a a new cluster only showing up this time. After gene ontology analysis of the uniquely expressed genes in this cluster, those cells seem to be neuron cells (maybe conduction cells), but they do not express the commonly used cardiac conduction cell marker genes, so I have annotated them as NA.

Hi Olga,
If 'conduction cells' is not valid, maybe you can use 'neuron cells' or
'NA'. Thanks.
Best,
Guang
On Mon, Feb 26, 2018 at 3:23 PM, Olga Botvinnik notifications@github.com
wrote:

Great, one last thing! Please change the term "conduction cells" to
something valid in the cell ontology:

validate_cell_ontology(cell_ontology_class)
Error in validate_cell_ontology(cell_ontology_class) :
"conduction cells" is not in the cell ontology

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/czbiohub/tabula-muris/pull/111#issuecomment-368687460,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AeD2MKy8VPaM6Mgb2qEEEKQSDEOS7u4oks5tYzzcgaJpZM4SNGak
.

Hi Olga,
Please use cardiac neuron. Thanks.
Best,
Guang
On Wed, Feb 28, 2018 at 2:16 PM, Olga Botvinnik notifications@github.com
wrote:

Even more specifically, there is "cardiac neuron" -
http://www.ontobee.org/ontology/CL?iri=http://purl.
obolibrary.org/obo/CL_0010022. Should we use "cardiac neuron" ?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/czbiohub/tabula-muris/pull/111#issuecomment-369402562,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AeD2MOlcjxug15oZtY8m55O5THM3Acx6ks5tZdBWgaJpZM4SNGak
.

repo: czbiohub/tabula-muris


text:
Xcode 7.3b1 API compatibility (9)

Upgraded XcodeServerSDK to version 0.5.4 which works with the new API version number (no actual behavioral changes found yet).

Result of Integration 1
Duration: 8 seconds
Result: -1 error, failing state: trigger-error

Result of Integration 2
Duration: 4 minutes and 54 seconds
Result: -1 error, failing state: trigger-error

Result of Integration 3
Duration: 4 minutes and 34 seconds
Result: Perfect build! All 33 tests passed. :+1:
Test Coverage: 23%


text:
GPU install

I am trying to use 6 msi rx 570s on miner.  At what point during installation should I connect GPUs to the motherboard with PCIe risers? I’m having trouble booting into Ubuntu when I connect one GPU.

The installation works with 1 GPU or more GPUs. Don't forget to turn on the "BIOS" in the "Above 4G decoding" and "PCI Gen 2" settings.

repo: czombos/AMDGPU-XMR-ETH-Mining-Ubuntu


text:
Export type ActionCode and Code?

We need to log response and final action so that sysadmin can easily understand the response, hence converting Code / ActionCode to string like accept, continue, reject is required. But:

they're defined in internal/ package, we can not use them directly.
milter package doesn't offer function / method to do such convert.

So is it better to export Code, ActionCode, Message, ModifyActCode, all Act*, all Code*? They all are most important parts of the milter protocol.

Hi @iredmail,
could you elaborate on how you want to do the logging/tracing that you need these types/constants? How do you get to the raw data that you actually want to use ActionCode and Code? Are you implementing a server or client?
When implementing a client: Are you using the mailfilter abstraction or are you implementing your own Milter?
FYI: The cmd package has both a logging client and server. They do not need to access that low-level types to do their logging.
This library aims to abstract away all protocol specifics of the milter protocol – that's why all constants in the wire package are internal and that's why I am a little bit reluctant to make them part of the public interface of this library.

could you elaborate on how you want to do the logging/tracing that you need these types/constants?

I want to log the action like accept, reject <reject-reason> instead of byte a (SMFIR_ACCEPT), r <reject-reason> (SMFIR_REJECT).

How do you get to the raw data that you actually want to use ActionCode and Code?

I write plugins for (a custom) milter server, each plugin registers itself in different state (e.g. Connect, Helo, EndOfMessage) and returns (*milter.Response, error). For example:
// it implements milter.Milter interface.
type Milter struct {
    // many fields here
}

type Plugin interface {
        Name() string
        Priority() int
        Apply(b *Milter, m *milter.Modifier) (*milter.Response, error)
}

type Registered struct {
        Connect      []Plugin
        Helo         []Plugin
        MailFrom     []Plugin
        RcptTo       []Plugin
        EndOfHeaders []Plugin
        EndOfMessage []Plugin
}

func applyPlugins(b *Milter, m *milter.Modifier, plugins []Plugin) (*milter.Response, error) {
        for _, p := range plugins {
                response, err := p.Apply(b, m)
                if err != nil {
                        // log
                        return milter.RespContinue, err
                }

                if !response.Continue() {
                        b.Logger.Info(`... response='%s' ...`, Pretty(response), )

                        return response, nil
                }
        }

        return milter.RespContinue, nil
}

The Pretty() function is what i'm working on.
When a plugin returns response like RejectWithCodeAndReason(451, "policy rejection"), i'd like to log something like temp_fail 451 policy rejection; and RejectWithCodeAndReason(550, "blacklisted"), i'd like to log reject 500 blacklisted.

Are you implementing a server or client?

A milter server (for Postfix).

Hi @iredmail
please have a look at PR #12 – does this handle your use case?
You would be able to write
// Applies all plugins registered in certain state.
func applyPlugins(b *Milter, m *milter.Modifier, plugins []Plugin) (*milter.Response, error) {
        for _, p := range plugins {
                response, _ := p.Apply(b, m)
                if err != nil {
                        // omit
                }

                if !response.Continue() {
                        b.Logger.Info(`... %s ...`, response.String(), )

                        return response, nil
                }
        }

        return milter.RespContinue, nil
}

please have a look at PR #12 – does this handle your use case?

Yes, this is indeed what i'm looking for, but since i cannot modify imported milter library directly, i have to write my own one instead. Do you plan to merge this PR?

The returned string is logfmt compatible – ading commas would not be compatible. You could use a logfmt parser like https://pkg.go.dev/github.com/go-logfmt/logfmt#example-Decoder to change the output to your liking.
I have added the data_len on top of the data since the data string might very well include hex codes (uint32 numbers, null-bytes, etc.) and thus you would need to parse the data string to figure out the actual byte length of it.

its released: https://github.com/d--j/go-milter/releases/tag/v0.8.3

Thanks @d--j :)

authors: d--j iredmail

repo: d--j/go-milter


text:
Bug in running CVC

Not sure why this line is here, but it is causing the path to be wrong, my solution was
-BASE_NAME=${DESIGN_NAME//[A-Z0-9][A-Z0-9]_/} # remove leading 2 byte prefices
-if [[ (! -f $WORK_ROOT/$DESIGN_NAME/$DESIGN_NAME.power) && -f $LVS_ROOT/cvc/$BASE_NAME.$PDK.power ]]; then
-       cp $LVS_ROOT/cvc/$BASE_NAME.$PDK.power $WORK_ROOT/$DESIGN_NAME/$DESIGN_NAME.power
+# BASE_NAME=${DESIGN_NAME//[A-Z0-9][A-Z0-9]_/} # remove leading 2 byte prefices
+if [[ (! -f $WORK_ROOT/$DESIGN_NAME/$DESIGN_NAME.power) && -f $LVS_ROOT/cvc/$DESIGN_NAME.$PDK.power ]]; then
+       cp $LVS_ROOT/cvc/$DESIGN_NAME.$PDK.power $WORK_ROOT/$DESIGN_NAME/$DESIGN_NAME.power

@marwaneltoukhy Thanks. Probably should anchor it to the front. make ship will add 2 byte random prefixes to sub blocks including user_project_wrapper. This gives something like A7_user_project_wrapper. However, this block does not have a default power definition while user_project_wrapper does. What path is incorrect?

Not sure if what I'm going to claim is accurate so please correct me if I'm wrong; make ship will only add those 2 bytes if the error we saw/debugged earlier last week happens, where it tries to read in two files with the same name, once gds and once mag. If that's the case then that's something wrong with the build script that needs to be fixed.
Also, in my case I'm running directly on user_project_wrapper so I don't actually run make ship so that line messes with the name of the cell user_project_wrapper which is correctly defined in the variable DESIGN_NAME to make it something else, meaning the script is searching for the wrong cell name.

Not sure where the extra 2 byte prefix comes from either, but all the oasis files have it.
${DESIGN_NAME//[A-Z0-9][A-Z0-9]_/} this is just a global substitution on the DESIGN_NAME value - globally replacing [A-Z0-9][A-Z0-9]_ with nothing. If DESIGN_NAME  is user_project_wrapper, it shouldn't change anything.

It changes user_project_wrapper to usprojewrapper

Here's a comparison:
user@chipignite-clear-dv-01:~/$ shopt nocasematch
nocasematch     off
user@chipignite-clear-dv-01:~/$ test_cell=AF_user_project_wrapper
user@chipignite-clear-dv-01:~/$ echo ${test_cell//[A-Z0-9][A-Z0-9]_}
user_project_wrapper

user@chipignite-clear-dv-01:~/$ shopt -s nocasematch
user@chipignite-clear-dv-01:~/$ shopt nocasematch
nocasematch     on
user@chipignite-clear-dv-01:~/$ echo ${test_cell//[A-Z0-9][A-Z0-9]_}
usprojewrapper

user@chipignite-clear-dv-01:~/$ shopt -u nocasematch
user@chipignite-clear-dv-01:~/$ shopt nocasematch
nocasematch     off
user@chipignite-clear-dv-01:~/$ echo ${test_cell//[A-Z0-9][A-Z0-9]_}
user_project_wrapper

I think this is fixed with shopt -u nocasematch, so I'll close it.
@marwaneltoukhy Please reopen if there are still problems.

authors: d-m-bailey marwaneltoukhy


text:
Idan

very detailed information here. as you can see.

you are Idan.
this is a PR to upload the CV of Idan.
please fix the title.

you said do pull request in class this pr is nothing but a test.

authors: TheLastVigil davidmeirlevy


text:
🛑 Staging Webhook Public Api is down

In 448f3c1, Staging Webhook Public Api ($STAGING_WEBHOOK) was down:

HTTP code: 503
Response time: 407 ms

Resolved: Staging Webhook Public Api is back up in dba19e8.


text:
Cookies!

TODO: Cookies tags like "Expires", "Max-Age", etc. (own class perhaps?)

This whole server implementation over sockets was too experimental. I'm moving backend to Sun's httpserver now.


text:
how to accelerate the speed of dectecting?

I train my own dataset with faster-rcnn, and there is only on class,but it cost 8 to 9 seconds on every image.That's too slow for me project.Is this because that I use cpu to train? Can anyone help me ?Thank you very much.

Yes, of course using CPU instead of GPU slows you down
If you are worried about the fact the it is a lot, it is normal, the process is really intensive

authors: GZYZG morpheusthewhite


text:
docs: Adds openshift gitlab guide

This replaces https://github.com/dagger/dagger/pull/6153
The OpenShift GitLab guide has been adapted to the new documentation structure.

If anything needs changing adding @vikram-dagger, let's do it in a follow-up, I don't want to delay this addition further.

This is now live: https://docs.dagger.io/488564/openshift-gitlab

authors: chrira gerhard

repo: dagger/dagger


text:
install.sh - fix bash completion instructions

The XDG_DATA_HOME env var can be empty (expectedly), and it breaks the printed bash completion setup instructions. This little PR makes the install script use the default $HOME/.local/share location when the XDG_DATA_HOME is empty. See  https://specifications.freedesktop.org/basedir-spec/latest/ar01s03.html

Nice catch, nice catch! Going to merge this now, but for this to appear on the dl site, we need to do some manual AWS hackery :tada: (cc @gerhard @matipan)

Thanks for the quick approval!

Reminder to self + @matipan: add a Dagger function that uploads this to S3 & invalidates the cache.
Did this manually:

Thanks @iximiuz 💪

authors: gerhard iximiuz jedevc


text:
Support server bundling with vite

Currently, wakuwork uses react-server-dom-webpack/node-loader for handing "use client" and "use server".
We use vite for client bundling, but for server bundling we use a naive approach.
It's limited. For example, we now don't support "use client" in node_modules.
I'm hoping we could use vite for server bundling. Wish vite-rsc does that.
@nksaraf What's the current status?

I will see if I can do it in this repo.

Have you thought through it?
I guess we just need to adapt the register logic in Rollup and apply it for use client components in transform hook.

Well, I'm learning vite. Will open a PR if something is ready.

Having a trouble...

repo: dai-shi/wakuwork


text:
FullScreen not working

Hi,
With the latest version, using the PlayerWebView, fullscreen mode is not working anymore. If I click on the button, nothing happens.
Any idea why ?
Thanks in advance,
Julien

never mind, took a look at your sample app ;)


text:
Cannot find symbol 'SliderLayout'

Hi,
I face issue import the library.
I follow the wiki by include this in my gradle
compile "com.android.support:support-v4:+"
    compile 'com.squareup.picasso:picasso:2.3.2'
    compile 'com.nineoldandroids:library:2.4.0'
    compile 'com.daimajia.slider:library:1.1.5@aar'

I sync the gradle with my project.
Still i face the cannot find symbol ;..
Any idea?
Thank

try my library @vsay01 https://github.com/jjhesk/LoyalNativeSlider

repo: daimajia/AndroidImageSlider


text:
Custom encoder doesn't work on PersistentQueue

(cheshire.custom/add-encoder clojure.lang.PersistentQueue cheshire.custom/encode-seq)
(cheshire.core/encode clojure.lang.PersistentQueue/EMPTY)

results in: No matching clause: clojure.lang.PersistentQueue@0

This is fixed (and supported by default) in 3.0.0, thanks!

authors: dakrone technomancy

repo: dakrone/cheshire


text:
Fix Active Directory search and mutiple search reference

Hi @bersace,
as asked on issue #228 here's the pull request.
In order to be simpler to manager Active Directory  I've added a new parameter in YML ldap section:
activedirectory: True/False
E.g. ldap2pg.yml
ldap:
  uri: "ldap://pdc.office.company.com:389"
  binddn: CN=inetwork,OU=Network Service Account,DC=office,DC=company,DC=com
  user: OFFICE\inetwork
  password: "******"
  activedirectory: True

Codecov Report

Merging #236 into master will decrease coverage by 0.19%.
The diff coverage is 50%.

@@           Coverage Diff            @@
##           master    #236     +/-   ##
========================================
- Coverage     100%   99.8%   -0.2%
========================================
  Files          12      12
  Lines        1543    1549      +6
========================================
+ Hits         1543    1546      +3
- Misses          0       3      +3

Impacted Files
Coverage Δ

ldap2pg/config.py
100% <ø> (ø)
:arrow_up:

ldap2pg/ldap.py
98.89% <33.33%> (-1.11%)
:arrow_down:

ldap2pg/manager.py
99.33% <66.66%> (-0.67%)
:arrow_down:

Continue to review full report at Codecov.

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

@datinho thanks for the PR ! Can you just put this option in ldaprc ?
I'm not convinced to add a activedirectory option. I would like ldap2pg to be configurable like a regular ldap tool.
Maybe the bug is that ldap2pg does not read REFERALS from ldaprc.
What is your opinion on this ?

Do you think we should add REFERALS in https://github.com/dalibo/ldap2pg/blob/master/ldap2pg/ldap.py#L245-L252 ?

Hi @bersace,
It could be the right parameter, but I must take a time to change and test it.
Meanwhile feel free to merge or not this request.

@datinho ok, no hurry. I should have time for this next week.

The change was not so difficult and I've test the option on my environment.

@datinho this looks awesome. I'll check this out on monday.
@cbandy good point. I'm ok to have default value to 0 in ldap2pg. :+1:

Let me reply in one comment:

LDAPREFERRALS vs REFERRALS: I wasn't aware of the interactions of YAML/ENV/con file, so I wrote something that could be similar to ldaprc syntax
referrals True: I had set it to be compatible with python True/False parameter
comment for developers: I've just comment it in order to keep the different behavior of Active Directory, it is not mandatory
logger.debug("Evalutate: it was useful for me during the debug and develop, it is not mandatory
not dn: problem with multiple search reference returned by AD search filter https://github.com/dalibo/ldap2pg/issues/228#issuecomment-415058907
\n problem: it's my mistake, I've worked on older file and then copied on repo.

I'm not a developer so I've tried to fix as best as I could do, I don't understand if you can push the changes that you prefer or you are waiting from me anothe push request.

@datinho sorry if i'm not clear enough :/

I don't understand if you can push the changes that you prefer or you are waiting from me another push request.

I can't push the changes in your branche, because it's on your fork.
That is not a problem. I can merge your branch as-is and continue the development. That's a nice contribution for a non developer :-) I just want you're acknowledgement for that.

authors: bersace codecov-io datinho

license: PostgreSQL


text:
Add support for the Swift Package Manager

Although the manager is in infancy, I find it much easier to use than CocoaPods or Carthage.
To add support simply create a directory named Source and move all needed swift files to it. Then create a Package.swift at the top level.

The Package.swift might look like
import PackageDescription

let package = Package(
    name: "Starscream"
)

Sweet. I will do that. Thanks for the info.

I'm not sure it will work with Source. Make it Sourcesand that should work.
See here http://blog.krzyzanowskim.com/2015/12/04/swift-package-manager-and-linux-compatible/
On 23 Dec 2015, 19:01 +0000, Daltonnotifications@github.com, wrote:

Sweet. I will do that. Thanks for the info.
—
Reply to this email directly orview it on GitHub(https://github.com/daltoniam/Starscream/issues/149#issuecomment-166971081).

I think it can be either. It works with Source for me.

Now you guys are going to make me have to decide :smile:. I think normally source would be the more common expression, but either way, just need to get it supported. Thanks for the links and input.

For reference (at least I think it is):
https://github.com/apple/swift-package-manager/blob/28f5027f025cd0ea9353d42c6286b4452ce68975/Sources/dep/Manifest%2BconfigureTargets.swift#L55

authors: daltoniam hamchapman nuclearace

repo: daltoniam/Starscream


text:
not found for model ViT-H-14.

when I run !python run_net.py
--cfg configs/exp01_vidcomposer_full.yaml
--input_video "demo_video/blackswan.mp4"
--input_text_desc "A black swan swam in the water"
--seed 9999
[2023-08-31 10:58:03,125] INFO: Loading ViT-H-14 model config.
[2023-08-31 10:58:15,720] WARNING: Pretrained weights (/content/vc/model_weights/open_clip_pytorch_model.bin) not found for model ViT-H-14.
Traceback (most recent call last):
File "/content/vc/run_net.py", line 36, in
main()
File "/content/vc/run_net.py", line 28, in main
inference_multi(cfg.cfg_dict)
File "/content/vc/tools/videocomposer/inference_multi.py", line 345, in inference_multi
worker(0, cfg)
File "/content/vc/tools/videocomposer/inference_multi.py", line 421, in worker
clip_encoder = FrozenOpenCLIPEmbedder(layer='penultimate',pretrained = DOWNLOAD_TO_CACHE(cfg.clip_checkpoint))
File "/content/vc/tools/videocomposer/inference_multi.py", line 108, in init
model, _, _ = open_clip.create_model_and_transforms(arch, device=torch.device('cpu'), pretrained=pretrained)
File "/usr/local/lib/python3.10/dist-packages/open_clip/factory.py", line 151, in create_model_and_transforms
model = create_model(
File "/usr/local/lib/python3.10/dist-packages/open_clip/factory.py", line 122, in create_model
raise RuntimeError(f'Pretrained weights ({pretrained}) not found for model {model_name}.')
RuntimeError: Pretrained weights (/content/vc/model_weights/open_clip_pytorch_model.bin) not found for model ViT-H-14.

You need to download the model files we provide first, as described in the instructions.

authors: Steven-SWZhang woozheng

repo: damo-vilab/videocomposer


text:
LuaSocket segfault after some amount of I/O

From @GoogleCodeExporter on May 31, 2015 11:31
What device(s) are you experiencing the problem on?
Iconia Tab A200

What firmware version are you running on the device?
CyanogenMod 9

What steps will reproduce the problem?
1. Create a Lua script which opens a socket for listening
2. Connect to the socket and send to it
3. After a while, the receiver segfaults.

Example receiver script:
require "android"
local listener = assert(socket.bind('localhost', 9999))
local sock = assert(listener:accept())
while true do sock:receive('*l') end

sender script:
require "android"
local sock = assert(socket.connect('localhost', 9999))
for i = 1, 1000000 do
	if not sock:send('.') then error("failed at " .. i) end
end
print("finished")

Start receiver, then sender, and receiver should segfault after a few seconds.

What is the expected output? What do you see instead?
Expected: receiver never terminates; sender runs for a few seconds then prints
"finished".
Actual: receiver segfaults after about 90,000 messages received.

What version of the product are you using? On what operating system?
Release 6 on CM9.

Please provide any additional information below.
The number of messages before segfault varies between about 60,000 and 95,000,
and is reduced by sending longer messages.

Original issue reported on code.google.com by hyperhac...@gmail.com on 15 Jul 2012 at 7:21
Copied from original issue: damonkohler/android-scripting#646

From @GoogleCodeExporter on May 31, 2015 11:31
Adding logcat.

Original comment by hyperhac...@gmail.com on 15 Jul 2012 at 7:23
Attachments:

logcat.txt


text:
refactored and cleaned-up controllers and webhooks code

Fixes #4, #14, #16, #57, #62. With this PR: A lot of unneeded code has been cleaned-up; All the controllers and webhooks now share the same structure and are well-documented, making it much easier to understand the code and expand it in the future; Error messages have been changed and added; Every instance of writing to an Elasticsearch index has been removed and instead ECS logger is used; Some open issues have been fixed in MigrationHierarchy and UpdateQuita; E2E testing is restructured to run in parallel with performance improved by almost x5 times; Controller now works in 1 replica instead of 3 due to issues with the in-memory namesapceDB across multiple replicas; HNS now runs with go 1.19, Dockerfile has been changed as well

/assign @fran2810

Broken up codes to different files

Pushed a new commit with the required changes and separated the code into more files even more

Pushed all changes, all tests pass as they should

looks good to me

/lgtm

repo: dana-team/hns


text:
Between on compound index

Hello,
I've been trying to make this following reql with gorethink and fail miserabily. I get no error in the debugger I'm just stuck on the request
reql
r.db("myDb").table("myTable").between(["myHash",r.time(2012,1,1,'Z')], ["myHash",r.now()], {"index": "userHash_date"}).orderBy({"index": r.desc("userHash_date")}).count()
Go:
betweenOpts := gr.BetweenOpts{Index: "userHash_date"}
orderByOpts := gr.OrderByOpts{Index: gr.Desc("userHash_date")}
start := gr.Time(2012, 1, 1, 'Z')
end := gr.Time(time.Unix(ilast, 0))
res, err := gr.DB("MyDb").Table("myTable", gr.TableOpts{ReadMode: "outdated"}).Between([]interface{}{id, start}, []interface{}{id, end}, betweenOpts).OrderBy(orderByOpts).Limit(qty).Run(prog.Session)

I'm wondering if I'm doing something wrong or if gorethink doesn't support compound indexes on between.
Thanks for your help !

Well sorry, my request as actually good it's my gr.Time that were wrong...

Hey, glad you figured out the issue 😄  Do you have any other questions?

authors: dancannon lomithrani

repo: dancannon/gorethink


text:
PreparedStatement预编译一次，多次set值多次executeUpdate数据相同

DataSource dataSource = getShardingDataSource();
String sql = "insert ignore into t_user(login_code,user_name,age,telephone,address) values(?,?,?,?,?)";
try (
Connection conn = dataSource.getConnection();
PreparedStatement ps = conn.prepareStatement(sql);){
List userList = getUserList(20);
for(User user:userList){
ps.setString(1, user.getLoginCode());
ps.setString(2, user.getUserName());
ps.setInt(3, user.getAge());
ps.setString(4, user.getTelephone());
ps.setString(5, user.getAddress());
ps.executeUpdate();
}
ps.close();
conn.close();
}

TableRule.builder("t_user").actualTables(Arrays.asList("t_user_0", "t_user_1", "t_user_2"));实际有三张表。这种情况下都往t_user_1表中写了。getShardingDataSource()换成原生的，数据不会相同。
ps = conn.prepareStatement(sql);放入for循环中正常，会正常往三张表里面写！

合并到 #36

authors: hanahmily xuchanggen

repo: dangdangdotcom/sharding-jdbc


text:
One less variable assignment in comments_helper.rb

Tiny patch to this ✨ awesome project 👍
Also my editor cleans up some trailing spaces in CHANGELOG.md.

          1 Warning

  :warning:
  Tests were not updated

          1 Message

  :book:
  @JuanitoFatas is not a contributor yet, would you like to join the Danger org?

  Generated by :no_entry_sign: danger

Hah - thanks!
I try to keep the CHANGELOG user facing ( I'll update the PR template to mention that ) but I'm happy to have this one in there 👯
Would you like to join the org? as a part of Moya Community Continuity - you're welcome to participate in PRs or help out at a level that works for you

I try to keep the CHANGELOG user facing ( I'll update the PR template to mention that ) but I'm happy to have this one in there 👯

I'll remember it, thanks! 📔

Would you like to join the org? as a part of Moya Community Continuity - you're welcome to participate in PRs or help out at a level that works for you

Yes I would like to join, thank you! ❤

authors: DangerCI JuanitoFatas orta

repo: danger/danger


text:
angular-file-upload interferes with hash navigation

When I add angular-file-upload as a dependency to my module, it starts interfering with my hash navigation. When visiting the url example.com/test/#documents it instantly redirects to example.com/test/#/documents
This seems to have nothing to do with click events, it appears to happen onload.

That's what angular does. The plugin doesn't do any modification on the window.location or $location.

I see ... once I add $location as a dependency I see this behaviour. That's not ideal but I'll work it out. Thanks for the response.

authors: aidanlister danialfarid

repo: danialfarid/angular-file-upload


text:
🛑 LABEL is down

In 9e84b85, LABEL (https://systemalpha.net/label) was down:

HTTP code: 0
Response time: 0 ms

Resolved: LABEL is back up in 21d1534 after 10 minutes.

repo: danichrisd/up


text:
Login frontend

Create a universal front end for the IPIMS

done