PyArray_NewFromDescr_int in ctors.c leaks the data buffer when a
user-defined DType's fill-zero loop raises an error.
This affects any DType that defines a get_fill_zero_loop that can fail —
for example, a fixed-point DType whose fill-zero rejects zero because it
falls outside the type's representable range.
can_elide_temp() in temp_elide.c incorrectly identifies new-style user-defined
dtypes as numeric types eligible for in-place buffer reuse. For large arrays this
silently rewrites a*a + b*b into (a*a) += (b*b), which raises a TypeError
when the result dtype of the in-place add does not match the pre-allocated buffer.
The maintainer (Sebastian Berg) suggests replacing most of PyArray_DescrFromScalar
with a two-step pattern:
DType class via PyArray_DescrFromTypeObject (robust, handles subclasses)NPY_DT_CALL_discover_descr_from_pyobject(DType, sc) unconditionally
scalar.astype(dst) silently fails for scalars belonging to parametric
new-style user-defined dtypes (introduced in NumPy 2.0). The intermediate
array NumPy creates internally uses the dtype's default descriptor rather
than the descriptor of the scalar instance, so setitem either rejects it or
stores wrong data. The fix is a one-function change to PyArray_DescrFromScalar
in numpy/_core/src/multiarray/scalarapi.c.
| import numpy as np | |
| import scipy.signal | |
| def sscascade(sslist): | |
| # The cascaded state-space representation can be constructed as block | |
| # matrices of the following form (example for 4 sub-systems): | |
| # A = [ A1 , , , ] | |
| # [ B2 @ C1 , A2 , , ] | |
| # [ B3 @ D2 @ C1 , B3 @ C2 , A3 , ] |
Somehow my BTRFS file system became corrupted by what appears to be a single bit flip in a metadata field. Rather than copying all the data and reformatting the file system, which would have required another disk at least as large as the original, I decided to try to fix this manually, which appears to have worked. I've documented the procedure I've used here, in case I need it again or someone else runs into a similar issue and finds it useful.
The first thing you should do is run btrfs check. For me this produced the following output:
Opening filesystem to check...
Checking filesystem on /dev/nvme0n1p1
UUID: ec7afe1c-8478-450a-82fc-d17b32d8ca3d
| import ctypes | |
| import glob | |
| import mmap | |
| import operator | |
| import os.path | |
| import time | |
| import numpy | |
| import matplotlib.pyplot as plt |
| QProgressDialog dialog("Parameter sweep ...", "Cancel", 0, (int) sweep_values.size(), this); | |
| dialog.setWindowTitle(MainWindow::WINDOW_CAPTION); | |
| dialog.setWindowModality(Qt::WindowModal); | |
| dialog.setMinimumDuration(0); | |
| dialog.setValue(0); | |
| std::atomic<bool> worker_canceled(false), worker_stopped(false); | |
| std::exception_ptr worker_exception; | |
| std::thread worker_thread([&]() { | |
| try { | |
| for(size_t i = 0; i < sweep_values.size(); ++i) { |
| # Maintainer: Schala <schalaalexiazeal "at" gmail {dot} com> | |
| # Contributor: calegria <calegria+al "at" gmail {dot} com> | |
| pkgbase=mingw-w64-harfbuzz | |
| pkgname=(mingw-w64-harfbuzz mingw-w64-harfbuzz-icu) | |
| pkgver=1.5.1 | |
| pkgrel=1 | |
| pkgdesc="OpenType text shaping engine (mingw-w64)" | |
| arch=(any) | |
| url="http://www.freedesktop.org/wiki/Software/HarfBuzz" |
| from pylab import * | |
| def segment_intersects_rectangle(x1, y1, x2, y2, cx, cy, w, h): | |
| return (fabs(x1 + x2 - 2.0 * cx) < fabs(x1 - x2) + w and | |
| fabs(y1 + y2 - 2.0 * cy) < fabs(y1 - y2) + h and | |
| 2.0 * fabs((x1 - cx) * (y1 - y2) - (y1 - cy) * (x1 - x2)) < w * fabs(y1 - y2) + h * fabs(x1 - x2)) | |
| def test_intersect(plot_line, plot_rect): | |
| for line in plot_line: | |
| (x1, x2) = line.get_xdata() |